介绍 设计模式中的SOLID原则,分别是单一原则.开闭原则.里氏替换原则.接口隔离原则.依赖倒置原则.前辈们总结出来的,遵循五大原则可以使程序解决紧耦合,更加健壮. SRP 单一责任原则 OCP 开放封闭原则 LSP 里氏替换原则 ISP 接口隔离原则 DIP 依赖倒置原则 单一责任原则 指的是一个类或者一个方法只做一件事.如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化就可能抑制或者削弱这个类完成其他职责的能力.例如餐厅服务员负责把订单给厨师去做,而不是服务员又要订单又要炒

给定一个语言, 定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子.角色:环境角色(PlayContent):定义解释规则的全局信息.抽象解释器(Empress):定义了部分解释具体实现,封装了一些由具体解释器实现的接口.具体解释器(MusicNote):实现抽象解释器的接口,进行具体的解释执行. 应用实例:编译器.运算表达式计算. 优点: 1.可扩展性比较好,灵活. 2.增加了新的解释表达式的方式. 3.易于实现简单文法. 缺点: 1.可利用场景比较少. 2.对于复

备忘录模式 备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象.备忘录模式属于行为型模式. 介绍 意图:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态. 主要解决:所谓备忘录模式就是在不破坏封装的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,这样可以在以后将对象恢复到原先保存的状态. 何时使用:很多时候我们总是需要记录一个对象的内部状态,这样做的目的就是为了允许用户取消不确定或者错误的操作,能够恢复到他原先的状态

命令模式 将一个请求封装为一个对象,从而使用户可用不同的请求对客户进行参数化.对请求排队或记录请求日志,以及支持撤销的操作. 命令模式以松散耦合主题为基础,发送消息.命令和请求,或通过一组处理程序发送任意内容.每个处理程序都会自行判断自己能否处理请求.如果可以,该请求被处理,进程停止.您可以为系统添加或移除处理程序,而不影响其他处理程序. 命令模式的四种角色: 1. 接收者(Receiver)负责执行与请求相关的操作 2. 命令接口(Command)封装execute().undo()等方法 3

迭代器模式 迭代器模式 (Iterator),又叫做游标(Cursor)模式.提供一种方法访问一个容器(Container)对象中各个元素,而又不需暴露该对象的内部细节. 当你需要访问一个聚合对象,而且不管这些对象是什么都需要遍历的时候,就应该考虑使用迭代器模式.另外,当需要对聚集有多种方式遍历时,可以考虑去使用迭代器模式.迭代器模式为遍历不同的聚集结构提供如开始.下一个.是否结束.当前哪一项等统一的接口. php标准库(SPL)中提供了迭代器接口 Iterator,要实现迭代器模式,实现该接口

一.工厂模式的介绍       工厂模式让我们相到的就是工厂,那么生活中的工厂是生产产品的,在代码中的工厂是生产实例的,在直白一点就是生产实例的类,代码中我们常用new关键字,那么这个new出来的实例就就依赖与这个类,2者之间的耦合度就高,此时我们就可以使用面向对象的去解决这个问题,将变化点封装起来,这就是我们将要首先引入的简单工厂模式:先来说一个场景,比如我们吃水果这个例子吧,我们有时候想吃苹果,有时候想吃橘子,但是每次都需要去买这些水果,后来有个水果店,又卖橘子,又卖苹果,这个水果店就当于简

一.建造模式的介绍       建造者模式就是将零件组装成一个整体,用官方一点的话来讲就是将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示.生活中比如说组装电脑,汽车等等这些都是建造者模式的具体体现,组装电脑反应到软件上就是一个复杂的对象,然后我们使用建造者模式的时候需要抽象一个建造类,抽象一个指挥者指挥具体实现的那个类,然后就是具体实现这个对象的类,这样就避免了每新创建一个不同的复杂对象就需要重新写一下这个类,这样就只要重写建造者就可以了,我们接下来就用组装电脑这个来说明一

一.代理模式的介绍       代理模式我们脑袋里出现第一个词语就是代购,其实就是这样通过一个中间层这个中间成是属于什么都干什么都买得,俗称"百晓生",在平时得开发中我们经常会听到什么远程代理,虚拟代理等等这一些都是代理模式得具体例子,来个官方定义就是给某一个对象提供一个代理,并由代理对象控制对原对象的引用:下面我们用代购的例子来说明一下这个情况:你想买一台iphone,国行有点贵,然后拜托海外的朋友买一台给你带回来,就是这样的一个例子,首先我们先将买东西这个主题抽象出来,然后再把真实

Prototype模式是提供自我复制的功能.包括浅拷贝和深拷贝. 一.Prototype模式的用途 场景1:游戏场景中有很多类似的敌人,它们的技能都一样,但是随着敌人出现的位置和不同,它们的能力也不太一样.那么,可以创建一个敌人抽象类,然后对于不同能力的步兵创建不同的子类.然后,使用工厂模式让调用方依赖敌人抽象类.问题来了,如果有无数种能力不同的步兵,难道需要创建无数子类吗?还有步兵模式的初始化工作比较耗时,创建这么多步兵对象可能会浪费更多的时间.我们是不是只创建一个步兵模式,然后复制出更多的一

—————————— ASP.Net+Android+IOS开发..Net培训.期待与您交流! —————————— 享元模式: Flyweight模式的有效性很大程度上取决于如何使用它以及在何处使用它.当以下情况成立时使用Flyweight模式:1 一个应用程序使用了大量的对象.2 完全由于使用大量的对象,造成很大的存储开销.3 对象的大多数状态都可以变为外部状态.4 如果删除对象以外的状态那么可以用相对较少的共享对象取代很多组对象.5 应用程序不依赖于对象标识. 使用享元模式 前 使用享元模

桥接模式 概述:将抽象部分与他的实现部分分离,这样抽象化与实现化解耦,使他们可以独立的变化.如何实现解耦的呢,就是通过提供抽象化和实现化之间的桥接结构.    应用场景        实现系统可能有多个角度分类,每一种角度都可能变化.    解释:桥接模式将继承模式转化成关联关系,他降低了类与类之间的耦合度,减少了系统中类的数量,也减少了代码量.    理解抽象化,实现化,解耦        抽象化:将复杂物体的一个或几个共同的特性抽出去而只注意其他特性的行动或过程.在java面向对象中抽象化就

场景和本质 场景 本质 案例 原理 应用场景 场景和本质 场景 我们要建造一个复杂的产品.比如:神州飞船,Iphone.这个复杂的产品的创建.有这样一个问题需要处理:装配这些子组件是不是有个步骤问题? 实际开发中,我们所需要的对象构建时,也非常复杂,有很多步骤需要处理时. 本质 分离了对象子组件的单独构造(由Builder来负责)和装配(由Director负责). 从而可以构造出复杂的对象.这个模式适用于:某个对象的构建过程复杂的情况下使用. 由于实现了构建和装配的解耦.不同的构建器,相同的装配

摘要:本文主要聚焦在结构型模式(Structural Pattern)上,其主要思想是将多个对象组装成较大的结构,并同时保持结构的灵活和高效,从程序的结构上解决模块之间的耦合问题. 本文分享自华为云社区<快来,这里有23种设计模式的Go语言实现(二)>,原文作者:元闰子. 本文主要聚焦在结构型模式(Structural Pattern)上,其主要思想是将多个对象组装成较大的结构,并同时保持结构的灵活和高效,从程序的结构上解决模块之间的耦合问题. 组合模式(Composite Pattern)

摘要:针对这种对象成员较多,创建对象逻辑较为繁琐的场景,非常适合使用建造者模式来进行优化. 本文分享自华为云社区<[Go实现]实践GoF的23种设计模式:建造者模式>,作者: 元闰子. 简述 在程序设计中,我们会经常遇到一些复杂的对象,其中有很多成员属性,甚至嵌套着多个复杂的对象.这种情况下,创建这个复杂对象就会变得很繁琐.对于 C++/Java 而言,最常见的表现就是构造函数有着长长的参数列表: MyObject obj = new MyObject(param1, param2, para

摘要:装饰者模式通过组合的方式,提供了能够动态地给对象/模块扩展新功能的能力.理论上,只要没有限制,它可以一直把功能叠加下去,具有很高的灵活性. 本文分享自华为云社区<[Go实现]实践GoF的23种设计模式:装饰者模式>,作者: 元闰子. 简介 我们经常会遇到"给现有对象/模块新增功能"的场景,比如 http router 的开发场景下,除了最基础的路由功能之外,我们常常还会加上如日志.鉴权.流控等 middleware.如果你查看框架的源码,就会发现 middleware

[放弃了原文访问者模式的Demo,自己写了一个新使用场景的Demo,加上了自己的理解] [源码地址:https://github.com/leon66666/DesignPattern] 一.设计模式的分类 总体来说设计模式分为三大类: 创建型模式,共五种:工厂方法模式.抽象工厂模式.单例模式.建造者模式.原型模式. 结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接模式.组合模式.享元模式. 行为型模式,共十一种:策略模式.模板方法模式.观察者模式.迭代子模式.责任链模式.命

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

.NET设计模式: 工厂模式(转) 转自:http://www.cnblogs.com/bit-sand/archive/2008/01/25/1053207.html   .NET设计模式(1): 简单工厂模式 最近一直在看设计模式,想把自己的学习笔记与大家分享一下,如果能帮助大家的话,我会非常高兴,同时也欢迎大家指出里面的不足.园子里其实关于此类文章已经很多了,如果dudu感觉放在首页欠妥的话,可以调一下. 简单工厂模式(Simple Factory Pattern) 介绍:简单工厂模式不能

一.为何需要单件模式 需求 我们开发了一个大型的项目,其中存在许多的工具类.但是其中很多的工具类我们并不是经常使用得到,甚至 一次都不会使用.但是这些工具类都是静态的类,会消耗很多的内存,即使一次都不使用.这个时候我们需要一种 方式可以解决这个问题.意指只有我们使用到这个工具类的时候才实例化,并且在以后的使用中总是返回首次实例 化的对象而不是重复的实例化新的对象. 方案 我们采取的方案是将类默认的构造方法设置为保护类型,这样使用者就无法直接实例化这个类,然后我们在公开一 个静态的方法,用于将本身

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

内容大纲 如何存储记录 备忘录模式的基本原理 使用备忘录模式 优化存储方案 恢复UIView的状态 1.如何存储记录 在存储记录时,第一步我们需要用一把钥匙去打开一把锁.第二步,当我们打开锁之后就会有黑盒子,我们一开始还不知道里面有什么,所以是黑盒子. 1.存储记录的必要性 生活中,比如去超市购物有时候就需要在入口储物柜存放自己的包裹 2.记录的唯一标示 储物柜对应一把钥匙和号码标示. 3.存储记录与取出记录 ===========================================