Patterns will help you become a better software developer
•Download as PPTX, PDF•
4 likes•766 views
Patterns can be found in all areas of your life, from creating grocery lists to crafting robust software applications. This session will introduce you to the concept of patterns, their history and benefits. We'll look at some different uses of patterns in crafting software applications, including design patterns, architectural patterns and user interface design patterns. We'll chase a rabbit and look at where patterns fail or might not be used correctly. You'll leave this session able to identify patterns and successfully use them in all facets of your design and construction of software applications.
Recommended
Recommended
More Related Content
Similar to Patterns will help you become a better software developer
Similar to Patterns will help you become a better software developer (20)
Recently uploaded
Recently uploaded (20)
Patterns will help you become a better software developer
- 1. I <3 Patterns Matt Ruma (@mattruma) Ann Arbor Day of .NET, October 29, 2011
- 2. You work small miracles every day. Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master. 2
- 3. It’s a difficult job. Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master. 3
- 4. There are no easy answers. Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master. 4
- 5. You get the job done, and do it well. Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master. 5
- 6. You want to become a better software developer. Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master. 6
- 7. Patterns will help you become a better software developer. 7
- 8. Agenda • Patterns in the wild • Speaking in patterns • Patterns defined • Advantages of patterns • Disadvantages of patterns (not really) • Pattern examples • Chase a rabbit, look at anti-patterns • Getting started with patterns • Wrap things up 8
- 9. PATTERNS IN THE WILD 9
- 10. Patterns are models deserving of imitation. 10
- 11. Patterns in books and movies. 11
- 12. Patterns in music. 12
- 13. Patterns in presentations. 13
- 14. Patterns for raising children. 14
- 15. On and on we could go. • Patterns for operating a gas station. • Patterns for operating a restaurant. • Patterns for operating a customer service desk. • Patterns for putting on a conference. • Patterns for the construction of buildings. 15
- 16. Patterns are part of everyday life. 16
- 17. SPEAKING IN PATTERNS 17
- 18. Is beauty in the eye of the beholder? Alexander, Christopher (1977). A Pattern Language: Towns, Buildings, Construction. 18
- 19. Each pattern describes a problem which occurs 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. Alexander, Christopher (1977). A Pattern Language: Towns, Buildings, Construction. 19
- 20. Architecture Patterns • Accessible Green • Four Story Limit • Warm Colors Alexander, Christopher (1977). A Pattern Language: Towns, Buildings, Construction. 20
- 21. What does all this architectural babble have to do with software developers? 21
- 22. PATTERNS DEFINED 22
- 23. Patterns describe a recurring problem and a solution. 23
- 24. Each pattern, in its simplest form, is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. 24
- 25. Pattern Elements • Context is the situation in which the pattern applies. • Problem refers to the goal you are trying to achieve in this context. • Solution is what you’re after: a general design that anyone can apply which resolves the goal and set of constraints. 25
- 26. Chocolate Chip Ratio • Context. You are baking chocolate chip cookies in small batches for family and friends • Problem. Determine the optimum ratio of chocolate chips to cookie dough • Solution. Observe that most people consider chocolate to be the best part of the chocolate chip cookie. Also observe that too much chocolate may prevent the cookie from holding together, decreasing its appeal. Since you are cooking in small batches, cost is not a consideration. Therefore, use the maximum amount of chocolate chips that results in a really sturdy cookie. 26
- 27. Patterns != Principles 27
- 28. Patterns are discovered not created. Alexander, Christopher (1977). Timeless Way of Building 28
- 29. ADVANTAGES 29
- 30. Someone has already solved your problem. Freeman, Elisabeth; Freeman, Eric; Bates, Bert; Sierra, Kathy (2004). Head First Design Patterns 30
- 31. Keeps you sane. 31
- 32. Allows for change. 32
- 33. Establish common terminology to improve communication within teams. Shalloway, Allen; Trott, James (2005). Designs Patterns Explained: A New Perspective on Object-Oriented Design 33
- 34. So many words Carpenter 1: How do Carpenter 2: Well, I you think we should think we should make build these drawers? the joint by cutting straight down into the wood, and then cut back up the other way 45 degrees, and then going straight back down, and then … Shalloway, Allen; Trott, James (2005). Designs Patterns Explained: A New Perspective on Object-Oriented Design 34
- 35. Just right Carpenter 1: Show we use a dovetail joint or a miter joint? Shalloway, Allen; Trott, James (2005). Designs Patterns Explained: A New Perspective on Object-Oriented Design 35
- 36. You are saying more with less. Shalloway, Allen; Trott, James (2005). Designs Patterns Explained: A New Perspective on Object-Oriented Design 36
- 37. Allows you to stay in the “design” frame of mind. Shalloway, Allen; Trott, James (2005). Designs Patterns Explained: A New Perspective on Object-Oriented Design 37
- 38. Move more quickly, less room for misunderstanding. Shalloway, Allen; Trott, James (2005). Designs Patterns Explained: A New Perspective on Object-Oriented Design 38
- 39. Motivates junior developers. Shalloway, Allen; Trott, James (2005). Designs Patterns Explained: A New Perspective on Object-Oriented Design 39
- 40. Uncle Bob says so. 40
- 41. DISADVANTAGES 41
- 42. Disadvantages, some so-so • Maslow’s hammer • Too complex • Different interpretations • Whoops! Using the wrong one • Pattern happy Shalloway, Allen; Trott, James (2005). Designs Patterns Explained: A New Perspective on Object-Oriented Design 42
- 43. EXAMPLES 43
- 44. Pattern Categories • Design Patterns • Application Architecture Patterns • Database Patterns • Refactoring Patterns • Application Presentation Patterns • User Interface Patterns 44
- 45. Design Patterns • Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context • Purpose can be creational, structural and behavioral • Scope can be class or object • Catalogued 23 popular patterns • Singleton, Decorator, Adapter, Façade, Composite and Factory Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John M. (1994). Design Patterns: Elements of Reusable Object-Oriented Software 45
- 46. Application Architecture Patterns • Client/Server • Layered • Multi-Tier (N-Tier) • Service Oriented Architecture (SOA) • Message Bus 46
- 47. Database Patterns • Table design – Small master – Large master • Database normalization – First normal form – Second normal form – Third normal form or Business normal form 47
- 48. Refactoring Patterns • Code – Extract method – Extract interface – Rename method – Replace inheritance with delegation • Database – Drop column – Introduce soft delete – Split table – Add lookup table 48
- 49. Application Presentation Patterns • Model View Presenter (MVP) • Model View Controller (MVC) • Model View View Model (MVVM) 49
- 50. User Interface Patterns • Lazy registration • Progressive Disclosure • Forgiving format • Clear primary actions http://uxdesign.smashingmagazine.com/2009/06/23/10-ui-design-patterns-you- should-be-paying-attention-to/ 50
- 51. Chasing a Fat Rabbit ANTI-PATTERNS 51
- 52. Anti-pattern • Tells you why a bad solution is attractive. • Tells you why that solution in the long term is bad. • Suggests other patterns which may provide good solutions. • Code smells. 52
- 53. Examples of Anti-patterns • Death march • Gold plating • God object • Object orgy • Reinventing the wheel 53
- 55. Start learning 55
- 56. Start talking in patterns 56
- 57. Start using patterns 57
- 58. The best designs will use multiple design patterns 58
- 59. Build you own patterns catalog • Pattern name • Description of the problem • Solution to the problem (include examples) • Consequences 59
- 60. CONCLUSION 60
- 61. Wrapping things up • Patterns are everywhere. • Patterns describe a problem and provide a solution. • Patterns embody principles. • The advantages of using patterns far out weigh their disadvantages. • Beware of anti-patterns. • Just do it • Using patterns in all facets of software development will make us better developers. • Better developers write better software. 61
- 62. References • The Timeless Way of Building by Christopher Alexander • A Pattern Language: Towns, Buildings, Construction by Christopher Alexander, Sara Ishikawa and Murray Silverstein • Design Patterns: Elements of Reusable Object-Oriented Software by Eric Gamma, Richard Helm, Ralph Johnson and John Vlissides • Design Patterns Explained: A New Perspective on Object-Oriented Design by Alan Shalloway and James Trott • Refactoring to Patterns by Joshua Kerievsky • The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas • Agile Principles, Patterns and Practices in C# by Robert Martin and Micah Martin • Head First Design Patterns by Eric Freeman, Elisabeth Freeman, Kathy Sierra and Bert Bates • Universal Principles of Design by William Lidwell, Kritina Holden and Jill Butler • Refactoring Databases: Evolutionary Database Design Scott Ambler and Pramodkumar Sadalage • Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom Demarco, Peter Hruschka, Tim Lister and Suzanne Robertson • Smashing Magazine http://smashingmagazine.com 62
- 63. Go work some small miracles. Matt Ruma Master Technology Guide Epitec Group mattruma mattruma.com mattruma@gmail.com 63
Editor's Notes
- Soft introduction, my name, my title, my company and what I currently do. if they want to learn more about me they can read my blog or check out the bio on the AADODN website. Want to jump right into my subject, Patterns.
- Programming is a craft. At its simplest, it comes down to getting a computer to do what you want it to do (or what your user wants it to do). As a programmer, you are part listener, part advisor, part interpreter, and part dictator. You try to capture elusive requirements and find a way of expressing them so that a mere machine can do them justice. You try to document your work so that others can understand it, and you try to engineer your work so that others can build on it. What's more, you try to do all this against the relentless ticking of the project clock.
- There are many people offering you help. Tool vendors tout the miracles their products perform. Methodology gurus promise that their techniques guarantee results. Everyone claims that their programming language is the best, and every operating system is the answer to all conceivable ills. Of course, none of this is true.
- There is no such thing as a best solution, be it a tool, a language, or an operating system. There can only be systems that are more appropriate in a particular set of circumstances.
- You adjust your approach to suit the current circumstances and environment. You judge the relative importance of all the factors affecting a project and use your experience to produce appropriate solutions. And you do this continuously as the work progresses.
- It doesn’t matter whether you are a lone developer, a member of a large project team, or a consultant working with many clients at once. You, as an individual, want to do better work.Isn’t this the reasonwe are all here today? This talk is aimed at people who want to become more effective and more productive programmers.
- Having solid foundation of patterns, in all aspect of the software development process, not just design patterns, but architectural patterns, user interface patterns and database patterns, will help you become a better software developer.The purpose of this talk is to demonstrate to you how patterns can help you become a better software developer.
- We’ll look at some patterns, but we are not going to get deep in any particular area of pattern, just want you to get familiar with the family of patterns available.
- Patterns have multiple definitions, for the sake of this talk, this is the one we will stick with.
- Novelists and playwrights rarely design their plots from scratch. Instead, they follow patterns like “Tragically Flawed Hero” (Macbeth, Hamlet, etc.) or “The Romantic Novel” (countless romance novels).Think of the countless books you’ve read or movies you seen. How many followed the “Flawed Hero” pattern.For villains, their major flaw is usually the cause of their eventual downfall.For heroes, their major flaw usually must be overcome (either temporarily or permanently) at some point in the story, often at the climax, by their own determination or skill.For neutral characters, or those that shift allegiance, the major flaw is usually the cause of either their corruption, redemption or both.For the protagonist himself, his most visible flaw generally serves a more vital interest, as well, as it defines his or her core problem. It is the protagonist's reluctant (and usually unconscious) journey to address this problem that forms the spine of the story.Think about Star Wars, Anakin Skywalker, or Darth Vader, in many ways fulfills all the requirements of a “Flawed Hero”, including the essential tragic flaw that leads him to disaster. He also goes to a process of redemption, which is also not unknown in tragic story arcs, such as Oedipus. Other examples include, Dr. Jekyll and Mr. Hyde, Hamlet, MacBeth and Magneto.
- Music is made up of four elements, or principles, melody, harmony, rhythm and dynamics. Melody is a musical and successive line of single tones or pitches perceived as a unity.Harmony is the relation of notes to notes and chords to chords as they are played simultaneously. Rhythm is, by its simplest definition, musical time. Dynamics tell the performer when to play loudly or more softly and when to change from one to the other.A hook is a musical idea, often a short riff, passage, or phrase, that is used in popular music to make a song appealing and to "catch the ear of the listener". The term generally applies to popular music, especially rock music, hip hop, dance music, and pop. In these genres, the hook is often found in, or consists of, the chorus. A hook can, in general, be either melodic or rhythmic, and often incorporates the main motif for a piece of music.A hook would be an example of musical pattern. Heavy metal is usually based on riffs created with three main harmonic traits: modal scale progressions, tritone and chromatic progressions, and the use of pedal points. Riffs would be another example of a musical pattern.I like heavy metal music … I was listening to some songs that I would consider to be my favorites to see if there were any patterns that I could recognize, and sure enough there were. I like songs that start off slow and then get heavy. I’m not sure if there is a name for this musical pattern, but it is one that I like. Whispers in the Dark – Skillet Move – RedAfterlife – Avenged SevenfoldCemetary Gates – PanteraOne could argue genres of music, like pop, country and jazz are really patterns.
- I styled my presentation after (3) different patterns.The first, I started with the WISDOM acronym found in the book the Pragmatic Programmer:What do you want them to learn?What is their Interest in what you’ve got to say?How Sophisticated are they?How much Detail do they want?Whom do you want to Own the information?How can you Motivate them to listen to you?The second, I used the time-honored format, let’s call Tell’em, that goes:Tell ’em what you’re going to tell ’em.Tell ’em.Tell ’em what you told ’em.Lastly, I tried implementing an Attention-Grabber or two. With my title, I wanted you to know that I am excited about this subject, I have a lot invested in patterns, and I want to share them with you. Then I wanted to let you know how I felt about the work we software developers do, each and every day, we work small miracles. Then I followed that up with the purpose of the talk, to make each of us a better software developer, who doesn’t want that?I did all this to get you thinking about the implications of this presentation, I wanted your buy-in on the relevancy of this topic to you, before we even went farther.
- Children are not the brightest, if you are a parent, I’m not telling you anything you don’t know. They eat boogers, they play with poop, they do things just because they can, like leap from the roof of garage just to see if they don’t get hurt, and on and on we could go.In our house, there comes a time when the appeal of fire, and the source of the fire, the gas stove, kicks in. It casts a spell over the child and they are irresistibly drawn to the gas stove, “like a moth to a flame.” There are few ways to solve this problem. Reason with the 2-year old on why they should touch the gas stove.Just throw out the gas stove, and just eat cold food the rest of your lifeBuy some contraption from the hardware store that you can install on the stove that would protect the childLet the child touch the fire, it is not going to kill themThese are different patterns that can be applied to this problem … some of these patterns work, others don’t … the ones that work are true patterns.
- Many, many, many more …
- I challenge you when you leave this talk to just pay attention to what is going on around and you, the patterns you see, and the patterns you use to solve problems. If you think about it, when you have “gut-feeling” about something, you are just experiencing a subconscious form of pattern recognition.
- Years ago, an architect named Christopher Alexander asked himself, “Is quality objective?” Is beauty really in the eye of the beholder, or would people agree that some things are beautiful and some are not?The particular form of beauty that Alexander was interested in was on of architectural quality. What makes us know when an architectural design is good? For example, if a person was going to design an entryway to a house, how would he or she know that the design was good? Can we know good design? Is there an objective basis for such a judgment? Alexander studied this problem by making many observations of buildings, towns, streets and virtually every other aspect of living spaces that human beings have built for themselves. He discovered that, for a particular architectural creation, good constructs had things in common with each other.Architectural structures differ from each other, even if they are of the same type. Yet even though they differ, they can still be of high quality.For example, two porches may appear structurally different and yet both may still be considered high quality. The might be solving different problems for different houses. Or two porches might solve a common problem in different ways.Alexander understood this.He knew structures couldn’t be separated from the problem they are trying to solve. Alexander realized that he had to look at different structures that were designed to solve the same problem.Alexander discovered that by narrowing his focus in this way – by looking at structures that solve similar problems – he could discern the similarities between designs that were high quality. He called these similarities patterns.
- In his book, “A Pattern Language: Towns, Buildings and Construction”, Alexander introduces over 200 architectural patterns.The Accessible Green pattern describes the problem that people need green open places to go to; when they are close they use them. But if the greens are more than three minutes away, the distance overwhelms the need. The Accessible Green pattern prescribes tosolution is to build one open public green within three minutes' walk - about 750 feet - of every house and workplace. This means that the greens need to be uniformly scattered at 1500-foot intervals, throughout the city. Make the green at least 150 feet across, and at least 60,000 square feet in area. The Four Story Limit pattern describes the problem that there is there is abundant evidence to show that high buildings make people crazy. The Four Story Limit pattern prescribes the solution as is, in any urban area, no matter how dense, keep the majority of buildings four stories high or less. It is possible that certain buildings should exceed this limit, but they should never be buildings for human habitation. The Warm Colors pattern describes the problem as greens and greys of hospitals and office corridors are depressing and cold, Natural wood, sunlight, bright colors are warm, In some way, the warmth of the colors in a room makes a great deal of difference between comfort and discomfort. The Warm Colors pattern prescribes the solution as choose surface colors which, together with the color of the natural light, reflected light, and artificial lights, create a warm light in the rooms.
- Even though Alexander was talking about patterns in buildings and towns, what he says is true about patterns used to develop software. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of all patterns is a solution to a problem in a context.Design Patterns aside, this concept of patterns and pattern languages has spilled over into user interface patterns, application patterns, business patterns, organizational patterns and more. These are all categories of patterns that we, as developers, can leverage to become better software developers and, in turn, make better software applications.
- If we look at original definition, it said “patterns are models deserving of imitation.” Let’s take a look at that word model. A model is something that is copied or used as the basis for a related idea, process, or system or a simplified version of something complex used in analyzing and solving problems or making predictions.If we combine all these definitions with what we learned from Mr. Alexander we end up this simple definition, ”A pattern describes a recurring problem and a solution.”Now that we have a pattern “officially” defined, lets look at elements of a good pattern.
- Let’s look at a sample pattern.
- Patterns come from principles. Principles say “what” while patterns say “how”. Good design patterns embody good design principles.Take the SOLID principles, they don't handily translate into design patterns. Rather, they influence good vs. bad in a design pattern.Single Responsibility is really Encapsulation plus some aspects of inheritance and polymorphism. Single Responsibility is more of a basic principle or tenet of how to decompose a problem into cooperating objects and define the classes of those objects. All design patterns should illustrate this.Similarly, Open/Closed is a language feature, usually implemented via inheritance. All design patterns should illustrate this.Generally, all of the SOLID principles show up in each design pattern somewhere. If all the SOLID principles don't show up, you have a way to improve on the design pattern.
- The spirit of this statement is further explained by Alexander, in his book, Timeless Way of Building where he says, "For of course, the discovery of patterns is not always historical. Some of the examples I have given might make it seem as though the only way to find patterns is to get them from observation. This would imply that it was impossible to find patterns which do not already exist in the world already: and would therefore imply a claustrophobic conservatism; since no patterns which do not already exist could ever be discovered. The real situation is quite different. A pattern is a discovery in the sense that it is a discovery of a relationship between context, forces, and relationships in space, which holds absolutely. This discovery can be made on a purely theoretical level.“
- Reuse existing, high-quality solutions to commonly recurring problems. Patterns capture wisdom. Reusing wisdom is extremely useful. By reusing already established designs, we get a head start on my problems and avoid gotchas. We get the benefit of learning from the experience of others. We do not have to reinvent solutions for commonly recurring problems.
- By building up your knowledge of patterns and their use you will be able to recognize solutions to problems quicker, in essence pattern recognition. Out of all our mental abilities this type of intelligence, pattern recognition, is said to have the highest correlation with the general intelligence factor. This is primarily because pattern recognition is the ability to see order in a chaotic environment. Pattern recognition is a key determinant of your potential in logical, verbal, numerical and spatial abilities. It is essential for reasoning your capacity to think logically is based on your perception of logic around you. Pattern recognition brings order to chaos, and helps keep us sane.
- Patterns are time-tested solutions. Therefore, they have evolved into structures that can handle change more readily than what often first comes to mind as a solution.
- Let’s look at an example of this.
- What are they talking about? Isn’t this a confusing description? What is Carpenter 2 prescribing? The details certainly get in the way!Doesn’t this sound like some of the code reviews you have attended? The one where the programmer describes the code in terms such as:An then, I use a WHILE LOOP here to do … followed by a series of IF statements to do … and here I use a SWITCH to handle …You get a description of the details of the code, but you have no idea what the program is doing and why it is doing it!The real question is should we use a joint that is expensive to make but is both beautiful and durable, or should we just make a quick and dirty joint that will last at least until the check clears?Often times a developers will explain what they are doing, as opposed to what they are trying to do … We might say the carpenters’ discussion really occurs at two levels: the surface level of their words, and the real conversation, which occurs at a higher level (a meta-level) that is hidden from the layman and which is much richer in meaning. This higher level is the level of “carpenter patterns” and reflects the real design issues for the carpenters.
- In the first case, Carpenter 2 obscures the real issues by discussing the details of the implementations of the joints. In the second case, Carpenter 1 wants to decide which joint to use based on costs and the quality of the joint.Who is more efficient? Who would you rather work with?By leveraging “carpenter patterns” our carpenters did not to have to “invent” anything new.
- The person whom which you are communicating with knows precisely the design you have in mind. I am not an “academically” training software developer, I am self taught.I went to Oakland University for engineering, but I sucked at math, I ended up dropping out. I then went to Macomb Community College for advertising and then switched to marketing. I then went to Michigan State University for marketing, and then switched to general business and then decided I wanted to be software developer … and dropped out. Making the long story short, I started learning to code on my own, move to Tennessee to mentor under a buddy of mine, and landed my first consultant job. Over the course of the past 15 years I learned a lot about programming, behind the proverbial eight ball and having a disdain for college, I read a lot of books, read blogs, read periodicals, listen to podcasts and more. A year or so ago I took a class a Walsh College on Business Information Technology. I aced the class. The reason being is that I understood the concepts of everything the teacher was talking about, I just didn’t know the fancy term or acronym, words like SCM (Supply Chain Management) and logistics (Moving things from one place to another). I was now able to say more with less.
- Minimizes the temptation to dive down into the nitty gritty details of implementing the nuts and the bolts of the solution.
- Move more quickly with less room for misunderstanding, because everyone on the team is well versed in design patterns.
- Junior team members see that senior developers who know design patterns had something of value, some junior team members want. This provides motivation for them to learn some of these powerful concepts. The more junior developers understand about design patterns, the more they will understand basic object-oriented design principles. Which will in turn allow them to take on more challenging work. It’s all about growth!
- Like it [the GOF book] or not, you’d better know it. The patterns in that book, and in many others like it, have become part of the vocabulary of our craft. Being unfamiliar with that vocabulary, and with the design patterns behind the vocabulary, will put you at a distinct disadvantage in a programming team.
- Maslow’s hammerMaslow’s hammer is the concept known as the law of the instrument, Maslow's hammer, or a golden hammer is an over-reliance on a familiar tool; as Abraham Maslow said in 1966, "It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.“The often achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a design and/or cost some performance. They should only be applied when the flexibility they afford is actually needed. Pay attention to the consequences of a pattern when evaluating it’s benefits and liabilities.Too complexSometimes this is true, but it is often caused by a lack of understanding a specific pattern. Bill knows patterns well and has over ten years of programming experience, on the other hand, Steve has little exposure to patterns and has for years of programming experience. One day Steve looked over a significant refactoring Bill had completed and exclaimed, "I liked the code better before! Now the code is way more complex!”Bill had refactored a large amount of conditional logic associated with validating data entry screens. His refactoring led him to the Composite pattern. Bill had converted many pieces of validation logic into separate validation objects, all of which shared the same interface.Bill, wanting to understand the root of Steve’s discontent, asked Steve some questions. Bill quickly learned that Steve was not familiar with the Composite pattern. That explained a lot. Bill offered to teach Steve about the Composite pattern, which Steve took him up on. Once Steve had a grasp on the Composite pattern, they revisited the refactored code. Steve agreed now that the code wasn’t as complex as he had thought, yet he didn’t go so far as to say it was better than the previous code.Different interpretationsThe same pattern can have different names depending on which book you user as your reference. Just because words might have different meanings too people doesn’t mean we get to “throw the baby out with bath water.” Two different words can mean the same thing. What I am doing today … could be called a talk, a presentation, a speech … it doesn’t matter … as long as I understand what you mean when you use the word “talk”, “presentation”, or “speech” then we are good.Whoops. Using the wrong one.This is very possible … and is caused by a lack of understanding in the problem to be solved or the pattern that was selected. This argument is weak, as it really states, I don’t want to make a mistake. Mistakes are fundamental to learning … to making us better software developers and people in general. Make mistakes, make them often, but learn from them, and don’t repeat them. Pattern happyThe overuse of patterns tends to result from being patterns happy. We are patterns happy when we become so enamored of patterns that we simply must use them in our code. A patterns-happy programmer may work hard to use patterns on a system just to get the experience of implementing them or maybe to gain a reputation for writing really good, complex code.It is perhaps impossible to avoid being patterns happy on the road to learning patterns. In fact, most of use learn by making mistakes. The true joy of patterns comes from using them wisely.
- In the early 1990s, some smart developers happened upon Alexander’s work patterns. The wondered whether what was true for architectural patterns would also be true for software design.Were there problems in software that occur over and over again that could be solved in somewhat the same manner?Was it possible to design software in terms of patterns, creating specific solutions based on these patterns only after the patterns had been identified?The group felt the answer to both of these questions was “unequivocally yes.” The next step was to identify several patterns and develop standards for cataloging new ones.Although many people were working on design patterns in the early 1990s, the book that had the greatest influence on this fledgling community was Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides. In recognition of their important work, these four authors are commonly and affectionately know as the Gang of Four.Design patterns are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. Nor are they complex, domain-specific designs for an entire application or subsystem. Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.We classify design patterns by two criteria.The first criterion, called purpose, reflects what a pattern does. Patterns can have either creational, structural, or behavioral purpose. Creationalpatterns concern the process of object creation. Structural patterns deal with the composition of classes or objects. Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility.The second criterion, called scope, specifies whether the pattern applies primarily to classes or to objects. Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static—fixed at compile-time. Object patterns deal with object relationships, which can be changed at run-time and are more dynamic. Almost all patterns use inheritance to some extent. Creationalclass patterns defer some part of object creation to subclasses, while Creational object patterns defer it to another object. The Structural class patterns use inheritance to compose classes, while the Structural object patterns describe ways to assemble objects. The Behavioral class patterns use inheritance to describe algorithms and flow of control, whereas the Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone.Some patterns are often used together. For example, Composite is often used with Iterator or Visitor. Some patterns are alternatives: Prototype is often an alternative to Abstract Factory. Some patterns result in similar designs even though the patterns have different intents. For example, the structure diagrams of Composite and Decorator are similar.Design Patterns include Singleton, Adapter, Façade, Composite, Factory and more … a total of 23 are cataloged in the GOF book.Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John M. (1994-10-31). Design Patterns: Elements of Reusable Object-Oriented Software (Kindle Locations 548-551). Addison-Wesley Professional. Kindle Edition.
- Application Architecture patterns are patterns for creating system level architecture. Client/Server application architecture pattern segregates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures.Examples of the client/server architectural style include Web browser—based programs running on the Internet or an intranet; Microsoft Windows® operating system—based applications that access networked data services; applications that access remote data stores (such as e-mail readers, FTP clients, and database query tools); and tools and utilities that manipulate remote systems (such as system management tools and network monitoring tools).Layered application architecture pattern partitions the concerns of the application into stacked groups (layers).Examples of layered applications include line-of-business (LOB) applications such as accounting and customer-management systems; enterprise Web-based applications and Web sites, and enterprise desktop or smart clients with centralized application servers for business logic.Multi-tier application architecturepatternprovides a model for developers to create a flexible and reusable application. By breaking up an application into tiers, developers only have to modify or add a specific layer, rather than have to rewrite the entire application over. There should be a presentation tier, a business or data access tier, and a data tier.An example of the N-tier/3-tier architectural style is a typical financial Web application where security is important. The business layer must be deployed behind a firewall, which forces the deployment of the presentation layer on a separate tier in the perimeter network. Another example is a typical rich client connected application, where the presentation layer is deployed on client machines and the business layer and data access layer are deployed on one or more server tiers.Service Oriented architecture pattern refers to applications that expose and consume functionality as a service using contracts and messages.Common examples of service-oriented applications include sharing information, handling multistep processes such as reservation systems and online stores, exposing industry specific data or services over an extranet, and creating mashups that combine information from multiple sources.Message Bus architecture pattern prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other.Consider the message bus architectural style if you have existing applications that interoperate with each other to perform tasks, or you want to combine multiple tasks into a single operation. This style is also appropriate if you are implementing a task that requires interaction with external applications, or applications hosted in different environments.http://msdn.microsoft.com/en-us/library/ee658117.aspx#KeyArchitectureStyles
- Yes, there are even patterns for working with databases.Table design patterns describe the kinds of things that you store in tables. Each pattern is characterized by the relative number of columns and rows, and whether it stores either information about permanent things or interactions between permanent things.Reference.Use single-column character primary key. Small Master.Use single-column character primary key. Large Master. Use integer auto-assigned primary key.Transactions. Describes interactions between things, like a customer purchase of an item or a student's enrollment in a class. Use integer auto-assigned primary key.Cross Reference.Describes relationships between master entries, such as an item's price group or a teacher's department. Use multi-column primary keys. Database normalization patterns eliminate unnecessary redundancies of data in a database. This is where you have normalization patterns like First normal form, Second normal form, Third normal form and on and on we go.Third normal form, or Business normal form, seems to be the most popular. It says you should create a table for:Every role a Business Partner (BP) (e.g., customer) can playEvery kind of relationship BP (e.g., contacts) can have with each otherEvery kind of relationship a BP (e.g., invoices, sales orders) can have with an account or other “thing”
- Examples of code refactoring patterns would include: Extract Method, Extract Interface, Rename Method, Replace Inheritance with Delegation.http://www.amazon.com/Refactoring-Patterns-Joshua-Kerievsky/dp/0321213351/ref=sr_1_1?s=books&ie=UTF8&qid=1319825699&sr=1-1Examples of database refactoring patterns would include: Drop Column, Introduce Soft Delete, or Replace View with Method(s). http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1319825677&sr=8-1
- ApplicationPresentationpatternshelp to remove any kind of cluttered code in user interfaces like manipulation of user interface control and maintaining state. Thus keeping your user interface code cleaner and better to maintain.MVC, MVP and MVVM are design patterns which come under the presentation pattern category.MVC (Model view controller) pattern divides the architecture into 3 parts model, view and controller. The first request comes to the controller and the controller then decides which view to be displayed and ties up the model with the view accordingly. MVC is suitable for Web projects.MVP (Model view presenter) pattern has similar goals as MVC i.e.separating the user interfacefrom the model. It does the same by using a presenter class. The user interface talks via an interface to the presenter class and the presenter class talks with the model. MVP is suitable for Windows Form or Web Forms projects.MVVM (Model view view model) pattern focusesof removing of user interfacecluttered code. It does the same by using an extra class called as viewmodel. MVVM is mostly suitable for Silverlight and WPF projects because of the rich bindings provided by the technologies.http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DPR305
- User interface design patterns address the problems of how to design interactive software programs and enhance the overall user experience.TheLazy Registration patternis meant to allow users to use your system and take action before registering. If satisfied with your service so far, users will regard this quick act of registration as just another small step in the entire process and not an obligation. The shopping cart is a good example of this pattern: users can browse and choose products and only have to register when they proceed to check out.TheProgressive Disclosure pattern is used to show only the information or features relevant to the user’s current activity and to delay other information until it is requested. By hiding more complex or infrequently used features, you de-clutter the user interface; by revealing them only as they are needed, you help users perform a complex, multi-step process on a single page.The Forgiving Format pattern significantly simplifies user interfaces. However, it may require a lot of work from back-end developers. The more options users have, the more difficult parsing becomes.The Clear Primary Actions pattern helps user quickly identify frequent activities. Simple Web forms often allow just one action (“Submit,” “Save” or “Send”). The user knows exactly what their final action in filling out the form will be, because they have only one option. However, users may sometimes be faced with several options and have to distinguish between primary and secondary actions.
- We finished up looking at some, and I stress some of the pattern categories we as developers can leverage. I would now like to chase a big fat rabbit. We looked at some possible disadvantages of patterns … but let’s take a quick look at anti-patterns.An anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.The term was coined in 1995 by Andrew Koenig, inspired by Gang of Four's book Design Patterns, which developed the concept of design patterns in the software field. The term was widely popularized three years later by the book Anti-patterns, which extended the use of the term beyond the field of software design and into general social interaction. Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible. Sometimes called pitfalls or dark patterns, this informal use of the term has come to refer to classes of commonly reinvented bad solutions to problems.
- An anti-pattern tells you why a bad solution is attractive. Let’s face it, no one would choose a bad solution if there wasn’t something about it that seemed attractive up front. One of the biggest jobs of the anti-pattern is to alert you to the seductive aspect of the solution.An anti-pattern tells you why that solution in the long term is bad. In order to understand why it’s an anti-pattern, you’ve got to understand how it’s going to have a negative effect down the road. The anti-pattern describes where you’ll get into trouble using the solution.An anti-pattern suggests other patterns that are applicable which may provide good solutions. To be truly helpful an anti-pattern needs to point you in the right direction; it should suggest other possibilities that may lead to good solutions.Sometimes, developers will refer to anti-patterns as “code smells.” The term appears to have been coined by Kent Beck on WardsWiki in the late 1990s. Usage of the term increased after it was featured in Refactoring. Improving the Design of Existing Code.
- Death March. Everyone knows that the project is going to be a disaster – except the CEO – so the truth is hidden to prevent immediate cancellation of the project - (although the CEO often knows and does it anyway to maximize profit). However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang"). Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline.Gold Plating. Refers to continuing to work on a project or task well past the point where the extra effort is worth the value it adds (if any). After having met the requirements, the developer works on further enhancing the product, thinking the customer would be delighted to see additional or more polished features, rather than what was asked for or expected. The customer might be disappointed in the results, and the extra effort by the developer might be futile.God Object. Concentrating too many functions in a single part of the design.Most of a program's overall functionality is coded into a single "all-knowing" object, which maintains most of the information about the entire program and provides most of the methods for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes God-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the God object for most of their information and interaction. Since the God object is referenced by so much of the other code, maintenance becomes more difficult than it would in a more evenly divided programming design.A God object is the object-oriented analogue of failing to use subroutines in procedural programming languages, or of using far too many global variables to store state information.Object orgy. Failing to properly encapsulate objects permitting unrestricted access to their internals.Reinventing the wheel. Failing to adopt an existing, adequate solution.
- Talk with your team, read books, look for patterns in code reviews. There are plenty of resources out there! I like what Joshua Kerievsky said in his book, “Refactoring to Patterns”.“My preferred way to gain knowledge of patterns is to choose great pattern books to study and then study one pattern a week in a study group … Folks in these study groups love to become better software designers. Meeting and discussing important design ideas each week is a great way to do that.”“If you think there are already too many patterns books to study, don’t worry. Follow the advice of Jerry Weinberg. I once asked him how he keeps up with all the books that come out. He said, “Easy – I only read the great ones.”
- I remember my German teacher in high school forcing us to speak to each other in German … I hated it! It sounded so forced and I thought I sounded so stupid! Surprise! Surprise! The more I did it, the easier it was to do and the better I became at speaking German. The same thing applies to patterns. When you are making design decisions with your team, for yourself and each other to speak, where it is applicable, in terms of design patterns. This will get you and your team more familiar with talking about them, which will lead to learning opportunities, which will lead to awesome design, and ultimately awesome software!
- Just do it! Knowledge of patterns is a good start, but remember patterns capture wisdom, and wisdom is knowledge applied. It does no good to have all this knowledge of patterns and not apply them to all facets of the software development process.Start refactoring to patterns … which is what you really are doing when you refactor.
- Something to keep in mind. Remember the best designs will use multiple design patterns that dovetail and intertwine to produce a greater whole.
- Patterns that your company frequently makes use of, design patterns, user interface patterns, database patterns and more. I don’t really like the term “standard”, I prefer instead to use patterns. “Standard” makes something sound mandated, “Pattern” makes something sound like silly not to use.The generally accepted format for writing patterns is:The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two. Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction. Having a vocabulary for patterns lets us talk about them with our colleagues, in our documentation, and even to ourselves. It makes it easier to think about designs and to communicate them and their trade-offs to others. Finding good names has been one of the hardest parts of developing our catalog.The problem describes when to apply the pattern. It explains the problem and its context. It might describe specific design problems such as how to represent algorithms as objects. It might describe class or object structures that are symptomatic of an inflexible design. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution doesn’t describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it. The consequences are the results and trade-offs of applying the pattern. Though consequences are often unvoiced when we describe design decisions, they are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern. The consequences for software often concern space and time trade-offs. They may address language and implementation issues as well. Since reuse is often a factor in object-oriented design, the consequences of a pattern include its impact on a system’s flexibility, extensibility, or portability. Listing these consequences explicitly helps you understand and evaluate them.We use CSLA, by Rockford Lhotka, as our framework for developing business objects for our applications. Within the context of CSLA there are so many different stereotypes of business objects, EditableRoot, EditableChild, ReadOnlyRoot, EditableCollection and so on. Within the business world there are so many ways to use these stereotypes to model business entities. My team is very familiar with selecting the correct stereotype to model familiar business entities, like customers and contacts. New developers always seem to struggle with creating Root objects with a collection Child objects. We all struggle with creating objects for hierarchical data or composite data. We’ve done it before, but we always seem to forget what projects we have done it in!Just this week it dawned on me, why don’t we create a pattern library for modeling business objects using CSLA stereotypes. We can give each a name, a description of the problem being solved, the solution, with plenty of working examples, and consequences.This will be a great catalog for new developers and forgetful ones to be able to browse.
- Feel free to email with any questions that you may have! If you are leaving here today ready to start exploring the world of patterns and having learned something new … then I accomplished my goal! Thank you for your time. Now go work some small miracles!