面向对象的设计启发式(2017)
1.面向对象的 设计指南I2252-教授。Kim Mens*这些幻灯片是课程LINGI2252“软件维护和发展”的一部分，由比利时伦敦大学学院的Kim Mens教授讲授*。
2.面向对象的设计启发--面向对象的设计启发--Arthur J.Riel 面向对象的设计启发 ©Addison-Wesley，1996年。 其他来源：由科罗拉多博尔德大学的肯尼思·M·安德森教授关于面向对象设计启发的演讲(2002年4月)苏黎世大学哈拉尔德·加尔教授关于面向对象设计启发的演讲(2006年)马克·霍伊杰的博客。
3.面向对象设计启发式是指系统设计良好？如何知道系统的面向对象设计是好是坏/介于两者之间？如果你问一位面向对象专家：“感觉正确的时候设计是好的”，如何知道什么时候感觉正确？潜意识里，大师会检查通过以前的设计经验建立起来的一系列设计启发式。如果启发式通过了，那么设计感觉是正确的。如果没有通过，说明设计感觉不正确。
4.面向对象的设计准则面向对象的设计准则Arthur J.Riel 面向对象的设计准则 ©Addison-Wesley，1996.~60条与语言无关的准则提供对OO设计改进的见解没有硬性规则，只有启发式：当不相关时可以忽略以程序员为目标提高他们的OO编程和设计技能基于Riel作为CS教师和OO A&A；D顾问的经验。
5.面向对象的设计思想--面向对象设计思想的核心--面向对象的设计思想(OO-OO Design HEURISTICSA，OO Design HEURISTICSA)。类和对象B。过程性应用程序与面向对象应用程序的拓扑。类和对象之间的关系D。继承关系E。多重继承其他类别：F.关联关系G.。类-种fic数据和行为H。面向物理对象的设计5。
6.面向对象的设计理念：WARNING…的Word。并不是所有的启发式方法都能完美地配合使用。有些甚至可能是直接对立的！在分析和设计时总是需要权衡的。例如，降低复杂性的改变可能会降低fl的可行性。你必须决定哪种启发式方法对你的特定环境最有意义。启发式方法并不是总是有效的“黄金”规则。
8.面向对象设计HEURISTICSHIDING DATAHeuristic A1所有数据都应该隐藏在它的类中。 8当开发人员说：“我需要公开这段数据是因为……”时，他们应该问问自己：“我试图用这些数据做什么，为什么类不能为我执行那个操作？”它真的必须公开给其他人吗？这段数据真的属于这个类吗？
9.面向对象设计HEURISTICSNO对CLIENT的依赖启发式A2类的用户必须依赖于它的公共接口，但类不应该依赖于它的用户。9为什么？
10.面向对象设计HEURISTICSNO依赖于CLIENT启发式A2一个类的用户必须依赖于它的公共接口，但是一个类不应该依赖于它的用户，为什么？可重用性！10例如，一个人可以使用闹钟，但闹钟不应该知道此人的情况。 否则闹钟不能供其他人使用。参数名称：BOBJONESAGE：31SSN：037439087TEL：991-4671闹钟CLOCKHOUR：12 分钟：34 闹钟小时：6ALARM分钟：0ALMR STATUS：ON。
11.面向对象设计HEURISTICSONE CLASS=one RESPONSIBILITYHeuristic A.8A类应该捕获一个且只有一个关键抽象。11A类应该是内聚性的。 尝试每个类有一个明确的职责。
12.面向对象设计启发类启发式A.3最小化类协议中的消息数量(类的协议是指类的实例可以响应的消息集) 保持它很小。大型公共接口的问题是你永远不能fi和你要找的东西。较小的公共接口使类更容易理解和修改。12。
13.面向对象设计启发式 多态和通信启发式A.4实现所有类都能理解的最小公共接口。例如，复制(深浅)、等价性测试、美观打印、从ASCII码描述中解析等操作。ASCII为什么？能够向不同的对象发送相同的消息。能够替换它们。13。
14.面向对象设计启发式SCLEAR PUBLIC INTERFACES保持干净：类的用户不希望在公共接口中看到他们不应该使用、不能使用或不感兴趣的操作。 启发式A.5不要将实现细节(如公共代码私有函数)放入类的公共接口中。启发式A.6不要用客户端不能使用或不感兴趣使用的项扰乱类的公共接口。14。
15.面向对象设计HEURISTICSMINIMISE类INTERDEPENDENCIES用于松散耦合！ 启发式A.7A类应该只使用另一个类的公共接口中的操作，或者与该类无关。15。
16.面向对象设计HEURISTICSSTRENGTHEN ENCAPSULATIONA类应具有内聚性。将数据移动到行为附近。启发式A.9将相关数据和行为保留在一个位置。(类似于“Move Method”重构模式。)启发式A.10将不相关的信息拆分到另一个类中。(类似于“提取类”重构模式。)16.。
17.面向对象设计启发式VS(Object-Oriented Design HEURISTICSROLES)VS.。类启发式A.11确定你建模的抽象是类，而不仅仅是对象扮演的角色。父母是不同的类，或者更确切地说，是人的角色？没有神奇的答案：取决于域。他们有不同的行为吗？如果是这样的话，他们更有可能是不同的阶层
18.面向对象设计HEURISTICSB。过程性VS的拓扑。OO应用程序这类启发式方法是关于在OO应用程序中使用非OO结构。过程拓扑将应用程序分解为共享数据结构的函数。在这样的拓扑中，很容易看出哪些函数访问哪些数据结构，但很难知道哪些函数使用了哪些数据结构。更改数据结构可能会对使用它的函数产生意想不到的后果。面向对象的拓扑试图使数据更接近行为。
19.面向对象设计原则风格问题熟悉过程技术的开发人员尝试创建OO设计时出现的两个典型问题：上帝类驱动应用程序的单个类； 所有其他类都是数据持有者。类的激增模块化程度过高的问题。太多大小/范围太小的类使系统很难使用、调试和维护。19.面向对象的设计原则风格问题当熟悉过程技术的开发人员尝试创建OO设计时，会出现两个典型的问题：上帝类驱动应用程序的单个类；所有其他类都是数据持有者。类的激增模块化程度过高的问题。太多的类在大小/范围上太小，使得系统很难使用、调试和维护。19。
20.面向对象设计启发创建上帝类不要创建控制所有其他类的上帝类。启发式B.12尽可能均匀地横向分布系统智能，即设计中的顶级类应该均匀地分担工作。启发式B.13不要在系统中创建上帝类或上帝对象。对名称包含驱动程序、管理器、系统、子系统等的类要非常怀疑。20.启发式B.13不要在系统中创建上帝类或上帝对象。对名称包含驱动程序、管理器、系统、子系统等的类要非常怀疑。20.启发式B.13不要在系统中创建上帝类或上帝对象。对名称包含驱动程序、管理器、系统、子系统等的类要非常怀疑。
21.。面向对象设计启发式B.14注意接口中有许多访问器方法Defi的类。这可能意味着相关的数据和行为没有保存在同一位置。启发式B.15注意具有过多非通信行为的类，即只在其数据成员的适当子集上操作的方法。上帝类通常表现出大量的非通信行为。
22.。面向对象设计启发式B.18从您的设计中删除不相关的类。无关的类通常只有GET、SET和PRINT方法。启发式B.19删除系统外的类。域相关的原则。启发式B.20不要将操作变成类。不要怀疑任何名称是动词或派生自动词的类，特别是那些只有一段有意义行为的类。问问自己。
23.。面向对象的设计启发式B.17尽可能对真实世界建模？启发式B.17尽可能地对真实世界建模。(由于系统智能分布、避免使用上帝类以及将相关数据和行为保存在一个地方的原因，这种启发式经常被违反。)如果您希望同一模型有两个不同的UI怎么办？启发式B.16在由面向对象的模型与用户界面交互组成的应用程序中，模型永远不应该依赖于接口。接口应该取决于型号。23。
24.。面向对象设计HEURISTICSC。类和对象之间的关系一般的指导方针是：类和对象内部的高度内聚力类和对象之间的松散耦合24。
25.。面向对象设计启发式C.22最小化类之间的耦合启发式C.22最小化其他类与之协作的类数。查找一个类与一组类通信的情况。询问是否可以用包含该组的类替换该组。 争取 松散耦合！25
26.。面向对象的设计启发类之间的耦合相关的启发式： 启发式c.23：最小化类与其协作者之间发送的消息的数量。(反例：访问者设计模式) 启发式C.24：最小化类与其协作者之间的协作量，即发送的不同消息的数量。 启发式c.25：最小化类中的扇出，即类和fi所需消息数的乘积。
27.。面向对象设计原则使用关系SHIP当一个对象“使用”另一个对象时，它应该获得对它的引用，以便与它交互以获得引用：(包容)包含另一个对象的类的实例变量另一个对象作为被请求的参数传递给第三方对象(映射…)。创建另一个对象的实例，然后与其交互27。
28.。面向对象设计HEURISTICSCONTAINMENT和USESHeuristic C.26如果一个类包含另一个类的对象，则包含类应该向包含的对象发送消息，也就是说，包含关系应该始终暗示“使用”关系。启发式C.34A类必须知道它包含什么，但永远不应该知道是谁包含它。(不依赖于您的用户。)28.。
29.。面向对象的设计启发类中的启发式c.27：类上的大多数方法defiNed应该在大多数时间使用大多数数据成员。类应该是内聚性的。 启发式c.28：类包含的对象不应该超过开发人员在他或她的短期内存中fit所能包含的对象。这个数字最喜欢的值是6(或7)。 启发式c.29：将系统智能垂直分布在狭窄和深层的遏制层次结构中。29STRIVE用于 高内聚力！
31.。面向对象设计HEURISTICSINHERITANCE DEPTHHeuristic D.39在理论上，继承层次结构应该越深-越深越好Heuristic D.40然而在实践中，继承层次结构不应该比普通人在他或她的短期记忆中所能保持的深度更深。这方面的通俗值是6。31。
32.。面向对象设计HEURISTICSABSTRACT CLASS=基类启发式D.41.所有抽象类必须是基类。启发式D.42：所有基类必须是抽象类。基类=至少有一个子类的类抽象类=至少有一个抽象方法的类这些启发式方法是有争议的。
33.。面向对象设计HEURISTICSABSTRACT CLASS=基类：有争议！启发式D.41：所有抽象类必须是基类。启发：如果不想在子类中具体化方法，为什么要使其抽象？反例：应用程序框架启发式D.42：所有基类都必须是抽象类。启发：在子类中覆盖的方法在超类中应该是抽象的。不一定是真的：它们可以在超类；子类中具有默认行为或值。
34.。面向对象的设计启发式继承中的类启发式D.37派生的类必须知道它们的基类，但基类不应该知道它们的派生类的任何信息。超类不应该知道它的子类。启发式D.38基类中的所有数据都应该是私有的；不使用受保护的数据。子类不应该直接使用超类的数据。启发式D.51派生类覆盖基类应该是非法的
35.。面向对象的设计准则继承中的通用性启发式D.43考虑数据、行为和/或接口的共性，在继承层次结构中尽可能高。启发式D.45如果两个或更多的类具有共同的数据(变量)和行为(即方法)，那么这些类都应该从捕获那些数据和方法的公共基类继承。35.启发式D.45如果两个或更多的类具有共同的数据(变量)和行为(即方法)，则每个类都应该从捕获这些数据和方法的公共基类继承。35.启发式D.43考虑数据、行为和/或接口的通用性，在继承层次结构中尽可能高地考虑数据、行为和/或接口。
36.。面向对象设计在继承中的启发HIERARCHIESHeuristic D.44如果两个或更多的类只共享公共数据(没有共同行为)，那么公共数据应该放在每个共享类将包含的类中。启发式D.44.bi如果两个或更多的类只共享公共接口(即消息，而不是方法)，那么只有当它们将被多态使用时，它们才应该从公共基类继承。
37.。面向对象设计HEURISTICSAVOID类型检查(本质！)启发式D.46显然，对对象类型的案例分析通常是错误的。或者至少是糟糕的设计：设计者应该使用多态性来代替。事实上，在大多数情况下，对象应该负责决定如何回复消息客户端应该只发送消息，而不是基于接收者类型发送的消息37。
38.。面向对象设计HEURISTICSAVOID CASE CHECKSHeuristic D.47对属性值的显式案例分析经常出错。类应分解为继承层次结构，其中每个属性值都不会转换为派生类。38。
39.。面向对象设计HEURISTICSINHERITANCE=SPECIALISATION启发式D.36继承应该仅用于建模专门化层次结构。不要混淆继承和包容。包容是黑盒。 继承是白盒。启发式D.52不要混淆可选包容和继承需要。用继承对可选包容建模会导致类的激增。
40.。面向对象设计HEURISTICSDYNAMIC SEMANTICSHeuristic D.48不要通过使用继承关系来建模类的动态语义。尝试用静态语义关系来建模动态语义将导致在运行时类型发生变化。Heuristic D.49不要将类的对象转换为类的派生类。对任何只有一个实例的派生类要非常警惕。Heuristic D.50I.启发式D.50I.试探性D.49不要将一个类的对象转换为该类的派生类。对任何只有一个实例的派生类要非常警惕。启发式D.50I.启发式D.50I.试探性D.49不要将一个类的对象变成该类的派生类。要非常怀疑任何只有一个实例的派生类。启发式D.50I。现在将这些对象概括为一个新类。
41.。面向对象的设计HEURISTICSFRAMEWORKS启发式D.53在构建继承层次结构时，尝试构建可重用的框架，而不是可重用的组件。41。
43.。面向对象设计HEURISTICSPROVE多重继承尽可能避免使用多重继承。 启发式E.54如果你在你的设计中有一个多重继承的例子，假设你犯了一个错误，然后证明不是这样。 最常见的错误：用多重继承代替包容43
44.。面向对象设计HEURISTICSQUESTION ITHeuristic E.55当OO设计中有继承时，问问自己两个问题：(A)我是要继承的东西的特殊类型吗？(B)我要继承的东西是我的一部分吗？对(A)和(B)的“是”和“否”意味着需要继承。对(A)和对(B)的“否”则意味着需要合成？-飞机是不是一种特殊的类型？不是(机身是飞机的机身)-机身是飞机的一部分吗？是44。
45.。面向对象设计HEURISTICSQUESTION ITHeuristic E.56当您在OODesign中发现多重继承关系时，请确保没有基类实际上是另一个基类的派生类，即。偶然的多重继承。
46.。面向对象设计原则在这里，多重继承是否有效？是的，子类型化用于组合当Defi有一个新类是另外两个类的特殊类型，并且这两个基类来自不同的域时，WOODENOBJECTDOORWOODEN DOOR46。
47.。面向对象设计的启示木门是一种特殊的门吗？是的， 是木门的一部分吗？没有 是木门的一种特殊类型的木制品吗？是的， 是门的木制品吗？No 是木制物体，是一种特殊类型的门吗？没有 是门的一种特殊类型的木制品吗？没有试探法通过！WOODENOBJECTDOORWOODEN DOOR47。
48.。面向对象设计HEURISTICSOHER分类面向对象设计HEURISTICSF。协会关系G。类-种fic数据和行为H。面向物理对象的设计48。
49.。面向对象设计HEURISTICSF。关联关系SHIPHeuristic F.57：包容还是关联？在OO设计中，如果要在娱乐和关联之间进行选择，请选择包容关系。49。
50.。面向对象设计HEURISTICSG。特定于类的数据和BEHAVIOURHeuristic G.58：无全局记账请勿使用全局数据或函数来执行有关类对象的记账信息。应该使用类变量或方法。50。
51.。面向对象设计HEURISTICSH。面向物理对象的设计启发式H.5900O设计者不应允许物理设计标准破坏他们的逻辑设计。然而，物理设计标准经常在逻辑设计时的决策过程中使用。启发式H.60不通过对象的公共接口不改变对象的状态
52.。面向对象设计准则使用以下准则：有洞察力的分析关键评审作为更好的OO设计的指南来构建可重用的组件和框架。
53.。面向对象设计启发式问题▸给出并解释了关于子类与其超类之间关系的至少两种设计启发式，▸讨论了“所有抽象类都必须是基类”和“所有基类都应该是抽象类”的设计启发式。你同意这些试探法吗？在什么情况下呢？▸几种设计启发式都与高内聚力的需要有关。讨论2个这样的启发式及其与内聚力的关系。▸几个设计启发式与松散耦合的需要有关。讨论了2个这样的启发式及其与耦合的关系，▸讨论了下面的设计启发式“对对象类型的显式案例分析通常是错误的”，▸给出了一个具体的例子，并讨论了何时多重继承是有效的设计解决方案。
