design_patterns_II - From Patterns to Pattern Languages...

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

View Full Document Right Arrow Icon
CSE 332: Design Patterns From Patterns to Pattern Languages Last time we looked at pattern-oriented software design We looked for key challenges at each step of the design process We matched each challenge with a suitable design pattern The pattern let us overcome that challenge and move on to the next one This lecture will take that same approach New focus: additional design issues related to multi-agent interactions A fresh look at the Singleton pattern New design patterns (from Gamma et al.) We’ll talk about how sets of patterns are combined/navigated A look back at the design patterns we’ve used this week
Background image of page 1

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

View Full DocumentRight Arrow Icon
CSE 332: Design Patterns Developing (and Using) a 2 nd Pattern Language We’ll further extend our design from last time (Part I) Idea: add “agents” who trade stocks and bonds Design goals Allow multiple agents, each with their own portfolio, who can trade directly Allow agents to enter and leave the group of agents currently trading • Add a market to mediate event triggered open trading of securities We’ll see again how key patterns drive the design (Part II) Singleton variant: provides key-discriminated access to a single instance Prototype: a type can produce a duplicate instance of the same type Memento: package up object state without violating encapsulation Command: encapsulates a future function call inside a functor Observer: tell registered observers when state changes We’ll see how we’ve evolved another pattern language (Part III) Can be reused in different design settings where the same issues arise I.e., many with interacting agents (interestingly, even distributed ones)
Background image of page 2
CSE 332: Design Patterns Part I: Design Exercise Outline Idea: add “agents” who trade stocks and bonds We define an “agent” as a potentially independently acting software entity (software engineering notion rather than AI) Shifts the focus from a single portfolio to the group of agents Design goals Allow multiple agents, each with their own portfolio Support (closed agent-to-agent) cross trading of securities Need to consider all of the common data (shares, current and projected values, name) when testing securities for equivalence Assume trades are for all (or none) of the shares in a security object Add a market to mediate (event triggered) open trading Allow agents to enter and leave the group that’s trading I.e., they can save and restore their portfolio and their reserve
Background image of page 3

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

View Full DocumentRight Arrow Icon
CSE 332: Design Patterns Part II: Applying Patterns to the Design First challenge: each agent needs their own portfolio Don’t let an agent access another’s portfolio (security) However, want to keep previous benefits of using singleton Reconsider how we have applied the Singleton pattern Need to maintain a separate portfolio instance per agent First access by an agent still creates their specific portfolio
Background image of page 4
Image of page 5
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 03/03/2010 for the course CSE 241 taught by Professor Cse241 during the Spring '08 term at Washington University in St. Louis.

Page1 / 18

design_patterns_II - From Patterns to Pattern Languages...

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

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