设计模式（07）——设计原则（2）

2020 年 12 月 5 日
筆記
设计模式

KISS原则

Keep It Simple and Stupid 这个原则听起来比较简单，重点是理解什么样的代码是简单的，代码行数少就是简单的代码吗？？？还是说当程序的逻辑十分复杂不容易理解时就是一个复杂的代码呢？？？

下面就让我们来看看怎么样判断简单。

代码行数

代码就不展示了，其实懂的都懂，代码行数是一定不能作为判断依据的，因为很多代码行数少的代码，其实是采用了一些高级语法特性的。如正则表达式、位运算符等。

如果盲目的采用这些特性，会影响代码的可读性，因为这种运算法为了减少代码行数，会采用很多方式来规定一些特性，这些特性有时会不好理解。例如用位运算符来代替算数运算，这样虽然会提高代码性能和减少行数，但也不是 KISS 原则下的指导产物，其违反了代码的可读性。

逻辑复杂

那代码的逻辑复杂可以作为判断依据吗？其实也是懂的都懂，代码也不展示了（因为太复杂了，所以不展示了-v-），为什么逻辑复杂不能作为判断依据呢？？？

因为有些代码他就是逻辑复杂的，如果不信的话，直接打开算法相关实现，找到一个看不懂的，那么其就是我们的目标了。

因此如果没办法，在特定场景下，只能采用该算法的实现，那么使用这种复杂逻辑就不是违反 KISS 原则了，因为没办法。

场景

综上，我们该如何写出符合 KISS 原则的代码呢，具体来说，还是需要 结合业务发展和技术团队能力。

在实际场景下，我们尽量做到以下几点就可以了。

不使用同事可能不懂的语法和技术，例如 lambda、正则等（不过这些还好，例如 lambda 虽然有些时候部分地方还不让使用，但其实其早已不是一个新技术了，还不懂的话，这种情况可以考虑换个地方或者进行下部门培训了）
不要重复造轮子，因为自己造的轮子在一定程度上肯定没有网上大家都用的好，比较容易出现问题，而这些问题可能在对应的轮子上已经被解决来（但自己学习的时候，该造还是要造）
不要过度优化，炫技，例如为了提高性能和减少代码行数，使用大量的位运算符、复杂的条件表达式等，这些都是给机器看的，一般我们都不需要在这个性能上过分的优化，反而牺牲来代码的可读性

YAGNI原则

定义

不要去设计当前用不到的功能，不要去写当前用不到的代码。

该原则是作为一个指导思想来做的，其作用就是防止过度设计，但需要注意的是其是让你不做，但需要有可能要做的意识，提前留好拓展点，这样如果要做的时候，也可以快速跟上。
**

后续会有一篇文章，来专门讲解如何在软件设计中，防止过度设计，但对对应该优化，该留好优化点如何实现。

DRY原则

定义

英语解释为：Dont repeat yourself，可以理解为不要写重复的代码，要做好代码的可复用性。但该规则跟 KISS 原则一样，听起来可能比较简单，但是在实际使用中，却要注重的一个原则。

因为在该原则中，有一个很关键的点，什么样的代码是重复的代码，只是简单的代码一样就是违反该原则了吗？下面就让我们来根据以下几种场景来判断什么是重复的代码。

实现逻辑重复

 public boolean validUsername(String username) {
        if (StrUtil.isEmpty(username)) {
            return false;
        }
        if (username.contains("77777")) {
            return false;
        }
        return true;
    }

    public boolean validNickname(String nickname) {
        if (StrUtil.isEmpty(nickname)) {
            return false;
        }
        if (nickname.contains("77777")) {
            return false;
        }
        return true;
    }

我们来看一下，这一段代码是重复的吗？

明显能看出，两个方法的执行逻辑是一模一样的，那么我们可以说其是重复的，而将其合为一个方法吗？

答案是不行的，首先如果合成一个就违反了单一职责原则，一个方法做了多件事，此外，现在两个参数的校验逻辑是一样的，因此看着重复，后面如果 nickname 的校验逻辑改了呢？那就需要侵入式的修改代码，需要在所有使用该方法的代码中进行修改，依据 nickname 来特定的进行判断，从而违反了开闭原则。

因此，实现逻辑重复，不能构成代码重复的条件。

功能语义重复

    public boolean checkPasswordByRegex(String password) {
        String regex = "123456";
        boolean matches = Pattern.matches(regex, password);
        return matches;
    }

    public boolean checkPasswordByStr(String password) {
        boolean matches = StrUtil.equals(password, "123456");
        return matches;
    }

我们来看一下，上述两段代码是否构成重复？

答案是这两段代码是重复的代码，虽然这两段代码的实现逻辑不一致，代码编写也不一致，但其仍然违反了 DRY 原则，因为这两段代码所实现的点是一样的，下面我们来看一下这样重复的代码会带来什么隐患。

这样的设计可能会导致以下问题，

当一个不知情的人看到这两段代码完成的任务是一样的，但采用的解决方式却是不一样的，则会想其的设计深意，以及不知道该用哪一个？
当函数的实现逻辑要改的时候，可能会导致修改了其中一个，而忘记修改另一个，这样则会造成逻辑的不一致。

代码执行重复

    // 代码执行重复
    public boolean validContainsA(String temp) {
        if (StrUtil.isNotEmpty(temp) && temp.contains("A")) {
            return true;
        }
        return false;
    }

    public boolean validTemp(String temp) {
        if (StrUtil.isNotEmpty(temp) && temp.contains("A")) {
            return true;
        }
        return validContainsA(temp);
    }

上述代码因为举的例子比较简单，应该能很简单的看出有一段代码被执行了两次，那么这样的设计违反了 DRY 原则吗？

我们认为其也是违反的，这里放的只是一个简单的逻辑判断，所以看不出来什么，如果这里是放了一个耗时操作呢，例如读取数据库、文件等。那么进行重复的执行，则会影响整个程序的对外性能。

总结

因此，判断如何一个代码是否是重复的，需要结合具体场景来做判断，在这里，我们可以看到代码实现方式一样不能作为判断依据，因此其实现的语义是不同的，这就是功能语义的判断范畴，而对于重复执行，我们在代码里需要做到尽量避免，因为如果重复执行费时操作，则会导致代码整体对外的性能下降。

迪米特原则

定义

迪米特原则是用来指导设计高内聚、低耦合代码的原则，因此我们先看一下什么是高内聚、低耦合。

高内聚：相近的功能放到一个类或模块中，不相近的功能不要放到一个类中，暗合了单一职责原则；
低耦合：类和类之间的依赖关系清晰简洁，即使有依赖，也要做到其中一个修改，依赖或被依赖的少修改。

看到想要完成的目标，现在再来看一下什么是迪米特原则。

其概念是：每个类或模块只需要了解与他关系密切即紧密关联的类或模块。再换句话说：

不该有依赖关系的不要有依赖；
有依赖关系，只依赖必要的接口。

Tags: 设计模式