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:
    thinking in patterns with Java.bmp
    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!
    thinking in patterns with Java.bmp
  • 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 阅读(1231) 评论(0)  编辑  收藏 所属分类: java技术


只有注册用户登录后才能发表评论。


网站导航: