What are design patterns?
Patterns are devices that allow programs to share knowledge about their design. In our daily programming, we encounter many
problems that have occured, and will occur again. The question we must ask ourself is how we are going to solve it this time.
Documenting patterns is one way that you can reuse and possibly share the infomation that you have learned about how it is best to
solve a specific program design problem.
Example : Facade
Rationalle and Motivation
The facade pattern can make the task of accessing a large number of modules much simpler by providing an additional interface
layer. When designing good programs, programmers usually attempt to avoid excess coupling between module/classes. Using this
pattern helps to simplify much of the interfacing that makes large amounts of coupling complex to use and difficult to understand. In
a nutshell, this is accomplished by creating a small collection of classes that have a single class that is used to access them, the
facade.
Classes
There can be any number of classes involved in this "facaded" system, but I would think that the minimum is four classes. One
client, the facade, and the classes underneath the facade. In a typical situation, the facade would have a limited amount of actual
code, making calls to lower layers most of the time.
Advantages/Disadvantages
As stated before, the primary advantage to using the facade is the make the interfacing between many modules or classes more
managable. One possible disadvantage to this pattern is that you may lose some functionality contained in the lower level of
classes, but this depends on how the facade was designed.
Examples
Imagine that you need to write some program that needs to represent a building as rooms that can be manipulated. Manipulated as
in interacting with objects in the room to change their state. The client that has ordered this program has determined that there will
only be a need for a finite number of objects possible in each room, and a finite number of operations that can be performed on each
of them.
You, as the program architect, have decided that the facade pattern will be an excelent way to keep the amount of interfacing low,
considering the number of possible objects in each room, and the actions that the client has specified.
A sample action for a room is to "prepare it for a presentation". You have decided that this will be part of your facade interface
since it deals with a large number of classes, but does not really need to bother the programmer with interacting with each of them
when a room needs to be prepared. Here is how that facade might be organised.
Current Progress and Future Directions:
A body of literature on design patterns has emerged. These
patterns identify, document, and catalog successful solutions to common software problems. The patterns captured by this literature have already had a significant impact
the construction of commercial software. In these systems, patterns have been used to enable widespread reuse of communication software architectures, developer
expertise, and object-oriented framework components.
Over the next few years, the author anticipates a wealth of software design knowledge will be captured in the form of patterns and frameworks. These patterns and frameworks
will span domains and disciplines such as concurrency, distribution, organizational design, software reuse, real-time systems, business and electronic commerce, and
human interface design.
Focus in the future: