老板交给总经理一项任务,总经理觉得一下子做不完,怎么办呢?分给五个副经理分别做吧,副经理们又按同样的思路分给各各项目经理,一直到工作人员.当然这个过程有不同的分配方式,由此产生了不同的设计模式.
现在总经理很轻松,各级领导也很轻松,工作人员也很轻松,因为他们只要完成一件事就好了.挺完美的系统吧.
可是编程序的时候你既是总经理,又是副经理,还是工作人员,分来分去所有的事还得自己做,记性好呢这些模式很好,灵丹妙药,记性不好就有点惨,调程序跟踪进去忽然发现一个方法调用是接口方法,真正的类在哪呢,程序大了真是乖乖的不的了,模式很巧妙,也通常是代码膨胀的源泉,能真正掌握模式的程序员恐怕百分比也不是很大,一个项目组工作起来就有点问题,项目工期会更长吧?有些时候读代码真有点累,明知道三五句话就能完成的功能,你就不知道他在说些什么,哈哈,我脑袋有点大,不过这样也好,反正老板给银子,时间越长越好.
不知道大家有何感想?
你说的不是真正的模式，如果严格按照模式来做，每个角色都是固定的，不会有太多class或接口。
关于代码膨胀，是系统可重用性增强的一个象征，膨胀的程度，需要控制，原则很简单，每个class或每个方法尽可能简单明了，责任明确而单一。这就需要对代码进行refactor,所以并不是编程完成后就可以了，还需要refactor,refactor后，再增加新功能，会轻松明了。
不能把简单问题复杂化，这也是refactor一个目标。
关于refactor由谁来做，最好自己做，或者由系统设计师来做。
Banq说得对，但是不是只有大的系统才适合做设计模式呢？
几个设计师将所有的设计用类图表现出来，这时候，虽然代码还没有编，但基本上已经宣布了软件开发的大部分已经完成。这样才能发挥模式的重要性！
设计模式使用无论系统大小。
创建型模式和结构型模式对于中大型系统应用较多。
但是很多行为模式是不分大小系统，具体说如Iterator
几乎都要用
是的，Iterator是非常普遍的模式，你也曾经说过自己做Iterator当数据集。
模式的根本还是利用继承与多态。
用设计模式重构才是最关键的。
你总结得很正确，模式可以说就是围绕继承和多态展开。
在开发系统时，很少有能一下子确定使用什么模式，只有在重构(refactoring 或叫重整)时，才能发现并实现。