More on this book
Community
Kindle Notes & Highlights
by
Metz Sandi
Started reading
August 11, 2022
Failures of OOD might look like failures of coding technique, but they are actually failures of perspective. The first requirement for learning how to do object-oriented design is to immerse yourself in objects; once you acquire an object-oriented perspective, the rest follows naturally.
Oop failure
Object-oriented design is about managing dependencies. It is a set of coding techniques that arrange dependencies such that objects can tolerate change. In the absence of design, unmanaged dependencies wreak havoc because objects know too much about one another.
Dependencie
Object-oriented design is about managing dependencies. It is a set of coding techniques that arrange dependencies such that objects can tolerate change. In the absence of design, unmanaged dependencies wreak havoc because objects know too much about one another.
A
Programmers are not psychics. Designs that anticipate specific future requirements almost always end badly. Practical design does not anticipate what will happen to your application; it merely accepts that something will and that, in the present, you cannot know what. It doesn’t guess the future; it preserves your options for accommodating the future. It doesn’t choose; it leaves you room to move. The purpose of design is to allow you to do design later, and its primary goal is to reduce the cost of change.
Ne prgrsmuuemy do przodu
Pattern misapplication results in complicated and confusing code, but this result is not the fault of the pattern itself. A tool cannot be faulted for its use; the user must master the tool.
Dont blame patterns
However, just because Agile says “don’t do a big up front design” doesn’t mean it tells you to do no design at all. The word design when used in BUFD has a different meaning than when used in OOD.
!
in all procedural languages, there is a chasm between data and behavior. Data is one thing, behavior is something completely different. Data gets packaged up into variables and then passed around to behavior, which could, frankly, do anything to it. Data is like a child that behavior sends off to school every morning; there is no way of knowing what actually happens while it is out of sight. The influences on data can be unpredictable and largely untraceable.
!
When the future cost of doing nothing is the same as the current cost, postpone the decision. Make the decision only when you must with the information you have at that time. Even though there’s a good argument for leaving Gear as is for the time being, you could also make a defensible argument that it should be changed. The structure of every class is a message to future maintainers of the application. It reveals your design intentions. For better or for worse, the patterns you establish today will be replicated forever. Gear lies about your intentions. It is neither usable nor exemplary. It
...more
When to improve
When the future cost of doing nothing is the same as the current cost, postpone the decision. Make the decision only when you must with the information you have at that time. Even though there’s a good argument for leaving Gear as is for the time being, you could also make a defensible argument that it should be changed. The structure of every class is a message to future maintainers of the application. It reveals your design intentions. For better or for worse, the patterns you establish today will be replicated forever. Gear lies about your intentions. It is neither usable nor exemplary. It
...more
Aaa
array of Wheels to begin with, it is not always possible. If you can control the input, pass in a useful object, but if you are compelled to take a messy structure, hide the mess even from yourself.
Hide mess
Good practices reveal design.
.
Because you are writing changeable code, you are best served by postponing decisions until you are absolutely forced to make them. Any decision you make in advance of an explicit requirement is just a guess. Don’t decide; preserve your ability to make a decision later.
Make decisions later
An object has a dependency when it knows: The name of another class. Gear expects a class named Wheel to exist. The name of a message that it intends to send to someone other than self. Gear expects a Wheel instance to respond to diameter. The arguments that a message requires. Gear knows that Wheel.new requires a rim and a tire. The order of those arguments. Gear knows that Wheel takes positional arguments and that the first should be rim, the second, tire.
Kiedy kasy sa zalezne
Your design challenge is to manage dependencies so that each class has the fewest possible; a class should know just enough to do its job and not one thing more. 3.1.2 Coupling Between Objects (CBO) These dependencies couple Gear to Wheel.
!
When two (or three or more) objects are so tightly coupled that they behave as a unit, it’s impossible to reuse just one. Changes to one object force changes to all. Left unchecked, unmanaged dependencies cause an entire application to become an entangled mess. A day will come when it’s easier to rewrite everything than to change anything.
!
One especially destructive kind of dependency occurs where an object knows another who knows another who knows something; that is, where many messages are chained together to reach behavior that lives in a distant object. This is the “knowing the name of a message you plan to send to someone other than self ” dependency, only magnified. Message chaining creates a dependency between the original object and every object and message along the way to its ultimate target. These additional couplings greatly increase the chance that the first object will be forced to change because a change to any of
...more
RSv2
Every dependency is like a little dot of glue that causes your class to stick to the things it touches. A few dots are necessary, but apply too much glue, and your application will harden into a solid block. Reducing dependencies means recognizing and removing the ones you don’t need.
Glued
This change is so small it is almost invisible, but coding in this style has huge benefits.
Di
depend on things that change less often than you do. This short statement belies the sophistication of the idea, which is based on three simple truths about code: Some classes are more likely than others to have changes in requirements. Concrete classes are more likely to change than abstract classes. Changing a class that has many dependents will result in widespread consequences.
A
There is design detail that must be captured at this level, but an object-oriented application is more than just classes. It is made up of classes but defined by messages. Classes control what’s in your source code repository; messages reflect the living, animated application. Design, therefore, must be concerned with the messages that pass between objects. It deals not only with what objects know (their responsibilities) and who they know (their dependencies) but also with how they talk to one another. The conversation between objects takes place using their interfaces; this chapter
...more
Oop vs classes
In the first application, the messages have no apparent pattern. Every object may send any message to any other object. If the messages left visible trails, these trails would eventually draw a woven mat, with each object connected to every other. Figure 4.1 Communication patterns In the second application, the messages have a clearly defined pattern. Here the objects communicate in specific and well-defined ways. If these messages left trails, the trails would accumulate to create a set of islands with occasional bridges between them.
Oop diagram
Are thoroughly documented in the tests.
Good docs
