随笔分类 - 19-设计模式
摘要：一. 接口隔离原则 1. 定义 一个类对另一个类的依赖应该建立在最小的接口上，不应该依赖他不需要的接口。 通俗的说：要为每个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。 与单一职责原则的区别： (1). 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖
阅读全文
摘要：一. 依赖倒置原则 1. 定义 高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。 通俗的来说：就是面向接口(或抽象类)编程。 补充说明： (1). 依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户端与实现模块之间的耦合。 (2). 由于在软件设计中，细节
阅读全文
摘要：一. 开闭原则 1. 定义 对扩展开放，对修改关闭。(当应用的需求改变时，在不修改软件实体的源代码前提下，可以扩展模块的功能，使其满足新的需求。) 2. 作用 (1). 对软件测试的影响 软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。 (2)
阅读全文
摘要：一. 单例模式 1. 背景 在有些系统中，为了节省内存资源、保证数据内容的一致性，对某些类要求只能创建一个实例，这就是所谓的单例模式。 在计算机系统中，还有 Windows 的回收站、操作系统中的文件系统、多线程中的线程池、显卡的驱动程序对象、打印机的后台处理服务、应用程序的日志对象、数据库的连接池
阅读全文
摘要：一. 观察者模式 1. 背景 在现实世界中，许多对象并不是独立存在的，其中一个对象的行为发生改变可能会导致一个或者多个其他对象的行为也发生改变。例如，某种商品的物价上涨时会导致部分商家高兴，而消费者伤心；还有，当我们开车到交叉路口时，遇到红灯会停，遇到绿灯会行。这样的例子还有很多，例如，股票价格与股
阅读全文
摘要：一. 外观模式 1. 背景 在现实生活中，常常存在办事较复杂的例子，如办房产证或注册一家公司，有时要同多个部门联系，这时要是有一个综合部门能解决一切手续问题就好了。 软件设计也是这样，当一个系统的功能越来越强，子系统会越来越多，客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变，客户端也要跟
阅读全文
摘要：一. 责任链模式 1. 背景 在现实生活中，常常会出现这样的事例：一个请求有多个对象可以处理，但每个对象的处理条件或权限不同。例如，公司员工请假，可批假的领导有部门负责人、副总经理、总经理等，但每个领导能批准的天数不同，员工必须根据自己要请假的天数去找不同的领导签名，也就是说员工必须记住每个领导的姓
阅读全文
摘要：一. 装饰器模式 1. 背景 在现实生活中，常常需要对现有产品增加新的功能或美化其外观，如房子装修、相片加相框等。在软件开发过程中，有时想用一些现存的组件。这些组件可能只是完成了一些核心功能。但在不改变其结构的情况下，可以动态地扩展其功能。所有这些都可以釆用装饰模式来实现。 2. 定义和特点 (1)
阅读全文
摘要：一. 组合模式 1. 背景 在现实生活中，存在很多“部分-整体”的关系，例如，大学中的部门与学院、总公司中的部门与分公司、学习用品中的书与书包、生活用品中的衣月艮与衣柜以及厨房中的锅碗瓢盆等。在软件开发中也是这样，例如，文件系统中的文件与文件夹、窗体程序中的简单控件与容器控件等。对这些简单对象与复合
阅读全文
摘要：一. 值类型和引用类型 1. 前言 (1). 分类 值类型包括：布尔类型、浮点类型(float、double、decimal、byte)、字符类型(char)、整型（int、long、short等）、枚举(entum)、结构体(struct)。 引用类型：数组、字符串(string)、类、接口、委托
阅读全文
摘要：1. 背景 在现实生活中常常遇到实现某种目标存在多种策略可供选择的情况，例如，出行旅游可以乘坐飞机、乘坐火车、骑自行车或自己开私家车等，超市促销可以釆用打折、送商品、送积分等方法。 在软件开发中也常常遇到类似的情况，当实现某一个功能存在多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或
阅读全文
摘要：一. 工厂方法模式 1. 定义和特点 (1). 定义：定义一个创建产品对象的工厂接口，然后把产品对象的实际创建工作放到具体的子类工厂当中实现。 PS： ① 我们把被创建的对象成为“产品”，创建产品的对象称为“工厂”。如果创建的产品不多，且基本不会增加新产品，只需要一个工厂类即可，这种模式叫做“简单工
阅读全文
摘要：一. 什么是设计模式 纠结了好久，今天终于下定决心开始写设计模式系列，因为这个系列章节确实不好写，在这之前，也看了好多关于设计模式的博客、视频、书籍等，最后结合自己的理解，亲自动手实操代码，完成该章节。 我也和我同行的朋友交流了一下关于设计模式，对设计模式的理解，可以分为这么几个层次： ①：根本不知
阅读全文
摘要：1. 背景 在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。 2. 定义 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。 3. 解决方案 当软件需要变化时，尽量通过扩
阅读全文
摘要：1. 背景 类与类之间的关系越密切，耦合度越大，当一个类发生变化时，对另一个类的影响也越大。 2. 定义 一个类应该对其它类保持最少的了解。 3. 解决方法 尽量降低类与类之间的耦合。 4. 迪米特法则的核心 低耦合 5.迪米特法则深究 只与直接的朋友通信。 每个对象都会与其他对象有耦合关系，只要两
阅读全文
摘要：1. 背景 类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类B和类D来说不是最小接口,则类B和类D不得不去实现它们不需要的方法。 2. 定义 一个类对另一个类的依赖应该建立在最小的接口上，不应该依赖他不需要的接口。 3. 解决方案 将臃肿的接口I拆分为独立的几个接口，类A和类C分别于
阅读全文
摘要：1. 背景 类A是高层代码，类A直接依赖B，如果要将类A改为还要依赖C，则必须修改类A的代码来实现。在实际场景中，类A是高层，负责业务逻辑，类B和类C是低层模块，负责基本的原子操作，假如修改A，会给程序带来不必要的风险。 2. 定义 高层模块不直接依赖低层模块，二者都应该依赖其抽象（抽象类或接口），
阅读全文
摘要：1. 背景 有一个功能p1,由类A完成，现在需要将功能p1进行扩展，扩展后的功能为p3，p3由原功能p1和新功能p2组成，而新功能p3和p2均由类A的子类B来完成，子类B在完成新功能p2的同时，可能会导致原有的功能p1故障。 2. 定义 所有引用基类的地方能透明的使用其子类对象进行替代。 3. 对应
阅读全文
摘要：1. 背景 类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。 2. 定义 不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 3. 宏观上 类层次上存在单一职责原则，同样方法层次上也存在单一职责
阅读全文