Design Patterns

Going to keep this one small and to the point today and we’re going to take a look at Design Patterns.

Essentially design patterns are a reusable solution to solving our software development problems. This is great because it means someone has taken the time to put together problem solving templates that we can apply during our development.

Now there are a lot of design patterns out there and I mean a lot but they all, generally, fall into 3 categories:

  • Creational
    • Concerned with the creation of objects
  • Structural
    • Concerned with the relations between classes and objects.
  • Behavioral
    • Concerned with the interactions between objects

The above 3 categories pretty much sum up all the design patterns we need to worry about about.

So how did we get to the point where we have well-know and well-defined design patterns we can use? It started with the release of a book called Design Patterns: Elements of Reusable Object-Oriented Software in 1995 by a group called the Gang of Four (GoF). The GoF consisted of:

  • Erich Gamma
  • John Vlissides
  • Richard Helm
  • Ralph Johnson

Which even today is considered one of the most reliable resources on software design patterns. From this book we got 23 design patterns split into the above 3 categories.

  • Creational: 5 Patterns
    • Abstract Factory
    • Builder
    • Factory
    • Prototype
    • Singleton
  • Structural: 7 Patterns
    • Adapter
    • Bridge
    • Composite
    • Decorator
    • Facade
    • Flyweight
    • Proxy
  • Behavioral: 11 Patterns
    • Chain of responsibility
    • Command
    • Interpreter
    • Iterator
    • Mediator
    • Memento
    • Observer
    • State
    • Strategy
    • Template
    • Visitor

Well that’s quite a list isn’t it, and it’s only grown since then.

So how do these patterns actually help us with developing software?

I’ll pick that up next with posts dedicated to each category, first up: Creational.

I welcome feedback, especially at this very early stage, so any improvements you think I can make please get in touch either in a comment below or send me a message and I’ll get back to you.

Four Pillars of Object Oriented Programming


This week we’re going to look at the Four Pillars of Object Oriented Programming as a nice follow on from the last post, Procedural and Object Oriented Programming, the plan here is we’re going to expand on what was mentioned and get more information on what the Four Pillars actually are, in a simple and to the point way. So first off, lets name them:

  1. Abstraction
  2. Encapsulation
  3. Inheritance
  4. Polymorphism

As a side note there is also the term Three Pillars of Object Oriented Programming, this version however does not include Abstraction. So I went for doing a post on the ‘Four Pillars’ as it would literally give the best of both worlds.


The first Pillar we are going to look at is ‘Abstraction’, also called ‘Data Abstraction’, this is the means by which we only show (externally to our class) what is absolutely necessary and we hide all other aspects of the class. This is where the access modifiers I mentioned in Procedural and Object Oriented Programming come in, that is public and private (there is also protected and for C# internal but we’ll just concentrate on public and private). So, in a class those parts (data members and methods) we want other entities to see we make them public and the parts we want to keep hidden we make private.

A good example of this would be the consider a car. When we want a car to turn left we use the steering wheel. How exactly the wheels move in the correct direction we don’t really need to know, just how we move the steering wheel (our public method) ensures all the actions ‘under the hood’ (our private methods) makes the wheels turn in our desired direction.

So Abstraction, also called Data Abstraction, is the process of hiding data and information.


Encapsulation is the process of containing or ‘encapsulating’ our state and behaviour, that is our data members and methods within a self contained entity, for example a class (check out my Procedural and Object Oriented Programming post for a bit more info). When applying our Access Modifiers (see Abstraction above) we can limit who has access to that state and behaviour. Encapsulation is a very useful mechanism as it allows us to place all the related ‘stuff’ of a class (data members and methods) within one nicely contained and well named package, i.e. class (I’ve made a point of well named because after reading a book by Robert Martin called ‘Clean Code’ it is a must, I recommend you read this but I’ll be giving you some details in the future).

And that’s it encapsulation is that simple, wrapping up state and behaviour within a single class.


Similar to how we consider the term in the real world when applied to parentage. It is the process in which we allow our classes to get data members and methods, state and behaviour, from other classes. Why would we want this? Why not write each class individually? Well the biggest answer is code reuse, the more code we write the more bugs we bring into a system and the more code we have to maintain. If we can write a class then allow other classes to take that functionality and use the content without having to write it that is very helpful. It’s similar to how a child gets some characteristics from their parents. We call the class providing the members and methods the parent or base class and the class inheriting the members and methods the child or sub class.

Different languages have different versions of inheritance, so C++ allows a child class to have multiple parent classes, there are pros and cons to this, one of the most well know cons is the diamond problem (to avoid getting side tracked I’ll do a post on this in the future). Another form of inheritance is single parent inheritance (from classes), in this case we can only ever have one parent class and of course this can go up the chain, so our parent class can have one parent class and so on, this is the case in C#. In C# however we concentrate more on the use of interfaces, which is where we define a contract and leave it up the the inheriting classes to provide the implementation (again this will definitely be a future post, very important).

So the easiest way to know if you need inheritance is think can I apply the ‘is-a’ relationship, i.e. a car is a vehicle, so in this circumstance we may have a vehicle class and a car class where we may, and probably should, have our car inherit the characteristics of vehicle.


The final pillar we’re going to look at is Polymorphism, ‘poly’ means ‘many’ and ‘morph’ means ‘forms’ so ‘Polymorphism’ means ‘many forms’. It allows use to define, say, a method in our base class and allow our child classes to provide their own implementation of that method. A good example is if we have an Animal base class with a method called ‘MakeSound’, now the result of ‘MakeSound’ would be different for pretty much every animal we created, for example a Dog would bark, a Cat would meow, a Lion would roar, and a (male) Grasshopper makes their noise by rubbing a hind leg on their wings.

It essentially allows for a contract to be agreed, so in terms of our animal example every animal that inherits from the Animal class are essentially saying I will provide you with my own ‘MakeSound’ implementation.

This one tends to be a bit trickier than the other pillars but it is quite that simple, if there is any interest in some more information please free feel to ask.


And there we go a quick view on the Four Pillars of  Object Oriented Programming. Hopefully that has given you some insight however if you have any questions please feel free to ask.