简单的旅游网站怎么做,北京推广营销,公司网址大全,h网站模版理论跟实践的关系#xff0c;说远不远#xff0c;说近不近。能不能把理论用到实践上#xff0c;还真不好说。通常讲到设计模式#xff0c;一个最通用的原则是SOLID#xff1a;S - Single Responsibility Principle#xff0c;单一责任原则O - Open Closed Principle… 理论跟实践的关系说远不远说近不近。能不能把理论用到实践上还真不好说。 通常讲到设计模式一个最通用的原则是SOLIDS - Single Responsibility Principle单一责任原则O - Open Closed Principle开闭原则L - Liskov Substitution Principle里氏替换原则I - Interface Segregation Principle接口隔离原则D - Dependency Inversion Principle依赖倒置原则嗯这就是五大原则。后来又加入了一个Law of Demeter迪米特法则。于是就变成了六大原则。 原则好理解。怎么用在实践中一、单一责任原则单一责任原则简单来说就是一个类或一个模块只负责一种或一类职责。看代码public interface IUser
{void AddUser();void RemoveUser();void UpdateUser();void Logger();void Message();
}
根据原则我们会发现对于IUser来说前三个方法AddUser、RemoveUser、UpdateUser是有意义的而后两个Logger和Message作为IUser的一部分功能是没有意义的并不符合单一责任原则的。所以我们可以把它分解成不同的接口public interface IUser
{void AddUser();void RemoveUser();void UpdateUser();
}
public interface ILog
{void Logger();
}
public interface IMessage
{void Message();
}
拆分后我们看到三个接口各自完成自己的责任可读性和可维护性都很好。 下面是使用的例子采用依赖注入来做public class Log : ILog
{public void Logger(){Console.WriteLine(Logged Error);}
}
public class Msg : IMessage
{public void Message(){Console.WriteLine(Messaged Sent);}
}
class Class_DI
{private readonly IUser _user;private readonly ILog _log;private readonly IMessage _msg;public Class_DI(IUser user, ILog log, IMessage msg){this._user user;this._log log;this._msg msg;}public void User(){this._user.AddUser();this._user.RemoveUser();this._user.UpdateUser();}public void Log(){this._log.Logger();}public void Msg(){this._msg.Message();}
}
public static void Main()
{Class_DI di new Class_DI(new User(), new Log(), new Msg());di.User();di.Log();di.Msg();
}
这样的代码看着就漂亮多了。二、开闭原则开闭原则要求类、模块、函数等实体应该对扩展开放对修改关闭。 我们先来看一段代码计算员工的奖金public class Employee
{public int Employee_ID;public string Name;public Employee(int id, string name){this.Employee_ID id;this.Name name;}public decimal Bonus(decimal salary){return salary * .2M;}
}
class Program
{static void Main(string[] args){Employee emp new Employee(101, WangPlus);Console.WriteLine(Employee ID: {0} Name: {1} Bonus: {2}, emp.Employee_ID, emp.Name, emp.Bonus(10000));}
}
现在假设计算奖金的公式做了改动。要实现这个我们可能需要对代码进行修改public class Employee
{public int Employee_ID;public string Name;public string Employee_Type;public Employee(int id, string name, string type){this.Employee_ID id;this.Name name;this.Employee_Type type;}public decimal Bonus(decimal salary){if (Employee_Type manager)return salary * .2M;elsereturnsalary * .1M;}
}
显然为了实现改动我们修改了类和方法。这违背了开闭原则。 那我们该怎么做我们可以用抽象类来实现 - 当然实际有很多实现方式选择最习惯或自然的方式就成public abstract class Employee
{public int Employee_ID;public string Name;public Employee(int id, string name){this.Employee_ID id;this.Name name;}public abstract decimal Bonus(decimal salary);
}
然后我们再实现最初的功能public class GeneralEmployee : Employee
{public GeneralEmployee(int id, string name) : base(id, name){}public override decimal Bonus(decimal salary){return salary * .2M;}
}
class Program
{public static void Main(){Employee emp new GeneralEmployee(101, WangPlus);Console.WriteLine(Employee ID: {0} Name: {1} Bonus: {2}, emp.Employee_ID, emp.Name, emp.Bonus(10000));}
}
在这儿使用抽象类的好处是如果未来需要修改奖金规则则不需要像前边例子一样修改整个类和方法因为现在的扩展是开放的。代码写完整了是这样public abstract class Employee
{public int Employee_ID;public string Name;public Employee(int id, string name){this.Employee_ID id;this.Name name;}public abstract decimal Bonus(decimal salary);
}public class GeneralEmployee : Employee
{public GeneralEmployee(int id, string name) : base(id, name){}public override decimal Bonus(decimal salary){return salary * .1M;}
}
public class ManagerEmployee : Employee
{public ManagerEmployee(int id, string name) : base(id, name){}public override decimal Bonus(decimal salary){return salary * .2M;}
}
class Program
{public static void Main(){Employee emp new GeneralEmployee(101, WangPlus);Employee emp1 new ManagerEmployee(102, WangPlus1);Console.WriteLine(Employee ID: {0} Name: {1} Bonus: {2}, emp.Employee_ID, emp.Name, emp.Bonus(10000));Console.WriteLine(Employee ID: {0} Name: {1} Bonus: {2}, emp1.Employee_ID, emp1.Name, emp1.Bonus(10000));}
}
三、里氏替换原则里氏替换原则讲的是子类可以扩展父类的功能但不能改变基类原有的功能。它有四层含义子类可以实现父类的抽象方法但不能覆盖父类的非抽象方法子类中可以增加自己的特有方法当子类重载父类的方法时方法的前置条件形参要比父类的输入参数更宽松当子类实现父类的抽象方法时方法的后置条件返回值要比父类更严格。在前边开闭原则中我们的例子里实际上也遵循了部分里氏替换原则我们用GeneralEmployee和ManagerEmployee替换了父类Employee。 还是拿代码来说。假设需求又改了这回加了一个临时工是没有奖金的。public class TempEmployee : Employee
{public TempEmployee(int id, string name) : base(id, name){}public override decimal Bonus(decimal salary){throw new NotImplementedException();}
}
class Program
{public static void Main(){Employee emp new GeneralEmployee(101, WangPlus);Employee emp1 new ManagerEmployee(101, WangPlus1);Employee emp2 new TempEmployee(102, WangPlus2);Console.WriteLine(Employee ID: {0} Name: {1} Bonus: {2}, emp.Employee_ID, emp.Name, emp.Bonus(10000));Console.WriteLine(Employee ID: {0} Name: {1} Bonus: {2}, emp1.Employee_ID, emp1.Name, emp1.Bonus(10000));Console.WriteLine(Employee ID: {0} Name: {1} Bonus: {2}, emp2.Employee_ID, emp2.Name, emp2.Bonus(10000));Console.ReadLine();}
}
显然这个方式不符合里氏替原则的第四条它抛出了一个错误。所以我们需要继续修改代码并增加两个接口interface IBonus
{decimal Bonus(decimal salary);
}
interface IEmployee
{int Employee_ID { get; set; }string Name { get; set; }decimal GetSalary();
}
public abstract class Employee : IEmployee, IBonus
{public int Employee_ID { get; set; }public string Name { get; set; }public Employee(int id, string name){this.Employee_ID id;this.Name name;}public abstract decimal GetSalary();public abstract decimal Bonus(decimal salary);
}
public class GeneralEmployee : Employee
{public GeneralEmployee(int id, string name) : base(id, name){}public override decimal GetSalary(){return 10000;}public override decimal Bonus(decimal salary){return salary * .1M;}
}
public class ManagerEmployee : Employee
{public ManagerEmployee(int id, string name) : base(id, name){}public override decimal GetSalary(){return 10000;}public override decimal Bonus(decimal salary){return salary * .1M;}
}
public class TempEmployee : IEmployee
{public int Employee_ID { get; set; }public string Name { get; set; }public TempEmployee(int id, string name){this.Employee_ID id;this.Name name;}public decimal GetSalary(){return 5000;}
}
class Program
{public static void Main(){Employee emp new GeneralEmployee(101, WangPlus);Employee emp1 new ManagerEmployee(102, WangPlus1);Console.WriteLine(Employee ID: {0} Name: {1} Salary: {2} Bonus:{3}, emp.Employee_ID, emp.Name, emp.GetSalary(), emp.Bonus(emp.GetSalary()));Console.WriteLine(Employee ID: {0} Name: {1} Salary: {2} Bonus:{3}, emp1.Employee_ID, emp1.Name, emp1.GetSalary(), emp1.Bonus(emp1.GetSalary()));ListIEmployee emp_list new ListIEmployee();emp_list.Add(new GeneralEmployee(101, WangPlus));emp_list.Add(new ManagerEmployee(102, WangPlus1));emp_list.Add(new TempEmployee(103, WangPlus2));foreach (var obj in emp_list){Console.WriteLine(Employee ID: {0} Name: {1} Salary: {2} , obj.EmpId, obj.Name, obj.GetSalary());}}
}
四、接口隔离原则接口隔离原则要求客户不依赖于它不使用的接口和方法一个类对另一个类的依赖应该建立在最小的接口上。通常的做法是把一个臃肿的接口拆分成多个更小的接口以保证客户只需要知道与它相关的方法。这个部分不做代码演示了可以去看看上边单一责任原则里的代码也遵循了这个原则。五、依赖倒置原则依赖倒置原则要求高层模块不能依赖于低层模块而是两者都依赖于抽象。另外抽象不应该依赖于细节而细节应该依赖于抽象。看代码public class Message
{public void SendMessage(){Console.WriteLine(Message Sent);}
}
public class Notification
{private Message _msg;public Notification(){_msg new Message();}public void PromotionalNotification(){_msg.SendMessage();}
}
class Program
{public static void Main(){Notification notify new Notification();notify.PromotionalNotification();}
}
这个代码中通知完全依赖Message类而Message类只能发送一种通知。如果我们需要引入别的类型例如邮件和SMS则需要修改Message类。下面我们使用依赖倒置原则来完成这段代码public interface IMessage
{void SendMessage();
}
public class Email : IMessage
{public void SendMessage(){Console.WriteLine(Send Email);}
}
public class SMS : IMessage
{public void SendMessage(){Console.WriteLine(Send Sms);}
}
public class Notification
{private IMessage _msg;public Notification(IMessage msg){this._msg msg;}public void Notify(){_msg.SendMessage();}
}
class Program
{public static void Main(){Email email new Email();Notification notify new Notification(email);notify.Notify();SMS sms new SMS();notify new Notification(sms);notify.Notify();}
}
通过这种方式我们把代码之间的耦合降到了最小。六、迪米特法则迪米特法则也叫最少知道法则。从称呼就可以知道意思是一个对象应该对其它对象有最少的了解。在写代码的时候尽可能少暴露自己的接口或方法。写类的时候能不public就不public所有暴露的属性、接口、方法都是不得不暴露的这样能确保其它类对这个类有最小的了解。这个原则没什么需要多讲的调用者只需要知道被调用者公开的方法就好了至于它内部是怎么实现的或是有其他别的方法调用者并不关心调用者只关心它需要用的。反而如果被调用者暴露太多不需要暴露的属性或方法那么就可能导致调用者滥用其中的方法或是引起一些其他不必要的麻烦。 最后说两句所谓原则不是规则不是硬性的规定。在代码中能灵活应用就好不需要非拘泥于形式但是用好了会让代码写得很顺手很漂亮。 全文完喜欢就来个三连让更多人因你而受益
