The Gang of Four book states,
Consider what should be variable in your design and encapsulate the concept that varies.
To a modern agile developer, the word “should” is a bit of a red flag. It presumes that we know, ahead of time, what is going to change. We don’t believe this and we certainly don’t want to depend on guessing correctly.
It is good to remember that the book precedes the agile movement and, in this regard, perhaps reflects an old point of view. But the advice is not obsolete, it just needs a bit of an update. It should say,
Consider what has become variable in your design and encapsulate the concept that varies.
Continue reading “Advice from the GoF: Encapsulate the concept that varies”
Composition indicates a “has-a” relationship between objects. Inheritance, on the other hand, indicates an “is-a” relationship. The Gang of Four would seem to be suggesting that you lean toward (“favor”) the former rather than the latter.
The potentially confusing aspect of this is that the patterns they delineate in the book use inheritance fairly extensively. Why would they recommend against this, and then do it? Continue reading “Advice from the GoF: Favor Composition Over Inheritance”
Behavior in object-oriented systems is a reflection of the interaction of objects. If you change the objects, or alter their interaction, the resulting behavior changes.
This means that objects have relationships to other objects, usually through references that are used to call methods. The Gang of Four recommends that these relationships should be defined based on how the objects look to each other, not by how the objects are implemented. Continue reading “Advice from the GoF: Design to Interfaces”
The Design Patterns movement, begun (in software) by Gamma, Helm, Johnson, and Vlissides, essentially elevated certain design elements as valuable, repeated, high-quality examples of a particular approach to design.
Their general advice was given in three parts:
- Design to Interfaces.
- Favor composition over inheritance.
- Encapsulate the concept that varies.
All patterns adhere to this rubric in different ways. Continue reading “What Design Patterns Represent”
I recently wrote a long series of posts here on various topics about Test-Driven Development. I ended up writing so many of them, they resulted in a little book I published through Amazon Kindle Direct called The TDD Companion.
I’ve started to hand out copies of this book to student in my TDD courses.
That worked out so well, I thought to do it again on another set of topics, in this case centered on good object-oriented analysis and design. It’s another topic I teach, and I’m hoping it will result in another handy field guide, likely to be called The Design Patterns Companion, as I use the patterns as my way of teaching good design and analysis in OO.
Part of what made this work for me was the terrific feedback I got from many individuals on my LinkedIn, though I also put these up on Net Objectives Thoughts. So if you enjoyed the TDD posts, I hope you’ll find this new series to be equally valuable and that you’ll continue to share your thoughts on these topics with me.
For the last few month, I have been posting several times a week on what I hope are interesting topics relating to aspects of Test-Driven Development. Many people have commented positively on this work. I have just posted the sixtieth entry in this series and this seemed like enough content to gather into a sort of handbook or field guide. I believe anyone using TDD will find this helpful in advancing in their practice.
So today, I am announcing the release of “The TDD Companion.” It is available via Amazon’s Kindle Direct Publishing. Continue reading “Announcing the TDD Companion”
Most requirements are statements of desired behavior. But there can be implications behind these requirements concerning behavior that is not desired.
For example, we might test-drive a value object that represents some domain information, and the requirement for it might include that the object must be “immutable.” The implication would be that the object has no mutator methods allowing the values contained to be altered.
How can we write a test that specifies that a method does not exist? Continue reading “Specifying the Negative in TDD”
Here is a bit of a thought experiment, first suggested to me by Eran Pe’er.
Imagine there are two magic buttons in front of you. You know, without any doubt that if you press Button A then your code will suddenly have 90% code coverage. If you push Button B, you will have 80% code coverage.
But there is another difference. Continue reading “TDD and the Magic Buttons”
Software is quite often implemented in the context of reusable frameworks and other preexisting, valuable entities. As our industry matures it becomes increasingly true that we don’t need to re-invent the wheel
For example, if code is written that is required to send data over a TCP-IP connection in, say, C#, the tendency is for the developer to use the built-in Socket class that is part of .Net. Why would a developer create their own such entity? It makes sense to reuse what is well tested and proven over time to be effective. Continue reading “TDD and Inflection Points”
TDD tests need to be run frequently. As an agile process, TDD needs to be responsive and flexible. Part of this is the ability to keep very short the feedback loop between tests and production.
To run tests frequently without excessive cost requires that they must be executed quickly. Here are some things that help keep tests fast. Continue reading “Keeping Tests Fast”