用OC代码认识设计模式（一）--创建型模式
用OC代码认识设计模式（二）--结构型模式
用OC代码认识设计模式（三）--行为型模式
用OC代码认识六大设计原则
- 单一职责原则：类的职责要单一；
- 里氏替换原则：不要破坏继承体系；
- 依赖倒置原则：要面向接口编程；
- 接口隔离原则：设计接口的时候要精简；
- 迪米特法原则：降低耦合；
- 开放封闭原则：对扩展开放，对修改关闭。
1、单一职责原则（Single Responsibility Principle，简称SRP ）
定义：就一个类而言，应该仅有一个引起它变化的原因。
示例：
1、员工的工资计算。刚开始的时候，我们会新建一个员工类，在员工类里面有一个计算工资的方法，代码如下所示：
//Employee.h
@interface Employee : NSObject
// 计算工资
- (void)calculateSalary:(NSString *)name;
@end
//Employee.m
@implementation Employee
- (void)calculateSalary:(NSString *)name
{
NSLog(@"%@的工资是100",name);
}
@end
Employee *employee = [[Employee alloc] init];
[employee calculateSalary:@"张三"];
[employee calculateSalary:@"李四"];
/*结果输出
张三的工资是100
李四的工资是100
*/
产品上线后，问题出来了，因为员工的岗位不同，工资的计算是不一样的。一般有三种修改方法：
（1）简单做法，修改calculateSalary，增加参数
// 计算工资,增加员工岗位的标识(Director:总监;Manager:经理;Staff:普通员工)
- (void)calculateSalary:(NSString *)name flag:(NSString *)flag
{
if ([flag isEqualToString:@"Director"])
{
NSLog(@"%@总监的工资是10000",name);
}
else if ([flag isEqualToString:@"Manager"])
{
NSLog(@"%@经理的工资是1000",name);
}
else if ([flag isEqualToString:@"Staff"])
{
NSLog(@"%@员工的工资是100",name);
}
}
（2）新建方法
// 总监工资计算
- (void)directorCalculateSalary:(NSString *)name;
// 经理工资计算
- (void)managerCalculateSalary:(NSString *)name;
// 普通员工工资计算
- (void)staffCalculateSalary:(NSString *)name;
（3）新建类
Director *director = [[Director alloc] init];
Manager *manager = [[Manager alloc] init];
Staff *staff = [[Staff alloc] init];
上面三种方式各有优缺点，那么在实际编程中，该采用哪一种呢？这个问题没有标准答案，需要根据实际情况来确定。
但是只有（3）是符合单一职责原则，也是最复杂的。
2、里氏替换原则（Liskov Substitution Principle,简称LSP）
定义：在使用基类的的地方可以任意使用其子类，能保证子类完美替换基类。
里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。
它包含以下2层含义：
1、子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法；
2、子类中可以增加自己特有的方法。
3、依赖倒置原则（Dependence Inversion Principle,简称DIP）
定义：高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖细节；细节应该依赖抽象。
例子：
SalaryManage类负责工资的管理；Director是总监类，现在我们要通过SalaryManage类来给总监发放工资了，主要代码片段如下所示：
// SalaryManage.h
- (void)calculateSalary:(Director *)director
{
[director calculateSalary];
}
// 员工类
Director *director = [[Directoralloc] init];
director.strName = @"张三";
// 工资管理（财务部）
SalaryManage *salaryManage = [[SalaryManagealloc] init];
[salaryManage calculateSalary:director];
假设我们还需要给普通员工、财务总监、研发总监等更多的岗位发送工资，那么我们就只能不断的去修改SalaryManage类来满足业务的需求。产生这种现象的原因就是SalaryManage与Director之间的耦合性太高了，必须降低它们之间的耦合度才行。因此我们引入一个委托EmployeeDelegate，它提供一个发放工资的方法定义，如下所示：
然后我们让具体的员工类Director、Manager等都实现EmployeeDelegate委托方法
@protocol EmployeeDelegate <NSObject>
- (void)calculateSalary;
@end
// 修改后的SalaryManage计算工资方法：
- (void)calculateSalary:(id<EmployeeDelegate>)employee
{
[employee calculateSalary];
}
// 使用例子
Director *director = [[Directoralloc] init];
director.strName = @"张三";
Manager *manager = [[Manageralloc] init];
manager.strName = @"李四";
SalaryManage *salaryManage = [[SalaryManagealloc] init];
[salaryManage calculateSalary:director];
[salaryManage calculateSalary:manager];
这与对象适配器模式差不多。
4、接口隔离原则（Interface Segregation Principle,简称ISP）
定义：类间的依赖关系应该建立在最小的接口上
在这里，我们定义了一个动物活动的接口IAnimal，里面有4个方法：飞行fly、行走walk、吃eat和工作work，然后分别用人类People和鸟类Bird实现了这个接口。中国人类ChinesePeople和鹦鹉类Parrot通过接口IAnimal分别依赖类People和类Bird。很明显，对于ChinesePeople来说，fly方法是多余的，因为人不会飞；对于Parrot类来说，work方法是多余的，因为鹦鹉不需要工作。接口IAnimal对于类ChinesePeople和类Parrot来说不是最小接口。
解决方案
将臃肿的接口IAnimal拆分为独立的几个接口，类ChinesePeople和类Parrot分别与它们需要的接口建立依赖关系，也就是采用接口隔离原则。修改后的UML图如下所示：
5、迪米特法则（Law of Demeter,简称LoD）
定义：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用，这里的第三者就是接口InmatesDelegate。
6、开放封闭原则（Open Close Principle,简称OCP）
定义：一个软件实体(如类、模块、函数)应当对扩展开放，对修改关闭。
尽量让设计的类做好后就不再修改，如果有新的需求，通过新加类的方式来满足，而不去修改现有的类(代码)。
