读书笔记：Android设计模式第五章

工厂模式，无非可以用下面的代码来概括

public class GoodsFactory {

public static void create() {

return new Goods();

}

这是他最简洁的形式。但是看完这一章以后，我很疑惑，最简洁的形式都感觉很多余，因为这个工厂类和方法是不需要的，直接new多省事。后来上网搜了一下，看到线程池的默认实现我才明白工厂的好处

public class Executors {
    public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable>());
    }


    public static ExecutorService newWorkStealingPool(int parallelism) {
        return new ForkJoinPool
            (parallelism,
             ForkJoinPool.defaultForkJoinWorkerThreadFactory,
             null, true);
    }


    public static ExecutorService newWorkStealingPool() {
        return new ForkJoinPool
            (Runtime.getRuntime().availableProcessors(),
             ForkJoinPool.defaultForkJoinWorkerThreadFactory,
             null, true);
    }


    public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable>(),
                                      threadFactory);
    }


    public static ExecutorService newSingleThreadExecutor() {
        return new FinalizableDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,
                                    0L, TimeUnit.MILLISECONDS,
                                    new LinkedBlockingQueue<Runnable>()));
    }

如果这么多参数自己去写真的是有点繁复了，需要指定5个参数。所以工厂模式的核心我感觉在于提供一些默认实现。

这样在自己写框架的时候也可以得到借鉴，提供一些默认实现。不管是这里的构造函数形式的，还是建造者形式，都可以提供一些默认实现。比如我封装的一个Toolbar，完全可以提供这个APP的主题样式，比如透明，arrow样式，比如cross，白色背景样式。

----------------------------

第二天又百度了工厂模式，算是得出了比较全面的结论，重新撰写工厂此文吧

----------------------------

直接new是直接的耦合，用工厂的话，使用者不仅要耦合目标对象，还要耦合工厂，这反而增加了耦合程度。

所以极简形式下，反而是加大了耦合。

再看看一般形式下，即接口+接口impl。比如A，AImpl吧。

正常形式是A a = new AImpl();

用了工厂后是A a = Factory.create("A");

这样一来，原来是耦合2个类，现在也是耦合两个类了，打了个平手。

在看看多个实现。

正常：A a = new AirImpl();

A a = new AppleImpl();

耦合3个

工厂：A a = Factory.create("Air");

A a = Factory.create("Apple");

耦合2个

反倒优胜一筹了，得出结论，同接口多实现的时候，工厂模式占优。

如果工厂模式不仅作为创建者，也作为调用者，解耦会进一步彻底。继续上面例子。

Factory.exec("Apple","eat");

仅耦合1个类，即可完成创建与调用。当然这需要反射支持或者代码预声明。

假设下，如果在Android中，收集整个项目中所有的碎片，会是怎样的情况。

Fragment fragment = FragmentFactory.create("HomeFragment");

首先只耦合了一个工厂类了，Fragment类是原生的，算不上实际耦合。其次FragmentFactory里的代码会显得非常清晰，整个项目的碎片一览无遗。不过这和添加一个txt文本的操作是差不多的。

到这里大概可以知道，工厂的同类管理能力特别强，在Android中，完全可以用工厂来管理Activity、Fragment的创建。其他的就暂时别用了，滥用反而不美。

还有一个就是提供默认实现，这一点可以从线程池的默认实现中学习。

这里从任玉刚老师博客里得到启发。你曾经在100个地方new了一个对象，提供了一些参数作为构造函数的参数。可是一旦要求新增一个固定参数，要去修改这100个地方，就哭了。用工厂只需要改一处就可以了。

再在此基础上扩展一下。如果增加的不是固定参数，而是动态生成的参数呢？我们在对象的构造函数依然可以按规矩写死，这也是应该的。但是工厂的创建方法中除了原有的参数，还可以留一个Object...objects的口子，为了未来维护，真正做到，一行代码，抵得上一百行。

所以说，在一个对象被多处生成实例的时候，可以考虑用工厂，这可以显著地减少维护的代价。

读书笔记：Android设计模式第五章

猜你喜欢