设计模式/重构/UML建模
文章平均质量分 89
有心好书
种一棵树最好的时间是十年前,其次是现在
展开
-
说说重构那些小事三:重读《重构》
0x01.《重构》一书为了做这期重构,自己也是专门又饭看了下《重构》,这本书,之前跟同事共读的时候,看过一遍。不过实践的机会不多。这次重读有一些思考。读书重要在于理解,而不是在于数量,在于读了多少本书。理解,比如对于重构这本书,理解更多是能够自己打散书的目录逻辑,在自己心里重建一套只有的逻辑框架顺序。重构这本书,可以分为大型重构、小型调整。大型重构专门有一个章节提到。目前来看,继承关系梳...原创 2019-09-30 18:35:38 · 393 阅读 · 0 评论 -
重构系列之对象间的重构:《重构》处理概括关系
这里说到的概括关系指的就是继承关系。Pull Up Field 字段上移两个子类拥有相同的字段。将该字段移至超类。原创 2016-07-10 16:54:56 · 1313 阅读 · 0 评论 -
重构系列之对象间的重构:《重构》对象之间搬移特性
在面对对象的设计中,“决定把责任放到哪儿”即使不是最重要的事情,也是最重要的事之一。我使用对象技术十几年了,但还是不能一开始就保证做对。这曾经让我很苦恼,但现在我知道,在这种情况下,可以运用重构,改变自己原先的设计。Move Method 移动函数类的行为做到单一职责 不要越俎代庖: 你的程序中,有个函数与其所驻类之外的另一个类进行更多的交流:调用后者,或被后者调用。在该函数最常用引用的类中建立一个有原创 2016-07-10 16:54:21 · 1434 阅读 · 0 评论 -
重构系列之对象行为的重构:《重构》简化函数调用
大力提倡的一种编程风格是:将复杂的处理分解成小函数。但是,如果做得不好,这会使你费尽周折却弄不清楚这些小函数各自的用途。要避免这种麻烦,关键就在于给函数起一个好名称。函数的名称应该准确表达它的用途。给函数命名有一个好办法:首先考虑应该给这个函数写上一句怎样的注释,然后想办法将注释变成函数名称。原创 2016-07-10 16:53:43 · 2262 阅读 · 0 评论 -
重构系列之对象行为的重构:《重构》简化条件表达式
条件逻辑有可能十分复杂,因此本章提供了一些重构手法,专门来简化他们。Decompose Conditional 分解条件表达式你有一个复杂的条件语句。从if、then、else三个段落中分别提炼出独立函数。原创 2016-07-10 16:53:06 · 1386 阅读 · 0 评论 -
重构系列之对象行为的重构:《重构》重新组织函数
函数过长或者逻辑太混乱,重新组织和整理函数的代码,使之更合理进行封装。Extract Method 提炼函数提炼函数:(由复杂的函数提炼出独立的函数或者说大函数分解成由小函数组成)你有一段代码可以被组织在一起并独立出来。将这段代码放进一个独立函数,并让函数名称解释该函数的用途。原创 2016-07-10 16:52:11 · 1503 阅读 · 0 评论 -
设计模式系列:总结
区分及如何使用 占位原创 2016-06-10 15:47:56 · 717 阅读 · 0 评论 -
设计模式系列:访问者模式
一.名称二.问题(为了解决什么问题)三.解决方案(主要体现在uml和核心代码上)访问者模式是一种较为复杂的行为型设计模式,它包含访问者和被访问元素两个主要组成部分,这些被访问的元素通常具有不同的类型,且不同的访问者可以对它们进行不同的访问操作。例如处方单中的各种药品信息就是被访问的元素,而划价人员和药房工作人员就是访问者。访问者模式使得用户可以在不修改现有系统的情况下扩展系统的功能,为这些不同类型的原创 2016-02-29 15:48:59 · 1037 阅读 · 0 评论 -
设计模式系列:模板方法模式
一.名称二.问题(为了解决什么问题)三.解决方案(主要体现在uml和核心代码上) 定义一个操作中的算法的框架,而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义改算法的某些特定步骤。 主要体现了依赖倒置,里氏替换,开闭原则。这主要做的也是增加了一层实现了解耦和复用。 抽象类和继承——依赖倒置 抽象类——开闭原则 抽象类——里氏替换原则模板方法模式经常和其他设计模式原创 2016-02-28 18:01:05 · 788 阅读 · 0 评论 -
设计模式系列:策略模式
一.引入1.案例计算a+b, a-b2.面向实现编程方案定义一个Calcuate类,里面有两个方法,一个加法,一个减法3.面向设计编程方案把加法和减法封装成两个类二.场景1.应用场景:多个类只有在算法或行为上稍有不同的场景。 算法需要自由切换的场景。 需要屏蔽算法规则的场景。2.策略模式的优点如下:策略模式提供了管理相关的算法族的方法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把原创 2016-02-29 15:45:43 · 959 阅读 · 0 评论 -
设计模式系列:状态模式
一.名称二.问题(为了解决什么问题) 在以下情况下可以使用状态模式:• 对象的行为依赖于它的状态(属性)并且可以根据它的状态改变而改变它的相关行为。 • 代码中包含大量与对象状态有关的条件语句,这些条件语句的出现,会导致代码的可维护性和灵活性变差,不能方便地增加和删除状态,使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为,而且这些条件对应于对象的各种状态。 状态模式在工作流或游戏原创 2016-02-29 15:51:39 · 1050 阅读 · 0 评论 -
设计模式系列:观察者模式
一.名称二.问题(为了解决什么问题)很好辨认,举一些常见的例子: 猫鼠游戏 广播收音机 事件监听等等三.解决方案(主要体现在uml和核心代码上)定义:定义对象间一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖于它的对象都会得到通知并被自动更新。其实观察者模式的更细节的1对1就是接口回调。扩展: java中已经帮我们定义了观察者和被观察者的接口,我们只需要直接实现即可。观察者模式体现原创 2016-02-29 15:47:50 · 1247 阅读 · 1 评论 -
设计模式系列:备忘录模式
一.场景保存和恢复状态或操作时,可以使用这个模式,例如游戏中的保存点。二.定义及体现了什么设计原则定义:在不破坏封装性的前提下,捕获一个对象的内部状态,并在改对象之外保存这个状态,这样以后就可将对象恢复到原先保存的状态。三.类图或时序图四.代码多状态的备忘录/** * Created by annuoaichengzhang on 16/3/23. */public class Origina原创 2016-02-29 15:48:44 · 961 阅读 · 0 评论 -
设计模式系列:中介者模式
一.引入1.案例:假设计算机1,2,3,4之间要相互通信。2.面向实现编程方案:类Computer1中要保存类Computer2、类Computer3和类Computer4实例,才能调用Computer2、Computer3、Computer4方法中的Comunicate方法。 。。。 。。。 。。。 具体图示如下: 3.面向设计编程方案:建立一个中介者,保有类Computer1,类Com原创 2016-02-28 18:02:59 · 2254 阅读 · 0 评论 -
设计模式系列:解释器模式
一.名称二.问题(为了解决什么问题)在以下情况下可以使用解释器模式:有一个简单的语法规则,比如一个sql语句,如果我们需要根据sql语句进行rm转换,就可以使用解释器模式来对语句进行解释。 一些重复发生的问题,比如加减乘除四则运算,但是公式每次都不同,有时是a+b-cd,有时是ab+c-d,等等等等个,公式千变万化,但是都是由加减乘除四个非终结符来连接的,这时我们就可以使用解释器模式。三.解决方案原创 2016-02-29 15:52:06 · 1027 阅读 · 1 评论 -
设计模式系列:命令模式
引入1.案例2.面向实现编程方案 如果我们用面向事项的方式来实现的话:会直接让调用者(invoker)和每个接受者(recevier)之间交互,产生耦合.3.面向设计编程方案 命令模式主要的就是在他们中间增加一层,命令层,来隔开这两者之间的交互,调用者和命令之间交互,命令再去调用具体的接受者来执行命令。一.名称二.问题(为了解决什么问题)在以下情况下可以使用命令模式: • 系统需要将请求调用者原创 2016-02-28 18:03:38 · 949 阅读 · 0 评论 -
设计模式系列:责任链模式
引入1.案例2.面向实现编程方案首先来看一段代码: public void test(int i, Request request){ if(i==1){ Handler1.response(request); }else if(i == 2){ Handler2.response(request); }原创 2016-02-28 18:03:55 · 965 阅读 · 0 评论 -
设计模式系列:代理模式
一.名称二.问题(为了解决什么问题)我相信第一次接触代理模式的读者肯定非常郁闷,为什么要用代理呢?我们来想想现实世界,打官司为什么要找一个律师?因为你不想参与中间过程的是是非非,只要完成自己的答辩就可以了,其他的比如事前调查、事后追查都由律师来搞定,这就是为了减轻你的负担。代理模式的使用场景非常多,大家可以看看spring AOP,这是一个非常典型的动态代理。在软件开发中,由于某些原因,客户端不想或原创 2016-02-28 18:01:58 · 1014 阅读 · 0 评论 -
重构系列之大型重构
Tease apart Inheritance 梳理并分解继承体系某个继承体系同时承担两项责任 ,建立两个继承体系,并通过委托关系让其中一个可以调用另一个 .原创 2016-07-10 16:55:31 · 1276 阅读 · 0 评论 -
重构系列之重构的标志:《重构》代码的坏味道
重复代码1. 表现:同一个类的两个函数含有相同的表达式。 方案:提炼函数。2. 表现:两个互为兄弟的子类内含有相同表达式。 方案:函数上移,推入超类。3. 表现:如果两个毫不相关的类出现重复代码。 方案:对其中一个类采用提炼类的方式,将重复代码提取到一个独立类中(类似工具类),然后在另外一个类中使用这个新类。(也可能这个函数并确实属于其中的一个类,那让另外一个类引用它即原创 2016-07-10 22:14:46 · 1964 阅读 · 0 评论 -
说说重构那些小事二:小视频落地页重构二期
0x01.二期的主要目的二期的主要是为了解决DetailAdapter代码膨胀的问题。目前DetailAdapter代码量已经达到了4300行。里面充斥了网络请求、业务逻辑、埋点逻辑、弹窗逻辑等等。在最小化对功能的影响的前提下(因为落地页有很多关键指标的埋点,包括商品浮层、播放loading率、起播时间等等),我们都是期待尽量少的动到过去的业务逻辑,其实之前尝试过做简单的重构,不过更多是把大的方...原创 2019-09-30 18:11:18 · 784 阅读 · 0 评论 -
说说重构那些小事一:小视频落地页重构一期
最近在针对视频落地页做一系列的代码重构。工作之余,又把之前的《重构:改善代码的既有设计》复习了一下。有了一些新的感悟和想法。故而有了这一系列的文章。规划的是讲一讲自己在项目中的心路思考及对重构的新认识。原创 2019-09-30 16:10:20 · 1917 阅读 · 0 评论 -
Git操作记录
git配置as vs的时候设置到.git那层目录,因为有的项目code和.git不是同一层Git 修改已提交的commit注释https://www.jianshu.com/p/098d85a58bf1git常见操作git add .git commit -m “”...原创 2019-05-14 22:55:25 · 295 阅读 · 0 评论 -
android缓存系列:DiskLruCache源码分析
disklrucache源码分析#项目介绍 LRU是一种算法,disklrucache基于LRU算法实现的磁盘缓存方案。在很多开源项目中都可以看到它的身影,比如universal imageloader等等。#简单用法(一个demo)首先,这个框架会涉及到一个文件,叫做journal,这个文件中会存储每次读取操作的记录;对于获取一个DiskLruCache,是这样的:原创 2016-09-12 23:28:07 · 2034 阅读 · 0 评论 -
重构案例积累系列:get set方法重构
封装字段你的类中需要一个public的字段。把它声明为private,并提供相应的访问函数。php版class Test{ private $day; /** * @return mixed */ public function getDay() { return $this->day; } /** * @p原创 2016-08-10 12:26:03 · 1161 阅读 · 0 评论 -
重构案例积累系列:以卫语句取代嵌套条件表达式
需求:验证qq是否合法:5-15位,不能以0开头,全是数字一般做法(不使用正则表达式): private static boolean checkQQ(String qq) { int len = qq.length(); if (len >= 5 && len <= 15) { if (!qq.startsWith("0")) {原创 2016-08-09 09:59:21 · 1767 阅读 · 0 评论 -
为第三方提供的功能做抽象层封装
对第三方提供的功能做抽象层封装,这样可以极大的降低项目和第三方之间的耦合,出问题的时候或者替换第三方的时候可以比较简单的切换,而不是对着项目中的上千个引用点做替换。比如,电话会议,我们使用云视通、华为等等的电话会议,最好为这些api提供一个抽象层的封装。比如,android底层的网络请求框架,我们用了volley等等,最好对他进行一个抽象层的封装。可扩展、可修改、可替换开闭原则是目的。原创 2016-08-28 17:28:54 · 988 阅读 · 0 评论 -
程序的扩展性建立在对业务需求变化的预见性之上
程序的扩展性建立在对业务需求的预见性之上原创 2016-08-01 22:15:33 · 920 阅读 · 0 评论 -
重构一书问题笔记
几个不需要看的地方以下几个比较特殊,感觉用处并没有那么广。Change value to Reference 将值对象改为引用对象??Change Reference to Value 将引用对象改为值对象???Duplicate Observed data 复制被监视数据???Change Unidirection Association to Bidirectional 将单向关联改为双向关联?原创 2016-07-17 08:56:41 · 1264 阅读 · 0 评论 -
重构系列:概论
重构的目的是使软件更容易被理解和修改。你可以在软件内部做很多修改,但必须对软件可观察的外部行为只造成很小的变化,或甚至不造成变化。与之形成鲜明对比的是性能优化。和重构一样,性能优化通常不会改变组件的行为(除了执行速度),只会改变其内部结构。但是两者出发点不同:性能优化往往使得代码很难理解,但为了得到所需的性能你不得不那么做。原创 2016-06-29 20:56:07 · 937 阅读 · 0 评论 -
建造者模式的简写方式分析
我们知道建造者模式一般由Product、Builder、Director三个模块组成。但是在一般的开发中,Director角色经常被忽略。而直接使用一个Builder来进行对象的组装,这个Builder通常是链式调用,它的关键点是每个setter方法都返回自身,也就是return this,这样就使得setter方法可以链式调用,代码大致如下:new TestBuilder().setA("A").原创 2016-07-04 18:12:59 · 1788 阅读 · 0 评论 -
设计模式系列:门面模式
引入大家有没有比较过自己泡茶喝去茶馆喝茶的区别呢?自己泡茶需要自行准备茶叶、茶具和开水,而去茶馆喝茶,最简单的方式就是跟茶馆服务员说想要一杯什么样的茶(铁观音、碧螺春等等)。正因为茶馆有服务员,顾客无须直接和茶叶、茶具、开水等交互,整个泡茶过程由服务员来完成,顾客只需与服务员交互即可,非常简单省事。外观类就充当了软件系统中的“服务员”角色,它为多个业务类的调用提供了统一的入口,简化了类与类之间的交互原创 2016-02-29 15:48:17 · 1007 阅读 · 0 评论 -
设计模式与架构的核心概念乃是抽象
最近一年来一直在学习设计模式,上周在公司内部听了一个分享,当时一位同事提出设计模式的核心是封装,我强烈不赞同,在我看来设计模式的核心乃是抽象。 君不见,各种开源框架开源项目遍地都是抽象类和接口,每每此时,你心中肯定一万个草泥马在奔腾:是不是有病呀,整这么多接口和抽象类,也不嫌累。其实不是这样的,为了扩展性,这些是必须的。 面对对象的三大原则是:封装、继承、多态。封装就不必说了,但是没有抽象,就没原创 2016-06-30 19:41:25 · 1496 阅读 · 2 评论 -
重构系列之对象属性的重构:《重构》重新组织数据
Self Encapsulate Field 自封装字段间接访问类的属性:你直接访问一个字段,但与字段之间的耦合关系逐渐变得笨拙。为这个字段建立取值/设值函数,并且只以这些函数来访问字段。原创 2016-07-10 16:51:25 · 1739 阅读 · 0 评论 -
设计模式系列:享元模式
一.名称二.问题(为了解决什么问题)系统中存在大量相似的对象 需要缓冲池的场景三.解决方案(主要体现在uml和核心代码上) 享元模式是池技术的重要实现方式,定义:使用共享对象可有效的支持大量的细粒度的对象。 仅仅是一个优化性能的解决方案. 在享元模式中,存储这些共享对象的地方成为享元池。 学习享元模式的关键是区分内部状态和外部状态。类图内部状态和外部状态内部状态是存储在享元原创 2016-02-29 15:53:20 · 1074 阅读 · 0 评论 -
设计模式系列:装饰者模式
一.引入1.案例 比如,三个继承关系:Father,Son,GrandSon三个类,我要在son类上增加一些功能怎么办?2.面向实现编程方案 修改Son,这种方案会有大问题,因为你增强的功能是是修改Son的方法还是增加Son的方法,是否会对GrandSon造成影响呢?3.面向设计编程方案 通过建立SonDecorator类来修饰Son类,相当于创建了一个新的类,这个对原有程序没有改变,通过扩展原创 2016-02-28 18:04:15 · 959 阅读 · 0 评论 -
设计模式系列:组合模式
一.名称二.问题(为了解决什么问题)比较好辨别,因为使用范围很窄当有一个结构可以组合成树形结构,且需要向客户端提供一致的操作接口,使得客户端操作忽略简单元素与复杂元素,如维护和展示部分-整体关系的场景,如树形菜单、文件和文件夹管理。从一个整体中能够独立出部分木块或功能的场景。当有一个结构可以组合成树形结构,且需要向客户端提供一致的操作接口,使得客户端操作忽略简单元素与复杂元素三.解决方案(主原创 2016-02-29 15:47:23 · 2726 阅读 · 0 评论 -
设计模式系列:概论
对于普遍的程序员来说,设计模式并不新鲜。网上、书店可以找到各种设计模式的资料。很多的公司招聘技术人员都把它作为一个衡量标准。自己最近阅读了n本设计模式相关的书籍、也查找了一些网上的资料,在与同事的交流中,体会较深。打算写一系列的博客来分享自己的技术体会和心得。 本系列博客的重心:实例讲解,对每个案例都会从面向实现编程和面向设计编程两个角度来分析设计模式的优势。网上和书上讲解较少的知识。尽量少讲原创 2016-02-05 16:13:27 · 1168 阅读 · 0 评论 -
设计模式系列:迪米特法则
迪米特法则原创 2016-06-10 11:41:34 · 797 阅读 · 0 评论 -
对面向接口编程的理解
什么是面向接口编程转载 2016-06-10 11:59:20 · 2385 阅读 · 0 评论