对面向对象（OOP）的进一步了解(2)

很明显，如果Better Mousetrap的工厂和员工住在同一个城市，并且Zokko Soda的两个工厂都建在另一个城市，那么城市之间的交通将会大大改善.

比较两张图，上面两个城市之间出现交通问题的原因是，每个城市的“聚合”相对较低: 两个不相关的公司出现在同一城市，使得内部城市的交通利用率为相对较低，城市之间的交通超载.

让我们看一下耦合的定义: 耦合是模块之间相关程度的度量. 相对于聚合的内向性，耦合集中于某个模块和其他模块之间的相关性. 实际上，在前面的示例中，我们不可避免地提到了耦合问题: 由于两个城市之间的紧密联系，导致了城市之间的交通拥堵. 另一个潜在的问题是，如果一个城市发生交通问题，另一座城市也会受到影响. 我们寻求的低​​耦合是尽可能减少两个模块之间的关系，并且一个模块的更改对其他模块的影响尽可能小.

让我们谈谈生活中的另一个例子. 我相信80年代以后的大多数人都在玩掌上游戏机，其中包含方块游戏. 尽管这种游戏机风靡一时，但它很快就会逐渐淡出市场，因为这种游戏机只能由Tetris玩. 当我们厌倦了玩游戏时，这个游戏机就像是浪费.

在同一时期，任天堂推出了红白相间的机器，这种机器已经流行了近20年. 这种游戏机的市场寿命很长. 这不是因为游戏机本身的质量，而是因为基于红色和白色机器的游戏的不断发展. 无数经典. 当时，甚至还不知道Contra和Super Mary. 红白机本身的游戏不存储在游戏机中. 每当启动新游戏时，您只需要购买一个新卡带. 游戏控制台和游戏盒的这种相对独立的设计，因此游戏设计制造商无需关心游戏控制台的实现细节，只要他们遵循游戏控制台提供的界面（插槽）即可. 许多游戏设计公司还从巨大的红白机市场中抢占了一块市场. 大多数玩家可能都不知道Contra并不是任天堂推出的产品，但是Konami公司（目前称为“实况足球”系列）在1988年从拱廊移植到了红白相间的机器上.

回到耦合的主题，因为较早的掌上游戏机将游戏本身内置到机器中，所以游戏的两个模块与机器之间的关系太紧密，因此游戏厌倦了游戏，并且游戏机无用游戏机坏了，不能再玩游戏了. 红色和白色游戏与游戏机之间的关系相对独立，只要它们都遵循已建立的协议，它们就可以独立开发和更改. 如果游戏卡带坏了，则其他游戏也可以在机器上运行；如果您的游戏机坏了，即使将录像带拿到朋友家的游戏机上，您也可以播放. 红白机的发展较晚，即使游戏机的手柄也可插拔，如果手柄坏了，只需要更换手柄即可.

在这一点上，每个人都应该对聚合和耦合有一个初步的了解. 那么，我们如何看待聚合和耦合在实践中的应用？我们的程序如何实现高聚集和低耦合？

如前所述，从不同的层次来看，聚集和耦合的程度将有所不同. 在Sidtown和Fredborough的示例中，从城市水平的角度来看，第二个设计已完全实现了高凝聚力和低耦合的目标. 但是，如果从城市的不同区域看，这种设计凝聚力是不够的. 如果我们继续坚持下去，恐怕Better Mousetrap的所有员工都会生活在生产线上. 盲目追求高凝聚力将不可避免地导致模块的功能过于单一，并且模块的数量将迅速增加. 因此，在设计和实现程序时，必须考虑模块之间的聚合和耦合程度. 有兴趣的朋友还可以研究聚集和耦合指标.

面向对象设计的基石是“开闭”原则. “打开和关闭”原则表示，软件实体应该对扩展开放，而对修改不开放. 该规则表明，在设计模块时，应对其进行扩展而不进行修改. 从另一个角度来看，这就是所谓的“可变性封装原理”.

“可变性的封装原理”意味着两件事:

一种可变性不应分散在代码的许多角落，而应封装在一个对象中. 相同变异性的不同表示形式表示相同继承层次结构中的特定子类. 一个可变性不应与另一个混合. 也就是说，类图的继承结构通常不应超过两层.

要实现“开闭”原则并非易事，但要遵循许多规则，这些定律也是设计原则，它们是实现开闭原则的工具.

如果软件实体使用基类，那么它也必须适用于子类. 但是反向替换尚未建立.

如果两个特定的类A和B之间的关系违反了Liskov替换原理，则可以选择以下两种重建方案之一:

创建一个新的抽象类C，作为两个具体类的超类，将A和B的共同行为移到C，从而解决A和B行为不一致的问题. 重写了从B到A的继承关系作为委派关系. 乍一看，为什么这仍然是面向对象设计的原理？这显然是Java的语法规则. 是的，Java为Liskov替代原则提供了语法支持. 但仅从语法上讲，并未提供与现实世界相符的程度. 经常有不符合《里斯科夫换人原则》的情况.

依赖逆转的原理是: 依靠抽象而不是具体. 那是用于接口编程，而不是用于实现编程. 接口编程意味着您应该将接口和抽象类用于变量类型声明，参数类型声明，方法返回类型声明和数据类型转换. 不要以实现编程为目标，这意味着您不应将特定类用于变量类型声明，参数类型声明，方法返回类型声明和数据类型转换.

依赖反转原理很强大，但是实现起来并不容易. 由于依赖关系反转，对象创建很可能会使用对象工厂来避免直接引用特定类. 使用该原理也将导致大量的类. 维护这样的系统需要良好的面向对象设计知识.

此外，依赖倒置原则假定所有具体类均已更改，但并不总是正确的. 一些特定的类可能很稳定，不会改变. 使用此特定类实例的客户端可以完全依赖此特定类.

接口隔离的原理是使用多个专用接口比使用单个接口更好. 从客户端的角度来看: 一类对另一类的依赖应该基于最小的接口. 如果客户端仅需要某些方法，则应将这些方法提供给客户端，而不是提供不必要的方法. 提供接口意味着对客户作出承诺. 过多的承诺会给系统的维护带来不必要的负担.

合成，聚合和重用的原理是在新对象中使用一些现有对象，使其成为新对象的一部分. 新对象通过委派给这些对象来达到重用现有功能的目的. . 这个原理有简短的描述: 尝试使用综合和聚合，并尝试不使用继承.

组成和聚合具有以下好处: 新对象访问组件对象的唯一方法是通过组件对象的接口. 这种重用是黑盒重用oop的概念，因为新对象看不到组件对象的内部详细信息. 这种重用可以在运行时动态执行，新对象可以动态引用与组件对象相同类型的对象. 合成和聚合可以应用于任何环境，而继承只能应用于某些有限的环境. 错误使用合成，聚合和继承的常见原因是错误地将“ Has-a”关系用作“ Is-a”关系. 如果两个类是“ Has-a”关系，则应使用综合和聚合. 如果它们是“ Is-a”关系，则可以使用继承.

迪米特定律说，一个物体应该对其他物体的了解尽可能少. 也就是说，仅与您的直接朋友交流，而不与陌生人交谈. 如果您需要与一个陌生人交谈，并且您的朋友和陌生人是朋友，则可以由您的朋友将呼叫转发给陌生人，这样某人仅会认识该朋友，而不是陌生人. 换句话说，某人会认为他正在调用朋友的方法.

以下条件称为朋友条件:

当前对象本身。以参量的形式传入到当前对象方法中的对象。当前对象的实例变量直接引用的对象。
当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友。任何一个对象，
如果满足上面的条件之一，就是当前对象的朋友，否则就是陌生人。

Dimit规则的主要目的是控制信息过载. 将其应用于系统设计时，应注意以下几点: 在类的划分中，应创建具有弱耦合的类. 类之间的耦合越弱，则越有利于重用. 在类结构设计中，每个类都应尝试减少成员的访问权限. 一个类不应公开其自身的属性，而应提供一种价值和分配方法，以允许外界间接访问其自身的属性. 在类设计中，应尽可能将一个类设计为不变类. 在引用其他对象时，应尽量减少对其他对象的引用.

看看什么是面向对象（OOP）

推荐的面向对象的向日葵集合

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-239444-2.html