面向对象设计不良的迹象有哪些？

Question

在设计新系统或了解其他人的代码时,有哪些迹象表明设计阶段出现了问题？是否有寻找类图和继承层次结构的线索,甚至是代码本身,只是为设计检修而尖叫,特别是在项目的早期？

Answer 1

对我来说最重要的事情是" 代码味道 ".

大多数情况下,我对违反"良好做法"的事情很敏感.

像:

• 除了你从名称中想到的东西之外的其他方法(例如:静默删除零字节文件的FileExists())

• 一些非常长的方法(程序周围的对象包装的标志)

• 在同一个枚举成员上重复使用switch/case语句(需要提取的子类的符号)

• 很多成员变量用于处理,而不是捕获状态(可能表示需要提取方法对象)

• 一个有很多责任的班级(违反单一可重复性原则)

• 成员访问的长链(this.that很好,这个.其他很好,但my.very.long.chain.of.member.accesses.for.a.result很脆弱)

• 类命名不佳

• 在狭小空间内使用太多设计模式

• 工作太辛苦(重写框架中已存在的功能,或同一项目中的其他地方)

• 拼写错误(任何地方)和语法(在评论中),或评论只是误导

Answer 2

我会说OO设计不好的头号规则(是的,我曾多次犯过它!)是:

• 违反单一责任原则(SRP)并执行过多操作的类

其次是:

• 太多的继承而不是组合,即纯粹从子类派生的类,因此它们可以免费获得功能. 赞成组合而不是继承.

Answer 3

无法正确进行单元测试.

Answer 4

反模式

软件设计反模式

• 抽象反转:不暴露用户所需的实现功能,以便他们使用更高级别的功能重新实现它
• 模糊观点:在不指定其观点的情况下呈现模型(通常为OOAD)
• 大泥球:一个没有可识别结构的系统
• Blob:从面向对象的设计中推广上帝对象
• 燃气工厂:一种不必要的复杂设计
• 输入kludge:未指定和实现可能无效输入的处理
• 界面臃肿:使界面如此强大,以至于很难实现
• Magic按钮:直接在接口代码中编码实现逻辑,而不使用抽象.
• 种族危害:未能看到不同事件顺序的后果
• 铁路解决方案:一种建议的解决方案虽然很差,但由于在设计的其他方面缺乏远见和不灵活性,因此是唯一可用的解决方案
• 重新耦合:引入不必要的对象依赖
• Stovepipe系统:几乎无法维护的与病态相关的组件
• Staralised架构:包含用于规范化和数据集市使用的双用途表的数据库架构

面向对象设计反模式

• 遗忘域模型:使用没有任何非OOP业务逻辑的域模型,因为每个对象都应该具有属性和行为
• BaseBean:从实用程序类继承功能而不是委托给它
• 调用super:要求子类调用超类的重写方法
• 圆椭圆问题:基于值子类型对变量类型进行子类型化
• 空子类失败:创建一个未通过"空子类测试"的类,其行为与从中派生的类不同而没有修改
• 上帝对象:在设计的单个部分集中太多功能(类)
• 对象污水池:重用状态不符合(可能是隐式)合同的对象进行重用
• 对象狂欢:未能正确封装对象,允许不受限制地访问其内部
• 恶作剧者:唯一目的是将信息传递给另一个物体的物体
• 顺序耦合:需要以特定顺序调用其方法的类
• 单胎炎:过度使用单身人士模式
• 又一个无用的层:向程序,库或框架添加不必要的层.在第一本关于编程模式的书之后,这变得很流行.
• 溜溜球问题:由于过度碎片化而难以理解的结构(例如,继承)

Answer 5

这个问题假设面向对象意味着良好的设计.有些情况下,另一种方法更为合适.

Answer 6

一种气味是具有硬依赖性/对其他对象的引用的对象,这些对象不是其自然对象层次结构或域相关组成的一部分.

示例:假设您有城市模拟.如果Person对象具有NearestPostOffice属性,则可能遇到麻烦.