Banaras Hindu University

Transcription

1 Banaras Hindu University

2 A Course on Software Reuse by Design Patterns and Frameworks

3 by Dr. Manjari Gupta Department of Computer Science Banaras Hindu University

4 Lecture 5 Basic Design Patterns

5 Basic Design Patterns common properties of design patterns common, basic and important design patterns in the areas of object-oriented design and programming.

6 Interface design pattern service provider objects corresponding to a specific service request are always of the same class type Client object interacts directly with the service provider object ties the client with a specific class type for a given service request may not be adequate when there is more than one class of objects provide the same service requires changes to the design and implementation of the client by other objects

7 Client

8 Client Service Provider

9 Client <<request service>> Service Provider

10 Service Provider_1 Different Classes of Service Providers Offering the Same Set of Services

11 Service Provider_1 Different Classes of Service Providers Offering the Same Set of Services Service Provider_1

12 Client Service Provider_1 Different Classes of Service Providers Offering the Same Set of Services Service Provider_2

13 Client <<request service>> Service Provider_1 Different Classes of Service Providers Offering the Same Set of Services Service Provider_2

14 Client Service Provider_1 Different Classes of Service Providers Offering the Same Set of Services Service Provider_2

15 Interface design pattern Cont interface pattern can be used to better design enable the client object to use different classes of service provider objects with little or no need for altering the client code common services abstracted out and declared as a separate interface each of the service provider classes implements this common interface

16 Client

17 Client <<Service provider_1>>

18 Client <<Service provider_1>> << Service provider_2>>

19 Client <<Interface Service IF>> <<Service provider_1>> << Service provider_2>>

20 Client <<Interface Service IF>> <<Service provider_1>> << Service provider_2>> Common Interface with Different Service Providers as Implementers

21 Client <<request service>> <<Interface Service IF>> <<Service provider_1>> << Service provider_2>> Common Interface with Different Service Providers as Implementers

22 Interface design pattern Cont client can safely assume the service provider object to be of the interface type objects of different service provider classes can be treated as objects of the interface type different types of service provider objects in a seamless manner without requiring any changes client does not need to be altered

23 Abstract Parent class design pattern useful for consistent implementation of functionality common to a set of related classes functionality outlined by abstract methods in an abstract class needs to be implemented differently subclass must implement all of the abstract methods declared in the parent abstract class ensures that the variable part of the functionality will be implemented in a consistent manner in terms of the method signatures.

24 Abstract Parent class design pattern Cont nonabstract subclasses of an abstract class can be instantiated set of methods implemented by the abstract parent class is automatically inherited by all subclasses eliminates the need for redundant implementations of these methods by each subclass.

25 Counter Subclass_1 Abstract method()

26 Counter Subclass_1 Counter Subclass_2 Abstract method() Abstract method

27 Abstract class Abstract method Counter Subclass_1 Counter Subclass_2 Abstract method() Abstract method

28 Abstract class Abstract method Counter Subclass_1 Counter Subclass_2 Abstract method() Abstract method An Abstract Class with Two Concrete Subclasses

29 Private Methods design pattern each method is designed to perform a single, defined task methods may use the functionality offered by other methods or other objects to perform the task they are designed for. Not all methods of a class are always meant to be used by external client objects object s public protocol are declared as public methods.

30 Private Methods design pattern Cont methods may exist to be used internally by other methods or inner classes of the same object Private Methods hides the behavior contained in these methods from client objects

31 Accessor methods design pattern state of an object can be grouped into two categories- public and private Public state of an object available to different client objects to access Private state of an object used internally by the object itself and not to be accessed by other objects

32 Customer id : int name :string SSN : String address: String Customer Class

33 Accessor methods design pattern Cont instance variable ID is maintained separately and used internally by each Customer class instance and not to be known by other objects the private state of a Customer object variables such as name, SSN (Social Security Number) and the address the public state of the Customer object and supposed to be used by client objects

34 Accessor methods design pattern Cont In case of such an object, accessor Method pattern recommends accessor methods to access the public state of an object prevents external client objects from accessing object instance variables directly hide from the client whether a property is stored as a direct attribute or as a derived one

35 Accessor methods design pattern Cont Client objects can make use of accessor methods to move a Customer object from one state (source) to another state (target). If target state is not reached, it should notify the caller object that the transition could not be completed. throw an exception

36 Accessor methods design pattern Cont If an object accesses its private variables directly greatly affect the maintainability of an application if an object access its instance variables through accessor methods any change to the definition of an instance variable requires a change only to its accessor methods.

37 Constant data manager design pattern data used by an object can either be variable data or constant data. useful for designing an efficient storage mechanism for the constant data used by different objects recommends all such constant data be kept in a separate object and accessed by other objects in the application. easy to maintain, centralized repository for the constant data in an application

38 customer data management Account final ACCOUNT_DATA_FILE : String = ACCOUNT.TXT final VALID_MIN_LNAME_LEN : int =2 Save () Address final ADDRESS_DATA_FILE : String = ADDRESS.TXT final VALID_MIN_LNAME_LEN : int =2 final VALID_MIN_LNAME_LEN : int =2 final DEFAULT_COUNTRY : String = USA Save () CreditCard Save final CC_DATA_FILE : String = CC.TXT final VALID_CC_CHARS : String = final MASTER : String = MASTER final VISA : String = VISA final DISCOVER : String = DISCOVER

39 Address save () ConstantDataManager final ACCOUNT_DATA_FILE : String = ACCOUNT.TXT final VALID_MIN_LNAME_LEN : int =2 final ADDRESS_DATA_FILE : String = ADDRESS.TXT final VALID_MIN_LNAME_LEN : int =2 final VALID_MIN_LNAME_LEN : int =2 final DEFAULT_COUNTRY : String = USA final CC_DATA_FILE : String = CC.TXT final VALID_CC_CHARS : String = final MASTER : String = MASTER final VISA : String = VISA final DISCOVER : String = DISCOVER save () Account save () CreditCard save ()

40 Immutable object design pattern data model classes instances of these classes are referred to as data objects several client objects may simultaneously access instances of such data model classes changes to the state of a data object may not coordinated properly ensures the concurrent access to a data object by several client objects without any problem without involving the overhead of synchronizing the methods to access the object data

41 Immutable object design pattern Cont Applying the immutable object pattern, instances of the data model class become immutable data of an immutable object cannot be modified makes it automatically thread-safe and eliminates any concurrent access related problems designing an object as immutable is an important decision If objects that were once thought of as immutable are in fact mutable could result in difficult implementation changes

42 Employee and EmployeeModel class representation Employee firstname : String lastname : String SSN : String address : String car : Car getfirstname () : String getlastname () : String getssn () : String getaddress () : String getcar () : Car setfirstname (fname : String) setlastname (lname : String) setssn (ssn : String) setaddress (addr : String) setcar (c : Car) save () : boolean delete () : boolean isvalid () : boolean update () : boolean firstname : String lastname : String SSN : String address : String car : Car EmployeeModel getfirstname () : String getlastname () : String getssn () : String getaddress () : String getcar () : Car setfirstname (fname : String) setlastname (lname : String) setssn (ssn : String) setaddress (addr : String) setcar (c : Car)

43 EmployeeModel Class: Immutable Version final class EmployeeModel final firstname : String final lastname : String final SSN : String final address : String final car : Car getfirstname () : String getlastname () : String getssn () : String getaddress () : String getcar () : Car return car.clone ();

44 Monitor design pattern an object may need to access shared resources methods of such an object are accessed simultaneously by more than one thread, could result in unpredictable behavior- race condition ensures only one thread to execute any method on that object at any given time. service provider object itself responsible to ensure that no two threads can execute its methods simultaneously In Java, using the synchronized keyword

45