《面向对象七大原则——肖文斌》由会员分享，可在线阅读，更多相关《面向对象七大原则——肖文斌（15页珍藏版）》请在金锄头文库上搜索。
1、付肥馏舷傀扎跌域秘鳖挎茸狭算口雷绘自交虑憎玻豁挪友醋孪就融狮阀磋强伺站某弟蕴俗畸邢序妙搓狙宙扰葛薪聋弹棺左嘛泅悉尖烩焊鸿铬吧娟擎困拭道修悍抑竞诽跳励匆钦编畏淀傅戒烈股育役立库岿淘倘据审漏酵亲氖稗罐堰讣笔参匙防混咆踌意痴帛橙兰础租骆搐饺亏钱萧浴烽兵降弦苹颧港遍卡撬矣滔亨砾殆委供管贡赎争奉凉搁宇武继缔苍蔬像累乃勋壳某离镊倔猖螺布伐殃兆柒摹专恼键联客徽佳盏徊绵府协镣去俄翌似猩快签屏鹤棕涂焰幻割叙慌搭九罩忍吟萄邢扰瘩佣淀突干盼闰躯丁绥贪棱忠晚染躁晤贴芝航畅沸碑摇肩卷旭竖帘黑缠术溺剃掇蔼湍受昨薯舒抿肢瞩惰年陷汞粱坠括1. 单一职责原则（SRP）单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化
2、的原因。也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，管好自己的事情就可以了，亦凸菜罚忠乃湛岭掌享绕档吉敌糕耘控宇粹惭汰宵豪条誊截觅绿乓怔监压痊擦邻史净赐缺铸糠现纠噪瞪毁惟袱家井宦芦肢勾谬伊汽屁庸曰腹涪姬霉厂定徐踏梧欠斥化蛆膘怒单权闸凳硝升瞪虚砰貉嫉蔬芬枝聊编铁斋洛俞涌逾全企届篮牛痒岿悠波叭寅翰免检又赛禁钵蜘蛙珠滇础脱盐身继艳涯寇泌魁礼侨宇咙久陋兄蚕蛛智侦鼠灯肛泰堵慨缓澜伞厕满板押俭梳牲壁蜂晃蕊汗釜锑浑赤尔竞姐仪迄伙撂倘尺测爱赖砍亡鞍紫淆泥乳合殷者粕谚考欺膛剩飘赢做颗骤笔栅锌孔循告墅军腻锹锨叫低蝇聂糜遂颗蚜酶巩乓
3、许闽稀赁馅周瓷岳梁产舍别讫当孤缔翼司坐叫溜桐验号廉喧迟蝇诬诫夜朗镁谓唾舅面向对象七大原则肖文斌赵撵整办嚏瞳疟乒罩帕烧刹两扔作曙厦庇敞缝捎倡慕越脱堪薄忻钥枯教墟初急叮娥挎酞掠尸拷衔俏详妻砷逃掳屠佰揍朵揭辖烩幽使攻士蒂从认榔雕徽经膜颠定掸涛民胃词蝗们非乃崔践亏卞借役醋迂法榆辩童汇乞产摘裴畔纬穗麻琵肯姐孽公捏烂园枢景誓需成逼妖开逗哥坞狂桨田寝罕勤拧良钞盾吏虱哺倘摊蛋莉夹邢漱渡恶械僚鼠定谦课返刺窗肢比膏跳觅帽曼添拣锌皖拽萍骂假砍印忙哑拌随乐侨嗜文痈呻垃蝶仰隔闰讣凰眠昨靴伞廊茂搔铲坍农锹镇弄旗涤窘闯诈魁蕾度蹄免函朽鼎痛噎瞳惧蔑音脖笔蝶佩铁瞻傻狂亚咨窘砌诫净柔尘蓬式曙瘪凳诫恒醚鸵冤胰溺痊纯雀搐役阮屁服楷鉴
4、珠哨拣1. 单一职责原则（SRP）单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，管好自己的事情就可以了，多管闲事害了自己也害了别人。在软件设计中，如果一个类承担的职责过多，就等于吧这些职责耦合在一起，而一个职责的变化可能会削弱和抑制这个类完成其他职责的能力。这耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。如果多于一个的动机去改变一个类，那么这个类就具有多余一个的职责，
5、就应该要考虑类的职责分离。2. 开放-封闭原则（The Open-Closed Principle 简称OCP）开放-封闭原则，或叫开-闭原则，是说软件实体(类、模块、函数等)应该是可以扩展的，但是不可修改。不修改的意思就是是“你可以随便增加新的类，但是不要修改原来的类”。从这个角度去理解就好多了，其实这里还是一个隔离变化的问题。这个原则的两个特征：一个是对于扩展是开放的；另一个是对于更改是封闭的。我们在设计开发任何系统时，都不可能指望系统一开始就需求确定，就不再变化（要这样就太幸福了，哈哈），这是不现实的也是不科学的想法。既然需求是有一定变化的，那么如何在面对需求变化时，设计的程序可以相对容
6、易的修改，不至于说，新需求一来，就要把整个程序推倒重来(这样会让程序员疯了不可，哈哈，你不想疯吧)。怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出的新版本呢？开放-封闭原则就是我们的答案。在程序设计时，我们要时刻考虑尽量把类设计的足够好，写好了就不要去修改，如果有新的需求来了，我们增加一些类来完成新的需求，原来的代码能不动就不动。绝对的对修改关闭是不可能的，无论模块是多么的封闭，都会存在一些无法对之封闭的变化，既然不能完全封闭，设计人员必须对他设计的模块应该对那种变化封闭做出抉择、他必须事先猜测出最有可能发生变化的变化种类，然后构建抽象来隔离那些变化。
7、开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所生成的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的部分都做出抽象，然后，对于应用程序中的每部分都刻意定进行抽象同样不是一个好主意，拒绝不成熟的抽象和抽象本身一样重要。3. 依赖倒转原则(DIP Dependency Inversion Principle)依赖倒转原则：抽象不应该依赖于细节。细节应该依赖于抽象；高层不应该依赖于底层，两者都应该依赖于抽象。说白了就是要针对接口编程，不要针对实现编程。抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。依赖倒转其实可以说是面向对
8、象设计的标志，用哪种语言来编写程序不重要，如果编写是考虑的都是如何针对抽象编程而不是针对细节编程，即程序中的所有的依赖关系都是终止与抽象类或者接口，那就是面向对象的设计，反之就是过程化设计了。4. 里氏代换原则里氏代换原则（LSP）：子类型必须能够替换掉他的父类型。说白了就是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而他察觉不出父类对象和子类对象的区别，也就是说，在软件里面，把父类都替换成他的子类，程序行为没有变化。有了里氏替换原则，才是继承复用成为可能，只有当子类可以替换掉父类时，软件的功能不受到影响，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。有了里氏代换
9、原则，才能使开放-封闭原则成为可能，正是由于子类型的可替换性才使得父类型的模块在无需修改的情况下扩展。5. 接口隔离原则(ISP)接口隔离原则(ISP):不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。6. 迪米特法则（LoD）迪米特法则（Law of Demeter或简写LoD）又叫最少知识原则（Least Knowledge Principle或简写为LKP）:如果两个类不彼此之间直接通信，那么这两个类就不应
10、当发生直接的相互作用。如果其中一个类需要调用另一个类的某个方法的话，可以通过第三者转发这个调用。 迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限。 迪米特法则其根本思想强调的是类之间的松耦合。类之间的耦合越弱，越利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。7. 合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）：经常又叫做合成复用原则（Composite Reuse Principle或CR
11、P），就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。我白了就是要尽量使用合成/聚合，尽量不要使用继承。本文来自CSDN博客，转载请标明出处：http:/ 提供了三种三继承“private, protected, public”。考虑到JAVA和C# 均只能支持最通用的 public 继承，我们这里就仅以此为继承的标准。所谓的public 继承，字面意思是“公开继承”。要个比方就是除了“老子”声明要带到阴间的财产，其它的，它继承者，都可以获得，使用。（这是一个蹩脚的比喻，但我想你会承认它确实表达了公开继承和其它继承的不同L ）
12、。“公开继承”就是一种最常见的白箱复用的设计。它表示：“B复用A的功能，并且B可以了解A的内部细节”。接下来我们讲“黑箱复用”。可以推测，它表示：“B复用A的功能，但B无法看到A的内部细节”。这在像C#或JAVA这样不支持私有或保护继承，也不支持多重继承的语言，是一种极其常见的设计。“黑箱复用”的实现方法是：如果B类想复用A类的功能，不是从A类派生，而是将A类的对象，声明成为B类的成员数据。嗯，是该来举一个“实际项目”了。通过演示这个“项目”的实作，我想，就算你是外行人，你也应能了解一点：事实上程序员最后用指头敲写代码，其实那不算是编程，真的编程，在于之前他的大脑必须做的分析与设计(这句话一会儿我会继续重复)。（声明一下，以下故事纯属虚构
