Docsity
Log inSign up
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Design Patterns - Software Architecture and Design - Notes | CS 6310, Study notes of Computer Science

Georgia Institute of Technology - Main CampusComputer Science

Material Type: Notes; Class: Software Arch & Design; Subject: Computer Science; University: Georgia Institute of Technology-Main Campus; Term: Unknown 2009;

Typology: Study notes

Pre 2010

Uploaded on 08/05/2009

koofers-user-1qw
koofers-user-1qw 🇺🇸

10 documents

1 / 61

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Design Patterns
• A design pattern is a solution to a problem in a
context
– descriptions of communicating objects and classes that are
customized to solve a general design problem in a particular
context -- Gamma et al.
• Means of capturing and reusing design knowledge
• Besides a broad collection of books on design
patterns there are also books on analysis and
reengineering patterns, as well as programming
language-specific pattern books and even a book on
anti-patterns
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d

Partial preview of the text

Download Design Patterns - Software Architecture and Design - Notes | CS 6310 and more Study notes Computer Science in PDF only on Docsity!

Design Patterns

  • A design pattern is a solution to a problem in a context - descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context -- Gamma et al.
  • Means of capturing and reusing design knowledge
  • Besides a broad collection of books on design patterns there are also books on analysis and reengineering patterns, as well as programming language-specific pattern books and even a book on anti-patterns

History

  • The concept of patterns derives from building architecture
    • Christopher Alexander et al. wrote the book A Pattern Language in 1977 that described prototypical ways in which building and their rooms are used
  • The seminal book on software design patterns (sometimes called the Gang of Four book) is Gamma, Helm, Johnson, and Vlissides. Design Patterns. Addison Wesley, 1995.
  • Other information on design patterns, including a catalog, can be found at http://hillside.net/patterns

Applicability

• Use the Mediator pattern in the following

situations

  • Object interactions are well-defined (statically

understood) but complex

  • Embedding behavior in objects reduces

reusability

  • Behavioral customization should be localized
  • Where you want to dynamically alter the

interactions among related components

Mediator Static Structure

Mediator createColleagues() updateColleagueStates() ConcreteMediator changed() Colleague getData() ConcreteColleague setData() ConcreteColleague mediator

More Mediator

  • Participants:
    • Mediator: defines collaboration interface
    • ConcreteMediator: implements dependencies among Colleagues; knows of specific Colleagues
    • Colleague: knows of Mediator but not other Colleagues
  • Collaborations
    • Colleagues communicate with Mediator
    • Mediator routes requests

Consequences

  • Decouples Colleagues
    • Supports Colleague reuse
  • Simplifies protocols
    • Communication is now just to and from Mediator
  • Centralizes and abstracts control
  • Intentionality
    • If collaboration is for the purpose of invariant maintenance, there is a single place to look to ensure compliance
  • Limits subclassing to Mediator when

customizing collaboration

Format For Patterns

  • Name: captures the concept in a word or phrase
  • Category: creational, structural, behavioral
  • Intent: design issue or problem addressed
  • Also known as: other names for
  • Motivating scenario: illustrates the design

problem being solved

  • Applicability/context: general description of the

situations where the pattern applies

  • Structure: static class model diagram
  • Participants: description of each of the classes

involved

Format - 2

• Collaborations: event trace; message

sequence chart; collaboration diagram

• Consequences: tradeoffs; what varies

• Implementation strategy: in various

languages; pitfalls, hints, techniques

• Sample code

• Known uses: in existing systems

• Related patterns: often used together

Creational Patterns

  • Abstract Factory: create families of objects without specifying concrete classes - UI toolkit variants with different looks and feels - Application itself does not know about look and feel
  • Builder: separate construction of a complex object from its representation to allow representation to vary
  • Factory Method: let subclass decide which class to instantiate - Framework merely asks for creation; specific creation is done by concrete factory
  • Prototype: use a prototypical instance, rather than a class, to guide construction of an object
  • Singleton: ensure only one instance of a class is created

Creational Pattern Variation

Design Pattern Aspect(s) That Can Vary

Abstract

Factory

families of product objects

Builder

how a composite object gets

created

Factory Method

subclass of class that is

instantiated

Prototype

class of object that is

instantiated

Singleton the sole instance of a class

Structural Pattern Variation

Design Pattern Aspect(s) That Can Vary Adapter interface to an object Bridge implementation of an object Composite structure and composition of an object Decorator responsibilities of an object Façade interface to a subsystem Flyweight storage costs of objects Proxy how an object is accessed; its location

Behavioral Patterns

  • Chain of Responsibility: separate request from handler; allow multiple handlers
  • Command: turn a request into an object; logging; undo
  • Interpreter: represent a grammar and interpret its instances
  • Iterator / Enumeration: access elements of a collection without exposing the underlying representation
  • Mediator: encapsulate object interactions
  • Memento: capture object's internal state for later restore

Behavioral Pattern Variation - 1

Design Pattern Aspect(s) That Can Vary Chain of Responsibility providers of a service Command when and how a request is fulfilled Interpreter grammar and interpretation of a language Iterator how an aggregate's elements are accessed, traversed Mediator how and which objects interact with each other

Behavioral Pattern Variation - 2

Design Pattern Aspect(s) That Can Vary Memento what private information is stored outside an object, and when Observer objects that depend on a given object; how the dependent objects stay up to date State states of an object Strategy an algorithm Template Method steps of an algorithm Visitor operations that can be applied to object(s) without changing their class(es)