junhong

Design Pattern with java (part one)

• Messager
  The most trivial of these is the messenger, which simply packages information into an object
  to be passed around, instead of passing all the pieces around separately. Note that without the
  messenger, the code for translate() would be much more confusing to read:
• Collecting Parameter
  Messenger’s big brother is the collecting parameter, whose job is to capture information from
  the method to which it is passed. Generally, this is used when the collecting parameter is
  passed to multiple methods, so it’s like a bee collecting pollen.
  A container makes an especially useful collecting parameter, since it is already set up to
  dynamically add objects.
• Object quantity:Singleton and object pool
  Singleton:The key to creating a singleton is to prevent the client programmer from having any way to
  create an object except the ways you provide. You must make all constructors private, and
  you must create at least one constructor to prevent the compiler from synthesizing a default
  constructor for you (which it will create using package access).
• Object pool:If this is an issue, you can create a solution involving a check-out
  and check-in of the shared objects. see the following example
  //: singleton:PoolManager.java
  package singleton;
  import java.util.*;
  public class PoolManager {
  private static class PoolItem {
  boolean inUse = false;
  Object item;
  PoolItem(Object item) { this.item = item; }
  }
  private ArrayList items = new ArrayList();
  public void add(Object item) {
  items.add(new PoolItem(item));
  }
  static class EmptyPoolException extends Exception {}
  public Object get() throws EmptyPoolException {
  for(int i = 0; i < items.size(); i++) {
  PoolItem pitem = (PoolItem)items.get(i);
  if(pitem.inUse == false) {
  pitem.inUse = true;
  return pitem.item;
  }
  }
  // Fail early:
  throw new EmptyPoolException();
  // return null; // Delayed failure
  }
  public void release(Object item) {
  for(int i = 0; i < items.size(); i++) {
  PoolItem pitem = (PoolItem)items.get(i);
  if(item == pitem.item) {
  pitem.inUse = false;
  return;
  }
  }
  throw new RuntimeException(item + " not found");
  }
  } ///:~
  //: singleton:ConnectionPoolDemo.java
  package singleton;
  import junit.framework.*;
  interface Connection {
  Object get();
  void set(Object x);
  }
  class ConnectionImplementation implements Connection {
  public Object get() { return null; }
  public void set(Object s) {}
  }
  class ConnectionPool { // A singleton
  private static PoolManager pool = new PoolManager();
  public static void addConnections(int number) {
  17 z 157
  for(int i = 0; i < number; i++)
  pool.add(new ConnectionImplementation());
  }
  public static Connection getConnection()
  throws PoolManager.EmptyPoolException {
  return (Connection)pool.get();
  }
  public static void releaseConnection(Connection c) {
  pool.release(c);
  }
  }
  public class ConnectionPoolDemo extends TestCase {
  static {
  ConnectionPool.addConnections(5);
  }
  public void test() {
  Connection c = null;
  try {
  c = ConnectionPool.getConnection();
  } catch (PoolManager.EmptyPoolException e) {
  throw new RuntimeException(e);
  }
  c.set(new Object());
  c.get();
  ConnectionPool.releaseConnection(c);
  }
  public void test2() {
  Connection c = null;
  try {
  c = ConnectionPool.getConnection();
  } catch (PoolManager.EmptyPoolException e) {
  throw new RuntimeException(e);
  }
  c.set(new Object());
  c.get();
  ConnectionPool.releaseConnection(c);
  }
  public static void main(String args[]) {
  junit.textui.TestRunner.run(ConnectionPoolDemo.class);
  }
  } ///:~
• Object decoupling:Both Proxy and State provide a surrogate class that you use in your code; the real class that
  does the work is hidden behind this surrogate class.When you call a method in the surrogate,
  it simply turns around and calls the method in the implementing class. These two patterns are
  so similar that the Proxy is simply a special case of State.
  
  The basic idea is simple: from a base class, the surrogate is derived along with the class or
  classes that provide the actual implementation:
  
  When a surrogate object is created, it is given an implementation to which to send all of the
  method calls.
  Structurally, the difference between Proxy and State is simple: a Proxy has only one
  implementation, while State has more than one. The application of the patterns is considered
  (in Design Patterns) to be distinct: Proxy is used to control access to its implementation,
  while State allows you to change the implementation dynamically. However, if you expand
  your notion of “controlling access to implementation” then the two fit neatly together.
• State: changing object behavior
  The State pattern switches from one implementation to another during the lifetime of the
  surrogate, in order to produce different behavior from the same method call(s). It’s a way to
  improve the implementation of your code when you seem to be doing a lot of testing inside
  each of your methods before deciding what to do for that method. For example, the fairy tale
  of the frog-prince contains an object (the creature) that behaves differently depending on
  what state it’s in. You could implement this using a boolean that you test:
• Factoring commonality
  Applying the “once and only once” principle produces the most basic
  pattern of putting code that changes into a method.
• Strategy: choosing the algorithm at run-time
  Strategy also adds a “Context” which can be a surrogate class that controls the selection and
  use of the particular strategy object—just like State!
  
• Policy: generalized strategy
  Although GoF says that Policy is just another name for strategy, their use of Strategy
  implicitly assumes a single method in the strategy object – that you’ve broken out your
  changing algorithm as a single piece of code.
  Others[6] use Policy to mean an object that has multiple methods that may vary
  independently from class to class. This gives more flexibility than being restricted to a single
  method.
  It also seems generally useful to distinguish Strategies with single methods from Policies with
  multiple methods
• Template method
  An important characteristic of the Template Method is that it is defined in the base class and
  cannot be changed. It's sometimes a private method but it’s virtually always final. It calls
  other base-class methods (the ones you override) in order to do its job, but it is usually called
  only as part of an initialization process (and thus the client programmer isn’t necessarily able
  to call it directly).
  E.g
  abstract class ApplicationFramework {
  public ApplicationFramework() {
  templateMethod(); // Dangerous!
  }
  abstract void customize1();
  abstract void customize2();
  final void templateMethod() {
  for(int i = 0; i < 5; i++) {
  customize1();
  customize2();
  }
  }
  }
  // Create a new "application":
  class MyApp extends ApplicationFramework {
  void customize1() {
  System.out.print("Hello ");
  }
  void customize2() {
  System.out.println("World!");
  }
  }

posted on 2006-04-09 17:15 junhong 閱讀(1553) 評(píng)論(0)  編輯  收藏 所屬分類: java技術(shù)