本文是极客时间里王争专栏《设计模式之美》的学习笔记，你可以通过链接阅读原文获取更加详尽的描述，也可以通过该链接进行订阅和购买获取优惠。

接口隔离原则（ISP）

今天来看看SOLID中的I, 接口隔离原则。

如何理解“接口隔离原则”？

接口隔离原则（Interface Segregation Principle），缩写为ISP。其定义：

Clients should not be forced to depend upon interfaces that they do not use。

客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。

"接口"这个名词，在软件开发中，我们既可以把它看做一组抽象的约定，也可以具体指系统与系统之间的API接口，还可以特指面向对象编程语言中的接口等。

理解接口隔离原则的关键，就是理解其中的“接口”二字。在这条原则中，我们可以把“接口”理解以下三种：

• 一组API接口集合
• 单个API接口或函数
• OOP中的接口概念

接下来看看，按照这三种理解方式，在不同的场景下，这条原则具体是如何解读和应用的。

本文是极客时间里王争专栏《设计模式之美》的学习笔记，你可以通过链接阅读原文获取更加详尽的描述，也可以通过该链接进行订阅和购买获取优惠。

里氏替换原则（LSP）

今天来看看SOLID 中的L, 里氏替换原则。

如何理解“里式替换原则”？

里式替换原则（Liskov Substitution Principle），缩写为 LSP。最早是在 1986 年由 Barbara Liskov 提出。里氏替换原则的定义：

子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。

本文是极客时间里王争专栏《设计模式之美》的学习笔记，你可以通过链接阅读原文获取更加详尽的描述，也可以通过该链接进行订阅和购买获取优惠。

开闭原则

在 23 种经典设计模式中，大部分设计模式都是为了解决代码的扩展性问题而存在的，主要遵从的设计原则就是开闭原则。

如何理解“对扩展开放、修改关闭”？

开闭原则（Open Closed Principle）,简写为OCP。其定义：

software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。

软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。

添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

本文是极客时间里王争专栏《设计模式之美》的学习笔记，你可以通过链接阅读原文获取更加详尽的描述，也可以通过该链接进行订阅和购买获取优惠。

单一职责原则（SRP）

SOLID原则是由 5 个设计原则组成的，它们分别是：单一职责原则、开闭原则、里式替换原则、接口隔离原则和依赖反转原则，依次对应 SOLID 中的 S、O、L、I、D 这 5 个英文字母。今天学习的是 SOLID 原则中的第一个原则：单一职责原则。

本文是基于BeeHive版本1.6.0进行分析。

BeeHive核心思想涉及两个部分：

1. 各个模块间从直接调用对应模块，变成以Service的形式，避免了直接依赖。
2. App生命周期的分发，将耦合在AppDelegate中的逻辑拆分，每个模块以微应用的形式独立存在。

Core+Plugin的形式可以让一个应用主流程部分得到集中管理，不同模块以plugin形式存在，便于横向的扩展和移植。

情景：把一堆算法塞到同一段代码中，然后使用if-else或者switch-case条件语句来决定要使用哪个算法？这些算法可能是一堆相似的类函数或方法，用以解决相关的问题。例如验证数据输入的情形，数据本身可以是任何数据类型(如CGFloat，NSString，NSInteger等)，每种数据类型需要不同的算法。如果把每一种算法封装成一个对象，那么就能消除根据数据类型决定使用什么算法的一堆if-else或switch-case语句。 面向对象软件设计中，我们可以把相关算法分离为不同的类，成为策略，对应的设计模式称为策略模式。