Main Content

Design Patterns - what are they? Why use them?

Archive - Originally posted on "The Horse's Mouth" - 2012-02-12 09:47:26 - Graham Ellis

Object orientation provides a wonderful bag of components, but they need to be linked together to provide a full set of facilities for data handling. And very often that linking together is in a way which can be standardised - along the lines of "you normally do it this way". Such standardised methodologies are known as Design Patterns

When teaching Object Orientation, we go through the mechanisms of the language, and application design (see "Designing your applications using UML techniques"). And I cover a little - a very little - about design patterns. Delegates need to be aware of them, but a course that included a deep study of design methodology and patterns would be extended from what we currently offer by at least a day, with delegates who are converting from another OO language finding that the extra time was mostly revision.

However, last week's PHP Course ran quickly - bright delegates, all starting with more experience that our stated prerequisites, and in the training room 30 from 30 minutes before class officially started each morning. So we got on to the mechanisms of OO programming in PHP on the final afternoon of the main course, rather than starting it in the official way on the Friday morning. Which gave me time to talk about UML techniques in more detail, and to add in some more coverage of Design Patterns than is usual.

In a new source code example ([here]), you'll find a number of design patterns in use - some being commonly accepted / named ones, others which are our / my own patterns.

There's a factory pattern which takes raw data and creates an object from it. A factory differs from a constructor in that it often has to do preliminary work on the data, and indeed it can return objects of different types depending on the data actually passed in, and indeed it can return an array / list / hash / dictionary of objects. A factory method is a static method, provided within a class to place the logic of interpreting the incoming data source into objects, even prior to the creation of any objects.

There's a comparator pattern, which compares two objects. Static (class) methods can work on the data for all objects in a class, dynamic (object) methods work on a single object. Yet so often you want to compare two objects. Which is the larger? Which is the older? And that's where you'll use a comparator design pattern.

As an extension of the comparator, we often use a standard (static) pattern to find the largeest or oldest - no formal name for this one, but you'll find an example called "longest" in the source example.

We've also got an example of a very simple getter pattern to retrieve a property, but this particular example didn't use some of the other common design patterns such as setter and singleton. That's fairly typical - you'll use design patterns for the standard stuff, and then your own (or modified) code beyond that to add the functionality that's unique to your data and the application thereof.

I spoke earlier about the decision we've had to take at Well House Consultants as to how far we go along teaching design methodologies and design patterns in our programming language courses. I believe we have the mix about right for most delegates who come on public courses. But if you're looking to learn about object orientation in Perl, PHP, Python, Ruby or C++, and would like an extra day or two covering the topics I describe in this article, please ask. We can usually (diary permitting) add an extra day onto the end of our courses to cover the subjects. Typically, it will be a private course - and we'll only charge you as if it was another day on the public course. A bargain way to learn about designing your application, and learn about it in the language that you'll be using!