Focusing on principles and smart crystallization -- Reading on the concept of design

Question: I am reading the book "design: The Evolution nature of Professional Software Development" (won the 19th jolt Productivity Award). I wrote my thoughts and comments, just as I thought.

 

The principle of separation between use and creation is something I have never touched before. It is easy to understand, that is, separating the creation and use responsibilities of objects. In a system, restrict the relationship between any entity a and any entity B. A can create B, or a can use B, but a cannot both create and use B. With this separation, the creation and use are independently enabled. If the creation method changes, the user will not be affected. If the usage method changes, the creation process will not be affected.

For example, the following classes are available:

The task manager completes some tasks through the task debugger. The two tasks are independent and have their own lifecycles. If they are encoded as shown in, the task manager is responsible for the lifecycle maintenance of the task debugger, coupled with the specific task scheduler type, and does not fully utilize the object-oriented polymorphism.

If changed:

Void doSomething(TaskScheduler scheduler){    Scheduler.shcedule();}

On the one hand, the task manager does not need to add additional management responsibilities for the scheduler, on the other hand, it is also decoupled from the specific scheduler type, so that it does not care about the scheduler creation process, is a manifestation of the principle of separation of creation and use.

So where is the creation work? Of course, there are many ways to solve the problem of object creation, factory mode, static method, and the responsibilities of creation together, it can also facilitate condition creation or dynamically determine the creation type from external attributes.

However, I think this principle should not be used everywhere. After all, there are too many usages in a software, as shown in. If they are all created and used in this way, many factory or factory methods will be introduced, but the code structure will be more complicated. Basically, whether or not to adopt this method depends on the value that can be brought by this method. Designers need to perform some analysis and design work on the variability of creation. If creation is immutable, there is no need to go further. The principle is guidance, but when should we apply it, it depends on whether the application can bring greater value.

For the open and closed principles, relying on the inverted principle and the gof-oriented interface design, the use of combinations rather than inheritance, and so on, there are too many books that will not be repeated.

In short, principles and wisdom can bring us a lot of help and provide guidance on the whole, but in the end, we still need to look at practice and make trade-offs and balances in a specific environment.

-- Welcome to reprint, please indicate the source of http://blog.csdn.net/caowenbin --