PATTERNS05 - Guidelines for Choosing a Design Pattern
Download as PPTX, PDF2 likes1,631 views
The document discusses the importance of understanding and applying design patterns in software development, emphasizing that choosing the right pattern involves analyzing specific scenarios and recognizing the implications of each pattern. It also highlights the need for experience in programming to effectively analyze and apply design patterns, along with the consideration of implementation costs and potential trade-offs. Ultimately, well-chosen patterns can reduce the need for refactoring and provide a foundation of 'deep smarts' that enhances programming skills.
PATTERNS05 - Guidelines for Choosing a Design Pattern
- 1. Choosing a Design Pattern Michael Heron
- 2. Introduction Knowing what the patterns are and what they are for is part of the battle. Knowing when and where they should be applied is the other. In this lecture we are going to discuss the ways in which you can determine the usefulness of a pattern. And where they are not useful
- 3. Key Points Design patterns are generalized. They must be adapted to context Design patterns are a codified form of developer experience. They represent good solutions, not necessarily the best solutions. Design patterns are not always appropriate to be applied to a given problem. It’s as important to know when not to use a pattern.
- 4. Analyzing a Problem Given a particular scenario, how can you tell if a pattern is called for? Consider your three families of patterns. Creational Behavioural Structural. Analyse the scenario for the existence of terms relating to any of these three.
- 5. Analyzing A Problem The biggest skill in analyzing a scenario is appreciation of implications. Put yourself in the shoes of someone writing the program. What problems are you going to run into? This requires not only an understanding of the scenario, but also of the nature of program design. You need to know your stuff, you can’t fake this.
- 6. Analyzing A Problem Experience is the greatest predictor of future problems. Call on your own experience in writing programs to effectively analyze a scenario. The only way to really learn is to make mistakes – that’s not new age mumbo jumbo, it’s the truth. Safe to work on the assumption that unless great care is taken with a design, it will have problems. All designs do – programming is an eternal trade-off between competing goals.
- 7. Analyzing A Problem There is also no shortcut for working out the implications. You just need to think your way through it. Every scenario is unique, but programming is all about recognizing patterns. Compile a list of the features you know of. Follow them through to the logical conclusions. Identify possible implications from those.
- 8. Example Scenario - 1 Mega Games Corp are creating an online role playing game. The game consists of twenty character races, and a selection of twenty classes for each. Players can select the combination of the two, and choose between three hundred weapons, five hundred magic spells, and six hundred pieces of armour. What’s the focus here? What are the implications?
- 9. Example Scenario - 2 Picture Perfect Software Inc are developing a new graphics package based on the principle of potato shapes. Users can select from a range of preconfigured shapes and ‘stamp’ them in paint before stamping them on the document. Users then get to move and recolour the pictures as needed. What’s the focus here? What are the implications?
- 10. From Implications To Strategy Knowing what the implications are allows you to map the scenario to your available patterns. All patterns are designed to fill a certain role. Consider the patterns you have been presented. What is their role? What process are they designed to manage? Does the analysis of the program implications suggest that a specific pattern will be relevant. Note, relevant – don’t worry about whether or not it’s a good idea yet. Do this for each pattern you know. If you don’t understand the pattern, make the effort to do so.
- 11. Candidate Patterns Going through the patterns will give you a list of relevant patterns to assess. They’re not all going to be winners. Consider what the impact would be of applying a pattern. What are the consequences of each pattern? Will it improve maintainability? Does it improve efficiency? Does it open up new functionality? Importantly, does it solve any problems you have identified?
- 12. Identify Variability Every program has parts of the program that are static and parts that will change according to circumstances. Identifying that variability is a key to unlock which patterns are genuinely useful. Which of the moving parts in the program are going to cause an issue? Inappropriate handling of variability leads to design issues down the line.
- 13. Cost of Implementation There is a cost to implementing any given design pattern. Often leads to additional complexity. Often leads to over-engineering Most patterns based on a trade-off Consider what the impact will be if you implement a pattern. The cost of implementation may outweigh any benefits.
- 14. Finally Having identified which design patterns are suitable: Relevant Beneficial Net gain in application You then take this smaller pool and work out which of these are going to be implemented. If any. Does the implementation of one design pattern open up new implications for the implementation of another?
- 15. This Is Hard… This is hard to do from a specification. If it wasn’t, people wouldn’t make so many mistakes when designing systems! It’s a hugely important skill though. One you can practice. It sits between ‘knowing’ and ‘doing’. You need to be able to reasonably do both to effectively analyze.
- 16. Refactoring The biggest impact well selected patterns have is on the reduction in the need for refactoring. It’s an unavoidable need, but can be managed. Refactoring is the process whereby we rewrite code the way we would have written it before, if we weren’t operating under limits. Time Constraints Benefit of Hindsight
- 17. Design Patterns and Refactoring Design patterns are what emerge from successive refactoring. They converge on a general and almost universally applicable solution to a given problem. Adopting a design pattern early saves you from having to adopt it later. Consciously or not. After a while, experience tends to teach you to code in this way anyway.
- 18. Deep Smarts Some things you just can’t teach. They are learned only as a result of the crushing grind of life. Swap and Leonard (who coined the term) put the time needed at at least ten years. Some writers have termed this experience based knowledge as deep smarts. A big goal of knowledge management is cataloguing and translating as much of these deep smarts as possible. Design patterns, for software engineering, represent a library of deep smarts.
- 19. Where Next? Even though we’ve done five lectures on this topic, we’ve only scratched the surface. Design patterns are rich and supported by an extensive literature. The seminal book on the topic is called Design Patterns and is authored by the ‘Gang of Four’ Erich Gamma Richard Helm Ralph Johnson John Vlissides Students are heartily recommended to check it out. It covers these patterns (and more) in much more depth.
- 20. Summary Picking a design pattern is a complex task. Involving a mixture of skills. There is a process you can follow to help in this. But it doesn’t do it for you. Thinking through the implications of scenarios that are presented is something that comes easier with practice and experience. As you build your deep smarts.