??xml version="1.0" encoding="utf-8" standalone="yes"?>国产99久久久国产精品,午夜精品网站,99国产精品国产精品毛片http://www.aygfsteel.com/paulwong/category/12268.htmlzh-cnTue, 26 Aug 2014 10:11:29 GMTTue, 26 Aug 2014 10:11:29 GMT60设计模式?/title><link>http://www.aygfsteel.com/paulwong/archive/2014/08/26/417363.html</link><dc:creator>paulwong</dc:creator><author>paulwong</author><pubDate>Tue, 26 Aug 2014 09:34:00 GMT</pubDate><guid>http://www.aygfsteel.com/paulwong/archive/2014/08/26/417363.html</guid><wfw:comment>http://www.aygfsteel.com/paulwong/comments/417363.html</wfw:comment><comments>http://www.aygfsteel.com/paulwong/archive/2014/08/26/417363.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.aygfsteel.com/paulwong/comments/commentRss/417363.html</wfw:commentRss><trackback:ping>http://www.aygfsteel.com/paulwong/services/trackbacks/417363.html</trackback:ping><description><![CDATA[{略模式Q?br /><br />场景Q又U警察模式,假设明开快RQ遇到警察,可能是好警察Q只是口头警告一下,p明CQ也可能是强的警察Q给明开了罚单。但明是不知道到底?x)遇到哪U警察,要到RUNTIME的时候才知道?br /><br />不好的封装:(x)好警察的处|行为封装ؓ(f)一个类AQ将强硬警察的处|行为封装ؓ(f)另一个类BQ将判断如何处罚装成一个类CQ在q个cM判断cȝcdQ如果是Ac,则执行AҎ(gu)Q如果是Bc,则执行BҎ(gu)?br /><br />良好的封装:(x)警察的处罚行ؓ(f)l一Z个接口I-A的一个方法,cC的执行方法只传入接口I-A?img src ="http://www.aygfsteel.com/paulwong/aggbug/417363.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.aygfsteel.com/paulwong/" target="_blank">paulwong</a> 2014-08-26 17:34 <a href="http://www.aygfsteel.com/paulwong/archive/2014/08/26/417363.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>Design Pattern 资源http://www.aygfsteel.com/paulwong/archive/2014/08/26/417332.htmlpaulwongpaulwongTue, 26 Aug 2014 01:41:00 GMThttp://www.aygfsteel.com/paulwong/archive/2014/08/26/417332.htmlhttp://www.aygfsteel.com/paulwong/comments/417332.htmlhttp://www.aygfsteel.com/paulwong/archive/2014/08/26/417332.html#Feedback0http://www.aygfsteel.com/paulwong/comments/commentRss/417332.htmlhttp://www.aygfsteel.com/paulwong/services/trackbacks/417332.htmlhttp://www.programcreek.com/category/design-patterns/page/5/

paulwong 2014-08-26 09:41 发表评论
]]>
Java设计模式Q观察?/title><link>http://www.aygfsteel.com/paulwong/archive/2014/08/26/417322.html</link><dc:creator>paulwong</dc:creator><author>paulwong</author><pubDate>Tue, 26 Aug 2014 00:50:00 GMT</pubDate><guid>http://www.aygfsteel.com/paulwong/archive/2014/08/26/417322.html</guid><wfw:comment>http://www.aygfsteel.com/paulwong/comments/417322.html</wfw:comment><comments>http://www.aygfsteel.com/paulwong/archive/2014/08/26/417322.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.aygfsteel.com/paulwong/comments/commentRss/417322.html</wfw:commentRss><trackback:ping>http://www.aygfsteel.com/paulwong/services/trackbacks/417322.html</trackback:ping><description><![CDATA[     摘要: 单来_(d)观察者模?发布?订阅者。下面是一个有关猎头的典型的例子。在下面q张囑ֽ中有两个角色Q猎头和L工作的h。找工作的h向猎头订阅,告知自己希望得到一份工作,当有新的工作Z(x)的时候,猎头׃(x)把这个信息通知l曾l向他订阅过的h。Java代码Subject接口Q?public interface Subject {2    publi...  <a href='http://www.aygfsteel.com/paulwong/archive/2014/08/26/417322.html'>阅读全文</a><img src ="http://www.aygfsteel.com/paulwong/aggbug/417322.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.aygfsteel.com/paulwong/" target="_blank">paulwong</a> 2014-08-26 08:50 <a href="http://www.aygfsteel.com/paulwong/archive/2014/08/26/417322.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>Core J2EE Patternhttp://www.aygfsteel.com/paulwong/archive/2012/07/06/382402.htmlpaulwongpaulwongFri, 06 Jul 2012 09:58:00 GMThttp://www.aygfsteel.com/paulwong/archive/2012/07/06/382402.htmlhttp://www.aygfsteel.com/paulwong/comments/382402.htmlhttp://www.aygfsteel.com/paulwong/archive/2012/07/06/382402.html#Feedback0http://www.aygfsteel.com/paulwong/comments/commentRss/382402.htmlhttp://www.aygfsteel.com/paulwong/services/trackbacks/382402.html



paulwong 2012-07-06 17:58 发表评论
]]>
一些Y件设计的原则http://www.aygfsteel.com/paulwong/archive/2011/04/27/349145.htmlpaulwongpaulwongWed, 27 Apr 2011 15:51:00 GMThttp://www.aygfsteel.com/paulwong/archive/2011/04/27/349145.htmlhttp://www.aygfsteel.com/paulwong/comments/349145.htmlhttp://www.aygfsteel.com/paulwong/archive/2011/04/27/349145.html#Feedback0http://www.aygfsteel.com/paulwong/comments/commentRss/349145.htmlhttp://www.aygfsteel.com/paulwong/services/trackbacks/349145.html
Don’t Repeat Yourself (DRY)
DRY 是一个最单的法则Q也是最Ҏ(gu)被理解的。但它也可能是最难被应用的(因ؓ(f)要做到这P我们需要在泛型设计上做相当的努力,qƈ不是一件容易的事)。它意味着Q当我们在两个或多个地方的时候发C些相似的代码的时候,我们需要把他们的共性抽象出来Ş一个唯一的新Ҏ(gu)Qƈ且改变现有的地方的代码让他们以一些合适的参数调用q个新的Ҏ(gu)?
参考:(x)http://en.wikipedia.org/wiki/KISS_principle

Program to an interface, not an implementation
q是设计模式中最Ҏ(gu)的哲学,注重接口Q而不是实玎ͼ依赖接口Q而不是实现。接口是抽象是稳定的Q实现则是多U多L(fng)。以后面我们?x)面向对象的SOLID原则中会(x)提到我们的依赖倒置原则Q就是这个原则的的另一U样子。还有一条原则叫 Composition over inheritanceQ喜Ƣ组合而不是承)Q这两条是那23个经典设计模式中的设计原则?

Command-Query Separation (CQS)  – 命o(h)-查询分离原则
查询Q当一个方法返回一个值来回应一个问题的时候,它就h查询的性质Q?
命o(h)Q当一个方法要改变对象的状态的时候,它就h命o(h)的性质Q?

通常Q一个方法可能是U的Command模式或者是U的Query模式Q或者是两者的混合体。在设计接口Ӟ如果可能Q应该尽量接口单一化,保证Ҏ(gu)的行Z格的是命令或者是查询Q这h询方法不?x)改变对象的状态,没有副作用,而会(x)改变对象的状态的Ҏ(gu)不可能有q回倹{也是_(d)(x)如果我们要问一个问题,那么׃应该影响到它的答案。实际应用,要视具体情况而定Q语义的清晰性和使用的简单性之间需要权衡。将Command和Query功能合ƈ入一个方法,方便了客L(fng)使用Q但是,降低了清晰性,而且Q可能不便于Z断言的程序设计ƈ且需要一个变量来保存查询l果?

在系l设计中Q很多系l也是以q样原则设计的,查询的功能和命o(h)功能的系l分,q样有则于系l性能Q也有利于系l的安全性?

参考:(x)http://en.wikipedia.org/wiki/Command-query_separation

You Ain’t Gonna Need It (YAGNI)
q个原则而言之ؓ(f)——只考虑和设计必ȝ功能Q避免过度设计。只实现目前需要的功能Q在以后(zhn)需要更多功能时Q可以再q行d?

如无必要Q勿增复杂性?
软g开发先是一场沟通博弈?

以前本站有一关?a target="_blank">q度重构的文?/a>Q这个示例就是这个原则的反例。而,W(xu)ebSphere的设计者就表示q他q度设计了这个?/a>。我们的E序员或是架构师在设计系l的时候,?x)考虑很多扩展性的东西Q导致在架构与设计方面用了大量折衷Q最后导致项目失败。这是个令h感到讽刺的教训,因ؓ(f)本来希望可能g镉K目的生命周期Q结果反而羃短了生命周期?

参考:(x)
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

Law of Demeter – q米Ҏ(gu)?/strong>
q米Ҏ(gu)?Law of Demeter)Q又U?#8220;最知识原?#8221;QPrinciple of Least KnowledgeQ,其来源于1987q荷兰大学的一个叫做Demeter的项目。Craig Larman把Law of Demeter又称?#8220;不要和陌生h说话”。在《程序员修炼之道》中讲LoD的那一章叫?#8220;解耦合与_c特法则”。关于_c特法则有一些很形象的比喻:(x)
如果你想让你的狗跑的话,你会(x)对狗狗说q是对四条狗腿说Q?
如果你去店里C西,你会(x)把钱交给店员Q还是会(x)把钱包交l店员让他自己拿Q?

和狗的四肢说话?让店员自׃钱包里拿钱?q听h有点荒唐Q不q在我们的代码里q几乎是见怪不怪的事情了?

对于LoDQ正式的表述如下Q?


在《Clean Code》一书中Q有一DA(ch)pache framework中的一D违反了LoD的代码:(x)

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

q么长的一串对其它对象的细节,以及(qing)l节的细节,l节的细节的l节……的调用,增加了耦合Q得代码结构复杂、僵化,难以扩展和维护?

在《重构》一书中的代码的环味道中有一U叫?#8220;Feature Envy”(依恋情结Q,形象的描qC一U违反了LoC的情c(din)Feature Envy是说一个对象对其它对象的内Ҏ(gu)有兴,也就是说老是慕别的对象的成员、结构或者功能,大老远的调用h家的东西。这L(fng)l构昄是不合理的。我们的E序应该写得比较“害羞”。不能像前面例子中的那个不把自己当外人的店员一P拿过客h的钱包自己把钱拿出来?#8220;害羞”的程序只和自己最q的朋友交谈。这U情况下应该调整E序的结构,让那个对象自己拥有它慕的featureQ或者用合理的设计模式Q例如Facade和MediatorQ?

参考:(x)http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge

面向对象的S.O.L.I.D 原则

一般来说这是面向对象的五大设计原则Q但是,我觉得这些原则可适用于所有的软g开发?

Single Responsibility Principle (SRP) – 职责单一原则

关于单一职责原则Q其核心的思想是:(x)一个类Q只做一件事Qƈ把这件事做好Q其只有一个引起它变化的原?/strong>。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引画I职责定义ؓ(f)引v变化的原因,以提高内聚性来减少引v变化的原因。职责过多,可能引v它变化的原因p多,q将D职责依赖Q相互之间就产生影响Q从而极大的损伤其内聚性和耦合度。单一职责Q通常意味着单一的功能,因此不要Z个模块实现过多的功能点,以保证实体只有一个引起它变化的原因?

Unix/Linux是这一原则的完体现者。各个程序都独立负责一个单一的事?
Windows是这一原则的反面示例。几乎所有的E序都交l耦合在一赗?

Open/Closed Principle (OCP) – 开闭原?/strong>

关于开发封闭原则,其核心的思想是:(x)模块是可扩展的,而不可修改的。也是_(d)Ҏ(gu)展是开攄Q而对修改是封闭的?

Ҏ(gu)展开放,意味着有新的需求或变化Ӟ可以对现有代码进行扩展,以适应新的情况?
对修改封闭,意味着cM旦设计完成,可以独立完成其工作Q而不要对c进行Q何修攏V?

对于面向对象来说Q需要你依赖抽象Q而不是实玎ͼ23个经典设计模式中?#8220;{略模式”是q个实现。对于非面向对象~程Q一些API需要你传入一个你可以扩展的函敎ͼ比如我们的C 语言的qsort()允许你提供一?#8220;比较?#8221;QSTL中的容器cȝ内存分配QACE中的多线E的各种锁。对于Y件方面,览器的各种插g属于q个原则的实c(din)?

Liskov substitution principle (LSP) – 里氏代换原则

软g工程大师Robert C. Martin把里氏代换原则最l简化ؓ(f)一句话Q?#8220;Subtypes must be substitutable for their base types”。也是Q子cd能够替换成它们的基cR即Q子cd该可以替换Q何基c能够出现的地方Qƈ且经q替换以后,代码q能正常工作。另外,不应该在代码中出现if/else之类对子cȝ型进行判断的条g。里氏替换原则LSP是代码W合开闭原则的一个重要保证。正是由于子cd的可替换性才使得父类型的模块在无需修改的情况下可以扩展?

q么说来Q似乎有Ҏ(gu)条化Q我非常大家看看q个原则个两个最l典的案例—?#8220;正方形不是长方Ş”?#8220;鸵鸟不是?#8221;。通过q两个案例,你会(x)明白《墨?取》中说的 —?#8220;娣,h也,爱娣Q非qZ….盗,ZQ恶盗,非恶Z?#8221;——妹妹虽然是hQ但喜欢妹妹q不代表喜欢h。盗贼是人,但讨厌盗gq不代表p厌hcR?strong>q个原则让你考虑的不是语义上对象的间的关p,而是实际需求的环境?/strong>

在很多情况下Q在设计初期我们cM间的关系不是很明,LSP则给了我们一个判断和设计cM间关pȝ基准Q需不需要承,以及(qing)怎样设计l承关系?

Interface Segregation Principle (ISP) – 接口隔离原则

接口隔离原则意思是把功能实现在接口中,而不是类中,使用多个专门的接口比使用单一的L口要好?

举个例子Q我们对?sh)脑有不同的使用方式Q比如:(x)写作Q通讯Q看?sh)?jing)Q打游戏Q上|,~程Q计,数据{,如果我们把这些功能都声明在电(sh)脑的抽类里面Q那么,我们的上|本QPC机,服务器,W记本的实现c都要实现所有的q些接口Q这显得太复杂了。所以,我们可以把其q些功能接口隔离开来,比如Q工作学?fn)接口,~程开发接口,上网׃接口Q计和数据服务接口Q这P我们的不同功能的?sh)脑可以有所选择地承这些接口?

q个原则可以提升我们“搭积木式”的Y件开发。对于设计来_(d)Java中的各种Event Listener和AdapterQ对于Y件开发来_(d)不同的用h限有不同的功能,不同的版本有不同的功能,都是q个原则的应用?

Dependency Inversion Principle (DIP) – 依赖倒置原则

高层模块不应该依赖于低层模块的实玎ͼ而是依赖于高层抽象?

举个例子Q墙面的开关不应该依赖于电(sh)灯的开兛_玎ͼ而是应该依赖于一个抽象的开关的标准接口Q这P当我们扩展程序的时候,我们的开兛_样可以控制其它不同的灯,甚至不同的电(sh)器。也是_(d)늁和其它电(sh)器承ƈ实现我们的标准开x口,而我们的开关商就可不需要关于其要控制什么样的设备,只需要关心那个标准的开x准。这是依赖倒置原则?

q就好像览器ƈ不依赖于后面的web服务器,其只依赖于HTTP协议。这个原则实在是太重要了Q社?x)的分工化,标准化都是这个设计原则的体现?

参考:(x)http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

Common Closure PrincipleQCCPQ?#8211; 共同闭原则
一个包中所有的cd该对同一U类型的变化关闭。一个变化媄(jing)响一个包Q便影响了包中所有的cR一个更短的说法是:(x)一起修改的c,应该l合在一P同一个包里)。如果必M改应用程序里的代码,我们希望所有的修改都发生在一个包里(修改关闭Q,而不是遍布在很多包里。CCP原则是把因为某个同L(fng)原因而需要修改的所有类l合q一个包里。如?个类从物理上或者从概念上联pd非常紧密Q它们通常一起发生改变,那么它们应该属于同一个包?

CCP延了开闭原则(OCPQ的“关闭”概念Q当因ؓ(f)某个原因需要修Ҏ(gu)Q把需要修改的范围限制在一个最范围内的包里?

参考:(x)http://c2.com/cgi/wiki?CommonClosurePrinciple

Common Reuse Principle (CRP) – 共同重用原则
包的所有类被一起重用。如果你重用了其中的一个类Q就重用全部。换个说法是Q没有被一起重用的cM应该被组合在一赗CRP原则帮助我们军_哪些cd该被攑ֈ同一个包里。依赖一个包是依赖q个包所包含的一切。当一个包发生了改变,q发布新的版本,使用q个包的所有用户都必须在新的包环境下验证他们的工作Q即使被他们使用的部分没有发生Q何改变。因为如果包中包含有未被使用的类Q即使用户不兛_该类是否改变Q但用户q是不得不升U该包ƈ对原来的功能加以重新试?

CCP则让pȝ的维护者受益。CCP让包可能大QCCP原则加入功能相关的类Q,CRP则让包尽可能(CRP原则剔除不用的c)。它们的出发点不一P但不怺冲突?

参考:(x)http://c2.com/cgi/wiki?CommonReusePrinciple

Hollywood Principle – 好莱坞原?/strong>
好莱坞原则就是一句话—?#8220;don’t call us, we’ll call you.”。意思是Q好莱坞的经Uh们不希望你去联系他们Q而是他们?x)在需要的时候来联系你。也是_(d)所有的lg都是被动的,所有的lg初始化和调用都由容器负责。组件处在一个容器当中,由容器负责管理?

单的来讲Q就是由容器控制E序之间的关p,而非传统实现中,q序代码直接操控。这也就是所?#8220;控制反{”的概忉|在:(x)

1.不创建对象,而是描述创徏对象的方式?
2.在代码中Q对象与服务没有直接联系Q而是容器负责这些联pd一赗?

控制权由应用代码中{C外部容器Q控制权的{U,是所谓反转?

好莱坞原则就是IoCQInversion of ControlQ或DIQDependency Injection Q的基础原则。这个原则很像依赖倒置原则Q依赖接口,而不是实例,但是q个原则要解决的是怎么把这个实例传入调用类中?你可能把其声明成成员Q你可以通过构造函敎ͼ你可以通过函数参数。但?IoC可以让你通过配置文gQ一个由Service Container d的配|文件来产生实际配置的类。但是程序也有可能变得不易读了,E序的性能也有可能q会(x)下降?

参考:(x)

[url]http://en.wikipedia.org/wiki/Hollywood_Principle [/url]
[url]http://en.wikipedia.org/wiki/Inversion_of_Control [/url]

High Cohesion & Low/Loose coupling & – 高内聚, 低耦合
q个原则是UNIX操作pȝ设计的经典原则,把模块间的耦合降到最低,而努力让一个模块做到精益求_?

内聚Q一个模块内各个元素彼此l合的紧密程?
耦合Q一个Y件结构内不同模块之间互连E度的度?

内聚意味着重用和独立,耦合意味着多米诺效应牵一发动全n?

参考:(x)

http://en.wikipedia.org/wiki/Coupling_(computer_science)
[url]http://en.wikipedia.org/wiki/Cohesion_(computer_science) [/url]

Convention over ConfigurationQCoCQ?#8211; 惯例优于配置原则
单点_(d)是一些公认的配置方式和信息作为内部缺省的规则来用。例如,Hibernate的映文Ӟ如果U定字段名和cd性一致的话,基本上就可以不要q个配置文g了。你的应用只需要指定不convention的信息即可,从而减了大量convention而又不得不花旉和精力啰里啰嗦的东东。配|文件很多时候相当的影响开发效率?

Rails 中很有配置文gQ但不是没有Q数据库q接是一个配|文ӞQRails 的fansL(fng)期开发效率是 java 开发的 10 倍,估计是q个原因。Maven也用了CoC原则Q当你执行mvn -compile命o(h)的时候,不需要指源文件放在什么地方,而编译以后的class文g攄在什么地方也没有指定Q这是CoC原则?

参考:(x)http://en.wikipedia.org/wiki/Convention_over_Configuration

Separation of Concerns (SoC) – x点分?/strong>
SoC 是计机U学中最重要的努力目标之一。这个原则,是在Y件开发中Q通过各种手段Q将问题的各个关注点分开。如果一个问题能分解为独立且较小的问题,是相对较易解决的。问题太q于复杂Q要解决问题需要关注的点太多,而程序员的能力是有限的,不能同时x于问题的各个斚w。正如程序员的记忆力相对于计机知识来说那么有限一PE序员解决问题的能力相对于要解决的问题的复杂性也是一L(fng)非常有限。在我们分析问题的时候,如果我们把所有的东西混在一赯论,那么只?x)有一个结果——ؕ?

我记得在上一家公司有一个项目,讨论pZ1q多Q项目本来不复杂Q但是没有用SoCQ全部的东西混ؓ(f)一谈,再加上一堆程序员注入了各U不同的观点和想法,整个目一下子失控了。最后,本来一?q的目做了3q?

实现x点分ȝҎ(gu)主要有两U,一U是标准化,另一U是抽象与包装。标准化是制定一套标准,让用者都遵守它,h们的行ؓ(f)l一hQ这样用标准的人就不用担心别h?x)有很多U不同的实现Q自己的程序不能和别h的配合。Java EE是一个标准的大集合。每个开发者只需要关注于标准本n和他所在做的事情就行了。就像是开发镙丝钉的h只专注于开发镙丝钉p了,而不用关注镙帽是怎么生的,反正镙帽和镙丝钉按标来就一定能合得上。不断地把程序的某些部分抽像差包装v来,也是实现x点分ȝ好方法。一旦一个函数被抽像出来q实CQ那么用函数的人就不用兛_q个函数是如何实现的Q同L(fng)Q一旦一个类被抽像ƈ实现了,cȝ使用者也不用再关注于q个cȝ内部是如何实现的。诸如组Ӟ分层Q面向服务,{等q些概念都是在不同的层次上做抽像和包装,以得用者不用关心它的内部实现细节?

说白了还?#8220;高内聚,低耦合”?

参考:(x)http://sulong.me/archives/99

Design by Contract (DbC) – 契约式设?/strong>
DbC的核心思想是对软gpȝ中的元素之间怺合作以及(qing)“责Q”?#8220;义务”的比喅R这U比M商业zd?#8220;客户”?#8220;供应?#8221;达成“契约”而得来。例如:(x)

供应商必L供某U品(责QQ,q且他有权期望客户已l付?gu)ƾ(权利Q?
客户必须付款Q责任)Qƈ且有权得C品(权利Q?
契约双方必须履行那些Ҏ(gu)有契U都有效的责任,如法律和规定{?

同样的,如果在程序设计中一个模块提供了某种功能Q那么它要:(x)

期望所有调用它的客h块都保证一定的q入条gQ这是模块的先验条Ӟ客户的义务和供应商的权利Q这样它?yu)׃用去处理不满_验条件的情况Q?
保证退出时l出特定的属性:(x)q就是模块的后验条g——(供应商的义务Q显然也是客L(fng)权利Q?
在进入时假定Qƈ在退出时保持一些特定的属性:(x)不变式?

契约是q些权利和义务的正式形式。我们可以用“三个问题”来ȝDbCQƈ且作计者要l常问:(x)

它期望的是什么?
它要保证的是什么?
它要保持的是什么?

Ҏ(gu)Bertrand Meyer氏提出的DBC概念的描qͼ对于cȝ一个方法,都有一个前提条件以?qing)一个后l条Ӟ前提条g说明Ҏ(gu)接受什么样的参数数据等Q只有前提条件得到满xQ这个方法才能被调用Q同时后l条件用来说明这个方法完成时的状态,如果一个方法的执行?x)导致这个方法的后箋条g不成立,那么q个Ҏ(gu)也不应该正常q回?

现在把前提条件以?qing)后l条件应用到l承子类中,子类Ҏ(gu)应该满Q?

1.前提条g不强于基c.
2.后箋条g不弱于基c.

换句话说Q通过基类的接口调用一个对象时Q用户只知道基类前提条g以及(qing)后箋条g。因此承类不得要求用户提供比基cL法要求的更强的前提条Ӟ亦即Q承类Ҏ(gu)必须接受M基类Ҏ(gu)能接受的M条gQ参敎ͼ。同Pl承cd顺从基cȝ所有后l条Ӟ亦即Q承类Ҏ(gu)的行为和输出不得q反由基cd立v来的MU束Q不能让用户对承类Ҏ(gu)的输出感到困惑?

q样Q我们就有了Z契约的LSPQ基于契U的LSP是LSP的一U强化?

参考:(x)http://en.wikipedia.org/wiki/Design_by_contract

Acyclic Dependencies Principle (ADP) – 无环依赖原则
包之间的依赖l构必须是一个直接的无环囑ŞQ也是_(d)在依赖结构中不允许出现环Q@环依赖)。如果包的依赖Ş成了环状l构Q怎么h破这U@环依赖呢Q有2U方法可以打破这U@环依赖关p:(x)W一U方法是创徏新的包,如果A、B、C形成环\依赖Q那么把q些共同cL出来攑֜一个新的包D里。这样就把C依赖A变成了C依赖D以及(qing)A依赖DQ从而打破了循环依赖关系。第二种Ҏ(gu)是用DIPQ依赖倒置原则Q和ISPQ接口分隔原则)设计原则?

无环依赖原则QADPQؓ(f)我们解决包之间的关系耦合问题。在设计模块Ӟ不能有@环依赖?

参考:(x)http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple



paulwong 2011-04-27 23:51 发表评论
]]>
门面模式 - Facade Patternhttp://www.aygfsteel.com/paulwong/archive/2009/06/17/282730.htmlpaulwongpaulwongTue, 16 Jun 2009 16:00:00 GMThttp://www.aygfsteel.com/paulwong/archive/2009/06/17/282730.htmlhttp://www.aygfsteel.com/paulwong/comments/282730.htmlhttp://www.aygfsteel.com/paulwong/archive/2009/06/17/282730.html#Feedback0http://www.aygfsteel.com/paulwong/comments/commentRss/282730.htmlhttp://www.aygfsteel.com/paulwong/services/trackbacks/282730.html
有门面模式时:

package pattern.facade;
/**
 * 门面模式/外观模式:Facade Pattern
 *
 * 保安pȝ:
 * 一个保安系l由两个录像机、一个感应器和一个报警器l成?br />  * ׃安操作A器的启动和关?没有使用门面模式Ӟ保安必须亲自启动每个仪器?br />  * 
@version 2009-6-15
 * 
@author Winty(wintys@gmail.com)
 
*/
public class FacadeTest{
    
public static void main(String[] args){
        
//无门面模?/span>
        Camera camera1,camera2;
        camera1 
= new Camera();
        camera2 
= new Camera();
        
        Sensor sensor;
        sensor 
= new Sensor();

        Alarm alarm;
        alarm 
= new Alarm();

        
//启动仪器
        camera1.turnOn();
        camera2.turnOn();
        sensor.activate();
        alarm.activate();
        System.out.println(
"");

        
/////////////////////////////////
        
//使用门面模式
        SecurityFacade security = new SecurityFacade();
        security.start();
    }
}

/**
 * 门面:Facade
 
*/
class SecurityFacade{
    
private Camera camera1;
    
private Camera camera2;
    
private Sensor sensor;
    
private Alarm alarm;

    
public SecurityFacade(){
        camera1 
= new Camera();
        camera2 
= new Camera();
        sensor 
= new Sensor();
        alarm 
= new Alarm();
    }
    
//启动
    public void start(){
        camera1.turnOn();
        camera2.turnOn();
        sensor.activate();
        alarm.activate();
    }

    
//停止
    public void stop(){
        camera1.turnOff();
        camera2.turnOff();
        sensor.deactivate();
        alarm.deactivate();
    }
}

class Camera{
    
public void turnOn(){
        System.out.println(
"turn on the Camera.");
    }

    
public void turnOff(){
        System.out.println(
"turn off the Camera.");
    }

    
//转动
    public void rotate(){
        System.out.println(
"rotate the Camera.");
    }
}


class Sensor{
    
public void activate(){
        System.out.println(
"activate the sensor.");
    }

    
public void deactivate(){
        System.out.println(
"deactivate the sensor.");
    }

    
//触发感应?/span>
    public void trigger(){
        System.out.println(
"trigger the sensor.");
    }
}

class Alarm{
    
public void activate(){
        System.out.println(
"activate the alarm.");
    }

    
public void deactivate(){
        System.out.println(
"deactivate the alarm.");
    }

    
//拉响报警?/span>
    public void ring(){
        System.out.println(
"ring the alarm.");
    }


q行l果:
turn on the Camera.
turn on the Camera.
activate the sensor.
activate the alarm.

turn on the Camera.
turn on the Camera.
activate the sensor.
activate the alarm.


paulwong 2009-06-17 00:00 发表评论
]]>
進銷存系i有qր資料nQ?/title><link>http://www.aygfsteel.com/paulwong/archive/2006/06/17/53451.html</link><dc:creator>paulwong</dc:creator><author>paulwong</author><pubDate>Sat, 17 Jun 2006 01:57:00 GMT</pubDate><guid>http://www.aygfsteel.com/paulwong/archive/2006/06/17/53451.html</guid><wfw:comment>http://www.aygfsteel.com/paulwong/comments/53451.html</wfw:comment><comments>http://www.aygfsteel.com/paulwong/archive/2006/06/17/53451.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.aygfsteel.com/paulwong/comments/commentRss/53451.html</wfw:commentRss><trackback:ping>http://www.aygfsteel.com/paulwong/services/trackbacks/53451.html</trackback:ping><description><![CDATA[ <p>我在教授 軟體a計課程Q尤其是以用案例圖在說明架構設a時Q每一個用套g(Package)所界定圍的系i,係指軟體應用pȝ(dng)Q但d乎不會談?qing)到資料庫。因 為,軟體應用pȝ(dng)與資料n是兩個不同的層次Q甚臻I把資料n視為是應用系iq "U有倉儲(private storage)"Q會比較恰當?/p> <p> <br /> </p> <p>不過Q這衍生出一個問,學員不容易分清楚如何 "mapping" 抽象面的架構a計臛_體的 IT pȝ(dng)Q尤其是資料庫的問題。所以,我會先帶一個問問學員Q?strong>在設a層ơ的考量中,進銷存系i有qր資料nQ?/strong></p> <p> <strong> <br /> </strong> </p> <p>這一個問要能回{得ZQ其假設前提的考量必須要瞭解,在整體的架構a計中,a計團隊到底?"進銷? 視為是一個,還是三個,甚至多個的子系i?</p> <p> <br /> </p> <p>參考下?Q這是?"進銷? 視為是單一的系i,所以,<strong>資料庫只有一個?/strong></p> <p> <strong> </strong> <br /> 好處是什| 是單Q開gҎ(gu)。進銷存相關的資訊處理Q都是在同一個資料n內,並沒有分散的問題Q所以當處理銯需要查詢n存資a時Q只要下 SQL 敘述直接連結庫存?TABLE 卛_?/p> <br /> <p> <img src="file:///C:/DOCUME%7E1/Paul/LOCALS%7E1/Temp/moz-screenshot.jpg" alt="" /> <img src="http://www.kenming.idv.tw/mybase/soft_imgs/in_sale_stock_system_01.jpg" /> </p> <br /> <p> <font color="red" size="-1">?、將進銷存視Z個整體系i?/font> </p> <p> <font color="red" size="-1"> <br /> </font> </p> <p>參考下?Q架構設a之初時Q就已把 "進銷? 分為三個子pȝ(dng)(Sub-system)Q或者也可以E׃為元?Component)Q以凔R子系i׃間的溝通,是透過介面(Interface)的呼 叫。其實,論子pȝ(dng)的範圍與規模Q稱?"模組(Module)" 更為適合Q不過,我個h並不喜歡?"模組" 二字來稱之,因為Q這個術語被業界i濫用了Q已淪落為在業務面的術語Q卻並沒有在實體的系i間Q嚴格遵循透過介面的呼叫?/p> <p> <br /> </p> <p>所以圖2Q?strong>有三個資料n?/strong></p> <p> <strong> </strong> <br /> 畉貨h員處理銷貨需要查詢n存資a時Q需要透過庫存pȝ(dng)所提供的介面來呼叫Q介面的實做可能?"Web Service"?Java Bean"?Session Bean"?COM+" {,但絕不能直接下 SQL 來呼叫位於n存系i內的資料nQ否則,違背了?的整體架構設a。不遵@整體架構a計的規,U自偷偷連接Q稱之為 "跳線"?/p> <p> <br /> </p> <br /> <p> <img src="http://www.kenming.idv.tw/mybase/soft_imgs/in_sale_stock_system_02.jpg" /> </p> <font color="red" size="-1">?、將進銷存分成三個獨立的子系i?br /><br /></font> <p>上圖2的抽象設a與IT面的實做技術,比較困難Q也需要花較多成本Q以案Z(Project-based)的開|時程短、預? 低廉Q不Ҏ(gu)達成?的設a目標。但若重覆性的案Q專注在進銷存這個領域上Q有豐富_的領域知?Domain Knowledge)Q且打算產品?Product)Q那|?的系i架構來得有彈性很多,"????? 三個子pȝ(dng)(元g)Q均可以隨意抽換Q各自更新或改版Q而不會媄(jing)響到另一個子pȝ(dng)Q如?PC L板內的硬體元Ӟ可以造成 "PnP(Plug and Play)" 的效果?/p> <p> <br /> </p> <p>請注意,上述問題的提問,會有qր資料nQ是指抽象的邏輯a計層面Q可千萬不要與實體的資料庫؜Z 談。例如,?雖然需要三個資料nQ但若以 Oracle 資料庫系i,DBA 可以邏輯層面的三個資料nQ切分為三?"TABLE SPACE"Q然後放在同一個實體的 Oracle 資料庫系i內Q而若?MS SQL 或是 MySQLQ則是切割為三? "database"Q放入同一個實體資料npȝ(dng)內?/p> <p> <br /> </p> <p>當然Q若有地理位|或資料庫系ip載的問題Q要分散臛_個實體的資料庫系i,那也沒問。例如,進銷存位g個地點不同的廠,各自配置了三個實體資料nQ各自存放自q資訊。這也是圖2架構a計的優點,一?strong>分合自如Q?/strong></p> <p> <strong> <br /> </strong> </p> <p>e 化的pȝ(dng)a計Q即使是 ERP 如此重視資料存取與處理的pȝ(dng)Q應該要能摒除傳i׃資料庫為中心的設a觀點,因為Q系i整體的彈性度會不佻I很難應變需求面的頻J變_(d)或是 IT 實體q_Q包括資料npȝ(dng)的變更等。設a重心應該要轉移?"Middleware"Q這個術語可能太D IT q_面了Q倒不如乾脆這麼說,a計的重心就是回歸至?"應用pȝ(dng)" ZQ是觀察應用系i可以提供那些服?services)或功?functions)Q這些服務與功能其實就是系i׃個個可以量化的子目?Sub- goal)Q次一步驟才是考量如何取得要能達成這些子目標的資訊(資料)Q要取得資訊Q就是到實體的倉儲Q也是U有的資料npȝ(dng)LQ或是,透過標準? E序Q也是透過標準的介面,臛_部系i取得相關的資訓來處理? </p> <img src ="http://www.aygfsteel.com/paulwong/aggbug/53451.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.aygfsteel.com/paulwong/" target="_blank">paulwong</a> 2006-06-17 09:57 <a href="http://www.aygfsteel.com/paulwong/archive/2006/06/17/53451.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss> <footer> <div class="friendship-link"> <a href="http://www.aygfsteel.com/" title="狠狠久久亚洲欧美专区_中文字幕亚洲综合久久202_国产精品亚洲第五区在线_日本免费网站视频">狠狠久久亚洲欧美专区_中文字幕亚洲综合久久202_国产精品亚洲第五区在线_日本免费网站视频</a> </div> </footer> վ֩ģ壺 <a href="http://" target="_blank">ֿ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ٹ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ന</a>| <a href="http://" target="_blank">ǧ</a>| <a href="http://" target="_blank">ˮ</a>| <a href="http://" target="_blank">½</a>| <a href="http://" target="_blank">˳</a>| <a href="http://" target="_blank">¡Ң</a>| <a href="http://" target="_blank">ɽ</a>| <a href="http://" target="_blank">³ľ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ͨ</a>| <a href="http://" target="_blank">ָ</a>| <a href="http://" target="_blank">̩</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">Ĭ</a>| <a href="http://" target="_blank">Ǭ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">躣</a>| <a href="http://" target="_blank">ɽ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">Ǭ</a>| <a href="http://" target="_blank">̨</a>| <a href="http://" target="_blank">Զ</a>| <a href="http://" target="_blank">֦</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">Ӫ</a>| <a href="http://" target="_blank">̶</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">׿</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">ﴨ</a>| <a href="http://" target="_blank">Ĵʡ</a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank"></a>| <a href="http://" target="_blank">Ϫ</a>| <script> (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })(); </script> </body>