Unit 4 Object-Oriented Design Patterns NameStudent Number CAI XIANGHT082182A KYAW THU LINHT082238Y LI PENGFEIHT082220L NAUNG NAUNG LATTHT082195L PLATHOTTAM LINU THANKAMHT082207Y Team S06

VMCS - Existing Model

VMCS - Existing Model (cont.)‏

VMCS – Problems of Existing Model Tight Coupling Creating an object by specifying the class explicitly Dependent on specific operations ChangeGiver, CoinReceiver and DispenserController depends on MachineryController; MachineryConroller depends SimulatorControlerPanel; Makes system modulization impossible. Severely violates DIP. Makes the system unstable.

VMCS – High level view of new design Keep the current division of subsystems. Keep the reference from functional systems to Store Management System. Reduce or remove the reference between functional systems. Reduce direct reference to concrete classes. Improve the stability and extensibility.

VMCS – High level view of new design

VMCS – Issue 1 The process of store data are bind to Property file. It’s difficult to introduce other data resource, such as CSV file, or database, into the current design. Candidate Patterns Factory Pattern – Factory Method is a creational pattern. This pattern helps to model an interface for creating an object which at creation time can let its subclasses decide which class to instantiate. Abstract Factory – This pattern is one level of abstraction higher than factory pattern. This means that the abstract factory returns the factory of classes

VMCS – Solution on Issue 1 Solution – Factory Method Abstract Factory is preferred: It provides a consistent way of data resource solution for both Cash and Drink store This pattern helps to model an interface for creating an object which at creation time can let its subclasses decide which class to instantiate. ParticipantVMCS ClassDescription AbstractFactoryDataLoaderFactory Newly defined interface of producing loader objects ConcreteFactory DataLoaderPropertyFactory DataLoaderCSVFactory Newly defined class of producing loader objects with data in properties file AbstractProduct CashDataLoader DrinkDataLoader Newly defined interfaces which specifies the operations loader object need provider Product CashPropertyLoader DrinkPropertyLoader CashCSVLoader DrinkCSVLoader Loader objects. ClientStoreControllerClient

VMCS – Solution on Issue 1 (cont.)‏

VMCS –Issue 2 The current design UI design is very complex. It is very difficult to extend. Want to decouple the process of building a complex object from the parts that make up the object. Candidate Patterns Builder – Separate the construction of a complex object from its representation so that the same construction process can create different representations. Template Method – Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method les subclasses redefine certain steps of an algorithm without changing the algorithm’s structure

VMCS – Solution on Issue 2 Builder pattern is favored: Easy to change UI based on the customer requirement. Maintainability. E.g. Changing ReceivingBox’s design will not affect DrinkSelectionBox. Isolate code for construction and representation. Solution – State Pattern

VMCS – Solution on Issue 2 (cont.)‏ Builder (CustomerPanelBuilder)‏ Specifies an abstract interface for creating part of CustomerPanel object. ConcreteBuilder (DefaultCustomerPanelBuilder)‏ Constructs and assembles parts of the product by implementing the Builder interface. Director (TransactionController)‏ Constructs an object using the Builder interface. Product (CustomerPanel)‏ Represents the related object under one construciton. buildCustomerPanel builds the Panel’s internal representation and defines the process by which it’s assembled.

VMCS – Solution on Issue 2 (cont.)‏

VMCS –Issue 3 Flexibility of payment mode Extensibility of payment mode to Cash card or nets instead of inserting coins. The flexibility to add on features is possible with the current design. Candidate Patterns Command Pattern – an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters. Strategy Pattern – define a family of algorithms encapsulate each one, and make them interchangeable. Strategy lets the algorithm very independently from clients that use it.

VMCS – Solution on Issue 3 Strategy pattern is favored: Encapsulate various algorithms to do more or less the same thing. Cash card,Nets,Coins algorithms can be created. Reduce multiple conditional statements. Solution – Strategy Pattern

VMCS – Solution on Issue 3 (cont.)‏ Strategy (MoneyReceiver)‏ Declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy. ConcreteStrategy (CoinReceiver, CashCardReceiver)‏ implements the algorithm using the Strategy interface. Context (TransactionController)‏ is configured with a ConcreteStrategy object.maintains a reference to a strategy object.may define an interface that lets Strategy access its data.

VMCS – Solution on Issue 3 (cont.)‏

VMCS –Issue 4 Coordinate the activity of receiving coin, dispensing drink, giving change and terminating transaction. Reduce the coupling between TransactionController and CoinReceiver / DispenserController / ChangeGiver Candidate Patterns Command – an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters. State Pattern – represent the state of an object.This is a clean way for an object to partially change its type at runtime

VMCS – Solution on Issue 4 Solution – State Pattern State pattern is favored: It integrates the behavior of receiving coins, selecting and dispensing drinks across various situation. It simplifies the program by removing all the if-else or switch statement, and organizing them into state

VMCS – Solution on Issue 4 (cont.) Let’s treat the customer functions as a machine. Customers can take four actions: Select a drink Input coins Terminate And, the machine responds to user panel: Output – change coins, purchased drink Messages – invalid coin, drink out of stock, etc Response – total inserted coin, etc Now we build a conceptual machine.

VMCS – Solution on Issue 4 (cont.) What are the machine’s states? Waiting for selecting drink Waiting for inputting coin In maintenance. Who is the context? TransactionController For the ease of flow control, the transaction related information is wrapped inside a Transaction class.

VMCS – Solution on Issue 4 (cont.)

State Diagram

VMCS – Solution on Issue 4 (cont.)

VMCS – Issue 5 Update the panels with the real time store information change. E.g. update drink and coin store change on maintenance and machinery panels after transaction is completed; update customer panels when maintainer change drink price, etc. Avoid dependency on specific class / operations Achieve functional extensibility of the system Candidate Patterns Mediator – deals with the complexity which comes in the coding when number of classes increase. Objects no longer communicate directly with each other, but instead communicate through the mediator. Observer – the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.

VMCS – Solution on Issue 5 Let MachineryController, MaintenanceController and TransactionController implement ‘Observer’ Let StoreController implements observerable. When changes occur in store, the controller will be notified and act accordingly. Solution – Observer Pattern Observer pattern is preferred than Mediator: It decouples the relationship between store management and controllers. It provides easier functional extensibility.

VMCS – Solution on Issue 5 (cont.)