DOCSLIB.ORG

A Fundamental Modeling Concept Approach for Modeling UML Design Patterns

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Fundamental Modeling Concept Approach for Modeling UML Design Patterns INTERNATIONAL JOURNAL OF COMPUTERS Issue 3, Volume 2, 2008 A Fundamental Modeling Concept Approach for Modeling UML Design Patterns A. Spiteri Staines structural. Abstract— Traditionally software design patterns were Behavioral Design Patterns describe behavior. Some developed to create software artifacts efficiently and effectively. behavioral patterns are i) chain of responsibility, ii) command, Patterns are represented using UML notations and formal models. iii) interpreter, iv) iterator, v) visitor, etc. Unfortunately these do not always suffice to analyze behavior. There Creational design patterns focus on using abstract classes are various problems related to visualization, abstracting, mapping the design to the implementation, etc. Various approaches have been to create objects that are managed independently from the tried out. Most methods are too complex and do not offer proper originator requesting their use. Some common creational visualization. This paper promotes the use of Fundamental Modeling design patterns are i) abstract factory, ii) builder, iii) prototype Concepts to support design patterns. These offer better visualization and iv) singleton. and simplicity over the mainstream approaches. Some examples are Structural design patterns focus on the interaction structure presented. from the system point of view. These patterns describe the components of a system. Some structural design patterns are i) Keywords—Design Patterns, Fundamental Modeling Concepts, adapter, ii) bridge , iii) composite, iv) proxy, etc. Software Engineering, UML. Some findings about design patterns and the UML are presented below: I. INTRODUCTION UML patterns are implemented as packages OFTWARE design patterns are standard solutions to Patterns can be composed of several classes recurring problems over different application domains S Patterns should exist at a higher level of [18]. Software patterns are defined as reusable micro abstraction than the actual class architectures. Unfortunately they are not pluggable solutions Patterns should be independent of implementation, in most cases. Users might be using these patterns without technologies and programming languages knowing it. The patterns presented in [8]–[15] explain how to In the mindset of the software engineer thinking in resolve software design problems from both the i) system and terms of ‘patterns’ simplifies the solution to a ii) programming point of view. Design patterns attempt to particular problem implement efficient and effective inexpensive solutions. They Conceptual thinking is a different way of obviate the need to re-invent a solution. A well defined design abstracting a problem where patterns can be used. pattern should be implemented regardless of the software platform used. Thinking in terms of patterns simplifies III. FINE VS COARSE GRANULARITY problem solving. Patterns can communicate knowledge and architectural design between different users. Knowledge can Fine granularity describes a system in detail, very close to be stored as a pattern in one’s mind without knowing it. This the actual implementation. Conversely coarse granularity requires that patterns are easily visualized and specified. depicts a system at a higher level of abstraction. Depending on the application being developed, different levels of granularity can be considered. E.g. for a simple application with no more II. DESIGN PATTERNS AND UML than five classes a fine grain approach is suitable. On the other The UML is the de facto standard used to describe recurrent hand for complex applications exhibiting different types of design patterns for various reasons [8],[12]-[13]. UML behavior, a coarse grained approach is preferred. diagrams are based on visual notations. There exist different These patterns also describe complex system interaction. classes of design patterns E.g. GOF, POF, observer, adaptor, Patterns can explain packages, clusters etc. [8]. Design etc. Design patterns can be classified into three subcategories Patterns can be linked to coarse granularity. A ‘class’ might [10],[14]-[15]. These are a) behavioral b) creational and c) actually be too small to model complex behavior. The UML is well suited to describing fine granularity, because it actually Manuscript received March 28, 2008; Revised version received Aug. 19, 2008 represents the implementation. Design Patterns abstracted at a A. Spiteri Staines is with the Department of Computer Information high level require a different treatment. Systems, Faculty of ICT, University of Malta, Msida, MSD 2080, Malta, Europe. phone: 00356-21373402; fax: 21312110; (e-mail: [email protected], [email protected]) 231 INTERNATIONAL JOURNAL OF COMPUTERS Issue 3, Volume 2, 2008 IV. ISSUES AND PROBLEMS presented. Although this is a valid approach it can become Development of information systems for large quite complex for large systems. organizations is a complex task. It is not easy to visualize the Design patterns from the Gof can be formalized in the B complete information system complete with functionality. language [9]. Other valid approaches are using UML-B. These Systems are composed of several viewpoints. The application are more suited for formal verification than visualization. In domain influences these views. Most system stakeholders are [10] a better solution is proposed where Le PUS3 / Class-Z non technical persons. It is possible to create business models are combined to model design patterns. Interesting diagrams that will be used to develop a system model. Well defined which are easily readable are presented but these are still too design patterns can support both system and software close to the implementation, hence a fine grained approach. modeling. Design patterns are again formalized in [11] using the To encourage the use of design patterns these should be Disco approach considering the subject vs observer well understood. Understanding system functionality implies viewpoints. that: i) the problem statement and ii) the solution are separate Visual notations help to reduce ambiguity that might be issues. Different approaches have been formulated to present in formal approaches. In [17] extensions to the UML represent design patterns. These are i) formal models [8]-[11], using a profile are suggested to visualize design patterns. This ii) visual notations. Formal models encompass logic-based is a valid solution. The FMC notations [1] presented in this languages and specification languages e.g. DPML. Formal paper strive to offer simpler solutions. FMC notations have notations are not comprehended by many stakeholders. been used in industry. Some of the techniques discussed above Consequently they are unsuitable for visualization and any can be used in conjunction with FMC notations. small change requires re-specification. Visual notations are found in the UML and other methods supporting natural VI. A FUNDAMENTAL MODELING CONCEPT SOLUTION languages. Most approaches do not properly show separate A possible solution to these issues is to use Fundamental pattern behavior from its static representation like in a class Modeling Concepts (FMC) developed at Hasso-Plattner- diagram. Institute Potsdam and presented in [1]-[7]. FMC and FMC- Some problems with pattern representation are :i) the UML visualization guidelines are useful to create more focuses on communication at a class level not pattern level, ii) comprehensible and constructible models. FMC are composed patterns can preserve hidden properties, iii) reverse of three main notations: i) Compositional Structures, ii) engineering might be impossible, iv) UML does not clearly Dynamic Structures and iii) Value Range Structures. The specify how to represent these patterns, lacking precise UML design patterns can be represented as compositional semantics, v) binding the pattern to the actual structures. The compositional structures are supported using software/hardware implementation is difficult to achieve [8]. dynamic structures which are place transition Petri nets. These The UML has a set of notations for specifying both the i) diagrams focus on system structures rather than software Static Composition and ii) Dynamic behavior of systems. structures making them suitable to describe ‘a larger granule The UML has a variety of notations for describing of organization’. Recurring patterns can be easily identified. similar system activities. This creates a dilemma as which to In literature it seems that FMC are well suited to model select. Consistency between different notations normally conceptual patterns [1],[4]. Design patterns can also be involves a lot of work, rework and resolution of structural modeled. clashes. The FMC dynamic structures clearly identify and capture Notwithstanding these problems, the UML still remains the behavior of the design pattern. FMC notations have valid as the starting point for describing system behavior. evolved over a number of years. The diagram notations like the dynamic structures are based on place transition Petri nets V. RELATED WORK that have over three decades of coverage and vast literature. Most of the work for design patterns is based on UML FMC diagrams are more practical to use when describing notations. In most cases the UML is insufficient to represent systems at a high level. They support communication between the semantic expression of a design [19]. To solve this technical people and system stakeholders for different system problem different methods are proposed. requirements. FMC are based on important
Load more

Recommended publications
  • Capturing Interactions in Architectural Patterns
    Capturing Interactions in Architectural Patterns Dharmendra K Yadav Rushikesh K Joshi Department of Computer Science and Engineering Department of Computer Science and Engineering Indian Institute of Technology Bombay Indian Institute of Technology Bombay Powai, Mumbai 400076, India Powai, Mumbai 400076, India Email: [email protected] Email: [email protected] TABLE I Abstract—Patterns of software architecture help in describing ASUMMARY OF CCS COMBINATORS structural and functional properties of the system in terms of smaller components. The emphasis of this work is on capturing P rimitives & Descriptions Architectural the aspects of pattern descriptions and the properties of inter- Examples Significance component interactions including non-deterministic behavior. Prefix (.) Action sequence intra-component Through these descriptions we capture structural and behavioral p1.p2 sequential flow specifications as well as properties against which the specifications Summation (+) Nondeterminism choice within a component are verified. The patterns covered in this paper are variants of A1 + A2 Proxy, Chain, MVC, Acceptor-Connector, Publisher-Subscriber Composition (|) Connect matching multiple connected and Dinning Philosopher patterns. While the machines are CCS- A1 | A2 i/o ports in assembly components based, the properties have been described in Modal µ-Calculus. Restriction (\) Hiding ports from Internal The approach serves as a framework for precise architectural A\{p1, k1, ..} further composition features descriptions. Relabeling ([]) Renaming of ports syntactic renaming A[new/old, ..] I. INTRODUCTION In component/connector based architectural descriptions [6], [13], components are primary entities having identities in the represents interface points as ports uses a subset of CSP for system and connectors provide the means for communication it’s formal semantics.
    [Show full text]
  • Automatic Verification of Java Design Patterns
    Automatic Verification of Java Design Patterns Alex Blewitt, Alan Bundy, Ian Stark Division of Informatics, University of Edinburgh 80 South Bridge, Edinburgh EH1 1HN, UK [email protected] [email protected] [email protected] Abstract 2. Design patterns There are a number of books which catalogue and de- Design patterns are widely used by object oriented de- scribe design patterns [4, 1, 6] including an informal de- signers and developers for building complex systems in ob- scription of the key features and examples of their use. ject oriented programming languages such as Java. How- However, at the moment there are no books which attempt ever, systems evolve over time, increasing the chance that to formalise these descriptions, possibly for the following the pattern in its original form will be broken. reasons: We attempt to show that many patterns (implemented in Java) can be verified automatically. Patterns are defined 1. The implementation (and description) of the pattern is in terms of variants, mini-patterns, and constraints in a language-specific. pattern description language called SPINE. These specifi- 2. There are often several ways to implement a pattern cations are then processed by HEDGEHOG, an automated within the same language. proof tool that attempts to prove that Java source code 3. Formal language descriptions are not common within meets these specifications. the object oriented development community. Instead, each pattern is presented as a brief description, and an example of its implementation and use. Designers and developers are then expected to learn the ‘feel’ of a pat- 1.
    [Show full text]
  • Co-Occurrence of Design Patterns and Bad Smells in Software Systems
    XI Brazilian Symposium on Information System, Goi^ania,GO, May 26-29, 2015. Co-Occurrence of Design Patterns and Bad Smells in Software Systems: An Exploratory Study Bruno Cardoso Eduardo Figueiredo Software Engineering Lab (LabSoft) Software Engineering Lab (LabSoft) Federal University of Minas Gerais (UFMG) Federal University of Minas Gerais (UFMG) Belo Horizonte, MG - Brazil Belo Horizonte, MG - Brazil [email protected] [email protected] ABSTRACT In a previous work [1], we performed a systematic literature A design pattern is a general reusable solution to a recurring review in order to understand how studies investigate these two problem in software design. Bad smells are symptoms that may topics, design patterns and bad smells, together. Our results indicate something wrong in the system design or code. showed that, in general, studies have a narrow view concerning Therefore, design patterns and bad smells represent antagonistic the relation between these concepts. Most of them focus on structures. They are subject of recurring research and typically refactoring opportunities. Among these, some tools [3][7][15][17] appear in software systems. Although design patterns represent have been proposed to identify code fragments that can be good design, their use is often inadequate because their refactored to patterns. Other studies [2][6] establish a structural implementation is not always trivial or they may be unnecessarily relationship between the terms design pattern and bad smell. In employed. The inadequate use of design patterns may lead to a addition, there are reported cases in the literature where the use of bad smell. Therefore, this paper performs an exploratory study in design patterns may not always be the best option and the wrong order to identify instances of co-occurrences of design patterns use of a design pattern can even introduce bad smells in code [19] and bad smells.
    [Show full text]
  • Enterprise Development with Flex
    Enterprise Development with Flex Enterprise Development with Flex Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Enterprise Development with Flex by Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Copyright © 2010 Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky.. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mary E. Treseler Indexer: Ellen Troutman Development Editor: Linda Laflamme Cover Designer: Karen Montgomery Production Editor: Adam Zaremba Interior Designer: David Futato Copyeditor: Nancy Kotary Illustrator: Robert Romano Proofreader: Sada Preisch Printing History: March 2010: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Enterprise Development with Flex, the image of red-crested wood-quails, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein.
    [Show full text]
  • A Design Pattern Detection Tool for Code Reuse
    DP-CORE: A Design Pattern Detection Tool for Code Reuse Themistoklis Diamantopoulos, Antonis Noutsos and Andreas Symeonidis Electrical and Computer Engineering Dept., Aristotle University of Thessaloniki, Thessaloniki, Greece [email protected], [email protected], [email protected] Keywords: Design Pattern Detection, Static Code Analysis, Reverse Engineering, Code Reuse. Abstract: In order to maintain, extend or reuse software projects one has to primarily understand what a system does and how well it does it. And, while in some cases information on system functionality exists, information covering the non-functional aspects is usually unavailable. Thus, one has to infer such knowledge by extracting design patterns directly from the source code. Several tools have been developed to identify design patterns, however most of them are limited to compilable and in most cases executable code, they rely on complex representations, and do not offer the developer any control over the detected patterns. In this paper we present DP-CORE, a design pattern detection tool that defines a highly descriptive representation to detect known and define custom patterns. DP-CORE is flexible, identifying exact and approximate pattern versions even in non-compilable code. Our analysis indicates that DP-CORE provides an efficient alternative to existing design pattern detection tools. 1 INTRODUCTION ecutable. As a result, developers cannot exploit the source code of other systems without first resolving Developers need to understand existing projects in or- their dependencies and executing them correctly. Sec- der to maintain, extend, or reuse them. However, un- ondly, pattern representations in most tools are not in- derstanding usually comes down to understanding the tuitive, thus resulting in black box systems that do not source code of a project, which is inherently difficult, allow the developer any control over the detected pat- especially when the original software architecture and terns.
    [Show full text]
  • Prof. Catalin Boja, Phd [email protected] Source Code Quality
    Design patterns Prof. Catalin Boja, PhD [email protected] http://acs.ase.ro/software-quality-testing Source code quality Principles for writing the code: • Easy to read / understand - clear • Easy to modify - structured • Easy to reuse • Simple (complexity) • Easy to test • Implement patterns for the standard problem Left: Simply Explained: Code Reuse 2009-12- acs.ase.ro [email protected] 03.By Oliver Widder, Webcomics Geek Aad Poke.2 Source code quality Forces that influence it: • Available time (delivery terms) • Costs • The experience of the programmer • Programmer competences • Specifications clarity • Solution complexity • Change rates for specifications, requirements, team, etc http://khristianmcfadyen.com/ acs.ase.ro [email protected] 3 Anti-Pattern: Big ball of mud “A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape- and-baling-wire, spaghetti- code jungle.” Brian Foote and Joseph Yoder, Big Ball of Mud, September 1997 acs.ase.ro [email protected] 4 Anti-Pattern: Big ball of mud Where from ? Why ? • Throwaway code - Temporary (Prototyping) solutions to be replaced / rewritten • Cut and Paste code • Adapting code by commenting / deleting other solutions • Very short or unrealistic deadlines • Lack of experience • Lack of standards / procedures acs.ase.ro [email protected] 5 Anti-Pattern: Big ball of mud How do you avoid it? • Rewriting the code (Refactoring) to an acceptable maturity level • Use Clean Code Principles • Design Patterns Implementation acs.ase.ro [email protected] 6 Design-pattern • A pattern is a reusable solution for a standard problem in a given context • Facilitates the reuse of architectures and software design • They are not data structures acs.ase.ro [email protected] 7 Design-pattern “A pattern involves a general “..
    [Show full text]
  • Reducing Maintenance Costs Through the Application of Modern Software Architecture Principles
    Reducing Maintenance Costs Through the Application of Modern Software Architecture Principles Christine Hulse and Michael Ubnoske Louis Vazquez Scott Edgerton Architecture Technology Department of the Army United Defense, LP Minneapolis, Minnesota Picatinny Arsenal, Minneapolis, Minnesota 1.612.829.5864 New Jersey 1.612.572.6109/6156 [email protected] 1.973.724.5259 [email protected] [email protected] [email protected] 1. ABSTRACT 1.1 Keywords Large software programs are usually long lived Architecture, design patterns, software maintenance, modeling, real-time software and continually evolve. Substantial maintenance effort is often extended by 2. INTRODUCTION engineers trying to understand the software The Crusader Field Artillery System is the U.S. Army's next prior to making changes. To successfully generation 155-mm self-propelled howitzer (SPH) and its companion resupply vehicle (RSV). The Crusader is a evolve the software, a thorough understanding software-intensive system that is being designed to last well of the architect's intentions about software into the next century. Ada95 is the implementation language organization is required. Software for all software development on the Crusader program. maintenance costs can be reduced significantly Modern software architecture methods are being applied to if the software architecture is well defined, capture the general principles used throughout the design and to provide a guide for further development of the clearly documented, and creates an software. The architecture is being modeled using the environment that promotes design consistency Unified Modeling Language (UML) to bring together the through the use of guidelines and design design vision of all of the key stakeholders.
    [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]
  • On the Interaction of Object-Oriented Design Patterns and Programming
    On the Interaction of Object-Oriented Design Patterns and Programming Languages Gerald Baumgartner∗ Konstantin L¨aufer∗∗ Vincent F. Russo∗∗∗ ∗ Department of Computer and Information Science The Ohio State University 395 Dreese Lab., 2015 Neil Ave. Columbus, OH 43210–1277, USA [email protected] ∗∗ Department of Mathematical and Computer Sciences Loyola University Chicago 6525 N. Sheridan Rd. Chicago, IL 60626, USA [email protected] ∗∗∗ Lycos, Inc. 400–2 Totten Pond Rd. Waltham, MA 02154, USA [email protected] February 29, 1996 Abstract Design patterns are distilled from many real systems to catalog common programming practice. However, some object-oriented design patterns are distorted or overly complicated because of the lack of supporting programming language constructs or mechanisms. For this paper, we have analyzed several published design patterns looking for idiomatic ways of working around constraints of the implemen- tation language. From this analysis, we lay a groundwork of general-purpose language constructs and mechanisms that, if provided by a statically typed, object-oriented language, would better support the arXiv:1905.13674v1 [cs.PL] 31 May 2019 implementation of design patterns and, transitively, benefit the construction of many real systems. In particular, our catalog of language constructs includes subtyping separate from inheritance, lexically scoped closure objects independent of classes, and multimethod dispatch. The proposed constructs and mechanisms are not radically new, but rather are adopted from a variety of languages and programming language research and combined in a new, orthogonal manner. We argue that by describing design pat- terns in terms of the proposed constructs and mechanisms, pattern descriptions become simpler and, therefore, accessible to a larger number of language communities.
    [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]
  • A Design Pattern Generation Tool
    Project Number: GFP 0801 A DESIGN PATTERN GEN ERATION TOOL A MAJOR QUALIFYING P ROJECT REPORT SUBMITTED TO THE FAC ULTY OF WORCESTER POLYTECHNIC INSTITUTE IN PARTIAL FULFILLME NT OF THE REQUIREMEN TS FOR THE DEGREE OF BACHELOR O F SCIENCE BY CAITLIN VANDYKE APRIL 23, 2009 APPROVED: PROFESSOR GARY POLLICE, ADVISOR 1 ABSTRACT This project determines the feasibility of a tool that, given code, can convert it into equivalent code (e.g. code that performs the same task) in the form of a specified design pattern. The goal is to produce an Eclipse plugin that performs this task with minimal input, such as special tags.. The final edition of this plugin will be released to the Eclipse community. ACKNOWLEGEMENTS This project was completed by Caitlin Vandyke with gratitude to Gary Pollice for his advice and assistance, as well as reference materials and troubleshooting. 2 TABLE OF CONTENTS Abstract ....................................................................................................................................................................................... 2 Acknowlegements ................................................................................................................................................................... 2 Table of Contents ..................................................................................................................................................................... 3 Table of Illustrations .............................................................................................................................................................
    [Show full text]
  • Additional Design Pattern Examples Design Patterns--Factory Method
    Additional Design Pattern Examples • Creational – Factory method – Abstract factory • Structural – Decorator – Adapter • Behavioral – Observer Design Patterns--Factory Method • Intent--Permit a class to be reuseable with arbitrary data types. Specifically, allow the class to be independent of the classes it instantiates – Define an interface for object creation. – Let subclasses decide which class to instantiate. • Motivation – Useful for development of frameworks 1 Factory Method--Continued • Consider a document-processing framework – High-level support for creating, opening, saving documents – Consistent method calls for these commands, regardless of document type (word-processor, spreadsheet, etc.) – Logic to implement these commands delegated to specific types of document objects. – May be some operations common to all document types. Factory Method--Continued Document Processing Example-General Framework: Document Application getTitle( ) * Edits 1 newDocument( ) newDocument( ) openDocument( ) openDocument( ) ... ... MyDocument Problem: How can an Application object newDocument( ) create instances of specific document classes openDocument( ) without being application-specific itself. ... 2 Factory Method--Continued Use of a document creation “factory”: Document Application getTitle( ) * Edits 1 newDocument( ) newDocument( ) openDocument( ) openDocument( ) ... ... 1 requestor * Requests-creation creator 1 <<interface>> MyDocument DocumentFactoryIF newDocument( ) createDocument(type:String):Document openDocument( ) ... DocumentFactory
    [Show full text]