关闭

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

165人阅读 评论(0) 收藏 举报

今天看了下csdn上大牛们设计模式,发现在这一方面很欠缺,慢慢学习补充中,先写下自己对 单一职责原则立即吧:

百度百科-:一个类,只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时,可能会影响其它的职责。另外,多个职责耦合在一起,会影响复用性。例如:要实现逻辑和界面的分离。

个人理解:一个类只负责一项职责(废话..)

很简单,都加都知道,但为什么要遵循这个原则呢,不遵循会有什么问题呢~?下面来举一个简单例子

  Question:类A负责a,b两个职责,后来需求变动要修改职责a,但修改可能导致b无法正常工作

   解决方案:建立类A1负责a功能,B1负责b功能,修改时就可以互不影响..(说道这里,自己也觉得这有点白痴..)

但虽然单一职责原则如此简单,并且被认为是常识,但是即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。所谓职责扩散,就是因为某种原因,职责a被分化为粒度更细的职责a1和a2。假设原来A类负责的职责为a,后来随着开发者能力的提高,把职责a细化分成了a1和a2,也就是职责扩散了,那如果遵循单一职责原则就需要创建类A1和A2分别对应职责a1和a2,但这在程序已经写好的情况下,这样做太浪费时间了.所以直接修改类A,让他负责2职责,这样会简单多了,但这样做如果以后如果扩散成a1.a2.a3......an,这样修改就有可能出现问题(所以要在职责扩散到无法控制地步之前,进行代码重构).

<?php
class Animal{
    function eat($animal){
        echo $animal."在吃草";
    }
}

$sheep=new Animal();
$ox=new Animal();
$ox->eat('牛');
$sheep->eat('羊');


结果是:牛在吃草,羊在吃草

如果后期要加上Dog的动作,很显然这个不能满足需求,需要进行修改,如果按照单一职责原则进行修改

<?php
class Plant_animal{
    function eat($animal){
        echo $animal."在吃草";
    }
}
class Flesh_animal{
    function eat($animal){
        echo $animal."在吃肉";
    }
}
$sheep=new Plant_animal();
$ox=new Plant_animal();
$dog=new Flesh_animal();
$ox->eat('牛');
$sheep->eat('羊');
$dog->eat('狗');


这样就可以满足需求,但这样修改花销很大,要将原来的类分解,如果直击修改类Animal会简单很多,如下代码


<?php
class Animal{
    function eat($animal){
        if($animal=='狗'){
            echo $animal."在吃肉";
        }else{
            echo $animal."在吃草";
        }

    }
}

$sheep=new Animal();
$ox=new Animal();
$Dog=new Animal();
$ox->eat('牛');
$sheep->eat('羊');
$Dog->eat('狗');



这样修改,明显比上面一直遵循单一职责的模式,写出的代码方便的多,但这样做也有一个坏处,如果出现植物呢?很简单在加一个if,但如果继续很多蜜蜂,蝴蝶...等等,if多了,很可能就会出新 狗在吃草,牛再吃肉等等,这是回去维护代码,你懂得...

还有一种方法,代码如下:

<?php
class Animal{
    function eat($animal){
        echo $animal."在吃草";
    }
    function eat1($animal){
        echo $animal."在吃肉";
    }
}

$sheep=new Animal();
$ox=new Animal();
$Dog=new Animal();
$ox->eat('牛');
$sheep->eat('羊');
$Dog->eat1('狗');


可以看出,这种方法,没有改动原来的方法,而是在类里面新添加了一个新方法,虽然也违背了单一职责原则,但在方法级别上却是符合单一职责原则的,因为它并没有动原来方法的代码。这三种方法可有有略点,到底采用哪一种,要是具体情况而来,上述例子非常简单,违反和遵循单一职责原则,影响都不大,但时间项目中,类中的方法要远比例子中复杂得多,修改也要麻烦得多。

原则:只有逻辑足够简单,才可以在代码级别上违反单一职责原则;只有类中方法数量足够少,才可以在方法级别上违反单一职责原则;(网上别人给出,借鉴)

遵循单一职责原的优点有:

  • 可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;
  • 提高类的可读性,提高系统的可维护性;
  • 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
此文从网上借鉴较多顺便掺杂自己些许想法,本想留做记录,但勇敢的菜鸟敢于面对扑面而来的板砖,随意决定发出来,不足之处欢迎指点~

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:7184次
    • 积分:100
    • 等级:
    • 排名:千里之外
    • 原创:10篇
    • 转载:2篇
    • 译文:0篇
    • 评论:0条