23种模式比喻
==创建型模式==
1、=SIMPLE FACTORY=
打完篮球真累,正好边上有个小摊。
“来杯可乐。”
“我要芬达。”
“一瓶矿泉水。”
工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。有了小摊这个工厂,我们口渴的问题就很easy的解决了。
2、=FACTORY METHOD=
以前每次下午打完篮球后一般很晚,回来再洗个澡,食堂就关门了。我们就集体跑过西三门外吃牛肉面(呵呵,人生之一大爽事啊),每个餐厅的风味还不一样,这无所谓啦,我们只要说一句“来碗牛肉面“就行了。
工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。每一个餐厅就是一个具体的工厂,可惜现在西三门已经关掉了,郁闷ing!
3、=SINGLETON=
Kobe就是Kobe,不管你是从电视上看到,还是从报纸上看到,其实就是他一个人
单例模式:单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例单例模式。组织后卫可以有几个,但Kobe只能有一个,废话!
4、=BUILDER=
NBA中强队颇多,且各有自己的特点,因此对付不同的队有不同的打法,但你只要说“今天打国王”就行了,具体该怎么打由教练去安排(build)就行了。
建造模式:将产品的内部表象和客户端分来,客户不必知道产品内部组成的细节,因此当产品的表象一般很复杂时才用。战术安排的确是个比较专业的任务,所以…。
5、=PROTOTYPE=
今年全明星赛真不错,真想再看一遍。
“小陈,把serv-u开一下,我下你的全明星赛。”
“OK!不过先上传两部好片。”
“啊,我晕~~!”
原始模型模式:实际上就是复制啦。原始模型模式允许动态的增加或减少产品类,产品类适合于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。还好,Windows里面的东东只要点右键,都有个复制选项。
==结构型模式==
6、=ADAPTER=
姚明刚去火箭时,交流有点不便,但通过经纪人Adapter,姚明很快就和火箭的其他人混熟了。
适配器模式:把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。通过经纪人Adapter,主教练就可以把姚明看作本土人(会说e文的人)。如今姚明已经加强了功能,使得不要经纪人也可以和主教练交流,呵呵,str man!
7、=COMPOSITE=
上半场被灌了个50:25,趁中场暂停,大家一起来安排下半场怎么打:
“方案A:6号太准,要专人盯防。”―“就是就是!”
“方案B:左边防守太弱,把XX换上来。”-“好耶好耶!”
“方案C:进攻太差,多打一些挡差。”-“不错不错!”
“方案D:上半场方案X其实还是不错的,下半场go on。”-“OKOK!“
…
一声哨响,下半场开始,我们把方案A,B,C…结合,定为方案Y。@#￥%^&*(!~等一系列后,我们终于以51:50战胜对手,哈哈…!!白日梦#&@*!
合成模式:合成模式使得客户端把单独的成分对象和由他们复合而成的合成对象同等看待,因此合成模式使得客户端增加新的构件变得容易。方案A是一条简单的方案,方案D是由不同的方案结合而成的复杂方案,但我们不管这些,我们只知道它们都是我们所要的方案。
8、=DECORA TOR=
记得西边操场没修好时,我们踢球没有地盘,还好,有个篮球场是空的,我们便捡来几块砖头,摆上两个门,哈哈,这样,篮球场也就变成小足球场了。
系里举办一个舞会,得找块大点的地盘,我们又看中了篮球场,挂起一盏灯,搬来两个音箱, ok,一切搞定。这样,篮球场便变成了舞会厅了,哈哈。
装饰模式:装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案,提供比继承更多的灵活性。其实,篮球场还可以变成很多其它的东东,只要发挥你的想像,嘻嘻。
9、=PROXY=
玩NBA正happying。
突然,小付跑过来说:“你的电话,X系说明天下午两点要跟俺们系干一场,怎么样?”
-“OK,就跟他们说没问题!”玩Games要紧。
小付作为一个代理倒省了俺不少事,呵呵。
代理模式:代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下,客户不想或者不能够直接引用一个对象,代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代
理对象,而仅仅持有一个被代理对象的接口,这时候代理对象不能够创建被代理对象,被代理对象必须有系统的其他角色代为创建并传入。X系只知道我们同意和他们干一场,但并不知道是回答他们的就是小付。
10、=FLYWEIGHT=
上次说到吃牛肉面,我们当中有几个还特挑剔。这不:
“老板,我要麻辣的。”-“好咧!”唰唰,老板放了些辣酱。
“我要川味的。”-“好咧!”唰唰,老板放了些泡菜。
“我也要川味的。”-老板按刚才的样式又做了一遍。
小陈一看大家都要,不服,就说:“老板,俺要黑的。”
“黑的?黑的是什么样的。”老板纳闷了。
“黑的,黑的就是多放些酱油…”-全场狂晕#&*%
享元模式:享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是其状态存储在享元内部,不会随环境的改变而有所不同。将可以共享的状态和不可以共享的状态从常规类中区分开来,把不可以共享的状态从类里剔除出去。客户端从工厂中获得对象时,工厂会先检查其是否有该对象,如果有则直接返回给客户,没有才创建新的实例。享元模式大幅度的降低内存中对象的数量。那些麻辣啦,川味啦,都是享元,要的牛肉面有很多,但口味却就那么几种。后来,我们打玩篮球又去了那家店,还没等过小陈开口,老板就说:“这位同学,你是要黑牛肉面吧。”-小陈“……”
11、=FACADE=
又要和X系开始一季一度的比赛了,具体时间和地点还得靠俺这个队长来搞定,好,no problem!给X系篮球队队长一个call:“星期六下午3:00,我们一见高下。”
门面模式:门面模式提供一个高层次的接口,使得子系统更易于使用,它将客户端和一些子系统分离,提高子系统的独立性和可移植性。X系篮球队队长就是个Facade,通过他,免得我要去跟他们系队员(子系统)一个个去通知。
12、=BRIDGE=
我是个学生,但在篮球队里,我又是个队员,那你说我是什么,超级赛亚人?呵呵。
桥梁模式:将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强关联变成弱关联,也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系,从而使两者可以独立的变化。哈哈,多亏这个模式,不然我还真不知道该怎么称呼我自己呢,嘻嘻。
==行为模式==
13、=STRA TEGY=
足球里有很多战术,比如,一般情况用442,打强队可以用451,打弱队可以用343。
当然篮球里面也有的,比如,你可以选择打中锋,或者远投,当然我们平时最多用的可能就是独干,哈哈。
策略模式:策略模式针对一组算法,将每一个算法封装到具有共同接口的独立的类中,从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类,各种算法在具体的策略类中提供。由于算法和环境独立开来,算法的增减,修改都不会影响到环境和客户端。
14、=TEMPLA TE METHOD=
不同的篮球班有不同的老师,但他们上课的内容都是一样的,一般都分为运球,传球,投篮,上篮这么几堂课,估计体育师范学院教书的模版就是这样。具体运球怎么教,上篮怎么教就依不同的老师自己了。
模板方法模式:模板方法模准备一个抽象类,将部分逻辑以具体方法以及具体构造子的形式实现,然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法,从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架,而将逻辑的细节留给具体的子类去实现。
15、=OBSERVER=
“今天下午去打篮球啊。”-A
“好啊,到时叫上我。”-B
“也叫上我。”-C
“还有我。”-D
…
我们班的号召力可见一斑,呵呵。
观察者模式:观察者模式使观察者和被观察者之间的耦合抽象化,被观察者会向所有的登记过的观察者发出通知。当A要去打篮球时,便会通知B,C,D…
16、=ITERA TOR=
大一时上篮球课,体育老师要清名单:“小王(体育委员),你们班到了多少人?”
小王:“立正--,报数。”
“1,2,3,4,…”
迭代子模式:迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。迭代子模式将迭代逻辑封装到一个独立的子对象中,从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象,每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。小王真聪明,不必查询任何一个人就知道到了多少人。
17、=CHAIN OF RESPONSIBLEITY=
现在湖人队进攻,佩顿将球交给马龙,马龙再传给奥尼尔,奥尼尔一记重扣,湖人再添2分。
责任链模式:在责任链模式中,很多对象由每一个对象对其下家的引用连接起来而形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求,系统可以在不影响客户端的情况下动态的重新组织链和分
配责任。处理者有两个选择:承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。其实刚才那个球,奥尼尔可以再传给科比来个空中接力大风车灌篮的,那就PERFECT了!
18、=COMMAND=
一场关键比赛最后一秒由俺的三分决定了胜负,不过,可累坏了俺。
“来杯水。”真听话,我同学A马上叫一靓MM给我倒了杯水。
“背好酸。”真听话,我同学A马上又叫那个靓MM给我锤背。
“真想洗个澡。”真听话…“等等,我不是那个意思,哇哇…^￥&#*。”
命令模式:命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开,委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否执行,何时被执行以及是怎么被执行的。如果早知道那个命令怎么执行,俺就不会说那句话了,呜呜…
19、=MEMENTO=
下了一个NBA小游戏,里面可以自动调关,但要改注册表,当然,先找到键值“总决赛”,右键,导出为final.reg,剩下来你就可以随便改了,万一改错了,还可以双击final.reg,呵呵。
备忘录模式:备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下,将一个对象的状态捉住,并与该对象分离,存储起来,从而可以在将来合适的时候把这个对象还原到存储起来的状态。
20、STA TE
今天打球真没劲,投篮老委掉。
忽然,一靓MM走过来…啊--,超级赛亚人第三阶,变身!
变身之后果然不同凡响,轻松幌过两个人,在三个人的夹击下出手命中,同时加罚!(呵呵,就会吹)
状态模式:状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去像是改变了它的类一样。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时,系统实际改变所选的子类。当一个对象行为依赖其所处状态时,就可以考虑用该模式。靓MM没来时,状态差,导致投篮委。靓MM一来,状态奇佳,就是打手也能进,哈哈。
21、=VISITOR=
下学期篮球课换了个老师,当然,他对我们全然不熟,于是第一节课他拿着花名册找到体育委员小王:“小陈技术怎样?”-“一般般,”
“小罗呢?”-“还可以,不过上篮不行。”
“小何呢?”-“他啊…”
等等,俺赶紧咳嗽一声。
“他怎么样?”-“他,他不错不错!”哈哈。
“就是投篮老委!”-啊,你这小样,耍我。
访问者模式:访问者模式的目的是封装一些施加于某种数据结构元素之上的操作,使得增加新的操作很容易,一旦这些操作需要修改的话,接受这个操作的数据结构可以保持不变,比如,老师还可以通过小王得到我们每个人的身高等。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类(比迭代子强),但增加一个新的节点就变得很困难,如果我们班来了个新同学,小王就没那么管用了。
22、=INTERPRETER=
想知道怎么玩出酷呆了的假动作么,我这儿有AND1的经典集锦,按照上面练习就行了。
解释器模式:给定一个语言后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后,使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构,也就是一系列的组合规则。每一个命令
对象都有一个解释方法,代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。
23、=MEDIA TOR=
俺一高中同学小D到我这儿来玩,当然,打球是必不可少的。叫上小王就出去K别人,但小D和小王不熟,所以几乎没什么配合,结果被CAI了个5:0。只好下场“休息”。
小王:“叫你那个同学少单干,多传球。”-“OK。”我过去把意见传给了小D。
小D:“你那个同学防守有问题,要盯人,不要盯球。”-“NO PROBLEM。”我又过去把意见传给了小王。
调停者模式:调停者模式包装了一系列对象相互作用的方式,使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时,不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化,把对象在小尺度的行为上与其他对象的相互作用分开处理。
果然,依靠我这个MEDIA TOR,我们马上还了对方一个鸡蛋。哈哈!
参考:<<追MM和设计模式>>
<
2、来自:
创建型模式
1、FACTORY—人才市场:以往是要哪个人才,就找哪个人才,效率低,现在有了人才市场,我们只需直接去人才市场挑一个好了;
--人市换成猎头公司如何?
2、BUILDER—生产流水线:以前是手工业作坊式的人工单个单个的生产零件然后一步一步组装做,
软件设计师23种设计模式总结
创建型结构型行为型 类Factory Method Adapter In terpreter Template Method 对象 Abstract Factory Builder Prototype Si ngleto n Apapter(对象) Bridge Composite Decorator Fa?ade Flyweight Proxy Chain of Resp on sibility Comma nd Iterator Mediator Meme nto Observer State Strategy Visitor （抽象工厂） 提供一个创建一系列相关或互相依赖对象的接口，而无须制定它们具体的类。 图10-25抽象工厂模式结构图 Abstract Factory 抽象工厂 class Program { static void Main(string[] args) { AbstractFactory factory1 = new Con creteFactory1(); Clie nt c1 = new Clie nt(factory1); c1.Ru n(); AbstractFactory factory2 = new Con creteFactory2(); Clie nt c2 = new Clie nt(factory2); c2.Ru n(); Co nsole.Read(); abstract class AbstractFactory { public abstract AbstractProductA CreateProductA(); public abstract AbstractProductB
几种常用的设计模式介绍
几种常用的设计模式介绍 1. 设计模式的起源 最早提出“设计模式”概念的是建筑设计大师亚力山大Alexander。在1970年他的《建筑的永恒之道》里描述了投计模式的发现，因为它已经存在了千百年之久，而现代才被通过大量的研究而被发现。 在《建筑的永恒之道》里这样描述：模式是一条由三个部分组成的通用规则：它表示了一个特定环境、一类问题和一个解决方案之间的关系。每一个模式描述了一个不断重复发生的问题，以及该问题解决方案的核心设计。 在他的另一本书《建筑模式语言》中提到了现在已经定义了253种模式。比如： 说明城市主要的结构：亚文化区的镶嵌、分散的工作点、城市的魅力、地方交通区 住宅团组：户型混合、公共性的程度、住宅团组、联排式住宅、丘状住宅、老人天地室内环境和室外环境、阴和阳总是一气呵成 针对住宅：夫妻的领域、儿童的领域、朝东的卧室、农家的厨房、私家的沿街露台、个人居室、起居空间的序列、多床卧室、浴室、大储藏室 针对办公室、车间和公共建筑物：灵活办公空间、共同进餐、共同小组、宾至如归、等候场所、小会议室、半私密办公室 尽管亚力山大的著作是针对建筑领域的，但他的观点实际上适用于所有的工程设计领域，其中也包括软件设计领域。“软件设计模式”，这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。目前主要有23种。 2. 软件设计模式的分类 2.1. 创建型 创建对象时，不再由我们直接实例化对象；而是根据特定场景，由程序来确定创建对象的方式，从而保证更大的性能、更好的架构优势。创建型模式主要有简单工厂模式（并不是23种设计模式之一）、工厂方法、抽象工厂模式、单例模式、生成器模式和原型模式。 2.2. 结构型 用于帮助将多个对象组织成更大的结构。结构型模式主要有适配器模式、桥接模式、组合器模式、装饰器模式、门面模式、亨元模式和代理模式。 2.3. 行为型 用于帮助系统间各对象的通信，以及如何控制复杂系统中流程。行为型模式主要有命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板模式和访问者模式。
23种设计模式趣味讲解
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，
设计模式学习总结
设计模式学习总结 引子 刚开始学习设计模式的时候.感到这些模式真的非常抽象。今年下半年以来.随着我们组工作重点的转移.以及我在小组中角色的变化.我开始有条件提出自己对新系统的设计想法。在设计过程中.我发现了很多设计模式的用处.也确实应用了很多设计模式.这让我越来越感到设计模式的重要性.因此我写了这十余篇专门介绍设计模式的文章.作为我的学习笔记。 《设计模式——可复用的面向对象软件的基础》（有趣的是.梅宏一再在组会上强调应该译成重用）中介绍了一共23种设计模式.我一共写了19个设计模式（其中三个和在一篇文章中）.余下四个.考虑到该模式的应用范围我就没有介绍。在写这些文章时.其中的很多例子都是我在实践中提炼出来的.当然也有很大一部分是《设计模式》中的例子。不过.这四个人（四人团）生活的年代里现在已经很远了.所以它们的例子也很古老。 让我们更加设计模式 设计模式是个好东西.它给出了很多设计中的技巧与思路.对于很多优秀的设计.它加以总结与提炼。设计模式并非四人团拍脑瓜想出来的.而是他们搜集了其他人优秀的设计.加以整理出来的.他们不是这些模式的创造者.仅仅是整理者。 应用设计模式会给我们带来很多好处：软件将变得更加灵活.模块之间的耦合度将会降低.效率会提升.开销会减少。更重要的.设计模式就好像美声唱法中的花腔.让你的设计更加漂亮。总的来说.设计模式似乎将软件设计提升到艺术的层次。 设计模式已经被广泛的应用了.在现在很多的图形界面框架都使用了MVC模式.大量跌代器模式的应用.彻底改变了我们对集合的操作方式。不仅如此.应用了设计模式的设计.往往被看成为优秀的设计。这是因为.这些设计模式都是久经考验的。 模式不是模型 在学习和使用设计模式的时候.往往出现一个非常严重的误区.那就是设计模式必须严格地遵守.不能修改。但是设计模式不是设计模型.并非一成不变。正相反.设计模式中最核心的要素并非设计的结构.而是设计的思想。只有掌握住设计模式的核心思想.才能正确、灵活的应用设计模式.否则再怎么使用设计模式.也不过是生搬硬套。
Gof的23种设计模式
Gof的23种设计模式 从2005年初听说设计模式，到现在虽然已经8年多了，但GoF的23种模式依然盛行，当然GoF提出这些模式的 年代更加久远（1995年）。在工作的过程中，陆陆续续接触了GoF的大部分模式，我记得在2008年的时候就想总结一下设计模式（最近想做的两件事情），最后因为各种原 因也没有完成。最近这段时间正好是职业空档期，没什么事儿做，就把之前看过的设计模式翻出来整理了一下，于是就有了上面几篇文章。整理设计模式的过程，也是一个深刻理解面向对象设计的过程。通过对各个模式的回顾，让我更能够明白前辈们关于面向对象设计提出的各种“最佳实践”，特别是S.O.L.I.D，我觉得在这里再说一次，也不算矫情。S：单一职责原则（Single Responsibility Principle, SRP），一个类只能有一个原因使其发生改变，即一个类只承担一个职责。 O：开放-封闭原则（Open-Close Principle, OCP），这里指我们的设计应该针对扩展开放，针对修改关闭，即尽量以扩展的方式来维护系统。 L：里氏替换原则（Liskov Subsititution Principle, LSP），它表示我们可以在代码中使用任意子类来替代父类并且程 序不受影响，这样可以保证我们使用“继承”并没有破坏父类。
I：接口隔离原则（Interface Segregation Principle, ISP），客户端不应该依赖于它不需要的接口，两个类之间的依赖应该建立在最小接口的基础上。这条原则的目的是为了让那些使用相同接口的类只需要实现特定必要的一组方法，而不是大量没用的方法。 D：依赖倒置原则（Dependence Inversion Principle, DIP），高层模块不应该依赖于低层模块，两者应该都依赖于抽象；抽象不依赖于细节，而细节应该依赖于抽象。这里主要是提倡“面向接口”编程，而非“面向实现”编程。设计模式，从本质上讲，是针对过去某种经验的总结。每种设计模式，都是为了在特定条件下去解决特定问题，离开这些前提去讨论设计模式，是没有意义的。下面，我们快速回顾GoF的23种模式。工厂方法 意图：定义一个用户创建对象的接口，让子类去决定具体使用哪个类。 适用场合：1）类不知道它所要创建的对象的类信息；2）类希望由它的子类来创建对象。抽象工厂 意图：提供一个创建一系列相关或者相互依赖的对象的接口，而无须指定它的具体实现类。 适用场合：1）系统不依赖于产品是如何实现的细节；2）系统的产品族大于1，而在运行时刻只需要某一种产品族；3）属于同一个产品族的产品，必须绑在一起使用；4）所有的
设计模式之我见
设计模式之我见 陈玉好 联系电话：1523163855 邮箱：1307041983@https://www.wendangku.net/doc/b912181691.html, 刚开始学习设计模式的时候，感到这些模式真的非常抽象。今年下半年以来，随着我们组工作重点的转移，以及我在小组中角色的变化，我开始有条件提出自己对新系统的设计想法。在设计过程中，我发现了很多设计模式的用处，也确实应用了很多设计模式，这让我越来越感到设计模式的重要性，因此我写了这十余篇专门介绍设计模式的文章，作为我的学习笔记。 《设计模式——可复用的面向对象软件的基础》（有趣的是，梅宏一再在组会上强调应该译成重用）中介绍了一共23种设计模式，我一共写了19个设计模式（其中三个和在一篇文章中），余下四个，考虑到该模式的应用范围我就没有介绍。在写这些文章时，其中的很多例子都是我在实践中提炼出来的，当然也有很大一部分是《设计模式》中的例子。不过，这四个人（四人团）生活的年代里现在已经很远了，所以它们的例子也很古老。 让我们更加设计模式 设计模式是个好东西，它给出了很多设计中的技巧与思路，对于很多优秀的设计，它加以总结与提炼。设计模式并非四人团拍脑瓜想出来的，而是他们搜集了其他人优秀的设计，加以整理出来的，他们不是这些模式的创造者，仅仅是整理者。 应用设计模式会给我们带来很多好处：软件将变得更加灵活，模块之间的耦合度将会降低，效率会提升，开销会减少。更重要的，设计模式就好像美声唱法中的花腔，让你的设计更加漂亮。总的来说，设计模式似乎将软件设计提升到艺术的层次。 设计模式已经被广泛的应用了，在现在很多的图形界面框架都使用了MVC模式，大量跌代器模式的应用，彻底改变了我们对集合的操作方式。不仅如此，应用了设计模式的设计，往往被看成为优秀的设计。这是因为，这些设计模式都是久经考验的。 在学习和使用设计模式的时候，往往出现一个非常严重的误区，那就是设计模式必须严格地遵守，不能修改。但是设计模式不是设计模型，并非一成不变。正相反，设计模式中最核心的要素并非设计的结构，而是设计的思想。只有掌握住设计模式的核心思想，才能正确、灵活的应用设计模式，否则再怎么使用设计模式，也不过是生搬硬套。 当然，掌握设计模式的思想，关键是要仔细研究模式的意图和结构。一个模式的意图，就是使用这个设计模式的目的，体现了为什么要使用这个模式，也就是需求问题。这个模式的结构，就是如何去解决这个问题，是一种手段、一种经典的解决方法，这种解决方法只是一种建议。两个方面结合起来，明白为什么需要设计模式，同时明白了如何实现这个模式，就容易抓住模式的本质思想。 在抓住意图和结构的基础上，实践也是掌握设计模式的必要方法。当然，设计模式必须在某个场景下得到应用才有意义，这也是为什么《设计模式》中提供了大量的例子用来说明模式的应用场景，这实际上为读者提供了一种上下文环境。学外语不是要强调“语言环境”
23种模式详解
总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下： 二、设计模式的六大原则 1、开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。 2、里氏代换原则（Liskov Substitution Principle） 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 3、依赖倒转原则（Dependence Inversion Principle） 这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。 4、接口隔离原则（Interface Segregation Principle） 这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。 5、迪米特法则（最少知道原则）（Demeter Principle） 为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。 6、合成复用原则（Composite Reuse Principle） 原则是尽量使用合成/聚合的方式，而不是使用继承。 三、Java的23中设计模式 从这一块开始，我们详细介绍Java中23种设计模式的概念，应用场景等情况，并结合他们的特点及设计模式的原则进行分析。 1、工厂方法模式（Factory Method） 工厂方法模式分为三种：
二十三种设计模式类图
二十三种设计模式类图 0 引言 谈到设计模式，绝对应该一起来说说重构。重构给我们带来了什么？除了作为对遗留代码的改进的方法，另一大意义在于，可以让我们在写程序的时候可以不需事先考虑太多的代码组织问题，当然这其中也包括了应用模式的问题。尽管大多数开发者都已经养成了写代码前先从设计开始的习惯，但是，这种程度的设计，涉及到到大局、到总体架构、到主要的模块划分我觉得就够了。换句话说，这时就能写代码了。这就得益于重构的思想了。如果没有重构的思想，有希望获得非常高质量的代码，我们就不得不在开始写代码前考虑更多其实并非非常稳定的代码组织及设计模式的应用问题，那开发效率当然就大打折扣了。在重构和设计模式的合理应用之下，我们可以相对较早的开始写代码，并在功能尽早实现的同时，不断地通过重构和模式来改善我们的代码质量。所以，下面的章节中，在谈模式的同时，我也会谈谈关于常用的这些模式的重构成本的理解。重构成本越高意味着，在遇到类似的问题情形的时候，我们更应该提前考虑应用对应的设计模式，而重构成本比较低则说明，类似的情形下，完全可以先怎么方便，怎么快怎么写，哪怕代码不是很优雅也没关系，回头再重构也很容易。 1 创建型 1.1FactoryMethod 思想：Factory Method的主要思想是使一个类的实例化延迟到其子类。 场景：典型的应用场景如：在某个系统开发的较早阶段，有某些类的实例化过程，实例化方式可能还不是很确定，或者实际实例化的对象（可能是需要对象的某个子类中的一个）不确定，或者比较容易变化。此时，如果直接将实例化过程写在某个函数中，那么一般就是if-else或select-case代码。如果，候选项的数目较少、类型基本确定，那么这样的if-else 还是可以接受的，一旦情形变得复杂、不确定性增加，更甚至包含这个构造过程的函数所
【模式】32设计模式
【关键字】模式 一、设计模式的分类 总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下： 二、设计模式的六大原则 总原则：开闭原则（Open Close Principle） 开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。 1、单一职责原则 不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。 2、里氏替换原则（Liskov Substitution Principle） 里氏代换原则(Liskov Substitution Principle LSP)面向东西设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 历史替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。 3、依赖倒转原则（Dependence Inversion Principle） 这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。 4、接口隔离原则（Interface Segregation Principle） 这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。 5、迪米特法则（最少知道原则）（Demeter Principle）
八种架构设计模式及其优缺点
八种架构设计模式及其优缺点概述(上) 1. 什么是架构 我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果。哈哈，我理解，架构就是骨架，如下图所示： 人类的身体的支撑是主要由骨架来承担的，然后是其上的肌肉、神经、皮肤。架构对于软件的重要性不亚于骨架对人类身体的重要性。 2. 什么是设计模式
这个问题我问过的面试者不下于数十次，回答五花八门，在我看来，模式就是经验，设计模式就是设计经验，有了这些经验，我们就能在特定情况下使用特定的设计、组合设计，这样可以大大节省我们的设计时间，提高工作效率。 作为一个工作10年以上的老码农，经历的系统架构设计也算不少，接下来，我会把工作中用到的一些架构方面的设计模式分享给大家，望大家少走弯路。总体而言，共有八种，分别是： 1.单库单应用模式：最简单的，可能大家都见过 2.内容分发模式：目前用的比较多 3.查询分离模式：对于大并发的查询、业务 4.微服务模式：适用于复杂的业务模式的拆解 5.多级缓存模式：可以把缓存玩的很好 6.分库分表模式：解决单机数据库瓶颈 7.弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一 8.多机房模式：解决高可用、高性能的一种方法 3. 单库单应用模式这是最简单的一种设计模式，我们的大部分本科毕业设计、一些小的应用，基本上都是这种模式，这种模式的一般设计见下图：
如上图所示，这种模式一般只有一个数据库，一个业务应用层，一个后台管理系统，所有的业务都是用过业务层完成的，所有的数据也都是存储在一个数据库中的，好一点会有数据库的同步。虽然简单，但是也并不是一无是处。
优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求、用户少的设计。 缺点：性能差、基本没有高可用、扩展性差，不适用于大规模部署、应用等生产环境。 4. 内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模式，常见的应用场景是使用CDN技术把网页、图片、CSS、JS等这些静态资源分发到离用户最近的服务器。这种模式的一般设计见下图：
Java23种设计模式6大原则总结
设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。设计模式分类：创建型、结构型、行为型。 创建型模式功能：1.统所使用的具体类的信息封装起来； 2.类的实例是如何被创建和组织的。 创建型模式作用：1.封装创建逻辑，不仅仅是new一个对象那么简单。 2.封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。 常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。 常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。单一职责原则：一个类应该只有一个职责。 优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引起的风险。 里氏替换原则： 优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的可重用性；提高代码的可扩展性；提高产品或项目的开放性。 缺点：1.继承是入侵式的。只要继承，就必须拥有父类所有属性和方法。 2.降低代码的灵活性。子类必须拥有父类的属性和方法，使子类收到限制。 3.增强了耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种 修改可能造成大片的代码需要重构。 依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。 在Java中的表现：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于是实现类； 实现类依赖于接口或抽象类。 接口隔离原则：1.一个类对另外一个类的依赖性应当是建立在最小的接口上的 2.一个接口代表一个角色，不应当将不同的角色交给一个接口。 3.不应该强迫客户使用它们的不同方法。 如图所示的电子商务系统在三个地方会使用到订单类：一个是门户，只能有查询方法；一个是外部系统，有添加订单的方法；一个是管理后台，添加、删除、修改、查询都要用到。“原子”在实践中的衡量规则： 1.一个接口只对一个子模块或者业务逻辑进行分类。 2.只保留接口中业务逻辑需要的public方法。 3.尽量修改污染了的接口，若修改的风险较大，则可采用适配器模式进行转化处理。 4.接口设计应因项目而异，因环境而异，不能照搬教条。 迪米特法则：（表述）只与你直接的朋友们通信；不要跟“陌生人”说话；每一个软件单位 对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密 切相关的软件单位。 对迪米特法则进行模式设计有两个：外观模式、中介者模式。 开闭原则：一个软件实体应当对扩展开放，对修改关闭。 重要性体现：提高复用性；提高维护性；提高灵活性；易于测试
23种设计模式_UML_类图及对应示例代码
23种设计模式UML 类图及对应示例代码(一) 收藏 1.DoFactory.GangOfFour.Abstract.Structural Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 using System; namespace DoFactory.GangOfFour.Abstract.Structural { ///
class MainApp { ///
《软件设计模式》教学设计2018(模板)
教 学 设 计 （理论版） 课程名称：软件设计模式 开课单位名称：信息科学与工程学院 授课教师：韩丞（讲师） 授课班级：16计科1班 授课学年学期：2018-2019学年第一学期
填表说明 1.该教学设计模板为理论课教学设计模板。“课程教学设计总概”是对该门课程教学设计的总体要求；“主题（章、节）教学设计”指具体内容的设计，教师要根据首页的“教学安排”整体情况，并视一次授课内容量，选择以主题或章或节作为设计单元；“课程教学反思”是教师本人在该门课程教学实施结束后的整体评价和反思。总概页、教学反思页内容在一门课程的教学设计中只需填写1次。所有表格均可添加页面。 2.封面内容 （1）“授课教师”内容包括授课教师的姓名和职称，以“张三（教授）”形式填写。 （2）“授课班级”内容分两种情况填写，“授课班级”是行政班的教学班应填写“年级、专业、班”信息，非行政班的教学班填写“混合教学班”。 3.总概内容 （1）“课程性质”参照2017级人才培养方案课程性质分类。 （2）“课程目标”指该门课程“课程标准”规定的课程目标。 （3）“学情分析”指对学生的性别构成、原有知识结构、学习动机、学习行为习惯、时间投入、资源获取方式等有效影响学习成效的因素进行分析。 （4）“课程资源”指纸质资源（如教材、参考资料、习题集、辅助资料等）、电子资源（如网站、网络课程、精品课程、视频公开课、PPT、电子学术论文、专著、会议报告等）、硬件资源（场馆、器材、设备、实验室等）、社会资源（如基地、平台、厂、所等）。 （5）“学时安排”采用“Ｘ学时”格式填写。 4.主题（章、节）教学设计内容 （1）“学习目标”描述学生完成学习后的行为表现，应用可观察的行为动词，学习行为表现要有成果物。采用“学生能够……”的方式进行表述。如：“学生能够根据案例给出的背景，综合分析案例中的外汇风险类型，并选择正确的外汇风险管理方法，能撰写分析报告并上交。”上述学习目标中的“分析”“选择”“撰写”“上交”等行为动词均可检测，忌用“知道”“掌握”“了解”等在“学习目标评价”中不能检测的行为动词，否则学习目标无法评价是否达到。 （2）“教学分析”中，“教学内容分析”指教师对讲解内容的分析，鼓励教师把教学内容系统化，用结构化图表或思维导图呈现；“教学重点”指教学内容中最基本、核心的内容；“教学难点”指学生不易理解的内容、技能。 （3）“学习效果评价”指为达成学习目标，教师对“学习目标”进行评价的设计活动。如上述“学习目标”中，教师组织学生“分析”“选择”“撰写”等活动。评价设计活动实施时，根据不同学习目标要求，可在课中评价，如“说出……”“分析……”“选择……”；也可在课后完成，比如“撰写……”“课后作业”等。 5.课程教学反思 “教学反思内容”指教师完成该门课程所有教学设计后，对“课程目标”的科学性、“课程资源”的时代性、“教学安排”的合理性、各“主题（章、节）教学设计”的有效性等内容进行再认识、再思考。
关于23种设计模式新解
关于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个漂亮的老婆，她们的老公都是我，
设计模式知识点整理
设计模式综述： 什么是设计模式？ Christopher Alexander说：“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，这样，你就能一次又一次地使用该方案而不必做重复劳动”。 设计模式就是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。 设计模式的基本要素？ 一般而言，一个模式有四个基本要素： 模式名称——一个助记名，它用一两个词来描述模式的问题、解决方案和效果。 问题——描述了应该在何时使用模式。 解决方案——描述了设计的组成部分。 效果——描述了模式应用的效果及使用模式应权衡的问题。 设计模式的分类？ 我们根据两条准则对模式进行分类： 第一是目的准则，即模式是用来完成什么工作的： 模式依据其目的可分为创建型（Creational）、结构型（Structural）或行为型（Behavioral）三种，创建型模式与对象的创建有关，结构型模式处理类或对象的组合，行为型模式对类或对象怎样交互和怎样分配职责进行描述。 第二是范围准则，即指定模式主要是用于类还是用于对象： 创建型类模式：将对象的部分创建工作延迟到子类 创建型对象模式：将对象的部分创建工作延迟到另一个对象中 结构型类模式：使用继承机制来组合类 结构型对象模式：描述了对象的组装方式 行为型类模式：使用继承描述算法和控制流 行为型对象模式：描述一组对象怎样写作完成单个对象所无法完成的任务 第一个设计模式——单例模式（创建型模式） 先来看看下面这幅图片：
这是windows任务管理器，当我们打开一个任务管理器窗口后，如果试图再打开一个任务管理器窗口，会发现打不开，显示的还是原来的那个窗口，也就是说，任务管理器窗口只能打开一个，不可能打开多个，这就用到了单例模式。那么，什么是单例模式呢？ 单例模式(Singleton Pattern)：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。 知道了单例模式的定义后，我们如果想自己创建一个单例模式，该怎么做呢？ 先看下面的java代码： //Singleton.java public class Singleton{ //定义该类的一个实例，类型为静态私有的 private static Singleton singleton; //定义一个字符串成员变量，用于对单例模式做测试 public String name; //将构造方法设为私有的 private Singleton(){} //给该类添加一个公有静态的方法，名为getInstance，用于返回该类的一个实例 //在该类的内部，判断该类的实例是否为null public static Singleton getInstance(){ if(singleton == null){ singleton = new Singleton(); } return singleton; }
23种设计模式额形象比喻 (1)
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聊天，一定要说些深情的话语了，我搜集了好
浅析23种软件设计模式
浅析23种软件设计模式 1、工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 4、原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。 5、单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。 6、适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。 7、桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。 8、合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。 9、装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。 10、门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。 11、享元模式：FL YWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存
设计模式题库
1.设计模式的原理? (C) C. 面向接口编程 2. 以下对"开-闭"原则的一些描述错误的是?(A) A. "开-闭"原则与"对可变性的封装原则"没有相似性. 3.以下属于创建型模式是? (A) （生成器） C. PROTOTYPE（原型）（单件） 4.以下属于结构型模式是? (D) COMPOSITE（组合） B. ADAPTER（适配器） B.FLYWEIGHT（享元） 5.以下属于行为型模式是? (D ) https://www.wendangku.net/doc/b912181691.html,MAND（命令） 7.STRATEGY(策略) 8.MEMENTO（备忘录） /*23模式意图*/ 6.以下意图那个是用来描述ABSTRACT FACTORY（抽象工厂)?(A) A.提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 7.以下意图那个是用来描述BUILDER（生成器）?(B) 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 8.以下意图那个是用来描述FACTORY METHOD（工厂方法）?(C) C.定义一个用于创建对象的接口，让子类决定实例化哪一个类。该模式使一个类的实例化延迟到其子类。 9.以下意图那个是用来描述PROTOTYPE（原型）?(D) D.用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 10.以下意图那个是用来描述SINGLETON（单件）?(B) B.保证一个类仅有一个实例，并提供一个访问它的全局访问点。
11.以下意图那个是用来描述ADAPTER（适配器）?(A) A.将一个类的接口转换成客户希望的另外一个接口。本模式使得原本由于接口不兼容 而不能一起工作的那些类可以一起工作。 12.以下意图那个是用来描述BRIDGE（桥接）?(B) B.将抽象部分与它的实现部分分离，使它们都可以独立地变化。 13.以下意图那个是用来描述COMPOSITE（组合）?(C) C.将对象组合成树形结构以表示“部分-整体”的层次结构。 14.以下意图那个是用来描述DECORATOR（装饰）?(D) 动态地给一个对象添加一些额外的职责。 15.以下意图那个是用来描述 FACADE（外观）?(A) A.为子系统中的一组接口提供一个一致的界面，本模式定义了一个高层接口，这个接 口使得这一子系统更加容易使用。 16.以下意图那个是用来描述FLYWEIGHT（享元）?(B) B.运用共享技术有效地支持大量细粒度的对象。 17.以下意图那个是用来描述 PROXY（代理）?(C) C.为其他对象提供一种代理以控制对这个对象的访问。 18.以下意图那个是用来描述CHAIN OF RESPONSIBILITY(职责链)?(D) D.使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。 19.以下意图那个是用来描述 COMMAND（命令）?(A) A.将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作 20.以下意图那个是用来描述 INTERPRETER(解释器)?(B) B.给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。 21.以下意图那个是用来描述 ITERATOR(迭代器)?(C) 。 C.提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
- 23种设计模式详解 PPT课件
- 设计模式(23种设计模式巧妙解析,趣味理解)
- 面向对象设计的6个设计原则,23个经典设计模式
- 23种设计模式趣味讲解
- 浅析23种软件设计模式
- 【思维导图】mindmapping-java23种设计模式
- 面向对象设计原则和23个设计模式的笔记
- 设计模式主要分三个类型 创建型 结构型和行为型
- 二十三种设计模式类图
- 二十三种设计模式的通俗理解
- c23种设计模式4外观模式
- 最新23种设计模式详解及实现方式汇总
- 二十三种设计模式
- 软件设计师23种设计模式总结
- 八种架构设计模式及其优缺点
- 23种设计模式uml图及java简单实现代码
- c23种设计模式7模板方法
- 23种设计模式PPT合集
- 23种设计模式简单实例
- 23种设计模式思维导图