概述
结构型模式中总共包含7个模式
1. 适配器模式(Adapter)
2. 桥接模式(Bridge)
3. 组合模式(Composite)
4. 装饰模式(Decorator)
5. 外观模式(Facade)
6. 享元模式(Flyweight)
7. 代理模式(Proxy)
接下来分别进行总结。
适配器模式
将一个类的接口转换成客户希望的另外一个接口
适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
实战例子:
外籍中锋的翻译器
首先为外籍中锋建立一个类
然后建立一个翻译者 这个翻译者是普通的球员 和其他球员一样
然后翻译者和其他球员听教练讲话 讲完话之后 翻译者 告诉外籍中锋 该干什么
好处是客户代码可以统一调用同一个接口就好了
这样可以更简单 更直接 更紧凑
适合场所
1使用一个已经存在的类 但是如果它的接口 也就是他的方法和你的要求不相同时 就应该考虑使用这个模式
2 在双方都不太容易修改的时候使用这个模式
3 两个类所做的事情相同或者相似 但是具有不同的接口时 使用这个模式
以上就是适配器模式的总结
桥接模式
将抽象部分与它的实现部分分离 使他们都可以独立地变化
什么叫抽象与它的实现分离
这并不是说 让抽象类与其派生类分离 因为这没有任何意义 实现指的是抽象类和它的派生类用来实现自己的对象
实战例子:
手机M和手机N 通讯录软件和音乐播放软件
首先建立一个手机软件抽象类
然后建立音乐播放软件 继承 手机软件抽象类
然后建立通讯录软件 继承 手机软件抽象类
然后建立一个手机类型的抽象类
然后建立一个手机继承手机类型抽象类
最后将音乐播放功能set进手机调用operation方法实现功能
好处是优先使用合成/聚合而不是类的继承 遵守开放-封闭原则 减低耦合度
桥接模式将抽象部分与它的实现部分分离
意思是 实现系统可能有多角度分类 每一种分类都有可能变化 那么就把这种多角度分离出来让它们独立变化 减少它们之间的耦合
适合场所实现系统可能有多角度分类的
以上就是桥接模式的总结了
组合模式
将对象组合成树形结构以表示部分-整体的层次结构
组合模式使得用户对单个对象和组合对象的使用具有一致性
实战例子:
某公司总部和上海分部有相同组织结构
首先建立一个抽象公司类
然后建立公司总部类 继承 抽象公司类
并且在类中添加各种方法 其中add方法的形参是抽象公司类
然后建立人力资源等等部门 继承 抽象公司类
由于不是公司 只是公司内部的部门 所以 抽象公司类中的add和remove等方法 不能够实现 为了整体一致 也就是透明方式 所以 还是要写上
最后实现的时候
建立一个总公司让总公司里边add上各种部门
建立一个上海分公司让分公司内add上需要的部门
然后总公司.add(上海分公司)
这样就可以了
好处是组合模式定义了包含人力资源部和财务部这些基本对象 和 分公司办事处等组合对象的类层次结构
基本对象可以被组合成更复杂的组合对象
而这个组合对象又可以被组合 这样不断地递归下去
客户代码中 任何用到基本对象的地方都可以使用组合对象了
用户是不关心到底是处理一个叶子节点还是处理一个组合组件 也就用不着为定义组合而写一些选择判断语句了
简单的说 组合模式让客户可以一致地使用组合结构和单个对象
使用场所
需求中是体现部分与整体层次的结构式以及你希望用户可以忽略组合对象与单个对象的不同 统一地使用组合结构中的所有对象时就应该考虑用组合模式了
以上就是组合模式的总结了
装饰模式
动态地给一个对象添加一些额外的职责
就增加功能来说 装饰模式比生成子类更为灵活
实战例子:
给XX配装穿衣服
首先建立一个人的类 里边有show方法
然后建立一个服饰类 里边有set人的方法 同时也有show的方法
然后建立具体的服饰 继承 服饰类
最后在实现的时候
建立一个人然后建立一个衣服
让衣服.set人(人)
建立一个裤子让裤子.set人(衣服)
建立一双鞋子让鞋子.set人(裤子)
这样就实现了动态改变人的穿着的过程
当系统需要新功能的时候向旧的类中添加新的代码
这些新加的代码通常装饰了原有类的核心职责或主要行为
在主类中加入了新的字段新的方法和新的逻辑从而增加了主类的复杂度
而这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要
而装饰模式却提供了一个非常好的解决方案
它把每个要装饰的功能放在单独的类中并让这个类包装它所要装饰的对象
因此当需要执行特殊行为时 客户代码就可以在运行时根据需要有选择地按顺序地使用装饰功能包装对象了
好处是把类中的装饰功能从类中搬移出去
这样可以简化原有的类 有效地把类的核心职责和装饰功能区分开了
而且可以去除相关类中重复的装饰逻辑
适用场所需要把所需的功能按照正确的顺序串联起来进行控制的时候
或者不能采用生成子类的方式进行扩充时
或者处理那些可以撤销的职责时
或者需要在不影响其他对象的情况下 以动态透明的方式给单个对象添加职责时 就使用这个模式
以上就是装饰模式的总结了
外观模式
为子系统中的一组接口提供一个一致的界面
此模式定义了一个高层接口 这个接口使得这一个子系统更加容易使用
实战例子:
委托炒股和基金也就是操盘手
首先建立几个想要做的方法类
然后创建一个外观类 并在外观类中建立几个不同的方法
然后在方法中根据自己的需要添加之前建立的方法类
最后客户端代码直接调用外观类中的方法就可以实现调用方法类的目的了
适用场所
首先在设计初期阶段 应该要有意识的将不同的两个层分离 层与层之间建立外观
其次在开发阶段 子系统往往因为不断的重构演化而变得越来越复杂 增加外观可以提供一个简单的接口 减少它们之间的依赖
第三在维护一个遗留的大型系统时 可能这个系统已经非常难以维护和扩展了 这时 可以为新系统开发一个外观类 来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口
让新系统与外观对象交互 外观与遗留代码交互所有复杂的工作
以上就是外观模式的总结了
享元模式
运用共享技术有效的支持大量细粒度的对象
实战例子:
开发多个相同的网站或者 java中的String的实现方式
首先建立一个USER类里边有取得name的方法
然后建立一个抽象的网站类里边有一个use方法 方法的形参是USER类
然后建立一个网站类的实例实现这个use方法
然后建立一个网站工厂类 get方法的时候如果已经实例过一样的网站了 就返回这个实例 如果没有实例过 就新实例一次
最后客户端实现的时候
先建立一个工厂类 让工厂去get一个网站实例 网站类型用形参传进去
然后网站类的USE方法将USER传进去就完成了
好处是
享元模式可以避免大量非常相似的开销
在程序设计中 有时需要生成大量细粒度的类实例来表示数据
如果能发现这些实例除了几个参数外基本上都是相同的 有时就能够受大幅度地减少需要实例化的类的数量
如果能把那些参数移到类实例的外面 在方法调用时将他们传递进来 就可以通过共享大幅度地减少单个实例的数目
适用场合
如果一个应用程序使用了大量的对象 而大量的这些对象造成了很大的存储开销时就应该考虑使用
还有就是对象的大多数状态可以变为外部状态
还有就是如果删除对象的外部状态 那么可以用相对较少的共享对象取代很多组对象 此时可以考虑使用享元模式
以上就是享元模式的总结了
代理模式
为其他对象提供一种代理以控制对这个对象的访问
首先建立一个抽象的请求类
然后建立一个真实的请求继承请求类
然后建立一个代理 继承 请求类 但是里边具体的请求除了有真实的请求之外 还有自己添加的东西
最后客户端直接建立一个代理
然后用代理的请求就可以了
适用场合
第一远程代理 也就是为一个对象在不同的地址空间提供一个本地的代理对象 这样可以隐藏一个对象存在于不同地址空间的事实
第二虚拟代理 是根据需要创建开销很大的对象 通过建立一个小开销的代理对象来存放实例化需要很长时间的真实对象
第三安全代理 用来控制真实对象访问时的权限
第四智能指引 是指当调用真实的对象时 代理处理另外一些事
典型的用途包括:对指向实际对象的引用计数,这样当该对象没有引用时,可以被自动释放;
当第一次引用一个持久对象时,将它装入内存;
在访问一个实际对象前,检查是否已经锁定了它,以确保其他对象不能改变它
以上就是代理模式的总结了
结构型设计模式涉及如何组合类和对象以获得更大的结构
结构型类模式采用继承机制来组合接口或实现
一个简单的例子是采用多重继承方法将两个以上的类组合成一个类 结果这个类包含了所有父类的性质
这一模式尤其有助于多个独立开发的类库协同工作
结构型对象模式不是对接口和实现进行组合 而是描述了如何对一些对象进行组合 从而实现新功能的一些方法
因为可以在运行时刻改变对象的组合关系 所以对象组合方式具有更大的灵活性 而这种机制用静态类组合是不可能实现的
结构型模式模式的总结到此就结束了
最后
以上就是勤劳灰狼为你收集整理的java设计模式总结篇--结构型模式的全部内容,希望文章能够帮你解决java设计模式总结篇--结构型模式所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复