zoukankan      html  css  js  c++  java
  • 设计模式学习大体总结

    一个月带着读看完了设计模式,其中有一些模式真的是被坑着了,比如composite组合模式如果不用叶节点,真说不出有什么特性。再比如备忘录模式,我觉得这个模式的核心是打包传递数据,而不是用来备忘。好了,先写一个总结,以后慢慢消化

    每个模式如果细说肯定不是三言两语可以概括的,但是需要简略概括,才能快速理解。

    ============================================================

    简单工厂模式

    针对一个类型多个子类的创建控制,或者说针对一个接口多种实现的控制。

    最早的时候对于抽象类我有这样一个问题,接口前面加I,抽象类前面是不是应该加Abs。这个问题纠结了很久,后来突然明白了

    抽象类就是一个类型的统称

    鸟 = 鹰

    鸟 = 麻雀

    不存在任何加Abs前缀的理由。扯远了。。

    简单工厂就是这样一个管理工具,不用自己再去new,再去找了。方便了代码的使用者

    鸟 = 鸟工厂.鹰();

    工厂模式,抽象工厂模式

    这个没弄明白,目前的理解是。针对创建的创建,而进行管理。

    可以把多个工厂混合在一块,而他们的创建提取为接口。

    目前实际项目还没用到过

    装饰器模式

    简单来说,就是一个链表不断的加东西,当最后运行时,回溯回去

    游戏中buff叠加计算也可以用这个模式

    可能无意中就会用到这个模式

    组合模式

    这个模式就是装饰器模式的树形结构版本

    这个模式比较恶心。。说2点个人想法。

    第一 不用叶节点,当前节点的子节点用null代替。效果一样

    第二 这个模式的特点是把获取数据和节点搜索分开成2个接口(安全型和透明型,其中透明型违反了李氏代换原则)。真的不知道看完之后学到了什么

    命令模式

    把命令的请求者和命令的执行者分开,如果发现一个类同时扮演这2个角色,就要考虑这个模式了。

    是在请求者和执行者中间加一个"命令管理器",命令的请求者在需要的时候给命令管理器添加任务就可以了。

    行为型模式往往是思路的转变,要在使用中理解。 

    职责链模式

    这个模式个人感觉不错,代码可读性加分

    举个例子,某某Boss带一群小弟出去吃饭

    Boss只管吃饭,聊天,付钱。他不会去管选哪家酒店,这家酒店停车位在哪,停车如何收费,怎么预定,点餐方式是什么样的等等。这些都是他的小弟去完成的

    这个模式的关键在于,判断能不能做Can slove,和去做Do something 是分开的。这样逻辑划分明确,代码可读性也就提升了

    状态模式

    首先这个模式千万别和switch case搞混了,完全就不是这种思路了

    职责链模式是,一个环形链表不停的循环(直接for循环也可)。遇到能解决的就跳出循环。

    状态模式是,一个普通链表的指针一直在到处乱跳,可能会跳到结尾就没了,或者各种状态跳个没完。

    它用来解决switch case, if else过多的情况。但在可读性上反而弱了。switch case比较稳定的情况下,千万别用。

    原型模式

    我刚开始看原型模式的时候,认为这个和组合模式一样坑爹的玩意。。

    后来无意中看了一篇博文,才发现是我用的思路不对,其实在代码中是会经常用到的

    我们经常要把一个东西备份一份出来,以后再用来对比。C#是自带了Clone的

    如果不用原型模式,就要把值类型参数一个一个保存下来,等用到的时候再一个一个对比(备忘录模式)

    备忘录模式

    备忘录模式重点不在备忘录上,而是它通过数据包传输数据的概念。

    类之间互相传递的始终都是一个“包”,你不知道是什么。只有用解析的类解析完了,才知道里面是什么。

    另外,备忘录模式里的宽接口,窄接口概念我至今没明白是什么意思。。(不想顾名思义去理解..但是又百度不到)

    这个模式用的也不多

    访问者模式

    这个模式的UML类图确实有点绕,为了实现动态的函数增加,其实不止这一种方法,可以有很多方法

    访问者模式这样做,性能损失是最小的。它不需要判断类型,都是重载的。

    这个模式很容易误用,子类的数量要稳定这个不说了。

    增加的功能,确认是不是每个子类都需要有这个新功能,如果就其中1,2个子类需要。考虑单独弄一个别的类,作为参数传进去处理(use a)

    确定了之后,再选用模式。 

    单例模式

    单例并非只有一个实例的模式。

    线程池,游戏子弹池这种数量约束概念的东西,也可以用上单例

    单例是对实例对象数目的一个约束,懒汉恶汉型我觉得不必过于纠结

    Facade外观模式

    设计模式有4,5种是即使不学设计模式,也会无意中用到的。

    外观模式就在这其中。

    本来我认为没啥用,今天看敏捷开发又看到这个模式,就记一下好了。

    Mediator中介者模式

    外观模式是对外一致访问,达到降低耦合的目的。而中介者模式,是对内部的一个一致访问。

    它把内部模块的交互部分,合并到一个中介者类里面去了。

     把普通代码重构成中介者模式也很简单,先保持对外函数不变,然后把函数里面的实现过程移到中介者类里面实现。

    除非有明显的共性可以提取出来,否则用中介者模式就会有滥用模式的状况,会更难以拓展。

    --------------------------------------------------------------------------------

    好了,就写这个多。有些模式我实在不想写,比如外观模式。还有些模式根本用不到。

    另外,推荐 设计模式纵横谈 这个讲座,在优酷上可以看到。讲的非常好

    把一件事物放到一个时间线上去看待,从变化和不变化中,看出用这个模式和不用这个模式的区别

  • 相关阅读:
    Java中的transient关键字
    【笔记】html的改变(上)
    《开发板 — 实现看门狗》
    《头文件导致Symbol xxx multiply defined重复定义问题分析和解决》
    《APP读取按键值》
    《补充 — Linux内核device结构体分析(转)》
    《设备树LED模板驱动程序》
    《C库 — 字符串和整型数相互转换函数atoi和itoa》
    《Ubuntu — rsync命令》
    《Ubuntu — 2>/dev/null和>/dev/null 2>&1和2>&1>/dev/null的区别》
  • 原文地址:https://www.cnblogs.com/chenliyang/p/6633675.html
Copyright © 2011-2022 走看看