Design Reuse Mechanisms for improving software reuse design

Design Reuse Mechanisms for improving software reuse, design and maintenance Copyright 2000, Georgia Tech

Story z. What are Architectural Styles? z. What are Frameworks? z. What are Design Patterns? z. Example Design Patterns z. Design Patterns in Smalltalk 2/6/2022 Copyright 2000, Georgia Tech 2

A Hierarchy of Blueprints z. Architectural Styles z. Frameworks z. Design Patterns z. Language Idioms 2/6/2022 Copyright 2000, Georgia Tech 3

Architecture z. 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. z. Typically have multiple views: Logical, Process, Module, and Physical. z. Highest level organization of system 2/6/2022 Copyright 2000, Georgia Tech 4

Architecture Styles z. Standard components z. Standard defined relationships between components. z. Standard configurations. 2/6/2022 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 2/6/2022 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 2/6/2022 Copyright 2000, Georgia Tech 7

Main Program-Subroutine Main M 1. 1 2/6/2022 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 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 Layer 1 2/6/2022 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 2/6/2022 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 2/6/2022 Copyright 2000, Georgia Tech 11

Frameworks z. Groups of classes used for a particular domain y. SUnit is a testing framework y. Swing is a GUI framework for Java z. Concrete classes y. The hard part is just learning about the framework and how to use it 2/6/2022 Copyright 2000, Georgia Tech 12

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

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

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

Your first pattern: Observer z “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 z Participants: y (Abstract) Subjects: Know observers and can attach/detach them y (Abstract) Observers: Can update() when notified of changes y Concrete. Subjects maintain state for subject y Concrete. Observers maintain a relationship with the Concrete. Subject 2/6/2022 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] Have we seen this anywhere before? ? ? Concrete. Subject subject. State 1 subject. State: an. Object 2/6/2022 Concrete. Observer observer. State update: a. Symbol Copyright 2000, Georgia Tech 17

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

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

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

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

Patterns in Architecture z “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 z Alexander is an Architect who has been collecting patterns in Architecture for years y. Standard ways of solving problems 2/6/2022 Copyright 2000, Georgia Tech 22

Patterns in Cognitive Science z. Experts do think in pattern-like elements y. Sometimes called “chunks” or “plans” y. Shown by Herb Simon for Chess y. Shown by Elliot Soloway for Software z. Can we teach these patterns to people to make them better designers? y. Can they recognize the situation and apply the pattern? 2/6/2022 Copyright 2000, Georgia Tech 23

Describing Design Patterns z Name and classification z Intent z Also Known As (AKA) z Motivation z Applicability z Structure z Participants 2/6/2022 z Collaborations z Consequences z Implementation issues z Sample code z Known uses z Related Patterns Copyright 2000, Georgia Tech 24

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

Patterns for Reuse z Patterns build heavily on composition and delegation z Inheritance is a “white box” form of reuse y. Its faster and straightforward y. But requires a lot of knowledge of superclass z Composition and delegation is “black box” reuse y. Keeps details hidden away z In general, program to an interface, not an implementation (Remember dependency inversion principle, open-closed, …) 2/6/2022 Copyright 2000, Georgia Tech 26

Design Patterns Solve Common Reuse Problems z. Example 1: Creating an object by specifying a class explicitly y. 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) y. To avoid it, create objects indirectly z. Solutions are Creational patterns 2/6/2022 Copyright 2000, Georgia Tech 27

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

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

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

Factory Method Structure Product Creator Factory. Method: some. Spec Concrete. Creator Concrete. Product Factory. Method 2/6/2022 Copyright 2000, Georgia Tech 31

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

Implementing Factory Method in Smalltalk z Imagine a Car. Builder abstract class, with subclasses Ford. Builder and Toyota. Builder y. 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 2/6/2022 Copyright 2000, Georgia Tech 33

Alternative Factory Method Implementation in Smalltalk z 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 2/6/2022 Copyright 2000, Georgia Tech 34

Another Factory Example Encrypts with Encryption Encrypted. Socket creates DESEncryption RSAEncryption Socket Encryption. Factory Gets Encryption From: Grand, Patterns in Java Vol. 1 Factory 2/6/2022 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. 2/6/2022 Copyright 2000, Georgia Tech 36

Related Pattern: Abstract Factory z. Intent: Provide an interface for creating families of related or dependent objects. z. In some sense, select a class which has the Factory Methods you need 2/6/2022 Copyright 2000, Georgia Tech 37

Abstract Factory Example Car. Part. Factory Car. Engine Car. Body Ford. Factory make. Body make. Engine Ford. Body 2/6/2022 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. 2/6/2022 Copyright 2000, Georgia Tech 39

Problem #2: Hardware/software dependence z. Redesign/reuse problem #2: Hardware/software dependence y. You want to limit your dependency on software specifics or hardware specifics z. Can solve this with an Abstract Factory z. Can also solve this with the Behavioral Pattern: Bridge 2/6/2022 Copyright 2000, Georgia Tech 40

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

Bridge Pattern Example Window implementation Window. Implementation Mac. Window. Implementation 2/6/2022 Copyright 2000, Georgia Tech Window. Implementation 42

Interesting Uses for Bridges z Not just to hide platform dependencies! z IBM Smalltalk separated collections into implementations and interfaces y. If a Set was small, stored in a Linear. Set. Implementation y. If a Set was large, stored in a Linear. Hash. Set. Implementation y. Programmer-User only saw the same Set interface— the implementation changed invisibly 2/6/2022 Copyright 2000, Georgia Tech 43

When to Bridge z. You want to avoid a permanent binding between an abstraction and its implementation z. Both abstraction and implementation might be extensible via subclassing z. Changes in implementation should not impact clients of the abstraction 2/6/2022 Copyright 2000, Georgia Tech 44

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

Problem #3: Dependence on Specific Operations z Reuse/Redesign Problem #3: When you specify a particular operation, you are committing to one way of satisfying a request. z 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 z One solution design pattern: Command 2/6/2022 Copyright 2000, Georgia Tech 46

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

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

Motivation for Command z. Need support for multi-level undo y. Need a history of commands x. What command was done x. What data was changed x. How do I undo? 2/6/2022 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 2/6/2022 Copyright 2000, Georgia Tech 50

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

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

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

Smalltalk Pluggable Command z. 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) 2/6/2022 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 2/6/2022 Copyright 2000, Georgia Tech 55

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

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

Design Problem #4: Adapter z. Design problem #4: Inability to alter classes conveniently y. Sometimes you have to change something (e. g. , you need an interface to be like this, but it’s implemented like that), but you can’t easily — it’s a system that you don’t have source to, or it’s in another language, or it’s big and complicated z. Solution: Structural pattern adapter 2/6/2022 Copyright 2000, Georgia Tech 58

Structural pattern Adapter z. Intent: Convert the interface of a class into another interface clients expect. y. Basically, put a “wrapper” around something, so that it looks right y. Pluggable components do this! x. Essentially, they let a standard interface work for any UI component y. Useful for wrapping non-OO code and making it look like an object. Used a lot in C++ to wrap (adapt) C libraries. 2/6/2022 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 2/6/2022 Copyright 2000, Georgia Tech 60

Adapter Participants z. Target: Defines the domain-specific interface for the Client z. Client: Collaborates with objects using the Target interface z. Adaptee: Defines the existing interface z. Adapter: Makes the adaptee more usable by implementing the Target interface and using it to adapt the adaptee 2/6/2022 Copyright 2000, Georgia Tech 61

Adapter Consequences z. Adapter adapts for all subclasses of adaptee, too z. Adapter makes it harder to override adaptee behavior—have to make adapter talk to adaptee subclass 2/6/2022 Copyright 2000, Georgia Tech 62

Parameterized Adapters in Smalltalk z 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”]. 2/6/2022 Copyright 2000, Georgia Tech 63

Other useful patterns z. Null Object z. I want to handle all results, without worrying about special checks for null. Account Cash Account 2/6/2022 Bond Account … Copyright 2000, Georgia Tech Null Account 64

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

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

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

Patterns So Far: z. Factory/Abstract Factory z. Observer z. Command z. Bridge z. Adaptor z. Null Object z. Singleton 2/6/2022 Copyright 2000, Georgia Tech 68

Bad Smells in Design/Code z. Duplicated Code/Functionality z. Long Methods z. Large Class z. Long Parameter Lists z. Shotgun Surgery z. Feature Envy z. Primitive Obsession 2/6/2022 Copyright 2000, Georgia Tech 69

More Bad Smells z. Switch statements z. Temporary Field z. Middle Man z. Message Chains 2/6/2022 Copyright 2000, Georgia Tech 70

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