深入浅出软件设计模式
文章平均质量分 82
软件设计模式的点点滴滴
airycode
走自己的路让别人说去把
展开
-
设计模式之装饰器模式
动态(组合)地给一个对象增加一些额外的职责。就增加功能而言,Decorator模式比生成子类(继承)更为灵活(消除重复代码 & 减少子类个数)。通过采用组合而非继承的手法, Decorator模式实现了在运行时 动态扩展对象功能的能力,而且可以根据需要扩展多个功能。避免 了使用继承带来的“灵活性差”和“多子类衍生问题”。Decorator类在接口上表现为is-a Component的继承关系,即 Decorator类继承了Component类所具有的接口。原创 2024-05-07 14:57:42 · 824 阅读 · 0 评论 -
设计模式之策略模式
定义一系列算法,把它们一个个封装起来,并且使它们可互相替换(变化)。该模式使得算法可独立于使用它的客户程序(稳定)而变化(扩展,子类化)。Strategy及其子类为组件提供了一系列可重用的算法,从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。Strategy模式提供了用条件判断语句以外的另一种选择,消除条件判断语句,就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。如果Strategy对象没有实例变量,那么各个上下文可以共享同一个。原创 2024-04-29 16:12:21 · 344 阅读 · 0 评论 -
设计模式之模板方法
Template Method模式是一种非常基础性的设计模式,在面向对象系统中有着大量的应用。它用最简洁的机制(虚函数的多态性)为很多应用程序框架提供了灵活的扩展点,是代码复用方面的基本实现结构。虚函数的多态性:虚函数的多态性可以理解为一种机制,通过该机制,程序在运行时能够基于对象的实际类型来选择调用哪个函数版本,而不是在编译时确定Java中的虚函数允许子类重写(Override)继承自父类的方法,从而实现多态性(polymorphism)原创 2024-04-29 09:16:51 · 898 阅读 · 2 评论 -
设计模式之创建型模式总结
定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法模式使得一个类的实例化延迟(目的:解耦)到子类。提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类使用原型实例指定创建对象的种类,然后通过拷贝这些原型来对象。将一个复杂对象的构建与其表示相分离,使得同样的构建过程(稳定)可以创建不同的表示(变化)值对象模式一种在面向对象编程中常见的设计模式,它主要用于封装一组值,使其可以通过值进行比较来判断两个对象是否是同一个对象。而不是通过引用来判断。原创 2024-04-25 14:36:38 · 1279 阅读 · 0 评论 -
设计模式之值对象模式
值对象模式一种在面向对象编程中常见的设计模式,它主要用于封装一组值,使其可以通过值进行比较来判断两个对象是否是同一个对象。而不是通过引用来判断。原创 2024-04-25 14:35:21 · 255 阅读 · 0 评论 -
设计模式之原型设计模式
Prototype 模式同样用于隔离类对象的使用者和具体类型(易变类)之间的耦合关系,它同样要求这些“易变类”拥有“稳定的接口”Prototype 模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做,使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象 — 所需工作仅仅是注册一个新类的对象(即原型),然后在任何需要的地方 clonePrototype 模式中的 clone 方法可以利用某些框架中的序列化来实现深拷贝。原创 2024-04-25 14:26:46 · 1065 阅读 · 0 评论 -
设计模式之分步构建模式
(分步构建模式)是一种创建型设计模式,它是链式建造者模式的进一步扩展,能够按步骤实例化对象通过分离稳定部分和变化部分,分步构建模式提供了一种灵活的方式来构建复杂对象。稳定部分保证了构建过程的稳定性和一致性,而变化部分则允许用户根据具体需求来定制构建过程。这种分离使得代码更加清晰、可维护和可扩展。原创 2024-04-25 14:05:39 · 504 阅读 · 2 评论 -
设计模式之建造者模式
Builder模式主要用于"分布构建一个复杂的对象",在这其中"分步骤"是一个稳定的算法,而复杂对象的各个部分则经常变化。变化点在哪里,封装哪里;Builder模式主要在于应对"复杂对象各个部分"的频繁需求变动。其缺点在于难以应对"分步骤构建算法"的需求变动。原创 2024-04-25 13:55:55 · 531 阅读 · 0 评论 -
设计模式之依赖注入模式
依赖注入是一种软件设计模式,其中一个或多个依赖项(或服务)被注入或通过引用传递到一个依赖对象(或客户端)中,并成为客户端状态的一部分。该模式将客户的依赖关系的创建与其自身的行为分开,这使程序设计可以松散耦合,并遵循控制反转和单一职责原则。原创 2024-04-25 11:20:11 · 1158 阅读 · 1 评论 -
设计模式之抽象工厂模式
提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类如果没有应对"多系列对象构建"的需求的变化,则没有必要使用抽象工厂模式,这时候使用简单工厂完全可以"系列对象"指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖抽象工厂模式主要在于应对"新系列"的需求变动。其缺点在于难以应对"新对象"的需求变动。原创 2024-04-25 10:26:40 · 820 阅读 · 0 评论 -
设计模式之工厂套件模式
工厂套件模式定义是:提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。原创 2024-04-25 09:54:34 · 246 阅读 · 2 评论 -
设计模式之工厂方法
定义一个用于创建对象的接口,让子类决定实例化哪一个类。原创 2024-04-19 18:14:32 · 295 阅读 · 0 评论 -
设计模式之简单工厂
提供一个创建对象实例的功能,而无须关心具体实现。被创建的实例的可以是接口、抽象类、也可以是具体的类。原创 2024-04-19 18:12:59 · 676 阅读 · 0 评论 -
设计模式之转换器模式
转换器模式的目的是提供相应类型之间双向转换的通用方法,允许进行干净的实现,而类型之间无需相互了解。此外,Converter模式引入了双向集合映射,从而将样板代码减少到最少。原创 2024-04-19 18:10:24 · 258 阅读 · 0 评论 -
设计模式之单例模式
确保一个类只有一个实例,并为其提供一个全局的访问点。原创 2024-04-19 18:08:54 · 754 阅读 · 0 评论 -
05.设计原则之合成复用原则
合成复用原则就是指在一个新的对象里通过关联关系(包括组合关系和聚合关系)来使用一些已有的对象,使之成为新对象的一部分;新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简而言之:要尽量使用组合/聚合关系,少用继承。在面向对象设计中,可以通过两种基本方法在不同的环境中复用已有的设计和实现,即通过组合/聚合关系或者通过继承。继承可能是类之间最明显、最简便的代码复用方式。如果你有两个代码相同的类,就可以为它们创建一个通用的基类,然后将相似的代码移到其中有效的使用继承会有助于对问题的理解,降低复杂度,原创 2024-03-15 16:13:55 · 394 阅读 · 0 评论 -
04.设计原则之依赖倒置原则
依赖倒置原则概念是高层次模块不依赖于低层次模块。看似在要求高层次模块,实际上是在规范低层次模块的设计。低层次模块提供的接口要足够的抽象、通用,在设计时需要考虑高层次模块的使用种类和场景。明明是高层次模块要使用低层次模块,对低层次模块有依赖性。现在反而低层次模块需要根据高层次模块来设计,出现了「倒置」的显现。原创 2024-03-15 08:11:25 · 387 阅读 · 0 评论 -
03.设计原则之开闭原则
开闭原则(Open-Closed Principle, OCP):一个软件实体(模块、类、方法)应当对扩展开放,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。即实现在不修改源代码的情况下改变这个模块的行为这个描述比较抽象,我们详细描述一下,那就是,添加一个新的功能应该是,在已有的代码基础上扩展代码(新增模块、类、方法等)而非修改已有代码(修改模块、类、方法)为了让你更好的理解这个原则,我举一个简单的例子进一步解释。多态依赖注入基于接口编程。原创 2024-03-14 13:04:42 · 373 阅读 · 0 评论 -
02.设计原则之里氏替换原则
通过上面的学习和分析,我们再来看一下里氏替换更具有意义的定义:按照协议来设计,子类在设计的时候,要遵守父类的行为约定/协议。父类定义了函数的行为约定,那子类可以改变函数的内部实现逻辑,但不能改变函数原有的行为约定。行为约定包括:函数声明要实现的功能;对输入、输出、异常的约定;注释中所罗列的特殊说明。原创 2024-03-13 14:57:49 · 830 阅读 · 0 评论 -
01.设计原则之接口隔离原则
单一职责原则针对的是模块、类、接口的设计。接口隔离的原则相对于单一职责原则,一方面更侧重于接口的最小化设计,另一方面更侧重于接口使用的精确性接口隔离原则提供了一种判断接口职责是否单一的标准:通过调用者如何使用接口来间接判定,如果调用者只使用了部分接口或接口的部分功能那么接口设计的就不够职责单一与其他原则一样,你可能会过度使用这条原则。不要进一步划分已经非常具体的接口。记住,创建的接口越多,代码就越复杂。因此要保持平衡。一般来说接口中仅包含某业务模块的方法即可,不应该有其他业务模块的方法。原创 2024-03-13 11:00:59 · 1197 阅读 · 0 评论 -
00.设计原则之单一职责原则
如何理解单一职责原则一个类只负责完成一个职责或者功能。不要设计大而全的类,要设计粒度小,功能单一的类。单一职责原则是为了实现代码高内聚、低耦合,提高代码的复用性、可读性、可维护性如何评判类的职责是否足够单一不同的应用场景、不同阶段的需求背景、不同的业务层面,对同一个类的职责是否单一,可能会有不同的判定结果。实际上,一些侧面的判断指标更具有指导意义和可执行性,比如下面的这些情况有可能说明类设计的不满足单一职责原则①类中的代码行数、函数、或者属性过多。原创 2024-03-05 14:49:26 · 961 阅读 · 0 评论