The ancient object-oriented principle teaches us, to package status and behavior together, and a class should not modify the status of another class. The concept of control classes seems to violate this principle, although the control class does not directly modify the data in another class, but the code in the control class is indeed part of the behavior, and indirectly modify the status in other classes. This can be concluded that the design of the control class is a bad design, or the control class will seriously damage the structure of the software, regard this destruction as a cost, the control class is very high, only The control class should be used if a few cases do not use the control class cost?
But the actual situation is that there will be a large number of control classes in most good designs, and the use of controls should be very common, not special cases, and the concept of deliberately rejection control can only lead to poor design. The introduction cost of the control class is not as big as the imagination, and the benefits of analyzing the control class can make people have a more deep understanding of the object-oriented nature.
If we look at the GOF design mode, it is more suitable to build a large structure (or a software architecture) mode. Only Command, Facade and Mediator, only these models can be perfectly divided into the largest in most cases. Several top modules. The three modes are observed by the concept of the concept of control, and it is easy to discover the main contents of these three modes. How do you load the control logic of the control smaller object to load a special class, which is a Command class, Facade Class and Mediator classes, in addition to controlling other objects, there is no responsibility to do other responsibilities, are all very simple control classes. That is, in most cases, the control logic must be specifically extracted into the control class in the architectural design of the software. It is the best choice. ------------------------------------------ COMMAND, FACADE and Mediator mode how are the MEDITOR? Use control class mode ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
According to GOF, the main purpose of these three modes is to weaken the coupling between modules, in fact these modes can be decoupled, precisely because they use the concept of control class. No matter whether there is other benefits in the control class, an important role of the control class is to eliminate the coupling between the modules, more importantly, only the control class can successfully eliminate the coupling between the modules, while also allowing each module between modules. Collaborative relationship is clearly visible. Other modes of other non-encapsulated control logic, such as Observer mode, and duties, although the coupling between modules can be weakened, but the interaction between the modules will become confused.
---------------------------------------- closely coupled to the root causes, we will take the whole Software is divided into multiple modules. ---------------------------------------- Of course, no one will design the entire software as A class, an object, which is degraded to the oriented design. We want to divide the data or status of the entire system into a very much portion (an object per part), it can be easier to manipulate. However, the multiple objects cannot be kept independent, because the behavior required in the demand is a change in the overall changes in the state of the software management, rather than changes to the status of a single object, that is, each function in the demand It will be required to change the state of multiple objects at the same time, not only to change the status of an object. In this way, certain objects need to call other objects, which is the control logic, and the control logic is inevitable because there are multiple objects in the system to change their status while changing them.
If all the functions in the design are managed their own state, the result is inevitably called each other, and cannot be divided into hierarchical, forming a close coupling. It is easy to find that in such a design, it is impossible to have any classes can be reused in other programs, and it is impossible to have any internal modifications, which can be independent of other classes. To unlock the tight coupling of the modularity, you must separate the control logic and status management logic to encapsulate in different classes, so at least we will get some classes that do not rely on software, these classes are completely passive. You can get another program reuse without any problems. If you have bugs in these isolated classes, we will also be confident that modifications to these bugs will never affect other parts. The isolated class is unable to work. To make the passive class, the dependency of the control class, the control class, and passive class must be unidirectional, only the control class is dependent on the passive class, the passive class does not rely on the control class, nor Other passive classes.
Control logic is the logic that guarantees to change multiple objects that can be coordinated, and they guarantee that multiple objects can change their status while changing their status, and control logic is active logic. It is the only factor that leads to dependence between objects. Logic in the perspective of loosely, the control logic is a bad thing that must be in the design. The status management logic is to change the state inside a certain package boundary, maintain the correctness of the state within the boundary, and simple state management logic, it can be completely implemented in the package boundary.
The reason why the control class can relieve the coupling because he puts all the necessary active depends in the system, and all extracts to focus on its own internal, so that other classes no longer dependence, and make it correct and encapsulation borders. -------------------------------------------- Control class extraction and encapsulate All dependencies in the system are garbage collectors in the design ------------------------------------- -------
In this way, the consequences of controlling logic packaging are also very obvious. If the control class in a system is unable to package all dependencies, these remaining dependencies inevitably leaked into other management status classes, causing them to couple each other, and they originally It can be completely unsatisfactory.
Why can't you make a class of the management status to undertake control logic to coordinate different object behavior? ----------------------------------------- Because this will reduce the internal gathering of the object Degree, enhanced coupling ----------------------------------------------------------------------------------------------------
Therefore, all the logic of a state cannot be modified to a class saved in the class, but the logic of the modified state is divided into control logic and status management logic, and packaged in different classes, respectively. There is still a question left. Otherwise, how to distinguish control logic and status management logic, both of which are directly or indirectly modified, this problem is the boundary of passive class, if all classes are divided into passive classes and control classes It is necessary to allocate responsibilities in the control class and passive class, and some responsibilities can be assigned to the control class, or it can be assigned to the passive class, as long as the active logic is assigned to the passive class, it will not result in a close coupling. Therefore, you can get the following passive class responsibilities to maximize principles: ------------------------------------- ---------- If a certain responsibility, if the passive class, the passive class will not cause the passive class to call the same level, and allocate this logic to the passive class ----------- -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The passive class can be a top layer module in the architecture or a physical class. The entity class is the bottom layer, which is relatively easy to identify. If the passive class is the top or this module, the passive class is divided, there is a problem of hierarchical division, because these modules appear to be passive classes in the previous level, but in the next level, it seems to be a control class. In fact, a hierarchical package for control logic. In this way, pure state management logic, all in the entity class, what is done outside the entity class, is often referred to as "business logic", it is easy to find: ------------ -------------------------------- Business logic is all control logic, they should be encapsulated to all levels of control Class in --------------------------------------------- Further, We can get "business logic" more fundamental properties: ----------------------------------- -------- Business logic is the logic that cannot be reused in another program --------------------------- --------------- Perhaps the above statement is too absolute, but the generality of the concept of business logic is far less than the universality of the corresponding concept of the entity, the physical class is reusable The range is much larger than the reusable range of the control class. Therefore, we can also use the reusable range to divide the level of the control class. A reusable range of a hierarchical control class is equal to the reusable range of classes whose reuse ranges in this level. -------------------------------------------- One level in each module The reusable range should be quite, and the reusable range of different levels should have a big gap ------------------------------------------------------------------------------------------------------ ---------------- Thus, the larger the range, the less content, the less content, the purpose of the division level is to reuse more content in a greater range.
