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***********"); } } }
标签:Name,原则,people,System,new,using,设计模式,public,DesignPatternPrinciple From: https://www.cnblogs.com/tx1185498724/p/17144052.html