架构训练营 0 期总结 -- 第二周

一、面向对象

写一写我比较有感触的地方，我面试过很多java程序员，不管是初级、中级、高级还是资深，我都会问一个问题：什么是面向对象？有的人回答用java写代码就是面向对象，好一点的会说是万物皆对象，对象有属性和方法，对象间有关系。然后我问三大特性是什么，基本都能能回答上来：封装、继承、多态。

1. 封装：隐藏实现细节(访问控制)，定义接口。

2. 继承：is-a关系，has-a关系(组合)

3. 多态：后期绑定，向上转形。



然后我会让面试者手写代码：小明邀请小红打篮球。

User  xiaohong = new User("xiaohong");
User  xiaoming = new User("xiaoming");
xiaohong.invite(xiaohong).play("basketball");
## xiaohong.invite(xiaohong).playBasketball();

对比下下面的代码：

inviteService.playBasketBall("xiaoming","xiaohong","basketball");
##playBasketBall方法内部是纯粹的调用entity，dao来完成对数据的持久化。

第一段代码定义了对象user和行为invite，play。第二段代码没有对象，一切都用service来解决，面向数据库编程。例子不够严谨，后面会把完整的实现贴出来，现在只是让大家有个基本感受。业务复杂的时候对对象的设计要求就很高，但是有了当前合理的对象，构建好系统的模型后期维护就会比较容易，因为之后的需求更迭会变成xxx对象的职责变了，xxx的和xxx的关系变了。而不是握着一堆乱七八糟的服务不知道是应该改这个还是改那个或者就干脆重新起一个新的服务。新人进团队了之后呈现给他的也是各种对象以及对象之间的关系，而不是一堆没有束缚的service。



二、SOLID

上面说过设计对象是非常考验能力的，前人总结了基础的五大规则(SOLID)：单一职责(S),开闭规则(O),里式替换(L),接口隔离(I),依赖倒置(D)。

单一职责是很好理解但是也是最难做好的。它的定义就是一个对象中只有一个行为会导致它的变化。那么我们怎么去确定它的单一职责以及行为呢，A有A的观点，B有B的观点，同样的场景设计出来的东西可能会完全不同。小到一个类的设计，大到微服务的划分，系统架构的设计，重点之一的边界问题就来源于单一职责。不同的场景有不同的设计，不同给的阶段也有不同的设计，找到当下最容易维护、关系最清晰的方案就是最好的单一职责设计。

开闭原则即对更改关闭、对扩展打开。这个规则的应用场景在很多if-else的时候有比较大的发挥空间，每添加一种场景，增加一个新的类去实现公共的父类，且注册一下当前所在类就行。不必再去更改原有的代码，后面我会补上一个示例。

里式替换原则要求子类和父类之间的设计得是正常的。这个正常就类似于，父类是马（可以骑和拉货的），子类可以是白马、黑马，你总不能说是海马，或者那种特别小的宠物马。

接口隔离用于控制权限，比如原来的abcd在一个接口下，有些实现类就需要这4个接口，但是有些场景下暴露第四个会有潜在危险，那么我们就可以把这个接口拆分成两个接口。需要是个的去实现这两个接口就好了，需要3个的实现第一个即可。

依赖倒置多用于框架和各种容器中，它要求实现的时候依赖抽象不依赖具体实现。还是用tomcat的例子来说：tomcat和web程序都遵循servlet的规范，tomcat依赖内部抽象的servlet规范，web程序提供servlet抽象的实现，然后在某种整合逻辑下，tomcat可以根据这种规范把请求给web程序，web程序也能把处理的结果返回给tomcat。