关注
分享
读了《大话设计模式》一书，在这本书指引下再一次学习了一遍设计模式，并记录了多篇博客，实践并绘制了所有类图，记录了自己学习时的困惑与新的，相关代码及visio类图均托管之github： https://github.com/anLA7856/design
6点A君
记录我学习的知识的地方～
展开
-
设计模式之builder模式
虽然网上各种模式有多种讲法，但我还是要自己学一遍，写一遍学习心得。今天看effective java，第二个讲的就是多个参数采用构造器的方法，也就是builder模式。其实一开始我不是很懂，虽然jdk中好多地方都用了builder模式，现在看着书，有种似曾相识的感觉。首先有个前提：所写的bean类中，有n属性。编写这个类时有两种主流方法①：如果要采用传统的构造器，那就是要写n+原创 2017-04-05 19:57:43 · 569 阅读 · 0 评论 -
UML类图关系示例
这些天在学习设计模式，敲了一些代码，分享记录下来嘻嘻。1、继承如果一个类别A“继承自”另一个类别B，就把这个A称为“B的子类别”，而把B称为“A的父类别”也可以称“B是A的超类”。继承可以使得子类别具有父类别的各种属性和方法，而不需要再次编写相同的代码。类图如下：2、实现（接口）实现（interface）和继承相似，里面含有抽象的方法或者常量字段，一个类如果原创 2017-07-26 15:31:30 · 861 阅读 · 0 评论 -
简单工厂模式--女娲造人造啥做啥
有这样一个问题，以面向对象的方法去实现一个简单的计算器该怎么实现呢？首先，有种很简单的思路，输入两个数，然后判断运算符类型，进行相应运算，最后输出结果。这样的方法虽然也能完成，但是不符合面向对象的方法，并且如果有一种新加的运算符时，会显得十分的冗余而不好更改。那有没有一种更好的方法呢？这就是简单工厂模式，理解就是女娲造人造啥做啥，工作类有相似的操作功能，并且当新加如功能类时原创 2017-07-26 17:08:57 · 4583 阅读 · 0 评论 -
策略模式--同一个任务不同的策略
有这样一种情况，一个商场举行活动，进行促销，开始一段时间采取的是打折的方式，假设打9折，如果要编这样的一个程序，想必是非常简单的。后来老板发现现有的促销方式无法燃起消费者的购物欲，决定加大打折力度，采取了满400立减100的策略，编程实现的话，可能就加个判断语句以及一些代码就行。后来促销结束，返回原价，为了保障系统正常运行，又加了一个判断以及部分代码。很明显，如果按照上面的方式去写原创 2017-07-26 22:38:37 · 800 阅读 · 0 评论 -
装饰模式--可用或不用，还能自定义
装饰模式，首先可以根据它的名字去理解。例如这样的一个场景，早起要穿衣服，穿哪一件呢？你可以T恤加牛仔加拖鞋的屌丝风；也可以西服领带皮鞋的绅士风；还能大T恤垮裤破球鞋的嘻哈路线；。。。。也就是说，你怎样搭配都可以，可以随性所欲的把某一件衣服和某一件裤子搭配起来。这样的方式，如果采用简单工厂模式去构造的话，则可能构造出m*n个具体类，也就是全部枚举出来。当然，真实的意图原创 2017-07-27 22:49:38 · 456 阅读 · 0 评论 -
代理模式--让替身帮你去干事儿
代理模式，字面上很容易理解，别人帮你去做，实际上意义也差不多。假设有这样一个情景：有三位同学，分别是，小A，性别男，爱好女；小B，性别女，爱好学习；小C，性别男，爱好小B；小A和小C是很要好的朋友，小A也知道小C喜欢小B。但是小C是个内向的男孩，因而经常性的要小A出面做一些事，比如给小B送情书，巧克力之类的。日复一日年复一年，结果猜得到，小A和小B在一起了哈哈哈。。。原创 2017-07-28 10:05:02 · 527 阅读 · 0 评论 -
工厂方法模式--简单工厂的再抽象
又是一个名字里面有工厂的模式，首先一个问题，不免的会和简单工厂模式比较，并且很可能会混淆。为了更好的与简单工厂模式比较，这里还是以简单工厂时举的计算器的例子例子来说明。传送门：简单工厂--造啥做啥 这篇文章中，要求实现一个计算器的功能，我们开始使用了简单工厂的模式，也就是把加减乘除的各种运算都抽象出来了，并且各司其职，在不同的Operation类里面完成不同的操作。最后，在统一原创 2017-07-28 11:57:06 · 428 阅读 · 0 评论 -
原型模式--自我复制（结合Java浅复制与深复制）
原型模式，字面上的理解，以原型为标杆的模式。原型模式其实就是从一个对象再创建另外一个可定制对象，而且不需知道任何创建的细节。我们可以用原型示例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。Java里面一个比较典型的就是Cloneable接口，通过实现Cloneable接口，我们可以进行对象的复制，这里当然就会讲到浅复制与深复制。首先来看看原型模式的类图吧：这原创 2017-07-28 16:09:44 · 729 阅读 · 0 评论 -
模板方法模式--大步骤一样小实现不同
听名字来说，模板方法，就是，方法是个模板，必须要按照模板来。没错，差不多就是这个意思。模板方法模式：定义了一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可冲定义该算法的某些特定步骤。也就是这样：模板方法是通过不不变的行为搬移到超类，去除子类中重复代码来体现它的优势。因此模板方法提供了一个很好的代码复用平台。首先还是来看看类图原创 2017-07-28 16:53:08 · 474 阅读 · 0 评论 -
外观模式--你指挥大管家就可以了
外观模式，英文表述为Facade。外观模式，为了子系统中的一组接口提供一个一致的界面，次模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。通俗的讲，比如有很多机器，他们分别可以完成不同的功能，你可以自己直接按照流程去操作他们，也可以招一个大管家，直接跟他说你想什么，让他去操作就行了。外观模式还是很好理解的，先看看类图熟悉下框架结构：其中包括四个子系原创 2017-07-28 20:53:26 · 539 阅读 · 0 评论 -
建造者模式--一种更好的方法去装配复杂的实例
试想可能有这样一种情况，公司要造一个机器人，老大决定把这个艰巨的任务交给你。你就去做了，一步一步来：先造头，再造一个身子，再造一个左手，再造一个右手，再造一个左脚，再造一个右脚。一段时间后你完成了任务，老大看你玩的十分的出色，就又让你去造一只猫，紧接着你又去做了，一步一步来：先造头，再造一个身子，再造一个左手，再造一个右手，再造一个左脚，原创 2017-07-28 22:40:25 · 969 阅读 · 0 评论 -
观察者模式--帮我把个风
观察者模式，从名字来讲就是观察的意思，一个比较有意思的例子，考试作弊是怎样的？一个或者多个望风的，其他的紧锣密鼓的抄，一有情况，赶紧停下来。没错，观察者模式也大概就是这样的流程。先看类图：上述类图为了使程序代码更容易扩展，将subject和observer都抽象出来了一层，降低了耦合度。观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题原创 2017-07-29 10:38:23 · 384 阅读 · 0 评论 -
抽象工厂模式
相对于开始讲的简单工厂模式和工厂方法模式，抽象工厂模式则是进一步抽象我觉得。比如在之前的需求上，进一步增加需求，整个需求在原需求的范围之外。很平常的一个例子就是更换数据库，你的dao层代码可能会要大改，因为大部分数据库语言会有差异。当然这里插入一点，如果使用框架的话，可能改动的较少，比如hibernate，他都帮你封装好了，其实也改了，只是是hibernate帮你改好了，你不用原创 2017-07-29 12:13:17 · 398 阅读 · 0 评论 -
状态模式--将条件拆分出去的漂亮方法
或许很多人都遇到过这样的一种状况：写代码时，有好多不同的条件，以前最开始喜欢用if/else来进行，但是当if/else语句达到三层时，就已经非常难维护的，是极不推荐的。后来学到了switch，就开始用switch来完成功能，但switch不能分割，也就导致了switch所在的那个类代码量很多很杂。这种判断总的来说是一种状态的转移，不同的状态对应的不同的处理逻辑。这就要使用原创 2017-07-29 14:28:53 · 795 阅读 · 0 评论 -
适配器模式--不要和装饰模式混淆了
一开始看适配器模式的时候，我也感觉有点和装饰模式混淆了，这里先贴张装饰模式的类图：传送门：装饰模式--可用或不用，还能自定义装饰模式，目的是为了在原有类功能的基础上，扩展其他功能而有的，这种模式很好的应用了开放封闭原则，不动原来的类基础上去增加或修改其他功能。另一方面，适配器模式，设计的目的是在接口不符合的情况下，增加一个适配器是的，原来由于接口不兼容而无法原创 2017-07-29 15:17:33 · 436 阅读 · 0 评论 -
备忘录模式--敲代码记得Ctrl+s
备忘录模式（Memento）：在不破坏封装性的前提下，波或一个对象的内部状态，并在改对象之外保存这个状态。这样以后就可以将改对象恢复到保存的状态。很常见的一个情景就是在玩游戏的时候，可能某一次你连过8关，但是第9关很难，于是你死了，当你再开始以为能直接打第9关时，发现没有保存游戏进度，于是你又必须从第1关开始打。。。。略杯具。备忘录模式则可以很好的解决这原创 2017-07-29 16:34:40 · 687 阅读 · 0 评论 -
组合模式--部分与整体的解决方案
其实我一开始念组合模式的时候，差点和建造者模式混淆，我以为就是多个子部分组合到一起，然后就是差不多组合模式。然后我发现我的第一感觉是错误的。先看个类图吧：类图十分的简单。并且第一眼看去，Leaf和Composite几乎一模一样，为什么这就是组合模式的类图呢？可以通过一个情景来加深印象：假设一个公司让给做员工OA系统，包括总部的系统，以及众多分公司原创 2017-07-29 17:40:03 · 1122 阅读 · 0 评论 -
迭代器模式--没错就是Iterator
相信Java中的Iterator很多人都用过，而本文却不是介绍Iterator的，而是介绍Iterator中用到的迭代器模式。迭代器模式（Iterator），提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。一个聚集对象，而不管这些对象是什么都需要遍历的时候，你就应该考虑用迭代器模式。下面看看类图吧：原创 2017-07-29 20:19:57 · 477 阅读 · 0 评论 -
桥接模式--继承并不一定总是最优
或许一般敲代码时，总会想到用继承或者实现接口的方式来使得代码结构最清晰，最易于维护。但是呢，正如标题所说的，并不是所有的情况继承都是最好的。看下面一个例子。在过去传统手机时代，也就是诺基亚称王的时代，当时不同的手机软件是互相不兼容的（不像现在就两个操作系统Android和IOS）。那么问题来了类结构应该如何设计呢？先看下面这个类图：再进一步就是这样：原创 2017-07-29 21:58:44 · 788 阅读 · 0 评论 -
命令模式
命令模式（Command），将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。也就是可以把命令队列统一的封装起来由特定的执行者统一执行。新加入的具体命令类不影响其他的类，因此增加新的具体命令类很容易。另一方面，命令模式把请求一个操作对象与怎么执行一个操作对象分隔开来了。实现了解耦合的思想。下面看基本类图：原创 2017-07-29 23:47:16 · 421 阅读 · 0 评论 -
职责链模式--解决不了的事往上传
职责链模式（Chain of Responsibility）：使得多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这个对象连城一条链，并沿着这条连传递该请求，直到有一个对象处理它为止。一个现实中的例子就是，你要求加薪，然后你跟经理说，经理又去找了人力资源总监谈了谈，人力资源总监又说去跟总经理聊一聊。这样可以看出，如果当前对象能够处理，就自己处理，处理不了原创 2017-07-30 11:55:37 · 420 阅读 · 0 评论 -
中介者模式--充当联合国的角色
中介者模式，听名字应该很好理解。中介者模式（Mediator），用一个中介对象来封装一系列的对象交互，中介者是对象不需要显式的的相互引用，从而使其耦合松散，而且可以独立的改变他们之间的交互。也就是两个类不自己关联，而给中介者去完成相互之间的事情。先看类图吧：如上图，ConcreteColleague1和ConcreteColleague2分别是两个具体的待交互的原创 2017-07-30 12:57:48 · 1625 阅读 · 0 评论 -
享元模式--共享的思想
享元模式（Flyweight）：运用共享的技术有效的支持打细粒度的对象。也就是可以以对象的规格，来实现共享及代码复用。事实上，享元模式可以避免大量非常相似类的开销。在程序设计中，有时需要生成大量细粒度的类实例来表示数据。如果发现除了几个小参数之外实例基本相同，又是就能够大幅度减少实例化类的数量。如果能把那些几个参数移到实例外面，在方法调用时将他们传递进来，就可以通过共享原创 2017-07-30 15:43:45 · 491 阅读 · 0 评论 -
解释器模式--注重的解释的思想
解释器模式（Interpreter）:给定一个语言，定义他的文法表示，并且定义一个解释器，这个解释器使用该表示来解释语言中的句子。解释器模式需要解决的是，如果一种特定语言类型的问题发生的频率足够高，那么可能就值得将改问题的各个实例表示为一个简单语言中的句子。这样就构成一个解释器，该解释器通过解释这些句子来解决该问题。其实我感觉解释器模式更加注重的是一种思想，它把用的频率原创 2017-07-30 16:33:14 · 512 阅读 · 0 评论 -
访问者模式--操作是操作，数据是数据
访问者模式（Visitor）：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。具体的意思就是，你有好几个对象（建议不能轻易增加或删除），然后还有好几个基于这几种不同种类对象的操作。这时，就可以把操作和类分开，进而当增加一个新的操作时，并不用动原有的数据结构对象，而仅仅添加一个新类即可。所以说，访问者模式吧数据结原创 2017-07-30 18:17:39 · 508 阅读 · 0 评论