共计 2754 个字符,预计需要花费 7 分钟才能阅读完成。
三大个性
封装、继承、多态性
拿简略工厂模式举例:
namespace DesignMode_01
{
// 计算基类
public class Operation
{
private double _numberA = 0;
private double _numberB = 0;
public double NumberA {get => _numberA; set => _numberA = value;}
public double NumberB {get => _numberB; set => _numberB = value;}
public virtual double GetResult()
{
double result = 0;
return result;
}
}
// 加法类
public class OperationAdd : Operation
{public override double GetResult()
{
double result = 0;
result = NumberA + NumberB;
return result;
}
}
// 减法类
public class OperationSub : Operation
{public override double GetResult()
{
double result = 0;
result = NumberA - NumberB;
return result;
}
}
// 工厂类:生产不同类的实例化对象
public class OperationFactory
{public static Operation CreateOperate(string operate)
{
Operation oper = null;
switch (operate)
{
case "+":
oper = new OperationAdd();
break;
case "-":
oper = new OperationSub();
break;
}
return oper;
}
}
// 当编译器遇到办法调用时,它首先在类型的实例办法中查找匹配项。如果找不到匹配项,它将搜寻为该类型定义的所有扩大办法,并绑定到找到的第一个扩大办法。public static class MyExtensions
{public static int Count(this String str)
{return str.Split(new char[] {'','.','?'},
StringSplitOptions.RemoveEmptyEntries).Length;
}
}
// 操作界面类
class Program
{static void Main(string[] args)
{
Operation operation;
operation = OperationFactory.CreateOperate("+");
operation.NumberA = 1;
operation.NumberB = 2;
double result = operation.GetResult();
// 调用扩大办法
string s = "Hello Extension Methods";
s.Count();}
}
}
封装:创立计算基类、工厂类和界面类让业务逻辑与界面逻辑离开,让它们之间的耦合度降落。
继承:加法减法类派生计算基类。
多态性 :定义 GetResult() 虚办法,让派生类对同一个办法产生不同实现。多态性的具体实现包含重载和重写。
六大准则
繁多职责准则 :就一个类而言,应该仅有一个引起它变动的起因。
比方:
- 你把业务逻辑、数据库拜访的 sql 语句什么都放在一个控制器里,这就意味着,无论什么需要要来,你都须要更改这个控制器,这其实是很蹩脚的,保护麻烦,复用不可能,也不足灵活性。这个时候就能够把程序分为服务层、仓储层,服务层专门用来解决业务逻辑,仓储层专门用解决数据库拜访的 sql 语句。
- boss 直聘前端页面一个搜寻文本框,能够让你抉择不同行业、不同月薪的分类按钮,按分类进行检索,这也是体现了繁多职责思维。
- 修电脑,显然内存坏了,不应该成为更换 CPU 的理由,他们各自的职责时明确的。当然,软件设计真正要做的许多内容,就是发现职责并把那些职责互相拆散。如果你可能想到多于一个的动机去扭转一个类,那么这个类就具备多于一个的职责,就应该思考类的职责拆散。
开发 - 关闭准则 :就是软件实体(类、模块、函数等等)应该能够扩大,然而不能够批改。即面对需要,对程序的改变是通过减少新代码进行,而不是更改现有的代码。然而,相对的对批改敞开是不可能的。在咱们最后编写代码时,假如变动不会产生。当变动产生时,咱们就创立形象来隔离当前发送的同类变动。
例如:
- 把一个加法程序,都在一个 client 类中实现,如果要加一个减法性能,减少性能就须要批改原来的这个类,这就违反了凋谢 - 关闭准则。能够通过减少一个形象的运算类,通过一些面向对象的伎俩,如继承、多态等来隔离具体加法、减法与 client 耦合。如果又要减少除法性能,你就不须要再去更改 client 以及加法减法的类了,而是减少乘法和除法子类就可。
- 中国的一国两制思维,原有的中国社会主义制度不能批改,为了回归大局,通过减少一种制度又何尝不可。
- C# 中的扩大办法,你不能批改微软的源码,然而微软给你提供了扩大办法,你能够通过新增扩大办法来实现需求。
- 电脑内存不够只有插槽足够就能够增加,硬盘不够能够用移动硬盘等。
依赖倒转准则 :说白了就是针对接口编程,不要对实现编程。
例如:
- 咱们的服务层、仓储层都是针对接口编程。只有仓储层接口不变,换任何数据库,都不影响服务层的业务逻辑。
里氏替换准则 :子类型必须可能替换掉他们的父类型。只有当子类能够替换掉父类,软件单位的性能不受到影响时,父类能力正真被复用,而子类也可能在父类的根底上减少新的行为。
例如:
- 为什么要独自在仓储层来引入通用的 ORM 长久化接口,是因为,升高耦合,如果当前想要换成 EF 或者 Deper,只须要批改 Repository 具体的实现类就行了,其余都不须要批改。
接口隔离准则: 客户端不应该依赖它不须要的接口;一个类对另一个类的依赖应该建设在最小的接口上。依据接口隔离准则,当一个接口太大时,咱们须要将它宰割成一些更细小的接口,应用该接口的客户端仅需晓得与之相干的办法即可。
迪米特法令 :如果两个类不用彼此间接通信,那么这两个类就不要该当产生间接的相互作用。如果其中一个类须要调用另一个类的某一个办法的话,能够通过第三者转发这个调用。首先强调的前提是在类的结构设计上,每一个类都该当尽量升高成员的拜访权限,也就是说,一个类包装好本人的 private 状态,不须要让别的类晓得的字段或行为就不要公开。基本思维是强调了类之间的松耦合。
例如:
- IT 部是形象的,哪怕外面的人到职换了新人,我的电脑出问题了也还是能够找 IT 部解决,而不须要意识其中的共事,纯靠关系帮忙了。就算须要意识,我也只有意识 IT 部的主管就能够了,由他来安顿工作。
正文完