Concept of Component Design Principles (1)

At Robert C. Martin (Uncle Bob)Agile Software Development: Principles, patterns, and practices)In his book, he proposed some principles for designing components (or packages. The traditional object-oriented design principles, such as solid, carp, and levels of detail, are mainly used to design components and package structures, there are six principles in total: the first three focus on ComponentsCohesion)To instruct us how to group class packages.Coupling)To help us determine the relationship between components. Simply put, the design of components (or packages) must also be"High Cohesion and low coupling". Sunny believes that some principles describe an ideal situation. In actual use, we try our bestTendsThese principles are usually hard to fully satisfy ,.

 

Principle of component cohesion: granularity (Principles of component cohesion: granularity)

The component cohesion principle helps developers decideHow to divide classes into components. These principles depend on the fact that:At least some classes already exist and the relationships between them are also determined.. Therefore, these principles divide classes based on bottom-up perspectives, analyze classes and relationships, and then gradually organize classes.

 

Reuse-publish Equivalence Principle (the reuse/release equivalence principle, Rep)
The granule of reuse is the granule of release.

The granularity of reuse is the publishing granularity.

In actual development, our reuse granularity is generally not class-level, but component-level. The component mentioned here can be jar in Java, DLL or shared library. Rep requires that we keep the granule of reuse of components consistent with the granule of release of components. I think everyone should understand what is reuse and publishing ,. Since reuse is at the component level, reusable components must contain reusable classes that are published to users as components. Rep requires us to repeat the content of a component from the perspective of reuse. classes in a component can either be reused or not reusable (either all the classes in a component are reusable, or none of them are .). For example, in a Model 2-based Java EE Project, we package all DaO classes into a jar to reuse all DaO classes in other projects based on the same database, this Dao component should not contain any control layer (servlet) or presentation layer (JSP, etc.) related classes, because these classes cannot be reused at the same time.

In addition, when implementing rep, similar to the SRP In the object-oriented design principle (single responsibility principle), a component should not contain too many classes of different types, do not place some completely unrelated classes in one component. This will lead to excessive component responsibilities and increase the frequency of modification and release. Therefore, we should make all the classes in a Component Reusable for users of the same class or for the same scenario. Some classes in the component should not be useful to users, but other classes should not apply.

In short, rep requires us to design components from the perspective of reuse,Enables all classes in a component to be reused together. There is no class that cannot be reused, and there is no class that can be reused only in another scenario. The granularity of reuse is the granularity of the published component.

 

The common Reuse Principle, CRP)
The classes in a component are reused together. If you reuse one of the classes in a component, you reuse them all.

Classes in a component must be reused together. If you reuse a class in the component, You need to reuse all the classes.

CRP and the previous rep usually appear together. classes in the same component are reused as a whole, rather than only one or several of them. I personally think that CRP is an ideal situation. It helps reduce the Coupling Degree between components, but it is difficult to implement it. For components with a slightly more class, it is difficult to reuse all the classes at the same time. In most cases, only the partial classification is used ,. What we need to do is,Try to place these classes in the same component, reduce the number of components that interact with the client program, and reduce the Coupling Degree of the system.

CRP tells us which classes need to be placed in the same component. In a slightly more complex system, classes are rarely reused in isolation. For example, if you need to reuse a specific class and its abstraction layer, You need to reuse an aggregation class and its iterator. You need to reuse the factory class and product class together. At this time, it is better to design them in the same component. If they are separated and placed in two different components, dependencies are bound to be added between some components. When the components of the dependent party are modified and re-released, the dependent components also need to be re-verified and released, resulting in increased maintenance and upgrade workload.

In addition, if there are too many classes in a component, as long as one of the classes in the component changes and is re-released, all customer classes dependent on the component should be tested and verified to see if a bug is introduced, even if the modified class has nothing to do with most of the customer classes, the testing workload will also increase, requiring a large number of unnecessary re-verification and re-release, which is time-consuming and labor-consuming.

CRP tells us moreClasses that are not closely linked should not be placed in one component. A component should only contain classes that need to be reused together.

 

The common closure principle (CCP) Principle)
The classes in a component shoshould be closed together against the same kinds of changes. A change that affects a component affects all the classes in that component and no other components.

All classes in a component should be closed for changes of the same type. If a change affects a component, all classes of the component are affected, but other components are not affected.

This principle is actually the single responsibility principle (SRP) of components, that isA component should not contain multiple reasons for its change. In most applications, maintainability is more important than reusability. If the code in an application needs to be modified, try to make such modifications in one component instead of in multiple components, such as replacing the database, you only need to modify or replace the components related to database operations. To replace the view layer interface, you only need to modify or replace the new interface components. If all the changes are concentrated in a single component, we only need to re-release that component, which is usually not very large and easy to maintain and reuse. If these changes are distributed across multiple components, the workload for software release, verification, and maintenance is increased.

Implementing the CCP requires us to identify closely related classes and try to encapsulate these classes into the same component to avoid modifying multiple components later.

CCP asks usChange a type(For example, replacing a database)Sensitive classes are organized into the same component. When a requirement changes, the changes can be limited to a minimum number of components..

 

 Summary

When considering how to organize classes into components, we need to fully consider the reusability and maintainability of components,Put the reusable classes together into one component as much as possible, and put the affected classes in one component as much as possible.. We should also note that with the development of the project, the composition of components may evolve over time and some adjustments need to be made accordingly. During the initial design, we need to minimize the workload of component modification!

 

[Author: Liu Wei http://blog.csdn.net/lovelion]