More on this book
Community
Kindle Notes & Highlights
Whenever anyone wants to know the balance of an account, we simply add up all the transactions for that account, from the beginning of time. This scheme requires no mutable variables.
Event sourcing is a strategy wherein we store the transactions, but not the state. When state is required, we simply apply all the transactions from the beginning of time.
If we have enough storage and enough processor power, we can make our applications entirely immutable—and, therefore, entirely functional.
Structured programming is discipline imposed upon direct transfer of control.
Object-oriented programming is discipline imposed upon indirect transfer of control.
Functional programming is discipline imposed upon variable assignment.
What we have learned over the last half-century is what not to do.
The rules of software are the same today as they were in 1946, when Alan Turing wrote the very first code that would execute in an electronic computer.
The tools have changed, and the hardware has changed, but the essence of software remains the same.
Good software systems begin with clean code.
On the one hand, if the bricks aren’t well made, the architecture of the building doesn’t matter much.
On the other hand, you can make a substantial mess with...
This highlight has been truncated due to consecutive passage length restrictions.
The SOLID principles tell us how to arrange our functions and data structures into classes, and how those classes should be interconnected.
A class is simply a coupled grouping of functions and data.
A module should have one, and only one, reason to change.
A module should be responsible to one, and only one, user or stakeholder.
A module should be responsible to one, and only one, actor.
Cohesion is the force that binds together the code responsible to a single actor.
Perhaps the best way to understand this principle is by looking at the symptoms of violating it.
The SRP says to separate the code that different actors depend on.
If component A should be protected from changes in component B, then component B should depend on component A.
The Dependency Inversion Principle (DIP) tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.
Source code dependencies should not refer to concrete modules.
It is the volatile concrete elements of our system that we want to avoid depending on.
Every change to an abstract interface corresponds to a change to its concrete implementations.
Conversely, changes to concrete implementations do not always, or even usually, require changes to the interfaces that they implement.
Therefore interfaces are less volatile than i...
This highlight has been truncated due to consecutive passage length restrictions.
Components are the units of deployment. They are the smallest entities that can be deployed as part of a system.
The granule of reuse is the granule of release.
Classes and modules that are grouped together into a component should be releasable together.
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.
Just as the SRP says that a class should not contain multiples reasons to change, so the Common Closure Principle (CCP) says that a component should not have multiple reasons to change.
If changes are confined to a single component, then we need to redeploy only the one changed component.
The SRP tells us to separate methods into different classes, if they change for different reasons.
The CCP tells us to separate classes into different components, if they change for different reasons.
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.
Don’t force users of a component to depend on things they don’t need.
Don’t depend on things you don’t need.
Allow no cycles in the component dependency graph.
It is always possible to break a cycle of components and reinstate the dependency graph as a DAG.
When cycles occur, they must be broken somehow.
Depend in the direction of stability.
Any component that we expect to be volatile should not be depended on by a component that is difficult to change.
Stability is related to the amount of work required to make a change.
One sure way to make a software component difficult to change, is to make lots of other software components depend on it.
If all the components in a system were maximally stable, the system would be unchangeable.
A component should be as abstract as it is stable.
Thus, if a component is to be stable, it should consist of interfaces and abstract classes so that it can be extended.
The SAP and the SDP combined amount to the DIP for components.
Either a class is abstract or it is not.
