设计原则是思想上的指导，而设计模式是实现上的手段，是针对某个场景下某些问题的某个解决方案，因此设计模式应该遵 守这些原则，换句话说，设计模式就是这些设计原则的一些具体体现。
 
设计模式常用的七大原则有:
 
单一职责原则 ——一个类只负责一个功能领域中的相应职责
开闭原则 ——对扩展开放，对修改关闭
里氏代换原则 ——所有引用基类的地方必须能透明地使用其子类的对象
依赖倒转原则 ——依赖于抽象，不能依赖于具体实现
接口隔离原则 ——类之间的依赖关系应该建立在最小的接口上
合成/聚合复用原则 ——尽量使用合成/聚合，而不是通过继承达到复用的目的
迪米特法则 ——一个软件实体应当尽可能少的与其他实体发生相互作用
 
UML 建模方法通过多种图形（Diagram）和视图（View）提供了多个层次、多个角度分析、观察软件架构的丰富手段和灵活表现形式，例如著名的“4+1 视图”（Use Case View, Logical/Design View, Process View, Implementation View, Deployment View）等。基于这样的思考，软件架构的设计才是全方位、系统化和高质量的。
我 认为 UML 最大的价值，在于帮助开发者对软件设计进行敏捷的思考（Agile thinking in UML）。针对一个具体、复杂的软件设计问题，编程高手在开始编码之前常常善于利用各种模型、图形与方法论在自己的大脑中进行深入思考和建模（Mind Modeling），明确需求，评估方案的可行性和有效性，衡量各种可选方案的利弊，必要时也会利用白板、图纸等建模工具进行设计，做到胸有成竹后才动 手，结果往往效率高、质量高而差错和返工少。这就是专家们常说的 Quality Before Code。
 
而普通码农，由于缺乏设计经验和思维训练，常常对一个问题的需求和方案还没想明白就习惯性地、急匆匆地开始编码，思维不成熟、考虑失误的结果必然导致代码错误一大堆，改来改去还老改不对（俗称 code and fix），因此浪费了不少时间和精力，还美其名曰“重构”。
 
每 天动手编码前或在编码过程中进行少量、必要（just enough）的 UML 建模、方案设计与思考，可以避免后期许多的折腾和浪费，这无疑是一种非常敏捷的优秀工程实践。其实像 Scott Ambler、Craig Larman、Martin Fowler 等敏捷大师都一直鼓励和提倡敏捷建模（Agile Modeling）如 UML Sketch（UML 素描）。可惜在敏捷运动的前十年时间里这并未引起大家的足够重视，因此我把 UML 建模（包括敏捷建模、太极建模等）列为 Agile 2.0 的一个重要实践。