学会这10个设计原则，离架构师又进了一步！！！

知识分享，以技会友。大家好，我是Tom哥。阅读本文大约需要 15 分钟。

 

闲言碎语：

 

一个懂设计原则的程序猿，写出来的代码可扩展性就是强，后续的人看代码如沐春风。相反，如果代码写的跟流水账似的，完全一根筋平铺下来，后续无论换谁接手维护都要骂娘。

 

做软件开发多年，CRUD仿佛已经形成一种惯性，深入骨髓，按照常规的结构拆分：表现层、业务逻辑层、数据持久层，一个功能只需要个把小时代码就撸完了。

再结合CTRL+C和CTRL+V 绝世秘籍，一个个功能点便如同雨后春笋般被快速克隆实现。

是不是有种雄霸天下的感觉，管他什么业务场景，大爷我一梭到底，天下无敌！！！

 

可现实真的是这样？

答案不言而喻！！！

初入软件行业，很多人都会经历这个阶段。时间久了，很多人便产生困惑，能力并没有随着工作年限得到同比提升，焦虑失眠，如何改变现状？

悟性高的人，很快能从一堆乱麻中找到线索，并不断的提升自己的能力。

什么能力？

当然是软件架构能力，一名优秀的软件架构师，要具备复杂的业务系统的吞吐设计能力、抽象能力、扩展能力、稳定性。

如何培养这样能力?

 

我将常用的软件架构原则，做了汇总，目录如下：

 

 

当然这些原则有些是相互辅助，有些是相互矛盾的。实际项目开发中，要根据具体业务场景，灵活应对。千万不能教条主义，生搬硬套

 

 

单一职责

 

我们在编码的时候，为了省事，总是喜欢在一个类中添加各种各样的功能。未来业务迭代时，再不断的修改这个类，导致后续的维护成本很高，耦合性大。牵一发而动全身。

为了解决这个问题，我们在架构设计时通常会考虑单一职责

定义：

单一职责（SRP：Single Responsibility Principle），面向对象五个基本原则（SOLID）之一。每个功能只有一个职责，这样发生变化的原因也会只有一个。通过缩小职责范围，尽量减少错误的发生。

单一职责原则和一个类只干一件事之间，最大的差别就是，将变化纳入了考量。

代码要求：

一个接口、类、方法只负责一项职责，简单清晰。

优点：

降低了类的复杂度，提高类的可读性、可维护性。进而提升系统的可维护性，降低变更引起的风险。

示例：

有一个用户服务接口UserService，提供了用户注册、登录、查询个人信息的方法，主要还是围绕用户相关的服务，看似合理。

public interface UserService{
    // 注册接口
    Object register(Object param);
    // 登录接口
    Object login(Object param);
    // 查询用户信息
    Object queryUserInfoById(Long uid);
} 

过了几天，业务方提了一个需求，用户可以参加项目。简单的做法是在UserService类中增加一个joinProject()方法

又过了几天，业务方又提了一个需求，统计一个用户参加过多少个项目，我们是不是又在UserService类中增加一个countProject()方法。

这样导致的后果是，UserService类的职责越来越重，类会不断膨胀，内部的实现会越来越复杂。既要负责用户相关还有负责项目相关，后续任何一块业务变动，都会导致这个类的修改。

两类不同的需求，都改到同一个类。正确做法是，把不同的需求引起的变动拆分开，单独构建一个ProjectService类，专门负责项目相关的功能

public interface ProjectService{
    // 加入一个项目
    void addProject (Object param);
    // 统计一个用户参加过多少个项目
    void countProject(Object param);
}

这样带来的好处是，用户相关的需求只要改动UserService。如果是项目管理的需求，只需要改动ProjectService。二者各自变动的理由就少了很多。

 

开闭原则

 

开闭原则（OCP：Open-Closed Principle），主要