设计模式后的设计理念:需求变化,针对接口编程,优先使用聚合

模式的基本元素:模式的名称,该模式所能解决的问题(模式应用的场景),解决方案,使用该模式后的结果(包括优点和缺点)

模式的分类:

架构模式:架构模式描述了软件系统基本的结构组织策略,实际上就是关于软件的宏观组织的规则和指南

设计模式:设计模式描述的是在软件系统的某一局部不断重现的核心解决方案,这种解决方案以完善的设计结构出现,可以被应用到以后出现的类似的语境中

通用职责分配软件模式(GRASP模式):描述了在面向对象设计过程中把职责分配给系统中不同对象的有效经验和基本原则,GRASP模式只是对职责分配过程中的设计原则的总结和概括,而没有为每一个模式提供建议的具体机构

蕴含在设计模式中的设计原则和理念:

  • 设计模式最根本的意图是适应需求变化:易变性根本就是软件的一个内在的特征;设计模式最大的用途就是适应需求变化,在设计模式的帮助下,我们可以在设计阶段就为未来可能发生的变化留下足够的空间(具体见下面机器人喂猪的案例);只实现你需要的东西,并在这一原则的指导下适度使用设计模式,应该把设计模式的应用范围限制在系统中那些明显不稳定,极有可能变化的部分
  • 针对接口编程,而不是针对实现编程:针对接口编程的组件不需要知道对象的具体类型和实现,只需要知道抽象类定义了那些接口,这减少了实现上的依赖关系
  • 优先使用聚合而不是继承

机器人喂猪案例:

一开始养猪场打算用机器人来喂大白猪:

需求变化一:后来引进了长白猪:

现在的问题就是养猪场的需求不断变化的问题,加入有引进了其他种类的猪或者其他的物种,需要不断修改代码;这是就应该添加一个猪的抽象接口,并且修改猪机器人的代码,使其不考虑猪的类型,只应用抽象的猪的接口来操作所有猪的对象实例

需求变化二:让机器人来打扫猪舍(这可能隐藏了更多的变化的需求,未来机器人的功能还可能不断增加,)

更改一:

但是这里存在一个问题:图中的继承结构是在编译器件就确定了的,在运行期不能发生任何变化,因此,如果养猪场需要一个喂猪机器人和一个清洁机器人,那么必须在养猪场放进这两个具体的机器人,以此类推,如果未来养猪场还需要其他种类机器人时,对象数目很大,而且没添加一种机器人就必须修改代码中的某一个地方,

更改二:

继承和聚合的比较:

  • 继承反映的是类之间的“‘.......是一个.......”这样的关系,它在编译期间静态定义,继承的优点是使用起来比较简单,但是缺点是:不能再运行期间改变继承的结构,基类中往往定义了部分的实现,基类的实现暴露给派生类后,继承机制就会破坏数据和操作的封装,使派生类对基类产生的较强的依赖(相对于聚合而言,该使用还是要使用的)
  • 聚合反映的是类之间“.................有一个.....”的关系,是在运行期间动态定义的,因此被聚合对象的类型可以很容易地在运行期间发生变化,只要保证他们的接口相同,满足完全替换原则即可,而且使用聚合可以更好地封装对象, 使每一个类集中在单个职能上,类的继承层次也会保持较小的规模;缺点是他不是面向对象语言直接支持的一个特性,用户必须编写一些代码来完成聚合功能
  • 在不违反继承和聚合所反映的关系的前提下,应该优先使用聚合而不是继承,同时,聚合也必须和接口及相关的继承结构协同使用
时间: 2024-08-28 04:31:18

设计模式后的设计理念:需求变化,针对接口编程,优先使用聚合的相关文章

针对接口编程

针对接口编程: 针对接口编程,不要针对具体编程是依赖倒转原则的另外一种表述.针对接口编程又称为面向接口编程,针对接口编程就是要先设计一系列的接口,把设计和实现分离开. 其核心思想是,我们只提供你使用的接口,接口中的代码如何实现的我们不管,你可以更改接口中的内容,但接口的使用方法是永远也不会改变的. 以下用一个例子来说明,什么是针对接口编程. 加密解密是我们用的比较多的东西,有时候,公司开发的过程中用到了一种加密算法,输入字符串后经过加密算法处理了,然后输出加密过的字符串.可能一开始用的是一种加密

针对接口编程能帮助达到面向对象开发和设计中"低耦合"的要求. 某公司...打印机...(笔试中遇到的题目)

针对接口编程能帮助达到面向对象开发和设计中"低耦合"的要求.         举个例子:某公司有一台特殊打印机,还可以使用一年,一年后可能换为另一种打印机,这两种打印机都特殊而贵.所以现在的程序希望换了打印机后也少量修改就可用.       方法:       1,定义一个打印机接口.       2,定义打印机类A,B,分别实现此接口.       3,定义一个工厂类,在类中可选择返回由A实现的接口,或者由B实现的接口.       4,在程序中使用打印机时,就可以使用工厂类来调用打

设计模式的6大原则:也是编程者编程时应该追求和遵循的

1.开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭.在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果.所以一句话概括就是:为了使程序的扩展性好,易于维护和升级.想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点. PS:曾经笔者面试的时候,被问过,为何要使用接口编程,那个时候我答不上来,准确说是没深入了解开闭原则之前,我都不能答上. 2.里氏代换原则(Liskov Substitution Principl

2017年,企业移动化的需求变化与创新解决方案

企业移动化说了很多年,是一个经久不衰的话题.随着时间推移,时代变迁,企业在移动化方面的需求也在不断更新.智能终端设备的普及,推动互联网真正走进万物互联的时代.相比PC时代,移动互联网时代更加碎片化.场景化.设备化.在未来,企业进行数字化转型或成发展趋势.因为数据是提升企业核心竞争力的重要一环.那么,企业如何建立高效.融合.安全的数据流?面对万物互联时代多设备.多应用的挑战,如何实现人与数据的无缝连接?从01年工作至今一直服务于企业,个人经历也紧随IT建设行业背景转移的资深技术人云适配技术研究院院

设计模式六大原则(4):接口隔离原则(Interface Segregation Principle)

接口隔离原则: 使用多个专门的接口比使用单一的总接口要好. 一个类对另外一个类的依赖性应当是建立在最小的接口上的. 一个接口代表一个角色,不应当将不同的角色都交给一个接口.没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染. "不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构."这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法,那么这些客户就会面临由于这些不使用的方法的改变所带来的改变. 定义:

把需求变化带来的代码修改成本降至最低的一种方法

为解决工作中一些繁琐的问题, 写了一个GUI程序, 操作界面是这个样子的 这个程序的实现起来并不是非常的繁琐, 但在界面的交互操作上, 也不仅仅只是展示数据. 如上面图片所见,列表中的每一条记录每一个数据项都需要可以填写和选择: 需要添加和删除记录:还需要调整记录的位置:向上移动.向下移动:要实现这些操作, 控制UI的程序其实挺复杂的. 我哼哧哼哧的把这个程序写完, 拿去给同事们演示使用方法, 同事们给我提出了不少的建议. 其中的一条是:把界面分割成上下两部份的方式替代列表中类型字段的选择, 以

从头认识设计模式-策略模式-05-引入设计原则:面向接口编程

这一章节我们来讨论一下怎么解决上一章节扩展性差的问题. 1.解决方案 面向接口编程 2.思路 使用java的多态性,动态的设置导入导出的行为 3.代码清单 在Base里面使用导入导出的接口,然后增加一个通用的导出导入方法,下面的实现中,我们只需要设置不同的导入导出行为,即可通过导入导出方法来实现不同的导入导出结果. package com.raylee.designpattern.strategy.ch05; /** * 1.0 这个类是我们需要使用设计模式改进的原始类,也就是策略模式应用的初始

设计模式六大原则(4):接口隔离原则(转载)

设计模式六大原则(4):接口隔离原则 定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: (图1  未遵循接口隔离原则的设计) 这个图的意思是:类A依赖接口I中的方法1.方法2.方法

搞定需求变化

坊间流传一句话--"杀一个程序员不用枪,改三次需求就可以了".问君能有几多愁,恰似调完代码改需求.需求变化是程序员眼中最大的痛,没有之一. 对程序员来讲,最理想的情况是,需求定下来后,直到软件交付都不发生一次变化.然而,需求的变化却是客观存在,无论你接受与否,稍微复杂点儿的项目,需求变化都是难以避免的事.所以,我们既要了解需求为什么说变就变,又要修炼面对需求的心态,,还要知道怎样控制需求变化. 老板为什么老调整需求 有位朋友在微信的一个群里问我: 安老师,如何保证项目进度呢?目前我们采