一.六个设计的基本原则
1.单一职责
所谓的单一职责就是对于一个类而言，尽量只有一个引起它变化的原因，简单的来说，一个类应该是一个线性相关性很高的函数的及数据的封装。
2.开闭原则
开闭原则即对修改我们应该是尽量避免的，当我们需要修改时，尽量采用扩展的方式来增加，即使用继承来实现。
3.里氏替换原则
这个也比较好理解，我们在使用基类对象的地方，可以使用扩展或者子类的对象来替换。比如android的window类在show的使用传入的View，在调用它的draw方法，那实际可能是Button、TextView等，这个有点就是代码可以复用、提高了扩展性，但是继承也是侵入性的，并且继承后子类也具有了父类的方法，从而导致代码冗余。
4.依赖倒置原则
这个简单粗暴的解释就是依赖抽象编程，不要依赖细节和实现，这样就会让系统更加灵活。
5.接口隔离原则
接口的颗粒度更小，这样系统的耦合性就更低，从而容易重构、更改。
6.迪米特原则
迪米特又称最少知道原则，简单的来说关我啥事、管你啥事、管他啥事的三不管，即：尽量和别的对象的关联性更低。
二.类之间的关系
1.依赖
对象之间最弱的一种关联方式，是临时性的关联，比如方法的参数、局部变量或者返回值。如下面的A依赖于B,B是A方法中的一个参数,虚线和箭头标识。
class A{
}
class B{
}
2.关联
关联(Association)关系是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系，通常是属性的存在，如汽车和轮胎、师傅和徒弟、班级和学生等等。一般在UML类图中，用实线连接有关联关系的对象所对应的类。关联关系还有以下分类：（ 注：关联关系中作为成员变量的类一般会在类中赋值 ）
1.单向关联
class A{
B b=new B();
}
class B{
}
2.双向关联
class A{
B b=new B();
}
class B{
A a=new A();
}
3.自关联
在系统中可能会存在一些类的属性对象类型为该类本身，这种特殊的关联关系称为自关联。例如：一个节点类(Node)的成员又是节点Node类型的对象
class A{
A a=new A;
}
3.聚合
表示has-a的关系，是一种不稳定的包含关系。较强于一般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。比如说员工和老板，员工可以独立存在，就算是公司倒闭了，员工还可以换工作。如下UML类图所示（注：聚合关系中作为成员变量的类一般使用set方法赋值）
class A{
private B b;
public void setB(B b){
this.b=b;
}
}
class B{}
4.组合
表示contains-a的关系，是一种强烈的包含关系。 组合类负责被组合类的生命周期。是一种更强的聚合关系。部分不能脱离整体存在。如公司和部门的关系，没有了公司，部门也不能存在了；调查问卷中问题和选项的关系；订单和订单选项的关系。在类图使用实心的菱形表示，菱形从局部指向整体。如下UML类图所示：（ 注：组合关系中的成员变量一般会在构造方法中赋值。)
public class A{
private B b;
public A(B b){
this.b=b;
}
}
public class B{
}
5.泛化
简单来说就是继承关系is-a 也是四种关系中耦合度最大的一种，通常我们在绘制UML类图的时候，子类以箭头的方式指向父类.。
class A{
}
class B extends A{}
6.实现
在类图中就是接口和实现的关系。
interface A{
}
class B impleted A{
}
三.设计模式的分类
23中设计模式被划分成三大类：
第一类是 关注对象的创建过程，主要处理对象的实例化问题，将对象的创建和使用分离。这样可以降低系统的耦合度，使得代码更加灵活、可维护和可扩展。 比如单例，构建者；
第二类是结构模式，这类是为了对类进行扩展组合从而形成更大的系统，以实现新的功能和需求，手段通常是组合和扩展方式来优化系统结构， 代理模式为其他对象提供一种代理以控制对这个对象的访问；装饰器模式动态地给一个对象添加一些额外的职责。
第三类是行为模式，关注对象之间的交互和职责分配，主要用于处理对象之间的通信和协作，以及如何在对象之间分配行为。它强调对象之间的消息传递和行为的分配，以实现系统的灵活性和可维护性。比如观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听一个主题对象；策略模式定义一系列的算法，并将每个算法封装起来，使它们可以相互替换。
