Chapter 5, Bend, or Break, is about writing flexible code, or code that can be changed easily in order to keep up with changing demands, or even just for the purposes of maintainability.
"Organize your code into cells (modules) and limit the interaction between them. If one module then gets compromised and has to be replaced, the other modules should be able to carry on."
- The Pragmatic Programmer, p138
"Minimize coupling" seems to be the same thing as "pass everything you need into a method as an argument," and "don't traverse object relationships." The Law of Demeter gets into more detail:
The Law of Demeter for functions states that any method of an object should call only methods belonging to itself, any parameters that were passed in to the method, any objects it created, or any directly held component object.
- The Pragmatic Programmer, p141
The example I use for minimizing coupling is that of turn signals and steering wheels. It's a good thing that turn signals are decoupled from actually turning the steering wheel. It would defeat the purpose of the signal, which allows other drivers to clear the way, signals intent, and is also reversible. How shitty would it be if your car turned as soon as you flipped the signal?
The Law of Demeter ensures that your code is decoupled. The exercises at the end of the section were helpful in developing an intuition about what did and did not violate the Law of Demeter (hardly a law in the physical sciences sense, I guess), though the authors do stress the fact that adherence to the Law of Demeter is situational. Strictly obeying the Law of Demeter can be as shortsighted as ignoring it.
Now, my understanding of metaprogramming may be colored from my experience with Ruby, in which metaprogramming is basically code that configures and executes code. The concept, I think, is the same, when the authors advocate for pulling the details out of the code. I surmise that if the details are in the code, then the details may be pulled out of that as well. But this is understandably more difficult in a compiled language rather than a just-in-time language.
A lot of the rest of this chapter has to do with the proper use of metadata, or data about data, to configure things like business logic (if it changes a lot, should it really be hardcoded?), and configuration details.
"Tip #38: Put abstractions in code, details in metadata"
This section was particularly interesting because it talked about concurrency, something I don't have experience with. It introduced the concepts in an approachable way, too, as a household chore - making a pina colada.
A few interesting points here: designing for concurrency means imposing design restrictions on the code, which are good things, leading to cleaner code. The example they use of a string tokenizer in C and Java is very telling. The tokenizer in the C library, strtok, is definitely uglier than its Java counterpart due to the design constraints of concurrency.
'less ugly' == 'cleaner interface' #=> trueThey also argue that it makes deployment and scaling much easier. Flexibility is the name of this chapter, after all.
This chapter builds up to an explanation of the MVC (Model-View-Controller) design pattern by explaining first how the various parts of the pattern might theoretically interact with each other - through a publish / subscription model. A view might subscribe to the events published by a model, for example, and update upon the model being updated. Reminds me of the Observer pattern.
The details of the subscription model were pretty interesting. It was just like subscribing to any email newsletter. Each actor can subscribe, recieve notifications, and then unsubscribe.
With regards to the MVC design pattern, it's tempting to think of it in terms of Rails, but the examples are not web applications. There are slight differences. When I think of them, I'll come back.
Yeah. I didn't really understand this.
I think it had more to do with software planning and project management as a whole rather than code itself? It basically espoused wiki style collaborative workflows that anyone can contribute to and update.
"Tip #43: Use blackboards to coordinate workflow."
Seems straightforward enough.
~
Really looking forward to the next chapter - "While You Are Coding."