单一职责原则，开闭原则，依赖倒置原则（面向接口编程），里氏替换原则，接口隔离原则。
面相对象设计的概念大家也都知道，它的设计目标就是希望软件系统能做到以下几点：
- 可扩展：新特性能够很容易的添加到现有系统中，不会影响原本的东西
- 可修改：当修改某一部分的代码时，不会影响到其它不相关的部分
- 可替代：将系统中某部分的代码用其它有相同接口的类替换时，不会影响到现有系统
这几个可以用来检测我们的软件系统是不是设计得合理，而如何设计出易于维护和扩展的软件系统是有设计原则可以遵循指导的,Robert C. Martin提出了面相对象设计的五个基本原则（SOLID）:
- S－单一职责原则
- O－开放关闭原则
- L－里氏替换原则
- I－接口隔离原则
- D－依赖倒置原则
单一职责原则：Single Responsibility Principle
一个类有且仅有一个职责，只有一个引起它变化的原因。
简单来说一个类只做好一件事就行，不去管跟自己不相干的，狗拿耗子多管闲事，其核心就是解耦以及高内聚。这个原则看着很简单，我们在写代码的时候即便不知道这个原则也会往这个方向靠拢，写出功能相对单一的类，不过这个原则很容易违背，因为可能由于某种原因，原来功能单一的类需要被细化成颗粒更小的职责1跟职责2，所以在每次迭代过程中可能需要重新梳理重构之前编写的代码，将不同的职责封装到不同的类或者模块中。
举个栗子：
@interface DataTransfer : NSObject
-(void)upload:(NSData *)data; //上传数据
-(void)download(NSString*)url; //根据URL下载东西
@end
DataTransfer包含上传跟下载功能，仔细考虑可以发现这相当于实现了两个功能，一个负责上传的相关逻辑，另一个负责下载的逻辑，而这个两个功能相对对立，当有一个功能改变的时候，比如我们之前是使用AFNetworking，现在想换成其它第三方或者nsurlconnection来实现上传跟下载：
- 上传方式变更，导致DataTransfer变更
- 下载方式变更，导致 DataTransfer变更
这就违反了单一职责的原则，所以需要将不同的功能拆解成两个不同的类，来负责各自的职责，不过这个拆的粒度可能因人而已，有时候并不需要拆的过细，不要成了为设计而设计。
屏幕快照 2018-10-27 下午7.58.38.png
在我们项目中经常看到很多违反这条原则的代码，而且违反的比较明显，许多类都是丰富功能的超级集合，整个类变得臃肿难以理解，这时候就需要我们有意识地去重构了。
开放关闭原则：Open Closed Principle
开闭原则的定义是说一个软件实体如类，模块和函数应该对扩展开放，而对修改关闭，具体来说就是你应该通过扩展来实现变化，而不是通过修改原有的代码来实现变化，该原则是面相对象设计最基本的原则。
之前说过在项目中每当需求需改的时候经常需要对代码有很大的改动，很大程度上就是因为我们对这个原则理解的不够透彻。
开闭原则的关键在于抽象，我们需要抽象出那些不会变化或者基本不变的东西，这部分东西相对稳定，这也就是对修改关闭的地方（这并不意味着不可以再修改），而对于那些容易变化的部分我们也对其封装，但是这部分是可以动态修改的，这也就是对扩展开发的地方，比如设计模式中的策略模式和模板模式就是在实现这个原则（现在应该对模式有更感性的认识了吧～）。
举个例子：我们需要保存对象到数据库当中，其中有个类似save()的保存方法，这部分应该是不变的，接口相对稳定，而具体保存的实现却有可能不同，我们现在可能是保存在Sqlite数据库中，假如以后如果想保存到一个自己实现的数据库中时，我们只需要实现一个拥有同样接口的扩展类添加进去即可，这就是对扩展开放，不会对之前的代码造成任何影响，就可以实现保存到新数据库的功能，保证了系统的稳定性。
屏幕快照 2018-10-27 下午8.04.25.png
实现开闭原则的指导思想就是：
- 抽象出相对稳定的接口，这部分应该不改动或者很少改动
- 封装变化
不过在软件开发过程中，要一开始就完全按照开闭原则来可能比较困难，更多的情况是在不断的迭代重构过程中去改进，在可预见的变化范围内去做设计。
里氏替代原则：Liskov Substitution Principle
该原则的定义：所有引用基类的地方必须能透明地使用其子类的对象。简单来说，所有使用基类代码的地方，如果换成子类对象的时候还能够正常运行，则满足这个原则，否则就是继承关系有问题，应该废除两者的继承关系，这个原则可以用来判断我们的对象继承关系是否合理。
比如有一个鲸鱼的类，我们让鲸鱼继承于鱼类，然后鱼类有个呼吸的功能：
屏幕快照 2018-10-27 下午8.09.22.png
然后在水里的时候，鱼能够进行呼吸：
if(isInwater){
//在水中了，开始呼吸
fish.breath();
}
当我们把鲸鱼这个子对象替换原来的基类鱼对象，鲸鱼在水里开始呼吸，这时问题就出现了，鲸鱼是哺乳动物，在水里呼吸是没法呼吸的，一直在水里就GG思密达了，所以这违反了该原则，我们就可以判断鲸鱼继承于鱼类不合理，需要去重新设计。
通常在设计的时候，我们都会优先采用组合而不是继承，因为继承虽然减少了代码，提高了代码的重用性，但是父类跟子类会有很强的耦合性，破坏了封装。
接口隔离原则：Interface Segregation Principle
该原则的定义：不能强迫用户去依赖那些他们不使用的接口。
简单来说就是客户端需要什么接口，就提供给它什么样的接口，其它多余的接口就不要提供，不要让接口变得臃肿，否则当对象一个没有使用的方法被改变了，这个对象也将会受到影响。接口的设计应该遵循最小接口原则，其实这也是高内聚的一种表现，换句话说，使用多个功能单一、高内聚的接口总比使用一个庞大的接口要好。
举个简单的例子：比如我们有个自行车接口，这个接口包含了很多方法，包括GPS定位，以及换挡的方法
屏幕快照 2018-10-27 下午8.12.08.png
然后我们发现即便普通的自行车也需要实现GPS定位以及换挡的功能，显然这违背了接口隔离的原则。遵循接口最小化的原则，我们重新设计：
屏幕快照 2018-10-27 下午8.14.21.png
这样一来每个接口的功能相对单一，使用多个专门的接口比使用一个总的接口要好，假如我们的山地车没有没有GPS定位的功能，我们不去继承实现对应的接口即可，在iOS开发中有很多这样的例子，比如UITalbleView的代理有两个不同的接口，UITableViewDataSource专门负责需要显示的内容，UITableViewDelegate专门负责一些view的自定义显示，然后我们会继承多个接口，这就满足了ISP原则。
@interface ViewController () <UITableViewDataSource,UITableViewDelegate,OtherProtocol>
依赖倒置原则：Dependence Inversion Principle
该原则的定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
其实这就是我们经常说的“针对接口编程”，这里的接口就是抽象，我们应该依赖接口，而不是依赖具体的实现来编程。
如你在Sqlite数据库的基础上开发一套新的数据库系统AWEDatabase，这时候Sqlite相当于底层模块，而你的AWEDatabase就属于高层模块；而从AWEDatabase开发使用者来看，他的业务层就相当于高层模块，而AWEDatabase就变成底层模块了，所以模块的高低应该是从开发者当前的角度来看的，不过DIP原则从不同角度来看它都适合且需要被遵守。假如我们高层模块直接依赖于底层模块，带来的后果是每次底层模块改动，高层模块就会受到影响，整个系统就变得不稳定，这也违反了开放关闭原则。
通常我们会通过引入中间层的方式来解决这个问题，这个中间层相当于一个抽象接口层，高层模块和底层模块都依赖于这个中间层来交互，这样只要中间抽象层保持不变，底层模块改变不会影响到高层模块，这就满足了开放关闭原则；而且假如高层模块跟底层模块同时处于开发阶段，这样有了中间抽象层之后，每个模块都可以针对这个抽象层的接口同时开发，高层模块就不需要等到底层模块开发完毕才能继续了。
比如在我们项目中有涉及IM的功能，现在这个IM模块采用的是XMPP协议来实现，客户端通过这个模块来实现消息的收发，但是假如后面我们想要换成其它协议，比如MQTT等，针对接口编程的话就可以让我们很轻松的实现模块替换：
屏幕快照 2018-10-27 下午8.18.18.png
@protocol MessageDelegate <NSObject>
@required
-(void)goOnline;
-(void)sendMessage:(NSString*)content;
@end
//xmpp实现
@interface XMPPMessageCenter <MessageDelegate>
@end
//MQTT实现
@interface MQTTMessageCenter <MessageDelegate>
@end
//业务层
@interface BussinessLayer
//使用遵循MessageDelegate协议的对象，针对接口编程，以后替换也很方便
@property(nonatomic,strong)id<MessageDelegate> messageCenter;
@end
当我们在进行面向对象设计的时候应该充分考虑上面这几个原则，一开始可能设计并不完美，不过可以在重构的过程中不断完善。但其实很多人都跳过了设计这个环节，拿到一个模块直接动手编写代码，更不用说去思考设计了，项目中也有很多这样的例子。当然对于简单的模块或许不用什么设计，不过假如模块相对复杂的话，能够在动手写代码之前好好设计思考一下，养成这个习惯，肯定会对编写出可读性、稳定性以及可扩展性较高的代码有帮助。
网友评论