CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 A proposition behind design patterns is that quality of software systems can be measured objectively. What is present in a good quality design that is not present in a poor quality design? What is present in a poor quality design that is not present in a good quality design? Think about architecture. What makes a good architectural design? Is it subjective or objective? Christopher Alexander studied architecture and noted that there are commonalities in all good designs. Two structures can even be of the same type, both be of high quality, but both serve different purposes, i.e. a porch.

CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 Alexander realized you had to look at comparing structures with the same purpose. i.e. problem of demarking an entryway: Structures look different, but solve the same problem. This lead to the concept of a pattern.

CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 Alexander described a pattern by indicating four items: The name of the pattern The name of the pattern The purpose of the pattern The purpose of the pattern How we could accomplish this How we could accomplish this The constraints and forces we have to consider to accomplish it The constraints and forces we have to consider to accomplish it He also noted: Patterns exist for almost any design problem Patterns exist for almost any design problem Patterns may be combined to solve complex patterns Patterns may be combined to solve complex patterns

CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 What do architectural patterns have to do with software design? Ask yourself two questions: Do problems exist in software that occur over and over again that could be solved in somewhat the same manner? Do problems exist in software that occur over and over again that could be solved in somewhat the same manner? Is it possible to design software in terms of patterns, creating specific solutions based on these patterns? Is it possible to design software in terms of patterns, creating specific solutions based on these patterns? It should be obvious that the answer is yes. I know even before I studied design patterns, it was always easier to build an app from an existing one. Once I figured out things like data connectivity and the details of a development environment, I saw that many programs had to do the same thing. i.e., log in, validate the user, connect to a data source. Almost every program I wrote started the same way. Sounds like a pattern to me.

CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 When we study software design patterns, we will describe them using the following structure: Name: All patterns will have a unique name that identifies them. Intent: The purpose of the pattern. Problem: The problem that the pattern is trying to solve. Solution: How the pattern provides a solution to the problem in the context in which it shows up. Participants and collaborators: The entities involved in the pattern. Consequences: The consequences of using the pattern. Implementation: How the pattern is implemented. Generic Structure: A standard diagram that shows a typical structure for the pattern By using patterns we will be able to reuse our solutions and establish a common terminology.

CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 Here’s a great example of how to discuss a problem at a higher level of abstraction. Imagine two carpenters discuss how to build a drawer for a cabinet. Imagine you are one of them. How would you relay the information about how to build the joint for the drawer? You could describe it as: Well I think we should make the joint by cutting straight up and down into the wood and the cut back up 45 degrees… then going straight back down, and the back the other way 45 degrees, and then going straight back down … Do you know what this is describing? Some of you might know it as a dove tail joint. If that were said right at the beginning, it would have been a lot clearer. This is a perfect example of diving right into the details and not discussing it at the proper level.

CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 Is that the right joint to use thou? Described that way you might never ask. A better start is to ask should be use a dovetail joint or a miter joint? Miter joint

CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 Which joint is better? Depends on the goal. A Miter: Is simpler Is simpler Is Lightweight Is Lightweight Is inconspicuous Is inconspicuous A dovetail is: More complex More complex Stronger and resistant to temperature and humidity Stronger and resistant to temperature and humidity more aesthetically pleasing more aesthetically pleasing independent of a fastening system independent of a fastening system So the question should have been worded differently. 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 as least until the check clears?

CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 Patterns help us communicate better. They help us see the forest and the trees. They improve the modifiability and maintainability of code. Think back to the CAD example. It’s not that the first solution was hard to implement. The pain came when you had to modify it and add another CAD system. Good Rules for OOD are: Deign to Interfaces Deign to Interfaces Favor aggregation over inheritance Favor aggregation over inheritance Find what varies and encapsulate it Find what varies and encapsulate it We will revisit these three rules over and over again. I am especially fond of the last one.

CS 350 – Software Design An Introduction to Design Patterns – Chapter 5 When we study software design patterns, we will describe them using the following structure: Name: All patterns will have a unique name that identifies them. Intent: The purpose of the pattern. Problem: The problem that the pattern is trying to solve. Solution: How the pattern provides a solution to the problem in the context in which it shows up. Participants and collaborators: The entities involved in the pattern. Consequences: The consequences of using the pattern. Implementation: How the pattern is implemented. Generic Structure: A standard diagram that shows a typical structure for the pattern