我写了一些关于设计模式的文章。一些例子是观察者模式和策略模式。在编写软件时，这两种模式都非常有效。但我也提到了SOLID，这是一个设计原则的集合。但设计模式和设计原则之间有什么区别呢？我们什么时候谈论设计模式，什么时候谈论设计原则呢？
设计模式和原则都在帮助我们编写更优秀的代码。其中一个更侧重于架构和指南，而另一个更侧重于代码中的解决方案。我们——开发者——在进行工作时需要有某种指导原则和解决方案。但请记住，我们正在处理的是软件：应预料到意外，并且需要了解并非所有环境都一样。
作为开发人员，我接触过很多原则和模式。有些是由团队成员想出来的，适用于该解决方案，有些则由伟大的思想家定义，仍在维护，并且至今仍在使用。本文是关于后者的。
定义
设计模式和设计原则都有各自不同的定义，这已经展示了它们之间的巨大差异。设计模式是某一特定问题的解决方案。大多数定义都可以在代码中显示。因为它可以翻译成代码，所以这个解决方案通常是可重用的，可以帮助解决反复出现的设计问题。
设计原则是一种指南，它向开发者解释了某些解决方案或指导方针，使得解决代码中可能出现的问题变得更容易。这些指导方针在此是为了帮助我们预防问题。设计问题帮我们创建健壮、易维护、灵活的软件。设计原则并不是代码，只是理论。
设计模式
最为人所知的设计模式之一就是单例模式。这种模式规定并显示，一个类应该只被初始化一次，这个类实例在应用程序的生命周期内一直存在。该模式可用于使用类和初始化类的所有编程语言。
另一个示例是策略模式。这种模式是一种行为模式，它允许在运行时动态选择策略。你可以简化复杂的if语句，或在运行时做出动态选择。
还有其他的示例，如观察者模式和工厂模式，但是还有更多。你可以把它们分为三类：创建性设计、结构设计和行为设计。下面的图片给你一个好的理念，哪些模式属于哪个类别。
你几乎不可能记住并运用所有的模式。我的建议是：理解他们的基本思想，知道在什么时候可以使用他们，当你处在一个可能会想到“噢，我知道一个模式可以解决这个问题！”的情况下，弄清楚它们是如何工作的。
设计原则
如果你看一下设计原则，我们会看到其他的名字出现。像SOLID、DRY、KISS，以及其他一些有趣的缩写。
DRY代表的是“不要重复自己”（Don’t Repeat Yourself），它的原则是你不应该写重复的代码。重复的代码在你需要改变一些东西时可能会造成很多问题。要避免这些问题，把你的代码写一次，然后在你的应用程序的其他部分重用它。
KISS代表的是“保持简单，愚蠢”（Keep It Simple Stupid），尽管在现代通常省略了最后的’s’。这个原则规定代码应该对于他人来说是简单和可理解的。你越是使它变得复杂，对于其他人理解就变得越困难。
SOLID是一组不同原则的集合：单一职责原则、开闭原则、里氏替换原则、接口隔离原则和依赖倒置原则。我可能会为所有这些原则举例，但那将会使你阅读量增大（也会使我书写量增大）。如果你在Wikipedia上查看SOLID的定义，你会得到很多信息。
使用场景
使用原则或模式的时刻也有所不同。没有一种解决方案适用于所有情况，而且你可能根本不会使用它们。设计模式通常在编码过程中使用，因为它们为特定的代码问题提供了解决方案。模式可以在途中添加或移除。
在创建软件的过程中，你的观点可能会变化（或者你的经理的观点会变）。这使你会有不同的决定，你可能想添加或移除一个模式。这是可以的。例如，一个简单的if语句突然变成了一个由elseif-elseif-elseif-elseif-等构成的怪物。那么也许是时候实施策略模式了。
设计原则通常在开发的早期阶段应用。它们主要是关于架构设计和规划。但也包括高级设计。这些是你在编码你的应用程序一半时不能改变的事情。
单一责任原则（Single Responsibility Principle，SRP）非常重要。如果你失去了对这个原则的控制，类和方法开始承担多重责任，你可能最终会重构你的代码，并且打破了许多方法，因为责任可能被分散到了多个方法和类中。
结论
设计模式是经过验证的解决方案，可以帮助解决反复出现的问题。设计原则是指导方针，可以帮助你为你的软件提供结构和架构。就这样，仅此而已。
你不需要使用所有存在的模式和原则。实际上，在单个软件应用程序中使用所有SOLID原则几乎是不可能的。我曾经做到过一次，那是一个示例项目。
查看设计原则和设计模式的区别并知道何时使用哪一个是一种很好的实践。再说一次，你几乎不可能记住所有的模式和原则，但是要知道他们的名字和背后的基本理念。
