1 / 53

Software Design

Software Design. Lecture : 35. Façade Design Pattern. Scenario – Building a Movie Theatre. You have decided to build your own home theatre compromising of the some what following components: DVD Player Sound Systems Amplifiers Projector Screen CD Player Theatre Lights etc

braima
Télécharger la présentation

Software Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Design Lecture : 35

  2. Façade Design Pattern

  3. Scenario – Building a Movie Theatre • You have decided to build your own home theatre compromising of the some what following components: • DVD Player • Sound Systems • Amplifiers • Projector • Screen • CD Player • Theatre Lights etc • You have spend a lot of time making all the connections to make it work

  4. Classes in Building Home Theatre

  5. Steps in Watching the Movie • Dim the lights • Turn the projector on • Connect DVD to Projector • Turn on the sound Amplifier on • Connect Amplifier input to DVD • Adjust the sound • Set the DVD Player on • Watch the movie • Exhausted !!! Is it that difficult to watch a movie • Think about turning off the Home Theatre

  6. Need for Simplicity • At this point in time Façade is what you need • Façade let you use the complex system by providing a simple interface to use the complex sub systems • Power of subsystems is still there but the complexity is reduced by availability of simpler interface to interact with

  7. Simplified Class Diagram

  8. Façade Design Pattern Defined • Façade provides a unified interface to a set of interfaces in a subsystem. It define a higher level interface which is easier to use

  9. Façade Design Pattern continue… • Façade decouple the client from interacting with the subsystems instead Façade take up the responsibility of dealing with the subsystems itself. • Façade will not add any extra functionality it will just simply the access to functionality. • Client can also access subsystems directly as if there is no Façade.

  10. Client Access without Facade

  11. Client Access with Facade

  12. Class Diagram of Facade

  13. New Software Design Principle • The Principle of Least Knowledge “Talk only to your immediate friends” • When creating software design for any object be careful of the number of classes it is interacting with and how it will be interacting with them

  14. Guidelines for Implementing Principle • Suppose we have an object with several methods, now for that object we should invoke methods only that belongs to: • An Object itself • Object passed in as a parameter • Any method that object creates or instantiates. • Any component of the Object

  15. Rules Explained with Example

  16. Applying Principle in Facade • There can be several Façade within One Façade with the increase in complexity. • We aim to maintain minimum possible communication with other classes.

  17. Example For an typical online transaction oriented system, customer can perform transactions against an account i-e Pay pal etc; credit card validators are used for verifying the creditionals of a client submitted by the client for checkout purposes. Address of the customer is also stored and checked for data entry checks for shipment purposes. Usually account, address and credit card subsystems works together to provide the feature of online transaction.

  18. To Do Tasks: • Build an application which perform the following tasks • Accepts customer details (account, address and credit card details) • Validates the input data • Saves the input data to appropriate data files • Assuming there are three classes and each class is having its own validation and data storage mechanism

  19. Sequence Diagram of System

  20. Sequence Diagram with Facade

  21. Advantages of Facade • It shields the client from subsystem components, thereby reducing the number of objects that clients have to deal with. • It promote weak coupling between the subsystems and its client. • Clients can directly access subsystems also, it provide choice between ease use and generality

  22. Software Design Lecture : 36

  23. Composite Design Pattern

  24. Motivation for Composite Design Pattern • Every component or object can be classified into one of the two categories — • Individual Components • Composite Components — which are composed of individual components or other composite components

  25. Intend of Composite Design Pattern • To have a common interface for both individual and composite components so that client programs can view both the individual components and groups of components uniformly. • Usually a Tree structure having nodes and leave nodes represents composite and individual components respectively.

  26. Discussion on Whole-Part relation

  27. Aggregation or “ has –a “ relationship • Specialized form of association i-e Weak Association. • Assembling a class from other classes. • Aggregation is a special type of relationship used to model a "whole to its parts" relationship • Part class is independent from the whole class's lifecycle.

  28. Aggregation • In an aggregation relationship, the child class instance can outlive its parent class. • Child class can be a part of multiple parent classes. • To represent an aggregation relationship, you draw a solid line from the parent class to the part class, and draw an unfilled diamond shape on the parent class's association end

  29. Example

  30. Aggregation Example

  31. Tree Structure Revisited

  32. Composite Pattern Defined • Composite Design pattern allow us to compose objects into tree structures to represent whole-part hierarchy . It let the client handle the composite and individual components in a uniform manner

  33. Class Diagram of Composite Design Pattern

  34. Example of Composite Pattern • 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 or leaf node of a tree structure.

  35. Design Approach • Let us define a common interface for both directories and files in the form of a Java interface FileSystemComponent The FileSystemComponent interface declares methods that are common for both file components and directory components. Let us further define two classes — FileComponent and DirComponent — as implementers of the common FileSystemComponent interface as shown in next slide

  36. Class Diagram of Proposed Approach

  37. Description of Classes • FileComponent The FileComponent class represents a file in the file system and offers implementation for the following methods. • getComponentSize() • This method returns the size (in kilobytes) of the file represented by the File- Component object.

  38. Class Descriptions • DirComponent This class represents a directory in the file system. Since directories are composite entities, the DirComponent provides methods to deal with the components it contains. These methods are in addition to the common getComponentSize method declared in the FileSystemComponent interface.

  39. Class Description • addComponent(FileSystemComponent) This method is used by client applications to add different DirComponent and FileComponent objects to a DirComponent object. • getComponent(int) The DirComponent stores the other FileSystemComponent objects inside a vector. This method is used to retrieve one such object stored at the specified location.

  40. Class Description • getComponentSize() This method returns the size (in kilobytes) of the directory represented by the DirComponent object. As part of the implementation, the DirComponent object iterates over the collection of FileSystemComponent objects it contains, in a recursive manner, and sums up the sizes of all individual FileComponents. The final sum is returned as the size of the directory it represents.

  41. Processing of Class Diagram A typical client would first create a set of FileSystemComponent objects (both DirComponent and FileComponent instances). It can use the addComponent method of the DirComponent to add different FileSystemComponents to a DirComponent, creating a hierarchy of file system (FileSystemComponent) objects.

  42. Calculating the Size of Object When the client wants to query any of these objects for its size, it can simply invoke the getComponentSize method. The client does not have to be aware of the calculations involved or the manner in which the calculations are carried out in determining the component size. In this aspect, the client treats both the FileComponent and the DirComponent object in the same manner. No separate code is required to query FileComponent objects and DirComponent objects for their size.

  43. Problem in Current Design • Client to keep track when calling a non-common method like addcomponent and getcomponent as these methods exists only in DirComponent

  44. Design Approach -II 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

More Related