代码港湾

主题

什么是过度设计？ ​

假如我有一个加减乘除的方法，我可以这样写：

java
public int calculate(int numa, int numb, char operation) {
    switch (operation) {
        case '+':
            return numa + numb;
        case '-':
            return numa - numb;
        case '*':
            return numa * numb;
        case '/':
            return numa / numb;
        default:
            return 0;
    }
}

但如果我希望后续支持更多的计算模式，用了策略模式后，就变成了这样，代码变多了，逻辑也复杂了很多：

java
public interface Operation {
    int calculate(int numa, int numb);
}
java
public class Addition implements Operation {
    @Override
    public int calculate(int numa, int numb) {
        return numa + numb;
    }
}
public class Subtraction implements Operation {
    @Override
    public int calculate(int numa, int numb) {
        return numa - numb;
    }
}
public class Multiplication implements Operation {
    @Override
    public int calculate(int numa, int numb) {
        return numa * numb;
    }
}
public class Division implements Operation {
    @Override
    public int calculate(int numa, int numb) {
        return numa / numb;
    }
}
java
public class OperationFactory {
    private static final Map<String, Operation> operations = new HashMap<>();

    static {
        operations.put("+", new Addition());
        operations.put("-", new Subtraction());
        operations.put("*", new Multiplication());
        operations.put("/", new Division());
    }

    public static Operation getOperation(String operation) {
        return operations.get(operation);
    }
}

设计模式的荼毒体现在哪？ ​

设计模式本身是软件工程中的最佳实践，它们提供了解决常见问题的模板或蓝图。然而，当不恰当地使用或过度使用时，设计模式可能会带来一些负面效果，这可以被称为“设计模式的荼毒”。以下是几个体现：

  1. 过度设计：开发人员可能倾向于为每一个小问题都应用设计模式，即使这些问题并不需要如此复杂的解决方案。这会导致代码变得过于复杂，难以理解和维护。

  2. 性能损失：某些设计模式，如装饰器模式或代理模式，可能会引入额外的层次和间接性，从而导致性能下降。

  3. 学习曲线：对于新手开发者来说，理解设计模式可能是一个陡峭的学习过程。如果项目中广泛使用了各种设计模式，那么新加入团队的成员可能需要花费大量时间来熟悉这些模式，从而降低了开发效率。

  4. 僵化的设计：过度依赖设计模式可能导致系统设计变得僵化，限制了系统的灵活性和适应性。例如，严格遵循单一职责原则（SRP）可能会导致过多的小类，使得系统难以管理和扩展。

  5. 不必要的复杂性：有时候，简单直接的解决方案会更加有效。而设计模式可能会增加不必要的抽象层，使得代码更难阅读和调试。

  6. 模式误用：不正确地选择或实现设计模式可能会导致代码质量下降。例如，错误地使用工厂模式（Factory Pattern）可能导致紧耦合，而不是预期的松耦合。

  7. 忽视上下文：设计模式通常是在特定上下文中提出的解决方案。如果不考虑实际的应用场景盲目套用，可能会适得其反。

  8. 沟通障碍：团队成员之间对设计模式的理解可能存在差异，这可能导致沟通上的误解，影响协作效率。

简化思维：避免不必要的复杂性 ​

把复杂问题搞简单，而不是把简单问题搞复杂，以下是两个例子，在考虑编写代码时，我们往往会陷入一种最优思维，这其实是没必要的，这会加重我们的思维负担。

  • 数据结构和算法－>大数据量问题：在考虑排序算法时，应该从数据量的角度去选择排序算法，如果数据量较小，则越简单越好。
  • 设计模式或代码设计－>复杂代码的问题：如果代码比较简单，业务变动大，完全没必要用设计模式。

如何避免过度设计？ ​

  1. 不要为了应用设计模式而应用，解决问题而不是炫技。
  2. 不以破坏代码可读性为前提，宁要可读不要优雅。
  3. 不要为了短期不存在的扩展而费神（YAGNI : You Ain't Gonna Need It）。
  4. 持续重构优于提前设计，发现问题，解决问题，不要试图一开始就打造完美代码。

总结 ​

在使用设计模式时，重要的是要根据具体的情况权衡利弊，并且保持适度。

设计模式应该是用来帮助解决问题的工具，而不是问题本身。

在实际开发中，应该以简洁性和实用性为原则，避免为了模式而模式。