More on this book
Community
Kindle Notes & Highlights
David Parnas’ classic paper “On the Criteria to be used in Decomposing Systems into Modules” appeared in 1971, but the state of the art in software design has not progressed much beyond that paper in the ensuing 45 years.
I have talked with several people I consider to be great programmers, but most of them had difficulty articulating specific techniques that give them their advantage.
However, there is quite a bit of scientific evidence that outstanding performance in many fields is related more to high-quality practice than innate ability (see, for example, Talent is Overrated by Geoff Colvin).
All programming requires is a creative mind and the ability to organize your thoughts.
This book is about how to use complexity to guide the design of software throughout its lifetime.
there isn’t a simple recipe that will guarantee great software designs. Instead, I will present a collection of higher-level concepts that border on the philosophical, such as “classes should be deep” or “define errors out of existence.” These concepts may not immediately identify the best design, but you can use them to compare design alternatives and guide your exploration of the design space.
“Exploration of design space” is most important aspect of software design.
The best way to use this book is in conjunction with code reviews.
Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.
Isolating complexity in a place where it will never be seen is almost as good as eliminating the complexity entirely. Complexity is more apparent to readers than writers. If you write a piece of code and it seems simple to you, but other people think
it is complex,
then it is c...
This highlight has been truncated due to consecutive passage length restrictions.
Your job as a developer is not just to create code that you can work with easily, but to create code that others can also work with easily.
Cognitive load: The second symptom of complexity is cognitive load, which refers to how much a developer needs to know in order to complete a task.
Sometimes an approach that requires more lines of code is actually simpler, because it reduces cognitive load.
Unknown unknowns: The third symptom of complexity is that it is not obvious which pieces of code must be modified to complete a task, or what
information a developer must have to carry out the task successfully.
Complexity is caused by two things: dependencies and obscurity.
If a system has a clean and obvious design, then it will need less documentation. The need for extensive documentation is often a red flag that the design isn’t quite right. The best way to reduce obscurity is by simplifying the system design.
The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado.
In some organizations, management treats tactical tornadoes as heroes. However, tactical
tornadoes leave behind a wake of ...
This highlight has been truncated due to consecutive passage length restrictions.
Tactical Tornado programmer is anti pattern for engineering. Finishing faster does not mean they have designed system well.
The first step towards becoming a good software designer is to realize that working code isn’t enough.
Your primary goal must be to produce a great design, which also happens to work. This is strategic programming.
Some of the investments will be proactive. For example, it’s worth taking a little extra time to find a simple design for each new class; rather than implementing the first idea that comes to mind, try a couple of alternative designs and pick the cleanest one. Try to imagine a few ways in which the system might need to be changed in the future and make sure that will be easy with your design. Writing good documentation is another example of a proactive investment.
complexity accumulates more rapidly under the tactical approach, which reduces productivity.
In order to manage dependencies, we think of each module in two parts: an interface and an implementation. The interface consists of everything that a developer working in a different module must know in order to use the given module.
A developer should not need to understand the implementations of modules other than the one he or she is working in.
Much of the discussion about modular design in this book focuses on designing classes, but the techniques and concepts apply to other kinds of modules as well.
The interface to a module contains two kinds of information: formal and informal.
In general, if a developer needs to know a particular piece of information in order to use a module, then that information is part of the module’s interface.
The informal aspects of an interface can only be described using comments, and the programming language cannot ensure that the description is complete or accurate1. For most interfaces the informal aspects are larger and more complex than the formal aspects.
An abstraction is a simplified view of an entity, which omits unimportant details.
An abstraction that omits important details is a false abstraction:
The mechanism for file I/O provided by the Unix operating system and its descendants, such as Linux, is a beautiful example of a deep interface. There are only five basic system calls for I/O, with simple signatures:
On the other hand, a shallow module is one whose interface is relatively complex in comparison to the functionality that it provides. For example, a class that implements linked lists is shallow.
Shallow classes are sometimes unavoidable, but they don’t provide help much in managing complexity.
Unfortunately, the value of deep classes is not widely appreciated today. The conventional wisdom in programming is that classes should be small, not deep. Students are often taught that the most important thing in class design is to break up larger classes into smaller ones. The same advice is often given about methods: “Any method longer than N lines should be divided into multiple methods” (N can be as low as 10). This approach results in large numbers of shallow classes and methods, which add to overall system complexity.
Classitis may result in classes that are individually simple, but it increases the complexity of the overall system. Small classes don’t contribute much functionality, so there have to be a lot of them, each with its own interface. These interfaces accumulate to create tremendous complexity at the system level.
This applies to Microservices or service oriented architectures as well.
Providing choice is good, but interfaces should be designed to make the common case as simple as possible
The basic idea is that each module should encapsulate a few pieces of knowledge, which represent design decisions.
Information leakage occurs when a design decision is reflected in multiple modules.
Suppose two classes both have knowledge of a particular file format (perhaps one class reads files in that format and the other class writes them).
Even if neither class exposes that information in its interface, they both depend on the file format: if the format changes, both classes will need to be modified. Back-door leakage like this is more pernicious than leakage through an interface, because it isn’t obvious.
When designing modules, focus on the knowledge that’s needed to perform each task, not the order in which tasks occur.
information hiding can often be improved by making a class slightly larger.
Buffering in file I/O is so universally desirable that noone should ever have to ask explicitly for it, or even be aware of its existence; the I/O classes should do the right thing and provide it automatically. The best features are the ones you get without even knowing they exist.
As a software designer, your goal should be to minimize the amount of information needed outside a module; for example, if a module can automatically adjust its configuration, that is better than exposing configuration parameters. But, it’s important to recognize which information is needed outside a module and make sure it is exposed.
The phrase “somewhat general-purpose” means that the module’s functionality should reflect your current needs, but its interface should not. Instead, the interface should be general enough to support multiple uses. The interface should be easy to use for today’s needs without being tied specifically to them.
The word “somewhat” is important: don’t get carried away and build something so general-purpose that it is difficult to use for your current needs.
One of the most important elements of software design is determining who needs to know what, and when.
