设计模式之禅单一职责原则

个人blog 此篇博文地址 :http://www.sanyinchenblog.com/?p=150

最近在看<<设计模式之禅>>感觉这本书很是不错的,demo虽然简单但是确实很明了,感觉很有必要自己再敲一遍 单一职责原则 demo: https://github.com/sanyinchen/UMLDemo 如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。 demo:一个手机类:Iphone。需要用手机来拨打电话,需要三个阶段:拨通电话号码,通话,挂机。
然后这三个阶段中拨通号码和挂机是管理协议,通话只是数据传输,所以我们可以这么设计。 IconnectionMangager
接口: public interface IconnectionMangager { public void dial();   public void hangup(); } IDataManger接口负责数据传输 public interface IDataManger { public void DataTranfer(IconnectionMangager mangager); } Iphone类继承于IDataManger public class Iphone implements  IDataManger
{   @Override public void DataTranfer(IconnectionMangager mangager) { // TODO Auto-generated method stub mangager.dial(); System.out.println("我正在通话!"); mangager.hangup(); } }     SingleDemo: public static void main(String[] args) { // TODO Auto-generated method
stub Iphone iphone = new Iphone(); IconnectionMangager mangager = new IconnectionMangager() { @Override public void hangup() { // TODO Auto-generated method stub System.out.println("我开始拨打电话了..."); } @Override public void dial() { // TODO Auto-generated method
stub System.out.println("我挂电话了..."); } }; iphone.DataTranfer(mangager); }

时间: 2024-10-16 18:59:47

设计模式之禅单一职责原则的相关文章

C#设计模式系列:单一职责原则(Single Responsibility Principle)

1.单一职责原则的核心思想 一个类应该有且只有一个变化的原因. 2.为什么要引入单一职责原则 单一职责原则将不同的职责分离到单独的类,每一个职责都是一个变化的中心.当需求变化时,这个变化将通过更改职责相关的类来体现.如果一个类拥有多于一个的职责,则这些职责就耦合到在了一起,那么就会有多于一个原因来导致这个类的变化.对于某一职责的更改可能会损害类满足其他耦合职责的能力.这样职责的耦合会导致设计的脆弱,以至于当职责发生更改时产生无法预期的破坏. 3.单一职责原则的优点 1>.可以降低类的复杂度,一个

Android与设计模式:用单一职责原则为Activity解耦

一.什么是单一职责原则 单一职责原则(SRP:Single responsibility principle)又称单一功能原则,其定义为:一个类,应该只有一个可以导致变化的原因.光看概念会让人很头疼,我先讲点小例子吧: 二.单一职责原则能解决什么问题 回顾我们的 Android 开发经历,很多人都会发现 Activity 类中的代码总会不知不觉地变得很多,这会让读我们代码的人非常痛苦.而造成这种情况的其中一个原因是:Activity 中需要与用户进行大量的交互,用户的操作会改变 Activity

设计模式六大原则(1)--单一职责原则

定义: 一个类,只有一个引起它变化的原因.通俗的来说就是一个类只负责一项职责. 问题由来: 类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案: 遵循单一职责原则,设计两个类T1和T2,T1负责完成职责P1,T2负责完成P2.当P1变动需要修改T1时不会影响T2:同理,当P2变动需要修改T2时不会影响T1.这样,T1与T2之间职责不同,独立存在,因此无论修改哪一项的实现功能都不会影响另一方的职责. 说

【设计模式之禅】第1章 单一职责原则

1.1 我是"牛"类,我可以担任多职吗 SRP 单一职责原则的英文名称是Single Responsibility Principle,简称是SRP. RBAC模型(Role-Based Access Control)基于角色的访问控制        通过分配和取消角色来完成用户权限的授予和取消,使动作主体(用户)与资源的行为(权限)分离 单一职责原则的定义是:应该有且仅有一个原因引起类的变更. 1.2 绝杀技,打破你的传统思维 SRP的原话解释是:        There shou

设计模式-单一职责原则

1.单一职责原则 单一职责原则:改变仅因为一个因素 <设计模式之禅>,作者提到有人写了个这样的接口 void changeUser(UserOB userOB,changeOptions option); 不如分开写 void changeUserName(String userName); void changeUserAddress(String address); void changeUserTel(String Tel); 虽然如作者提到的,下面的替代上面的,到底是不是应该替换呢?看

设计模式六大原则之单一职责原则

一.什么是设计模式 设计模式:设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.由此可见,设计模式不是代码复用而是经验复用.是代码设计的经验总结. 设计模式的六大原则:[单一职责.里氏替换.依赖倒置.接口隔离.迪米特法则.开闭] 23中常用的设计模式: [单例模式.工厂模式.抽象工厂模式.模板模式.代理模式.建造者模式.原型模式.中介者模式. 命令模式.装饰模式.策略模式.责任链模式.适配模式.迭代器模式.组合模式.观察者模式.备忘录模式

学习设计模式 - 六大基本原则之单一职责原则

设计模式总共有六大基本原则,统称为SOLID (稳定)原则,分别是S-单一职责原则(Single Responsibility Principle), O-开闭原则(Open closed Principle),L-里氏替换原则(Liskov Substitution Principle),L-迪米特法则(Law of Demeter),I-接口隔离原则(Interface Segregation Principle),D-依赖倒置原则(Dependence Invension Principl

大话设计模式第三章之单一职责原则

单一职责原则指的是就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能削弱或者抑制这个类完成其它职责的能力(就像一个程序员  叫他去做医学研究,生物研究,可能会抑制他学设计模式的能力).这种耦合会导致脆弱的设计,当变化发生时,设计会遭到异常不到的破坏(你医学研究久了,设计模式少接触,也就生疏了). 在写一个类的时候,要在类的职责分离上多思考(类的职责搞不清楚,就好像你生病了去找修车的,买菜去学校买),这样代码才是真正的可维护,易扩

设计模式.设计原则-单一职责原则

1:什么情况下 会使用到单一职责原则设计模式? 当同一个类中同时出现业务和属性等代码的时候或者当同一个类中要做多样事情的时候,就需要将其抽象出来,做成多种不同的接口,以便后续方便扩展单一职责:原则要求一个接口或者类只有一个原因引起变化,也就是一个接口或者类只有一个职责,它就负责一件事情 单一原则的好处:类的复杂性降低,实现责任清晰明确可读性高,复杂性降低可维护性提高,可读性提高变更引起风险性降低,变更是必不可少的,如果接口修改,只影响对应的实现类,对其他接口没有影响 如上图所示:Perion类这