软件设计模式
文章平均质量分 94
以通用的23种设计模式为基准进行探索和学习
存在morning
乐于了解新技术,善于复盘总结,不是很聪明,但能够持续进步。
展开
-
【Java设计模式 前言】我为什么要学习设计模式
中级人员的心智“或许这里我需要一个单件模式。悟道者的心智能够看到模式在何处能够自然融人。悟道者的心智并不急切于使用模式,而是致力于最能解决问题的简单方案。悟道者的心智会考虑对象的原则,以及它们之间的折衷。当对模式的需要自然出现时,悟道者的心智就拿捏得宣地采用模式。悟道者的心智也能看到相似模式之间的关系,以及它们在意图上的微妙差异。悟道者的心智也同于初学者的心智-不会让这此模式的知识过度影响设计的决策。原创 2022-03-06 17:04:35 · 559 阅读 · 0 评论 -
【Java设计模式 学习目标及大纲】高质量代码的标准及实现路径
易维护、易读、易扩展、灵活、简洁、可复用、可测试的代码就是高质量的代码,而高质量代码的达成路径工具箱包括:面向对象设计思想是基本指导思想,是很多设计原则、设计模式的实现基础;设计原则是代码设计的抽象经验总结、是设计模式设计的指导原则;设计模式是代码设计的一套具体解决方案或设计思路,主要用来提高代码可扩展性;编程规范是一套可执行的代码编写规范,主要用来提高代码的可读性;代码重构依赖面向对象设计思想、设计原则、设计模式、编程规范实现,主要用来提高代码的可维护性。也可以这么理解:1个设计思想、6个设计原则、23个原创 2022-05-03 22:21:30 · 1086 阅读 · 0 评论 -
【Java设计模式 面向对象设计思想】一 再谈面向对象和封装、抽象、继承、多态四大特性
今天可以说又重新认识了一下面向对象四大特性,回顾设计模式目标,写出高质量的代码:易维护、易读、易扩展、灵活、简洁、可复用、可测试,面向对象设计思想是基本指导思想,是很多设计原则、设计模式的实现基础,后者进一步支持高质量代码目标达成。而面向对象四大特性本来被设计出来也能一定意义上本身作为一个达成路径,例如封装,可以让数据更安全,不能被随便修改,让代码更易维护;通用的抽象影响无处不在,抽象的代码设计让代码易扩展、易维护;继承让代码更加可复用;多态让代码更易扩展、易复用。它们的作用远不止这些,这些顶层的语言特性抽原创 2022-05-25 01:44:31 · 629 阅读 · 0 评论 -
【Java设计模式 面向对象设计思想】二 再谈面向对象和面向过程
面向对象还是面向过程?其实不是那么重要,我们只看最终目的:是否能写出易维护、易读、易复用、易扩展的高质量代码,面对复杂网状业务场景的时候我们更趋向于使用面向对象的方式,因为设计它的语言四大基本特性(封装、继承、抽象、多态)和代码组织方式(类和对象)具备编写高质量代码的先决条件。但这并不能说明面向过程一无是处,在简单的线状业务场景下面向过程可能会更快的实现,甚至我们经常使用的网站开发模式MVC贫血模式就是基于面向过程实现的,因为简单且流程化的思维更容易被我们理解。所以还是那个道理:谈概念和优势的时候一定要关联原创 2022-05-30 22:23:59 · 577 阅读 · 0 评论 -
【Java设计模式 面向对象设计思想】三 再谈抽象类和接口
抽象类是对成员变量和方法的抽象,是一种 is-a 关系,是为了解决代码复用问题。接口仅仅是对方法的抽象,是一种 has-a 关系,表示具有某一组行为特性,是为了解决解耦问题,隔离接口和具体的实现,提高代码的扩展性。如果要表示一种 is-a 的关系,并且是为了解决代码复用问题,我们就用抽象类;如果要表示一种 has-a 关系,并且是为了解决抽象而非代码复用问题,那我们就用接口。总的来看,抽象类更像是介于普通类和接口直接,既可以代码复用,又可以优雅的实现多态。...原创 2022-05-31 10:41:22 · 309 阅读 · 0 评论 -
【Java设计模式 面向对象设计思想】四 基于接口而非实现编程
基于接口而非实现编程,实际上是基于抽象而非实现编程,具体到Java里就是抽象特性的体现,抽象的两个实现方式也就是上篇Blog提到的抽象类和接口类。原则的设计初衷是将接口和实现相分离,封装不稳定的实现,暴露稳定的接口。上游系统面向接口而非实现编程,不依赖不稳定的实现细节,这样当实现发生变化的时候,上游系统的代码基本上不需要做改动,以此来降低代码间的耦合性,提高代码的扩展性。但这个原则使用时也需要注意,设计接口和实现时思维顺序要摆正,不要通过实现去反推接口定义;写代码时候也不要惯性的为每个实现类都定义接口,使用原创 2022-06-02 09:35:22 · 348 阅读 · 0 评论 -
【Java设计模式 面向对象设计思想】五 多用组合少用继承编程
继承的问题是如果继承的层级过深,那么代码的可读性和可维护性就会变差,而且可能由于行为方法的增加导致组合爆炸。通过接口+组合+委托可以巧妙的解决这个问题且能保持继承的优势:接口可以实现继承的多态,组合+委托可以实现继承代码复用。当然多用组合少用继承也不是说完全不用继承,也是区分场景的,例如当业务结构稳定,继承层次不深的情况下,使用继承还能避免组合多定义细粒度的类的问题。而继承层次深、结构不稳定的时候,或者继承关系只是为了实现代码复用而无业务上的父子关系含义时,使用组合更加灵活、代码可读性和可扩展性、可维护性更原创 2022-06-03 17:31:16 · 661 阅读 · 0 评论 -
【Java设计模式 面向对象设计思想】六 再谈MVC贫血模式与DDD领域驱动开发
DDD从代码上的区别很小,就是对Service层进行重新设计并将BO升级为Domain,但是从设计和思维模式上区别很大,它是一套自底向上的面向对象思维方式和开发流程,能让我们从业务建模的视角去看问题。从可读性上来说:它可以把原来最重的service逻辑拆分并且转移一部分逻辑,可以使得代码可读性略微提高,另外,模型充血以后基于模型的业务抽象在不断的迭代之后会越来越明确,业务的细节会越来越精准,通过阅读模型的充血行为代码,能够极快的了解系统的业务,对于开发来说能说明显的提升开发效率。......原创 2022-06-04 13:39:08 · 908 阅读 · 0 评论 -
【Java设计模式 面向对象设计思想】七 面向对象分析、面向对象设计和面向对象编程
面向对象分析英文缩写是 OOA,全称是 Object Oriented Analysis;面向对象设计的英文缩写是 OOD,全称是 Object Oriented Design;面向对象编程的英文缩写是 OOP,全称是 Object Oriented Programming。OOA、OOD、OOP 三个连在一起就是面向对象分析、设计、编程(实现),正好是面向对象软件开发要经历的三个阶段,想想之前为什么我们基本没有面向对象分析和设计,主要原因就是我们进行的都是面向过程编程,我们的视角是自上而下的任务处理流程,原创 2022-06-04 21:05:58 · 841 阅读 · 0 评论 -
【Java设计模式 面向对象设计思想】八 面向对象设计思想小结
说到面向对象设计思想,看似每个学习Java语言的人入门时都知道,类、对象等概念也耳熟能详,但是每个人对面向对象这种设计思想理解是千差万别的,就拿我来说,16年读研时初一学习Java时只知道:面向对象开发有类、对象、成员变量、方法等,学会了基本语法,然后死记硬背会了抽象类和接口的区别、类之间的关系,根本不清楚为啥有抽象类,它和接口到底啥区别,为啥有普通类了还要它?甚至说多态是啥意思都没能深入理解,以为多态就是接口。18年初刚一工作的时候想学习时新技术,去学DDD,结果只背会了一堆概念,因为没有工作实践过,写了原创 2022-06-05 15:38:53 · 489 阅读 · 0 评论 -
【Java设计模式 经典设计原则】一 SOLID-SRP单一职责原则
单一职责原则是为了实现代码高内聚(功能相关高内聚)、低耦合(功能无关低耦合),提高代码的可复用性、可读性、可维护性。具体怎么拆分主观上依据对业务发展的认知和场景的分析持续重构,客观上依据几条可执行规则:代码的行数、属性、方法不要过多;类依赖与被依赖的程度较低;私有的通用方法不能过多;类要比较好命名,见名之意;类的属性操作比较均衡。虽然单一职责原则原则好,可不要单纯为了更单一去拆分,否则本来内聚的功能被拆分了后代码的可维护性就会变的很差。...............原创 2022-06-11 11:25:30 · 562 阅读 · 1 评论 -
【Java设计模式 经典设计原则】二 SOLID-OCP开闭原则
OCP是相对而言的一个概念,在不同代码粒度可能就是不同的结果,所以不能认为OCP就是不改代码,而是尽量让改动更上层,集中在非核心逻辑部分,一个判断依据就是当有新功能添加时不需要改之前的核心实现逻辑并且单元测试都能通。实现OCP的方式有很多,例如依赖注入、基于接口而非实现编程、多态以及各种设计模式。但核心指导思想则是,写代码时候要多思考,要时刻具备扩展意识、抽象意识、封装意识。原创 2022-09-15 00:14:40 · 382 阅读 · 0 评论 -
【Java设计模式 经典设计原则】三 SOLID-LSP里式替换原则
LSP乍一看对子类的实现限制有点儿死,但这样的好处是让父子类的继承关系更加健壮,相同方法子类能对父类功能做增强但又不会因此而带来预期外的结果或副作用。例如1.0版本的Sort接口基于LSP的实现为冒泡排序,2.0版本基于LSP增加了快速排序,这个时候用快速排序替换冒泡排序增强了排序效果,但又不脱离Sort的功能范围,影响Sort的正常逻辑。原创 2022-09-15 23:21:21 · 403 阅读 · 0 评论 -
【Java设计模式 经典设计原则】四 SOLID-ISP接口隔离原则
ISP中的接口对于不同功能诉求的使用者来说,可以当做一组 API 接口或方法集合,按照使用者分类来暴露给不同使用者差异化的接口集,不要给使用者它不care的功能;对于单一功能的使用者来说,可以当做一个API接口或方法集合,按照使用者的场景诉求主观判断是否需要拆分,不要给使用者他不care的复杂方法实现;对于一个固定的需求实现而言,可以当做一个OOP的接口去看待,按照需求定义接口,不要让接口的实现类和调用者,依赖它不care的功能的接口原创 2022-09-15 22:40:56 · 499 阅读 · 0 评论 -
【Java设计模式 经典设计原则】五 SOLID-DIP依赖反转原则
理不辨不明,IOC是一种指导框架设计的思想,通过控制反转接管大量与核心业务逻辑无关的内容,让RD能专注业务逻辑开发,按照规范将代码注册到框架预留扩展点即可。而DI是IOC思想的一种具体实现方式,主要用于外部创建对象注入给当前对象,Spring中对DI的使用则更加具体为在运行时通过反射创建外部依赖对象并注入当前对象,所以Spring是一种贯彻IOC思想的通过DI实现的一个框架。依赖反转是一种设计原则,也是指导框架设计的,它关注的是如何约束框架代码和业务代码的关系,高层(框架)的运行不依赖于底层(业务代码),而原创 2022-09-16 23:25:33 · 915 阅读 · 0 评论 -
【Java设计模式 经典设计原则】六 KISS、YAGNI和DRY原则
KISS 原则讲的是“如何做”的问题(尽量保持简单),它的目的是提升代码的可读性、可维护性,而 YAGNI 原则说的是“要不要做”的问题(当前不需要的就不要做),它的目的是降低代码的冗余度,提升代码的可维护性。DRY原则说的是不要做重复的事,它的目的是减少代码量,提高代码的可读性、可维护性。除此之外,复用已经经过测试的老代码,bug 会比从零重新开发要少,也就提高了代码健壮性。所以要有代码复用意识、写可复用性强的代码、不要违反DRY的去添加重复功能。不要违反YAGNI去过度设计,不要违反KISS去单纯的炫技原创 2022-09-17 16:26:45 · 993 阅读 · 0 评论 -
【Java设计模式 经典设计原则】七 LOD迪米特法则
SRP原则侧重高内聚,指导类功能的设计要单一,LOD法则侧重低耦合,指导类间依赖关系要松耦合,ISP原则是从调用者的角度出发确保接口的设计具备对调用者有良好的隔离性。基于接口而非实现编程思想也是从调用者的角度出发确保稳定的依赖和可插拔的实现。总的来说SRP原则、ISP原则、LOD法则以及基于接口而非实现编程思想的目标都是实现代码的高内聚低耦合,提高代码的可扩展性、可读性和可维护性。原创 2022-09-17 20:36:34 · 511 阅读 · 0 评论 -
【Java设计模式 经典设计原则】 八 经典设计原则小结
其实无论是SOLID、还是KISS、YAGNI、DRY以及LOD,都是服务于写出高质量代码。简单而言就是写出:可维护性、可读性、可扩展性、灵活性、简洁性(简单、复杂)、可复用性、可测试性强的高质量代码。可读性、可维护性的一个基本设计就是写出高内聚、低耦合的代码,其中SRP服务于高内聚,ISP和LOD服务于低耦合。毋庸置疑OCP服务于代码的扩展性,LSP和DIP场景就比较具体了:LSP用于指导父子关系设计,DIP用于指导框架设计。而KISS、YAGNI以及DRY都是从代码的整体视角去告诉我们写代码要尽量简单明原创 2022-09-18 12:12:59 · 504 阅读 · 0 评论 -
【Java设计模式 规范与重构】 一 重构的目的、内容、时机、方法
在系统开发前期我们不可能预见所有业务需求,而且还要避免过度设计,而随着业务的发展,代码不得不随着业务发展和堆砌,导致代码的熵增、系统的无序。所以持续重构真的非常重要,它能在不改变功能的前提下保证系统的健康度和活力。对于业务发展阶段的大的变动需要通过有计划、分阶段的大型重构来达成,而常规的小型变动则仅仅通过编程规范、意识以及一些代码规范检测工具即可达成。原创 2022-09-19 22:04:19 · 1077 阅读 · 0 评论 -
【Java设计模式 规范与重构】 二 重构的保障:单元测试,以及如何提高代码可测试性
单元测试好像写的没有之前多了,更多的是写相对更粗粒度的接口测试,一个主要原因就是觉得写单元测试琐碎,写接口测试能通就证明主流程OK,就能提测了,事实上在比较紧凑的迭代节奏里这是常态,幸而测试同学的集成测试比较给力,没出什么问题,但其实也不能老依赖于接口测试和集成测试,单元测试也有必要写的,更多的是通过写单测CR下自己的代码吧,践行持续重构的理念。对于代码的可测试性而言,其实我们日常基于Spring去开发,本身大多数场景都是依赖注入,所以体会可能没有那么深,至于对于远程服务的依赖,使用二次封装是个不错的方法,原创 2022-09-21 22:04:52 · 1237 阅读 · 0 评论 -
【Java设计模式 规范与重构】 三 大型重构的手段:高内聚,低耦合
讨论解耦的背后其实主要讨论高内聚、松耦合这个比较通用的设计思想,它不仅可以指导细粒度的类和类之间关系的设计,还能指导粗粒度的系统、架构、模块的设计。相对于编码规范,它能够在更高层次上提高代码的可读性和可维护性,是大型重构的重要手段,从面向对象设计思想层面角度就是:封装、抽象,从思想的最佳实践角度就是基于接口而非实现编程、多用组合少用继承,从设计原则层面角度就是:SRP、ISP、LOD,从设计模式角度就是:观察者模式、适配器模式等。从系统设计角度就是:模块化,从编程技巧角度就是:DI依赖注入,从学习设计模式迄原创 2022-09-22 23:57:23 · 925 阅读 · 2 评论 -
【Java设计模式 规范与重构】 四 小型重构的手段:规范的十五条军规
代码规范是一个永久的话题,每个人的理解不一样,但是一些通用的实践还是有帮助的。之前学习了《阿里代码规范》后有了一些进步,但还是有做的不好的地方:命名时想要最达意的英文,有时候单词虽然达意但生僻,自己再看都不知道什么意思;命名没有和大家整齐划一,之前项目大家用insert,我就使用create,项目体感比较杂乱;注释做的还是不够,重要方法注释只做到了:是什么,对于为什么、怎么做没有详细说明;类中成员方法的排序也没有按照作用域排列过,静态成员也没有放到动态成员的前面;在拆分代码时有时矫枉过正,单纯为了缩代码行数原创 2022-09-24 14:25:23 · 542 阅读 · 0 评论 -
【Java设计模式 规范与重构】 五 重构实战:基于ID生成器case
用一句话总结一下,重构就是发现代码质量问题,并且对其进行优化的过程。面对一段看起来烂但又不能准确全面的分析的代码时,先依次通过代码诊断的常规检查CheckList和业务检查CheckList将代码问题罗列出来并分类,然后制定多轮重构计划,小步快跑的一轮一轮的重构解决代码问题。这个流程其实也适用于代码CR,在给别人CR代码的时候其实也能按这个方法流程来。原创 2022-09-24 20:42:12 · 837 阅读 · 0 评论 -
【Java设计模式 规范与重构】 六 代码重构小结
代码重构实际上是设计思想、设计原则、设计模式、编程规范的一个练兵场,通过掌握这些知识,对代码存在的问题进行诊断,依据诊断结果进行重构,才能保证写出高质量有活力的代码!【Java设计模式 规范与重构】 一 重构的目的、内容、时机、方法【Java设计模式 规范与重构】 二 重构的保障:单元测试,以及如何提高代码可测试性【Java设计模式 规范与重构】 三 大型重构的手段:高内聚,低耦合【Java设计模式 规范与重构】 四 小型重构的手段:规范的十五条军规。原创 2022-09-25 14:17:07 · 787 阅读 · 0 评论 -
【Java设计模式 思想原则重构】设计思想、设计原则、重构总结
对于总结的总结来说,好像没什么可说的,一言以蔽之:通过继承、封装、多态、抽象、基于接口而非实现编程、多用组合少用继承、高内聚-松耦合、控制反转等设计思想;SOLID、KISS、DRY、YAGNI、LOD等设计原则和法则;创建型、结构型、行为型这些设计模式;依赖注入等编程技巧;模块化等系统设计技巧;命名与注释、编程风格、编程技巧等编程规范,在持续的重构中发挥作用。通过单元测试保证重构的顺利进行。而最终的目的都是保证易扩展、易维护、易复用、易读、简介、灵活、易测试的高质量代码活力常在。原创 2022-09-25 13:46:24 · 614 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】设计模式概述、基本原则及分类
研究问题的方法,提出问题:随着时间推移,系统越来越难以维护,越来越臃肿;提出解决问题的目标:如果代码的设计是高内聚、低耦合的就好了;基于目标设定处理原则:开闭原则、里式替换原则、依赖倒置原则、接口隔离原则、合成复用原则、单一职责原则、迪米特法则;基于处理原则总结在类的使用过程中如何贯彻原则、实现目标的代码设计最佳实践:5种创建型设计模式、7种结构型设计模式、11种行为型设计模式。这样就厘清了前因后果了,知道为什么而去学习设计模式。原创 2022-03-12 17:39:05 · 750 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】创建型模式 一:单例模式
今天总结了一套学习设计模式的模版来不断套用学习模式,并且对历史学习的单例进行了一个整合性学习,加深了单例的概念内容探究。重新回顾了饿汉式单例实现、懒汉式单例实现、双检锁单例实现、静态内部类单例实现以及常规单例的反射和序列化破坏,最终祭出大杀器:枚举单例,算是一篇大汇总吧,同时也发散了一下自己的思维,单例的唯一性在什么限定范围下?多例模式是什么?很多看起来单例的应用场景是如何甄别为不适用于单例,单例的反模式反在哪里?以及单例的最佳应用场景:对于一个类判定其后续不扩展且不依赖外部并且试图全局唯一最好使用单例模式原创 2022-03-13 13:43:22 · 1103 阅读 · 1 评论 -
【Java设计模式 设计模式与范式】创建型模式 二:简单工厂模式
当一种产品实现有多种不同的呈现方式或表现形式时,比较适合使用工厂模式,而简单工厂其实能适配我们日常使用的大多数场景,依据我在工作中的体验,工厂模式中几乎只用到了简单工厂。在几种简单工厂的实现中,我觉得多例模式(单例+Map)是最合适的工厂实现模式,它解决了if else这个灾难性问题,下一篇一起来看看工厂方法模式是怎么工作的吧!原创 2022-04-09 17:15:01 · 606 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】创建型模式 三:工厂方法模式
其实工厂模式应用非常广泛,工作中经常会遇到,因为面向接口编程,在很多场景下会有多个类拥有同一种行为的情况,无论这种行为来自实现接口还是继承父类。但是它们各自又有不同的实现内容,也就是多态。在使用这些类进行某种行为时我们希望不关心创建过程直接获取自己需要的类并进行个性化行为,此时工厂方法模式就是最佳选择,工厂方法模式可以让我们的客户端调用代码与被调用对象的创建解耦,无论被调用对象的创建过程如何变化,客户端调用代码都无需改变。其实大多数情况下简单工厂就够用了,只有当类的创建过程复杂、待创建类的种类非常多对工厂扩原创 2022-03-20 17:18:21 · 706 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】创建型模式 四:抽象工厂模式
抽象工厂模式其实是工厂方法模式的升级版,其优点其实和工厂方法类似,都是将对象的创建解耦出来,不过抽象工厂模式的工厂能创建的不只是一个产品而是一组产品,这一组产品都有相同的产品类别,同组不同类的产品相互依赖和约束,例如一个工厂要生产红方旗,那么布料类产品必须是方形布料、染料类产品必须为红色染料,方形布料和红色染料在该工厂中就是绑定关系,该工厂也就约束了其生产的具体产品品类。原创 2022-03-21 23:38:50 · 546 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】创建型模式 五:建造者模式
和工厂模式类似,建造者模式也致力于将对象的创建与使用分离。不同的是工厂模式的产品是具有抽象产品的,也就是具体产品可以有各自不同的方法实现,建造者模式的产品是固定的复杂对象,不同的具体建造者所能改变的也只是产品的组成部分属性值,产品的方法实现是固定的。但建造者模式拥有指挥者角色可以依据不同场景下的要求更好的调节产品内组成部分的依赖(顺序或种类)从而改变产品的特征。我感觉将二者结合起来应对复杂场景设计应该非常有帮助。原创 2022-03-27 12:49:28 · 644 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】创建型模式 六:原型模式
和单例模式略有不同,原型模式要做的是进行对象复制。如果说单例是一份结构一份数据,那么原型则是一份结构多份数据。当系统中存在复杂但常用对象,且不同的对象属性值略微不同时,也就是当所需对象和原型对象相差无几且创建成本高时,使用原型模式比使用构造方法性能更高、限制更少,在Java中很简单,就是clone方法,但是需要注意的是深浅拷贝的不同含义,避免拷贝对象的使用对原型对象造成影响。还有一点需要注意,原型模式和我们经常用的spring的beanutils工具类进行对象拷贝有些差异,beanutils工具类主要(不排原创 2022-03-27 18:32:15 · 655 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】创建型模式小结
创建型模式主要解决对象的创建问题,封装复杂的创建过程,解耦对象的创建代码和使用代码单例模式用来创建全局唯一的对象。工厂模式用来创建不同但是相关类型的对象(继承同一父类或者接口的一组子类),由给定的参数来决定创建哪种类型的对象。建造者模式是用来创建复杂对象,可以通过设置不同的可选参数,定制化地创建不同的对象。原型模式针对创建成本比较大的对象,利用对已有对象进行复制的方式进行创建,以达到节省创建时间的目的其中工厂模式又分为:简单工厂模式、工厂方法模式、抽象工厂模式原创 2022-04-10 10:54:08 · 424 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】结构型模式 一:适配器模式
适配器模式理解起来非常容易,其实就是一个转接口,当我们在现有业务逻辑下调用新定义的接口时,如果系统中已经存在该接口的实现对象,只是接口定义上略有不同,我们没有办法修改现存对象接口实现对应的接口定义(该接口定义可能已经广泛的被上下游使用了)来匹配新定义的接口,此时使用适配器模式比较合适,有了适配器,客户端只和目标接口绑定而不是和实现绑定(适配过程被解耦并封装到了适配器类中),需要适配哪种现存对象实现就增加哪种适配器类。但长期看能不适配就尽量不适配,最好通过重构使系统代码更优雅。原创 2022-04-03 23:24:17 · 752 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】结构型模式 二:代理模式
其实代理模式之前在项目中用到很多,包括开源框架原理学习(mybatis和spring aop)、远程proxy调用(retrofit2)等,只是当时对这些实际应用没有一个准确的归纳,现在学习完后才知道其实之前用到的各种代理其设计思想都是来源于这种设计模式。所以说设计模式其实是一种思想,掌握了思想就能更好的理解思想在实际场景中的各种应用,不变应万变。原创 2022-04-05 16:04:59 · 707 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】结构型模式 三:装饰器模式
装饰器模式和代理模式其实很容易混了,说实在的单从角色关系结构上来说也非常相似。但是我们从使用角度出发去看还是有很多差别的,代理模式解决的问题是对当前功能的横向扩展,所以每个代理类要横向扩展的功能是固定的,例如增加日志,所以设计上不存在也没有必要定义抽象代理类,横向功能是不需要也不可能穷尽收束的。而装饰者模式被设计来是用来替代继承实现类功能增强的一种方案,设计上存在抽象装饰类,以便通过各种具体装饰子类对具体构件实现多样的功能增强,对一个具体构件来说我们是可以给它定制装饰方案的,所以通过抽象装饰类来实现。原创 2022-04-05 18:22:28 · 915 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】结构型模式 四:桥接模式
其实我觉得从代码结构上去区分代理、桥接、装饰器、适配器这四种结构型模式非常容易搞混(甚至退化的装饰器结构能和代理模式玩去一样)也大可不必,因为它们的结构非常相似,反而是从要解决的问题、应用场景出发去思考,先对问题有宏观认知,然后再去思考这个场景适配哪种模式,最后再去关心代码结构应该怎么写,这才是个比较不错的思考方式。原创 2022-04-18 23:00:04 · 415 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】结构型模式 五:外观模式
接口粒度设计得太大,太小都不好。太大会导致接口不可复用,太小会导致接口不易用。在实际的开发中,接口的可复用性和易用性需要权衡。针对这个问题,一个基本的处理原则是,尽量保持接口的可复用性,但针对特殊情况,允许提供冗余的门面接口,来提供更易用的接口。其实外观模式我们日常都会不经意间使用,就是分层里更上层的业务层,封装聚合了下层单一行为接口,为调用者提供一个独立且与下层接口解耦的功能。原创 2022-04-19 22:51:43 · 483 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】结构型模式 六:组合模式
组合模式的场景使用较为特殊,实际上就是树这种数据结构组织的对象,通过抽象复杂数据结构中的通用方法使这个复杂对象调用起来和简单对象一样容易,例如核算一个部门的成本数据,对于部门+人这类组织数据就可以理所当然的认为是一个树形结构,无论是部门这种树枝还是人这种树叶都提供计算成本的统一方法,只要构建完毕这样一个组织,那么无论是计算哪一级的成本,都统一调用计算方法即可,递归逻辑已经内置在组织构建过程中了。原创 2022-04-25 23:35:42 · 468 阅读 · 0 评论 -
【Java设计模式 设计模式与范式】结构型模式 七:享元模式
享元模式从概念上看非常简单,意图就是复用相似对象,结构上和多例模式、缓存、池化技术等类似都用到了工厂,但是设计意图却大相径庭,例如多例模式主要用于限制对象个数,缓存时提高对象访问效率,池化技术主要目的是节省时间。从这里也能看出,有些模型设计虽然结构非常类似,但是出发点却不同,这也印证了学习设计模式的出发点应为设计意图而非死记结构,最终结构只是设计的落地方式而已。原创 2022-05-01 15:02:53 · 860 阅读 · 0 评论