This blog was originally written in April, 2012
I have incredible respect for the signatories of the Agile Manifesto. I believe it to be a great document. I say this for several reasons – the greatest being it created a new space for effective development to take place. It started a movement that has changed the lives of millions.
That said, I believe manifestos, by their very nature when they are effective, tend to be time dependent. In the case of the Agile manifesto, this is particularly so – it’s very success has created a vacuum. Continue reading “Agile Manifesto: Incredible Success and time to Move On”
Traditionally, encapsulation has been thought of as the hiding of data or “state.” While it is true that hiding data encapsulates it, encapsulation can mean much more than this. It’s like the notion that all dogs are mammals, but not all mammals are dogs. Continue reading “Practice: Encapsulate by Policy, Reveal by Need”
Programming by Intention is a way of writing code that capitalizes on the way a programmer thinks.
Whenever you write code, what you are essentially doing in breaking down a behavior into its steps. In sense, that’s what code is. So, your brain, as a developer, is good at this. Programming by Intention says let’s capitalize on this fact. Continue reading “Practice: Programming by Intention”
One of the simplest practices a development team can benefit from is the adoption of a coding standard. A standard is simply a set of straightforward rules that everyone on the team agrees to. Here are some rules to include in a coding standard. Continue reading “Practice: Adhere to a Coding Standard”
A recurring question in OO is, “When it is determined that an algorithm should be established in its own separate class (to make it testable, or reusable, or simply as an issue of cohesion) should it also be given a separate abstract type that it implements?”
The advantage, of course, is that the client (or clients, as more arise) will not couple to the specific service class, but rather to the abstract type. If more versions of the service are added, then clients will be largely unaffected. It’s a form of “future proofing”. But can you do this all the time? Should every class, when deemed necessary, also have a second class that hides its real type? Often this would seem like overkill or over-design. Does that mean it should never be done? That seems wrong too.
Is there something that can be done to resolve this conundrum?
Continue reading “Practice: Encapsulating Constructors in Simple Classes”
Create a manager class to represent a pool of reusable resources. Clients will access the manager to obtain an instance of the resource and return it when their task is complete.
Continue reading “The Object Pool”
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. (GoF)
Continue reading “The Observer”
The system needs to behave differently when it is in various conditions (states). This often occurs when a program is modal.
Continue reading “The State”
We want to abstract out a common theme from different cases that have different implementations of an algorithm.
Continue reading “The Template Method”
Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. (GoF)
Continue reading “The Mediator”