DesignPatternPrinciple-设计模式原则
1. 单一职责原则（Single Responsibility Principle）类T负责两个不同的职责：职责P1，职责P2。
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.SRP { /// <summary> /// 单一职责原则：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时， /// 有可能会导致原本运行正常的职责P2功能发生故障。 /// /// 一个类只负责一件事儿 /// 面向对象语言开发，类是一个基本单位，单一职责原则就是封装的粒度 /// /// 写分支判断，然后执行不同的逻辑，其实这就违背了单一职责原则，但是功能是可以实现的 /// /// 拆分父类+子类， /// 每个类很简单，简单意味着稳定 意味着强大 /// (现在的东西没有以前经用，因为功能多了，这不坏那坏了) /// /// 拆分后，也会造成代码量的增加， /// 类多了，使用成本也高(理解成本) /// /// 究竟该什么时候使用单一职责原则呢？ /// 如果类型足够简单，方法够少，是可以在类级别去违背单一职责 /// 如果类型复杂了，方法多了，建议遵循单一职责原则 /// /// 方法级别的单一职责原则：一个方法只负责一件事儿（职责分拆小方法，分支逻辑分拆） /// 类级别的单一职责原则：一个类只负责一件事儿 /// 类库级别的单一职责原则：一个类库应该职责清晰 /// 项目级别的单一职责原则：一个项目应该职责清晰(客户端/管理后台/后台服务/定时任务/分布式引擎) /// 系统级别的单一职责原则：为通用功能拆分系统(IP定位/日志/在线统计) /// /// </summary> public class SRPShow { public static void Show() { { Animal animal = new Animal("鸡");//呼吸空气 animal.Breath(); //animal.Action(); } { Animal animal = new Animal("牛");//呼吸空气 animal.Breath(); //animal.Action(); } { Animal animal = new Animal("鱼");//呼吸水 animal.Breath(); animal.Action(); } { AbstractAnimal animal = new Chicken(); animal.Breath(); animal.Action(); } { AbstractAnimal animal = new Fish(); animal.Breath(); animal.Action(); } } } }
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.SRP { /// <summary> /// 封装 /// 动物类 /// 简单意味着稳定 /// </summary> public class Animal { private string _Name = null; public Animal(string name) { this._Name = name; } /// <summary> /// 这个方法就挺不稳定，经常各种分支变化经常修改 /// </summary> public void Breath() { if (this._Name.Equals("鸡")) Console.WriteLine($"{this._Name} 呼吸空气"); else if (this._Name.Equals("牛")) Console.WriteLine($"{this._Name} 呼吸空气"); else if (this._Name.Equals("鱼")) Console.WriteLine($"{this._Name} 呼吸水"); else if (this._Name.Equals("蚯蚓")) Console.WriteLine($"{this._Name} 呼吸泥土"); } //BreathChicken BreathFish //应该拆分了 public void Action() { if (this._Name.Equals("鸡")) Console.WriteLine($"{this._Name} flying"); else if (this._Name.Equals("牛")) Console.WriteLine($"{this._Name} walking"); else if (this._Name.Equals("鱼")) Console.WriteLine($"{this._Name} Swimming"); else if (this._Name.Equals("蚯蚓")) Console.WriteLine($"{this._Name} Crawling"); } } }
2. 里氏替换原则（Liskov Substitution Principle）：任何使用基类的地方，都可以透明的使用其子类
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.LSP { /// <summary> /// 里氏替换原则：任何使用基类的地方，都可以透明的使用其子类 /// 继承、多态 /// 继承：子类拥有父类的一切属性和行为，任何父类出现的地方，都可以用子类来代替 /// 继承+透明(安全，不会出现行为不一致) /// /// 1 父类有的，子类是必须有的； /// 如果出现了子类没有的东西，那么就应该断掉继承； /// (再来一个父类，只包含都有的东西) /// 2 子类可以有自己的属性和行为 /// 子类出现的地方，父类不一定能代替 /// 白马非马 /// 3 父类实现的东西，子类就不要再写了，(就是不要new隐藏) /// 有时候会出现意想不到的情况，把父类换成子类后，行为不一致 /// 如果想修改父类的行为，通过abstract/virtual /// /// 声明属性、字段、变量，尽量声明为父类(父类就能满足) /// /// </summary> public class LSPShow { public static void Show() { Console.WriteLine("***************************"); Poly.Test(); { //People people = new Chinese(); Chinese people = new Chinese(); people.Traditional(); //DoChinese(people); people.SayHi(); } { Chinese people = new Hubei(); people.Traditional(); //DoChinese(people); people.SayHi(); } { var people = new Hubei(); people.Traditional(); //DoChinese(people); people.SayHi(); } { People people = new Japanese(); people.Traditional(); //要么上端调用去判断 不能写 因为Japanese没有Traditional //要么就只能在子类抛异常 } { Hubei people = new Hubei(); people.Traditional(); DoChinese(people); DoHubei(people); } { //People people = new People(); //Do(people); } } private static void DoChinese(Chinese people) { Console.WriteLine($"{people.Id} {people.Name} {people.Kuaizi}"); people.SayHi(); } private static void DoHubei(Hubei people) { Console.WriteLine($"{people.Id} {people.Name} {people.Kuaizi}"); people.SayHi(); } } }
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.LSP { public class People { public int Id { get; set; } public string Name { get; set; } //abstract void Eat(); public void Traditional() { Console.WriteLine("仁义礼智信 温良恭俭让 "); } } public class Chinese : People { public string Kuaizi { get; set; } public void SayHi() { Console.WriteLine("早上好，吃了吗？"); } } public class Hubei : Chinese { public string Majiang { get; set; } public new void SayHi() { Console.WriteLine("早上好，过早了么？"); } } //public class Animal//让People继承自Animal //{ // public int Id { get; set; } // public string Name { get; set; } //} public class Japanese : People { //public int Id { get; set; } //public string Name { get; set; } //public new void Traditional() //{ // Console.WriteLine("忍者精神 "); //throw new Exception(); //} //Traditional也会继承 但是Japanese又没有Traditional public void Ninja() { Console.WriteLine("忍者精神 "); } } }
3. 依赖倒置原则（Dependence Inversion Principle）依赖倒置原则:上层模块不应该依赖于低层模块，二者应该通过抽象依赖
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.DIP { /// <summary> /// 依赖倒置原则:高层模块不应该依赖于低层模块，二者应该通过抽象依赖 /// 依赖抽象，而不是依赖细节 /// 抽象：接口/抽象类--可以包含没有实现的元素 /// 细节：普通类--一切都是确定的 /// /// 面向抽象编程：尽量的使用抽象，80%的设计模式都是跟抽象有关 /// 属性 字段 方法参数 返回值。。。尽量都是抽象 /// /// /// </summary> public class DIPShow { public static void Show() { Console.WriteLine("**************DIPShow***************"); Student student = new Student() { Id = 191, Name = "候鸟班长" }; //Student-使用-手机 //高层---------底层 { iPhone phone = new iPhone(); student.PlayiPhone(phone); student.PlayT(phone); student.Play(phone); } { Lumia phone = new Lumia(); student.PlayLumia(phone); student.PlayT(phone); student.Play(phone); } { Honor phone = new Honor(); student.PlayHonor(phone); student.PlayT(phone); student.Play(phone); } //依赖细节 高层就依赖了底层 //手机扩展一下，学生就得改一下。。。手机多了怎么办 { Mi phone = new Mi(); student.PlayT(phone); student.Play(phone); } { Oppo phone = new Oppo(); student.PlayT(phone); student.Play(phone); } //用泛型+父类约束其实就等同于用父类参数类型 //面向抽象有啥好处？ //1 一个方法满足不同类型的参数， //2 还支持扩展，只要是实现了这个抽象，不用修改Student { //面向抽象后，不能使用子类的特别内容 Mi phone = new Mi(); student.Play(phone); //如果传递的是Mi，Bracelet是有的，但是方法确实不能用 //编译器决定了是不能用Bracelet的(dynamic/反射是可以调用的) //不能常规调用，这个问题是解决不了的， //因为面向抽象不止一个类型，用的就是通用功能；非通用的，那就不应该面向抽象 } //面向抽象，只要抽象不变，高层就不变 //面向对象语言开发，就是类与类之间进行交互，如果高层直接依赖低层的细节，细节是多变的，那么低层的变化就导致上层的变化；如果层数多了，底层的修改会直接水波效应传递到最上层，一点细微的改动都会导致整个系统从下往上的修改(这就是大家经常加班的原因) //面向抽象，如果高层和低层没有直接依赖，而是依赖于抽象，抽象一般是稳定的，那低层细节的变化扩展就不会影响到高层，这样就能支持层内部的横向扩展，不会影响其他地方，这样的程序架构就是稳定的 //依赖倒置原则(理论基础)---IOC控制反转(实践封装)---DI依赖注入(实现IOC的手段) } } }
4. 接口隔离原则（Interface Segregation Principle）:客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上；
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.ISP { /// <summary> /// 接口隔离原则:客户端不应该依赖它不需要的接口； /// 一个类对另一个类的依赖应该建立在最小的接口上； /// </summary> public class ISPShow { public static void Show() { Console.WriteLine("***************ISPShow*************"); Student student = new Student() { Id = 191, Name = "候鸟班长" }; //AbstractPhone定义了id branch call text is a //现有智能手机map movie online game.. //是否该把这几个上升到AbstractPhone? //不应该的，上升后，oldman也是手机，但是没有这些功能！ //AbstractPhone就只能放入任何手机都必须具备的功能 { OldMan phone = new OldMan(); phone.Call(); phone.Text(); } //不适合放在抽象类，但是面向抽象编程，接口！ //接口interface定义 can do 不局限产品 //Camera能拍照，能录像 //既然面向抽象，那么有这些功能的对象都得能传递进来 //那就让Camera也去实现IExtend { Honor honor = new Honor(); student.Happy(honor); student.Video(honor); } { Camera camera = new Camera(); student.Video(camera); } //实现IExtend接口，Camera出现很多自己没有的功能, //不应该用这种大而全的接口 { IExtendVideo camera = new Camera(); student.Video(camera); } { IExtendHappy extend = new TV(); student.Happy(extend); } { IExtendGame extend = new PSP(); student.Happy(extend); } //拆下去，都拆成一个方法一个接口，肯定也不好！ { //List<> //Dictionary //IList<T> 索引相关 //ICollection<T> 集合相关操作 //IEnumerable<T> 迭代器foreach } //接口到底该如何定义？ //1 既不能是大而全，会强迫实现没有的东西，也会依赖自己不需要的东西 //2 也不能一个方法一个接口，这样面向抽象也没有意义的 //按照功能的密不可分来定义接口， //而且应该是动态的，随着业务发展会有变化的，但是在设计的时候，要留好提前量，避免抽象的变化 //没有标准答案，随着业务和产品来调整的 //3 接口合并 Map--定位/搜索/导航 这种属于固定步骤，业务细节，尽量的内聚，在接口也不要暴露太多业务细节 } } }
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.ISP { public class Honor : AbstractPhone, IExtend, IExtendVideo, IExtendHappy { public override void Call() { Console.WriteLine("User {0} Call", this.GetType().Name); } public override void Text() { Console.WriteLine("User {0} Call", this.GetType().Name); } public void Photo() { Console.WriteLine("User {0} Photo", this.GetType().Name); } public void Online() { Console.WriteLine("User {0} Online", this.GetType().Name); } public void Game() { Console.WriteLine("User {0} Game", this.GetType().Name); } public void Map() { Console.WriteLine("User {0} Map", this.GetType().Name); } public void Pay() { Console.WriteLine("User {0} Pay", this.GetType().Name); } public void Record()//录音 { Console.WriteLine("User {0} Record", this.GetType().Name); } public void Movie() { Console.WriteLine("User {0} Movie", this.GetType().Name); } } }
5. 迪米特法则 （Law Of Demeter）:一个对象应该对其他对象保持最少的了解。
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.LOD { /// <summary> /// 迪米特法则(最少知道原则):一个对象应该对其他对象保持最少的了解。 /// 只与直接的朋友通信。 /// 面向对象语言---万物皆对象---类和类交互才能产生功能--这不就耦合了吗？ /// /// 类与类之间的关系： /// 纵向：继承≈实现(最密切) /// 横向：聚合> 组合> 关联> 依赖(出现在方法内部) /// /// 高内聚低耦合 /// 迪米特法则，降低类与类之间的耦合 /// 只与直接的朋友通信，就是要尽量避免依赖更多类型 /// 基类库(BCL--框架内置的)的类型除外 /// /// 迪米特，也会增加一些成本 /// /// 工作中有时候会去造一个中介/中间层 /// 门面模式 中介者模式 分层封装 /// 上层UI下订单---订单系统&支付系统&仓储&物流 /// 门面模式--上层交互门面--门面依赖子系统 /// 三层架构：UI---BLL---DAL /// /// 去掉内部依赖 /// 降低访问修饰符权限 /// private /// protected /// internal /// protected internal 子类或者同类库 /// public /// /// 迪米特,依赖别人更少，让别人了解更少 /// </summary> public class LODShow { public static void Show() { Console.WriteLine("************************"); School school = new School() { SchoolName = "SchoolName", ClassList = new List<Class>() { new Class() { ClassName="CN", StudentList=new List<Student>() { new Student() { StudentName="Tony" }, new Student() { StudentName="sada" } } } } }; school.Manage(); } } }
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.LOD { /// <summary> /// 学生 /// </summary> public class Student { public int Id { get; set; } public string StudentName { get; set; } public int Height { private get; set; } public int Salay; public void ManageStudent() { Console.WriteLine(" {0}Manage {1} ", this.GetType().Name, this.StudentName); } } }
6： 开闭原则 (Open Closed Principle):对扩展开发，对修改关闭
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DesignPatternPrinciple.OCP { /// <summary> /// 开闭原则:对扩展开发，对修改关闭 /// 修改：修改现有代码(类) /// 扩展：增加代码(类) /// 面向对象语言是一种静态语言，最害怕变化，会波及很多东西 全面测试 /// 最理想就是新增类，对原有代码没有改动，原有的代码才是可信的 /// /// 开闭原则只是一个目标，并没有任何的手段，也被称之为总则 /// 其他5个原则的建议，就是为了更好的做到OCP /// 开闭原则也是面向对象语言开发一个终极目标 /// /// 如果有功能增加/修改的需求： /// 修改现有方法---增加方法---增加类---增加/替换类库 /// </summary> public class OCPShow { public static void Show() { Console.WriteLine("*************OCPShow***********"); } } }
