Đang tải... (xem toàn văn)
Software design - Lecture 37. The main topics covered in this chapter include: flyweight design pattern; motivation for flyweight design pattern; intrinsic information - shareable; extrinsic information – not shareable; heavyweight object nightmare;...
1 Software Design Lecture : 37 Flyweight Design Pattern Motivation for Flyweight Design Pattern At time some programs require a large number of objects that have some shared state among them Every object can be viewed as consisting of one or both of the following two sets of information: i Intrinsic ii Extrinsic Intrinsic Information Shareable The intrinsic information of an object is independent of the object context. That means the intrinsic information is the common information that remains constant among different instances of a given class For example, the company information on a visiting card is the same for all employees Extrinsic Information – Not Shareable The extrinsic information of an object is dependent upon and varies with the object context. That means the extrinsic information is unique for every instance of a given class For example, the employee id , employee name and title are extrinsic on a visiting card as this information is unique for every employee Heavyweight Object nightmare Consider an application scenario that involves creating a large number of objects that are unique only in terms of a few parameters. In other words, these objects contain some intrinsic, invariant data that is common among all objects This intrinsic data needs to be created and maintained as part of every object that is being created. The overall creation and maintenance of a large group of such objects can be very Intent of Flyweight Design Pattern The intent of this pattern is to use sharing to support a large number of objects that have part of their internal state in common where the other part of state can vary • Flyweight Pattern Defined “Facilitates the reuse of many fine grained objects, making the utilization of large numbers of objects more efficient” Applicability i An application uses large number of objects ii Storage costs are high due to quantity of objects iii Most object state can be made extrinsic iv Many group of objects may be replaced by relatively few shared objects once extrinsic objects are removed v The application doesn’t depend upon on object identify as flyweight objects can be shared and identity test will return distinct objects 10 Suggested Approach in Flyweight The Flyweight pattern suggests separating all the intrinsic common data into a separate object referred to as a Flyweight object • The group of objects being created can share the flyweight object as it represents their intrinsic state 16 Class Diagram 17 18 Flyweight Declares an interface through which flyweights can receive and act on extrinsic state Concrete Flyweight Implements the Flyweight interface and stores intrinsic state. A Concrete Flyweight object must be sharable. The Concrete flyweight object must maintain state that it is intrinsic to it, and must be able to manipulate state that is extrinsic 19 Flyweight Factory The factory creates and manages flyweight objects. In addition the factory ensures sharing of the flyweight objects. The factory maintains a pool of different flyweight objects and returns an object from the pool if it is already created, adds one to the pool and returns it in case it is new Client A client maintains references to flyweights in addition to computing and maintaining extrinsic state 20 Flow of the application 21 A client needs a flyweight object; it calls the factory to get the flyweight object. The factory checks a pool of flyweights to determine if a flyweight object of the requested type is in the pool, if there is, the reference to that object is returned. If there is no object of the required type, the factory creates a flyweight of the requested type, adds it to the pool, and returns a reference to the flyweight. 22 The flyweight maintains intrinsic state (state that is shared among the large number of objects that we have created the flyweight for) and provides methods to manipulate external state (State that vary from object to object and is not common among the objects we have created the flyweight for) 23 Flyweight and other design patterns Factory and Singleton patterns Flyweights are usually created using a factory and the singleton is applied to that factory so that for each type or category of flyweights a single instance is returned 24 Consequence Flyweight pattern saves memory by sharing flyweight objects among clients. The amount of memory saved generally depends on the number of flyweight categories saved 25 Example Scenario 26 In a war game , there is a large number of soldier objects; a soldier object maintain the graphical representation of a soldier, soldier behavior such as motion, and firing weapons, in addition soldiers health and location on the war terrain. Creating a large number of soldier objects is a necessity however it would incur a huge memory cost. Note that although the representation and behavior of a soldier is the same their health and location can vary greatly 27 Example Scenario Continue The war game instantiates 5 Soldier clients, each client maintains its internal state which is extrinsic to the soldier flyweight. And Although 5 clients have been instantiated only one flyweight Soldier has been used 28 29 Flow of Application Soliderclient SoldierFactorysoldier impl(flyewight) Solider factory uses singleton design pattern to maintain one single instance of intrinsic or common objects ie Soldier impl for all the extrinsic objects 30 package flyweight; /** * Flyweight Interface * */ public interface Soldier { /** Move Soldier From Old Location to New Location Note that soldier location is extrinsic to the SoldierFlyweight Implementation */ public void moveSoldier(int previousLocationX, previousLocationY , int newLocationX ,int newLocationY); } int