设计模式的个人理解

type

status

date

slug

summary

category

icon

password

😀

设计模式一般指23种设计模式，但随着变成技术的发展，设计模式以远不指23种，例如生产者消费者模式、并发性模式。 Android开发中常用的MVP、MVVC模式研究的是模块之间的关系，解决通用问题，属于架构设计，而设计模式研究的是类、对象、接口之间的关系，解决特定情况的问题。关于MVP和MVVC会在后面的文章讲解。

设计模式是在软件设计中经常出现的特定问题的通用解决方案。它们可以被视为编程问题的最佳实践，这些问题会在我们的实际编程中反复出现。

设计模式可以帮助程序员编写可重用的代码，使代码更易于理解，易于维护，并且保证代码的可靠性。

设计模式通常可以分为三类：

创建型模式（Creational Patterns）：这类模式涉及到对象的创建机制，试图在创建对象的时候提供更多的灵活性和效率。例如：单例模式（Singleton）、建造者模式（Builder）、原型模式（Prototype）、工厂方法模式（Factory Method）、抽象工厂模式（Abstract Factory）等。

结构型模式（Structural Patterns）：这类模式主要关注类和对象的组合，以获得新的功能。例如：适配器模式（Adapter）、装饰器模式（Decorator）、代理模式（Proxy）、外观模式（Facade）、桥接模式（Bridge）、组合模式（Composite）、享元模式（Flyweight）等。

行为型模式（Behavioral Patterns）：这类模式专注于对象之间的通信，即对象之间的责任分配。例如：策略模式（Strategy）、模板方法模式（Template Method）、观察者模式（Observer）、迭代器模式（Iterator）、责任链模式（Chain of Responsibility）、状态模式（State）、访问者模式（Visitor）等。

这些模式我们常用的并不多，观察者模式、单例模式等这些常用的设计模式一定要掌握。

设计模式的四大原则，是指在面向对象的软件设计中，为了提高软件的可维护性、灵活性和稳定性，而总结出的一套设计原则。这四个原则分别是：

单一职责原则（Single Responsibility Principle, SRP）：一个类应该只有一个引起它变化的原因。换句话说，一个类应该只负责一项职责。这样可以使类的复杂性降低，提高类的可读性和可维护性，但可能会导致更多的代码和类文件。

开闭原则（Open-Closed Principle, OCP）：软件实体（类、模块、函数等等）应当对扩展开放，对修改关闭。也就是说，当应用的需求改变时，我们应该尽量通过添加新代码进行扩展，而不是改变已有的代码。

里氏替换原则（Liskov Substitution Principle, LSP）：所有引用基类的地方必须能透明地使用其子类的对象。也就是说，在软件中，如果使用的是基类的话，那么其子类可以无缝替换。这样可以保证继承关系的合理性。

依赖倒置原则（Dependency Inversion Principle, DIP）：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖于细节，细节应该依赖于抽象。换言之，要依赖于抽象（接口和抽象类），不要依赖于具体类（细节），这样可以减少类间的耦合性，提高系统的稳定性。

这四个原则可以帮助代码结构更统一，提高扩展性，但同时也带来一些负面影响。例如单一职责原则，一个类只负责一项职责，如果我们新增功能就需要新建类，这样就会生成很多类，并不方便我们阅读和调试；开闭原则也是一样，增加新功能都是添加新代码而不是修改代码，这样做的结果就是随着项目的发展，废弃代码会越来越多，结构越来越臃肿，层层嵌套。所以设计模式并不是万金油，而是一种指导思想，在实际的软件开发中，需要根据具体的需求和情况来灵活运用。

下面总结了设计模式的优缺点：

优点：

代码复用性：设计模式提供了一种解决常见问题的通用模板，这意味着开发者可以在不同的项目中重复使用这些解决方案，从而节省开发时间。

提高代码可读性：设计模式为特定的问题提供了结构化的解决方案。因此，如果开发者熟悉特定的设计模式，他们就能更快地理解使用这些模式的代码。

提高代码的可维护性：由于设计模式提供了结构化和通用的解决方案，因此使用它们的代码通常更容易维护和修改。

提高系统的可扩展性：设计模式通常使得代码更易于扩展，因为它们通常将变化的部分从稳定的部分中分离出来。

提高团队沟通效率：设计模式提供了一种共享的语言，开发者可以通过提到特定的设计模式来更好地交流他们的设计思想。

缺点：

增加系统的复杂性：设计模式通常涉及创建更多的类和对象，这可能会使系统变得更复杂。

学习曲线陡峭：为了正确和有效地使用设计模式，开发者需要花费一定的时间来学习和理解它们。

过度使用：设计模式并不是适用于所有情况的解决方案。有时，开发者可能会过度使用设计模式，从而导致代码变得不必要地复杂。

不适用于所有情况：设计模式并不是所有问题的解决方案。有时，尝试将设计模式应用于不适合的情况可能会导致更多的问题。