zoukankan      html  css  js  c++  java
  • UML与设计模式

    大部分时候写的代码太乱了,找点逻辑看看。这个是从《人人都懂设计模式》里摘录的,加上我可能用到的理解。写给自己参考的。花了3天读了一下。

    UML常见关系

    泛化

    一种实现形式,从基类到特定的子类。最为常用,空心箭头,实线。

    实现

    实现的强弱关系和泛化一样,不一样的是父类为接口,使用的是虚线而不是实线。

    组合

    在visio里较复合,其中被聚合的部分离开整体后无法单独存在。因此关系之间更强。实心菱形,实线。电脑为调用者,组件为被调用者。

    聚合 

    被聚合的类可以离开整体而单独存在。公司为调用者,员工为被调用者。

     关联

    一种调用关系,从调用者指向被调用者,调用者操作被调用者的类。为下图上面。

     依赖

    一种调用关系,从调用者指向被调用者,调用者操作被调用者的方法。为下图下面。

     监听模式

    1. 创建被观察者和观察者

    2. 将观察者添加到被观测者列表

    3. 对被观测者进行数据操作

    4. 被观察者通过观察者的内部方法访问,对其进行通知

    5. 通知过程中,观察者可能需要通过被观察者的内部方法访问,获得数据信息。

    状态模式

    1.【用户】创建上下文环境实现类

    2. 【上下文环境实现类】添加状态类到上下文环境类中的数组

    3. 【用户】调用上下文环境类的行为

    4. 【上下文环境实现类】根据当前的状态调用对应状态的行为

    5. 【用户】改变上下文环境类的属性信息

    6. 【上下文环境实现类】根据改变的信息遍历状态,获取状态的行为信息

    中介模式

    1. 创建中介对象

    2. 创建交互对象

    3.交互对象中传入中介对象方法,添加交互对象到中介对象

    4. 用户对象中传入中介对象方法,获取中介对象提供的服务,间接知道交互对象

    【交互复杂度转换为了中介的复杂度导致的中介复杂,多个使用者等问题】

     

     装饰模式

    【组件1和组件2为出口,装饰器为栈调用形式,每个装饰器实现中存放了上一个装饰器实现,最深的一层为组件】

    1. 【用户】创建组件1

    2. 【用户】创建装饰器1,并将组件1传入装饰器1,得到装饰器1

    3. 【用户】创建装饰器2,并将装饰器1传入装饰器2,得到装饰器2

    4. 【用户】调用装饰器的函数功能,【函数功能】调用自身的【添加行为】方法,对存放的上一层【函数功能】进行调用。

    5. 【最后一层】【函数功能】为组件,调用组件的函数功能,最后调用栈向上走,到最后一程装饰器的【函数功能】

    6.  结束

     

    单例模式

    【使得用户只能从该类中创建一个对象,继续创建则返回第一个创建的对象实例】

    【匿名对象好像默认就是单例的啊,创建的地址都一个】

    1. 重写__new__方法,当首次创建对象,则将实例保存,后续创建则使用第一次的实例,保存的位置为类的私有变量,__init__方法修改为首次创建,则进行初始化,否则不初始化。首次创建的flag存放在类的私有变量。

    2. 自定义metaclass

    3. 自定义装饰器实现。

    def decoder_x(cls, *args, **kwargs):
        instance = {}
        def wrap_x(*args, **kwargs):
            if cls not in instance:
                instance[cls] = cls(*args, **kwargs)
            return instance[cls]
    return wrap_x

     

     克隆模式

    克隆出一样的,然后修改吧,deepcopy

     职责模式

    1. 创建请求者和责任者们

    2. 为请求者和责任者创建上层责任者

    3. 【用户】发送请求,责任者1处理请求,然后判断是否调用上层责任者

    4.  上层责任者依次处理请求。

     代理模式

    【这里的客户端指代用户】

    1. 【用户】创建真实主题类

    2. 【用户】创建代理主题类,并将真实主题类传入

    3. 【用户】对【代理主题类】发送请求,代理主题类经过前处理,访问真实主题类,后处理,完成请求过程。

     外观模式

    【外观模式为复杂的子系统提供了一层抽象,当子系统无法真实维护,但又可用,创建对外的统一接口,方便使用】

    【客户端和用户含义相同】

    1.【用户】创建外观类

    2.【外观类】挂载子系统类

    3.【用户】操作外观类,【外观类】访问子系统,完成功能。

     迭代模式

    【迭代器模式,客户端一般通过next方法获取下一个元素等】

    iter函数将可迭代数据类型转换为迭代器类型,可使用next方法。

     组合模式

    1. 【用户】创建一些组成部分

    2. 【用户】添加一些组件到各个组成部分

    3. 【用户】将子组成部分添加到组成部分

    4. 【用户】最大的组成部分执行操作,如显示特征,则逐个调用。

    【组成部分的聚合关系,表示了组成部分会遍历其组件】

     构建模式

    1. 【用户】创建构建者

    2. 【用户】调用构建产品

    3. 【构建者】创建并构建对应的产品

     适配模式

    1. 【客户端】调用其他目标类的实现,正常

    2. 【客户端】间接调用被适配对象,则通过适配器【直接】调用,适配器通过对被适配对象的修正,完成访问的方法。

    【和什么外观模式,代理模式还有点像哈】

     策略模式

    1. 【用户】创建上下文环境(它是需要策略的)

    2. 【用户】创建策略如策略1,并将其装入上下文环境中

    3. 【用户】执行上下文操作接口,【上下文环境】调用对应的策略执行动作。

    sorted重写比较器就是这样简单的

    工厂模式

    我觉得工厂模式有点乱,可能是比较灵活的原因。其中UML绘制可能有点出入,但是大体思想是从工厂里,创建并返回对象。

    可能二级工厂就够了,这个是三级的,不过用起来应该会很方便吧。

    1. 【用户】创建工厂,如工厂1

    2. 【用户】操作工厂,传入参数,工厂根据参数对产品创建,返回产品。

    3. 【用户】操作产品的方法,完成任务。

     命令模式

     我这里修改了客户端到调度者、命令为实线箭头。

    【客户端和用户同义】

    1. 【用户】创建调度者

    2. 【用户】创建命令

    3. 【用户】将命令放入调度者中

    4. 【调度者】根据命令,选择执行命令,【命令】访问【接收和执行】,执行直接内容。

     备忘模式

    1. 【用户】创建发起人

    2. 【用户】对发起人写入数据

    3. 【用户】调用发起人创建备忘录

    4. 【用户】创建备忘录管理器,将备忘录插入管理器

    5. 【用户】从备忘录管理器中获取备忘录,调用发起人,传入备忘录,从而恢复数据

    享元模式

    【客户端理解为用户,用户在访问工厂中的产品时,因资源限制,这些产品是公共享用的,且只生成一次(set判断)】

    1. 【用户】创建轻量级工厂,传入参数获得指定轻量级

    2. 【轻量级工厂】根据是否创建了对应的轻量级,来动态创建轻量级,并返回给用户

    3. 【用户】操作轻量级,完成功能。

    非共享轻量级可能和工厂模式或者构建模式像。

    访问模式 

    【客户端是用户】

    1. 【用户】创建数据结构管理器,创建数据节点

    2. 【用户】将数据节点插入数据结构管理器中

    3. 【用户】创建访问者,将访问者传入数据结构管理器,执行动作。

    4.  【数据结构管理器】执行客户端行为,调用数据节点的访问方法

    5. 【数据节点】调用访问者的访问方法,完成访问操作。

     模板模式

    我觉得就是抽象类和具体类的区别吧,一套公用的接口,然后大家都实现它。

     桥接模式

    说是和策略模式有点像,我想是这样的:桥接模式是用于对代码重构的思考,如果程序层次性太深或拓展性不够,是否可将下层的部分作为上层的一个组件形式,即聚合关系,桥接到上层。

    【抽象类(形状)实现类(颜色)桥接,从而用户在创建形状的时候,尽管有各种形状和各种颜色,但是因为颜色成为一个形状的组件,因此只需关注形状类,而颜色类可以自由拓展】

     解释模式

    【用于表达式的解析和执行上】

    1. 【用户】将数据传入到抽象表达式中,根据表达式常用的思路,以栈的形式首先对表达式解析,然后存储到栈中。

    2. 【抽象表达式】通过逐层调用,找到最内部的表达式,解析并将结果返回给上层表达式。

    3. 以此类推,获得最终结果。




    Le vent se lève! . . . il faut tenter de vivre!


    Le vent se lève! . . . il faut tenter de vivre!
  • 相关阅读:
    【01】Maven依赖插件之maven-dependency-plugin
    docker(六) 使用docker-maven-plugin插件构建docker镜像
    SpringBoot 打包配置去除第三方依赖包
    maven打包为jar文件时,解决scope为system的jar包无法被打包进jar文件的解决方案。
    SpringBoot入门之spring-boot-maven-plugin
    SpringBoot系列之—瘦身部署
    java之mybatis之模糊查询
    java之mybatis之查询及分页
    java之mybatis之占位符
    java之mybatis之使用mybatis实现crud操作
  • 原文地址:https://www.cnblogs.com/bai2018/p/15477195.html
Copyright © 2011-2022 走看看