More on this book
Community
Kindle Notes & Highlights
They try to find ways to add functionality to implementations without making ch...
This highlight has been truncated due to consecutive passage length restrictions.
Don’t refer to volatile concrete classes.
Don’t derive from volatile concrete classes.
Don’t override concrete functions. Concrete functions often require source code dependencies. When
Never mention the name of anything concrete and volatile. This is really just a restatement of the principle itself.
To comply with these rules, the creation of volatile concrete objects requires special handling. This caution is warranted because, in virtually all languages, the creation of an object requires a source code dependency on the concrete definition of that object.
In most object-oriented languages, such as Java, we would use an Abstract Factory to manage this undesirable dependency.
The curved line divides the system into two components: one abstract and the other concrete.
The abstract component contains all the high-level business rules of the application.
The concrete component contains all the implementation details that those bus...
This highlight has been truncated due to consecutive passage length restrictions.
The way the dependencies cross that curved line in one direction, and toward more abstract entities, will become a new rule that we will call the Dependency Rule.
If the SOLID principles tell us how to arrange the bricks into walls and rooms, then the component principles tell us how to arrange the rooms into buildings.
Components are the units of deployment.
They are the smallest entities that can be deployed as part of a system. In Java, they are jar files. In Ruby, they are gem files. In .Net, they are DLLs.
These dynamically linked files, which can be plugged together at runtime, are the software components of our architectures.
this chapter we will discuss the three principles of component cohesion:
REP: The Reuse/Release Equivalence Principle
CCP: The Common Closure Principle
CRP: The Common Reuse Principle
THE REUSE/RELEASE EQUIVALENCE PRINCIPLE The granule of reuse is the granule of release.
We are now living in the age of software reuse—a fulfillment of one of the oldest promises of the object-oriented model.
People who want to reuse software components cannot, and will not, do so unless those components are tracked through a release process and are given release numbers.
Classes and modules that are grouped together into a component should be releasable together. The fact that they share the same version number and the same release tracking, and are included under the same release documentation, should make sense both to the author and to the users.
Gather into components those classes that change for the same reasons and at the same times. Separate into different components those classes that change at different times and for different reasons.
This is the Single Responsibility Principle restated for components.
the Common Closure Principle (CCP) says that a component should not have mult...
This highlight has been truncated due to consecutive passage length restrictions.
For most applications, maintainability is more important...
This highlight has been truncated due to consecutive passage length restrictions.
If the code in an application must change, you would rather that all of the changes occur in one component, rather than being...
This highlight has been truncated due to consecutive passage length restrictions.
two classes are so tightly bound, either physically or conceptually, that they always change together, then they belong in the same component.
This minimizes the workload related to releasing, revalidating, and redeploying the software.
The OCP states that classes should be closed for modification but open for extension. Because 100% closure is not attainable, closure must be strategic.
We design our classes such that they are closed to the most common kinds of changes that we expect or have experienced.
Gather together those things that change at the same times and for the same reasons. Separate those things that change at different times or for different reasons.
THE COMMON REUSE PRINCIPLE Don’t force users of a component to depend on things they don’t need.
You may have already realized that the three cohesion principles tend to fight each other.
The REP and CCP are inclusive principles: Both tend to make components larger.
The CRP is an exclusive principle, driving components to be smaller. It is the tension between these principles that...
This highlight has been truncated due to consecutive passage length restrictions.
An architect who focuses on just the REP and CRP will find that too many components are impacted when simple changes are made.
In contrast, an architect who focuses too strongly on the CCP and REP will cause too many unneeded releases to be generated.
Generally, projects tend to start on the right hand side of the triangle, where the only sacrifice is reuse.
We once thought that cohesion was simply the attribute that a module performs one, and only one, function.
In choosing the classes to group together into components, we must consider the opposing forces involved in reusability and develop-ability.
the partitioning that is appropriate today might not be appropriate next year. As a consequence, the composition of the components will likely jitter and evolve with time as the focus of the project changes from develop-ability to reusability.
The forces that impinge upon the architecture of a component structure are technical, political, and volatile.
Allow no cycles in the component dependency graph.
In addition, build issues grow geometrically with the number of modules.
is always possible to break a cycle of components and reinstate the dependency graph as a DAG. There are two primary mechanisms for doing so:
Apply the Dependency Inversion Principle (DIP). In the case in Figure 14.3, we could create an interface that has the methods that User needs. We could then put that interface into Entities and inherit it into Authorizer. This inverts the dependency between Entities and Authorizer, thereby breaking the cycle.
Moreover, we want to keep changes as localized as possible, so we start paying attention to the SRP and CCP and collocate classes that are likely to change together.
As the application continues to grow, we start to become concerned about creating reusable elements. At this point, the CRP begins to influence the composition of the components.
