阿里大佬告诉我，想学习设计模式，得先学好这些硬核技能
写在前面
我们继续学习架构师技能，今天是本系列的第二篇，希望大家持续关注。
可能你不是科班出生，甚至大学都没念，没背景没关系。我们只要每天进步一点点，一个月、两个月、半年、一年......。
规划性的学习一年半载后，你会觉得开始的你是多么的无知，如若不信，你可试试看！
只要你肯努力，迟早弯道超车！
坐稳了，开始发车
网上都流行那么个段子：搞死一个程序员，不用动刀或枪，只需要修改几次需求。
开玩笑，确定吗？
我也是程序员，也和相关人员互怼过，不过都只是动口不动手。确实，很多时候，相关人员提的需求确实有点过分，因为要考虑到工期以及现有资源，有句话叫做“你给我做够资源和时间，我可以给你造飞机火箭！”。
话又说回来，看这篇文章的相信都是程序员，咱们都是一路人。但，我想说其实很多时候，我们也存在问题。
比如：系统设计的可扩展性、可维护性等，大家是否真的有认真想过，甚至部分人连软件设计的七大原则都还搞不清楚。
不过，很多人也是想好好设计的，但是无赖，给你工期不够，否则，你需要加班，甚至加班估计够呛，从而也就导致系统逐渐变的非常难以维护，臃肿，同样的功能有n套代码，到最后就是推翻了出个新版本（长痛不如短痛）。
但，牛逼的人，只要工期不是很离谱，他们写代码永远是看起来非常舒服、还给你预留了很多扩展口子、封装了很多公用的工具类、抽象出了很多模型等等。
综上，个人建议同行朋友，尤其是三年左右的，这时候，知识的广度，深度都要有所涉及，同时，系统设计或者某个模块的设计也是体现你的能力的点（领导交给你的某个模块，其实也可以理解为一个系统，所以还是要认真对待，大项目也是有多个模块组成的）。希望大家一定多体会&&领会软件设计的七大原则。
牛人们的总结
Robert C.Martin
一个可维护性（Maintainability）较低的软件设计，通常由于以下4个原因造成
1、过于僵化(Rigidity)：设计难以修改
2、过于脆弱(Fragility)：设计易遭到破坏（需要修改的时候，容易牵一发而动全身，不该受到影响的代码也被迫的破坏掉）
3、牢固性(Immobility)：复用率低（当想使用一些功能时会发现里面的某些代码不是他想要的，想把这些代码去掉时，发现没办法去掉，原因是代码耦合度太高了）
4、粘度过高(Viscosity)：难以做正确事情（维护的过程中想进行修改某些代码，但是发现没有办法进行修改，原因就是粘度太高）
PeterCoad
一个好的系统设计应该具备如下三个特性：
- 可扩展性（Extendibility）
- 灵活性（Flexibility）
- 可插入性（Pluggability）
面向对象设计原则和设计模式也是对系统进行合理重构，重构是在不改变软件现有功能的基础上，通过调整代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理性，提高软件的扩展性和维护性。
软件设计七大原则
- 开闭原则
- 依赖倒置原则
- 单一职责原则
- 接口隔离原则
- 迪米特法则
- 里氏替换原则
- 合成复用原则
关于这个七大设计原则，相信大部分人也听说过，甚至很多朋友都学习过，但是始终没有掌握，希望通过本文的分享，不敢说你一定能掌握，但是至少掌握部分。
本文主要内容就是软件设计的七大原则，重点在于用代码来演示。
PS：七种原则并不是孤立存在的，他们相互依赖，相互补充。
开闭原则
开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶提出，他在 1988 年的著作《面向对象软件构造》中提出：
软件实体应当对扩展开放，对修改关闭
这就是开闭原则的经典定义。
在现实生活中，开闭原则也有体现。比如，很多互联网公司都实行弹性制作息时间，规定每天工作8小时。意思就是，对于每天工作8小时这个规定是关闭的，但是什么时候来、什么时候走是开放的。早来早走，晚来晚走。
作用
开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。
- 对软件测试的影响：软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。
- 可以提高代码的可复用性：粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。
- 可以提高软件的可维护性：遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。
实际案例
报名一个网上课程，课程有价格、id、名称。
//课程接口类
public interface ICourse {
String getCourseName();
Integer getCourseId();
BigDecimal getCoursePrice();
}
//整个课程生态有Java架构、大数据、人工智能、前端、软件测试等。
//我们创建一个Java架构课程的类JavaCourse。
public class JavaCourse implements ICourse {
@Override
public String getCourseName() {
return "JAVA课程";
}
@Override
public Integer getCourseId() {
return 1;
}
@Override
public BigDecimal getCoursePrice() {
return new BigDecimal("599");
}
}
public class OpenCloseDemo {
public static void main(String[] args) {
ICourse course = new JavaCourse();
System.out.println("课程ID=" + course.getCourseId());
System.out.println("课程名称=" + course.getCourseName());
System.out.println("课程价格=" + course.getCoursePrice());
}
}
运行OpenCloseDemo的main方法，结果：
课程ID=1
课程名称=JAVA课程
课程价格=599
现在要给Java架构课程做活动，价格优惠，比如双11、618等节日搞促销活动。如果修改JavaCourse中的getPrice()方法，则会存在一定风险，可能影响其他地方的调用结果。
如何在不修改原有代码的前提下，实现价格优惠这个功能呢？我们再写一个处理优惠逻辑的类——JavaDiscountCourse类（可以思考一下为什么要叫JavaDiscountCourse，而不叫DiscountCourse）。
于是我们就这么干，增加一个java课程的打折类。
public class JavaDiscountCourse extends JavaCourse {
public BigDecimal getDiscountCoursePrice(BigDecimal discount) {
return super.getCoursePrice().multiply(discount);
}
}
public class OpenCloseDemo {
public static void main(String[] args) {
JavaCourse course = new JavaDiscountCourse();
DiscountJavaCourse discountJavaCourse = (DiscountJavaCourse) course;
System.out.println("课程ID=" + course.getCourseId());
System.out.println("课程名称=" + course.getCourseName());
System.out.println("课程价格=" + course.getCoursePrice());
BigDecimal discount = new BigDecimal(0.5);
System.out.println("课程折后价=" + discountJavaCourse.getDiscountCoursePrice()discount;
}
}
运行结果：
课程ID=1
课程名称=JAVA课程
课程价格=599
课程折后价=299.5
这样的话，我们就没必要动JavaCourse这个类了，其他地方可能还在使用这个JavaCourse中的价格。
整个类图：
依赖倒置原则
定义
依赖倒置原则（Dependence Inversion Principle，DIP）指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。通过依赖倒置，可以降低类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并降低修改程序带来的风险。
案例
我们来看一个案例，还是以课程为例，首先创建一个类Tian。
public class Tian {
public void studyJavaCourse(){
System.out.println("老田在学java课程");
}
public void studyCCourse(){
System.out.println("老田在学C课程");
}
}
然后编写客户端测试代码并调用。
public static void main(String[] args) {
Tian tian = new Tian();
tian.studyJavaCourse();
tian.studyCCourse();
}
随着学习兴趣的暴涨，老田还想学习AI课程。
这个时候，需要业务扩展，代码要从底层到高层（调用层）一次修改代码。在Tian类中增加studyAICourse()的方法，在高层也要追加调用。如此一来，在系统发布以后，实际上是非常不稳定的，在修改代码的同时会带来意想不到的风险。因此我们优化代码，首先创建一个课程的抽象接口ICourse。
public interface ICourse {
void study();
}
然后写JavaCourse类。
public class JavaCourse implements ICourse {
@Override
public void study() {
System.out.println("老田在学习java架构师课程");
}
}
再实现PythonCourse类。
public class PythonCourse implements ICourse {
@Override
public void study() {
System.out.println("老田在学习Python课程");
}
}
最后修改Tian类。
public class Tian {
public void study(ICourse course) {
course.study();
}
}
来看客户端测试代码。
public static void main(String[] args) {
Tian tian = new Tian();
ICourse course = new JavaCourse();
tian.study(course);
}
这时候再看代码，老田的兴趣无论怎么暴涨，对于新的课程，只需要新建一个类，通过传参的方式告诉Tian，而不需要修改底层代码。实际上，这是一种大家非常熟悉的方式，叫作依赖注入。
- 构造器注入方式
- Setter注入方式。
下面来看构造器注入方式。
public class Tian {
private ICourse course;
/** 构造函数方式注入course **/
public Tian(ICourse course) {
this.course = course;
}
public void study() {
course.study();
}
}
来看客户端代码，将JavaCourse对象作为Tian对象的构造参数注入。
public static void main(String[] args) {
Tian tian = new Tian(new JavaCourse());
tian.study();
}
}
根据构造器注入方式，当调用时，每次都要创建实例。
但，如果Tian是全局单例，则只能选择Setter注入方式，继续修改Tian类的代码。
public class Tian {
private ICourse course;
public void setCourse(ICourse course) {
this.course = course;
}
public void study() {
course.study();
}
}
来看客户端代码，调用Tian对象的setCourse（）方法，将JavaCourse对象作为参数。
public static void main(String[] args) {
Tian tian = new Tian();
tian.setCourse(new JavaCourse());
tian.study();
tian.setCourse(new PythonCourse());
tian.study();
}
}
最终得到的类图如下：
注：
以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此大家在拿到需求后，要面向接口编程，按照先顶层再细节的顺序设计代码结构。
单一职责原则
定义
单一职责原则的定义单一职责原则（Simple Responsibility Principle，SRP）指不要存在一个以上导致类变更的原因。
假设有一个Class负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个Class就存在两个导致类变更的原因。
如何解决这个问题呢？我们就要分别用两个Class来实现两个职责，进行解耦。后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。
总体来说就是一个Class、Interface、Method只负责一项职责。
案例
我们来看代码实例，还是用课程举例，我们的课程有直播课和录播课。直播课不能快进和快退，录播课可以任意地反复观看，功能职责不一样。首先创建一个Course类。
public class ICourse {
public void study(String courseName){
if("直播课".equals(courseName)){
System.out.println("不能快进哦");
}else{
System.out.println("可以自定义播放速度，已经来回播放");
}
}
}
然后看客户端代码，无论是直播课还是录播课，都调用study()方法的逻辑。
public class Test1 {
public static void main(String[] args) {
Course course = new Course();
course.study("直播课");
course.study("看录像");
}
}
从上面代码来看，Course类承担了两种处理逻辑。
假如，现在对课程进行加密，那么直播课和录播课的加密逻辑是不一样的，必须修改代码。
而修改代码逻辑势必会相互影响，容易带来不可控的风险。
我们对职责进行分离解耦，分别创建两个类LiveCourse和ReplayCourse。
LiveCourse直播课程：
public class LiveCourse {
public void study(String courseName){
System.out.println("现场直播，无法修改播放速度");
}
}
ReplayCourse重播或录像课程：
public class ReplayCourse {
public void study(String courseName){
System.out.println("看录像，可以随便切换播放速度，以及来回播放");
}
}
客户端代码如下，将直播课的处理逻辑调用LiveCourse类，录播课的处理逻辑调用ReplayCourse类。
public class Test2 {
public static void main(String[] args) {
LiveCourse course = new LiveCourse();
course.study("直播课");
ReplayCourse replayCourse=new ReplayCourse();
replayCourse.study("录播课");
}
}
当业务继续发展时，要对课程做权限。没有付费的学员可以获得课程的基本信息，已经付费的学员可以获得视频流，即学习权限。
那么对于控制课程层面，至少有两个职责。我们可以把展示职责和管理职责分离开，都实现同一个抽象依赖。
设计一个顶层接口，创建ICourse接口。
public interface ICourse {
//获得课程的基本信息
String getCourseName();
//获取视频流
byte[] getCourseVioeo();
//学习课程
void studyCourse();
//退款
void refundCourse();
}
可以把这个接口拆成两个接口，创建一个接口ICourseInfo和ICourseManager。ICourseInfo接口的代码如下。
ICourseInfo接口的代码如下：
public interface ICourseInfo {
//获取课程名称
String getCourseName();
//获取课程视频流
byte [] getCourseVideo();
}
ICourseManager接口的代码如下：
public interface ICourseManager {
//学习课程
void studyCourse();
//退款
void refundCourse();
}
下面来看方法层面的单一职责设计。有时候，为了偷懒，通常会把一个方法写成下面这样。
public void modifyUserInfo(String userName, String address){
userName = userName;
address = address;
}
还可能写成这样：
private void modifyUserInfo(String userName, String... fields){
userNmae = userName;
}
private void modifyUserInfo(String userName, String address,boolean flag){
if(flag){
//....
}else{
//....
}
userName = userName;
address = address;
}
显然，上面两种写法的modifyUserInfo（）方法都承担了多个职责，既可以修改userName，也可以修改address，甚至更多，明显不符合单一职责原则。那么我们做如下修改，把这个方法拆成两个。
private void modifyUserName(String userName){
userName = userName;
}
private void modifyAddress(String address){
address = address;
}
代码在修改之后，开发起来简单，维护起来也容易。在实际项目中，代码会存在依赖、组合、聚合关系，在项目开发过程中还受到项目的规模、周期、技术人员水平、对进度把控的影响，导致很多类都不能满足单一职责原则。但是，我们在编写代码的过程中，尽可能地让接口和方法保持单一职责，对项目后期的维护是有很大帮助的。
接口隔离原则
定义
接口隔离原则的定义接口隔离原则（Interface Segregation Principle，ISP）指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。
这个原则指导我们在设计接口时，应当注意以下几点。
（1）一个类对另一个类的依赖应该建立在最小接口上。
（2）建立单一接口，不要建立庞大臃肿的接口。
（3）尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。
接口隔离原则符合“高聚合、低耦合”的设计思想，使得类具有很好的可读性、可扩展性和可维护性。在设计接口的时候，要多花时间思考，要考虑业务模型，包括还要对以后可能发生变更的地方做一些预判。所以，在实际开发中，我们对抽象、业务模型的理解是非常重要的。
案例
我们来写一个动物行为的抽象。
IAnimal接口的代码如下：
public interface IAnimal{
//吃
void eat();
//飞
void fly();
//游泳
void swim();
}
Bird实现类代码如如下：
public class Bird implements IAnimal{
//吃
@Override
void eat(){
//小鸟吃东西
}
//飞
@Override
void fly(){
//小鸟在飞
}
//游泳
void swim(){
//空着，因为小鸟不游泳
}
}
Dog类实现的代码如下。
public class Dog implements IAnimal{
//吃
@Override
void eat(){
//小狗吃东西
}
//飞
@Override
void fly(){
//空着，因为小狗不会飞
}
//游泳
void swim(){
//小狗在游泳
}
}
由上面代码可以看出，Bird类的swim（）方法可能只能空着，Dog类的fly（）方法显然是不可能的。这时候，我们针对不同动物的行为来设计不同的接口，分别设计IEatAnimal、IFlyAnimal和ISwimAnimal接口。
IEatAnimal接口的代码如下：
public interface IEatAnimal{
//吃
void eat();
}
IFlyAnimal接口的代码如下：
public interface IFlyAnimal{
//飞
void fly();
}
ISwimAnimal接口的代码如下：
public interface ISwimAnimal{
//游泳
void swim();
}
Dog只实现IEatAnimal和ISwimAnimal接口。
public class Dog implements IEatAnimal、ISwimAnimal{
//吃
@Override
void eat(){
//小狗吃东西
}
//游泳
void swim(){
//小狗在游泳
}
}
我们来看两种类图的对比，如下图所示，还是非常清晰明了的。
迪米特法则
迪米特法则的定义
迪米特法则（Law of Demeter，LoD）又叫作最少知道原则（Least KnowledgePrinciple，LKP），指一个对象应该对其他对象保持最少的了解，尽量降低类与类之间的耦合。迪米特法则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入和输出参数中的类都可以被称为成员朋友类，而出现在方法体内部的类不属于朋友类。
案例
我们来设计一个权限系统，TeamLeader需要查看目前发布到线上的课程数量。这时候，TeamLeader要让Employee去进行统计，Employee再把统计结果告诉TeamLeader，来看代码。
Course类的代码如下：
public class Course{
}
Employee类的代码如下：
public class Employee{
public void checkNumberOfCourse(List<Course> courseList){
System.out.println("目前已经发布的课程数量是：" + courseList.size());
}
}
TeamLeader类的代码如下：
public class TeamLeader{
public void commandCheckNumber(Employee employee){
List<Course> courseList = new ArrayList();
for(int i=0;i<20;i++){
courseList.add(new Course());
}
employee.checkNumberOfCourse(courseList);
}
}
客户端测试代码如下，将Employee对象作为参数传送给TeamLeader对象
public static void main(String [] args){
TeamLeader teamLeader = new TeamLeader();
Employee employee = new Employee();
teamLeader.commandCheckNumber(employee);
}
写到这里，其实功能都已经实现，代码看上去也没什么问题。根据迪米特法则，TeamLeader只想要结果，不需要跟Course产生直接交流。而Employee统计需要引用Course对象，TeamLeader和Course并不是朋友，从如下图所示的类图就可以看出来。
改造
Employee类的代码如下。
public class Employee{
public void checkNumberOfCourse(List<Course> courseList){
List<Course> courseList = new ArrayList();
for(int i=0;i<20;i++){
courseList.add(new Course());
}
System.out.println("目前已经发布的课程数量是：" + courseList.size());
}
}
TeamLeader类的代码如下。
ublic class TeamLeader{
public void commandCheckNumber(Employee employee){
employee.checkNumberOfCourse(courseList);
}
}
再来看如下图所示的类图，Course和TeamLeader已经没有关联了。
学习软件设计原则，千万不能形成强迫症。当碰到业务复杂的场景时，需要随机应变。
里氏替换原则
定义
里氏替换原则（Liskov Substitution Principle，LSP）指如果对每一个类型为T1的对象O1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有对象O1都替换成O2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。
定义看上去比较抽象，我们重新解释一下，可以理解为一个软件实体如果适用于一个父类，则一定适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。也可以理解为，子类可以扩展父类的功能，但不能改变父类原有的功能。根据这个理解，我们对里氏替换原则的定义总结如下。
（1）子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
（2）子类中可以增加自己特有的方法。
（3）当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松。
（4）当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类的方法更严格或相等。
案例
在讲开闭原则的时候，我们埋下了一个伏笔。我们在获取折扣价格后重写覆盖了父类的getPrice()方法，增加了一个获取源码的方法getOriginPrice()，这显然违背了里氏替换原则。我们修改一下代码，不应该覆盖getPrice()方法，增加getDiscountPrice()方法。
public class JavaDiscountCourse extends JavaCourse{
public JavaDiscountCourse(Integer id, String name,Double price){
super(id,name,price);
}
public Double getDiscountPrice(){
return suer.getPrice()*0.5
}
}
使用里氏替换原则有以下优点：
- 约束继承泛滥，是开闭原则的一种体现。
- 加强程序的健壮性，同时变更时可以做到非常好的兼容性，提高程序的维护性、可扩展性，降低需求变更时引入的风险。
现在来描述一个经典的业务场景，用正方形、矩形和四边形的关系说明里氏替换原则，我们都知道正方形是一个特殊的长方形，那么可以创建一个长方形的父类Rectangle类，代码如下。
public class Rectangle{
private long height;
private long width;
//set get方法省略
}
创建正方形Square类继承长方形，代码如下：
public class Square extends Rectangle{
private long length;
//length的get set方法
@Override
public long getHeight(){
return getLength();
}
@Override
public void setHeight(long height){
setLength(height);
}
@Override
public long getWidth(){
return getLength();
}
@Override
public void setWidth(long width){
setLength(width);
}
}
在测试类中，创建resize（）方法。根据逻辑，长方形的宽应该大于等于高，我们让高一直自增，直到高等于宽变成正方形，代码如下。
public class Test {
public static void resize(Rectangle rectangle) {
while (rectangle.getWidth() >= rectangle.getHeight()) {
rectangle.setHeight(rectangle.getHeight() + 1);
System.out.println("width=" + rectangle.getWidth() +
" height=" + rectangle.getHeight());
}
System.out.println("Resize end,width=" + rectangle.getWidth() +
" height=" + rectangle.getHeight());
}
public static void main(String[] args) {
Rectangle rectangle = new Rectangle();
rectangle.setWidth(20);
rectangle.setHeight(10);
resize(rectangle);
}
}
运行结果：
width=20 height=11
width=20 height=12
width=20 height=13
width=20 height=14
width=20 height=15
width=20 height=16
width=20 height=17
width=20 height=18
width=20 height=19
width=20 height=20
width=20 height=21
Resize end,width=20 height=21
由运行结果可知，高比宽还大，这在长方形中是一种非常正常的情况。再来看下面的代码，把长方形替换成它的子类正方形，修改客户端测试代码如下。
public class Test {
public static void resize(Rectangle rectangle) {
while (rectangle.getWidth() >= rectangle.getHeight()) {
rectangle.setHeight(rectangle.getHeight() + 1);
System.out.println("width=" + rectangle.getWidth() +
"height=" + rectangle.getHeight());
}
System.out.println("Resize end,width=" + rectangle.getWidth() +
"height=" + rectangle.getHeight());
}
public static void main(String[] args) {
Square square = new Square();
square.setWidth(20);
square.setHeight(10);
resize(square);
}
}
运行结果：
此时，运行出现了死循环，违背了里氏替换原则，在将父类替换为子类后，程序运行结果没有达到预期。因此，代码设计是存在一定风险的。里氏替换原则只存在于父类与子类之间，约束继承泛滥。
再来创建一个基于长方形与正方形共同的抽象——四边形QuardRangle接口，代码如下。
public interface QuardRangle {
long getHeight();
long getWidth();
}
修改长方形Rectangle类的代码如下。
public class Rectangle implements QuardRangle{
private long height;
private long width;
@Override
public long getHeight() {
return height;
}
public void setHeight(long height) {
this.height = height;
}
@Override
public long getWidth() {
return width;
}
public void setWidth(long width) {
this.width = width;
}
}
修改正方形Square类的代码如下。
public class Square implements QuardRangle{
private long length;
public long getLength() {
return length;
}
public void setLength(long length) {
this.length = length;
}
@Override
public long getHeight(){
return length;
}
@Override
public long getWidth(){
return length;
}
}
此时，如果把resize（）方法的参数换成四边形QuardRangle类，方法内部就会报错。因为正方形已经没有了setWidth（）和setHeight（）方法，所以，为了约束继承泛滥，resize（）方法的参数只能用长方形Rectangle类。
合成复用原则
定义
合成复用原则（Composite/Aggregate Reuse Principle，CARP）指尽量使用对象组合（has-a）或对象聚合（contanis-a）的方式实现代码复用，而不是用继承关系达到代码复用的目的。
合成复用原则可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较小。继承，又被称为白箱复用，相当于把所有实现细节暴露给子类。
组合/聚合又被称为黑箱复用，对类以外的对象是无法获取实现细节的。我们要根据具体的业务场景来做代码设计，其实也都需要遵循面向对象编程（Object OrientedProgramming，OOP）模型。
案例
还是以数据库操作为例，首先创建DBConnection类。
public class DBConnection{
public String getConnection(){
return "数据库连接";
}
}
创建ProductDao类。
public class ProdcutDao{
private DBConnection dbConnection;
public void setDBConnection(DBConnection dbConnection){
this.dbConnection=dbConnection;
}
public void addProduct(){
String conn=dbConnection.getConnection();
System.out.println("使用" + conn + "连接数据库");
}
}
这是一种非常典型的合成复用原则应用场景。但是，对于目前的设计来说，DBConnection还不是一种抽象，不便于系统扩展。目前的系统支持MySQL数据库连接，假设业务发生变化，数据库操作层要支持Oracle数据库。
当然，我们可以在DBConnection中增加对Oracle数据库支持的方法，但是这违背了开闭原则。其实，可以不必修改Dao的代码，将DBConnection修改为abstract，代码如下。
public abstract class DBConnection{
public abstract String getConnection();
}
然后将MySQL的逻辑抽离。
public class MySQLConnection extends DBConnection{
@Override
public String getConnection(){
return "MySQL 数据库连接";
}
}
再创建Oracle支持的逻辑。
public class OracleConnection extends DBConnection{
@Override
public String getConnection(){
return "Oracle 数据库连接";
}
}
具体选择交给应用层，来看如下图所示的类图。
总结
学习设计原则是学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，而是要综合考虑人力、时间、成本、质量，不刻意追求完美，要在适当的场景遵循设计原则。这体现的是一种平衡取舍，可以帮助我们设计出更加优雅的代码结构。
分别用一句话归纳总结软件设计七大原则，如下表所示。
参考：Tom的架构师笔记
大家好，我是一个写了10来年bug的老田，继续分享架构师技能，对设计模式感兴趣的可以加我wx：tj20120622，一起搞定设计模式。
学得越多，不知道的越多，但咱们还是不能停下学习的jio步。
腾讯云开发者
