偷偷看了同事的代码找到了优雅代码的秘密

最新推荐文章于 2024-10-02 07:55:04 发布

A1867350

最新推荐文章于 2024-10-02 07:55:04 发布

阅读量813

点赞数 8

分类专栏：程序员文章标签： log4j c# 开发语言

本文链接：https://blog.csdn.net/A1867350/article/details/137975536

版权

程序员专栏收录该内容

553 篇文章 0 订阅

订阅专栏

这里我们以一个例子来进行说明，否则可能还是有点抽象。在一个监控平台中，我们需要对服务所占用CPU、内存等运行信息进行监控，第一版代码如下。

public class Alarm {

private AlarmRule alarmRule;

private AlarmNotify alarmNotify;

public Alarm(AlarmRule alarmRule, AlarmNotify alarmNotify) {

this.alarmRule = alarmRule;

this.alarmNotify = alarmNotify;

}

public void checkServiceStatus(String serviecName, int cpu, int memory) {

if(cpu > alarmRule.getRule(ServiceConstant.Status).getCpuThreshold) {

alarmNotify.notify(serviecName + alarmRule.getRule(ServiceConstant.Status).getDescription)

}

if(memory > alarmRule.getRule(ServiceConstant.Status).getMemoryThreshold) {

alarmNotify.notify(serviecName + alarmRule.getRule(ServiceConstant.Status).getDescription)

}

复制代码

代码逻辑很简单，就是根据对应的告警规则中的阈值判断是否达到触发告警通知的条件。如果此时来了个需求，需要增加判断的条件，就是根据服务对应的状态，判断需不需要进行告警通知。我们来先看下比较low的修改方法。我们在checkServiceStatus方法中增加了服务状态的参数，同事在方法中增加了判断状态的逻辑。

public class Alarm {

private AlarmRule alarmRule;

private AlarmNotify alarmNotify;

public Alarm(AlarmRule alarmRule, AlarmNotify alarmNotify) {

this.alarmRule = alarmRule;

this.alarmNotify = alarmNotify;

}

public void checkServiceStatus(String serviecName, int cpu, int memory， int status) {

if(cpu > alarmRule.getRule(ServiceConstant.Status).getCpuThreshold) {

alarmNotify.notify(serviecName + alarmRule.getRule(ServiceConstant.Status).getDescription)

}

if(memory > alarmRule.getRule(ServiceConstant.Status).getMemoryThreshold) {

alarmNotify.notify(serviecName + alarmRule.getRule(ServiceConstant.Status).getDescription)

}

if(status == alarmRule.getRule(ServiceConstant.Status).getStatusThreshold) {

alarmNotify.notify(serviecName + alarmRule.getRule(ServiceConstant.Status).getDescription)

}

复制代码

很显然这种修改方法非常的不友好，为什么这么说呢？首先修改了方法参数，那么调用该方法的地方可能也需要修改，另外如果改方法有单元测试方法的话，单元测试用例必定也需要修改，在原有测试过的代码中添加新的逻辑，也增加了bug引入的风险。因此这种修改的方式我们需要进行避免。那么怎么修改才能够体现对修改关闭以及对扩展开放呢？首先我们可以先将关于服务状态的属性抽象为一个ServiceStatus 实体，在对应的检查方法中以ServiceStatus 为入参，这样以后如果还有服务状态的属性增加的话，只需要在ServiceStatus 中添加即可，并不需要修改方法中的参数以及调用方法的地方，同样单元测试的方法也不用修改。

@Data

public class ServiceStatus {

String serviecName;

int cpu;

int memory;

int status;

}

复制代码

另外在检测方法中，我们怎么修改才能体现可扩展呢？而不是在检测方法中添加处理逻辑。一个比较好的实现方式就是通过抽象检测方法，具体的实现在各个实现类中。这样即使新增检测逻辑，只需要扩展检测实现方法就可，不需要在修改原先代码的逻辑，实现代码的可扩展。

LSP

LSP（Liskov Substitution Principle）里氏替换原则，这个设计原则我觉得相较于前面的两个设计原则来说要简单些。它的内容为子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。

里式替换原则是用来指导，继承关系中子类该如何设计的一个原则。理解里式替换原则，最核心的就是理解“design by contract，按照协议来设计”这几个字。父类定义了函数的“约定”（或者叫协议），那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。这里的约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。

我们怎么判断有没有违背LSP呢？我觉得有两个关键点可以作为判断的依据，一个是子类有没有改变父类申明需要实现的业务功能，另一个是否违反父类关于输入、输出以及异常抛出的规定。

ISP

ISP（Interface Segregation Principle）接口隔离原则，简单理解就是只给调用方需要的接口，它不需要的就不要硬塞给他了。这里我们举个栗子，以下是关于产品的接口，其中包含了创建产品、删除产品、根据ID获取产品以及更新产品的接口。如果此时我们需要对外提供一个根据产品的类别获取产品的接口，我们应该怎么办？很多同学会说，这还不简单，我们直接在这个接口里面添加根据类别查询产品的接口就OK了啊。大家想想这个方案有没有什么问题。

public interface ProductService {

boolean createProduct(Product product);

boolean deleteProductById(long id);

Product getProductById(long id);

int updateProductInfo(Product product);

}

public class UserServiceImpl implements UserService { //…}

复制代码

这个方案看上去没什么问题，但是再往深处想一想，外部系统只需要一个根据产品类别查询商品的功能，，但是实际我们提供的接口中还包含了删除、更新商品的接口。如果这些接口被其他系统误调了可能会导致产品信息的删除或者误更新。因此我们可以将这些第三方调用的接口都隔离出来，这样就不存在误调用以及接口能力被无序扩散的情况了。

public interface ProductService {

boolean createProduct(Product product);

boolean deleteProductById(long id);

Product getProductById(long id);
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。