第三话-单一职责原则



写在前面:本人最近在看《大话设计模式》这本书,书里是用C#讲解的实例。现在写心得笔记与大家分享,就试着写一个JAVA版的。例子还是书里的例子。不过是Java语言实现的。后面也会给出本人的一些理解建议。谢谢《大话设计模式》的作者。

一、什么是单一职责原则?

今天要说的是单一职责原则,这个应该比较好理解。所谓单一职责,就一个类而言,应该仅有一个引起它变化的原因。也就是说它只做简单的一件事,只是做好自己的本质工作其他尽量不去参与。

在我们设计类的时候,我们往往还没有好好思考就开始编码了,这是个不好的习惯。磨刀不误砍柴工,我们应该把业务逻辑理清,把交互的代码和逻辑代码分离开,然后再把逻辑代码根据分工分离开,前提是他需要一个类,也就是有一个能引起这一部分代码变化的原因,那这部分代码就可以单独成类。由于大部分ITer(IT人士)开始接触编程时用的是C语言这种过程化的程序设计,又由于,我们人类习惯按步骤按方法去做事,所以编程时首先想到的就是方法,而不是类。在面向对象的语言中类是程序的最小单位。所以我们要锻炼自己的抽象思想,万物皆类,无论抽象的事物还是具体的事物都可以是一个类。

设计模式,其实不是什么很高深的东西,只是我们没有去总结而已。有过多年开发经验的老鸟们去看设计模式,他会笑而不语,因为这些他们几乎都用过,只是没有给出一个名字而已。设计模式,其实真的是很高深的东西,因为从哲学的角度(不要骂我,我只是宣扬一下马克思的课有点用)来看,它不仅适用于编程,还适用于生活。就像我们ITer,谁都知道,如果我们立志在IT行业奋下去,一定要找一个方向,要做好我们的本质,不能今年做程序员,明年做销售吧。不然你什么都做不好。还有就是朝着一个方向走,就像android,ios, wp, javaweb,
.net等等,太多了你要是什么都去搞,十年你也是什么都会什么都不精。如果你只搞android,一天一个知识点,一天一个小项目,7天一个大点的项目。一年之后,你绝对是大牛。

二、代码实例

闲话少说,上实例(手机拍照)。

一般的设计:

Phone.java

public class Phone {

private float width;

private float height;

private float thick;

public void takePhoto() {

System.out.println("Take a photo");

}

public void makeCall() {

System.out.println("Make a call");

}

public void sendMessage() {

System.out.println("Send a message");

}

public void playMusic() {

System.out.println("Play a music");

}

}

其实可以这样做:

Camera.java

public interface Camera {

public void takePhoto();

}

Mp3.java

public interface Mp3 {

public void playMusic();

}

Phone.java

public class Phone implements Camera, Mp3 {

private float width;

private float height;

private float thick;

public void makeCall() {

System.out.println("Make a call");

}

public void sendMessage() {

System.out.println("Send a message");

}

public void playMusic() {

// TODO Auto-generated method stub

System.out.println("Play a music");

}

public void takePhoto() {

// TODO Auto-generated method stub

System.out.println("Take a photo");

}

}

三、小结

虽说单一职责原则很使代码很清晰,可以解决一个类过于庞大的问题,但是真的不能乱用。用的过分了,可能会使你的程序分崩离析,这样就得不偿失了。一句话,面向对象面向对象,找个对象面向面向就会了。别雪没对象,咱可以去new啊,要多少有多少。

时间: 2024-10-10 12:57:05

第三话-单一职责原则的相关文章

三、单一职责原则、开放-封闭原则、依赖倒转原则

一.单一职责原则 1.定义:就一个类而言,应该仅有一个引起它变化的原因. 2.为什么要?:如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 3.软件设计真正要做的许多内容,就是发现职责并把职责相互分离. 如果你能想到多余一个动机去改变一个类,那么这个类就具有多于一个原则. 4.示例:设计俄罗斯方块的游戏 可以分为游戏逻辑和界面表示逻辑. 游戏逻辑--数组每一项的值改

第三章 单一职责原则

定义 单一职责原则(Single Responsibility Principle,SRP)又称单一功能原则,由罗伯特·C.马丁(Robert C. Martin)于<敏捷软件开发:原则.模式和实践>一书中提出的.这里的职责是指类变化的原因,单一职责原则规定一个类应该有且仅有一个引起它变化的原因,否则类应该被拆分(There should never be more than one reason for a class to change). 该原则提出对象不应该承担太多职责,如果一个对象承

设计模式(三)面向对象设计原则之单一职责原则

引用自:http://blog.csdn.net/lovelion  作者:刘伟 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小.单一职责原则定义如下: 单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责, 或者可以定义为:就一个类而言,应该只有一个引起它变化的原因. 单一职责原则告诉我们:一个类不能太"累"!在软件系统中,一个类(大到模块,小到方法)承担的 职责越多,它被复用的可能性就越小,而

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

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

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

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

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

单一职责原则 定义: 不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案: 遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒

设计模式六大原则(1):单一职责原则(转载)

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾

设计模式(3)-----单一职责原则

单一职责原则(SRP) 定义 就一个类而言,应该仅有一个引起它变化的原因.一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起.这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责.另外,多个职责耦合在一起,会影响复用性.例如:要实现逻辑和界面的分离. 例子 例如在做一个根据参数对用户表进行查询再显示出来的功能,把这些东西写在一个类里面是非常不好的.如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个

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

定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责.  问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾.因为它太简单了.稍有经验的程序员即