Design Patterns: Introduction

I did quite well in COS 121 (Software Modelling module at University of Pretoria). I found it to be my most enlightening module yet; however, not many people even passed the module, because of its difficulty and what I think is a lack of preparation and poor resources.

I want to try make design patterns easier to understand, and show you what you actually need to know about them (especially to pass) vs. the daunting amount of information you are presented with.

While most COS academics don’t like the idea of teaching people to “pass” (they want us to be able to think for ourselves), I think that it’s better to pass and have a decent understanding than neither.

What Will Be Covered

The following will be covered (not necessarily in this order):

  1. UML Diagrams
  2. Creational Design Patterns
    1. Prototype Patterns
    2. Factory Method Pattern
    3. Abstract Factory Pattern
    4. Singleton Pattern
    5. Abstract Factory Pattern
  3. Structural Design Patterns
    1. Decorator
    2. Adapter
    3. Bridge
    4. Composite
    5. Facade
    6. Flyweight
    7. Proxy
  4. Behavioural Design Patterns
    1. Template Method
    2. Strategy
    3. State
    4. Memento
    5. Mediator
    6. Observer
    7. Chain of Responsibility
    8. Command
    9. Interpreter
    10. Iterator
    11. Visitor
  5. Model View Controller (architectural pattern)

Why Design Patterns?

You have now moved from procedural programming to object-oriented programming. Objects complicate things… On the one hand they’re great for organising related information into single structures and hierarchies, but they can also be a nuisance if you don’t really know what’s happening — everything can quickly become a tangled mess with excess classes and functions, making it difficult to build upon your code or even use it.

Design patterns are simply “good” ways of organising classes for specific problems. They are guidelines — nothing more. They provide a blueprint for select problems for you to follow so that your code can be optimal and understandable.

If classes are the blueprint to your house, design patterns are the rules the architect was taught to help him/her make sure your house doesn’t have five front doors and no bathroom.

If anything, they will help you understand how to structure a program, and aid you in solving some problems.

Thinking Design Patterns

In order to understand design patterns, you need to start one of the most difficult parts of Computer Science: abstract thinking. Design patterns are more about concepts than actual code.

The easiest way to do this — I think — is to forget code altogether; you should, instead, start thinking about relationships. How are two entities related?

If you have an Animal class and a Dog class, it’s easier to think about the relationship as “A dog is an animal” than “Dog extends Animal“.

If you have a Character class and a Weapon class, it’s easier to think about the relationship as “A character always has a weapon” than “A character has a composition relationship with weapon, where Character is the whole”.

The idea is to break things down into simple terms, and real-world use cases.


Copyright © Matthew Evans 2017