整体来讲设计模式分为三大类:java
建立型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式算法
结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式编程
行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式设计模式
单例(Singleton)模式:某个类只能生成一个实例,该类提供了一个全局访问点供外部获取该实例,其拓展是有限多例模式。架构
原型(Prototype)模式:将一个对象做为原型,经过对其进行复制而克隆出多个和原型相似的新实例。框架
工厂方法(Factory Method)模式:定义一个用于建立产品的接口,由子类决定生产什么产品。ide
抽象工厂(AbstractFactory)模式:提供一个建立产品族的接口,其每一个子类能够生产一系列相关的产品。函数
建造者(Builder)模式:将一个复杂对象分解成多个相对简单的部分,而后根据不一样须要分别建立它们,最后构建成该复杂对象。学习
代理(Proxy)模式:为某对象提供一种代理以控制对该对象的访问。即客户端经过代理间接地访问该对象,从而限制、加强或修改该对象的一些特性。ui
适配器(Adapter)模式:将一个类的接口转换成客户但愿的另一个接口,使得本来因为接口不兼容而不能一块儿工做的那些类能一块儿工做。
桥接(Bridge)模式:将抽象与实现分离,使它们能够独立变化。它是用组合关系代替继承关系来实现,从而下降了抽象和实现这两个可变维度的耦合度。
装饰(Decorator)模式:动态的给对象增长一些职责,即增长其额外的功能。
外观(Facade)模式:为多个复杂的子系统提供一个一致的接口,使这些子系统更加容易被访问。
享元(Flyweight)模式:运用共享技术来有效地支持大量细粒度对象的复用。
组合(Composite)模式:将对象组合成树状层次结构,使用户对单个对象和组合对象具备一致的访问性。
模板方法(TemplateMethod)模式:定义一个操做中的算法骨架,而将算法的一些步骤延迟到子类中,使得子类能够不改变该算法结构的状况下重定义该算法的某些特定步骤。
策略(Strategy)模式:定义了一系列算法,并将每一个算法封装起来,使它们能够相互替换,且算法的改变不会影响使用算法的客户。
命令(Command)模式:将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。
职责链(Chain of Responsibility)模式:把请求从链中的一个对象传到下一个对象,直到请求被响应为止。经过这种方式去除对象之间的耦合。
状态(State)模式:容许一个对象在其内部状态发生改变时改变其行为能力。
观察者(Observer)模式:多个对象间存在一对多关系,当一个对象发生改变时,把这种改变通知给其余多个对象,从而影响其余对象的行为。
中介者(Mediator)模式:定义一个中介对象来简化原有对象之间的交互关系,下降系统中对象间的耦合度,使原有对象之间没必要相互了解。
迭代器(Iterator)模式:提供一种方法来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示。
访问者(Visitor)模式:在不改变集合元素的前提下,为一个集合中的每一个元素提供多种访问方式,即每一个元素有多个访问者对象访问。
备忘录(Memento)模式:在不破坏封装性的前提下,获取并保存一个对象的内部状态,以便之后恢复它。
解释器(Interpreter)模式:提供如何定义语言的文法,以及对语言句子的解释方法,即解释器。
定义:软件实体应当对扩展开放,对修改关闭,这就是开闭原则的经典定义。是指一个软件实体如类、模块和函数应该对 扩展开放,对修改关闭。所谓的开闭,也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架,用实现扩展细节。能够提升软件系统的可复用性及可维护性。开闭原则,是面向对象设计中最基础的设计原则。
举个例子
咱们销售手机,每一个手机都有它的属性好比:类型、价格、名称,定义了一个接口
public interface IPhone {
String getType(); // 手机类型
Double getPrice(); // 手机价钱
String getName(); // 手机名称
}
复制代码
如今咱们使用苹果手机对他进行实现
public static class ApplePhone implements IPhone {
private String type;
private String name;
private Double price;
ApplePhone(String type, Double price, String name) {
this.type = type;
this.price = price;
this.name = name;
}
@Override
public String getType() {
return type;
}
@Override
public Double getPrice() {
return price;
}
@Override
public String getName() {
return name;
}
}
复制代码
如今咱们进行活动对手机进行打折售出
public static class ActivityApplePhone extends ApplePhone {
ActivityApplePhone(String type, Double price, String name) {
super(type, price, name);
}
@Override
public Double getPrice() { // 违反了里氏替换原则
return super.getPrice() * 0.8;
}
@Override
public String getName() { // 违反了里氏替换原则
return "[优惠~]" + super.getName();
}
}
复制代码
这样咱们能够不修改原来的代码上扩展了活动中苹果的类,还能够经过实现 IPhone
类来添加更多类型的手机的属性。
定义:继承必须确保超类所拥有的性质在子类中仍然成立。里氏替换原则主要阐述了有关继承的一些原则,也就是何时应该使用继承,何时不该该使用继承,以及其中蕴含的原理。里氏替换原是继承复用的基础,它反映了基类与子类之间的关系,是对开闭原则的补充,是对实现抽象化的具体步骤的规范。
补充:里氏替换原则里
举个例子:
仍是上面的例子,咱们从里氏替换原则出发现问题 子类能够扩展父类的功能,但不能改变父类原有的功能
,咱们的上面的例子很简单发现违反了这个原则。
修改:
public static class ActivityApplePhone extends ApplePhone {
ActivityApplePhone(String type, Double price, String name) {
super(type, price, name);
}
public Double getActivityPrice() {
return super.getPrice() * 0.8;
}
public String getActivityName() {
return "[优惠~]" + super.getName();
}
}
复制代码
定义:要面向接口编程,不要面向实现编程。
因为在软件设计中,细节具备多变性,而抽象层则相对稳定,所以以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类,而细节是指具体的实现类。使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操做,把展示细节的任务交给它们的实现类去完成。
举个例子:
用户购物,若是用户想购买物品 C 则没法实现,由于里面没有购买 物品 C 的动做。若是随意改变代码很容出现问题。
public static class User {
public void shoppingGoodsA(){
System.out.println("购买商品 -- A");
}
public void shoppingGoodsB() {
System.out.println("购买商品 -- B");
}
}
复制代码
咱们改变一下,以下...
public static class User {
public void shoppingGoods(IGoods goods){
goods.shopping();
}
}
interface IGoods {
void shopping();
}
public static class GoodsA implements IGoods {
@Override
public void shopping() {
System.out.println("购买商品 -- A");
}
}
public static class GoodsB implements IGoods {
@Override
public void shopping() {
System.out.println("购买商品 -- B");
}
}
复制代码
用户不管怎么购物均可以,知足用户的需求,并且不须要对原来的代码修改..
下面使用 构造注入 和 set 注入购买的商品
// 构造注入
public static class User {
private IGoods goods;
User(IGoods goods) { // 构造注入
this.goods = goods;
}
public void shoppingGoods() {
if (goods != null) goods.shopping();
}
}
// 运行
User userA = new User(new GoodsA());
userA.shoppingGoods();
User userB = new User(new GoodsB());
userB.shoppingGoods();
复制代码
// set 注入
public static class User {
private IGoods goods;
public void setGoods(IGoods goods) {
this.goods = goods;
}
public void shoppingGoods() {
if (goods != null) goods.shopping();
}
}
// 运行
User u = new User();
u.setGoods(new GoodsA());
u.shoppingGoods();
u.setGoods(new GoodsB());
u.shoppingGoods();
复制代码
定义:单一职责原则又称单一功能原则,这里的职责是指类变化的缘由,单一职责原则规定一个类应该有且仅有一个引发它变化的缘由,不然类应该被拆分。该原则提出对象不该该承担太多职责,若是一个对象承担了太多的职责,至少存在如下两个缺点:[1] 一个职责的变化可能会削弱或者抑制这个类实现其余职责的能力;[2] 当客户端须要该对象的某一个职责时,不得不将其余不须要的职责全都包含进来,从而形成冗余代码或代码的浪费。
举个例子
咱们购买商品或者退款商品,以及查看商品信息均可以属于和商品的操做,可是根据单一职责原则应该分为 商品信息 和 商品操做 两个接口, 商品信息接口能够扩展吧商品的类型 颜色 状态 等描述清楚,而商品的操做类,只用关注商品的购买和退款两个操做。
public interface IGoods {
void getInfo();
void purchase();
void refund();
}
复制代码
改变为
public interface IGoodsInfo {
void getInfo();
}
public interface IGoodsOperation {
void purchase();
void refund();
}
复制代码
定义: 客户端不该该被迫依赖于它不使用的方法。该原则还有另一个定义:一个类对另外一个类的依赖应该创建在最小的接口上。以上两个定义的含义是:要为各个类创建它们须要的专用接口,而不要试图去创建一个很庞大的接口供全部依赖它的类去调用。接口隔离原则和单一职责都是为了提升类的内聚性、下降它们之间的耦合性,体现了封装的思想,但二者是不一样的: 单一职责原则注重的是职责,而接口隔离原则注重的是对接口依赖的隔离。单一职责原则主要是约束类,它针对的是程序中的实现和细节;接口隔离原则主要约束接口,主要针对抽象和程序总体框架的构建。
举个例子
若是对购买/退货商品分析,发现商品的购买的动做实际上是 库存减小,销售额增长。退货同理~
public interface IGoodsOperation {
void purchase();
void refund();
}
interface IDepot {
void increase();
void reduce();
}
interface IMoney {
void increase();
void reduce();
}
复制代码
定义:迪米特法则又叫做最少知识原则,若是两个软件实体无须直接通讯,那么就不该当发生直接的相互调用,能够经过第三方转发该调用。其目的是下降类之间的耦合度,提升模块的相对独立性。迪米特法则中的“第三方”是指:当前对象自己、当前对象的成员对象、当前对象所建立的对象、当前对象的方法参数等,这些对象同当前对象存在关联、聚合或组合关系,能够直接访问这些对象的方法。
举个例子:
在购买完物品后去付款,你去扫码支付的时候,扫码支付关系的多少钱,而不是你买了什么,因此对于支付来讲物品他不关心。因此经过购物清单获得购物的最后价格。
public static class GoodModel {
private String name;
private Double price;
private Integer num;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Double getPrice() {
return price;
}
public void setPrice(Double price) {
this.price = price;
}
public Integer getNum() {
return num;
}
public void setNum(Integer num) {
this.num = num;
}
}
public static class GoodsList {
List<GoodModel> list = new ArrayList<>();
Double getCountPrice () {
double countPrice = 0.0;
for (GoodModel goodModel : list) {
countPrice += goodModel.getPrice() * goodModel.getNum();
}
return countPrice;
}
}
public static class Payment {
private GoodsList goodsList;
public Payment() {
}
public Payment(GoodsList goodsList) {
this.goodsList = goodsList;
}
public void run() {
System.out.println("支付 --- " + goodsList.getCountPrice());
}
}
复制代码
定义:又叫组合/聚合复用原则。它要求在软件复用时,要尽可能先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现。若是要使用继承关系,则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的,二者都是开闭原则的具体实现规范。
举个例子:
购买笔记本,如今有笔记本种类 得力和晨光 两种。 每种里面都有 规格A 规格B 规格C,若是是继承者违背了 里氏替换原则。经过注入想要的类型,从而复用公共的部分。
public static abstract class Book {
private BookType type;
public Book(BookType type) {
this.type = type;
}
public abstract String brand();
public final void purchase() {
System.out.println("购买--品牌:" + this.brand() + "类型:" + type.toType());
}
}
public interface BookType {
String toType();
}
public class BookTypeA implements BookType {
@Override
public String toType() {
return "Type_A";
}
}
public static class BookTypeB implements BookType {
@Override
public String toType() {
return "Type_B";
}
}
public static class BookTypeC implements BookType {
@Override
public String toType() {
return "Type_C";
}
}
public static class DeliBook extends Book {
public DeliBook(BookType type) {
super(type);
}
@Override
public String brand() {
return "Deli";
}
}
public class ChenGuangBook extends Book {
public ChenGuangBook(BookType type) {
super(type);
}
@Override
public String brand() {
return "ChenGuang";
}
}
复制代码
这 7 种设计原则是软件设计模式必须尽可能遵循的原则,各类原则要求的侧重点不一样。其中,开闭原则是总纲,它告诉咱们要对扩展开放,对修改关闭;里氏替换原则告诉咱们不要破坏继承体系;依赖倒置原则告诉咱们要面向接口编程;单一职责原则告诉咱们实现类要职责单一;接口隔离原则告诉咱们在设计接口的时候要精简单一;迪米特法则告诉咱们要下降耦合度;合成复用原则告诉咱们要优先使用组合或者聚合关系复用,少用继承关系复用。
学习设计原则,学习设计模式的基础。在实际开发过程当中,并非必定要求全部代码都遵循设计原则,咱们要考虑人力、时间、成本、质量,不是刻意追求完美,要在适当的场景遵循设计原则,体现的是一种平衡取舍,帮助咱们设计出更加优雅的代码结构。