追MM与设计模式的有趣见解(zt)
- 格式:pdf
- 大小:204.10 KB
- 文档页数:7
23种设计模式趣味讲解对设计模式很有意思的诠释,呵呵,原作者不详。
创立型模式1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,固然口味有所不同,但不管你带MM往麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。
麦当劳和肯德基就是生产鸡翅的Factory工厂模式:客户类和工厂类离开。
花费者任何时候需要某种产品,只需向工厂恳求即可。
花费者无须修正就可以接纳新产品。
毛病是当产品修正时,工厂类也要做相应的修正。
如:如何创立及如何向客户端供给。
2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同处所的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM 我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。
(这必定比美军在伊拉克用的翻译机好卖)建造模式:将产品的内部表象和产品的天生过程分割开来,从而使一个建造过程天生具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变更,客户不必知道产品内部组成的细节。
建造模式可以强迫履行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM往麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。
工厂方法模式:核心工厂类不再负责所有产品的创立,而是将具体创立的工作交给子类往做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的串口,而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天,必定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。
一个月下来,把常见的20个设计模式好好复习并且逐个用C++实现了一遍,收获还是很大的,很多东西看上去明白了但是真正动手去做的时候发现其实还是不明白——我深知这个道理,于是不敢怠慢,不敢写什么所谓的解释原理的伪代码,不敢说所谓的"知道原理就可以了"……因为我知道,我还还没有资格说这个话,至少对于设计模式而言我还是一个初学者,唯有踏实和实干才能慢慢的掌握到知识。
在我学习设计模式的过程中,觉得造成理解困难的主要是以下几点,谈一下自己的体会,希望对他人有帮助,不要走上我的老路上,毕竟我花了N长的时间才敢号称自己入门了~~!!-_-:1)Gof并不适合于初学者。
初学设计模式的一般都是从Gof入门开始学习的,不幸的是,这不是一本好的教科书,而把这本书称为一本奠定了设计模式理论基础的开山之作也许好一些,它把这些散落在各个设计中的常见模式收集起来,从此开始有了一个名词叫做"Design Pattern".说这本书不是一本好的教科书主要是以下的几个原因:a)对设计模式或者说面向对象里面的一些原则性的东西解释的不够多不够彻底,比如"面向接口编程而不是对实现编程","优先采用组合而不是继承"等等,以至于后面看到各个模式的实现的时候很多模式看起来很相似却找不到区别和共性的地方。
b)对各个模式的解释或者举出来的例子不是特别的好,大部分都是为了讲解模式而讲解,没有加入前面提到过的一些基本原则的考量在里面,也就是说:原理性的东西和实现(各个设计模式)脱节。
2)初学者对语言或者说一些概念理解的不好。
拿C++来说,为了做到面向对象需要提供的语言上的支持有继承,多态,封装,虚函数,抽象等等,我以前初学C++的时候,只为了学这些概念而去学习,不知道为什么要提供这些特性,这也是造成我走弯路的重要原因之一。
当然,指望一个初学者在初学语言的时候就知道why是一件很困难的事情,也许结合着对设计模式的理解可以帮助你消化这些概念(我就是这样的)。
追MM与设计模式的有趣见解创建型模式1、FACTORY —追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。
麦当劳和肯德基就是生产鸡翅的Factory工厂模式:客户类和工厂类分开。
消费者任何时候需要某种产品,只需向工厂请求即可。
消费者无须修改就可以接纳新产品。
缺点是当产品修改时,工厂类也要做相应的修改。
如:如何创建及如何向客户端提供。
2、BUILDER —MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。
(这一定比美军在伊拉克用的翻译机好卖)建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。
建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。
工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。
(100块钱一份,你要不要)原始模型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。
bim毕业设计思路过程及收获BIM毕业设计思路过程及收获BIM(Building Information Modelling)是一种基于数字化技术的建筑信息模型,能够快速模拟建筑物的运作和设计,并在设计、建造和运营等各个环节中利用相关数据,提高整体效率。
在大学学习期间,我选择了BIM作为我的毕业设计课题,并在整个设计过程中有了收获和感悟。
思路过程:1.确定设计主题首先,我们需要确定毕业设计的主题,考虑到BIM的相关性,我选择了一所小学教学楼的设计来作为我的毕业设计主题。
这个设计主题能够大致涵盖BIM的基本设计思路,并且更贴近建筑设计专业的课程。
2.资料收集在确定了我的设计主题后,我开始收集资料,了解学校的教学楼布局、建筑结构和安全等方面的规定和要求。
同时,我也收集了一些关于BIM技术的资料来帮助我更好地理解和应用BIM技术。
3.建立模型通过收集足够的资料后,我开始建立模型,将学校教学楼的外立面、结构、房间内饰以及其他细节元素建模。
用BIM技术进行的建模可以让我们更好地了解建筑信息,并且方便查看模型内文本信息,以便于我们更好地指导设计。
4.模型分析完成建模后,我使用BIM技术进行了模型分析,使用模拟技术来测试建筑物的风、震、温度和声音等各种因素对建筑物的影响,以及如何在应对字段上使用自动调节技术,以便于提高建筑物的运作效率。
5.优化设计通过模型分析,我找到了一些可能的设计缺陷,例如:建筑物的通风系统未能达到理想效果。
基于这些发现,我对模型进行了优化设计,并使用自动化程序分析器来处理通风系统,以达到更高程度的精度和效率。
收获:1.技术实践的机会BIM毕业设计是我能够应用学到的技术知识并在创造性地解决问题的机会,这是我大学期间技术实践最好的体现。
2.建模和分析的能力BIM技术并非只停留在理论层面,是一种实际建模和分析的能力,在整个设计过程中,我学会了如何建立模型以及如何利用BIM技术来进行模型分析。
3.团队协作的能力毕业设计除了对技术知识的考验,还有团队协作的考验。
1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM 爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。
麦当劳和肯德基就是生产鸡翅的Factory。
工厂模式:客户类和工厂类分开。
消费者任何时候需要某种产品,只需向工厂请求即可。
消费者无须修改就可以接纳新产品。
缺点是当产品修改时,工厂类也要做相应的修改。
如:如何创建及如何向客户端提供。
2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。
(这一定比美军在伊拉克用的翻译机好卖)建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。
建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM 到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。
工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。
(100块钱一份,你要不要)原始模型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。
UI设计:设计追波风!值得每个设计师阅读思考的深度剖析文UI设计分享,火星时代与大家分享一篇来自国外的博文。
此篇文章一经发表即掀起设计圈的一阵轰动,文章言辞虽激烈但一针见血,戳痛处也不忘给干货,现在腾讯的Wellso 同学把它翻译过来,Dribbble大牛务必冷静阅读。
13年底,Intercom的产品VP Paul Adams在Intercom官博发表了一篇博文。
文章讲述了网络上设计社区里普遍存在的一种现象,大意是“许多设计师在社区中分享的作品往往是为了炫技,而产品的逻辑通常都经不起推敲的,真正优秀的设计应该从更高的层面出发,而不只是做表面上的工作”。
文章发布后,在Twitter、HN及博客评论下引起了反响。
虽然部分内容在一些设计师眼里看起来比较有攻击性(也就是俗称“开喷”),甚至还带有些地图炮,但是文中关于“设计的四个层次”以及“when I want to then I can……”等设计观点和方法论都非常值得我们回味并运用到工作当中。
设计追波风这些天气app中,只有一个试图解决用户的实际问题。
现在的产品设计和交互设计界发生了一些奇怪的事情。
一方面有着如Ryan Singer和Julie Zhuo这样能写出很赞的文章的人来推动我们设计水平的发展。
另一方面则是越来越多的人在Dribbble上发布与交流他们的作品,不过最后结果是追波上的这些玩意反而使我们的水平倒退了。
我写这篇文章不是在谈追波的好坏是非,而是想探讨什么才是追波真正的价值。
我会将“产品设计”贯穿始终,尤其是在谈到用户体验和交互设计的时候。
“屌爆了!”Dribbble就是用这种形式来鼓励大家炫技去年我看了不少应聘Facebook和Intercom的求职者的设计作品,然后我发现了一个令人担忧的现象。
太多的设计师都在为吸引同行的关注而做设计,而不是把心思花在解决实际的工作问题上。
这点一直都是广告创意领域才有的毛病(比起优先解决客户需求,做酷炫的作品拿个奖攒点人气似乎更重要),并且,这在产品设计以及交互设计的领域越来越突出。
博客园-探索设计模式(一):开篇探索设计模式开篇——探索设计模式系列之一Terrylee,2005年12月06日前言加入Design & Pattern团队有几个月的时间了,惭愧的是从没有写过关于设计模式的随笔,得到wayfarer的同意,把企业库系列的随笔放在了团队的首页上。
不是不想去写这样的随笔,也不是没有时间,自己初学设计模式,去写设计模式的文章,有点班门弄斧的味道。
园子里吕震宇老师的《设计模式系列》和wayfarer的《设计之道》堪称设计模式里的经典之作。
可是正如wafarer所说的那样,受到发表欲的蛊惑,本着交流就是进步的想法,思考再三,还是决定写这样的随笔,来对设计模式做一些探索和总结,起名曰“探索设计模式”,有些言过其实,就当是记录自己学习设计模式的历程吧,不过还是希望能得到各位前辈的指点!设计模式设计模式是规则吗?地上本没有路,走得人多了也就成了路。
设计模式如同此理,它是经验的传承,并非体系;是被前人发现,经过总结形成了一套某一类问题的一般性解决方案,而不是被设计出来的定性规则;它不像算法那样可以照搬照用。
设计模式是架构吗?架构和模式应该是一个属于相互涵盖的过程,但是总体来说架构更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用,因此在不同层面考虑问题的时候就形成了不同问题域上的模式。
模式的目标是,把共通问题中的不变部分和变化部分分离出来。
不变的部分,就构成了模式,因此,模式是一个经验提取的“准则”,并且在一次一次的实践中得到验证,在不同的层次有不同的模式,小到语言实现,大到架构。
在不同的层面上,模式提供不同层面的指导。
设计模式,软件的永恒之道?这个问题没有答案,有的只是讨论,看一下一位前辈结合建筑学得出的几点心得吧:和建筑结构一样,软件中亦有诸多的“内力”。
和建筑设计一样,软件设计也应该努力疏解系统中的内力,使系统趋于稳定、有生气。
HR追:设计思维2015年,IBM以空前的规模招募设计人员,并在世界各地大量开设以设计思维为主导的工作室。
管理者十分清楚他们必须不断创新以助力企业成长,他们需要了解如何在企业内部试行创新举措。
人力资源管理者当然也不例外。
这就是我们在今天为什么尤其要追逐:设计思维。
人力资源管理者利用设计思维进行工作,可不是想当然地把设计思维等同于设计。
设计思维是用于为寻求未来改进结果的问题或事件提供实用和富有创造性的解决方案,它有一整套设计思维路径图。
利用设计思维工作,这是一个艰苦的工作,但也是有趣的有成就感的工作。
思想时刻在参与,这是一种何其的美丽!在这个“激活个体”的时代,人力资源工作再一次踏上了追寻“设计思维”的艰苦之路!不同于设计你可能首先想到的是让人力资源的工作漂亮实用起来,这当然是一种设计。
今天,信息生成的速度和体量太过惊人,人们必须将之简化才能被理解——此即设计的作用之一。
拿企业雇主品牌来说,通过有趣的信息图很容易引起人们的注意,增加粉丝数量,在社交媒体中是一种非常灵活、流行的传播工具。
甚至信息图可作为网站的链接诱饵,在搜索引擎优化方面可以起到很大的作用。
信息图的应用可以为人力资源部门所用,就像图片中人瑞集团“香草招聘”的信息图不是单纯地平面设计,这个切合时机与对象的整个创意内容,正是人力资源工作者利用设计思维以及设计工具在雇主品牌营销方面常常在使用的最佳实践之一,它也成为企业雇主品牌价值传播的创新解决方案。
追:管理者的设计思维路径设计思维是一种方法论。
设计思维是用于为寻求未来改进结果的问题或事件提供实用和富有创造性的解决方案。
它需要征集不同思路和方法,需要漫思维模型的方式,思想尽量游弋、漫入漫出;而最后沉淀下来的想法,是经层层筛选的,又要依靠聚思维模型。
它是创新地解决问题的过程。
需要人力资源管理者先尽可能多地征集不同思路和方法,再择其一进行精细打磨。
它有一整套设计思维路径图。
设计思维需要人力资源管理者去了解自己的客户,即员工包括自己的老板、需要头脑风暴设想出几种解决方案、需要选择、试验和测试。
纪录片《设计与思考》观后感看了《设计与思考》这部纪录片,突然觉得自己和原研哉所说的一样,越来越不懂设计了。
然而“这并不意味着你对于设计的认知倒退了,而是证明你在设计的世界里又往更深处迈进了一步”,所以归根结底,这种意犹未尽的感觉是因为我对设计这个异彩纷呈的世界越来越高涨的热情,以及对设计的意义更加深刻的思考与感知。
设计是什么?在我离设计很远很远的时候,我一直以为他是一个非常简单的名词。
而如今作为一个初学者,它有些神秘,有些美丽,又有点包罗万象,意蕴复杂。
对于这个最基本的问题,这部纪录片并没有给出一个明晰的答案。
但它给了我们弥足宝贵的启示。
通过创新与交流来认识我们生活在其中的世界,这是我在第一章“设计到底是什么”中所认识的设计。
“设计的时代将要来临”。
当初的松下幸之助看到了设计发展前景,二战后的日本产品设计高速成长,并且对质量的追求为规模化、量化的生产提供了品质保证。
日本设计所具有的独特魅力是因为,对如何形成真正具有自身特色的设计思想的思索,在于反思什么样的东西才是“日本的”,在于将现代主义的感觉浸润并融入日本的生活文化中去。
完美是枯燥的。
设计不是工业流水线上生产出来的完美但千篇一律、毫无个性的东西。
真正的设计应该不受教条、规则的束缚,充满想象力,永远在寻找新的、更好的、不同的、不被遗忘的创意。
试着通过不同的眼光来看待事物,才可以寻求新突破。
每个人也要有自己的逻辑体系,不人云亦云。
设计在哪里?设计已经深深的扎根在生活当中,最令我们视而不见、习而不察,而恰恰又离不开的大概就是设计了。
因为生活中的细枝末节,每一个不容忽视的部分,都是设计。
设计也为原本普通的生活,带来不一样的温馨与惊喜,让生活变美、变放松。
“生活本身,就是设计的起源地;而设计,归根结底就是我们对生活的发言。
”什么才是好的设计?没有标准答案。
事实上,哪有那么多好与不好,只要它足够有趣、足够有新意;只要你喜欢,哪怕一件有趣的小物件,也可以将不好变成好,给你带来完全不同的感官享受,让你怦然而心动。
《追求理解的教学设计》读书心得《追求理解的教学设计》读书心得《追求理解的教学设计》读书心得(精选10篇)读完某一作品后,相信大家都积累了属于自己的读书感悟,是时候静下心来好好写写读书心得了。
千万不能认为读书心得随便应付就可以,下面是小编为大家收集的《追求理解的教学设计》读书心得(精选10篇),欢迎大家分享。
《追求理解的教学设计》读书心得1《追求理解的教学设计》是一本非常有价值的书,特别是对于“整体性教学”、“项目式学习”的设计具有指导性的意义。
这本书提出了“逆向设计”的概念和方法和“项目式学习”理念下的学习设计有共同之处,都认为教师在考虑如何开展教与学活动之前,先要努力思考学习要达到的目的到底是什么,关注学习期望,产生适合的教学方式,总的来说就是“以终为始”,从学习结果开始逆向思考。
这个概念和方法对于今天我们为追求有意义、有效果的教学设计以及思考和寻找教师教学行为转变的路径颇有启迪。
这本书对“理解”的概念和实践也都进行了更加深入的阐述和解释,提出了衡量“理解”的一个基本指标是能把所学得知识迁移到新的环境和挑战中,也就是综合应用,而不仅仅是知识的回忆和再现。
这本书还提出了一种课程与教学的设计方法,旨在促使学生参与探究活动,提升学习迁移能力;为学生提供理解概念的框架,帮助他们理解一些零散的知识和技能,并揭示与内容相关的大概念。
通过对大量的教学实践进行积累和总结,本书还提出了一个关于学生理解的单元模板,以协助教师设计课程以评估;围绕大概念、基本问题和核心评估任务提出了如何把教学单元放在一个更大、更连贯、更结构化的课程和项目框架中进行设计的思路和方法;提出了一套在课程和评价中实现质量控制的设计标准。
谈及本书的内容和特色,用三个词概括,即“理解”、“逆向”、“实践智慧”。
它倡导的是关于课程、评估和教学的优秀设计,专注于如何发展和深化对重要观点的理解。
本书的精髓聚焦在一个问题上:我们如何通过教学设计是更多的学生真正理解他们所要学习的知识?因为事实上大部分情况是那些说“懂了”的学生可能仅是凭运气理解了知识,所以我们的教师计划该如何制定,才能使每位学生都受到知识的影响,包括那些缺乏经验的学生,有较高能力但缺乏学习动机的学生、能力稍逊的学生、具有不同兴趣和风格的学生。
MM模型出自 MBA智库百科(/)MM模型(Modigliani Miller Models,米勒一莫迪利安尼模型,公司资本结构与市场价值不相干理论)目录[隐藏]∙ 1 MM模型的含义∙ 2 MM模型的两种类型∙ 3 MM理论的发展∙ 4 MM模型案例分析o 4.1 案例一:基于MM模型的税收效应分析[1]∙ 5 参考文献MM模型的含义MM理论是莫迪格利安尼(Modigliani)和默顿·米勒(Miller)所建立的公司资本结构与市场价值不相干模型的简称。
美国经济学家莫迪格利安尼和米勒于1958年发表的《资本成本、公司财务和投资管理》一书中,提出了最初的MM理论,这时的MM理论不考虑所得税的影响,得出的结论为企业的总价值不受资本结构的影响。
此后,又对该理论做出了修正,加入了所得税的因素,由此而得出的结论为:企业的资本结构影响企业的总价值,负债经营将为公司带来税收节约效应。
该理论为研究资本结构问题提供了一个有用的起点和分析框架。
[编辑]MM模型的两种类型“MM”理论主要有两种类型:无公司税时的MM模型和有公司税时的MM模型。
1)无公司税时MM理论指出,一个公司所有证券持有者的总风险不会因为资本结构的改变而发生变动。
因此,无论公司的融资组合如何,公司的总价值必然相同。
资本市场套利行为的存在,是该假设重要的支持。
套利行为避免了完全替代物在同一市场上会出现不同的售价。
在这里,完全替代物是指两个或两个以上具有相同风险而只有资本结构不同的公司。
MM理论主张,这类公司的总价值应该相等。
可以用公式来定义在无公司税时的公司价值。
把公司的营业净利按一个合适的资本化比率转化为资本就可以确定公司的价值。
公式为:VL=Vu=EBIT/K=EBIT/Ku式中,VL为有杠杆公司的价值,Vu为无杠杆公司的价值;K= Ku为合适的资本化比率,即贴现率;EBIT为息税前净利。
根据无公司税的MM理论,公司价值与公司资本结构无关。
设计模式原则详解这篇文章,不需要你一次就看懂,如果你真的能一次都看懂,我想设计模式对于你来说已经没什么难度了..因为设计模式就是要体现这些原则的,你可以把设计原则看做是一门语言,设计模式是由这些语言编码的程序..你既然已经明白,精通了语言,剩下的编码自然是很简单的事情,编码的越多则经验越多,经验越多则对原则的理解就越深...这是一个学习领悟的过程..我希望这篇文章能帮助新人感受到设计模式的乐趣,避免重复编码....减少劳动量..如果你能在用心静静的体会文章的每个字,每段话的意思,这样可以避免走很多弯路...我以前学习设计模式的时候,就是因为忽略了原则,凭着感觉,看着书来学习设计模式,结果就是知其然而不知其所以然....如果你是初学设计模式,再了解了OOP的三大原则(封套,继承,多态)之后,请反复的结合原则,来学习设计模式..这样可以达到事半功倍的效果...设计模式的核心原则是:"开-闭"原则( Open - Closed Principle 缩写:OCP ),一切的一切都是围绕着"开-闭"原则展开的..意思是,在一个系统中,对于扩展是开放的,对于修改是关闭的,一个好的系统是在不修改源代码的情况下,可以扩展你的功能..而实现开闭原则的关键就是抽象化.在"开-闭"原则中,不允许修改的是抽象的类或者接口,允许扩展的是具体的实现类,抽象类和接口在"开-闭"原则中扮演着极其重要的角色..即要预知可能变化的需求.又预见所有可能已知的扩展..所以在这里"抽象化"是关键!!!可变性的封闭原则:找到系统的可变因素,将它封装起来..这是对"开-闭"原则最好的实现..不要把你的可变因素放在多个类中,或者散落在程序的各个角落..你应该将可变的因素,封套起来..并且切忌不要把所用的可变因素封套在一起..最好的解决办法是,分块封套你的可变因素!!避免超大类,超长类,超长方法的出现!!给你的程序增加艺术气息,将程序艺术化是我们的目标!!里氏代换原则:任何基类可以出现的地方,子类也可以出现..如果你通读过<Java编程思想>,我想你应该明白这个原则,在书中,Bruce Eckel 大师用了大量的章节来讲解"向上转型"和"向下转型",我想目的很清楚,不仅是要你明白类的型别,更重要的是要你明白父类与子类的关系..依赖倒转原则:要依赖抽象,而不要依赖具体的实现..如果说开闭原则是目标,依赖倒转原则是到达"开闭"原则的手段..如果要达到最好的"开闭"原则,就要尽量的遵守依赖倒转原则..可以说依赖倒转原则是对"抽象化"的最好规范!!我个人感觉,依赖倒转原则也是里氏代换原则的补充..你理解了里氏代换原则,再来理解依赖倒转原则应该是很容易的..合成/聚合原则:要尽量使用合成/聚合原则,而不是继承关系达到软件复用的目的..此原则和里氏代换原则氏相辅相成的,两者都是具体实现"开-闭"原则的规范..违反这一原则:就无法实现"开-闭"原则..先来看看什么是合成,什么是聚合.什么是合成?合成:是指一个整体对依托他而存在的关系,例如:一个人对他的房子和家具,其中他的房子和家具是不能被共享的,因为那些东西都是他自己的..并且人没了,这个也关系就没了..这个例子就好像,乌鸡百凤丸这个产品,它是有乌鸡和上等药材合成而来的一样..也比如网络游戏中的武器装备合成一样,多种东西合并为一种超强的东西一样..什么是聚合?聚合:聚合是比合成关系的一种更强的依赖关系,聚合是一个整体对个体的部分,例如,一个奔驰S360汽车,对奔驰S360引擎,奔驰S360轮胎的关系..这些关系就是带有聚合性质的..因为奔驰S360引擎和奔驰S360轮胎他们只能被奔驰S360汽车所用,离开了奔驰S360汽车,它们就失去了存在的意义..在我们的设计中,这样的关系不应该频繁出现..这样会增大设计的耦合度..明白了合成和聚合关系,再来理解合成/聚合原则应该就清楚了..要避免在系统设计中出现,一个类的继承层次超过3次..如果这样的话,可以考虑重构你的代码,或者重新设计结构..当然最好的办法就是考虑使用合成/聚合原则...迪米特法则:系统中的类,尽量不要与其他类互相作用,减少类之间的耦合度,因为在你的系统中,扩展的时候,你可能需要修改这些类,而类与类之间的关系,决定了修改的复杂度,相互作用越多,则修改难度就越大,反之,如果相互作用的越小,则修改起来的难度就越小..例如A类依赖B 类,则B类依赖C类,当你在修改A类的时候,你要考虑B类是否会受到影响,而B类的影响是否又会影响到C类..如果此时C类再依赖D类的话,呵呵,我想这样的修改有的受了..接口隔离法则:这个法则与迪米特法则是相通的,迪米特法则是目的,而接口隔离法则是对迪米特法则的规范..为了做到尽可能小的耦合性,我们需要使用接口来规范类,用接口来约束类.要达到迪米特法则的要求,最好就是实现接口隔离法则,实现接口隔离法则,你也就满足了迪米特法则...如果你能看这里,说明你已经对这些原则了有了感性的认识..这些原则是设计模式的核心,如果不能充分理解这些原则,是很难理解好设计模式的..。
追MM与设计模式(23种设计模式巧妙解析,趣味理解)2017-04-26程序员共读在网络上流畅很广的一篇旧文,暂时没找到原作者,目前所看到的最早转载时间是 2005 年 2 月 28 日。
作者用轻松的语言,形象解释了 23 种模式,有很好的启发作用。
创建型模式1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。
麦当劳和肯德基就是生产鸡翅的Factory工厂模式:客户类和工厂类分开。
消费者任何时候需要某种产品,只需向工厂请求即可。
消费者无须修改就可以接纳新产品。
缺点是当产品修改时,工厂类也要做相应的修改。
如:如何创建及如何向客户端提供。
2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。
(这一定比美军在伊拉克用的翻译机好卖)建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。
建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。
工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。
浅析参数化、模块化三维设计的优势和实施方法1引言对于机械设计,传统的设计方法都是设计人员通过画图板、铅笔、制图工具,来绘制图形。
这样的设计方法不但使设计工作变得复杂、枯燥,而且浪费了很多的资源和时间。
如今已经很少看到设计人员用纸笔画图了,取而代之的是CAD软件。
通过CAD软件来设计图形使设计人员节约了很多时间,提高了设计的质量和效率,做到了传统设计方法无法做到的一些事情。
目前模拟传统作图过程的CAD二维设计已经得到广泛的应用,而CAD三维设计正在以无可比拟的优势逐渐替代CAD二维设计。
三维设计技术有着和传统设计不同的思想和方法,它的出现和发展是我们机械设计上的一大进步。
目前三维设计软件已经渗透到各个工程领域,未来互联网+、智能制造、虚拟现实技术皆是以三维设计为基础,可以说三维设计是机械设计行业的必由之路。
孙中山先生说过,“天下大势,浩浩汤汤,顺之者昌,逆之者亡。
”对于国家历史尚且如此,小到一个企业及个人又何尝不是呢,对于设计人员来说,三维设计的思想和方法已经成为本领域人员不可或缺的技能,也是跟上时代不被淘汰必备的基本技能。
2参数化、模块化三维设计优势三维设计有其自身的规律和方式,并不是许多人认为的那样,杀猪杀屁股,各有各的杀法,只要最后做出的模型正确就行了。
作者经过多年的使用和推广,总结了很多三维设计的经验,并摸索出了很好的设计方法,其中十二条原则(见附录)是很重要的原则,是三维设计必须坚持的基本原则,是多年来由失败中总结出的经验结晶,不遵守的话就可以直接放弃三维设计了,因为到设计后期将举步维艰。
三维设计水平的层次可以划分为三个阶段,第一阶段是三维建模堆积木,第二阶段是TOP-DOWN设计,第三阶段是模块化设计。
目前设计人员的三维设计水平参差不齐,由于各种原因,部分设计人员仍坚持使用AutoCAD二维设计方法,其中很重要的几点是:一、有人总是说三维设计效率低,没有在老图纸的基础上改改来的快;二是三维设计总是出错;三是错误后很难更改。
mm空间设计理念
MM空间设计理念,强调的是“简约、实用与美学”的完美结合。
MM不仅代表着一种空间尺度的概念,更是对生活方式的深入理解和重新诠释。
以下是MM空间设计理念的核心内容:
一、简约至上。
在MM空间设计中,简约并不意味着简单,而是要通过精简的设计元素,展现出空间的质感和格调。
避免过多的装饰和冗余的功能设计,使空间呈现出清晰、流畅的线条和几何美感。
二、实用主义。
实用性是MM空间设计的基石。
设计应围绕人的需求展开,确保每一寸空间都能得到高效利用。
灵活多变的空间布局、人性化的功能设置以及便捷的储物解决方案,都是实用主义的体现。
三、美学追求。
美学是MM空间设计的灵魂。
在简约和实用的基础上,通过色彩、材质、光影等设计元素的巧妙运用,营造出富有层次感和立体感的视觉效果。
同时,注重空间与自然的和谐共生,引入自然光和绿色植物,使空间充满生机与活力。
四、个性化表达。
MM空间设计鼓励个性化的表达。
每个人的生活方式和审美观念都是独特的,设计应尊重并体现这种差异性。
通过定制化的设计方案,满足不同人群的需求和喜好,使空间成为展现个人魅力的舞台。
综上所述,MM空间设计理念是一种注重简约、实用、美学和个性化的设计理念。
它旨在通过精简的设计手法和高效的空间利用,创造出既美观又实用的居住环境。
在这个空间里,人们可以享受到舒适、便捷和愉悦的生活体验。
23种设计模式的形象比喻1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM 爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。
麦当劳和肯德基就是生产鸡翅的Factory工厂模式:客户类和工厂类分开。
消费者任何时候需要某种产品,只需向工厂请求即可。
消费者无须修改就可以接纳新产品。
缺点是当产品修改时,工厂类也要做相应的修改。
如:如何创建及如何向客户端提供。
2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。
(这一定比美军在伊拉克用的翻译机好卖)建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。
建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。
工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。
(100块钱一份,你要不要)原始模型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。
设计模式心得体会设计模式心得体会8篇我们有一些启发后,写一篇心得体会,记录下来,如此可以一直更新迭代自己的想法。
那么心得体会该怎么写?想必这让大家都很苦恼吧,下面是小编精心整理的设计模式心得体会,希望对大家有所帮助。
设计模式心得体会1刚学几天就有一些浅薄的心得了。
在学过的几种设计模式中(目前为止,本人只学过创建性模式),每一种设计模式都会有一种具体的应用场景,每一种场景描述的都是一种需求变化。
设计模式就是用来解决这些变化的。
只要客户有新的需求,你的程序就要发生改变,不管你用什么方法,这个改变是避免不了的。
关键是你如何是解决这种变化!设计模式就是寻求一种通用的较好的方法来解决这种变化而不是避免这种变化,并不是你应用了设计模式,你的系统就不会发生变化了。
面向对象的编程有三大机制,我个人认为,设计模式很好的利用了其中的“封装与多态”(当然并不是所有的设计模式都是这样的,也不是说继承就没用,继承在三大机制排第一呀,是基本的),比如工厂方法模式和生成器模式。
“封装”的意义不仅仅在于封装代码的实现,更重要的是“封装”系统中变化的部分。
设计模式回答了怎么样去“封装”这种变化。
在一个系统中,总会有一部分经常发生变化,相对的,也总有一个部分是改变频率较低的,我们可以在某种范围内将其理解为不改变的部分。
设计模式要作的事情就是把“变化”的部分封装起来,实现将“变化”的部分与“不变化”的部隔离,这样,“变化”的部分在发生变化时,不会影响到“不改变”的部分。
如果你也学过设计模式,那你可能跟我有同感。
设计模式解决变化的途径可以概括为两步(纯属个人见解):一是转移变化,二是转化变化。
首先是“转移变化”。
简单的说就是把a部分的变化转移到b部分,请b去变化,让a 不发生变化。
在程序中就是将变化从调用者转移到被调用者。
比如,你有一个类scene,这个类用于显现一种风格的游戏场景,调用程序实例化这个类并使用它。
如果有一天,需求改变了,当前风格的游戏场景颜色太冷了,我需要改变当前场景的颜色。
(本案例,从国外网站翻译过来。
能够使用案例概述23种设计模式的经典之作。
)创建型模式1、FACTORY —追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。
麦当劳和肯德基就是生产鸡翅的Factory工厂模式:客户类和工厂类分开。
消费者任何时候需要某种产品,只需向工厂请求即可。
消费者无须修改就可以接纳新产品。
缺点是当产品修改时,工厂类也要做相应的修改。
如:如何创建及如何向客户端提供。
2、BUILDER —MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。
(这一定比美军在伊拉克用的翻译机好卖)建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。
建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD —请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。
工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE —跟MM用QQ聊天,一定要说些深情的话语了,我搜集了好多肉麻的情话,需要时只要copy出来放到QQ里面就行了,这就是我的情话prototype了。
(100块钱一份,你要不要)原始模型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。
原始模型模式允许动态的增加或减少产品类,产品类不需要非得有任何事先确定的等级结构,原始模型模式适用于任何的等级结构。
缺点是每一个类都必须配备一个克隆方法。
5、SINGLETON —俺有6个漂亮的老婆,她们的老公都是我,我就是我们家里的老公Sigleton,她们只要说道“老公”,都是指的同一个人,那就是我(刚才做了个梦啦,哪有这么好的事)单例模式:单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例单例模式。
单例模式只应在有真正的“单一实例”的需求时才可使用。
结构型模式6、ADAPTER —在朋友聚会上碰到了一个美女Sarah,从香港来的,可我不会说粤语,她不会说普通话,只好求助于我的朋友kent了,他作为我和Sarah之间的Adapter,让我和Sarah可以相互交谈了(也不知道他会不会耍我)适配器模式:把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。
适配类可以根据参数返还一个合适的实例给客户端。
7、BRIDGE —早上碰到MM,要说早上好,晚上碰到MM,要说晚上好;碰到MM穿了件新衣服,要说你的衣服好漂亮哦,碰到MM新做的发型,要说你的头发好漂亮哦。
不要问我“早上碰到MM新做了个发型怎么说”这种问题,自己用BRIDGE组合一下不就行了桥梁模式:将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强关联变成弱关联,也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系,从而使两者可以独立的变化。
8、COMPOSITE —Mary今天过生日。
“我过生日,你要送我一件礼物。
”“嗯,好吧,去商店,你自己挑。
”“这件T恤挺漂亮,买,这条裙子好看,买,这个包也不错,买。
”“喂,买了三件了呀,我只答应送一件礼物的哦。
”“什么呀,T恤加裙子加包包,正好配成一套呀,小姐,麻烦你包起来。
”“……”,MM都会用Composite模式了,你会了没有?合成模式:合成模式将对象组织到树结构中,可以用来描述整体与部分的关系。
合成模式就是一个处理对象的树结构的模式。
合成模式把部分与整体的关系用树结构表示出来。
合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
9、DECORATOR —Mary过完轮到Sarly过生日,还是不要叫她自己挑了,不然这个月伙食费肯定玩完,拿出我去年在华山顶上照的照片,在背面写上“最好的的礼物,就是爱你的Fita”,再到街上礼品店买了个像框(卖礼品的MM也很漂亮哦),再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……,我们都是Decorator,最终都在修饰我这个人呀,怎么样,看懂了吗?装饰模式:装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案,提供比继承更多的灵活性。
动态给一个对象增加功能,这些功能可以再动态的撤消。
增加由一些基本功能的排列组合而产生的非常大量的功能。
10、FAÇADE —我有一个专业的Nikon相机,我就喜欢自己手动调光圈、快门,这样照出来的照片才专业,但MM可不懂这些,教了半天也不会。
幸好相机有Facade设计模式,把相机调整到自动档,只要对准目标按快门就行了,一切由相机自动调整,这样MM也可以用这个相机给我拍张照片了。
门面模式:外部与一个子系统的通信必须通过一个统一的门面对象进行。
门面模式提供一个高层次的接口,使得子系统更易于使用。
每一个子系统只有一个门面类,而且此门面类只有一个实例,也就是说它是一个单例模式。
但整个系统可以有多个门面类。
11、FLYWEIGHT —每天跟MM发短信,手指都累死了,最近买了个新手机,可以把一些常用的句子存在手机里,要用的时候,直接拿出来,在前面加上MM的名字就可以发送了,再不用一个字一个字敲了。
共享的句子就是Flyweight,MM的名字就是提取出来的外部特征,根据上下文情况使用。
享元模式:FLYWEIGHT在拳击比赛中指最轻量级。
享元模式以共享的方式高效的支持大量的细粒度对象。
享元模式能做到共享的关键是区分内蕴状态和外蕴状态。
内蕴状态存储在享元内部,不会随环境的改变而有所不同。
外蕴状态是随环境的改变而改变的。
外蕴状态不能影响内蕴状态,它们是相互独立的。
将可以共享的状态和不可以共享的状态从常规类中区分开来,将不可以共享的状态从类里剔除出去。
客户端不可以直接创建被共享的对象,而应当使用一个工厂对象负责创建被共享的对象。
享元模式大幅度的降低内存中对象的数量。
12、PROXY —跟MM在网上聊天,一开头总是“hi,你好”,“你从哪儿来呀?”“你多大了?”“身高多少呀?”这些话,真烦人,写个程序做为我的Proxy吧,凡是接收到这些话都设置好了自动的回答,接收到其他的话时再通知我回答,怎么样,酷吧。
代理模式:代理模式给某一个对象提供一个代理对象,并由代理对象控制对源对象的引用。
代理就是一个人或一个机构代表另一个人或者一个机构采取行动。
某些情况下,客户不想或者不能够直接引用一个对象,代理对象可以在客户和目标对象直接起到中介的作用。
客户端分辨不出代理主题对象与真实主题对象。
代理模式可以并不知道真正的被代理对象,而仅仅持有一个被代理对象的接口,这时候代理对象不能够创建被代理对象,被代理对象必须有系统的其他角色代为创建并传入。
行为模式13、CHAIN OF RESPONSIBLEITY —晚上去上英语课,为了好开溜坐到了最后一排,哇,前面坐了好几个漂亮的MM哎,找张纸条,写上“Hi,可以做我的女朋友吗?如果不愿意请向前传”,纸条就一个接一个的传上去了,糟糕,传到第一排的MM把纸条传给老师了,听说是个老处女呀,快跑!责任链模式:在责任链模式中,很多对象由每一个对象对其下家的引用而接起来形成一条链。
请求在这个链上传递,直到链上的某一个对象决定处理此请求。
客户并不知道链上的哪一个对象最终处理这个请求,系统可以在不影响客户端的情况下动态的重新组织链和分配责任。
处理者有两个选择:承担责任或者把责任推给下家。
一个请求可以最终不被任何接收端对象所接受。
14、COMMAND —俺有一个MM家里管得特别严,没法见面,只好借助于她弟弟在我们俩之间传送信息,她对我有什么指示,就写一张纸条让她弟弟带给我。
这不,她弟弟又传送过来一个COMMAND,为了感谢他,我请他吃了碗杂酱面,哪知道他说:“我同时给我姐姐三个男朋友送COMMAND,就数你最小气,才请我吃面。
”,命令模式:命令模式把一个请求或者操作封装到一个对象中。
命令模式把发出命令的责任和执行命令的责任分割开,委派给不同的对象。
命令模式允许请求的一方和发送的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否执行,何时被执行以及是怎么被执行的。
系统支持命令的撤消。
15、INTERPRETER —俺有一个《泡MM真经》,上面有各种泡MM的攻略,比如说去吃西餐的步骤、去看电影的方法等等,跟MM约会时,只要做一个Interpreter,照着上面的脚本执行就可以了。
解释器模式:给定一个语言后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器。
客户端可以使用这个解释器来解释这个语言中的句子。
解释器模式将描述怎样在有了一个简单的文法后,使用模式设计解释这些语句。
在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。
在解释器模式中需要定义一个代表文法的命令类的等级结构,也就是一系列的组合规则。
每一个命令对象都有一个解释方法,代表对命令对象的解释。
命令对象的等级结构中的对象的任何排列组合都是一个语言。
16、ITERATOR —我爱上了Mary,不顾一切的向她求婚。
Mary:“想要我跟你结婚,得答应我的条件”我:“什么条件我都答应,你说吧”Mary:“我看上了那个一克拉的钻石”我:“我买,我买,还有吗?”Mary:“我看上了湖边的那栋别墅”我:“我买,我买,还有吗?”Mary:“你的小弟弟必须要有50cm长”我脑袋嗡的一声,坐在椅子上,一咬牙:“我剪,我剪,还有吗?”……迭代子模式:迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。
多个对象聚在一起形成的总体称之为聚集,聚集对象是能够包容一组对象的容器对象。
迭代子模式将迭代逻辑封装到一个独立的子对象中,从而与聚集本身隔开。
迭代子模式简化了聚集的界面。
每一个聚集对象都可以有一个或一个以上的迭代子对象,每一个迭代子的迭代状态可以是彼此独立的。
迭代算法可以独立于聚集角色变化。