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”
Practice: Programming by Intention
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”
Practice: Adhere to a Coding Standard
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”
Practice: Encapsulating Constructors in Simple Classes
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”
The Object Pool
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.
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. (GoF)
The system needs to behave differently when it is in various conditions (states). This often occurs when a program is modal.
The Template Method
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)
The Null Object
Rather than using a null reference when an object is absent, create an object which implements the expected interface but whose methods have no behavior.
Many of the behavioral design patterns such as State and Strategy allow implementation to vary without specializing clients. Often when a behavior or algorithm has many different versions, one of those versions may be to have no behavior at all. To avoid putting special-case conditional code, “if(!null)” for example, into clients, a Null Object can be used.