Home >Java >javaTutorial >Detailed graphic explanation of the principles of composition, aggregation and reuse in Java
This article mainly introduces the principles of synthesis, aggregation and reuse. The editor thinks it is quite good. I will share it with you now and give it as a reference. Let’s follow the editor and take a look.
Principle of synthesis, aggregation and reuse
The principle of synthesis and reuse is also called the principle of combination/aggregation and reuse (Composition/ Aggregate Reuse Principle (CARP), which is defined as follows:
Composite Reuse Principle (CRP): Try to use object combination instead of inheritance to achieve the purpose of reuse.
The principle of synthesis and reuse is to use some existing objects in a new object through association relationships (including combination relationships and aggregation relationships) to make them part of the new object; The new object achieves the purpose of reusing functions by calling methods of existing objects through delegation. In short: When reusing, try to use combination/aggregation relationships (association relationships) and use less inheritance.
In object-oriented design, there are two ways to reuse existing designs and implementations in different environments, namely through composition/aggregation relationships or through inheritance, but you should first consider using composition /Aggregation, combination/aggregation can make the system more flexible, reduce the coupling between classes, and changes in one class will have relatively little impact on other classes; secondly, consider inheritance. When using inheritance, you need to strictly follow the rules According to the principle of substitution, effective use of inheritance will help understand the problem and reduce complexity, while abuse of inheritance will increase the difficulty of system construction and maintenance and the complexity of the system. Therefore, inheritance reuse needs to be used with caution.
The main problem with reuse through inheritance is that inheritance reuse will destroy the encapsulation of the system, because inheritance will expose the implementation details of the base class to the subclass, because the internal details of the base class are usually not visible to the subclass. is visible, so this kind of reuse is also called "white box" reuse. If the base class changes, then the implementation of the subclass will also have to change; the implementation inherited from the base class is static and does not It may change at runtime and is not flexible enough; and inheritance can only be used in limited circumstances (for example, a class is not declared as not inheritable).
Extension
For an in-depth understanding of inheritance, you can refer to the article by Mr. Wen Yu, the author of "Software Architecture Design" - " Seeing the mountains is just mountains and seeing water is just water - Improving the understanding of inheritance".
Since the combination or aggregation relationship can incorporate existing objects (also called member objects) into new objects and make them part of the new object, the new object can call the functions of the existing objects. Doing so can make the internal implementation details of the member object invisible to the new object, so this kind of reuse is also called "black box" reuse. Compared with the inheritance relationship, its coupling degree is relatively low, and changes in the member object have no impact on the new object. The impact is not big, and the operations of member objects can be selectively called in new objects according to actual needs; synthetic reuse can be performed dynamically at runtime, and new objects can dynamically reference other objects of the same type as member objects.
Generally speaking, if the relationship between two classes is "Has-A", combination or aggregation should be used, and if there is an "Is-A" relationship, inheritance can be used. "Is-A" is a strict taxonomic definition, meaning that one class is "a kind" of another class; "Has-A" is different, it means that a certain role has a certain responsibility.
The following is a simple example to deepen our understanding of the principle of synthesis and reuse:
In the initial design of the CRM system, the developers of Sunny Software Company took into account the small number of customers. The system uses MySQL as the database. Classes related to database operations such as the CustomerDAO class need to connect to the database. The method getConnection() for connecting to the database is encapsulated in the DBUtil class. Since the getConnection() method of the DBUtil class needs to be reused, the designer uses CustomerDAO as A subclass of the DBUtil class, the initial design plan structure is shown in Figure 1:
Figure 1 Initial design plan structure chart
As customers As the number increases, the system decides to upgrade to the Oracle database, so a new OracleDBUtil class needs to be added to connect to the Oracle database. Since there is an inheritance relationship between CustomerDAO and DBUtil in the initial design plan, the CustomerDAO class needs to be modified when changing the database connection method. The source code uses CustomerDAO as a subclass of OracleDBUtil, which will violate the open-close principle. [Of course, you can also modify the source code of the DBUtil class, which will also violate the opening and closing principle. 】
Now use the principle of synthesis and reuse to reconstruct it.
According to the principle of synthetic reuse, we should use more associations and less inheritance when implementing reuse. Therefore, in this example we can use association reuse to replace inheritance reuse. The reconstructed structure is shown in Figure 2:
Figure 2 Reconstructed structure picture
In Figure 2, the relationship between CustomerDAO and DBUtil changes from inheritance to association. Dependency injection is used to inject the DBUtil object into CustomerDAO. You can use constructor injection or Setter injection. If you need to extend the functions of DBUtil, you can do so through its subclasses, such as connecting to the Oracle database through the subclass OracleDBUtil. Since CustomerDAO is programmed for DBUtil, according to the Liskov substitution principle, the object of the DBUtil subclass can overwrite the DBUtil object. You only need to inject the subclass object into CustomerDAO to use the methods extended by the subclass. For example, by injecting the OracleDBUtil object into CustomerDAO, the Oracle database connection can be realized. The original code does not need to be modified, and new database connection methods can be added flexibly.
The above is the detailed content of Detailed graphic explanation of the principles of composition, aggregation and reuse in Java. For more information, please follow other related articles on the PHP Chinese website!