我就不明白, 一个简简单单的需求分析, 在经过了这么多专家的仔细阐述分析之后,怎么让大家搞得越来越复杂了?
什么是面向接口? 就是你分析了需求, 根据需求定义了接口, 然后所有东西都围着这个接口转.
有人可能觉得一个类通过重构变得那样太不可接受了. 那么我请问, 你的重构的底线是什么? 类变成什么样你可以接受? 你那么关心类的实现方法干什么? 你到底是面向接口编程还是面向类编程?
一个模块X, 它要实现接口I, 然后要让别人用自己的实例.
仔细分析, 这里面的需求是什么?
只有一个
1. X要给外界提供一个实现了I接口的实例.
没有别的了. 真的, 没有别的了. 我只要能保证调用者从我这里取得一个I的实例, 我就完成了工作. 你管我是偷来的抢来的?
这个需求要求你必须用X实现I了么?
它要求你必须每次调用的时候返回不同的实现了么?
它告诉你X不能开始时候实现I, 后来又不实现了么?
同志们, 放下骄傲的直觉, 科学理性地分析一下吧.
通过数学的方法, 从需求1, 你得不出上述得任何结论!
根据这个需求,
java代码:
1 class X implements I{
...}
2 public X(){}
3 }
符合要求.
java代码:
1 class X implements I{
...}
2 public static I instance(){return new X();}
3 }
符合要求
java代码:
1 class X{
...}
2 static class Inner implements I{
...}
3 }
4 public static I instance(){return new Inner();}
5 }
符合要求.
java代码:
1 class X{
...}
2 public static I instance(){return GenericI.instance();}
3 }
符合要求
java代码:
1 class X{
...}
2 class Inner implements I{
...}
3 }
4 private static final X singleton = new X();
5 public static I instance(){return singleton.new Inner();}
6 }
仍然符合要求.
设计是什么? 就是在分析了需求之后, 保留真正的需求, 剔除一些假想的并不真正存在的假设.什么外部用容器啦, 什么类X不能从implements I变成不implements I啦, 都是你自己的一厢情愿的假设.
如果分析出了这个需求, 谁是最能够忠实反映这个需求而添加的额外约束最小的? 构造函数还是静态工厂?
一个假设最小的接口就是最灵活的接口. 什么外部创建逻辑, 什么容器, 这些外部的逻辑没有理由在一个不灵活的接口上可以做到而在一个更灵活的接口上反而做不到.
