设计模式之单一原则

定义

一个类只能负责一项工作

发生的问题

类A负责不同的工作:工作W1,工作W2.当由于工作W1需要发生修改而需要修改类A时,有可能会导致原本进行正常的工作W2可能发生故障。

解决方法

实行单一工作原则,分别建立两个类A1,A2。这样让A1负责W1的功能,A2负责W2的功能。这样,修改A1就不会修改W2的功能了,同理 修改A2就不会修改W1的功能。

说到单一工作原则,很多人不屑一顾,因为它原理太简单了。稍有经验的程序员没有学习过设计模式,没有听说单一工作原则,但是在实际开发过程中自觉就实行运用这一原则了,因为这是常识,因为在开发过程,谁都不希望因为修改一个类而导致其他功能发生故障。而避免这一现象的发生,采用单一工作原则是不错的选择。

运行结果:

老人会说话!!

儿童会说话!!

青年会说话!!

程序运行后,发现问题了,并不是所有的生命都会说话,比如动物就不会说话,哑巴也不会说话。如果再细分的话,可以将living类分为normalpeople,animal和dumb。

package text2;
 
public class design {
  public static void main(String[] args) {
living normal=new living();
normal.speak("儿童");
normal.speak("老人");
normal.speak("青年");
dump d=new dump();
d.speak("哑巴");
Animal a=new Animal();
    a.speak("小鸟");
  }   
}
class living{
public void speak(String who)
{
       System.out.println(who+"会说话!!");
}
}
class dump{
public void speak(String who)
{
System.out.println(who+"是不会说话的!");
}
}
class Animal{
public void speak(String who)
{
System.out.println(who+"不会说话的!");
}
}

运行结果

儿童会说话!!

老人会说话!!

青年会说话!!

哑巴是不会说话的!

小鸟不会说话的!

我们看到修改后的花销是大的,除了living类修改了,而且还增加了类,我们直接可以修改living类,虽然违背了单一工作的原则,但是花销变小了.

代码如下:

package text3;
 
public class design {
    public static void main(String[] args) {
    living l=new living();
    l.speak("老人");
    l.speak("儿童");
    l.speak("青年");
    l.speak("哑巴");
    l.speak("小鸟");
    }
 
}
class  living{
public void speak(String who)
{
if("老人".equals(who) || "儿童".equals(who) || "青年".equals(who)){
System.out.println(who+"会说话!!");
}else if("哑巴".equals(who)){
System.out.println(who+"不会说话!");
}else if("小鸟".equals(who)){
System.out.println(who+"不会说话!");
}
}
}

运行结果

老人会说话!!

儿童会说话!!

青年会说话!!

哑巴不会说话!

小鸟不会说话!

可以看到,这种修改方式要简单的多,但是存在隐患时:有一天需要将小鸟分类 麻雀 和 鹰 .则需要修改living类中speak方法啊.则对原有代码修改会对调用 “老人”,”青年”,”儿童”等相关功能带来风险.也许有一天代码量增多,运行结果 正常人中的老人不会说话了!! 这种修改时简单,但是违背了单一工作原则,到后来的隐患是大的.

package
 text4;
public class design {
    public static void main(String[] args) {
    Living l=new Living();
    l.speak("老人");
    l.speak("儿童");
    l.speak("青年");
    l.noSpeak("哑巴");
    l.noSpeak("小鸟");
    
}
}
class Living{
public void speak(String who)
{
System.out.println(who+"是会说话的");
}
public void noSpeak(String who)
{
System.out.println(who+"不会说话的");
}
}

运行结果

老人是会说话的

儿童是会说话的

青年是会说话的

哑巴不会说话的

小鸟不会说话的

可以看到,这种修改没有改动原来类中的方法,而是在类中新增加一个方法,这样虽然说违背了单一工作方式,但在方法级别上是符合单一工作原则的.因为它没有修改原来的方法的代码

这三种方法各有利弊,那么在实际的开发中,采取哪种方法呢 ?这个要根据实际的开发需求,

只要逻辑简单,才可以代码级别上违背单一工作原则,只有类中的方法足够多,才可以在方法级别上违背单一工作原则

  单一工作原则的优点:

1 可以降低复杂度,一个类只负责一个功能,其逻辑肯定比负责多个功能简单的多.

2提高性的可读性,提高系统的可维护性.

3修改代码引起的风险降低.

需要说明的是 单一工作原则不只是面向对象编程中所特有的.只要是模块化程序设计,都适用于单一工作原则.

时间: 2024-08-07 21:19:09

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

设计模式_01_单一原则

设计模式_01_单一原则 package designPatternOf_01; /** * 单一原则示例:动物呼吸 * 引入的问题:鱼不吸空气,吸水 */ public class SinglePrinciple_01 { public static void main(String[] args) { Animal animal=new Animal(); animal.breath("小猫"); animal.breath("小兔"); animal.brea

设计模式--6大原则--单一职责原则

单一职责原则(Single Responsibility Principle),简称SRP. 定义: There should never be more than one reason for a class to change. 应该有且仅有一个原因引起类的变更. 有时候,开发人员设计接口的时候会有些问题,比如用户的属性和用户的行为被放在一个接口中声明.这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了. 下

【设计模式】单一职责 开-闭 依赖倒转 里氏替换原则

几个设计模式的原则,简单了解了一下 单一职责 类的功能应该单一,就一个类而言,应该仅有一个引起它变化的原因,否则就要拆分. [大话设计模式]里大鸟和小菜用的DV的摄像功能和手机的摄像功能的比较,DV的功能单一,手机的功能多而复杂,小菜在看到UFO的时候赶紧拿出手机来录像,结果发现录的很不清楚,如果是DV的话,小菜应该来得及摆一个牛逼的姿势,把UFO给录进去. 开闭原则 可以很简单的总结为一句话:对扩展开放,对修改关闭. 对一个功能的修改应该是通过增加代码的方式,而不是通过修改代码的方式.(内心独

学习大话设计模式03_单一职责原则

单一职责原则:一个类,应仅有一个引起它变化的原因 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分享.如果你能够想到多于一个的动机去改变一个类,那么这个类就是具有多于一个的职责 学习大话设计模式03_单一职责原则

设计模式的六大原则

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

设计模式——设计模式与设计原则

设计模式--设计模式与设计原则 一.设计模式  1.设计模式简介 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石. 模式的经典定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,我们可以无数次地重用那些已有的解决方案,无需再

设计模式之设计原则学习

设计模式的设计原则包含了:单一职责原则.里氏替换原则.依赖倒置原则.接口隔离原则.迪米特法则和开闭原则等6大原则. 单一职责原则(Single Responsibility Principle,简称SRP),英文介绍为:There should never be more than one reason for a class to change,即一个类,应当只有一个引起它变化的原因.单一职责原则,要求对象不能承担太多的职责,充分保证对象的高内聚.单一职责的优点有:1.降低了类的复杂性:2.提

设计模式之SOLID原则再回首

    本科阶段学过设计模式,那时对设计模式的五大原则--SOLID原则的概念与理解还是比较模糊,此时过去了2年时间,在学习<高级软件工程>课程中老师又提到了设计模式,课程中还详细讨论了五大原则的过程,这次SOLID原则再回首作者提出了一些更通俗的理解吧~ 一. 什么是设计模式?     那么,什么是设计模式呢? 从广义角度讲设计模式是可解决一类软件问题并能重复使用的设计方案; 从狭义角度讲设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述,是在类和对象的层次描述的可重复

设计模式之六大原则(转载)

关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来. 原作者博客链接:http://blog.csdn.net/LoveLion/article/category/738450/7 一.单一职责原则 原文链接:http://blog.csdn.net/lovelion/article/details/7536542 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大