敏捷思考 遵循与破坏"开闭原则"

2.在没OO之前,就是用你这种方式抽象的.已经有人用过了.
这个没什么好说的,函数本来就可以隔离具体实现,但函数本身不具备继承和多态的特性.

3.维护成本?代码行数少了,注释密度增大后,人眼一次看到全图的可能性提高了...
如果只是为了可读性,那么生成一个doc文档不就可以了吗?即使你用接口来做这件事情,要做的工作也不会轻松多少

4.我可以保证世界上99%以上的应用使用对象不是程序员.所以我相信用户读懂接口可能性更高一些出错可能性小
我想我没有讨论到交付一个产品给用户,而是一个程序在开发过程中的设计,对于你提出的这个场景,读一份doc文档或许也不必读接口源文件要困难.

以上我想说的是,接口应该有它本身的作用,而不是作为文档.

5.怎么对未来进行判断?你是说算卦么?
这就举两个例子吧:
5.1我现在要实现一个对User Entity的分页,那么我考虑到系统中其他的实体或者记录都需要分页(这个需求是明显的),那么我不应该只做User Entity的分页,应该把它抽象出来,其他的记录也可以重用这一个分页组件,而只需要做一些必要的实现.
5.2我现在用Hibernate来做ORM,我考虑了一下我以后会不会换ORM框架呢?这种需求概率不大,因此我不需要现在做抽象,我只做一个具体实现.
以上就是我所说的判断,我觉得不应该算作是算卦,算卦的话是随机概率事件,而以上是确实有客观依据的,这些依据让你决定是否做抽象.
一个新理论:"如果你只能用算卦来决定未来是否会产生变化,那么你不应该现在就做抽象"

6.你可以把你的理论延生出的实践拿出来我们来试一下.
在我的应用中,我连XXXDAO都不要,就只有一个DAO

UserService -> DAO
XXXService -> DAO

这一点是因为我发现XXXDAO和YYYDAO提供的功能基本是一致的,只是名字不一样.DAO就实现一些数据存储的东西,我并不把业务逻辑放到里边.

其实我这篇文章想说的就是,不要做没有必要的抽象,维护接口和具体实现比单单维护具体实现的代价是要高的,另外说一下我理解的OCP概念.
非常希望异常哥能够给我指出我这样的实践方式会有什么样的问题.谢谢

2........
3没有约束,变更后.成本更高
4.你作的应用中有没有大量的private 方法呢?我作的项目有不少.这些方法也是有注释的,客户不关心这些东西,而且还有很多工具类.增加视觉负担
5.问题是客户不关心颁,也不关心实现.把这些无用的信息去掉.接口的内容就少了.

6.这个问题在于为了适应框架与社会分工,
有些应该合并的DAO没合并在一起
应该拆分的service没拆分.
张三要作dao + service  + action + jsp + js
李四要作dao + service  + action + jsp + js

这里dao的名子与意义根本无法确定
导至接口一点意义没有
没有意义的接口不要了吧.

感觉都有点跑题了,说到用什么东西来做手册了.
private方法我也是一堆一堆的用,生成doc可以只生成public method.(另外我private不太喜欢写注释,程序结构合理一些的话,其实方法的名字往往就可以当做注释了)
我确实不太赞成使用接口来做用户手册.我们可以有其他东西来做.

另外分工的这一点,大家都用一个DAO,大家都不用自己去写DAO
张三做 xxxService method -> jsp
李四做 xxxService method -> jsp
这样就省去了大家重复写只是名字不同的DAO的劳动,也让DAO的职责更单一一些.


变更有时候是无法约束的.
我想说多一个接口并不能改变变更的可能性,而少一个接口,面对变更时需要进行的修改将会更简单.
比如:
UserService 现在要增加一个计算User总量的函数,如果我有没有IUserService接口,我只需要去增加一个函数,如果有接口,我必须让他们保持同步,这就要花费更多的力气.

何出此言？

service与dao分开
是框架决定的
是选型问题
为了考虑重用性
(这个问题在现在分工方式是个伪命题)

约束是指代码与文档

PS:保持同步在eclipse里只要抽一下就可以了.
并没多麻烦.

理解,
接口有时候并不用作它本来的意义,而是作为一种协作之间的规约,类似API文档的东西.
这种做法容易误导新手对于接口在JavaOO中实际意义的理解.不去评论这种做法的对错了,它既然是有效的,那么就有存在的价值.或许我们有更好的方式来做这件事情,只是我们还没有去尝试.

这确实有些跑题了~

异常哥提出的这一点后,搞得我的命题变得复杂了,那么不谈接口的额外作用,从它本来应该做的事情上来说,我们应该消除很多没有必要的接口."依赖抽象,不依赖于具体实现"这句话并非对所有情况都是真理.

开闭原则太隐晦了。针对接口编程和针对实现编程，前者只是用初期的较小付出为不可知的系统变化买的一份保险。这个例子应该算是典型的策略模式吧？

1.开闭原则隐晦
我写这篇文章就是想说说自己的认识,如果你不明白,能否说一下是哪里有困惑,讨论讨论

2.这个例子应该算是典型的策略模式吧？
策略模式的定义就是依赖于抽象,不依赖于具体实现.所以你只要依赖于抽象的地方都可以理解为策略模式.(个人感觉很无聊的一个模式)

隐晦的是它的名字。开闭原则在我看来就是针对接口编程。而策略模式最直接的解释了它。

开闭是一个原则,遵循这个原则不一定要用哪一个模式,策略模式是一种解决办法,但不同场景下也有不同的解决方法.