Đang tải... (xem toàn văn)
Software design - Lecture 35. The main topics covered in this chapter include: façade design pattern; scenario – building a movie theatre; classes in building home theatre; simplified class diagram; client access without facade; class diagram of facade;...
1 SoftwareDesign Lecture:35 FaỗadeDesignPattern ScenarioBuildingaMovieTheatre You have decided to build your own home theatre compromising of the some what following components: i DVD Player ii.Sound Systems iii.Amplifiers iv.Projector v.Screen vi.CD Player vii.Theatre Lights etc You have spend a lot of time making all the connections to make it work Classes in Building Home Theatre Steps in Watching the Movie i Dim the lights ii Turn the projector on iii Connect DVD to Projector iv Turn on the sound Amplifier on v Connect Amplifier input to DVD vi Adjust the sound vii Set the DVD Player on viii.Watch the movie Exhausted!!!Isitthatdifficulttowatchamovie ThinkaboutturningofftheHomeTheatre NeedforSimplicity AtthispointintimeFaỗadeiswhatyouneed 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 SimplifiedClassDiagram 10 FaỗadeDesignPatternDefined Faỗadeprovidesaunifiedinterfacetoasetof interfaces in a subsystem. It define a higher level interface which is easier to use 39 40 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 41 Design Approach Let us define a common interface for both directories and files in the form FileSystemComponent of The a Java interface 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 42 Class Diagram of Proposed Approach 43 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 44 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 FileSystemComponent interface declared in the 45 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 46 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 47 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 48 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 49 Problem in Current Design Client to keep track when calling a noncommon method like addcomponent and getcomponent as these methods exists only in DirComponent 50 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 51 52 • public abstract class FileSystemComponent { • String name; • public FileSystemComponent(String cName) { • name = cName; •} • public void addComponent(FileSystemComponent component) • throws CompositeException { • throw new CompositeException( 53 Code in Word File ... Client Access with Facade 14 Class Diagram of Facade 15 16 New? ?Software? ?Design Principle The Principle of Least Knowledge “Talk only to your immediate friends” When creating? ?software? ?design for any object be careful ... subsystems and its client Clients can directly access subsystems also, it provide 27 Software? ?Design Lecture? ?: 36 28 Composite Design Pattern 29 Motivation for Composite Design Pattern Every component or object can be classified into one ... solid line from the parent class to the part class, and draw an unfilled diamond shape on the parent class's association end 34 Example 35 Aggregation Example 36 Tree Structure Revisited 37 Composite Pattern Defined Composite Design