For our beginning notes to review and discuss for our book club choice, The Pragmatic Programmer, I used notes from Joe Hallenbeck. This was great for the first 4 chapters, but then I had to put in some work and start taking my own notes. These were just to help jog the memory for discussion points, and in case someone didn’t read the chapter they could read some of the notes and still join in on the discussion.
Notes on Chapter 5, Bend or Break
- Decoupling and the Law of Demeter
- “Shy” code works in two ways, don’t reveal yourself to others and don’t interact with too many people
- Minimize coupling, too many unnecessary dependencies make code hard to maintain, and can be highly unstable, to keep them down use “the Law of Demeter” for methods and functions.
- Metaprogramming, get items that can change a lot out of the code (i.e. configuration)
- Make systems highly configurable using metadata (any data that describes the application)
- Put abstractions in code, details in metadata
- EJB example 🙁
- Temporal Coupling, time related specifically concurrency and ordering.
- Analyze workflow to improve concurrency
- MVC, Model View Controller, use this structure to divide functions.
- Blackboards
- Maybe like Event sourcing…Kafkta
- More decoupled, only data structures are shared but no calls are coupled.
- Asynchronous, maybe transactional and often combined with rules engines to orchestrate workflows
- Ex. Tuple space, JaveSpace
For our group the pattern that we found the most confusing was the Blackboard pattern that was discussed at the end of the chapter. Reading this in 2019 (20 years after it was published) we have found a mix of information and techniques that are still relevant, such as MVC which is hard to believe was just used with applet programming and smalltalk. But then when examples using EJB (enterprise java beans) or other patterns that maybe are known by another name (blackboards?) then this book really shows its age.
Are blackboards a pattern you still see as relevant? Do you know this pattern by a different name?
Some of the questions we discussed (from provided questions from The Dev Empathy Bookclub)
- In Chapter 5, the authors encourage writing modular code (which comes in many forms, as elaborated through the chapter) as a way of making code resilient to change. Put differently: coupled code makes more assumptions, and the more assumptions you make, the more likely you’ll be wrong about something in the future. With that in mind, how do we couple code to people, and to human systems?
- Are some of the suggested problems, such as concurrency still a problem 20 years on? And are the solutions still viable? Blackboards in particular.
Top comments (0)