Page 2

Final Exam Notes
Material to be covered: Everything we've seen in class, up to the end of the semester (= the end of tonight's lecture :-), with emphasis on the later material. Textbook sections: Old: Chapters 2, 4-6, 8-20 New: (Parts of) Chapters 21, 23-26 and 31 Patterns: See Gang of Four, Head First Design Patterns, Wikipedia patterns page, Fluffycat patterns page, etc.

Page 3

Final Exam Preparation

Same as for the midterm exam:
● ●

Start by reviewing the lecture notes. Concentrate especially on anything that you don't fully understand. Don't hesitate to ask for help if necessary (preferably not at the last minute :-). Understanding is much more important than memorization!

Page 4

Final Exam Generalities

The exam will be closed-book, with no reference materials or calculators. Where necessary, reference material will be provided in the exam book itself.

Page 7

Compound Patterns

Often two or more patterns work together in a given design. We've seen some examples. One really extreme example is given in chapter 12 of Head First Design Patterns, in which the Ducks example is reworked using all of the following:
– – – – –

Adapter Decorator Abstract Factory Composite Observer

Yes, this example is deliberately contrived. :-) You can download and examine the code if you like.

Page 8

Compound Patterns

Most of the time, the set of patterns in a given design is ad hoc ― that is, you use whatever patterns make sense for the task at hand, and usually those will vary from one project to the next. ...but sometimes, a particular combination of patterns will be useful in many different situations. This kind of pattern of patterns is what we call a compound pattern. The classic compound pattern example is... ...our old friend model-view-controller. :-) The easiest way to understand MVC is to realize that it's actually built from three Gang of Four patterns: Strategy, Observer and Composite.

Page 9

Compound Patterns

Most of the time, the set of patterns in a given design is ad hoc ― that is, you use whatever patterns make sense for the task at hand, and usually those will vary from one project to the next. ...but sometimes, a particular combination of patterns will be useful in many different situations. This kind of pattern of patterns is what we call a compound pattern. The classic compound pattern example is... ...our old friend model-view-controller. :-) The easiest way to understand MVC is to realize that it's actually built from three Gang of Four patterns: Strategy, Observer and Composite. ...even though MVC predates the Gang of Four by 15 years! What does that suggest? :-)

Page 10

Compound MVC

MVC components:

Strategy The view is configured with a given strategy, as provided by the controller. Yes, this implies that the same view could work with a different controller if you want the system's behaviour to change. Observer The model is the concrete observable object, and the views are concrete observers. Composite The view may include nested components as part of a GUI. When the controller tells the view to update itself, all the subcomponents will be taken care of as well.

Page 11

Pattern Catalogs
Recall from week 5: Problem "A pattern is a solution to a problem in context". Forces Solution Benefits Related Patterns Consequences

Context

Page 12

Pattern Catalogs
Okay, but what does this actually mean?

Consider this situation: Problem: How do I get to Concordia in time for the final exam? Context: I've locked my keys into the car. Solution: Break a window, unlock the car, and drive to Concordia. Is this a pattern? :-)

Page 13

Pattern Catalogs
Okay, but what does this actually mean?

Consider this situation: Problem: How do I get to Concordia in time for the final exam? Context: I've locked my keys into the car. Solution: Break a window, unlock the car, and drive to Concordia. Is this a pattern? :-) Why isn't it a pattern? Two reasons:  While a sufficiently absent-minded person might lock their keys into the car often, breaking the window isn't a solution that can be applied over and over.
 It's  It

not the kind of tactic you can give to someone else to apply to their own problems. doesn't have a name. (Okay, that's three reasons. :-)

Page 14

Pattern Catalogs

This is why patterns are described the way they are in the Gang of Four book ― which incidentally is the most definitive pattern catalog for software design, but not the only one. Others include: – The Portland Patterns Repository:  http://c2.com/ppr/index.html – The Hillside Group:  http://hillside.net/patterns/onlinepatterncatalog.htm

Page 15

Modifying Patterns

If a pattern doesn't quite fit your needs, there's no law that says you can't adapt it. After all, patterns are guidelines, not rules. If you do adapt a pattern, it's a good idea to document how you did so, partly because the modified pattern may be useful in its own right, and partly to let your colleagues know what you did.

Page 16

Creating Patterns

Patterns don't just happen, they're created by real programmers. ...which means that you too can create your own design patterns. :-) ...but generally, people don't set out to create a pattern, they set out to solve a problem. The trick is to think in general terms, and to recognize a pattern once you see it. Part of being able to do that is to study existing patterns, what they do and how they relate to each other. The more you know about how patterns are crafted, the easier it gets (plus you don't really want to reinvent the wheel :-). You know you have a new pattern when...

Page 17

Creating Patterns

Patterns don't just happen, they're created by real programmers. ...which means that you too can create your own design patterns. :-) ...but generally, people don't set out to create a pattern, they set out to solve a problem. The trick is to think in general terms, and to recognize a pattern once you see it. Part of being able to do that is to study existing patterns, what they do and how they relate to each other. The more you know about how patterns are crafted, the easier it gets (plus you don't really want to reinvent the wheel :-). You know you have a new pattern when... ...other people have used it and found it useful. The so-called "Rule of Three" suggests that it shouldn't be called a pattern until it's been applied in at least three real world projects.

Page 18

May the Force be With You
terminology:
The Design Pattern definition tells us that the problem consists of a goal and a set of constraints. Patterns gurus have a term for these. They call them forces. Why? Well, we're sure they have their own reasons, but if you remember the movie, the force "shapes and controls the Universe." Likewise, the forces in the pattern definition shape and control the solution. Only when a solution balances both sides of the force (the light side: your goal, and the dark side: the constraints) do we have a useful pattern ― whether here, or in a galaxy far, far away :-) (from Head First Design Patterns, p. 582)

Page 19

Organizing Patterns

Generally, design patterns are organized into three categories (as in the GoF book): Creational patterns involve instantiating objects, and are intended to decouple a client from the objects it needs to instantiate. Examples: Factory Method, Abstract Factory, Singleton Behavioural patterns are concerned with interactions between classes and objects, and distribution of responsibility. Examples: Command, Iterator, Observer, Strategy, Visitor, State Structural patterns help compose classes or objects into larger structures. Examples: Adapter, Compositge, Decorator, Facade, Proxy

Page 20

Organizing Patterns

A second way of organizing patterns is to classify them by whether they deal with classes or with objects. Class patterns describe inheritance/implementation relationships, and are established at compile time. Examples: Factory Method, Adapter Object patterns describe relationships between objects (mostly via composition). These relationships are typically created at runtime, and are therefore more flexible. Examples: Composite, Visitor, Strategy, Decorator, Chain of Responsibility, Abstract Factory, Singleton, ... Notice that there are many more object patterns than class patterns!

Page 21

Thinking in Patterns
Some principles from Head First Design Patterns:

Keep it simple. When you design, solve things in the simplest way possible. In particular, don't use a pattern just because you can; if you use one, use it because it's the right thing to do. Design patterns aren't a magic bullet (in fact, they're not even a bullet!). You can't just plug a pattern into a design and hope for the best; instead, you need to consider how the pattern fits into the design, and what its consequences will be (and how you plan to deal with the consequences). You know you need a pattern when... ...you're sure it addresses a problem in your design. This is where your experience and knowledge com in. Consider the problem you're trying to solve along with the constraints you're working with: is there a pattern that will fit this particular situation? (Hint: study the Intent and Applicability sections of the pattern you're considering.)

Page 22

Thinking in Patterns

Refactoring time is Patterns time. Refactoring offers a great opportunity to reexamine your design to see if it might be better structured with patterns. Note: entire books have been written on just this one topic. :-/ Take out what you don't really need. Don't be afraid to remove a pattern from your design. When should you do this? When it turns out that the flexibility you planned for isn't needed after all ― in other words, when a simpler solution without the pattern is better. If you don't need it now, don't do it now. If the reason for adding a pattern is a hypothetical future requirement, wait for the requirement to happen for real. Remember the XP mantra: YAGNI.

Page 23

Evolution of a Designer

The Beginner uses patterns everywhere. This is good in a way, because it helps the beginner gain experience with patterns ― but the beginner thinks "the more patterns I use, the better the design", and this is almost always false.

The Intermediate Designer starts to see where patterns are needed and where they aren't. This may still involve trying to put square pegs into round holes, but at this level designers begin to realize how patterns can be adapted where the canonical version doesn't fit.

The Expert is able to see where patterns fit naturally. The expert isn't obsessed with using patterns, but looks for the simple solution that will best solve the problem. The expert sees the principles and the tradeoffs involved, and recognized when to use and when to adapt a pattern.

Page 24

Anti-Patterns

An anti-pattern is something that looks like a good solution, but turns out to be bad when you actually apply it. The reason for documenting anti-patterns is that helps people avoid making the same mistakes over and over again. (Those who forget history are doomed to repeat it. And also math and computer science. :-) A good anti-pattern describes the problem, but it also describes why the proposed solution is attractive and why it doesn't really work. References: http://www.antipatterns.com/ http://en.wikipedia.org/wiki/Anti-pattern

Page 25

A Sample Anti-Pattern
 

Name: Golden Hammer Problem: You need to choose technologies for your development and you believe that exactly one technology must dominate the architecture. Context: You need to develop some new system or piece of software that doesn't fit well with the technology that the development team is familiar with. Forces: – The development team is committed to the technology they know. – The development team is not familiar with other technologies. – Unfamiliar technologies are seen as risky. – It is easy to plan and estimate for development using the familiar technology.

Page 26

A Sample Anti-Pattern

Supposed Solution: Use the familiar technology anyway. The technology is applied obsessively to many problems, including places where it is clearly inappropriate. Refactored Solution: Expanding the knowledge of developers through education, training, and book study groups that expose developers to new solutions. Examples: Web companies keep using and maintaining their internal homegrown caching systems when open source alternatives are in use.

Page 27

Some Head First Bullet Points

Let Design Patterns emerge in your designs, don't force them in just for the sake of using a pattern. Design Patterns are set in stone; adapt and tweak them to meet your needs. Always use the simplest solution that meets your needs, even if it doesn't include a pattern. Study Design Pattern catalogs to familiarize yourself with patterns and the relationships among them.

Page 28

Some Head First Bullet Points

Pattern classifications (or categories) provide groupings for patterns. When they help, use them. You need to be committed to be a patterns writer: it takes time and patience, and you have to be willing to do lots of refinement. Remember, most patterns you encounter will be adaptations of existing patterns, not new patterns. Build your team's shared vocabulary. This is one of the most powerful benefits of using patterns.

Page 29

Some Parting Words

We've discussed various methodologies, tools, principles and patterns. ...but in a world full of tradeoffs (some technical, some economic, some "political"), in the end it all comes down to you: to your knowledge, your experience, your wisom and your sense of responsibility and determination to do the right thing. Anyone can claim to be a programmer or a software designer, but being a good one takes commitment and a sense of pride in what you do.

Page 30

Page 31

Thank you all for being here this semester, and best of luck in whatever you go on to do next!