DOCSLIB.ORG

COSC 3351 Software Design Design Patterns Behavioral Patterns (II)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
COSC 3351 Software Design Design Patterns Behavioral Patterns (II) COSC 3351 Software Design Design Patterns Behavioral Patterns (II) Edgar Gabriel Spring 2008 Edgar Gabriel Purpose Creational Structural Behavioral Scope Class Factory Method Adapter(class) Interpreter Template Method Object Abstract Factory Adapter(object) Chain of Responsibility Builder Bridge Command Prototype Composite Iterator Singleton Decorator Mediator Façade Observer Flyweight State Proxy Strategy Visitor Memento COSC 3351 – Software Design Edgar Gabriel 1 Memento • Intent : Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later. • Applicability : Use the memento pattern when – A snapshot of an object’s state must be saved so that it can be restored to that state later, and – A direct interface to obtaining the state would expose implementation details and break the object’s encapsulation COSC 3351 – Software Design Edgar Gabriel Structure Originator Memento Caretaker state state SetMemento(Memento m) GetState() CreateMemento() SetState() state = m->GetState(); return new Memento(state); COSC 3351 – Software Design Edgar Gabriel 2 Participants • Memento: – stores internal state of the Originator object – protects against access by objects other than the originator • Originator: – creates a memento containing a snapshot of its current internal state – uses the memento to restore its internal state • Caretaker: – is responsible for the memento’s safekeeping – never operates on or examines the contents of a memento COSC 3351 – Software Design Edgar Gabriel Implementation • Mementos have two interfaces: – a wide one for the originators: C++ usually relies on making the Originator a friend of Memento + making Memento’s wide interface private – a narrow one for other objects: public interface COSC 3351 – Software Design Edgar Gabriel 3 class Originator { public: Memento* CreateMement(); void* SetMemento( const Memento* ); private: State* _state; } class Memento { public: // narrow public interface virtual ~Memento(); private: friend class Originator; Memento(); void SetState(State *); State* GetState(); private: State* _state; } COSC 3351 – Software Design Edgar Gabriel // implementation of the Do() and Undo() operations of // the Originator, assuming that it confirms to the command // pattern void Originator::Do() { Originator* ori = Originator::Instance(); _state = ori->CreateMemento(); // do whatever the code has to do } void Originator::Undo() { Originator *ori = Originator::Instance(); ori->SetMemento(_state); … } COSC 3351 – Software Design Edgar Gabriel 4 State • Intent : allow an object to alter its behavior when its internal state changes. The object will appear to change its class. • Applicability : use the state pattern when – an object’s behavior depends on its state, and it must change its behavior at run-time depending on the state. – Operations have large, multipart conditional statements • Advantages : – Localizes state-specific behavior and partitions behavior for different states – It makes state transition explicit – State objects can be shared COSC 3351 – Software Design Edgar Gabriel Structure Context <<interface>> State Request() Handle() state->Handle(); ConcreteStateA ConcreteStateB Handle() Handle() COSC 3351 – Software Design Edgar Gabriel 5 Participants • Context: – Define the interface of interest to clients – Maintains an instance of a ConcreteState subclass that defines the current state • State: – Defines an interface for encapsulating the behavior associated with a particular state of the Context • ConcreteState: – Each subclass implements a behavior associated with a state of the Context. COSC 3351 – Software Design Edgar Gabriel Example: TCP connection COSC 3351 – Software Design Edgar Gabriel 6 class TCPOctetStream; class TCPState; class TCPConnection { public: TCPConnection(); void ActiveOpen(); void PassiveOpen(); void Close(); void Send(); void Acknowledge(); void Synchronize(); void ProcessOctet(TCPOctetStream* ); private: friend class TCPState; void ChangeState (TCPState *); private: TCPState* _state; } COSC 3351 – Software Design Edgar Gabriel • TCPState duplicates the state-changing interface of TCPConnection – each method takes an additional TCPConnection instance as a parameter can therefore access Data from TCPConnection and modify the state class TCPState { public: virtual void Transmit(TCPConnection*, TCPOctetStream*) virtual void ActiveOpen(TCPConnection* ); virtual void PassiveOpen(TCPConnection*); virtual void Close(TCPConnection*); virtual void Send(TCPConnection*); virtual void Acknowledge(TCPConnection*); virtual void Synchronize(TCPConnection*); protected: void ChangeState (TCPConnection*, TCPState *); } // provide default implementations for all classes, e.g. void TCPState::Transmit(TCPConnection*, TCPOctetStream*) {} void ActiveOpen(TCPConnection* ) {} void PassiveOpen(TCPConnection*) {} void Close(TCPConnection*) {} COSC 3351 – Software Design voidEdgar Gabriel Send(TCPConnection*) {} 7 TCPConnection::TCPConnection() { _state = TCPClosed::Instance(); } void TCPConnection::ChangeState(TCPState *s ) { _state = s; } void TCPConnection::ActiveOpen() { _state->ActiveOpen(this); } void TCPConnection::PassiveOpen() { _state->PassiveOpen(this); } void TCPConnection::Close() { _state->Close(this); } void TCPConnection::Acknowledge() { _state->Acknowledge(this); } void TCPConnection::Synchronize() { _state->Synchronize(this); } COSC 3351 – Software Design Edgar Gabriel class TCPEstablished:: public TCPState { public: static TCPState* Instance(); virtual void Transmit(TCPConnection*, TCPOctetStream*); virtual void Close(TCPConnection*); }; class TCPListen:: public TCPState { public: static TCPState* Instance(); virtual void Send (TCPConnection*); … } void TCPEstablished:: Close ( TCPConnection *s ) { // send FIN // receive ACK ChangeState ( s, TCPListen::Instance() ); } void TCPEstablished::Transmit (TCPConnection *s, TCPOctetstream *o ) { s->ProcessOctet(o); // this function does not change the state } COSC 3351 – Software Design Edgar Gabriel 8 Strategy • Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. • Applicability: use the Strategy pattern when – many related classes differ only in the behavior – you need different variants of an algorithm – you want to avoid to expose complex, algorithm-specific data structures – a class defines many behaviors, and these appear as multiple conditional statements in the operation. COSC 3351 – Software Design Edgar Gabriel Structure Context <<interface>> Strategy Contextinterface() Algorithminterface() ConcreteStrategyA ConcreteStrategyB Algorithminterface() Algorithminterface() COSC 3351 – Software Design Edgar Gabriel 9 Participants • Strategy: declares an interface common to all supported algorithms • ConcreteStrategy: implements the algorithm using the Strategy interface • Context: – is configured with a ConcreteStrategy object, i.e. the Constructor takes a ConcreteStrategy object – maintains a reference to a Strategy object – may define an interface that lets Strategy accesss data COSC 3351 – Software Design Edgar Gabriel Visitor • Intent : Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates • Applicability : Use the Visitor pattern when – an object structure contains many classes of objects with differing interfaces and you want to perform operations on these objects that depend on their concrete classes – many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid ‘polluting’ the classes with these operations – the classes defining the object structure changes rarely, but you often want to define new operations on the structure COSC 3351 – Software Design Edgar Gabriel 10 Structure <<interface>> Client Visitor VisitorConcreteElementA() VisitorConcreteElementB() ConcreteVisitorA ConcreteVisitorB VisitorConcreteElementA () VisitorConcreteElementA() VisitorConcreteElementB () VisitorConcreteElementB() <<interface>> ObjectStructure Element Accept(Visitor) ConcreteElementA ConcreteElementB v->VisitorConcreteElementA(this); Accept (Visitor v) Accept (Visitor v) OperationA() OperationB() COSC 3351 – Software Design Edgar Gabriel Participants • Visitor : declares a Visit operation for each ConcreteElement in the object structure • ConcreteVisitor : implements each operation declared by Visitor • Element : defines an Accept operation that takes a visitor as an argument • ConcreteElement : implements an Accept operation that takes a visitor as an Argument • ObjectStructure: – Can enumerate its elements – May provide a high-level interface to allow the visitor to visit its elements – May either be a composite or a collection such as a list or a set COSC 3351 – Software Design Edgar Gabriel 11 Consequences • Visitor makes adding new operations easy • Adding a new ConcreteElement is hard, since you have to update all ConcreteVisitor classes • The visitor pattern depends on Double Dispatch : the method calls depends on the Visitor and the Element. COSC 3351 – Software Design Edgar Gabriel class Visitor { public: virtual void VisitElementA(ElementA *); virtual void VisitElementA(ElementA *); protected: Visitor(); } class Element { public: virtual ~Element(); virtual void Accept(Visitor&) =0; protected: Element(); } class ElementA : public Element { public:
Load more

Recommended publications
  • 1 Design Pattern for Open Class (DRAFT) 2 Abstract Factory
    1 Design Pattern for Open Class (DRAFT) Tanaka Akira <[email protected]> A design pattern describes a software architecture which is reusable and exten- sible. [GoF] is the book containing 23 design patterns for OOP languages like C++ and Java. [GoF] describes several trade offs of the patterns. In C++ and Java, a class is defined by only one module. However, there are languages which can define a class by two or more modules: Cecil, MultiJava, AspectJ, MixJuice, CLOS, Ruby, etc. Such class is called "open class" because it is extensible by modules implemented later [Chambers]. For languages with open class, more extensible and/or simpler design patterns exists. We studied design patterns with open class for each GoF design patterns. In this paper, we describe two patterns: the Abstract Factory pattern and the Visitor pattern. 2 Abstract Factory The Abstract Factory pattern is a design pattern for separating class names from the code which generates the object group of related classes for making them configurable. Following figure is the class diagram of the Abstract Factory pattern. Since the example described in [GoF] uses only one concrete factory for each binaries, the required concrete factory is selected statically. The example builds two binaries for Motif and Presentation Manager from a single source code. Two concrete factories are exist for Motif and Presentation Manager. When a binary is built, it is selected which concrete factory is linked. Such static selection can be implemented with the fewer number of classes by open class as following modules. • The module which defines Window and ScrollBar class and their methods which is independent to window systems.
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • Tree Visitors in Clojure Update the Java Visitor Pattern with Functional Zippers
    Tree visitors in Clojure Update the Java Visitor pattern with functional zippers Skill Level: Intermediate Alex Miller ([email protected]) Senior Engineer Revelytix 20 Sep 2011 JVM language explorer Alex Miller has recently discovered the benefits of implementing the Visitor pattern using Clojure, a functional Lisp variant for the Java Virtual Machine. In this article, he revisits the Visitor pattern, first demonstrating its use in traversing tree data in Java programs, then rewriting it with the addition of Clojure's functional zippers. I’ve used trees of domain objects in my Java applications for many years. More recently, I’ve been using them in Clojure. In each case, I've found that the Visitor pattern is a reliable tool for manipulating trees of data. But there are differences in how the pattern works in a functional versus object-oriented language, and in the results it yields. About Clojure Clojure is a dynamic and functional programming language variant of Lisp, written specifically for the JVM. Learn more about Clojure on developerWorks: •"The Clojure programming language" •"Clojure and concurrency" •"Solving the Expression Problem with Clojure 1.2" •"Using CouchDB with Clojure" In this article, I revisit domain trees and the Visitor pattern for the Java language, Tree visitors in Clojure Trademarks © Copyright IBM Corporation 2011 Page 1 of 27 developerWorks® ibm.com/developerWorks then walk through several visitor implementations using Clojure. Being a functional language, Clojure brings new tricks to data query and manipulation. In particular, I've found that integrating functional zippers into the Visitor pattern yields efficiency benefits, which I explore.
    [Show full text]
  • Facet: a Pattern for Dynamic Interfaces
    Facet: A pattern for dynamic interfaces Author: Eric Crahen SUNY at Buffalo CSE Department Amherst, NY 14260 201 Bell Hall 716-645-3180 <[email protected]> Context: Wherever it is desirable to create a context sensitive interface in order to modify or control the apparent behavior if an object. Problem: How can I modify the behavior of an existing object so that different behaviors are shown under different circumstances; and yet still maintain a clean separation between the policy (when each behavior is available) and implementation of each behavior allowing them to be developed independently of one another? Forces: Interfaces provide an essential level of abstraction to object oriented programming. Generally, objects are able define aspects of their function very well using interfaces. At times, this may not be enough. When dealing with two or more classes whose responsibilities are distinctly separate, but whose behavior is closely related, classes can begin to resist modularization. For example, adding security to an application means inserting code that performs security checks into numerous locations in existing classes. Clearly, these responsibilities are distinct; the original classes being responsible for the tasks they were designed to perform, and the security classes being responsible for providing access control. However, making those original classes secure means intermingling code that deals with security. When the classes dealing with security are changed many classes are going to be impacted. One method of adding new behavior to an existing class might be to simply create a subclass and embed that new behavior. In the security example, this would mean creating a subclass for each class that needs to be secure and adding calls to the security code.
    [Show full text]
  • Object-Oriented Desgin Visitor Pattern George Blankenship 1
    Object-Oriented Desgin Visitor Pattern CSCI 253 Object Oriented Design: Visitor Pattern George Blankenship Visitor Pattern George Blankenship 1 Overview Creational Patterns Structural Patterns Behavioral Patterns Singleton Composite Chain of Respons. Abstract factory Façade Command Factory Method Proxy Interpreter Prototype Flyweight Iterator Builder Mediator Adapter Memento Bridge Observer Decorator State Strategy Template Method Visitor Pattern George Blankenship Visitor 2 The Elements of a Design Pattern • A pattern name • The problem that the pattern solves – Including conditions for the pattern to be applicable • The solution to the problem brought by the pattern – The elements (classes-objects) involved, their roles, responsibilities, relationships and collaborations – Not a particular concrete design or implementation • The consequences of applying the pattern – Time and space trade off – Language and implementation issues – Effects on flexibility, extensibility, portability Visitor Pattern George Blankenship 3 George Blankenship 1 Object-Oriented Desgin Visitor Pattern The Visitor Pattern: The Problem Represents an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates • many distinct and unrelated operations need to be performed on objects in an object structure an you want to avoid “polluting” their classes with these operations • the classes defining the object structure rarely change but you often want to define new operations over the structure Visitor Pattern George Blankenship 4 Visitor Example • The root of the structure accepts a visitor: root.accept( visitor ) • The root and every child object in the structure have a an accept method: void accept( visitor ) { visitor.visit( this ); for each child of mine child.accept( visitor ) next } • In short order our visitor gets a visit() call from each object in the collection.
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]
  • Behavioral Patterns
    Behavioral Patterns 101 What are Behavioral Patterns ! " Describe algorithms, assignment of responsibility, and interactions between objects (behavioral relationships) ! " Behavioral class patterns use inheritence to distribute behavior ! " Behavioral object patterns use composition ! " General example: ! " Model-view-controller in UI application ! " Iterating over a collection of objects ! " Comparable interface in Java !" 2003 - 2007 DevelopIntelligence List of Structural Patterns ! " Class scope pattern: ! " Interpreter ! " Template Method ! " Object scope patterns: ! " Chain of Responsibility ! " Command ! " Iterator ! " Mediator ! " Memento ! " Observer ! " State ! " Strategy ! " Visitor !" 2003 - 2007 DevelopIntelligence CoR Pattern Description ! " Intent: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. ! " AKA: Handle/Body ! " Motivation: User Interfaces function as a result of user interactions, known as events. Events can be handled by a component, a container, or the operating system. In the end, the event handling should be decoupled from the component. ! " Applicability: ! " more than one object may handle a request, and the handler isn't known a priori. ! " Want to issue a request to one of several objects without specifying the receiver !" 2003 - 2007 DevelopIntelligence CoR Real World Example ! " The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver, by giving more than one object a chance to handle the request. ! " Mechanical coin sorting banks use the Chain of Responsibility. Rather than having a separate slot for each coin denomination coupled with receptacle for the denomination, a single slot is used. When the coin is dropped, the coin is routed to the appropriate receptacle by the mechanical mechanisms within the bank.
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]
  • Behavioral Patters
    11. Behavioral Pattern Venkat Subramaniam BDP-1 Behavioral Patters • Concerned with algorithms & assignment of responsibilities • Patterns of Communication between Objects Venkat Subramaniam BDP-2 Chain of Responsibility Pattern —Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it“ Venkat Subramaniam BDP-3 Example that would benefit from Chain Of Responsibility Pattern • Various types of Controls are used in an application. Controls handle certain events while they do not handle others. Each control may be invoked from other controls. An event not handled by a control must be passed on to its parent control. Venkat Subramaniam BDP-4 Example using Chain of Responsibility Pattern Client Event Handler handleEvent() Control1 Control2 handleEvent() handleEvent() Venkat Subramaniam BDP-5 When to use Chain Of Responsibility Pattern • More than one object may handle a request, and the handler isn‘t known ahead of time. • One of several objects may be the intended receiver • Set of objects that handle request is dynamic Venkat Subramaniam BDP-6 Consequences of using Chain Of Responsibility • Reduced Coupling • Flexibility in assigning responsibilities œ Distributes responsibilities among objects • Receipt isn‘t guaranteed Venkat Subramaniam BDP-7 Chain Of Responsibility Vs. Other Patterns • Often used with Composite œ Parent acts as Successor Venkat Subramaniam BDP-8 Iterator Pattern —Provide
    [Show full text]
  • Scala by Example (2009)
    Scala By Example DRAFT January 13, 2009 Martin Odersky PROGRAMMING METHODS LABORATORY EPFL SWITZERLAND Contents 1 Introduction1 2 A First Example3 3 Programming with Actors and Messages7 4 Expressions and Simple Functions 11 4.1 Expressions And Simple Functions...................... 11 4.2 Parameters.................................... 12 4.3 Conditional Expressions............................ 15 4.4 Example: Square Roots by Newton’s Method................ 15 4.5 Nested Functions................................ 16 4.6 Tail Recursion.................................. 18 5 First-Class Functions 21 5.1 Anonymous Functions............................. 22 5.2 Currying..................................... 23 5.3 Example: Finding Fixed Points of Functions................ 25 5.4 Summary..................................... 28 5.5 Language Elements Seen So Far....................... 28 6 Classes and Objects 31 7 Case Classes and Pattern Matching 43 7.1 Case Classes and Case Objects........................ 46 7.2 Pattern Matching................................ 47 8 Generic Types and Methods 51 8.1 Type Parameter Bounds............................ 53 8.2 Variance Annotations.............................. 56 iv CONTENTS 8.3 Lower Bounds.................................. 58 8.4 Least Types.................................... 58 8.5 Tuples....................................... 60 8.6 Functions.................................... 61 9 Lists 63 9.1 Using Lists.................................... 63 9.2 Definition of class List I: First Order Methods..............
    [Show full text]
  • HEDGEHOG: Automatic Verification of Design Patterns in Java
    HEDGEHOG: Automatic Verification of Design Patterns in Java Alex Blewitt I V N E R U S E I T H Y T O H F G E R D I N B U Doctor of Philosophy School of Informatics University of Edinburgh 2006 Abstract Design patterns are widely used by designers and developers for building complex systems in object-oriented programming languages such as Java. However, systems evolve over time, increasing the chance that the pattern in its original form will be broken. To verify that a design pattern has not been broken involves specifying the original intent of the design pattern. Whilst informal descriptions of patterns exist, no formal specifications are available due to differences in implementations between programming languages. This thesis shows that many patterns (implemented in Java) can be verified automatically. Patterns are defined in terms of variants, mini-patterns, and artefacts in a pattern description language called SPINE. These specifications are then processed by HEDGEHOG, an automated proof tool that attempts to prove that Java source code meets these specifications. iii Acknowledgements I am indebted to Alan Bundy who has given me the freedom to work on this thesis whilst at the same time guiding me towards the final production and presentation of these results. I not would have been able to achieve this without Alan’s support through a sometimes difficult, but always busy part of my life. This project, and especially the production of this thesis, would not have been possible without the care and attention that Alan provided. Ian Stark has provided invaluable feedback on all aspects of this thesis, from the low-level technical intricacies of Java’s design patterns through to the high-level structure of the thesis as a whole.
    [Show full text]
  • Design Pattern Implementation in Java and Aspectj
    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
    [Show full text]