Lecture 6a: Design Patterns and reusable code


I. Motivations for design patterns

Just like in real life, you probably don't want to reinvent the wheel... especially many times... that's just bad business, or life in general.  Design patterns are patterns design for reuse by everyone.  They present a "recommended" approach of solving a specific problem.

The idea of design pattern was not originally realized in software... in fact it's everywhere.  For instance, architecture.  There are many "recommended" ways of designing something, like a courtyard, cathedrals and others.  Design patterns can be found in many engineering disciplines as well and are important in engineering in general.

Software design patterns are language independent and prevalent in all software that we use today.  They were conceived in the 70s and 80s in academia but didn't hit mean stream until the recommended textbook on design patterns came out in the mid-90s.  The idea hit it big and was able to bring OOP to a new level.  It paved the road to software architecture (not covered in this course and shouldn't be covered in undergrad) and other important design and corporate programming environments.

For this class we will only go over structural patterns (except singleton), all the other ones are a little advanced for this class.  The structural patterns only helps you design where things go, not necessarily how the behave... which is harder to convey in UML and design patterns in general... and much harder to implement as well.

II. Facade pattern

The facade pattern is what we have seen in our designs already.  It basically makes a class that is an interface to something more complicated.  For the full prescription of the pattern, refer to Wikipedia.  The UML for it looks something like this:


This is like our Vehicle class that we talked about in the good design lecture.  It wraps around something complicated and makes it simple to use.  It is not meant to be confused with the Adapter pattern which will be talked about later in that this is only to simplify, not cover over.  It should also not be confused with the proxy pattern in that the proxy pattern is meant to control, not just to simplify... two very different things.

III. Adapter pattern

The adapter pattern is a pattern that allows you to integrate something into your framework.  The key to the adapter pattern is that the adaptor can either be inherited or dependent on the adaptee.  This allows for many levels of similarity to the adaptee by the adaptor.  More detail can be found on Wikipedia.



What I have shown here is only an example of adaptation.  You don't have to go insane and use the multiple adaptee idea.  You could, but it's harder to pull together.

IV. Composite pattern

The composite pattern is a pattern that allows you to show relationships between objects in the form of the container and the contained.  This allows for containers to hold both the contained and containers at once.  More detail can be found on Wikipedia.



The composite pattern shouldn't be confused with such things as linked list and other forms of list in that it doesn't prescribe the way to implement it but only prescribes the relationship between the entities.

V. Proxy pattern (will not be tested)

The proxy pattern is a very ... dynamic one.  There are many variants of this due to the different usages that you may have.  It is designed to control a set of things or just one thing.  A list of proxy pattern usage can be found on Wikipedia as well as more details.

VI. Singleton pattern

The singleton pattern is one of the most disputed design patterns of them all.  Many dispute that it isn't even OO in concept in that you can achieve the same thing with functional programming... or nothing at all.  In some ways this is known as a waste of time for many.  But it is good in that it is a good prescribed and tested way of keeping only one instance of a class in memory.  It restricts overusage of memory... especially in cases when you know an object will take up most of the memory.  Even if you don't enforce this in your software the operating system may force you to do it by not compiling anyway if the situation really asks for it.  This is why you can sometimes get away with not even using this method and get forced into it.



More about the singleton pattern can be found on Wikipedia.

VII. The factory pattern family (will not be tested)

The factory patterns are one of the most well-known creation patterns.  They are a prescribed way of getting an object to be fully responsible for only creation of another object.  This is the greatest example of engineering in software in that the way you design these factories follows the exact same procedures as traditional engineering.  You set up your requirements and then you construct an assembly line to perform the tasks of a factory.  It works in a conveyor belt fashion.


The abstract factory pattern



The factory method pattern

You can find out more about those patterns from Wikipedia (abstract factory, factory method).