Consider what should be variable in the design. This method is the opposite of focusing on the causes of redesign. It does not consider what will force a design change, but consider what can be changed without causing a redesign. At this time, the main concern is to encapsulate the concept of change. At this time, many design patterns are themed.
How to find different changes in the problem field and how to find commonalities in different fields. Finding the location of change is called "common analysis", and finding out how to change is called "variable analysis ".
Common analysis is to find some common elements that can help us understand where the series members are. Variable analysis reveals the differences between series members. variability is meaningful only after a common set is given.
Common analysis is looking for structures that cannot change over time, while variable analysis is looking for structures that may change. Variability Analysis is meaningful only in the context defined by the associated common analysis. From the perspective of the architecture, the common analysis provides a long-term element for the architecture, while the variable analysis facilitates him to adapt to practical needs. That is to say, if changes are specific situations in the problem field, the commonalities define the concept of linking these situations in the problem field. Common concepts are displayed in abstract classes. The changes discovered by the variability analysis are implemented through a specific class (that is, a class with a specific implementation derived from an abstract class.
Common and Variability Analysis, relationships between three perspectives and abstract classes
The conceptual perspectives of the common split and problem fields are correlated, and the variability analysis is correlated with the implementation of specific situations.
The perspective of the Protocol is in the middle, and the points of commonality and change are related to the perspective. The Conventions describe how to communicate with a group of similar conceptual objects. Each of these objects shows a change in a common concept. It is called an abstract class or interface at the implementation level.
In the new perspective of object-oriented design, we can say this:
Ing with abstract classes |
Discussion |
Abstract class> core concepts |
Abstract classes represent the core concepts associated with all derived classes. This core concept defines the commonalities of derived classes. |
Commonalities-> abstract classes |
Commonalities define the abstract classes we need to use. |
Change Point-> the derived class of the abstract class |
The variation points recognized from the commonalities become the derived class of the abstract class. |
Conventions> abstract class interfaces |
The interfaces of these classes correspond to the protocol level. |
Simplify the design process of the class into a program with two steps:
When you define ...... |
You must ask yourself ...... |
Abstract class (commonalities) |
What interfaces should be used to handle all responsibilities of this class? |
Derived class (variability) |
How should we implement this specific implementation (this change) based on the given protocol. |
Association between the Protocol perspective and the conceptual perspective: the Protocol identifies the interface required to handle all the situations of the concept (that is, the commonality defined by the conceptual perspective.
Association between the Protocol perspective and the implementation perspective: how to implement this specific situation (Change Point) for a given statute ).