设计模式六大原则学习总结1

设计模式：面向对象语言开发过程中，遇到种种的场景和问题，提出的解决问题的思路。设计模式是解决具体问题的套路。

设计模式六大原则：面向对象语言开发过程中，推荐的一些指导性原则，没有明确招数，而且经常会被忽视或者违背。

 

目录

1.单一职责原则：

2.里氏替换原则：

3.迪米特法则：

---

1.单一职责原则：

定义：类T负责两个不同的职责：职责P1，职责P2。当由于P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2发生故障。

方法级别的单一职责原则：一个方法只负责一件事情（不同职责分拆成多个方法，分支逻辑拆分）；

类级别的单一职责原则：一个类只负责一件事情；

类库级别的单一职责原则：一个类库应该职责清晰；

项目级别的单一职责原则：一个项目应该职责清晰（客户端、管理后台、后台服务、定时任务、分布式引擎）；

系统级别的单一职责原则：为通用功能拆分成系统（IP定位、日志、在线统计）；

 

单一职责原则的优点：

1.降低代码的复杂度，一个类（方法、类库、项目、系统）负责一个事情，逻辑简单。

2.代码的可读性高，易维护。

 

单一职责原则的缺点：

1.代码拆分多了，代码量会增加。

2.类多了，方法多了，使用（理解）成本增高。

 

单一职责原则的使用：

如果类型足够简单，方法少，可以在类级别去违背单一职责；如果类型复杂，方法多，建议遵循单一职责原则；

 

2.里氏替换原则：

定义：任何使用基类的地方，都可以透明的使用其子类。

里氏替换原则实质是指导应该更好的使用继承。

1.父类里面的一些方法属性，子类中没有，那么子类就不应该再继承父类。

2.子类可以实现父类的抽象方法，但是父类不能覆盖父类的非抽象方法。

父类中凡是已经实现好的方法，实际上是在设计一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些规范，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。

 

看下面一个实例：有一个动物的抽象类，抽象类中定义动物可以吃饭和睡觉。有一个狗类继承动物类，并实现其父类的抽象方法。

执行结果：

 

 

上面的实例是正常的父子继承情况，如果要在子类中覆盖父类的非抽象方法，Dog类要覆盖BaseAnimal的Sleep方法，如下图：

 

 这样的话，执行结果就变了：

这种情况就违背了里氏替换原则，要么Dog类不要再继承BaseAnimal，要么Dog类就不要覆盖父类的Sleep方法。 

子类覆盖父类的非抽象方法，语法当然是没有问题的。只是从设计上不推荐这样用。

 

3.迪米特法则：

迪米特法则也叫最少知道原则，一个软件实体应当尽可能少地与其他实体发生相互作用。

很形象的一句话是只与最直接的朋友通信。

 

实例：明星与经纪人的关系。

明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与粉丝的见面会，与媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则。

经理人类：

粉丝类：

公司类：

明星类：

 

程序调用：

执行结果：

 

迪米特法则在具体程序中的应用：

1.尽量减少内部依赖。

2.降低访问修饰符，只暴露应该暴露的方法或者属性。

private、protected、internal、public 的使用

 

设计模式详细讲解参加：http://c.biancheng.net/design_pattern/