April 18, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Pattern Summaries: Fundamental Patterns, Page 2

  • August 26, 2003
  • By Mark Grand, Mark Grand
  • Send Email »
  • More Articles »

Immutable

In situations where multiple objects share access to the same object, problems can arise if changes to the shared object are not properly coordinated between objects that share it. Coordinating changes to an object can require careful programming that is easy to get wrong. If the changes to and fetches of the shared objects’ state are done asynchronously, then in addition to the greater likelihood of bugs, correctly functioning code will have the overhead of synchronizing the accesses to the shared objects’ state.

The Immutable pattern avoids these problems. It organizes a class so that the state information of its instances never changes after they are constructed.

Suppose that you are writing a game program that involves the placement and occasional movement of objects on a playing field. In the course of designing the classes for that program, you decide that you want to use immutable objects to represent the position of objects on the playing field. The organization of a class for modeling position that way might look like this:


Figure 2: Immutable position.

The position that a Position object represents is passed into its constructor. The Position class has methods to get the x and y value of the position its instances prepresent. It deliberately does not have any methods to change the x or y value of the position that a Position object represents. To represent a new position of a game piece, you create a new Position object.

A very commonly used class from the core Java API that is immutable is java.lang.String.

Though the Immutable pattern is not used by a lot of other patterns, it is fundamental in the sense that it is used extensively in the APIs that come with Java. It also turns up in a lot of programs.

Proxy

Proxy is a pattern that occurs in a number of forms. The type of problem that it is intended to solve is the need to manage access to an object that provides a servce in a way that is transpartent to objects that use the service.

A proxy object is an object that receives method calls on behalf of another object. Client objects call the proxy object’s method. The proxy object’s methods do not directly provide the service that its clients expect. Instead, the proxy object's methods call the methods of the actual object that provides the service. Here is a diagram showing that structure:


Figure 3: Method calls through a proxy.

Though a proxy object’s methods do not directly provide the service its clients expect, the proxy object manages access to those services. Proxy objects generally share a common interface with the service-providing object. Whether client objects directly access a service providing object or a proxy, they access it through the common interface, rather than as an instance of a particular class. This allows client objects to be unaware that they are calling the methods of a proxy object rather than the methods of the actual service-providing object.


Figure 4: Proxy class diagram.

There are many different types of access management that a proxy can be used to provide. Some of the more important ones will be described in future articles as patterns in their own right. Here are some of the more common uses for proxies:

  • Make a method that can take a long time to complete appear to return immediately.
  • Create the illusion that an object that exists on a different machine is an ordinary local object. This kind of proxy is called a remote proxy. It is used by RMI, CORBA, and other object request brokers.
  • Control access to a service-providing object based on a security policy. This use of proxy is the Protection Proxy pattern.
  • Create the illusion that a service object exists before it actually does. This can be useful if a service object is expensive to create and its services may not be needed. This use of proxies is the Virtual Proxy pattern.

About the author

Mark Grand is the author of a series of books titled Patterns in Java. He is currently the chief architect of an application framework for e-commerce called EBox. Mark Grand can be contacted at mgrand@mindspring.com.



Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel