Design patterns in Java SJSU.edu, 2014.pdf

(918 KB) Pobierz
Design Patterns
in Java
© 2004 by CRC Press LLC
2
BASIC PATTERNS
The patterns discussed in this section are some of the most common, basic and
important design patterns one can find in the areas of object-oriented design and
programming. Some of these fundamental design patterns, such as the Interface,
Abstract Parent, Private Methods, etc., are used extensively during the discussion
of the other patterns in this book.
Chapter
Pattern Name
Description
3
4
5
6
7
8
Can be used to design a set of service provider classes
that offer the same service so that a client object can
use different classes of service provider objects in a
seamless manner without having to alter the client
implementation.
Abstract Parent Useful for designing a framework for the consistent
Class
implementation of the functionality common to a set of
related classes.
Private Methods Provide a way of designing a class behavior so that
external objects are not permitted to access the
behavior that is meant only for the internal use.
Accessor
Provide a way of accessing an object’s state using specific
Methods
methods. This approach discourages different client
objects from directly accessing the attributes of an
object, resulting in a more maintainable class structure.
Constant Data
Useful for designing an easy to maintain, centralized
Manager
repository for the constant data in an application.
Immutable
Used to ensure that the state of an object cannot be
Object
changed. May be used to ensure that the concurrent
access to a data object by several client objects does not
result in race conditions.
Interface
3
The Java programming language has built-in support for some of the funda-
mental design patterns in the form of language features. The other fundamental
patterns can very easily be implemented using the Java language constructs.
4
3
INTERFACE
This pattern was previously described in Grand98.
DESCRIPTION
In general, the functionality of an object-oriented system is encapsulated in the
form of a set of objects. These objects provide different services either on their
own or by interacting with other objects. In other words, a given object may rely
upon the services offered by a different object to provide the service it is designed
for. An object that requests a service from another object is referred as a client
object. Some other objects in the system may seek the services offered by the
client object.
From Figure 3.1, the client object assumes that the service provider objects
corresponding to a specific service request are always of the same class type and
interacts directly with the service provider object. This type of direct interaction
ties the client with a specific class type for a given service request. This approach
works fine when there is only one class of objects offering a given service, but
may not be adequate when there is more than one class of objects that provide
the same service required by the client (Figure
3.2).
Because the client expects
the service provider to be always of the same class type, it will not be able to
make use of the different classes of service provider objects in a seamless manner.
It requires changes to the design and implementation of the client and greatly
reduces the reusability of the client by other objects.
In such cases, the Interface pattern can be used to better design different
service provider classes that offer the same service to enable the client object to
use different classes of service provider objects with little or no need for altering
Client
ServiceProvider
service()
<<requests service>>
Figure 3.1 Client–Service Provider Interaction
5

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin