DOCSLIB.ORG

Design Patterns

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design Patterns Design Patterns Partha Kuchana, Software Architecture Design Patterns in Java, Auerbach Publications, 2004. Contents I. Basic Patterns 1. Interface Pattern 2. Abstract Parent Class Pattern II. Creational Patterns III. Collectional Patterns 1. Composite Pattern 2. Visitor Pattern IV. Structural Patterns 1. Adapter Pattern 2 Contents V. Behavioral Patterns 1. Command Pattern 2. State Pattern 3 I. Basic Patterns 1. Interface Pattern 2. Abstract Parent Class Pattern 4 I.1 The Interface Pattern The Interface pattern can be used to design a set of service provider classes that offer the same service so that a client object can use different classes of service provider objects in a seamless manner without having to alter the client implementation. 5 I.1 The Interface Pattern Problem: Client-Service Provider Interaction An object that requests a service from another object is referred as a client object. An object that provides a service is called a service provider object. (a) One class of service provider 6 I.1 The Interface Pattern (b) More than one class of service providers It will not be able to make use of the different classes of service provider objects in a seamless manner. It requires changes to the design and implementation of the client and greatly reduces the reusability of the client by other objects. 7 I.1 The Interface Pattern Applying the Interface pattern, the common services offered by different service provider classes can be abstracted out and declared as a separate interface. Each of the service provider classes can be designed as implementers of this common interface. 8 I.1 The Interface Pattern Common interface with different service providers as implementers 9 I.1 The Interface Pattern An example: Let us build an application to calculate and display the salaries of different employees of an organization with the categorization of designations as listed in the following table Designations Category Programmer, Designer, Consultant Category-A Sales Rep, Sales Manager, Account Rep Category-B ... ... C-Level Executives Category-n ... ... 10 I. Interface This design works fine as long as the need is to calculate the salary for Category-A employees only and there is only one class of objects that provides this service. 11 I.1 The Interface Pattern Let us assume that the application also needs to calculate the salary of employees who are part of Category-B, such as sales representatives and account representatives, and the corresponding salary calculation service is provided by objects of a different class CategoryB 12 I.1 The Interface Pattern The main application will not be able to reuse the existing Employee class to represent different types of employees. This is because the Employee object expects the salary calculator to be always of the CategoryA type. 13 I.1 The Interface Pattern Applying the Interface pattern 14 15 16 Practice Questions 1. Design a Search interface that declares methods for searching an integer in an ordered list of integers. Design and implement two implementers - BinarySearch and LinearSearch - to conduct a binary and linear search of the list, respectively. 2. Pizza Mania (ref. Rice University) Pizza Mania is having a special on the same kind of pizza (i.e. same thickness and same ingredients). The special comes in two shapes: rectangular (4" by 6") for $4.99 and round (5" in diameter) for $3.99. Which one is the better deal? Write a program to solve this problem. 17 Practice Questions A pizza has a price and a shape. We want to compute the price/area ratio. It is the shape that intrinsically "knows" how to compute its area. A shape is an abstract concept. The area of a shape is an abstract computation. A rectangle is a concrete and specific shape. A rectangle knows its own width and height and therefore can compute its area in some concrete and specific way. A circle is a concrete and specific shape. A circle knows its own diameter and therefore can compute its area in some concrete and specific way. 18 19 I.2 The Abstract Parent Class Pattern This pattern is useful for designing a framework for the consistent implementation of the functionality common to a set of related classes. 20 I.2 The Abstract Parent Class Pattern In the Java there is no support for multiple inheritance. That means a class can inherit only from one single class. Hence inheritance should be used only when it is absolutely necessary. Whenever possible, methods denoting the common behavior should be declared in the form of a Java interface to be implemented by different implementer classes. 21 I.2 The Abstract Parent Class Pattern But interfaces suffer from the limitation that they cannot provide method implementations. This means that every implementer of an interface must explicitly implement all methods declared in an interface, even when some of these methods represent the invariable part of the functionality and have exactly the same implementation in all of the implementer classes. This leads to redundant code. The Abstract Parent Class pattern can be used in such cases without requiring redundant 22 method implementations. I.2 The Abstract Parent Class Pattern 23 I.2 The Abstract Parent Class Pattern An example: Let us consider the following operations as part of designing the representation of an employee. (1) Access employee attributes such as name and ID (2) Display employee data (3) Calculate compensation While Operation 1 and Operation 2 remain the same for all employees, the compensation calculation will be different for employees with different designations. 24 I.2 The Abstract Parent Class Pattern Each of the subclasses must implement the computeCompensation method. 25 I.2 The Abstract Parent Class Pattern Abstract Parent Class versus Interface As an alternate design strategy, we could design the employee representation as a Java interface, instead of designing it as an abstract class, with both the Consultant and the SalesRep classes as its implementers. 26 I.2 The Abstract Parent Class Pattern All methods specified in the interface remains the same for all implementers, this leads to redundant code in the application. The implementation of these invariable methods cannot be made part of the interface. An interface is used for the declaration purpose only. By designing the Employee class as an abstract class, the need for a redundant implementation can be eliminated. 27 II. Creational Patterns 28 III. Collectional Patterns 1. Composite Pattern 2. Visitor Pattern 29 III.1 Composite Patterns Every component or object can be classified into one of the two categories Individual Components or Composite Components, which are composed of individual components or other composite components. The Composite pattern is useful in designing a common interface for both individual and composite components. Client programs can view both the individual components and groups of components uniformly. 30 III.1 Composite Pattern In other words, the Composite design pattern allows a client object to treat both single components and collections of components in an identical manner. This can also be explained in terms of a tree structure. The Composite pattern allows uniform reference to both Nonterminal nodes (which represent collections of components or composites) and terminal nodes (which represent individual components). 31 III.1 Composite Pattern An example: Let us create an application to simulate the Windows/UNIX file system. The file system consists mainly of two types of components directories and files. Directories can be made up of other directories or files, whereas files cannot contain any other file system component. In this aspect, directories act as nonterminal nodes and files act as terminal nodes of a tree structure. 32 III.1 Composite Pattern Design Approach I Define a common interface for both directories and files in the form of an interface FileSystemComponent. The FileSystemComponent interface declares methods that are common for both file components and directory components. FileComponent and DirComponent are defined as implementers of the common FileSystemComponent interface 33 III.1 Composite Pattern 34 Design Approach I The client treats both the FileComponent and DirComponent objects in a uniform manner in the case of the common getComponentSize method. The client does need to distinguish when calling composite specific methods such as addComponent and getComponent defined exclusively in the DirComponent. Because these methods are not available with FileComponent objects, the client needs to check to make sure that the FileSystemComponent object35 it is working with is in fact a DirComponent object. Design Approach II The objective of this approach is to: Provide the same advantage of allowing the client application to treat both the composite DirComponent and the individual FileComponent objects in a uniform manner while invoking the getComponentSize method. 36 Design Approach II The FileSystemComponent provides the default implementation for these methods and is designed as an abstract class. 37 Design Approach II The default implementation of these methods consists of what is applicable to FileComponent objects. FileComponent objects are individual objects and do not contain other FileSystemComponent objects within. Hence, the default implementation does nothing and simply throws a custom CompositeException exception. The derived composite DirComponent class overrides these methods to provide custom implementation. 38 Practice Questions 1. There is an abstract notion of a list. 1. An empty list is a list. It has no element. 2. A non-empty list is a list. It has an element called first and an element called rest, which is itself another list. Design and implement an application to display all elements in a list. 2. A typical product database consists of two types of product components — product categories and product items. A product category is generally composite in nature. It can contain product items and also other product categories as its subcategories.
Load more

Recommended publications
  • The Command Dispatcher Pattern Benoit Dupire and Eduardo B Fernandez {[email protected], [email protected]}
    The Command Dispatcher Pattern Benoit Dupire and Eduardo B Fernandez {[email protected], [email protected]} Department of Computer Science and Engineering. Florida Atlantic University Boca Raton, FL 33431 Can also be called: Command Evaluator Pattern. Intent This pattern increases the flexibility of applications by enabling their services to be changed, by adding, replacing or removing any command handlers at any point in time without having to modify, recompile or statically relink the application. By simulating the command-evaluation feature common in interpreted languages, this pattern supports the need for continual, incremental evolution of applications. Example Autonomous Underwater Vehicles (AUVs) are small, unmanned, untethered submersibles. There are numerous applications for AUVs, such as oceanographic surveys, operations in hazardous environments, underwater structure inspection and military operations. We implement the high level controller of this AUV as a Hierarchical Finite State Machine (Figure 1). A state of the Finite State Machine (FSM) represents a mode of the system, in which some tasks have to be executed, as described in the mission plan. The system takes transitions based on the results of these actions and the progression of the AUV. The system is programmed with high-level commands of the style "set depth 3" state1 state2 action 1.1 action 2.1 Figure 1: Simplified Finite State Machine for the AUV. The FSM must be able to fire any type of actions, without knowing anything about them. This problem is addressed by the Command Pattern [GOF95], which encapsulates an action as an object, thereby letting you parameterize clients with different actions.
    [Show full text]
  • Design Case Study: Java Swing
    Principles of Software Construction: Objects, Design, and Concurrency Part 2: Design case studies Design case study: Java Swing Charlie Garrod Chris Timperley 17-214 1 Administrivia • Reading due today: UML and Patterns 26.1 and 26.4 • Homework 4b due Thursday, October 17th https://commons.wikimedia.org/wiki/File:1_carcassonne_aerial_2016.jpg 17-214 2 Key concepts from Thursday • Observer design pattern • Introduction to concurrency – Not enough synchronization: safety failure – Too much synchronization: liveness failure • Event-based programming • Introduction to GUIs 17-214 3 GUI programming is inherently multi-threaded • Swing event dispatch thread (EDT) handles all GUI events – Mouse events, keyboard events, timer events, etc. • No other time-consuming activity allowed on the EDT – Violating this rule can cause liveness failures 17-214 4 Swing has many event listener interfaces • ActionListener • MouseListener • AdjustmentListener • TreeExpansionListener • FocusListener • TextListener • ItemListener • WindowListener • KeyListener • … class ActionEvent { int when; String actionCommand; int modifiers; Object source(); int id; … interface ActionListener { } void actionPerformed(ActionEvent e); } 17-214 5 Aside: lambdas vs. explicit class declarations? //static public void main… JFrame window = … JPanel panel = new JPanel(); window.setContentPane(panel); panel to hold the button JButton button = new JButton(“Click me”); button.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { System.out.println(“Button
    [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 Mathematical Approach to Object Oriented Design Patterns
    06.2006 J.Natn.Sci.FoundationObject oriented design Sripatterns Lanka 2008 36 (3):219-227 219 RESEARCH ARTICLE A mathematical approach to object oriented design patterns Saluka R. Kodituwakku1*and Peter Bertok2 1 Department of Statistics and Computer Science, Faculty of Science, University of Peradeniya, Peradeniya. 2 Department of Computer Science, RMIT University, Melbourne, Australia. Revised: 27 May 2008 ; Accepted: 18 July 2008 Abstract: Although design patterns are reusable design the distribution of responsibilities. For ease of learning elements, existing pattern descriptions focus on specific and reference, in1, design patterns are organized into a solutions that are not easily reusable in new designs. This paper catalogue. introduces a new pattern description method for object oriented design patterns. The description method aims at providing a The catalogue is formed by two criteria: purpose more general description of patterns so that patterns can be and scope. According to their purpose, design patterns readily reusable. This method also helps a programmer to are classified into creational, structural and behavioural, analyze, compare patterns, and detect patterns from existing software programmes. whereas the scope divides patterns into class patterns and object patterns. Class patterns capture relationships This method differs from the existing pattern description between classes and their subclasses; object patterns deal methods in that it captures both static and dynamic properties with relationships between objects. of patterns. It describes them in terms of mathematical entities rather than natural language narratives, incomplete graphical Software patterns provide reusable solutions to notations or programme fragments. It also helps users to recurring design problems. Even if we have reusable understand the patterns and relationships between them; and solutions they may not be effectively reused, because select appropriate patterns to the problem at hand.
    [Show full text]
  • Lecture 1 for Chapter 8, Object Design: Reusing Pattern Solutions
    Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 8, Object Design: 8, Object Chapter Reuse and Patterns I and Patterns Reuse Object Design Object design is the process of adding details to the requirements analysis and making implementation decisions The object designer must choose among different ways to implement the analysis model with the goal to minimize execution time, memory and other measures of cost Requirements Analysis: Use cases, functional and dynamic model deliver operations for object model Object Design: Iterates on the models, in particular the object model and refine the models Object Design serves as the basis of implementation System Development as a Set of Activities System Problem Application objects Analysis Solution objects Design Custom objects - Object Design Off-the-Shelf Components - System Design Existing Machine Examples of Object Design Activities Identification of existing components Full definition of associations Full definition of classes (System Design => Service, Object Design => Subsystem interfaces/API) Choosing algorithms and data structures Identifying possibilities of reuse Detection of solution-domain classes Optimization Increase of inheritance Decision on control …… A More Detailed View of Object Design Activities Select Subsystem Specification Reuse Identifying missing Identifying components attributes & operations Specifying visibility Adjusting components Specifying types & signatures Identifying patterns Specifying constraints Specifying exceptions
    [Show full text]
  • The Scalable Adapter Design Pattern: Enabling Interoperability Between Educational Software Tools
    The Scalable Adapter Design Pattern: Enabling Interoperability Between Educational Software Tools Andreas Harrer, Catholic University Eichstatt-Ingolstadt,¨ Germany, Niels Pinkwart, Clausthal University of Technology, Germany, Bruce M. McLaren, Carnegie Mellon University, Pittsburgh PA, U.S.A., and DFKI, Saarbrucken,¨ Germany, and Oliver Scheuer, DFKI, Saarbrucken,¨ Germany Abstract For many practical learning scenarios, the integrated use of more than one learning tool is educationally beneficial. In these cases, interoperability between learning tools - getting the pieces to talk to one another in a coherent, well-founded manner - is a crucial requirement that is often hard to achieve. This paper describes a re-usable software design that aims at the integration of independent learning tools into one collaborative learning scenario. We motivate the usefulness and expressiveness of combining several learning tools into one integrated learning experience. Based on this we sketch software design principles that integrate several existing components into a joint technical framework. The feasibility of the approach, which we name the “Scalable Adapter” design pattern, is shown with several implementation examples from different educational technology domains, including Intelligent Tutoring Systems and collaborative learning environments. IEEE keywords: J.m Computer applications, H.5.3 Group and Organization interfaces, K.3.m Computers in Education A short version of this paper appeared in the Proceedings of the Conference on Intelligent Tutoring Systems 2008 1 The Scalable Adapter Design Pattern: Enabling Interoperability Between Educational Software Tools1 I. INTRODUCTION hypothesis and plans. In order to help the student or student In the field of educational technology, there have been groups during the different steps of this inquiry procedure, it numerous attempts in recent years to connect differently makes sense to enable them to have hypotheses, experimenta- targeted learning environments to one another.
    [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]
  • 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]
  • Design Patterns Adapter Pattern
    DDEESSIIGGNN PPAATTTTEERRNNSS -- AADDAAPPTTEERR PPAATTTTEERRNN http://www.tutorialspoint.com/design_pattern/adapter_pattern.htm Copyright © tutorialspoint.com Adapter pattern works as a bridge between two incompatible interfaces. This type of design pattern comes under structural pattern as this pattern combines the capability of two independent interfaces. This pattern involves a single class which is responsible to join functionalities of independent or incompatible interfaces. A real life example could be a case of card reader which acts as an adapter between memory card and a laptop. You plugin the memory card into card reader and card reader into the laptop so that memory card can be read via laptop. We are demonstrating use of Adapter pattern via following example in which an audio player device can play mp3 files only and wants to use an advanced audio player capable of playing vlc and mp4 files. Implementation We have a MediaPlayer interface and a concrete class AudioPlayer implementing the MediaPlayer interface. AudioPlayer can play mp3 format audio files by default. We are having another interface AdvancedMediaPlayer and concrete classes implementing the AdvancedMediaPlayer interface. These classes can play vlc and mp4 format files. We want to make AudioPlayer to play other formats as well. To attain this, we have created an adapter class MediaAdapter which implements the MediaPlayer interface and uses AdvancedMediaPlayer objects to play the required format. AudioPlayer uses the adapter class MediaAdapter passing it the desired audio type without knowing the actual class which can play the desired format. AdapterPatternDemo, our demo class will use AudioPlayer class to play various formats. Step 1 Create interfaces for Media Player and Advanced Media Player.
    [Show full text]