设计模式之美学习笔记

面向对象编程的几大特性：封装、抽象、继承、多态

封装：信息隐藏或者数据访问保护。类通过暴露优先的访问接口，授权外部仅能通过类提供的方式来访问内部信息或者数据

封装能对类中的属性做访问限制，提高类的易用性

抽象：隐藏信息、保护数据

面向对象封装的定义是：通过访问权限控制，隐藏内部数据，外部仅能通过类提供的有限

的接口访问、修改内部数据。所以，暴露不应该暴露的 setter 方法，明显违反了面向对象

的封装特性。数据没有访问权限控制，任何代码都可以随意修改它，代码就退化成了面向过

程编程风格的了。

 

在设计实现类的时候，除非真的需 要，否则，尽量不要给属性定义 setter 方法。除此之外，尽管 getter 方法相对 setter 方法要安全些，但是如果返回的是集合容器（比如例子中的 List 容器），也要防范集合内部数据被修改的危险。

当 Constants 类中包含很多常量定义的时候，依赖这个类的代码就会很多。那每次修改

Constants 类，都会导致依赖它的类文件重新编译，因此会浪费很多不必要的编译时间。

我们在做软件开发的时候，一定要有抽象意识、封装意识、接口意识。在定义接

口的时候，不要暴露任何实现细节。接口的定义只表明做什么，而不是怎么做。而且，在设

计接口的时候，我们要多思考一下，这样的接口设计是否足够通用，是否能够做到在替换具

体的接口实现的时候，不需要任何接口定义的改动。

 

只要搞清楚了这条原则是为了解决什么样的问题而产生的，你

就会发现，很多之前模棱两可的问题，都会变得豁然开朗。

前面我们也提到，这条原则的设计初衷是，将接口和实现相分离，封装不稳定的实现，暴露

稳定的接口。上游系统面向接口而非实现编程，不依赖不稳定的实现细节，这样当实现发生

变化的时候，上游系统的代码基本上不需要做改动，以此来降低代码间的耦合性，提高代码

的扩展性。

从这个设计初衷上来看，如果在我们的业务场景中，某个功能只有一种实现方式，未来也不

可能被其他实现方式替换，那我们就没有必要为其设计接口，也没有必要基于接口编程，直

接使用实现类就可以了。

除此之外，越是不稳定的系统，我们越是要在代码的扩展性、维护性上下功夫。相反，如果

某个系统特别稳定，在开发完之后，基本上不需要做维护，那我们就没有必要为其扩展性，

投入不必要的开发时间。

 

针对鉴权这个功能的开发，我们该如何做需求分析？

实际上，这跟做算法题类似，先从最简单的方案想起，然后再优化。所以，我把整个的分析

过程分为了循序渐进的四轮。每一轮都是对上一轮的迭代优化，最后形成一个可执行、可落

地的需求列表。