| 缩写 | 英文名称 | 中文名称 |
|---|---|---|
| SRP | Single Responsibility Principle | 单一职责原则 |
| OCP | Open Close Principle | 开闭原则 |
| LSP | Liskov Substitution Principle | 里氏替换原则 |
| LOD | Law of Demeter （ Least Knowledge Principle） | 迪米特法则（最少知道原则） |
| ISP | Interface Segregation Principle | 接口分离原则 |
| DIP | Dependency Inversion Principle | 依赖倒置原则 |
上面就是通常说的SOLID上方表格缩写的首字母，从上到下）：面向对象设计的六大设计原则
-
1、单一职责：一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。不过在现实开发中，这个原则是最不可能遵守的，因为每个人对一个类的哪些功能算是同一类型的职责判断都不相同。
-
2、开放封闭原则：软件实体应该是可扩展，而不可修改的。也就是说，你写完一个类，要想添加功能，不能修改原有类，而是想办法扩展该类。有多种设计模式可以达到这一要求。
-
3、里氏替换原则：当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系。也就是说接口或父类出现的地方，实现接口的类或子类可以代入，这主要依赖于多态和继承。
-
4、迪米特法则（最少知道原则）：一个对象应该对尽可能少的对象有接触，也就是只接触那些真正需要接触的对象
-
5、接口分离原则：不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。 不要提供一个大的接口包括所有功能，应该根据功能把这些接口分割，减少依赖
-
6、依赖倒置原则：高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象
软件实体应该是可扩展，而不可修改的。也就是说，你写完一个类，要想添加功能，不能修改原有类，而是想办法扩展该类。有多种设计模式可以达到这一要求。
定义的解读
- 用抽象构建框架，用实现扩展细节。
- 不以改动原有类的方式来实现新需求，而是应该以实现事先抽象出来的接口（或具体类继承抽象类）的方式来实现
代码讲解
下面通过一个简单的关于在线课程的例子讲解一下开闭原则的实践。
需求点
设计一个在线课程类：
由于教学资源有限，开始的时候只有类似于博客的，通过文字讲解的课程。 但是随着教学资源的增多，后来增加了视频课程，音频课程以及直播课程。
先来看一下不好的设计：
不好的设计
最开始的文字课程类：
//================== Course.h ==================
@interface Course : NSObject
@property (nonatomic, copy) NSString *courseTitle; //课程名称
@property (nonatomic, copy) NSString *courseIntroduction; //课程介绍
@property (nonatomic, copy) NSString *teacherName; //讲师姓名
@property (nonatomic, copy) NSString *content; //课程内容
@end
Course类声明了最初的在线课程所需要包含的数据：
- 课程名称
- 课程介绍
- 讲师姓名
- 文字内容
接着按照上面所说的需求变更：增加了视频，音频，直播课程：
//================== Course.h ==================
@interface Course : NSObject
@property (nonatomic, copy) NSString *courseTitle; //课程名称
@property (nonatomic, copy) NSString *courseIntroduction; //课程介绍
@property (nonatomic, copy) NSString *teacherName; //讲师姓名
@property (nonatomic, copy) NSString *content; //文字内容
//新需求：视频课程
@property (nonatomic, copy) NSString *videoUrl;
//新需求：音频课程
@property (nonatomic, copy) NSString *audioUrl;
//新需求：直播课程
@property (nonatomic, copy) NSString *liveUrl;
@end
三种新增的课程都在原Course类中添加了对应的url。也就是每次添加一个新的类型的课程，都在原有Course类里面修改：新增这种课程需要的数据。
这就导致：我们从Course类实例化的视频课程对象会包含并不属于自己的数据：audioUrl和liveUrl：这样就造成了冗余，视频课程对象并不是纯粹的视频课程对象，它包含了音频地址，直播地址等成员
很显然，这个设计不是一个好的设计，因为（对应上面两段叙述）：
随着需求的增加，需要反复修改之前创建的类。 给新增的类造成了不必要的冗余。
之所以会造成上述两个缺陷，是因为该设计没有遵循对修改关闭，对扩展开放的开闭原则，而是反其道而行之：开放修改，而且不给扩展提供便利。 难么怎么做可以遵循开闭原则呢？下面看一下遵循开闭原则的较好的设计
较好的设计
首先在Course类中仅仅保留所有课程都含有的数据：
//================== Course.h ==================
@interface Course : NSObject
@property (nonatomic, copy) NSString *courseTitle; //课程名称
@property (nonatomic, copy) NSString *courseIntroduction; //课程介绍
@property (nonatomic, copy) NSString *teacherName; //讲师姓名
接着，针对文字课程，视频课程，音频课程，直播课程这三种新型的课程采用继承Course类的方式。而且继承后，添加自己独有的数据：
文字课程类：
//================== TextCourse.h ==================
@interface TextCourse : Course
@property (nonatomic, copy) NSString *content; //文字内容
@end
视频课程类：
//================== VideoCourse.h ==================
@interface VideoCourse : Course
@property (nonatomic, copy) NSString *videoUrl; //视频地址
@end
音频课程类：
//================== AudioCourse.h ==================
@interface AudioCourse : Course
@property (nonatomic, copy) NSString *audioUrl; //音频地址
@end
直播课程类：
//================== LiveCourse.h ==================
@interface LiveCourse : Course
@property (nonatomic, copy) NSString *liveUrl; //直播地址
@end
这样一来，上面的两个问题都得到了解决：
随着课程类型的增加，不需要反复修改最初的父类（Course），只需要新建一个继承于它的子类并在子类中添加仅属于该子类的数据（或行为）即可。
因为各种课程独有的数据（或行为）都被分散到了不同的课程子类里，所以每个子类的数据（或行为）没有任何冗余。
而且对于第二点：或许今后的视频课程可以有高清地址，视频加速功能。而这些功能只需要在VideoCourse类里添加即可，因为它们都是视频课程所独有的。同样地，直播课程后面还可以支持在线问答功能，也可以仅加在LiveCourse里面。
一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。不过在现实开发中，这个原则是最不可能遵守的，因为每个人对一个类的哪些功能算是同一类型的职责判断都不相同。但是我们还是要尽可能的遵守这个原则。
定义的解读
-
类职责的变化往往就是导致类变化的原因：也就是说如果一个类具有多种职责，就会有多种导致这个类变化的原因，从而导致这个类的维护变得困难。
-
往往在软件开发中随着需求的不断增加，可能会给原来的类添加一些本来不属于它的一些职责，从而违反了单一职责原则。如果我们发现当前类的职责不仅仅有一个，就应该将本来不属于该类真正的职责分离出去。
-
不仅仅是类，函数（方法）也要遵循单一职责原则，即：一个函数（方法）只做一件事情。如果发现一个函数（方法）里面有不同的任务，则需要将不同的任务以另一个函数（方法）的形式分离出去
代码讲解
单一职责原则的demo比较简单，通过对象（属性）的设计上讲解已经足够，不需要具体的客户端调用。我们先看一下需求点：
需求点
初始需求：需要创造一个员工类，这个类有员工的一些基本信息。
新需求：增加两个方法：
判定员工在今年是否升职 计算员工的薪水 先来看一下不好的设计：
不好的设计
//================== Employee.h ==================
@interface Employee : NSObject
//============ 初始需求 ============
@property (nonatomic, copy) NSString *name; //员工姓名
@property (nonatomic, copy) NSString *address; //员工住址
@property (nonatomic, copy) NSString *employeeID; //员工ID
//============ 新需求 ============
//计算薪水
- (double)calculateSalary;
//今年是否晋升
- (BOOL)willGetPromotionThisYear;
@end
由上面的代码可以看出：
- 在初始需求下，我们创建了
Employee这个员工类，并声明了3个员工信息的属性：员工姓名，地址，员工ID。 - 在新需求下，两个方法直接加到了员工类里面。
新需求的做法看似没有问题，因为都是和员工有关的，但却违反了单一职责原则：因为这两个方法并不是员工本身的职责。
calculateSalary这个方法的职责是属于会计部门的：薪水的计算是会计部门负责。
willPromotionThisYear这个方法的职责是属于人事部门的：考核与晋升机制是人事部门负责。
而上面的设计将本来不属于员工自己的职责强加进了员工类里面，而这个类的设计初衷（原始职责）就是单纯地保留员工的一些信息而已。因此这么做就是给这个类引入了新的职责，故此设计违反了单一职责原则。
我们可以简单想象一下这么做的后果是什么：如果员工的晋升机制变了，或者税收政策等影响员工工资的因素变了，我们还需要修改当前这个类。
那么怎么做才能不违反单一职责原则呢？- 我们需要将这两个方法（责任）分离出去，让本应该处理这类任务的类来处理。
较好的设计
我们保留员工类的基本信息：
//================== Employee.h ==================
@interface Employee : NSObject
//初始需求
@property (nonatomic, copy) NSString *name;
@property (nonatomic, copy) NSString *address;
@property (nonatomic, copy) NSString *employeeID;
接着创建新的会计部门类：
//================== FinancialApartment.h ==================
#import "Employee.h"
//会计部门类
@interface FinancialApartment : NSObject
//计算薪水
- (double)calculateSalary:(Employee *)employee;
@end
和人事部门类：
//================== HRApartment.h ==================
#import "Employee.h"
//人事部门类
@interface HRApartment : NSObject
//今年是否晋升
- (BOOL)willGetPromotionThisYear:(Employee*)employee;
@end
通过创建了两个分别专门处理薪水和晋升的部门，会计部门和人事部门的类：FinancialApartment 和 HRApartment，把两个任务（责任）分离了出去，让本该处理这些职责的类来处理这些职责。
这样一来，不仅仅在此次新需求中满足了单一职责原则，以后如果还要增加人事部门和会计部门处理的任务，就可以直接在这两个类里面添加即可
高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象
即：
- 依赖抽象，而不是依赖实现。
- 抽象不应该依赖细节；细节应该依赖抽象。
- 高层模块不能依赖低层模块，二者都应该依赖抽象。
定义解读
- 针对接口编程，而不是针对实现编程。
- 尽量不要从具体的类派生，而是以继承抽象类或实现接口来实现。
- 关于高层模块与低层模块的划分可以按照决策能力的高低进行划分。业务层自然就处于上层模块，逻辑层和数据层自然就归类为底层。
需求点
实现下面这样的需求：
用代码模拟一个实际项目开发的场景：前端和后端开发人员开发同一个项目
不好的设计
首先生成两个类，分别对应前端和后端开发者：
前端开发者：
//================== FrondEndDeveloper.h ==================
@interface FrondEndDeveloper : NSObject
- (void)writeJavaScriptCode;
@end
//================== FrondEndDeveloper.m ==================
@implementation FrondEndDeveloper
- (void)writeJavaScriptCode{
NSLog(@"Write JavaScript code");
}
@end
后端开发者：
//================== BackEndDeveloper.h ==================
@interface BackEndDeveloper : NSObject
- (void)writeJavaCode;
@end
//================== BackEndDeveloper.m ==================
@implementation BackEndDeveloper
- (void)writeJavaCode{
NSLog(@"Write Java code");
}
@end
这两个开发者分别对外提供了自己开发的方法：writeJavaScriptCode和writeJavaCode
接着创建一个Project类：
//================== Project.h ==================
@interface Project : NSObject
//构造方法，传入开发者的数组
- (instancetype)initWithDevelopers:(NSArray *)developers;
//开始开发
- (void)startDeveloping;
@end
//================== Project.m ==================
#import "Project.h"
#import "FrondEndDeveloper.h"
#import "BackEndDeveloper.h"
@implementation Project
{
NSArray *_developers;
}
- (instancetype)initWithDevelopers:(NSArray *)developers{
if (self = [super init]) {
_developers = developers;
}
return self;
}
- (void)startDeveloping{
[_developers enumerateObjectsUsingBlock:^(id _Nonnull developer, NSUInteger idx, BOOL * _Nonnull stop) {
if ([developer isKindOfClass:[FrondEndDeveloper class]]) {
[developer writeJavaScriptCode];
}else if ([developer isKindOfClass:[BackEndDeveloper class]]){
[developer writeJavaCode];
}else{
//no such developer
}
}];
}
@end
在Project类中，我们首先通过一个构造器方法，将开发者的数组传入project的实例对象。然后在开始开发的方法startDeveloping里面，遍历数组并判断元素类型的方式让不同类型的开发者调用和自己对应的函数。
思考一下，这样的设计有什么问题？
问题一：
假如后台的开发语言改成了GO语言，那么上述代码需要改动两个地方：
BackEndDeveloper:需要向外提供一个writeGolangCode方法。Project类的startDeveloping方法里面需要将BackEndDeveloper类的writeJavaCode改成writeGolangCode。
问题二：
假如后期老板要求做移动端的APP（需要iOS和安卓的开发者），那么上述代码仍然需要改动两个地方：
- 还需要给
Project类的构造器方法里面传入IOSDeveloper和AndroidDeveloper两个类。而且按照现有的设计，还要分别向外部提供writeSwiftCode和writeKotlinCode。 Project类的startDeveloping方法里面需要再多两个elseif判断，专门判断IOSDeveloper和AndroidDeveloper这两个类。
很显然，在这两种假设的场景下，高层模块（Project）都依赖了低层模块（BackEndDeveloper）的改动，因此上述设计不符合依赖倒置原则。
那么该如何设计才可以符合依赖倒置原则呢？
答案是：将开发者写代码的方法抽象出来，让Project类不再依赖所有低层的开发者类的具体实现，而是依赖抽象。而且从下至上，所有底层的开发者类也都依赖这个抽象，通过实现这个抽象来做自己的任务。
这个抽象可以用接口，也可以用抽象类的方式来做，在这里笔者用使用接口的方式进行讲解：
较好的设计
首先，创建一个接口，接口里面有一个写代码的方法writeCode
//================== DeveloperProtocol.h ==================
@protocol DeveloperProtocol <NSObject>
- (void)writeCode;
@end
然后，让前端程序员和后端程序员类实现这个接口（遵循这个协议）并按照自己的方式实现：
前端程序员类：
//================== FrondEndDeveloper.h ==================
@interface FrondEndDeveloper : NSObject<DeveloperProtocol>
@end
//================== FrondEndDeveloper.m ==================
@implementation FrondEndDeveloper
- (void)writeCode{
NSLog(@"Write JavaScript code");
}
@end
后端程序员类：
//================== BackEndDeveloper.h ==================
@interface BackEndDeveloper : NSObject<DeveloperProtocol>
@end
//================== BackEndDeveloper.m ==================
@implementation BackEndDeveloper
- (void)writeCode{
NSLog(@"Write Java code");
}
@end
最后我们看一下新设计后的Project类：
//================== Project.h ==================
#import "DeveloperProtocol.h"
@interface Project : NSObject
//只需传入遵循DeveloperProtocol的对象数组即可
- (instancetype)initWithDevelopers:(NSArray <id <DeveloperProtocol>>*)developers;
//开始开发
- (void)startDeveloping;
@end
//================== Project.m ==================
#import "FrondEndDeveloper.h"
#import "BackEndDeveloper.h"
@implementation Project
{
NSArray <id <DeveloperProtocol>>* _developers;
}
- (instancetype)initWithDevelopers:(NSArray <id <DeveloperProtocol>>*)developers{
if (self = [super init]) {
_developers = developers;
}
return self;
}
- (void)startDeveloping{
//每次循环，直接向对象发送writeCode方法即可，不需要判断
[_developers enumerateObjectsUsingBlock:^(id<DeveloperProtocol> _Nonnull developer, NSUInteger idx, BOOL * _Nonnull stop) {
[developer writeCode];
}];
}
@end
新的Project的构造方法只需传入遵循DeveloperProtocol协议的对象构成的数组即可。这样也比较符合现实中的需求：只需要会写代码就可以加入到项目中。
而新的startDeveloping方法里：每次循环，直接向当前对象发送writeCode方法即可，不需要对程序员的类型做判断。因为这个对象一定是遵循DeveloperProtocol接口的，而遵循该接口的对象一定会实现writeCode方法（就算不实现也不会引起重大错误）。
现在新的设计接受完了，我们通过上面假设的两个情况来和之前的设计做个对比
假设1：后台的开发语言改成了GO语言
在这种情况下，只需更改BackEndDeveloper类里面对于DeveloperProtocol接口的writeCode方法的实现即可：
//================== BackEndDeveloper.m ==================
@implementation BackEndDeveloper
- (void)writeCode{
//Old：
//NSLog(@"Write Java code");
//New:
NSLog(@"Write Golang code");
}
@end
而在Project里面不需要修改任何代码，因为Project类只依赖了接口方法WriteCode，没有依赖其具体的实现。
假设2：后期老板要求做移动端的APP（需要iOS和安卓的开发者）
在这个新场景下，我们只需要将新创建的两个开发者类：IOSDeveloper和AndroidDeveloper分别实现DeveloperProtocol接口的writeCode方法即可。
同样，Project的接口和实现代码都不用修改：客户端只需要在Project的构建方法的数组参数里面添加这两个新类的实例即可，不需要在startDeveloping方法里面添加类型判断，原因同上。
我们可以看到，新设计很好地在高层类（Project）与低层类（各种developer类）中间加了一层抽象，解除了二者在旧设计中的耦合，使得在低层类中的改动没有影响到高层类。
同样是抽象，新设计同样也可以用抽象类的方式：创建一个Developer的抽象类并提供一个writeCode方法，让不同的开发者类继承与它并按照自己的方式实现writeCode方法。这样一来，在Project类的构造方法就是传入已Developer类型为元素的数组了。有兴趣的小伙伴可以自己实现一下~
不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。 不要提供一个大的接口包括所有功能，应该根据功能把这些接口分割，减少依赖
定义解读
- 客户端不应该依赖它不需要实现的接口。
- 不建立庞大臃肿的接口，应尽量细化接口，接口中的方法应该尽量少。
需要注意的是：接口的粒度也不能太小。如果过小，则会造成接口数量过多，使设计复杂化。
需求点
现在的餐厅除了提供传统的店内服务，多数也都支持网上下单，网上支付功能。写一些接口方法来涵盖餐厅的所有的下单及支付功能。
不好的设计
//================== RestaurantProtocol.h ==================
@protocol RestaurantProtocol <NSObject>
- (void)placeOnlineOrder; //下订单：online
- (void)placeTelephoneOrder; //下订单：通过电话
- (void)placeWalkInCustomerOrder; //下订单：在店里
- (void)payOnline; //支付订单：online
- (void)payInPerson; //支付订单：在店里支付
@end
在这里声明了一个接口，它包含了下单和支付的几种方式：
下单：
- online下单
- 电话下单
- 店里下单（店内服务）
支付
- online支付（适用于online下单和电话下单的顾客）
- 店里支付（店内服务）
对应的，我们有三种下单方式的顾客：
1.online下单，online支付的顾客
//================== OnlineClient.h ==================
#import "RestaurantProtocol.h"
@interface OnlineClient : NSObject<RestaurantProtocol>
@end
//================== OnlineClient.m ==================
@implementation OnlineClient
- (void)placeOnlineOrder{
NSLog(@"place on line order");
}
- (void)placeTelephoneOrder{
//not necessarily
}
- (void)placeWalkInCustomerOrder{
//not necessarily
}
- (void)payOnline{
NSLog(@"pay on line");
}
- (void)payInPerson{
//not necessarily
}
@end
2.电话下单，online支付的顾客
//================== TelephoneClient.h ==================
#import "RestaurantProtocol.h"
@interface TelephoneClient : NSObject<RestaurantProtocol>
@end
//================== TelephoneClient.m ==================
@implementation TelephoneClient
- (void)placeOnlineOrder{
//not necessarily
}
- (void)placeTelephoneOrder{
NSLog(@"place telephone order");
}
- (void)placeWalkInCustomerOrder{
//not necessarily
}
- (void)payOnline{
NSLog(@"pay on line");
}
- (void)payInPerson{
//not necessarily
}
@end
3.在店里下单并支付的顾客：
//================== WalkinClient.h ==================
#import "RestaurantProtocol.h"
@interface WalkinClient : NSObject<RestaurantProtocol>
@end
//================== WalkinClient.m ==================
@implementation WalkinClient
- (void)placeOnlineOrder{
//not necessarily
}
- (void)placeTelephoneOrder{
//not necessarily
}
- (void)placeWalkInCustomerOrder{
NSLog(@"place walk in customer order");
}
- (void)payOnline{
//not necessarily
}
- (void)payInPerson{
NSLog(@"pay in person");
}
@end
我们发现，并不是所有顾客都必须要实现RestaurantProtocol里面的所有方法。由于接口方法的设计造成了冗余，因此该设计不符合接口隔离原则。
注意，Objective-C中的协议可以通过@optional关键字设置不需要必须实现的方法，该特性不与接口分离原则冲突：只要属于同一类责任的接口，都可以放入同一接口中。
较好的设计
要符合接口隔离原则，只需要将不同类型的接口分离出来即可。我们将原来的RestaurantProtocol接口拆分成两个接口：下单接口和支付接口。
下单接口：
//================== RestaurantPlaceOrderProtocol.h ==================
@protocol RestaurantPlaceOrderProtocol <NSObject>
- (void)placeOrder;
@end
支付接口：
//================== RestaurantPaymentProtocol.h ==================
@protocol RestaurantPaymentProtocol <NSObject>
- (void)payOrder;
@end
现在有了下单接口和支付接口，我们就可以让不同的客户来以自己的方式实现下单和支付操作了：
首先创建一个所有客户的父类，来遵循这个两个接口：
//================== Client.h ==================
#import "RestaurantPlaceOrderProtocol.h"
#import "RestaurantPaymentProtocol.h"
@interface Client : NSObject<RestaurantPlaceOrderProtocol,RestaurantPaymentProtocol>
@end
接着另online下单，电话下单，店内下单的顾客继承这个父类，分别实现这两个接口的方法：
1.online下单，online支付的顾客
//================== OnlineClient.h ==================
#import "Client.h"
@interface OnlineClient : Client
@end
//================== OnlineClient.m ==================
@implementation OnlineClient
- (void)placeOrder{
NSLog(@"place on line order");
}
- (void)payOrder{
NSLog(@"pay on line");
}
@end
2.电话下单，online支付的顾客
//================== TelephoneClient.h ==================
#import "Client.h"
@interface TelephoneClient : Client
@end
//================== TelephoneClient.m ==================
@implementation TelephoneClient
- (void)placeOrder{
NSLog(@"place telephone order");
}
- (void)payOrder{
NSLog(@"pay on line");
}
@end
3.在店里下单并支付顾客：
//================== WalkinClient.h ==================
#import "Client.h"
@interface WalkinClient : Client
@end
//================== WalkinClient.m ==================
@implementation WalkinClient
- (void)placeOrder{
NSLog(@"place walk in customer order");
}
- (void)payOrder{
NSLog(@"pay in person");
}
@end
因为我们把不同职责的接口拆开，使得接口的责任更加清晰，简洁明了。不同的客户端可以根据自己的需求遵循所需要的接口来以自己的方式实现。
而且今后如果还有和下单或者支付相关的方法，也可以分别加入到各自的接口中，避免了接口的臃肿，同时也提高了程序的内聚性。
在设计接口时，尤其是在向现有的接口添加方法时，我们需要仔细斟酌这些方法是否是处理同一类任务的：如果是则可以放在一起；如果不是则需要做拆分。
做iOS开发的朋友对UITableView的UITableViewDelegate和UITableViewDataSource这两个协议应该会非常熟悉。这两个协议里的方法都是与UITableView相关的，但iOS SDK的设计者却把这些方法放在不同的两个协议中。原因就是这两个协议所包含的方法所处理的任务是不同的两种：
UITableViewDelegate：含有的方法是UITableView的实例告知其代理一些点击事件的方法，即事件的传递，方向是从UITableView的实例到其代理。
UITableViewDataSource：含有的方法是UITableView的代理传给UITableView一些必要数据供UITableView展示出来，即数据的传递，方向是从UITableView的代理到UITableView。
很显然，UITableView协议的设计者很好地实践了接口分离的原则，值得我们大家学习
迪米特法则（最少知道原则）：一个对象应该对尽可能少的对象有接触，也就是只接触那些真正需要接触的对象
定义解读
迪米特法则也叫做最少知道原则（Least Know Principle）， 一个类应该只和它的成员变量，方法的输入，返回参数中的类作交流，而不应该引入其他的类（间接交流）。
需求点
设计一个汽车类，包含汽车的品牌名称，引擎等成员变量。提供一个方法返回引擎的品牌名称
不好的设计
Car类：
//================== Car.h ==================
@class GasEngine;
@interface Car : NSObject
//构造方法
- (instancetype)initWithEngine:(GasEngine *)engine;
//返回私有成员变量：引擎的实例
- (GasEngine *)usingEngine;
@end
//================== Car.m ==================
#import "Car.h"
#import "GasEngine.h"
@implementation Car
{
GasEngine *_engine;
}
- (instancetype)initWithEngine:(GasEngine *)engine{
self = [super init];
if (self) {
_engine = engine;
}
return self;
}
- (GasEngine *)usingEngine{
return _engine;
}
@end
从上面可以看出，Car的构造方法需要传入一个引擎的实例对象。而且因为引擎的实例对象被赋到了Car对象的私有成员变量里面。所以Car类给外部提供了一个返回引擎对象的方法：usingEngine。
而这个引擎类GasEngine有一个品牌名称的成员变量brandName：
//================== GasEngine.h ==================
@interface GasEngine : NSObject
@property (nonatomic, copy) NSString *brandName;
@end
这样一来，客户端就可以拿到引擎的品牌名称了：
//================== Client.m ==================
#import "GasEngine.h"
#import "Car.h"
- (NSString *)findCarEngineBrandName:(Car *)car{
GasEngine *engine = [car usingEngine];
NSString *engineBrandName = engine.brandName;//获取到了引擎的品牌名称
return engineBrandName;
}
上面的设计完成了需求，但是却违反了迪米特法则。原因是在客户端的findCarEngineBrandName:中引入了和入参（Car）和返回值（NSString）无关的GasEngine对象。增加了客户端与 GasEngine的耦合。而这个耦合显然是不必要更是可以避免的
较好的设计
同样是Car这个类，我们去掉原有的返回引擎对象的方法，而是增加一个直接返回引擎品牌名称的方法
//================== Car.h ==================
@class GasEngine;
@interface Car : NSObject
//构造方法
- (instancetype)initWithEngine:(GasEngine *)engine;
//直接返回引擎品牌名称
- (NSString *)usingEngineBrandName;
@end
//================== Car.m ==================
#import "Car.h"
#import "GasEngine.h"
@implementation Car
{
GasEngine *_engine;
}
- (instancetype)initWithEngine:(GasEngine *)engine{
self = [super init];
if (self) {
_engine = engine;
}
return self;
}
- (NSString *)usingEngineBrandName{
return _engine.brand;
}
@end
因为直接usingEngineBrandName直接返回了引擎的品牌名称，所以在客户端里面就可以直接拿到这个值，而不需要间接地通过原来的GasEngine实例来获取。
我们看一下客户端操作的变化：
//================== Client.m ==================
#import "Car.h"
- (NSString *)findCarEngineBrandName:(Car *)car{
NSString *engineBrandName = [car usingEngineBrandName]; //直接获取到了引擎的品牌名称
return engineBrandName;
}
与之前的设计不同，在客户端里面，没有引入GasEngine类，而是直接通过Car实例获取到了需要的数据。
这样设计的好处是，如果这辆车的引擎换成了电动引擎(原来的GasEngine类换成了ElectricEngine类)，客户端代码可以不做任何修改！因为它没有引入任何引擎类，而是直接获取了引擎的品牌名称。
所以在这种情况下我们只需要修改Car类的usingEngineBrandName方法实现，将新引擎的品牌名称返回即可
所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类对象可以替换其父类对象，而程序执行效果不变
定义的解读
在继承体系中，子类中可以增加自己特有的方法，也可以实现父类的抽象方法，但是不能重写父类的非抽象方法，否则该继承关系就不是一个正确的继承关系。
需求点
创建两个类：长方形和正方形，都可以设置宽高（边长），也可以输出面积大小。
不好的设计
首先声明一个长方形类，然后让正方形类继承于长方形。
长方形类：
//================== Rectangle.h ==================
@interface Rectangle : NSObject
{
@protected double _width;
@protected double _height;
}
//设置宽高
- (void)setWidth:(double)width;
- (void)setHeight:(double)height;
//获取宽高
- (double)width;
- (double)height;
//获取面积
- (double)getArea;
@end
//================== Rectangle.m ==================
@implementation Rectangle
- (void)setWidth:(double)width{
_width = width;
}
- (void)setHeight:(double)height{
_height = height;
}
- (double)width{
return _width;
}
- (double)height{
return _height;
}
- (double)getArea{
return _width * _height;
}
@end
正方形类：
//================== Square.h ==================
@interface Square : Rectangle
@end
//================== Square.m ==================
@implementation Square
- (void)setWidth:(double)width{
_width = width;
_height = width;
}
- (void)setHeight:(double)height{
_width = height;
_height = height;
}
@end
可以看到，正方形类继承了长方形类以后，为了保证边长永远是相等的，特意在两个set方法里面强制将宽和高都设置为传入的值，也就是重写了父类Rectangle的两个set方法。但是里氏替换原则里规定，子类不能重写父类的方法，所以上面的设计是违反该原则的。 而且里氏替换原则原则里面所属：子类对象能够替换父类对象，而程序执行效果不变。我们通过一个例子来看一下上面的设计是否符合：
在客户端类写一个方法：传入一个Rectangle类型并返回它的面积：
- (double)calculateAreaOfRect:(Rectangle *)rect{
return rect.getArea;
}
我们先用Rectangle对象试一下：
Rectangle *rect = [[Rectangle alloc] init];
rect.width = 10;
rect.height = 20;
double rectArea = [self calculateAreaOfRect:rect];//output:200
长宽分别设置为10，20以后，结果输出200，没有问题。
现在我们使用Rectange的子类Square的对象替换原来的Rectange对象，看一下结果如何
Square *square = [[Square alloc] init];
square.width = 10;
square.height = 20;
double squareArea = [self calculateAreaOfRect:square];//output:400
结果输出为400，结果不一致，再次说明了上述设计不符合里氏替换原则，因为子类的对象square替换父类的对象rect以后，程序执行的结果变了。
不符合里氏替换原则就说明该继承关系不是正确的继承关系，也就是说正方形类不能继承于长方形类，程序需要重新设计。
较好的设计
既然正方形不能继承于长方形，那么是否可以让二者都继承于其他的父类呢？答案是可以的。
既然要继承于其他的父类，它们这个父类肯定具备这两种形状共同的特点：有4个边。那么我们就定义一个四边形的类：Quadrangle。
//================== Quadrangle.h ==================
@interface Quadrangle : NSObject
{
@protected double _width;
@protected double _height;
}
- (void)setWidth:(double)width;
- (void)setHeight:(double)height;
- (double)width;
- (double)height;
- (double)getArea;
@end
接着，让Rectangle类和Square类继承于它：
Rectangle类：
//================== Rectangle.h ==================
#import "Quadrangle.h"
@interface Rectangle : Quadrangle
@end
//================== Rectangle.m ==================
@implementation Rectangle
- (void)setWidth:(double)width{
_width = width;
}
- (void)setHeight:(double)height{
_height = height;
}
- (double)width{
return _width;
}
- (double)height{
return _height;
}
- (double)getArea{
return _width * _height;
}
@end
Square类：
//================== Square.h ==================
@interface Square : Quadrangle
{
@protected double _sideLength;
}
-(void)setSideLength:(double)sideLength;
-(double)sideLength;
@end
//================== Square.m ==================
@implementation Square
-(void)setSideLength:(double)sideLength{
_sideLength = sideLength;
}
-(double)sideLength{
return _sideLength;
}
- (void)setWidth:(double)width{
_sideLength = width;
}
- (void)setHeight:(double)height{
_sideLength = height;
}
- (double)width{
return _sideLength;
}
- (double)height{
return _sideLength;
}
- (double)getArea{
return _sideLength * _sideLength;
}
@end
我们可以看到，Rectange和Square类都以自己的方式实现了父类Quadrangle的公共方法。而且由于Square的特殊性，它也声明了自己独有的成员变量_sideLength以及其对应的公共方法