OOP设计原则

很久没跟新技术博客了，惭愧！

最近做一个关于OOP设计原则的演讲，到处找资料，也顺便把我了解到的跟大家讲一下。

有涉及很多原则，最基本的是叫做“SOLID”的五条原则：

S = 单一职责原则 Single Responsibility PrincipleO = 开放闭合原则 Opened Closed Principle L = Liscov替换原则 Liscov Substitution PrincipleI = 接口隔离原则 Interface Segregation PrincipleD = 依赖倒置原则 Dependency Inversion Principle

单一职责原则：

用图表示就是：

看懂了吗？英文翻译是：“不是因为你可以做，你就都做。”

让我们回到创世起初，我们看到男人外出打猎野兽，女人在洞穴中看顾孩子。来到古代社会，男耕女织，分工明细，自给自足。回到现代社会，分工趋于明细，专业区分也更加的细致，经济学、会计学、金融学、国际贸易学……

回到OOP设计原则上，类也是如此，应该被划分地更加细致，职责越专一越好，能够引起它变动的因素越少越好。因为这样意味着它可以更加专注于自己的负责的一块，并且不必因为其他类的修改而影响到自身的功能。能够做到功能如上图般丰富的“刀”又有多少？上能掏耳朵，下能剪指甲，饿了还可以削苹果皮！如果可以，我想使用起来也不会很方便！更多的时候，我们需要的是一把只能剪指甲，却很锋利，也很好用的指甲刀，而不是一把样样都能的“全能刀”

因而，我们在设计类的时候也应该注意，不要太想“一口吃成胖子”，要拆分类的功能，做到职责单一。

开放闭合原则：

它的意思是：当你需要换一件衣服的时候，没必要打开你的胸膛。

这意味着，你的身体对修改是封闭的（你不能轻易被开膛破肚，否则你就死了），而你的身体对于外部的扩展比如穿衣服，则是开放的（你可以随意地换上合身的衣服）。

对人如此，对类也是这样。

让我们看一张图：

这就是违背”开放封闭原则“的设计，因为当你改动服务类时，客户端类就很可能也需要被修改，这样做导致了 他们之间的高耦合度。

而这样的设计则是更好的：

这样子做添加了一个抽象服务类，而在客户端类中包含了一个抽象服务类的引用，具体的服务类实现了抽象服务类。这样，当具体的服务类发生修改时，抽象服务类没有改动，进而包含抽象服务类的引用的客户端类就不用发生改动！

在这里，抽象是关键！如果你抽象的好，很可能在扩展功能的时候，不需要设计其他的类，这就减少了很多的工作，提高了效率！

里氏替换原则：

同样用一张图：

继续翻译：”如果它看起来像一只鸭子，叫声像鸭子，但是需要电池————你很可能做出了错误的抽象“

此文未完…………