|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-07-12
firebody 写道 嗯，我的观点跟你的观点是一致的。
不知道是不是我很愚昧， 看了很多的技术很深入的帖子，虽然，讨论很激烈，但是我切从中很少看得到任何清晰明了的理论，反而有一种把本简单明了的东西越讨论越复杂，把简单明了的东西用一种晦涩难懂的思维表达. 我一直有一个观点:那就是好的设计和好的代码从来都不是一蹴而就的,复杂的系统总归是由一段段代码积累起来. 设计也是在不断的编码中得以优化和实现,这个过程会随着系统的规模成正比,.而与参与开发人员地的素质成反比. 但是无论系统规模多大,开发团队 素质如何. 坚持一个原则: 在任何你所认为需要重构的时候重构,消除任何你认为重复多余的代码! 那么设计总归会朝着好的方向进展,! 然而任何一个轻视或者烦腻于这种设计从不好到好的转变过程的开发人员,都会付出惨重的代价. 同样,好的OO架构能够在你所设计的系统中得以体现,也不可能仅仅凭查阅几本书,对照几个优秀的开演框架得出来的, 或者熬几个星期设计想的出来的! 虽然不可忽略初期优秀i设计所带来的巨大产出率,但是不经过整个开发团队集体编码推敲,整修甚至大规模的整改系统初期的设计架构这么一个复杂过程,任何优秀的设计都只是纸上谈兵。 当你们整个团队在初期设计已经整理了一个自认为好的不得了的技术架构思路，欣欣然准备分配任务开工时，请记住： 1） 请乐于接受任何在编码中发现的架构设计缺陷，而不把这归咎于“不能”和 “没办法” 2） 当发现任何问题时，你们应该感到高兴，因为你们发现了问题，意味着你们 往成功又迈进了一步。而不是沮丧，问题的发现总会带来质量的提升，如果 回避问题，那一切都是徒劳，因为必定失败。 3） 足够的交流，充分的互监督。 设计和代码是集体的产物，所以，涉及和代码 应该由集体来创作和完成。 你发现他的代码不好，请指出，你发现你的 代 码有何问题，请告诉大家！ 到最后，你发现一切都是有所付出，有所回报。 你说的很有道理，我也很赞同，但是咱们现在说的不是开发管理问题，而是技术问题。 |
| 返回顶楼 | |
|
发表时间：2005-07-12
庄表伟 写道 firebody 写道 看到这一段，说两句：
我觉得可以用1句话总结这个创建型模式出现的原因: 分离对象可以分离的行为. 使之更稳定. 解析： 如果一个对象具备越复杂的逻辑,他越不稳定. 如果系统中复杂的行为逻辑能够以某种合适的粒度分离到复杂但结构清晰的对象体系中,那么这个系统越稳定和易扩展. 出于这么一个原则，系统中任何的行为都可以被封装和抽象。当然这有个充分条件： 如果这种行为是构成多处重复代码的根源，如果这种行为足够复杂。 按照面向对象的理念，一个行为、功能，如果从逻辑上、概念上就应该属于这个类，有什么理由把它分离出去呢？ 仅仅因为复杂，就应该拆散它吗？如果创建的行为因为你所理解的——注意，是你理解的——复杂性，就将他拆成N个部分，而其他的程序员，却觉得不算太复杂，你们之间如何相互说服？ 复杂到需要拆分的标准是什么？你这样的说法，并无判定依据可循，甚至比SRP还要模糊。 再说你的另一个原则：如果这种行为是构成多处重复代码的根源。 Class A和Class B的创建代码都很复杂，而且有可以相互借鉴之处，因此，需要分离出来。我同意这样的原则，当然，这也是AOP这样的思想出现的原因，但是，这是设计模式当年提出的时候，没有想过的问题。 可以 强调一点： 写代码是主观行为！ 把 任何一种处理都用概念化的东西加以框条化是不大可能也不切实际的， 我觉得判断是否足够复杂的依据还是 依据你或者团队主观的判断，这个主观是指你的经验，敏锐的代码感觉，以及严谨的逻辑思维能力。至于这个结果，可能好可能坏 ，无论好与坏，只要你意识到这个结果，总归是好的。 另外再说一点行为的从属问题！ 事情没有绝对的 ，同样行为的从属也没有绝对的。 你说 这些行为从逻辑，概念上属于这个对象。 这句话虽然 有可能是对 ，而且这句话也有可能成为制止你做分离行为或者别的重构的任何构想的主要原因。 但是，请不要忘了，这个对象也是你或者团队主观构造出来的，从客观上来说是我们赋予这个对象的所有逻辑。 然而，我们也可以 从新分解这个对象，让你们从 逻辑，概念上更加感觉原本属于旧对象的行为现在却更像从属于新构造对象。 这个重构又何来错误呢？ 绝对的事情从来都不是绝对的 ，相反它是一种教条式的东西。 |
| 返回顶楼 | |
|
发表时间：2005-07-12
firebody 写道 可以 强调一点：
写代码是主观行为！ 把 任何一种处理都用概念化的东西加以框条化是不大可能也不切实际的， 我觉得判断是否足够复杂的依据还是 依据你或者团队主观的判断，这个主观是指你的经验，敏锐的代码感觉，以及严谨的逻辑思维能力。至于这个结果，可能好可能坏 ，无论好与坏，只要你意识到这个结果，总归是好的。 另外再说一点行为的从属问题！ 事情没有绝对的 ，同样行为的从属也没有绝对的。 你说 这些行为从逻辑，概念上属于这个对象。 这句话虽然 有可能是对 ，而且这句话也有可能成为制止你做分离行为或者别的重构的任何构想的主要原因。 但是，请不要忘了，这个对象也是你或者团队主观构造出来的，从客观上来说是我们赋予这个对象的所有逻辑。 然而，我们也可以 从新分解这个对象，让你们从 逻辑，概念上更加感觉原本属于旧对象的行为现在却更像从属于新构造对象。 这个重构又何来错误呢？ 绝对的事情从来都不是绝对的 ，相反它是一种教条式的东西。 请原谅我需要再次上升到哲学高度，来讨论软件设计的原则问题。 经验论，是固然教条主义的解毒剂。 但是也要警惕，过度强调经验的独特性，就有可能滑入相对主义与虚无主义的泥潭。软件设计之间的优劣比较，也就不复存在了。 |
| 返回顶楼 | |
|
发表时间：2005-07-12
庄表伟 写道 firebody 写道 庄表伟 写道 firebody 写道 看到这一段，说两句：
我觉得可以用1句话总结这个创建型模式出现的原因: 分离对象可以分离的行为. 使之更稳定. 解析： 如果一个对象具备越复杂的逻辑,他越不稳定. 如果系统中复杂的行为逻辑能够以某种合适的粒度分离到复杂但结构清晰的对象体系中,那么这个系统越稳定和易扩展. 出于这么一个原则，系统中任何的行为都可以被封装和抽象。当然这有个充分条件： 如果这种行为是构成多处重复代码的根源，如果这种行为足够复杂。 按照面向对象的理念，一个行为、功能，如果从逻辑上、概念上就应该属于这个类，有什么理由把它分离出去呢？ 仅仅因为复杂，就应该拆散它吗？如果创建的行为因为你所理解的——注意，是你理解的——复杂性，就将他拆成N个部分，而其他的程序员，却觉得不算太复杂，你们之间如何相互说服？ 复杂到需要拆分的标准是什么？你这样的说法，并无判定依据可循，甚至比SRP还要模糊。 再说你的另一个原则：如果这种行为是构成多处重复代码的根源。 Class A和Class B的创建代码都很复杂，而且有可以相互借鉴之处，因此，需要分离出来。我同意这样的原则，当然，这也是AOP这样的思想出现的原因，但是，这是设计模式当年提出的时候，没有想过的问题。 可以 强调一点： 写代码是主观行为！ 把 任何一种处理都用概念化的东西加以框条化是不大可能也不切实际的， 我觉得判断是否足够复杂的依据还是 依据你或者团队主观的判断，这个主观是指你的经验，敏锐的代码感觉，以及严谨的逻辑思维能力。至于这个结果，可能好可能坏 ，无论好与坏，只要你意识到这个结果，总归是好的。 另外再说一点行为的从属问题！ 事情没有绝对的 ，同样行为的从属也没有绝对的。 你说 这些行为从逻辑，概念上属于这个对象。 这句话虽然 有可能是对 ，而且这句话也有可能成为制止你做分离行为或者别的重构的任何构想的主要原因。 但是，请不要忘了，这个对象也是你或者团队主观构造出来的，从客观上来说是我们赋予这个对象的所有逻辑。 然而，我们也可以 从新分解这个对象，让你们从 逻辑，概念上更加感觉原本属于旧对象的行为现在却更像从属于新构造对象。 这个重构又何来错误呢？ 绝对的事情从来都不是绝对的 ，相反它是一种教条式的东西。 请原谅我需要再次上升到哲学高度，来讨论软件设计的原则问题。 经验论，是固然教条主义的解毒剂。 但是也要警惕，强调经验的独特性，就有可能滑入相对主义与虚无主义的泥潭。软件设计之间的优劣比较，也就不复存在了。 嘿嘿，相反， 我倒认为软件设计是一种相对主义的行为！ 至于虚无主义，没听懂。 好与坏的标准虽然争论不休，但是评判一个软件好与坏每个人 ，每个团队都会有一个深刻的体会的。 |
| 返回顶楼 | |
|
发表时间：2005-07-12
庄表伟 写道 创建模式中，有的是隔离了具体的创建地点：比如工厂模式，有的则是包揽了创建的具体工作：比如Builder模式。这是有区别的。我并没有偷换概念，你以为呢？
好吧我再举个形象的例子。 京剧 京剧里分了很多行当，现在有白脸曹操这么一个角色，很多演员都可以演，但是 导演可以决定让黄华来演，通常都是黄华来演这个角色，某天出现了紧急情况，黄华生病了，必须有人替代，导演叫也训练过的李斌出演。李斌要演出首先要化妆，化妆师给他画脸谱，指定需要穿戴的服装，靴子，最后戴上头盔，套上腰带，曹操该出场了，虽然不是黄华在演出，李斌是胖了点，但观众对于谁来演曹操没有要求，不过一定要演得到位，符合他们心理上对角色的期望，李斌唱客户已熟记的唱腔，唱词，变幻预设姿势，拿出了吃奶的劲，成功的塑造了曹操这个角色。 这里，导演好比factory，化妆师好比builder,曹操好比interface，观众好比client，李斌是实现interface的子类。 明显导演，化妆师，李斌的职责是不同的。这也是对象同创建者的区别。 庄表伟 写道 容器不只是负责高级的创建模式，而是负责对象的整个生命期的管理，创建－－保持－－销毁。容器作为一个对象之外的环境概念而存在。请注意这个“环境概念”，这是OO经典思想中，原本没有的东西。
这不更说明容器是创建模式的升级了吗？在容器里的对象享受的可是VIP服务哦。 环境概念在经典OO中没有？ 难道环境就不是由对象构成的吗？环境的构建是用另一种非OO的方式构架的？ 几个类是OO，一大堆类就不是OO了？ 我认为把对象同它所处的环境分离，是为了能明确的划分职责，这样容器和对象 就可以按照约定来共同完成特定目的了。 庄表伟 写道 partech 写道 关于结构化模式
确实不理解OO中接口的作用，设计模式一无是处。 没有理解你的意思。 绝大多数设计模式，都运用接口作为抽象的关键，如果看不到这点，模式在你眼中就会黯然失色。 |
| 返回顶楼 | |
|
发表时间：2005-07-12
to:partech
1、你的例子不恰当，京剧演员的替换，不但用户感觉不到而且他们实际上的表演也应该毫无差别。这个跟工厂模式，产生符合同一接口的不同对象，是不一样的。 2、搭建一个容纳Object的环境，自然用OO的语言最为方便，所以一个容器自然是一堆对象组成的框架，但是我要说的是，概念是新生的。这个概念，原本是没有的。 3、最近正在看《Modern C++ Design》里面采用的泛型模板的方式来实现GoF的设计模式，实在是经典之极，但是确实没看到接口的东东。 |
| 返回顶楼 | |
|
发表时间：2005-07-12
引用 容器不只是负责高级的创建模式，而是负责对象的整个生命期的管理，创建－－保持－－销毁。容器作为一个对象之外的环境概念而存在。请注意这个“环境概念”，这是OO经典思想中，原本没有的东西。
SICP第三章第一个注脚，所谓对象就是用“有内部状态的软件模块”模拟真实世界目标，采用这种看待目标的方式即意味着需要将“代换模型”转变为“环境模型”。 谁说OO经典思想没有环境概念？ |
| 返回顶楼 | |
|
发表时间：2005-07-12
gigix 写道 引用 容器不只是负责高级的创建模式，而是负责对象的整个生命期的管理，创建－－保持－－销毁。容器作为一个对象之外的环境概念而存在。请注意这个“环境概念”，这是OO经典思想中，原本没有的东西。
SICP第三章第一个注脚，所谓对象就是用“有内部状态的软件模块”模拟真实世界目标，采用这种看待目标的方式即意味着需要将“代换模型”转变为“环境模型”。 谁说OO经典思想没有环境概念？ 此“环境”非彼“环境”。 |
| 返回顶楼 | |
|
发表时间：2005-07-12
庄表伟 写道 to:partech
1、你的例子不恰当，京剧演员的替换，不但用户感觉不到而且他们实际上的表演也应该毫无差别。这个跟工厂模式，产生符合同一接口的不同对象，是不一样的。 2、搭建一个容纳Object的环境，自然用OO的语言最为方便，所以一个容器自然是一堆对象组成的框架，但是我要说的是，概念是新生的。这个概念，原本是没有的。 3、最近正在看《Modern C++ Design》里面采用的泛型模板的方式来实现GoF的设计模式，实在是经典之极，但是确实没看到接口的东东。 1.接口难道不是客户感觉不到就行了吗？还要求实现它的子类的具体行为？你越说我越糊涂。 2.这样来说你是在批判经典OO了？可是什么时候的OO是经典OO呢？OO就不存在演变了？ 3.呵呵，泛型模板的运用实际上极其有限，而且使得思考变得异常复杂，因为是类的类，所以不得不同时考虑很多类的各种情况。另外它不能完全取代接口。你有这样的观点，在我来看应该是你没有理解接口存在的真正意图。 |
| 返回顶楼 | |
|
发表时间：2005-07-12
庄表伟 写道 如果你能够理解为什么现在会出现那么多容器，就能理解设计模式中的创建模式，只不过是用来解决OO概念欠缺的一种不完善的手段了。 概念好象有点混淆了，还是打个比喻吧。如果说OO语言是一把剑，那么设计模式也好，或者其他设计指导思想也好，都是属于剑法的范畴，剑只有一把，剑法却可以有无数种，并且各有优劣，好的剑客通常都会是集众家之长于一身。你想说的是剑不好，你的斧头最好，还是想说你有一套可以将其他剑法轰至渣的剑法呢？每种剑法都必然会有缺陷有破绽，细数这些破绽到底能为你证明什么呢？证明剑一无是处？证明你的斧头最好？ |
| 返回顶楼 | |
