【设计模式】设计模式总览

设计模式

1. 创建型模式(6种)

创建对象时,不再由我们直接实例化对象;而是根据特定场景,由程序来确定创建对象的方式,从而保证更大的性能、更好的架构优势。

  • 简单工厂模式(不是之一)

  • 工厂方法模式

  • 抽象工厂模式

  • 原型模式

  • 建造者模式

  • 单例模式

2. 结构型模式(7种)

用于帮助将多个对象组织成更大的结构。

  • 外观模式

  • 适配器模式

  • 代理模式

  • 装饰模式

  • 桥接模式

  • 组合模式

  • 享元模式

3.行为型模式(11种)

用于帮助系统间各对象的通信,以及如何控制复杂系统中流程。

  • 模版方法模式

  • 观察者模式

  • 状态模式

  • 策略模式

  • 职责链模式

  • 命令模式

  • 访问者模式

  • 调停者模式

  • 备忘录模式

  • 迭代器模式

  • 解释器模式

设计模式六大原则

单一职责原则
一个类=只有一个引起它变化的原因。

如果一个类承担的职责过多,即耦合性太高=一个职责的变化可能会影响到其他的职责

开放封闭原则
一个实体(类、函数、模块等)应该对外扩展开放,对内修改关闭

  1. 即每次发生变化时,要通过添加新的代码来增强现有类型的行为,而不是修改原有的代码。
  2. 符合开放封闭原则的最好方式是提供一个固有的接口,然后让所有可能发生变化的类实现该接口,让固定的接口与相关对象进行交互。

里氏代替原则
子类必须替换掉它们的父类型。

  1. 在软件开发过程中,子类替换父类后,程序的行为是一样的。
  2. 只有当子类替换掉父类后软件的功能不受影响时,父类才能真正地被复用,而子类也可以在父类的基础上添加新的行为。

依赖倒置原则
细节应该依赖于抽象,而抽象不应该依赖于细节。

所谓的的 “面向接口编程,而不是面向实现编程”。这样可以降低客户与具体实现的耦合。

接口隔离原则

使用多个专门功能的接口,而不是使用单一的总接口。

不要让一个单一的接口承担过多的职责,而应把每个职责分离到多个专门的接口中,进行接口分离。

合成复用原则

在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分。

新对象通过向这些对象的委派达到复用已用功能的目的。简单地说,就是要尽量使用合成/聚合,尽量不要使用继承。

最少知识原则(迪米特法则)

一个模块或对象应尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立,这样当一个模块修改时,影响的模块就会越少,扩展起来更加容易。

  1. 关于迪米特法则的其他描述:只与你直接的朋友们通信;不要跟“陌生人”说话。
  2. 外观模式(Facade Pattern)和中介者模式(Mediator Pattern)就使用了迪米特法则。

原文地址:https://www.cnblogs.com/yeyang/p/9357591.html

时间: 2024-10-18 22:49:15

【设计模式】设计模式总览的相关文章

设计模式——设计模式与设计原则

设计模式--设计模式与设计原则 一.设计模式  1.设计模式简介 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石. 模式的经典定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,我们可以无数次地重用那些已有的解决方案,无需再

[设计模式]设计模式

在进行控件封装时,通常会定义一个通用操作的接口,只要满足此接口,都可以使用控件承载其功能,但是当需要扩展控件基本功能的时候,难免会在此接口中添加其他的定义,那么实现了此接口的所有类定义都必须的添加新的方法,改动非常大. 通常的做法是使用一个抽象类实现此接口,其他需要扩展此接口的类都继承自此抽象类,而非直接继承接口本身,这样就算接口添加再多的方法,只需要在抽象类中添加对应方法即可,不影响子类. 伪代码描述: interface CustomeViewInterface { void Click()

Python设计模式 - UML - 总览

说到设计模式就不得不涉及建模思想,说到建模思想自然而然会应用UML,目前业界开源的UML工具很多,用起来也非常便捷.近几年来随着软件应用领域开发模式转向快速迭代试错,UML在敏捷开发,尤其是web及mobile开发领域应用越来越少. 就国内软件行业发展现状来说,稳定成熟的商业软件凤毛麟角,初具雏形的互联网App大行其道,竞争中的公司更看重的是快速占领市场,小团队快速迭代试错,而不是长期.精心打磨同一款软件产品,所以注重统一规范.充分需求分析.严密框架设计的UML显得相对繁琐,自然会被灵活敏捷的各

100设计模式总结--总览

设计模式七大原则 设计模式分类:复述每种设计模式 按语言区分使用领域 最后总结: 业务领域如何使用 原文地址:https://www.cnblogs.com/gcq243627152qq/p/12000215.html

小菜学设计模式——设计模式总结之结构型

1.设计模式总结 设计模式总共23个,但是常用的不到10个,下面就把这23个设计模式进行整理归类,具体如下: 1)创建型模式,共五种:工厂方法模式.抽象工厂模式.单例模式.建造者模式.原型模式. 2)结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接模式.组合模式.享元模式. 3)行为型模式,共十一种:策略模式.模板方法模式.观察者模式.迭代器模式.职责链模式.命令模式.备忘录模式.状态模式.访问者模式.中介者模式.解释器模式 2.结构型设计模式 1)适配器模式:将一个类的接口

小菜学设计模式——设计模式总结之创建型

1.面向过程与面向对象 1)面向过程通过划分功能模块,通过函数间相互调用来实现,但需求变化时就需要更改函数,而你改动的函数有多少地方在调用她呢?关联多少数据,这是很不容易弄得清楚地地方.或许开发者本人弄得清楚,但是下一个维护人员未必能够吃透.所以,由于这种强耦合性直接导致程序的扩展性和可维护性降低,后期维护的成本自然增高了不少. 2)面向对象关注的是对象,对象的优点在于,可以定义自己负责的事务,做要求它自己做的事情.对象应该自己负责自己,而且应该清楚的定义责任. 3)一般面向对象开发只是关心这么

Java设计模式-设计模式的六种原则

所谓无招胜有招,练一门功夫分为内功和外功. 外功好比招式,就是所谓的23种设计模式.而内功呢,就是心法,那就是这6种法则.光会外功那是花拳绣腿,内功修为才是境地. 如此众多的设计模式,学完2遍.3遍可能也会忘的仅仅记得单例和工厂模式.可是仅仅要原则记住,在以后的设计中,有意无意就会用的设计模式的精髓. 六种设计原则 单一职责原则 不要存在多于一个导致类变更的原因.通俗的说,即一个类仅仅负责一项职责.  问题由来:类T负责两个不同的职责:职责P1,职责P2. 当因为职责P1需求发生改变而须要改动类

设计模式——设计模式总结

     设计模式总结 设计模式(Design Patterns)是可复用面向对象软件的基础,是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码,让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样.项目中合理的运用设计模式可以完美的解决很多问题,每种模式在现在中都有相应的原理来与之对应,每一个模式描述了一个在我们周围不断重复发生的问题

GOF业务场景的设计模式-----设计模式六大原则

单一职责原则(Single Responsibility Principle) 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风

设计模式——设计模式之禅day2

接口隔离原则 接口分为两种: ● 实例接口( Object Interface) , 在Java中声明一个类, 然后用new关键字产生一个实例, 它是对一个类型的事物的描述, 这是一种接口. 比如你定义Person这个类, 然后使用Person zhangSan=new Person()产生了一个实例, 这个实例要遵从的标准就是Person这个类, Person类就是zhangSan的接口. 疑惑? 看不懂? 不要紧, 那是因为让Java语言浸染的时间太长了, 只要知道从这个角度来看, Java