设计模式-设计原则-单一职责
2017-11-02 22:00
155 查看
在上一篇文章中我就面向对象语言的三大特性进行阐述
这篇文章主要是来分析设计模式中的四大基本准则:
1. 单一职责
2. 开放-封闭
3. 迪米特法则
4. 依赖倒转
单一职责:对于一个类来说,不应该存在多个导致类发生变化的因素。简单的来说,一个类负责一个功能。例如 面包店A 负责销售面包,由于早餐需要新增豆浆和粥,将面包店的职责细粒度化为销售面包和粥,这可能会导致师傅的工作量激增,影响原有的面包质量。
就面向对象编程来讲,程序的稳定运行以来于对象间直接明了的交互,例如我想买面包,就去面包店挑选,然后想买粥,就到粥铺。不用担心面包店新增业务对原有的产生影响。但是这单一原则在实际的开发中却往往不被准守。
举个例子动物有移动这个行为,
但是随着物种的丰富,出现的大雁之流的飞禽,这就导致我们原来moving这个职责要被细粒度化为奔跑和飞行。遵守单一原则应将动物拆分为飞禽和走兽
这样我们就将对动物类别进行区分的职责从moving中剥离了出来,转移到了客户端上的修改了,这样会导致我们的代码有大量的修改。
如按不遵守单一原则的方式进行修改如下:
这么做相当如把对动物类别进行区分的职责划分到了Animal中,这样对我们来说整体的修改量最小,产生印象的概率最低,但同时会埋下在陆地动物移动行为发生变化需要修改的时候会对鸟类造成不可预知的印象。
就目前据地例子职责简单,无法明显的突出两者的差别。
个人觉得我们在编写程序的时候完全预知未来可能会出现的变化来进行准确的职责划分的概率不大,相反当我们过度进行展望的时候,反而会产生一些bug。我认为在对原有职责影响不大和新增职责不是很沉重的情况下可以适度的打破单一原则。但是当新增的职责过于重要的情况下,简易还是进行拆分的好。
这篇文章主要是来分析设计模式中的四大基本准则:
1. 单一职责
2. 开放-封闭
3. 迪米特法则
4. 依赖倒转
单一职责:对于一个类来说,不应该存在多个导致类发生变化的因素。简单的来说,一个类负责一个功能。例如 面包店A 负责销售面包,由于早餐需要新增豆浆和粥,将面包店的职责细粒度化为销售面包和粥,这可能会导致师傅的工作量激增,影响原有的面包质量。
就面向对象编程来讲,程序的稳定运行以来于对象间直接明了的交互,例如我想买面包,就去面包店挑选,然后想买粥,就到粥铺。不用担心面包店新增业务对原有的产生影响。但是这单一原则在实际的开发中却往往不被准守。
举个例子动物有移动这个行为,
public class Animal { public void moving(String name) { System.out.println(name + ":running 4000 fast"); } public static void main(String[] args) { Animal animal = new Animal(); animal.moving("cat"); animal.moving("dog"); animal.moving("hourse"); } }
但是随着物种的丰富,出现的大雁之流的飞禽,这就导致我们原来moving这个职责要被细粒度化为奔跑和飞行。遵守单一原则应将动物拆分为飞禽和走兽
public class Animal { public static class AnimalOnLand { public void moving(String name) { System.out.println(name + " moving on land"); } } public static class AnimalOnAir { public void moving(String name) { System.out.println(name + " moving on the air"); } } public static void main(String[] args) { AnimalOnLand animalOnLand = new AnimalOnLand(); animalOnLand.moving("cat"); animalOnLand.moving("dog"); AnimalOnAir animalOnAir = new AnimalOnAir(); animalOnAir.moving("bird"); } }
这样我们就将对动物类别进行区分的职责从moving中剥离了出来,转移到了客户端上的修改了,这样会导致我们的代码有大量的修改。
如按不遵守单一原则的方式进行修改如下:
public class Animal { public void moving(String name) { if ("bird".equals(name)) { System.out.println(name + " moving on the air"); } else { System.out.println(name + " moving on land"); } } public static void main(String[] args) { Animal animal = new Animal(); animal.moving("cat"); animal.moving("dog"); animal.moving("bird"); } }
这么做相当如把对动物类别进行区分的职责划分到了Animal中,这样对我们来说整体的修改量最小,产生印象的概率最低,但同时会埋下在陆地动物移动行为发生变化需要修改的时候会对鸟类造成不可预知的印象。
就目前据地例子职责简单,无法明显的突出两者的差别。
个人觉得我们在编写程序的时候完全预知未来可能会出现的变化来进行准确的职责划分的概率不大,相反当我们过度进行展望的时候,反而会产生一些bug。我认为在对原有职责影响不大和新增职责不是很沉重的情况下可以适度的打破单一原则。但是当新增的职责过于重要的情况下,简易还是进行拆分的好。
相关文章推荐
- 设计模式六大原则(1):单一职责原则
- 设计模式六大原则(1):单一职责原则
- 设计模式六大原则<一>单一职责原则
- 设计模式六大原则(1):单一职责原则
- 设计模式六大原则(1):单一职责原则
- 设计模式之禅单一职责原则
- 设计模式6大原则(1):单一职责原则
- 设计模式学习--面向对象的5条设计原则之单一职责原则--SRP
- 设计模式: 3 单一职责原则
- 设计模式六大原则(1):单一职责原则
- 设计模式原则(一)--- 单一职责原则
- Android设计模式——单一职责原则
- 小菜学设计模式 单一职责原则
- IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle)
- 设计模式六大原则----------单一职责原则
- pp看书笔记---设计模式之禅第二版 第一章【单一职责原则】
- 设计模式六大原则(1):单一职责原则
- 设计模式六大原则(1):单一职责原则
- 设计模式---->单一职责原则
- 设计模式六大原则(1):单一职责原则