50,526
社区成员
发帖
与我相关
我的任务
分享其实 接口，徒有虚名！！！！！
我感觉设计模式其实是在误导设计人员！我发现，所有设计模式的例子其实都是在一种完美的环境下讲述的。
但在实际业务中，很少有这样完美的环境，都是相当复杂的。
在有些实际业务里，接口是很难定义出来的。
就算定义出来了，也是徒有虚名！
大家认为呢？
但在实际业务中，很少有这样完美的环境，都是相当复杂的。
在有些实际业务里，接口是很难定义出来的。
就算定义出来了，也是徒有虚名！
大家认为呢？
...全文
请发表友善的回复…
发表回复
AllError 2003-10-31
- 打赏
- 举报
其实 接口，徒有虚名！！！！！,不过没有不行
chuijon 2003-10-31
- 打赏
- 举报
我觉得接口的定义还是应该从需要出发吧，如果某个部分是可变的，需要有变化的，或者暂时不能确定具体处理的，用接口来做吧。
北极猩猩 2003-10-30
- 打赏
- 举报
通过重构使用模式，这是最基本的道理。
一上来就逃用一大堆设计模式是没有用的，而且极容易导致过度设计。
初始设计应该以简单明晰为主，在变化中发现需求（通常是代码中的bad smell）然后对其进行重构，为了满足重构的目标再根据需要应用设计模式
一上来就逃用一大堆设计模式是没有用的，而且极容易导致过度设计。
初始设计应该以简单明晰为主，在变化中发现需求（通常是代码中的bad smell）然后对其进行重构，为了满足重构的目标再根据需要应用设计模式
zzzbbbll0304 2003-10-30
- 打赏
- 举报
对，是，有些极端。
应该改成，有时接口，徒有虚名。
比如。拿DAO 模式，和模板方法模式，工厂模式 ，策略模式来说 来说，说实话，以前我刚接触设计模式的时候。
对这个东西看的很深奥。上面有位兄弟说的DAO，说实话我感觉它根本就不是什么新鲜东西。可是当我学完之后，我发现我一年前的项目所做的设计 竟然和这些设计模式不谋而和。那时我只是听说过设计模式，但在作设计的时候，我只掌握一条原则，就
是：能写一遍的代码，尽量不让它写两遍！！！！！
相反，当我学完设计模式之后，反而思维受到限制。想问题的时候，总是
拿出那几个模式，感觉相似，就往上套，总想定义出接口。
可是事与愿违！弄的我很苦恼。
最后，还是 艺术向业务妥协了。
应该改成，有时接口，徒有虚名。
比如。拿DAO 模式，和模板方法模式，工厂模式 ，策略模式来说 来说，说实话，以前我刚接触设计模式的时候。
对这个东西看的很深奥。上面有位兄弟说的DAO，说实话我感觉它根本就不是什么新鲜东西。可是当我学完之后，我发现我一年前的项目所做的设计 竟然和这些设计模式不谋而和。那时我只是听说过设计模式，但在作设计的时候，我只掌握一条原则，就
是：能写一遍的代码，尽量不让它写两遍！！！！！
相反，当我学完设计模式之后，反而思维受到限制。想问题的时候，总是
拿出那几个模式，感觉相似，就往上套，总想定义出接口。
可是事与愿违！弄的我很苦恼。
最后，还是 艺术向业务妥协了。
dreamhead 2003-10-30
- 打赏
- 举报
初学设计模式的时候，有着同大家的类似的感觉，每学一个模式总要想法设法的把它应用起来，造成的结果是处处受限。
经过一段时间的沉淀之后，我倒不觉得设计模式是什么羁绊了。
学习设计模式更多是应该掌握其中的思想，让自己写出代码弹性更好。
最近拜读Robert Martin的《敏捷软件开发》，其中讲到了许多设计原则，慢慢地开始体会到设计模式的内涵。运用设计模式实际上就是让系统在未来的维护和修改中，节省不该浪费的体力。
谁都知道倚天屠龙的威力，却不是每个拥有倚天屠龙的人都能让它发挥出最大威力。
经过一段时间的沉淀之后，我倒不觉得设计模式是什么羁绊了。
学习设计模式更多是应该掌握其中的思想，让自己写出代码弹性更好。
最近拜读Robert Martin的《敏捷软件开发》，其中讲到了许多设计原则，慢慢地开始体会到设计模式的内涵。运用设计模式实际上就是让系统在未来的维护和修改中，节省不该浪费的体力。
谁都知道倚天屠龙的威力，却不是每个拥有倚天屠龙的人都能让它发挥出最大威力。
longaway 2003-10-30
- 打赏
- 举报
马桶从来没有说过
自己有吸力的。
自己有吸力的。
truezerg 2003-10-30
- 打赏
- 举报
armorking2003(阿墨) 说的不错,犹其是
"从实际业务到抽象出接口，可能是一个痛苦而艰难的过程" 这句
如果把这句
“所以，重构经常是必要的 ” 改成 “所以，经常重构是必要的”那就更好了 :)
人间天上 的经历和我一样。 也是一年多前，自己做完了项目之后了解到持久层的模式时发现自己做的和书上讲的竟然是一样的。只是当时没有叫DAO而叫DB，VO没有叫VO而叫Table。哈，名字起的是差了点
"从实际业务到抽象出接口，可能是一个痛苦而艰难的过程" 这句
如果把这句
“所以，重构经常是必要的 ” 改成 “所以，经常重构是必要的”那就更好了 :)
人间天上 的经历和我一样。 也是一年多前，自己做完了项目之后了解到持久层的模式时发现自己做的和书上讲的竟然是一样的。只是当时没有叫DAO而叫DB，VO没有叫VO而叫Table。哈，名字起的是差了点
soloxiao 2003-10-30
- 打赏
- 举报
学习!
wdhs 2003-10-30
- 打赏
- 举报
相反，当我学完设计模式之后，反而思维受到限制。想问题的时候，总是
拿出那几个模式，感觉相似，就往上套，总想定义出接口。
-----------------------------------------------------------
我刚开始接触设计模式，有同感 ：）
不过，设计模式只是一个套路，有空的时候想想它为什么是这样而不那样，对我帮助挺大。
拿出那几个模式，感觉相似，就往上套，总想定义出接口。
-----------------------------------------------------------
我刚开始接触设计模式，有同感 ：）
不过，设计模式只是一个套路，有空的时候想想它为什么是这样而不那样，对我帮助挺大。
shangqiao 2003-10-29
- 打赏
- 举报
但是还是有好的接口呀,你不是成天用Collection和Itertor吗?
SwordsmanF 2003-10-29
- 打赏
- 举报
呵呵，我最近也要做一个称为“数据接口”的东西。它被描述成一个完整的，无值守的应用程序。在我的最初印象中，“接口”不应该是一个独立运行的并且完成任务应用程序。它应该是一个方便其它应用程序调用并规范数据的东西。大家怎么看？
armorking2003 2003-10-29
- 打赏
- 举报
哦，这话有道理
但过于极端
oo的一个基本目的在于重用
实现重用的难度在于：永远存在特例
于是，随着用户需求的变更，软件的结构越来越背离原意
所以，重构经常是必要的
而模式，降低了重构的难度
从这个角度看，初始设计作的再漂亮也没用
从实际业务到抽象出接口，可能是一个痛苦而艰难的过程
这里考验的是设计师的经验
而没有模式作为参照，设计出来的东东，很难保证可维护性
因为，模式的目的在于降低耦合，提高内聚
无米之炊岂是易为？
但过于极端
oo的一个基本目的在于重用
实现重用的难度在于：永远存在特例
于是，随着用户需求的变更，软件的结构越来越背离原意
所以，重构经常是必要的
而模式，降低了重构的难度
从这个角度看，初始设计作的再漂亮也没用
从实际业务到抽象出接口，可能是一个痛苦而艰难的过程
这里考验的是设计师的经验
而没有模式作为参照，设计出来的东东，很难保证可维护性
因为，模式的目的在于降低耦合，提高内聚
无米之炊岂是易为？
