面向对象之类的设计_代码大全笔记（二）

类的基础是抽象数据类型。抽象数据类型（ADT）是数据和对这些数据操作的集合。此“数据”为泛指，可以是窗体，文件，链表，汽车，飞机，人等。

类还支持继承和多态，因此可以认为，抽象数据类型 + 继承 + 多态 = 类

任何东西首先展示给人的都是外表，类需要一个良好的接口。（这里的接口主要是指类提供的public函数的集合）

1.合理的抽象

类的接口为隐藏具体实现而提供一种抽象，此接口应该提供一组明显相关的操作。--情非得已别让狗拿耗子

1.一致的抽象层

类设计时，把类看成是实现ADT的机制，每个类只实现一个ADT，若某个类实现了多个ADT，则应把这个类重新组织为多个明确的ADT。

如某个类中一半的子程序使用一部分数据，另一半的子程序使用另一部分的数据，此时可能已经把两个类混在一起了，可以考虑分开。

2.理解类所实现的抽象

一些类非常相似，需要仔细理解类的接口，以确定所需要的抽象是哪个。

3.相反操作

开-关；添加-删除；激活-禁用等，设计类时，不要盲目创建相反操作，要认真考虑，是否需要。-做事情不要太顺手

4.抽象性和内聚性

好的抽象通常也有很高的内聚性，如果发现某个类的内聚性很弱，不知道如何修改，可以尝试看看这个类是否表现了一致的抽象。

2.良好的封装

抽象是忽略实现细节来管理复杂度，而封装是阻止看到细节。--非礼勿视

1.尽可能限制成员的可访问性

如果暴露一个子程序不会破坏抽象的一致性，则这么做是可行的，否则隐藏之会更好。

2.不要公开（public）数据成员

公开数据会破坏封装性，限制对抽象的控制能力。

3.避免把私有的实现细节放入类的接口中

（可参考一中的隐藏抽象的实现细节一节的内容）把private段的内容放到类的头文件中还是暴露了部分的实现细节，可以把类的接口和类的实现隔离开来，在类的接口文件中声明一个指向类实现的指针。

4.避免使用友元

一般情况下友元会破坏封装性，有些场合如设计模式中，使用友元是为了管理复杂度。

5.让阅读代码比编写代码更方便

这个说起来容易做起来也容易，难的是一般程序员不屑于做。-这说到心坎上了

6.留意过于紧密的耦合关系（两个类之间关联）

以下是一些指导建议

尽可能限制类和成员的可访问性

避免友元类

将基类数据声明为private而不是protected，以降低派生类和基类的耦合

避免在类中暴露数据成员

3.类的设计和内部实现

包含（有一个的关系）才是面向对象编程的主力技术。-聚合优先于继承

1.万不得已时通过private继承来实现“有一个”的关系

某些情况下根本无法包含一个对象时，可以通过private继承来实现。-private继承实际是实现继承，相当于将基类的public和protected成员以private声明于子类

2.警惕有太多数据成员的类

研究表明，人们能记住的离散项目的个数是7±2。如果一个类有超过7个数据成员，可以考虑是否有必要分解为更小的类。如果数据成员是整形型者字符串这类简单数据类型，可以按7±2上限考虑，若是复杂对象，则按7±2下限考虑。-这个是否有点绝对化了，看到好多类都是超过这个数的，应该要视情况而言吧
 
当决定使用继承（是一个的关系）时，考虑如下

对于每个成员函数，应该对派生类可见吗？应该有默认的实现吗？此默认实现可以被覆盖（override）吗？

对于每个数据成员，应该对派生类可见吗？

1.public继承实现“是一个......”的关系

如果派生类不准备完全遵守基类定义的同一个接口契约，就不应该用继承。
考虑子类是否需要进行向上类型转换，如果不需要，那么继承就不是正确的实现技术。-这个很关键，不需要多态时应考虑聚合

2.遵循Liskov替换原则

3.派生类的成员函数不要与基类中不可覆盖的成员函数重名

如果一个函数在基类中是私有的，派生类就不要创建一个同名的成员函数。

4.公用的接口，数据放到继承树中尽可能高的位置

多高算高？当把子程序移到更高层次会破坏抽象性，就该停手。

5.派生类覆盖某个子程序，其中没做任何操作，这种情况需要注意

6.避免让继承体系过深

7.尽量使用多态，避免大量的类型检查

8.让所有数据都是private，而非protected

当决定使用多重继承之前，应该仔细考虑其他解决方案。

何时使用继承，何时使用包含

多个类共享数据而非行为，应该创建这些类可以包含的共用对象

多个类共享行为而非数据，应该从共同的基类继承，在基类定义共用子程序

多个类同时共享数据和行为，应该从基类继承，并在基类中定义共用的数据和行为

当需要用基类控制接口时，使用继承；当想自己控制接口时，使用包含。

成员函数和数据成员

让类中子程序尽可能少
禁止隐式地产生成员函数和运算符（类似将赋值运算符声明为private的方式）
减少类所调用的不同子程序的数量（扇入扇出概念）
对其他类的子程序的间接调用尽可能少

尽量减小类与类之前相互合作的范围

尽量让下面的数字最小

所实例化的对象种类
在被实例化对象上直接调用的不同子程序数量
调用由其他对象返回的对象的子程序数量

4.创建类的原因

为现实世界中的对象建模

为抽象对象建模（经典的shape不是真实存在的）

降低复杂度（信息隐藏，无需考虑他们了）

隔离复杂度（隔离复杂算法，大型数据等）

隐藏实现细节

限制变动的影响范围

隐藏全局数据

让参数传递更顺畅

建立中心控制点

代码更易于重用

为程序族做计划

把相关操作包装到一起

实现某种特定的重构

5.应该避免的类

避免创建万能类
消除无关紧要的类
避免动词命名的类