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

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

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

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

像:

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

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

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

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

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

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

类命名不佳

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

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

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

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

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

其次是:

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

无法正确进行单元测试.

反模式

软件设计反模式

抽象反转:不暴露用户所需的实现功能,以便他们使用更高级别的功能重新实现它

模糊观点:在不指定其观点的情况下呈现模型(通常为OOAD)

大泥球:一个没有可识别结构的系统

Blob:从面向对象的设计中推广上帝对象

燃气工厂:一种不必要的复杂设计

输入kludge:未指定和实现可能无效输入的处理

界面臃肿:使界面如此强大,以至于很难实现

Magic按钮:直接在接口代码中编码实现逻辑,而不使用抽象.

种族危害:未能看到不同事件顺序的后果

铁路解决方案:一种建议的解决方案虽然很差,但由于在设计的其他方面缺乏远见和不灵活性,因此是唯一可用的解决方案

重新耦合:引入不必要的对象依赖

Stovepipe系统:几乎无法维护的与病态相关的组件

Staralised架构:包含用于规范化和数据集市使用的双用途表的数据库架构

面向对象设计反模式

遗忘域模型:使用没有任何非OOP业务逻辑的域模型,因为每个对象都应该具有属性和行为

BaseBean:从实用程序类继承功能而不是委托给它

调用super:要求子类调用超类的重写方法

圆椭圆问题:基于值子类型对变量类型进行子类型化

空子类失败:创建一个未通过"空子类测试"的类,其行为与从中派生的类不同而没有修改

上帝对象:在设计的单个部分集中太多功能(类)

对象污水池:重用状态不符合(可能是隐式)合同的对象进行重用

对象狂欢:未能正确封装对象,允许不受限制地访问其内部

恶作剧者:唯一目的是将信息传递给另一个物体的物体

顺序耦合:需要以特定顺序调用其方法的类

单胎炎:过度使用单身人士模式

又一个无用的层:向程序,库或框架添加不必要的层.在第一本关于编程模式的书之后,这变得很流行.

溜溜球问题:由于过度碎片化而难以理解的结构(例如,继承)

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

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

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