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 閱讀(1552) 評論(0)  編輯  收藏 所屬分類: java技術(shù)

          主站蜘蛛池模板: 蒙自县| 杭锦旗| 佳木斯市| 利辛县| 兰考县| 武强县| 中牟县| 旺苍县| 大冶市| 通许县| 客服| 色达县| 卢氏县| 兰西县| 拜泉县| 区。| 沙坪坝区| 启东市| 海淀区| 分宜县| 阿城市| 东兴市| 阿合奇县| 政和县| 龙里县| 东乌珠穆沁旗| 漾濞| 卢湾区| 卫辉市| 滕州市| 连平县| 米脂县| 乌什县| 普兰县| 商南县| 石屏县| 阳谷县| 鄂托克前旗| 抚远县| 汽车| 蒙自县|