单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。
该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
依赖倒置原则（Dependence Inversion Principle，DIP）是 Object Mentor 公司总裁罗伯特·马丁（Robert C.Martin）于 1996 年在 C++ Report 上发表的文章。
依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程。
依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。
由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。
使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。
里氏替换原则（Liskov Substitution Principle，LSP）由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立（Inheritance should ensure that any property proved about supertype objects also holds for subtype objects）。
里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。
在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据 7 条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。
开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出：软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。
这里的软件实体包括以下几个部分：
开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。
设计模式不是为每个人准备的，而是基于业务来选择设计模式，需要时就能想到它。要明白一点，技术永远为业务服务，技术只是满足业务需要的一个工具。我们需要掌握每种设计模式的应用场景、特征、优缺点，以及每种设计模式的关联关系，这样就能够很好地满足日常业务的需要。
许多设计模式的功能类似，界限不是特别清楚（为了能让大家更好的理解，后面会列出类似功能设计模式之间的对比）。大家不要疑惑，设计模式不是为了特定场景而生的，而是为了让大家可以更好和更快地开发。
设计模式只是实现了七大设计原则的具体方式，套用太多设计模式只会陷入模式套路陷阱，最后代码写的凌乱不堪。
在实际工作中很少会规定必须使用哪种设计模式，这样只会限制别人。不能为了使用设计模式而去做架构，而是有了做架构的需求后，发现它符合某一类设计模式的结构，在将两者结合。
设计模式要活学活用，不要生搬硬套。想要游刃有余地使用设计模式，需要打下牢固的程序设计语言基础、夯实自己的编程思想、积累大量的时间经验、提高开发能力。目的都是让程序低耦合，高复用，高内聚，易扩展，易维护。
| 分类 | 箭头特征 | 记忆技巧 |
|---|---|---|
| 箭头方向 | 从子类指向父类 | 1. 定义子类需要通过 extends 关键字指定父类； 2. 子类一定是知道父类定义的，但父类并不知道子类的定义； 3. 只有知道对方信息时才能指向对方； 4. 箭头的方向是从子类指向父类 |
| 继承/实现 | 用线条连接两个类；空心三角箭头表示继承或实现 | 实线表示继承，是is-a的关系，表示扩展，不虚，很结实 |
| 虚线表示实现，虚线代表“虚”无实体 | ||
| 关联/依赖 | 用线条连接两个类；普通箭头表示关联或依赖 | 1. 虚线表示依赖关系：临时用一下，若即若离，虚无缥缈，若有若无； 2. 表示一种使用关系，一个类需要借助另一个类来实现功能； 3. 一般一个类将另一个类作为参数使用，或作为返回值 |
| 1. 实线表示关联关系：关系稳定，实打实的关系，“铁哥们”； 2. 表示一个类对象和另一个类对象有关联； 3. 通常一个类中有另一个类对象作为属性 | ||
| 组合/聚合 | 用菱形表示：像一个盛东西的器皿（如盘子） | 1. 聚合：空心菱形，代表空器皿里可以放很多相同的东西，聚集在一起（箭头方向所指的类）； 2. 整体和局部的关系，两者有独立的生命周期，是 has-a 的关系； 3. 弱关系，消极的词：弱-空 |
| 1. 组合：实心菱形，代表器皿里已经有实体结构的存在，生死与共； 2、 整体与局部的关系，和聚合关系对比，关系更加强烈，两者具有相同的生命周期，contains-a 的关系 3. 强关系，积极的词；强-满 |
在 UML 2.0 的 13 种图中，类图（Class Diagrams）是使用频率最高的 UML 图之一。类图描述系统中的类，以及各个类之间的关系的静态视图，能够让我们在正确编写代码之前对系统有一个全面的认识。类图是一种模型类型，确切地说，是一种静态模型类型。类图表示类、接口和它们之间的协作关系，用于系统设计阶段。
设计模式有两种分类方法，即根据模式的目的来分和根据模式的作用的范围来分。
根据目的来分
根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。
根据作用范围来分
根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。