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 patternThe factory method pattern