Class design (how to choose between static classes and free static classes)

Because some framework designs often see
DB::get('mall')->where('aaa');
Why can't we do this
DB::get('mall')::where(' aaa');

Another problem is that objects produced through factories or static containers are generally static.
For example, for a log class, I have seen both static and non-static designs. A bit uncertain

Don’t tell me which tool type is best to be static without using nonsense like new.

Reply content:

Because some framework designs often see
DB::get('mall')->where('aaa');
Why can't we do this
DB::get('mall')::where(' aaa');

Another problem is that objects produced through factories or static containers are generally static.
For example, for a log class, I have seen both static and non-static designs. A bit uncertain

Don’t tell me which tool type is best to be static without using nonsense like new.

First you need to understand the difference between static and non-static.

Static class can be used without instantiation. In this case, there will be a slight performance improvement.

Static attributes are shared by all instances. No matter how many instances there are, there is only one static attribute.

Of course, if non-static classes are used as singletons, there is actually not much difference.

So how to choose between static and non-static? Depending on everyone's understanding of object-oriented, the method of use is different.

For example, log. If there is only one log object in a system, then using static classes is undoubtedly the best, as it is more convenient in terms of method calling, performance, and data storage. At this time, you can use this log object as an entity object or as an abstract object.

But if the log is refined into user behavior log, database operation log, server status log, etc., then the log is already an abstract object, and it needs to have an entity for better use. At this time, it would be better to use non-static ones and use new separately. Because although they all belong to the same log object, they have different data and methods. Function.

So, my personal understanding is that if a class is a complete functional module that does not depend on other modules and does not need to be extended to complete the function of this module, then it is best to write it statically.
If a class is just an abstract object and also depends on other modules, or needs to be extended, or needs to be inherited, etc., then it is better to use non-static ones

• In fact, it does not comply with the object-oriented design principles. In fact, any way you can write it will be fine

• Secondly, static classes are not easy to be recycled. In scripting languages ​​​​such as PHP, the life cycle of the script usually ends when the script is executed. The memory occupied by the script is theoretically recycled, so theoretically using static classes There is no memory recycling problem. But for Java, etc., the proliferation of static classes is not conducive to memory recovery