The Concept "Patterns are a recent software engineering problem-solving discipline that emerged from the object-oriented community" "Form of software engineering problem-solving documentation " "A pattern language defines a collection of patterns and the rules to combine them into an architectural style. Pattern languages describe software frameworks or families of related systems. " "Recurring solutions to common problems of design " "A pattern is not an implementation. It describes when, why, and how to go about creating an implementation or other engineering product. " "Problem/Solution pairs in a Context" "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”

Pattern Elements Name A meaningful "conceptual handle" for discussion Context Tells how the problem occurs / when the solution works Delineation of situations under which the pattern applies. Often includes background, discussions of why this pattern exists, and evidence for generality. Problem A description of the relevant forces and constraints, and how they interact. In many cases, entries focus almost entirely on problem constraints that a reader has probably never thought about. Design and construction issues sometimes themselves form parts of the constraints. Forces Trade-offs, goals+constraints, motivating factors/concerns Tells why the problem is difficult Solution Tells how to generate the solution The solution structure, its participants & collaborations Examples (optional) Resulting Context (optional) Describes the end result, benefits and consequences Shows how the forces were balanced/traded-off Tells how the solution works out Rationale (optional) Underlying principles/heuristics justifying the solution Tells underpinnings of why the solution works out Related Patterns Patterns which are similar, or which may precede/follow this one Known Uses 3 or more independent instances of "real world" success

Q: What is the relationship between frameworks and design patterns? A: Frameworks are software whereas patterns are knowledge or information about software. Patterns can be used to describe frameworks and some part or aspect of a framework can be a realization of a pattern. Patterns support reuse of software architecture and design they capture static and dynamic structures and collaborations of sucessful solutions to problem that arise when building applications in a particular domain Frameworks support reuse of detailed design and code is an integrated set of components that collaborate to provide a reusable architecture for a family of related applications

Why Patterns? Solve "real world" problems Capture domain expertise Document design decisions and rationale Reuse wisdom and experience of master practitioners Convey expert insight to novices Form a shared vocabulary for problem-solving discussion Show more than just the solution: context (when and where) forces (trade-off alternatives, misfits, goals+constraints) resolution (how and why the solution balances the forces)

Examples Silly example - non programming Silly example 2 Example built-into Java Singleton Example in C#

The Problem Writing good patterns is very difficult. Patterns should not only provide facts (like a reference manual or user's guide), but should also tell a story which captures the experience they are trying to convey. A pattern should help its users to: comprehend existing systems; customize systems to fit user needs; and construct new systems. The process of looking for patterns to document is called pattern mining (or sometimes reverse-architecting). How do you know a pattern when you come across one? The answer is you don't always know. You may jot down the beginnings of some things you think are patterns, but it may turn out that they aren't patterns at all, or they are only pieces of patterns, or simply good principles or rules of thumb that may form part of the rationale of a particular pattern. It is important to remember that a solution in which no forces are present is not a pattern.

Types of Patterns Creational Patterns deals with the creation of objects The Singleton Pattern: makes sure that at any point of time, there is one and only one instance of a class present and also provides a global point of access to the object. Factory Design Pattern: delegates the work of object creation to derived classes of the interface Abstract Factory Pattern: is a type of design pattern that is used for creating groups of dependant instances of classes without specifying their concrete classes Builder Design Pattern: separates the creation of an instance of a class from its representation so that the same creation pattern can be used for creating different representations of the object. Prototype Design Pattern: creates new instances of classes by copying its prototype Structural Patterns concerned with how classes and objects are composed to form larger structures. Adapter Pattern: "Convert the interface of a class into another interface clients expect." Also known as a "Wrapper." The structure of a Class Adapter uses multiple inheritance to adapt one interface to another. Bridge Pattern: "Decouples an abstraction from its implementation so that the two can vary independently." Composite Pattern: There is often a problem in software design where you need to create a hierarchy of objects and also need to treat each element of the hierarchy uniformly. The Composite structural design pattern accomplishes this by defining primitive and composite objects. Primitives can be composed into more complex systems, which can in turn be composed, and so on. Decorator Pattern: Sometimes you need to attach greater responsibility to an object dynamically. This is known as the Decorator structural design pattern. Behavioral Patterns concern communication between classes and objects. Template Method Pattern: allows software to define a skeleton of an algorithm in an operation, deferring some steps to subclasses. Stratgey Pattern: define[s] a family of algorithms, encapsulate[s] each one, and make[s] them interchangeable.