Hello everyone, I am han Cao 😈, a grass code ape 🐒 who has been working for more than a year. If you like my article, you can follow ➕ to like it and grow up with me. Add my wechat: Hancao97, invite you to join the group, learn and communicate together, and become a better engineer

“This is the 14th day of my participation in the First Challenge 2022. For details: First Challenge 2022.”

background

This is the twelfth in my Architectural Cleanliness series, where we will learn about component aggregation

Clean Architecture Series:

• Hancao’s column on the Way to Neat architecture

Component aggregation

Three basic principles related to building components:

• REP: Reuse/release equivalence principle
• CCP: Common closure principle
• CRP: Principle of common reuse

Reuse/release equivalence principle

The minimum granularity of software reuse should be equal to the minimum granularity of its distribution

Module management tools such as Maven, Leiningen, RVM, etc. The growing importance of these tools is due to the proliferation of reusable components and component libraries.

If you want to reuse a software component, you generally have to require that the development of that component be driven by some kind of release process and have a clear release number. Without a version number, there is no way to ensure that all reused components are compatible with each other. More importantly, software developers must be able to know when these components were released and what changes were made with each release. Only then can the software engineer, after receiving notification of a new release of a component, decide whether to continue with the old version or make upgrades based on the changes made in that release.

Therefore, the component’s release process must also be able to generate appropriate notifications and release documentation so that its users can make effective upgrade decisions based on this information.

From a software design and architectural design perspective, the REP principle means that the classes and modules in a component must be closely related to each other. That is, a component should not consist of a set of unrelated classes and modules, but should have a common theme or general direction between them.

From another perspective, classes and modules contained in a component should also be publishable at the same time. This means that they share the same version number and version trace, and are included in the same release document, which should make sense to both the author and the user of the component.

The common closure principle

We should put the classes that will be modified at the same time and for the same purpose in the same component, and the classes that will not be modified at the same time and will not be modified for the same purpose in different components.

That is: if two classes are closely related, both at the source level and the abstract level, and will always be modified together, then they should belong to the same component. By following this principle, we can effectively reduce the stress associated with software release, validation, and deployment.

We can take this one step further: we can try to aggregate all the classes involved in a particular type of change into one place. This way, when such changes occur, we can maximize their impact on a limited number of related components.

Group together things that need to be changed for the same reason and at the same time. Separate things that are being modified for different reasons and not at the same time.

Principle of common reuse

Don’t force users of a component to rely on something they don’t need.

This principle suggests that we put classes and modules that are often reused together in the same component. Therefore, when we decide to rely on a component, it is best to actually rely on every class in that component. In other words, we want all classes in a component to be unbreakable, that is, no one should rely on some of its classes and not others.

More important in the principle of co-reuse are suggestions about which classes should not be put together. In short, the principle of co-reuse actually teaches us that classes that are not closely related should not be placed in the same component.

To put it simply: Don’t rely on things you don’t need

Component aggregation tension diagram

These three principles are in competition with each other. REP and CCP principles are adherence principles, which make components larger, while CRP principles are exclusion principles, which make components as small as possible.

The task of the software architect is to choose between these three principles.

The following diagram is a tension diagram of the three principles of component aggregation, with the edges describing the consequences of ignoring the corresponding principles.

Software architects who focus only on REP and CRP will find that even simple changes can affect many components at once. Conversely, if software architects focus too much on CCP and REP, it can lead to a lot of unnecessary releases.

A good software architect should be able to locate a position in the triangle tension that best fits the current state of the development team, and adjust to the timing.

Typically, the focus of a software project will start on the right side of the triangle, at the initial cost of reusability. Then, as the project matures and other projects become dependent on it, the project’s center of gravity slides to the left of the triangle.

conclusion

When deciding which classes to classify as a component, it is not easy to consider the contradiction between r&d and reusability, and to balance the two according to the needs of the application. And the balance itself is changing. In other words, what works today may not work next year.

Therefore, the composition of components should evolve depending on the focus of the project, and depending on r&d versus reusability.

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

Youth never knows heaven and earth

Conceit and talent are everywhere you look

Pretentious as it is

I was honest

I love such a boy

Humble and arrogant

Proud and calm ☀️

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

Your likes and attention are my constant motivation, you can add my wechat: HancAO97, invite you to join the group, learn and communicate together, become a better front-end engineer ~