无责任书评－－java与模式(100分)

昨天冒着感染非典的危险到书店转了一圈，买了本《java与模式》
这是我买的第二本中国人写的计算机类书籍了。
晚上看看，终于明白了，所谓设计模式，讨论的是对象之间的关系。
最早面向对象考虑的是这些内容：数据封装、继承和多态。这里只有继承是对象之间
的关系。可是现实如此复杂，对象之间的关系远远不只是继承。所以人们开始考虑
设计模式这个东东。
《java与模式》中推崇道家思想，虽然试图将传统文化精髓和现代科学相联系，
但是我感觉道家千年以来，一直已炼丹为己任，远离人民。恐怕难担此重任。
以上观点，欢迎指正。

老哥，我也学JAVA，可是学不走。
另外你给我发的东西发没得哦，我急死了？
我的邮箱： zoujinhe@changhong.com，大小：14M。拜托你。

师傅领进门，修行在各人

小弟也买了喔， 大家多多交流看书心得如何？
qq： 786552

to catfox
同志啊，我终于找到你了。哽咽中....
还有哪位大虾买了，可以发表一下高见。

买是买了，不过还没看，等到水平偶才看，呵呵，
努力进阶ing…………[]

正在继续看。
我发现原来有些书籍中称被继承的类为父类，实在是在误人子弟，这给原来懵懵懂懂的我
把继承理解为大马生小马，呵呵。从“类”这个词来说，面向对象是一个分类的学问。是
人们对现实世界进行分类的计算机语言描述。
多重继承是全世界人们所不齿的东东，不过从要解决的现实世界而言，多重继承又是个
不可少的东东。显然，分类体系远远不只一种，老虎当然是一种动物，同时又是一种可食用
的东东（当然，广东人把可食用的范围大大的扩展了），同时还是一种用来吓唬小孩的好
东东，这里又和妖魔鬼怪同类了。
人们似乎是这样解决这个问题的：
继承只是描速一个对象的最常用的分类，或者是某个系统中主要的分类，至于其他的分类体系，
人们发明的“接口”这个东东，这样，既可以不使用多重继承，又可以实现多重继承的显示
描述。
不过这样一来，接口岂不是很多，很乱，没有头绪？

根据OO的原则，每一个类的设计必须尽量实现他本身应该实现的功能，
也就是说不属于该类应该具有的功能就不应该在该类里面，但是我们有时候设计的时候不
得不加一些该类本不具备的功能。比如说要做一张门，门本来是用来防盗的，处此之外
就不应该具备其他的功能，但是我又要他具备的防火的功能，那么我门可以实现防火的
接口，但是煤气灶就不应该实现防火的接口，他的防火功能应该从灶继承下来，至于
不防火的灶到目前为止我还没见过。
接口实际上就是一组规范，他告诉你要怎么做，而你不得不这么做。
接口是实现设计模式的基础，那我们为什么用设计模式啊！你当然有权不用，只是说
当你项目完成了2/3的时候，突然需求要改一下，或者项目完成以后要增加一些功能，
如果你的系统能轻而易举的实现的话，那你有足够的理由不用设计模式。

to billy_yuan
>只是说当你项目完成了2/3的时候，突然需求要改一下，或者项目完成以后要增加一些功能，
这是自然的，我没有见过哪个需求能做的如此完善而不用增加的。
我参与过一些系统，大多数都在维护期耗尽了软件人员的心血，我要问的是，使用了
设计模式，或者说，使用了优良的设计模式，可以在多大程度上减少维护量？
billy_yuan大虾关于门的论述是不是可以描述为：
tCustomDoor = class
end;

IProtectFire = interface
procedure raiseTemp(temp:integer) //温度升高，可以是报警，可以是自动喷水，可以是不被破坏？？？
end;

tMyDoor = class(tCustomDoor,IProtectFire)
end;

我想问的是如果在项目完成后，我需要增加通风功能，是不是要增加一个通风的接口？

如果将许多工作留到维护的时候再去做，那么必然是一个很失败的工程
好的系统分析员要优先见之明，有丰富成功的和失败的经验

gz

》好的系统分析员要优先见之明，有丰富成功的和失败的经验
如何能做的这一点呢？我是系统分析员，也有经验，可是我还是经常性的迷惑。

是啊，太不容易了，要做好，太难了，不光我们觉得

>>to jian1
"我要问的是，使用了设计模式，或者说，使用了
优良的设计模式，可以在多大程度上减少维护量？"
大多数开发人员，热衷于“设计模式”都是希望它能够
轻松地对付客户需要的改变和添加。 但事实上设计模式
只能很有限的做到这点的。
现有的设计模式都是通过在某个不确定的方向上添加抽象层来提供灵活性。
这就是需要在设计时就做出判断，客户需求在哪个方面上会进行怎么
样形式的变化。而事实上如果我们能有这样的预见性，那即便不用
设计模式，而采用一些比较粗糙的解决方法基本也能解决问题。

就是总结“设计模式”的意义来说，正如阎博士在书中所提到，
可以让我们举一反三。可能“设计模式”更多的是给我们一种
提示而不是一条道路。比如在建立一个对象时，想想类本身提供是
构造方法是否已经能够胜任，还是需要采用某种构造模式来对付可能
的复杂性。 前提是我们需要预见到这种创建的对象的复杂性，如果
我们对每个对象构造都用模式，结果只怕是比不用模式更糟。
或者叫设计过度。
但如果将来不是要在构造方法做扩展而是在行为模式上做扩展，
那带来修改将不可避免。技术都只能在一定范围内，
解决一定的问题，否则就是妖术。
"没有银弹"。：）
建议看看以下两篇书评，可以看到一个人对于“设计模式”的看法转变过程。
http://www.csdn.net/develop/Article/14/14238.shtm
http://www.csdn.net/develop/article/16/16367.shtm

首先，看来我的id没有选好，很多人都认为是jian1,实践上是jianl(L),呵呵。
感谢tuti大虾的发言和推荐的两篇文章，我已经保存了。
第一篇，说实话，看一遍没看懂。可能是我完全不懂建筑。等我回头慢慢再看也许能明白。
第二篇，感觉似乎作者对这本书提出两个比较大的批评：
1、无用的哲学搀和
2、没有给出各个模式的使用范围。这一点和tuti所言的：“技术都只能在一定范围内，
解决一定的问题，否则就是妖术。”一致。
我看tuti所言，似乎更倾向于了解客户，超越客户，把自己放在客户的位置来进行需求分析，
然后，如果做的好，用什么技术倒不是最重要的问题。也就是说，当前面临的最大问题不是
分析设计的问题，而是需求不明的问题。
那么我是不是应该改行去当行业专家？

To: jianL
"当前面临的最大问题不是分析设计的问题，而是需求不明的问题。"
我就是这意思。很多人都想用更好的设计方法去克服需求不明的问题，
有本末倒置之嫌。
就我观察，大多数死得很难看的项目都死在不明白"要做什么上"，
而不是死在“要怎么做”上。
我猜"行业专家"可能比"系统分析员"赚钱多。
要是能改行也未尝不可 。

to jianl
首先，先看看你（我）所举的例子
tCustomDoor = class
end;

IProtectFire = interface
procedure raiseTemp(temp:integer) //温度升高，可以是报警，可以是自动喷水，可以是不被破坏？？？
end;

tMyDoor = class(tCustomDoor,IProtectFire)
end;
在tMyDoor中没有实现raiseTemp（）方法，这个门还是不能防火！
to tuti
我举的例子只是为了说明接口与类继承之间的不同的地方，不是说明设计模式的用途。
大多数开发人员，热衷于“设计模式”都是希望它能够
轻松地对付客户需要的改变和添加。 但事实上设计模式
只能很有限的做到这点的。
这个“有限”怎么去理解到底有多大，得，我举出我现在的一个例子来说明，
我现在要做有个画流程图的东西，有点象ROSE里面画那些图的功能，
我用到了类工厂模式和COMMAND模式，我分为两个层次，专门处理元件与元件之间的关系
和本身的属性，另外是写元件本身，什么3角型，陵型啊，正方型，都有可能，我把他们的共同行为全部
抽象成接口，在处理元件关系的时候我只用接口调，我才不管当前的对象是什么鸟东东呢，
这样的好处是你写一个元件就只要测一次，以后你只要专注写你的元件了。要是你写一个元件
就测一次，那你得写到什么时候啊！还有好不容易要用的元件都写完了，现在要对元件之间的关系
作一些限制，你改完了，那一个个的元件又得测一遍，你还没测完，好象那里又得改一下。。。。。。
首先声明我不是一个很喜欢测试的人，但是有人很喜欢他！
-----------------------------------------------------------------
现有的设计模式都是通过在某个不确定的方向上添加抽象层来提供灵活性。
这就是需要在设计时就做出判断，客户需求在哪个方面上会进行怎么
样形式的变化。而事实上如果我们能有这样的预见性，那即便不用
设计模式，而采用一些比较粗糙的解决方法基本也能解决问题。
-------------------------------------------------------------------------
我觉得你不用这是很难说的，实际上你可能用了你不知道，但是这并不妨挨你用他。
如果你的“比较粗糙的解决方法基本也能解决问题”我觉得你的方法肯定要比设计
模式要好，因为设计模式不是精简了代码而是增加了代码，只是我们用我们增加了的
代码换一个好一点的软件结构。我比较欣赏“最好的修改代码的方式是增加代码”，
改代码，特别是改很多地方用到的代码，我门不得不考虑到后果---测试，因为你
不知道你改过的代码是否再次有效。
-----------------------------------------------------------------------
大家有空交流一下QQ：1960704

当前面临的最大问题不是分析设计的问题，而是需求不明的问题。"
我就是这意思。很多人都想用更好的设计方法去克服需求不明的问题，
有本末倒置之嫌。
就我观察，大多数死得很难看的项目都死在不明白"要做什么上"，
而不是死在“要怎么做”上。
--------------------------------------------------------------
比如说，我做一个工资管理系统，我对该公司的工资制度已经是很了解了，
并且我已经按现有模式做出了一个计算工资的方法，但是软件运行了3个月后
公司人事制度改革，出台一套新的工资计算方法，那怎么办呢！
这算不算“需求不明”呢！我想应该算，至少没有预料到他的工资制度会变！

说到工资，我曾经听过一位前辈这样论述：
工资一定要解决2个问题：
1、工资项目可能发生变化。
2、计算方法可能发生变化。
能解决这两个问题，就可以通吃了，呵呵。
我可以解决第一个问题，第二个问题前辈说了一个什么什么原理，不记得了，应为再也没有
做工资程序，也就忘记了，sign。

to billy_yuan
我并没有贬低 设计模式的意思，只是提醒大家不要把他当银弹看。
“有限”是多少？ 坦白说：我不知道。这个“有限”的范围主要基于
运气。结构良好的程序,要比粗糙的程序抗变动性要好一点。至于
抗得住抗不住，要看这个预先不知道的变动到底有多大。
就画流程图的东西来讲，说明 billy大虾对需求比较清楚,遇见到了
图形之间关系的复杂性。于是用factory模式处理了图形组件类型之间,匹配相关性的关系，
用COMMAND模式处理了组件实例之间,相互作用关系。使得模式得到了良好运用。
至于工资管理系统，我觉得这首先是个商业问题。让他重新出钱再做一个，
他不肯出。。。 那就只有看运气了