Design Reuse Architectural Styles Frameworks and Design Patterns

Design Reuse – Architectural Styles, Frameworks and Design Patterns Mechanisms for improving software reuse, design and maintenance

Menu �What are Architectural Styles? �What are Frameworks? �What are Design Patterns? �Example Design Patterns �Design Patterns in Smalltalk Fall 2004 Copyright 2000, Georgia Tech 2

A Hierarchy of Blueprints �Architectural Styles �Frameworks �Design Patterns �Language Idioms Fall 2004 Copyright 2000, Georgia Tech 3

Architecture �A description of a system through its major components, the relationships between those components and between the external environment, and the properties of those components. �Typically have multiple views: Logical, Process, Module, and Physical. �Highest level organization of system Fall 2004 Copyright 2000, Georgia Tech 4

Architecture Styles �Standard components �Standard defined relationships between components �Standard configurations Fall 2004 Copyright 2000, Georgia Tech 5

Pipe-and-Filter F 1 F 2 F 3 Good for batch processing No feedback mechanisms Flexible configurations Think Unix command line Java Image. Producer-Consumer Fall 2004 Copyright 2000, Georgia Tech 6

Blackboard C 1 C 2 C 3 Blackboard C 4 C 5 Shared Memory - same except not active Used in AI-Robotics, Distributed Systems Fall 2004 Copyright 2000, Georgia Tech 7

Main Program-Subroutine Main M 1. 1 Fall 2004 M 2 M 3 M 4 Typical of procedural languages Verb-oriented Design Generally has a central control Copyright 2000, Georgia Tech 8

Layered Layer 3 Layer 2 Layer 1 Fall 2004 Components provide service to layer above Use service of layers below Do not jump layers Used for portability across HW: HW dependent layer HW independent layer Used to provide abstraction of complex services (“Middleware”) Copyright 2000, Georgia Tech 9

N-Tiered Server Tries to offload server work by having intermediate processing done. Business Logic Typically separate business logic from UI on client and DB on server. Client Fall 2004 Copyright 2000, Georgia Tech 10

Implicit Invocation (Event. Driven) C 1 C 2 Software Event Bus C 3 C 4 Used a lot in GUI frameworks. Components fire events and register for events they need to know about Fall 2004 Copyright 2000, Georgia Tech 11

Frameworks �We are going to save frameworks for a later class �We will discuss framework design and how it differs from application’s design �Let’s go on to design patterns… Fall 2004 Copyright 2000, Georgia Tech 12

References �Design Patterns: Elements of Reusable Object-Oriented Software �“Gang of Four”: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison. Wesley, 1995) �Best-selling Computer Science book ever �The Design Patterns Smalltalk Companion �Sherman R. Alpert, Kyle Brown, Bobby Woolf (Addison-Wesley, 1998) Fall 2004 Copyright 2000, Georgia Tech 13

What are Design Patterns? �Codified standard practices of expert designers �“Recorded experience in designing object-oriented software” – Gang of Four �“A reusable implementation model or architecture that can be applied to solve a particular recurring class of problem” — Alpert et al. �Definitely not innovative, unique approaches �Instead, tried-and-true, worth reusing practices �Practices that address common design problems �Practices that help improve reusability Fall 2004 Copyright 2000, Georgia Tech 14

Pieces of a Design Pattern �Pattern Name �Problem: When to apply the pattern �Solution: The elements that make up the design, their relationships, responsibilities, collaborators. �Not a concrete design or implementation, but a template �Consequences: Results and tradeoffs of the pattern Fall 2004 Copyright 2000, Georgia Tech 15

Your first pattern: Observer � “Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. ” – G 4 � Participants: � (Abstract) Subjects: Know observers and can attach/detach them � (Abstract) Observers: Can update() when notified of changes � Concrete. Subjects maintain state for subject � Concrete. Observers maintain a relationship with the Concrete. Subject Fall 2004 Copyright 2000, Georgia Tech 16

Observer Structure Subject * dependents add. Dependent: an. Observer remove. Dependent: an. Observer changed: a. Symbol Observer update: a. Symbol dependents do: [ : observer | observer update: a. Symbol] Hmm, that looks vaguely familiar Concrete. Subject subject. State 1 subject. State: an. Object Fall 2004 Concrete. Observer observer. State update: a. Symbol Copyright 2000, Georgia Tech 17

An instantiation of Observer: MVC! �You’ve seen this before! �All the issues are the same! �Subjects are Models �Your application specific Models are Concrete. Subjects �User Interface Components (Views) are Observers �The specific UI components you use in your application are Concrete. Observers �Observer is also the pattern being used in Java’s Listener class in Swing Fall 2004 Copyright 2000, Georgia Tech 18

Using Observer �Use the observer pattern when… �A change to one object requires updating many �When an object should be able to notify other objects without making assumptions about who those objects are (loosely coupled) �When an abstraction has two aspects, one dependent on the other, but you want to vary and reuse them independently �Note: These are not just about UI! Fall 2004 Copyright 2000, Georgia Tech 19

Consequences of Observer �Abstract coupling between Subject and Observer �Could be an issue in large, multi-layered system �Requires support for broadcast communication �Freedom to add/remove observers anytime �Can be computationally expensive �Unexpected updates �Observer and subjects are blind to the costs of sending each other messages (Cascading notifications) Fall 2004 Copyright 2000, Georgia Tech 20

Implementation Issues �How to track observers? (global vs local table) �Observing more than one subject is complex �Who triggered the update? �Beware that subject state is updated before notifying �Avoid observer-specific update protocols: Push vs. Pull �Specifying aspects of interest explicitly �Encapsulating complex update semantics Fall 2004 Copyright 2000, Georgia Tech 21

Patterns in Architecture �“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” — Christopher Alexander �Alexander is an Architect who has been collecting patterns in Architecture for years �Standard ways of solving problems Fall 2004 Copyright 2000, Georgia Tech 22

Patterns in Cognitive Science �Experts do think in pattern-like elements �Sometimes called “chunks” or “plans” �Shown by Herb Simon for Chess �Shown by Elliot Soloway for Software �Can we teach these patterns to people to make them better designers? Fall 2004 Copyright 2000, Georgia Tech 23

Describing Design Patterns �Name and classification �Intent �Also Known As (AKA) �Motivation �Applicability �Structure �Participants Fall 2004 �Collaborations �Consequences �Implementation issues �Sample code �Known uses �Related Patterns Copyright 2000, Georgia Tech 24

Some Classifications of Design Patterns � Fundamental: Key OO concepts (like delegation) � Creational: Make a system independent of how its objects are created, composed, and represented � Structural: How classes and objects are composed to form larger structures � Behavioral: The patterns of communication between objects � Partitioning: How systems are decomposed � Concurrency: How multiple threads of execution interoperate Fall 2004 Copyright 2000, Georgia Tech 25

Patterns for Reuse �Patterns build heavily on composition and delegation �Inheritance is a “white box” form of reuse �Its faster and straightforward �But requires a lot of knowledge of superclass �Composition and delegation is “black box” reuse �Keeps details hidden away �In general, program to an interface, not an implementation Fall 2004 Copyright 2000, Georgia Tech 26

Design Patterns Solve Common Reuse Problems �Example 1: Creating an object by specifying a class explicitly �If you specify a class name when you create an object, you’re committing to a particular implementation (that class) as opposed to a particular interface (e. g. , features that you need) �To avoid it, create objects indirectly �Solutions are Creational patterns Fall 2004 Copyright 2000, Georgia Tech 27

Solution to #1: Factory Method Pattern �Intent: Define an interface for creating an object, but let subclasses decide which class to instantiate �Have a factory method (that, perhaps, take a parameter that tells you the kind of object you want) decide which object to give you �Example: Application suite that can create Word Processing, Spreadsheet, Picture documents Fall 2004 Copyright 2000, Georgia Tech 28

Factory Method Applicability �Use it when… �A class can’t anticipate the class of objects it must create �A class wants its subclasses to specify the objects it creates �You want to localize the knowledge of which specific class gets created for a specific purpose Fall 2004 Copyright 2000, Georgia Tech 29

Factory Method Participants �Product: Defines the interface of objects that the factory method creates (e. g. , all documents can open, close, save, etc. ) �Concrete. Product: Implements the Product interface (e. g. , a WP document) �Creator: Defines the Factory Method �Concrete. Creator: Overrides the Factory Method to create an instance of Concrete. Product Fall 2004 Copyright 2000, Georgia Tech 30

Factory Method Structure Product Creator Factory. Method: some. Spec Concrete. Creator Concrete. Product Factory. Method Fall 2004 Copyright 2000, Georgia Tech 31

Consequences of Factory Method �Disadvantage: You have to have a Concrete. Creator class for every product you create �You need to provide hooks for subclasses �Connects parallel class hierarchies �Makes class evolution and development a little more complex Fall 2004 Copyright 2000, Georgia Tech 32

Implementing Factory Method in Smalltalk �Imagine a Car. Builder abstract class, with subclasses Ford. Builder and Toyota. Builder �Each wants to build 4 cylinder cars add. Four. Cylinder. Engine “in Car. Builder” self car add. Engine: self four. Cylinder. Engine “in Ford. Builder” ^Ford 4 Cylinder. Engine new four. Cylinder. Engine “in Toyota. Builder” ^Toyota 4 Cylinder. Engine new Fall 2004 Copyright 2000, Georgia Tech 33

Alternative Factory Method Implementation in Smalltalk �Return the class itself! add. Four. Cylinder. Engine “in Car. Builder” self car add. Engine: self four. Cylinder. Engine “in Car. Builder” ^self my. Four. Cylinder. Engine. Class new my. Four. Cylinder. Engine. Class “in Ford. Builder” ^Ford 4 Cylinder. Engine my. Four. Cylinder. Engine. Class “in Toyota. Builder” ^Toyota 4 Cylinder. Engine Fall 2004 Copyright 2000, Georgia Tech 34

Another Factory Example Encryption DESEncryption Encrypts with Socket RSAEncryption creates Encrypted. Socket Encryption. Factory Gets Encryption From: Grand, Patterns in Java Vol. 1 Factory Fall 2004 Copyright 2000, Georgia Tech 35

Smalltalk Code Factory>> create. Encryption: a. Key subclass. Responsibility Encryption. Factory>> create. Encryption: a. Key algorithm = #des if. True: [^DESEncryption with: a. Key]. a. Key algorithm = #rsa if. True: [^RSAEncryption with: a. Key]. ^Unknown. Encryption with: a. Key. Fall 2004 Copyright 2000, Georgia Tech 36

Related Pattern: Abstract Factory �Intent: Provide an interface for creating families of related or dependent objects. �In some sense, select a class which has the Factory Methods you need �In Squeak: File. Directory, External. Web. Browser, App. Registry as a generic approach Fall 2004 Copyright 2000, Georgia Tech 37

Abstract Factory Example Car. Part. Factory Car. Engine Car. Body Ford. Factory make. Body make. Engine Ford. Body Fall 2004 Toyota. Body Ford. Engine Toyota. Factory make. Body make. Engine Toyota. Engine Copyright 2000, Georgia Tech 38

Abstract Factory Code my. Factory : = self factory. “Ford. Factory or Toyota. Factory returned. ” my. Engine : = my. Factory make. Engine. my. Body : = my. Factory make. Body. Fall 2004 Copyright 2000, Georgia Tech 39

Problem #2: Platform Dependence �Redesign/reuse problem #2: Hardware/software dependence �You want to limit your dependency on platform specifics, e. g. Mac vs. MSWin �Can solve this with an Abstract Factory �Can also solve this with the behavioral pattern Bridge Fall 2004 Copyright 2000, Georgia Tech 40

Bridge Pattern �Intent: Decouple an abstraction from its implementation so that the two can vary independently �Basically, separate the interface and implementation so that the two can vary independently �Classic example: All windowing systems offer similar abstract interface / functionality, but vary in implementation / concrete interface Fall 2004 Copyright 2000, Georgia Tech 41

Bridge Pattern Example Window implementation Window. Implementation Mac. Window. Implementation Fall 2004 Copyright 2000, Georgia Tech Window. Implementation 42

Interesting Uses for Bridges �Java AWT and “peers” �IBM Smalltalk separated collections into implementations and interfaces �If a Set was small, stored in a Linear. Set. Implementation �If a Set was large, stored in a Linear. Hash. Set. Implementation �Programmer-User only saw the same Set interface— the implementation changed invisibly Fall 2004 Copyright 2000, Georgia Tech 43

When to Bridge �You want to avoid a permanent binding between an abstraction and its implementation �Both abstraction and implementation might be extensible via subclassing �Changes in implementation should not impact clients of the abstraction Fall 2004 Copyright 2000, Georgia Tech 44

Bridge Implementation Issues �What if only one implementor? �Still might be useful �In Java/C++, can avoid changing client, just re -link �Choosing the right implementation object �May have to change later, depending on size, platform, etc. �Can use a factory to choose implementation for us! Fall 2004 Copyright 2000, Georgia Tech 45

Problem #3: Dependence on Specific Operations �Reuse/Redesign Problem #3: When you specify a particular operation, you are committing to one way of satisfying a request. �If you can remain flexible with how you respond to requests, you make it easier to change, even (in C++/Java/etc. ) at run-time or compile-time �One solution design pattern: Command Fall 2004 Copyright 2000, Georgia Tech 46

Command—A Behavioral Design Pattern �Intent: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. �AKA: Action, or Transaction pattern �Sometimes, you want to ask an object to do something without knowing the actual message name or even the receiver of the message. �Do this by making the request itself be an object Fall 2004 Copyright 2000, Georgia Tech 47

Motivation for Command �An Application wants to have a Menu that sends commands to Documents like Open, Close, Paste, Copy �The Menu. Item doesn’t necessarily know which document gets the command �The Menu. Item may not even know which message the document understands �Further, the creation of an inverse (for Undo) is not the Menu’s responsibility Fall 2004 Copyright 2000, Georgia Tech 48

Motivation for Command �Need support for multi-level undo �Need a history of commands �What command was done �What data was changed �How do I undo? Fall 2004 Copyright 2000, Georgia Tech 49

Command Structure Client (Application) Invoker (Menu. Item) Command execute Receiver (Document) action receiver Concrete. Command (Paste, Open) execute receiver action Fall 2004 Copyright 2000, Georgia Tech 50

Command Participants �Command: Declares the interface for an operation �Concrete. Command: Binds a Receiver and an action �Implements Execute() (or do. It / undo. It) �Client: Creates Concrete. Command, sets its receiver �Invoker: Asks command to carry out request �Receiver: Knows how to do the operation Fall 2004 Copyright 2000, Georgia Tech 51

Use Command when you want to. . . � Parameterize objects by an action to perform (e. g. , menu. Item and push. Button both do same Command object) � Specify, queue, and execute requests at different times � Support undo or redo (put Commands in a stack or queue) � Support logging changes � Structure a system around high-level operations built on primitive operations Fall 2004 Copyright 2000, Georgia Tech 52

Command Consequences �Command decouples the object invoking operation from one that performs it �Commands are first-class objects that can be subclassed, etc. �Commands can be assembled into macros �It’s easy to add new Commands—you don’t actually have to change existing classes Fall 2004 Copyright 2000, Georgia Tech 53

Smalltalk Pluggable Command �Create a class Pluggable. Command with instance variables receiver, selector, and arguments command : = Pluggable. Command receiver: self selector: #cut unselector: #uncut arguments: (Array with: my. Text. Pane) Fall 2004 Copyright 2000, Georgia Tech 54

Pluggable. Command execute “Pluggable. Command” ^self receiver perform: self selector with. Arguments: self arguments undo. It ^self receiver perform: self unselector with. Arguments: self arguments Fall 2004 Copyright 2000, Georgia Tech 55

Undo/Macro Commands 0. . n Abstract Comman d manages Command Manager do. It undo. It Macro Comman d Concrete Comman stated do. It undo. It Fall 2004 Copyright 2000, Georgia Tech Must know state so that undo can happen. (i. e. Document, pos, string for Insert) 56

Implementing Macro/Undo �Macro is just a collection of commands we can go through and execute. �Undo is a collection (or stack) of commands. Every time we undo, we take the most recent command execute the undo. �If we wanted redo, we could add the undone command to a redo list that could also be executed again. Fall 2004 Copyright 2000, Georgia Tech 57

Design Problem #4: Adapter �Design problem #4: Square Peg, Round Hole �Inability to alter useful classes directly �maybe you don't have source �maybe it's in another language �maybe it's just huge �Solution: Structural pattern Adapter �a kind of “wrapper” Fall 2004 Copyright 2000, Georgia Tech 58

Structural pattern Adapter �Intent: Convert the interface of a class into another interface clients expect. �Basically, have a wrapper that interprets one intterface into the other �Read. Stream: treat a collection as a stream �Pluggable components: turn your sophisticated model into. . . a list. �Wrapping non-OO code and making it look like an object. Used a lot in C++ to wrap (adapt) C libraries. Squeak's MPEGPlugin. Fall 2004 Copyright 2000, Georgia Tech 59

Adapter Structure Client Target request: any. Param Adaptee Adapter request: any. Param adaptee hard. To. Reuse. Request: some. Param request: any. Param adaptee hard. To. Reuse. Request: any. Param Fall 2004 Copyright 2000, Georgia Tech 60

Adapter Participants �Target: Defines the domain-specific interface for the Client �Client: Collaborates with objects using the Target interface �Adaptee: Defines the existing interface �Adapter: Makes the adaptee more usable by implementing the Target interface and using it to adapt the adaptee Fall 2004 Copyright 2000, Georgia Tech 61

Adapter Consequences �Adapter adapts for all subclasses of adaptee, too �Adapter makes it harder to override adaptee behavior—have to make adapter talk to adaptee subclass Fall 2004 Copyright 2000, Georgia Tech 62

Parameterized Adapters in Smalltalk �Define a class Parameterized. Adapter with instance variables adaptee, get. Block, and set. Block. adapter : = Parameterized. Adapter on: an. Adaptee. adapter get. Block: [: x | “something that gets a value for adaptee”]; set. Block: [: x | “Something that sets a value for adaptee”]. Fall 2004 Copyright 2000, Georgia Tech 63

Other useful patterns �Null Object �I want to handle all results, without worrying about special checks for null. Account Cash Account Fall 2004 Bond Account … Copyright 2000, Georgia Tech Null Account 64

Null Object �If I search for an account, how do I signal not found, nil? Then I have to check for that special case. �Why not have a null object that implements the entire interface by doing nothing. Fall 2004 Copyright 2000, Georgia Tech 65

Singleton �Sometimes we have classes that need to be accessible, but we only want one instance of the class. �We make constructor private (make an empty new in smalltalk), use a class get. Instance method to return the one version of the class. �Keep class instance var (Instance) that keeps the one true instance of the class. Fall 2004 Copyright 2000, Georgia Tech 66

Impact of Singleton �Everyone can get to it because of static public method. �Can’t easily subclass. �Can be garbage collected if no one is pointing to it. Fall 2004 Copyright 2000, Georgia Tech 67

Patterns So Far: �Factory/Abstract Factory �Observer �Command �Bridge �Adaptor �Null Object �Singleton How can we use each of these in our project? Fall 2004 Copyright 2000, Georgia Tech 68

Warning Signs in Design/Code �Duplicated Code/Functionality �Long Methods �Large Class �Long Parameter Lists �Shotgun Surgery �Feature Envy �Primitive Obsession Fall 2004 Copyright 2000, Georgia Tech 69

More Warning Signs �Switch statements �Temporary Field �Middle Man �Message Chains Fall 2004 Copyright 2000, Georgia Tech 70

Arguments Against Patterns �Maybe these are things that should just be language features? �Alexander’s approach has not been accepted in Architecture �His efforts in defining patterns have only described a few small classes of buildings (e. g. , cottages) �Real experts have lots of chunks �Simon estimates 10, 000 of them �John Anderson says that you can’t teach them directly, only through experience Fall 2004 Copyright 2000, Georgia Tech 71