Join Elisabeth Robson for an in-depth discussion in this video Looking at what we've done and where to go from here, part of Foundations of Programming: Design Patterns.
Well, at this point we've reached the end of our design patterns journey for this course. We've actually covered an impressive number of patterns including strategy, which is a pattern for changing the behavior of an object. Observer, which gives us a way to allow objects to communicate in a loosely coupled manner. Decorator, which allows us to build up behavior through composition. Singleton, which ensures only one copy of an object exists. State, which changes behavior based on a set of state objects and transitions. Iterator, which encapsulates iteration.
And Factory, which encapsulates creation. Now those are the core, common patterns that get frequently used. And there are more, including six additional patterns you'll find in the head first design pattern book, and in the gang-of-four book. And, you'll find an additional nine of the less commonly used patterns also in the gang-of-four book as well. Of course, there are many other patterns out there, including domain specific patterns like enterprise design patterns. There's also a type of pattern we haven't discussed yet. And that's the compound pattern. Compound patterns are built from two or more design patterns.
The most well known of these is the MVC or model view controller pattern which is heavily used from building systems with user interfaces. The MVC combines strategy, observer, and a composite design pattern that we haven't covered to supply the user interface, core logic, and data model for GUI-based applications. Also, we should mention our core design principle which are important not just for patterns, but for general object oriented design. We've covered a number of these. Encapsulate what varies, favor composition over inheritance, program to an interface, strive for loosely coupled designs, classes should remain open for extension and closed for modification.
And, a class should have only one reason to change. Now, we wouldn't want you to leave this course, without having an actual definition for design pattern. And here it is. A design pattern is a solution to a problem in a context. Well, would you expect anything other than something this abstract, for the definition of a design pattern? Let's step through what these are. The context is really the situation that the pattern applies to. You might have a situation where you have a number of objects which all need to say, keep track of one particular data item.
The problem is you're trying to do that in a way so that each time another object enters the scene and needs access to that same data item, you don't have to go in, and, let's say, redo all your code. And the solution would be something like the observer pattern. Where we have a way of constructing those objects together, so that everything remains loosely coupled. Yet, everyone knows about that data item, any time they need to, or any time it changes. Finally, when you begin using patterns, your temptation might be to try to apply the pattern to every part of your design. Rather than doing that, save patterns for the places where your code really is likely to change.
Otherwise, you're adding needless complexity to your designs. That said, always have patterns in mind, rather than reinventing the wheel. A huge amount of real world experience went into every design, and you should make use of that whenever you can. Remember, keep your designs as simple as possible, and ask yourself the hard question of whether or not a pattern is needed or is likely to be needed. If it is, great. You've got a toolbox of patterns ready to help you. And finally, now that you know basic design principles and you have experience with the patterns, you're in a great position to go out and expose yourself to more.
And don't forget, patterns become even more powerful when the rest of your team knows them as well.
- What are design patterns?
- Encapsulating code that varies with the strategy pattern
- Setting behavior dynamically
- Implementing the observer pattern
- Creating chaos with inheritance
- Extending behavior with composition
- Dealing with multithreading and the singleton pattern
- Revising the design for a state machine
- Encapsulating iteration with the collection pattern
- Encapsulating object creation with the factory method pattern