在经典的"四人帮"列表中,您是否经常发现任何被滥用,误解或过度使用的设计模式(除了备受争议的单身人士之外)？换句话说,有没有一种设计模式,建议您在使用前三思而后行？(为什么？)
单身模式..全局状态经常在测试时导致问题
任何依赖于单例的代码都会变得越来越难以测试,因为这种依赖关系不容易被模拟.
工厂模式......
我被空降到一个项目中,之前系统中的每个人MyObject都有一个等效MyObjectFactory的生成新实例.没有抽象概念或扩展类......只是简单的旧ClassX和ClassXFactory.
没有人可以解释为什么......"这就是事情一直以来的方式"
唯一的一个(除了前面提到的Singleton及其犯罪伙伴,工厂)不会是一个GoF,它应用于一个对象的本地属性时的setter和getter.
应用于成员变量的setter和getter在功能上与public成员变量相同.没有setter的getter更像是一个公共最终成员变量 - 但在那时为什么不只是使用一个公共最终成员变量,他们不会受到更多伤害......
唯一的区别是你"可以"拦截呼叫并覆盖它,但人们很少这样做.更常见的是,它被用作程序程序员的拐杖,以避免OO编程(这是反模式的真正原因).
使用setter和/或getter,你仍然会将你的内部成员结构暴露给外部世界(例如,如果你发现需要将int更改为long,你将不得不重构其他类)并且你几乎要确保应该在对象内部的一些代码放在外面.
我可以想到一些例外情况:
Setter用于简化对象构造.有时需要创建一个对象,然后再设置其他值.这些值应该是不可变的(您不应该调用set两次)以确保安全.
用于访问包含对象的getters.由于所包含的对象通常能够确保其自身的完整性,因此共享它们非常有用.塞特斯在这种情况下普遍不好,你不希望与换出你的鼻子正下方的特定状态的对象,它使保证你自己的诚信困难得多.
用于屏幕组件的Java Bean:是的,无法找到实现这些"属性球"的更好方法.反射对这个组件很方便,模式很有用 - 它有点像hacky但有效.
DAO/DTO Bean对象.老实说,我觉得这些都是模式的前途未卜的使用情况,但他们的模式.它通过元数据而非代码操作属性比应该更难,因为它必须是反射的.该bean的属性总是依赖于一些外部源(数据库格式,数据传输格式,组件属性,...),所以我们为什么重复定义每个部分的工作？
编辑:从恐龙的评论被盗,提出了到后期,因为这真的是我在说一个完美的总结和评论会被错过.需要,因为不是每个人似乎都认为添加语言的访问器只能编写糟糕的OO设计模式:
精简版 -
if (account1.balance > 1000)
{
account1.balance = account1.balance - 1000;
account2.balance = account2.balance + 1000;
}; = BAD CODE.
account2.deposit(account1.withdraw(1000)); = GOOD CODE.
第二个不需要访问者... - kyoryu(由于我比他的评论中有更多的空间而被账单k略微修改).
第二个是将测试和其他一些数学移动到Account中,而不是在每个可能进行传输的地方将其复制到整个代码中.
只是为了说明问题更多,请注意,使用"GOOD CODE"样式很明显,.withdraw的输出可能是一个Transaction对象,其中包含有关整个事务的信息,包括其成功,源和目标以及日志记录功能.对于以"BAD CODE"风格编写代码的人来说,这会怎样？
另外你如何重构BAD CODE甚至使用这样的对象？这只是一团糟.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
