L13
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View L13 as PDF for free.
More details
- Words: 2,368
- Pages: 31
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.
Compound Patterns
Page 7
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".
Context
Forces Solution Benefits
Consequences Related Patterns
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
not the kind of tactic you can give to someone else to apply to their own problems.
It
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 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 :-)
terminology:
(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!
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.
Compound Patterns
Page 7
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".
Context
Forces Solution Benefits
Consequences Related Patterns
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
not the kind of tactic you can give to someone else to apply to their own problems.
It
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 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 :-)
terminology:
(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!
Related Documents
L13
August 2019 19
L13 Investment
November 2019 12
Promotion Transfer L13.pptx
April 2020 5
Grade5-l13 1-17game
July 2020 11
