DesignPatterns - Background1 Software Design Patterns...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
12/3/09 1 1 Software Design Patterns Michael L. Collard, Ph.D. Department of Computer Science The University of Akron 2 Background 1 • Search for recurring successful designs – emergent designs from practice (via trial and error) • Supporting higher levels of reuse (i.e., reuse of designs) is quite challenging • Described in Gamma, Helm, Johnson, Vlissides 1995 (i.e., “gang of 4 book”) • Based on work by Christopher Alexander (an Architect) on building homes, buildings and towns. 3 Background 2 • Design patterns represent solutions to problems that arise when developing software within a particular context. E.g., problem/solution pairs within a given context • Describes recurring design structures • Describes the context of usage 4 Background 3 • Patterns capture the static and dynamic structure and collaboration among key participants in software designs • Especially good for describing how and why to resolve non-functional issues • Patterns facilitate reuse of successful software architectures and designs. 5 Origins of Design Patterns “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 in the same way twice” Christopher Alexander, A Pattern Language, 1977 Context: City Planning and Building architectures 6 Elements of Design Patterns • Design patterns have four essential elements: – Pattern name – Problem – Solution – Consequences
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
12/3/09 2 7 Pattern: Name • A handle used to describe: – a design problem – its solutions – its consequences • Increases design vocabulary • Makes it possible to design at a higher level of abstraction • Enhances communication “The hardest part of programming is coming up with good variable [function, and type] names.” 8 Pattern: Problem • Describes when to apply the pattern • Explains the problem and its context • May describe specific design problems and/or object structures • May contain a list of preconditions that must be met before it makes sense to apply the pattern 9 Pattern: Solution • Describes the elements that make up the – design – relationships – responsibilities – collaborations • Does not describe specific concrete implementation • Abstract description of design problems and how the pattern solves it 10 Pattern: Consequences • Results and trade-offs of applying the pattern • Critical for: – evaluating design alternatives – understanding costs – understanding benefits of applying the pattern • Includes the impacts of a pattern on a system’s: – flexibility – extensibility – portability 11 Design Patterns are NOT • Designs that can be encoded in classes and reused as is (i.e., linked lists, hash tables) • Complex domain-specific designs (for an entire application or subsystem) • They are: – “Descriptions of communicating objects and classes
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

Page1 / 7

DesignPatterns - Background1 Software Design Patterns...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online