Don't Get Wet: Stay DRY on SOLID Ground!

If you've been doing object-oriented programming then you know about inheritance, references, and so on. But are you ready to go full-throttle on application design? To achieve that we need a solid foundation in using the fundamental principles of design and design patterns.

A principle is a fundamental rule that we want to follow because it produces better results. Robert Martin (Uncle Bob) identified five fundamental principles and grouped them under the acronym SOLID (Martin). They started out as SOLDI, but Michael Feathers pointed out to Bob that if they switched the last two principles they would spell a cool acronym (Hansel). Andy Hunt and Dave Thomas identified another important one: Don't Repeat Yourself (Hunt). And underlying all software development I insist on recognizing that there is a general, unspoken principle of organization, which all of these principles are related to.

My interest is to explore what is behind these six principles, why they are so important, and how they relate to each other. I've spoken about these topics frequently, this is my chance to put some of those thoughts down in writing. I will try to be agnostic about whether we are using a class-based (C++, Java, C#) or prototypal (JavaScript) environment.

Custom Types in Object-Oriented Languages

C++ inherited a preprocesser command from C: typedef. It is a form of abstraction. Think about it: if I can assign a new name to an existing type with this, then I'm encapsulating that type behind an abstraction. If I need to change the definition I don't need to recode all the clients that use it. And in C++ it works with templates!

#typedef CustomerList vector<Customer&>;

The reason C gave us typedef is to simplify the type names used. Simplifying things reduces the mistakes that are made.

There Can Be Only One!

Well, I want to talk about singletons but that title is a bit misleading because you can have more than one instance of a singleton. Say what? My definition of a singleton is "restrict a class or object to a single instance in a shared context." OK, I know my definition isn't exactly the Gang of Four's: "Ensure a class only has one instance, and provide a global point of access to it" (Gamma). But honestly, some folks take that book way to literally.

Those guys used "global" in the context of C++ applications mostly written for the desktop, and their point gets twisted by the choice of that word. When you move the management of the object into the class, as the GoF teaches us, then that could mean one object in a module. Or what about web-server applications: how about one per connection, or one per session? Such software wasn't really around in 1994, that is why almost two decades later the the word context is really a better choice for the description.

High Cohesion and Low Coupling

We don't often talk about cohesion and coupling at the same time but maybe we should. High cohesion is not a principle, it's a state that we try to achieve. Cohesion is a metric: a measurement of how closely related a group of things are.

We have been tasked with designing software for a bank. Here is our first shot at what an account should look like in the Unified Modeling Language. We are going to take this back to our customer and make sure that we are all on the same page about how an account works:

You may not like this example. Maybe you see some problems, or maybe it's just a feeling that something is wrong. So, let's pull it apart and find out exactly why!

In JavaScript Everything's an Object, Get Over It!

Today I am staying out of the philosophical discussion about whether JavaScript is truly an object-oriented language. FYI a lot of that discussion revolves around polymorphism and that because it is not strongly typed it does not have overload methods. That is true of other languages too, consider Groovy. But for the moment, let's just say that if we can actually create objects with properties then we can do some OOP with it.

In this article I am only interested in the tools that JavaScript has to build objects, and JavaScript is a bit schizophrenic about that. For example JavaScript defines the "new" operator so that creating an object looks more like programming Java. But we can also create objects literally or by using the grandparent of all objects: Object.

Let's take a tour of object creation and see if we can sort some all it out. First of all, we can define literal objects and properties using a comma-separated list of "name: value" pairs enclosed in braces. The property names should follow the identifier rules for JavaScript, and the value can be anything: a string, a number, an array, a reference to another object, or even a function. We can save a reference to the new object in a variable, and we can retrieve or assign new values to a property using the the variable and the . (dot) operator:

newline = '<br />';
Box = { width: 4, height: 5 };
document.write('The box is ' + Box.width + ' x ' + Box.height + newline);
document.write('The box volume is ' + (Box.width * Box.height) + newline);

Secondly, by default all JavaScript objects are extensible; all you have to do is assign a value to a new property and the object has it:

Box.depth = 6;
document.write('The box is ' + Box.width + ' x ' + Box.height + ' x ' + Box.depth + newline);
document.write('The box volume is ' + (Box.width * Box.height * Box.depth) + newline);

So, back to that new operator. It works with a function and builds a new object:

function Rectangle() {
}

var shape = new Rectangle();

Collaboration

Including the answer to: "What exactly is the difference between aggregation and composition?"

One facet of the principle of Single Responsibility is that each class is responsible for one thing. Specifically, Robert Martin defines this as each class should "have only one reason to change" (Hansel; Martin, Agile). When you apply the idea of Single Responsibility to classes in an object-oriented design then the classes must work with each other to accomplish more complex tasks, and you just forced collaboration. There are several types of relationships that classes use for collaboration. We are going to look four: dependency, association, aggregation, and composition.

XML Validation in Client-Side JavaScript

This week Alan, a participant in an advanced JavaScript course, posed a question to me: "how can I validate the XML returned from an AJAX call against a DTD or Schema?" I have to admit that I hadn't really considered it before. In retrospect I've always been in the camp that figures the server is part of the greater application, the server is the source for the data, and we can safely rely on it. But what if we can't? Or we shouldn't? The good news is that at least one JavaScript library exists that can validate a document against a schema; the bad news is that it cannot validate a document against a DTD.