敲响OO时代的丧钟！——DJ对于数据持久化的支持(3)

复用设计一般都是基于这样的假设：这种情况以往曾经出现过多次，所以我们大胆猜测以后也会是如此。猜中了就是可复用设计，猜错了就是过度设计，如果不小心翼翼的避开OO设计的陷阱，猜错的后果会很严重，可能整个设计都会废掉。

素偶用词不精确 

还没有看完，大概看了一下 ajoo和庄到此的讨论，庄，我想ajoo的意思是非常清楚的，无论你批判OO也好，还是批判OO这个时代也好，都必须对你批判的对象给出一个定义，给出一个范畴。比如说，如果你对OO时代有批判的想法，那么首先就要精确表明出什么是OO时代。

我也觉得，如果你以论文的名义来说件事情，必须对what给出精确的定义，不然肯定是空对空的东西……

设计模式批判(1)

http://spaces.msn.com/members/zbw25/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!286.entry

看到这一段，说两句：
我觉得可以用1句话总结这个创建型模式出现的原因:
分离对象可以分离的行为. 使之更稳定.

解析：
如果一个对象具备越复杂的逻辑,他越不稳定. 如果系统中复杂的行为逻辑能够以某种合适的粒度分离到复杂但结构清晰的对象体系中,那么这个系统越稳定和易扩展.

出于这么一个原则，系统中任何的行为都可以被封装和抽象。当然这有个充分条件：
如果这种行为是构成多处重复代码的根源，如果这种行为足够复杂。

看完后一个感觉--文章思维混乱。

以下是反对意见：
作者的观点设计同重构是矛盾。
似乎重构的时候不需要设计？而设计也似乎成了不必考虑实际需求的自娱自乐？
我的观点是设计同重构并不矛盾，而两者是相辅相成的关系，首先对于需求进行思索我们会有一个初始的设计，随着需求的增加我们不断地重构来修正我们的设计，需求是会变化，而且可能会出现不可预测的变化，但这不能推出我们不能设计，难道对于已有需求谈设计都是一件奢侈品吗？TDD可以有效的防治这种倾向。

另外设计模式并不是上帝传授的先验技巧，相反它正是无数实践的结晶，设计是基于经验和思考的，否则在开发能力上我可以把Erich Gamma同普通大学毕业生视为具有同等价值。

关于创建模式不符合SRP原则
对象应该自己创建自己，这确实没错，否则构造函数这种东西就不该存在，但是你明显偷换了概念，创建自己完成任务，同在什么时候，什么情况下创建那个子类来完成任务完全是两回事。打个比方：程序员是负责开发软件的，但是却是经理负责分配任务。

“在容器出现后，创建模式是解决OO概念不完善的手段”
创建的职责总要有对象来负责，从发展的观点来看，可以把容器看作高级的创建模式，就因为这很重要也很通用，所以才有可能出现这么多的产品。

关于结构化模式
确实不理解OO中接口的作用，设计模式一无是处。

嗯，我的观点跟你的观点是一致的。
不知道是不是我很愚昧， 看了很多的技术很深入的帖子，虽然，讨论很激烈，但是我切从中很少看得到任何清晰明了的理论，反而有一种把本简单明了的东西越讨论越复杂，把简单明了的东西用一种晦涩难懂的思维表达.
我一直有一个观点:那就是好的设计和好的代码从来都不是一蹴而就的,复杂的系统总归是由一段段代码积累起来. 设计也是在不断的编码中得以优化和实现,这个过程会随着系统的规模成正比,.而与参与开发人员地的素质成反比. 但是无论系统规模多大,开发团队 素质如何. 坚持一个原则: 在任何你所认为需要重构的时候重构,消除任何你认为重复多余的代码!
那么设计总归会朝着好的方向进展,!
然而任何一个轻视或者烦腻于这种设计从不好到好的转变过程的开发人员,都会付出惨重的代价.
同样,好的OO架构能够在你所设计的系统中得以体现,也不可能仅仅凭查阅几本书,对照几个优秀的开演框架得出来的, 或者熬几个星期设计想的出来的!
虽然不可忽略初期优秀i设计所带来的巨大产出率,但是不经过整个开发团队集体编码推敲,整修甚至大规模的整改系统初期的设计架构这么一个复杂过程,任何优秀的设计都只是纸上谈兵。

当你们整个团队在初期设计已经整理了一个自认为好的不得了的技术架构思路，欣欣然准备分配任务开工时，请记住：
1） 请乐于接受任何在编码中发现的架构设计缺陷，而不把这归咎于“不能”和
    “没办法”

2） 当发现任何问题时，你们应该感到高兴，因为你们发现了问题，意味着你们
    往成功又迈进了一步。而不是沮丧，问题的发现总会带来质量的提升，如果
    回避问题，那一切都是徒劳，因为必定失败。

3） 足够的交流，充分的互监督。 设计和代码是集体的产物，所以，涉及和代码
     应该由集体来创作和完成。 你发现他的代码不好，请指出，你发现你的   代   码有何问题，请告诉大家！


到最后，你发现一切都是有所付出，有所回报。

应该说是更自然的描述现实。

程序逻辑有多种范型描述，各有适用面，说不上哪个比哪个更好。

函数式范型就一定比命令式的好?那也未必

复杂一点的逻辑使用函数式描述，会产生大量的递归调用，在冯诺衣曼计算机上，这是个很难克服的问题。

按照面向对象的理念，一个行为、功能，如果从逻辑上、概念上就应该属于这个类，有什么理由把它分离出去呢？

仅仅因为复杂，就应该拆散它吗？如果创建的行为因为你所理解的——注意，是你理解的——复杂性，就将他拆成N个部分，而其他的程序员，却觉得不算太复杂，你们之间如何相互说服？

复杂到需要拆分的标准是什么？你这样的说法，并无判定依据可循，甚至比SRP还要模糊。

再说你的另一个原则：如果这种行为是构成多处重复代码的根源。

Class A和Class B的创建代码都很复杂，而且有可以相互借鉴之处，因此，需要分离出来。我同意这样的原则，当然，这也是AOP这样的思想出现的原因，但是，这是设计模式当年提出的时候，没有想过的问题。

我想说的是，在重构出现之前，对于设计模式的理解与使用，与重构出现之后，对于设计模式的理解与使用，是有区别的。重构当然是好东西，他的问题已经极少极少了，我很难攻击它。



从经验总结这个角度来说，设计模式是有价值的。这也是我感觉很难写自己的这篇文章原因之一，我知道设计模式不只是带来了解决之道，同时也带来了问题，而且还暴露了很多OO经典思想的问题，但是这样的一篇文章该如何组织，我确实没有想得足够成熟，只是时间拖得太长，大家又要催我，我就先贴出来了。



创建模式中，有的是隔离了具体的创建地点：比如工厂模式，有的则是包揽了创建的具体工作：比如Builder模式。这是有区别的。我并没有偷换概念，你以为呢？



容器不只是负责高级的创建模式，而是负责对象的整个生命期的管理，创建－－保持－－销毁。容器作为一个对象之外的环境概念而存在。请注意这个“环境概念”，这是OO经典思想中，原本没有的东西。



没有理解你的意思。