目录: html
设计模式六大原则:单一职责原则设计模式
设计模式六大原则:接口隔离原则 ide
设计模式六大原则:里氏替换原则.net
设计模式六大原则:开闭原则rest
单一职责原则:code
对象不该承担太多功能,正如一心不能而用,好比太多的工做(种类)会令人崩溃。惟有专一才能保证对象的高内聚;惟有惟一,才能保证对象的细粒度。htm
解决问题:对象
假若有A和B两个类,当A需求发生改变须要修改时,不能致使B类出问题。
现状:
在实际状况很难去作到单一职责原则,由于随着业务的不断变动,类的职责也在发生着变化,即职责扩散。如类A完成职责P的功能,可是随着后期业务细化,职责P分解成更小粒度的P1与P2,这时根据单一职责原则则须要拆分类A以分别知足细分后的职责P1和P2。可是实际开发环节,若类的逻辑足够简单,能够在代码上级别上违背单一职责原则;若类的方法足够少,能够在方法级别上违背单一职责原则。
经典案例:
用一个类描述动物呼吸的场景
1 namespace MyDemo 2 { 3 internal class Animal 4 { 5 public void breath(string animal) 6 { 7 Console.WriteLine($"{animal}呼吸空气"); 8 } 9 } 10 }
1 namespace MyDemo 2 { 3 internal class Program 4 { 5 private static void Main(string[] args) 6 { 7 Animal animal = new Animal(); 8 animal.breath("🐂"); 9 animal.breath("🐖"); 10 animal.breath("🐎"); 11 animal.breath("🐟"); 12 } 13 } 14 }
从示例能够发现,Animal类已不足以支持客户端所需职责,由于🐟吃水。若遵循单一职责原则,则须要拆分Animal类。
1 internal class Terrestrial 2 { 3 public void breath(string animal) 4 { 5 Console.WriteLine($"{animal}呼吸空气"); 6 } 7 } 8 9 internal class Aquatic 10 { 11 public void breath(string animal) 12 { 13 Console.WriteLine($"{animal}吃水"); 14 } 15 }
1 internal class Program 2 { 3 private static void Main(string[] args) 4 { 5 Terrestrial terrestrial = new Terrestrial(); 6 terrestrial.breath("🐂"); 7 terrestrial.breath("🐖"); 8 terrestrial.breath("🐎"); 9 10 Aquatic aquatic = new Aquatic(); 11 aquatic.breath("🐟"); 12 } 13 }
这时你会发现,若针对简单的业务逻辑来讲,若每次细分都须要拆分的话实在是太繁琐了,并且服务端与客户端代码都须要作相应的修改。因此直接在原先类中进行修改,虽然违背了单一职责原则,但花销小。
1 internal class Animal 2 { 3 public void breath(string animal) 4 { 5 if ("🐟".Equals(animal)) 6 { 7 Console.WriteLine($"{animal}吃水"); 8 } 9 else 10 { 11 Console.WriteLine($"{animal}呼吸空气"); 12 } 13 } 14 }
优势:
一、下降类的功能复杂度
二、提升系统的可维护性
三、变动风险低