Pattern Basics
"Each pattern describes a problem which occurs over and over and over again in our environment, and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without ever doing it the same way twice"
- Christopher Alexander
Surgeons have names for the procedures they perform. This allows them to communicate quickly and efficiently. When a surgeon states that he needs to perform a "cesarean section", other sugeons and nurses know immediately what needs to occur, and even though every procedure is unique. There is no need for everyone to stop, discuss what needs to occur, and formulate a plan. Part of the beauty of Design Patterns is that a group of developers can communicate quickly with each other and save hours of discussion time about what needs to occur.
Just a quick list of notes about Software Design Patterns in general. This does not describe any particular pattern.
-
Patterns are NOT algorithms. Patterns are conceptual. Patterns do not have an exact implementation, and you can not build a library of Patterns the way you would build a library of classes (like STL, or unlike STL).
-
Patterns improve reuse. The larger your program, the longer you hope to have it in use, and the more it will have to adapt to changes, the more useful Patterns will be to you. You don't need to waste your time with patterns if you are building a throw-away program that is fairly simple.
-
Patterns improve reuse by anticipating the things that are likely to change and designing your project in such a way that your future changes are not breaking changes.
-
Trying to fit all the Patterns into your project is not the right idea. They should be used only when they make sense. The use of patterns adds a layer of complexity that can make it more difficult to understand the code. They isolate items that are likely to change in the future so that you can change while leaving the rest of your code intact. This is why interfaces are a HUGELY important concept with Patterns.
-
Trade-offs: Each pattern has a consequence. When you build your software you have to weigh the cost of performance and the cost of maintainability. Most or all patterns will cause a performance hit, and make your code more difficult to understand by others if they are not familiar with patterns. Also different developers will see different ways to implement a pattern or perhaps suggest a different pattern altogether, so this is not about making a 'right or wrong' decision, rather a thoughtfully weighed consideration of when and how to utilize patterns to make your software more reliable and maintainable and more stable in the face of change.
- Patterns may tell you what to put in the interface, and what not to put in the interface