你的位置:首页 > ASP.net教程

[ASP.net教程]面向对象(五)——类库和五大原则


一、类库

引用别人写的类

1、源代码方法

可以将直接写好的.cs源代码文件,添加进我的解决方案文件夹下,在解决方案资源管理器中, 项目上右键→添加→现有项,来添加此.cs源代码文件的使用,需要引入相应的命名空间

2、类库方法

      一个dll文件,就是一个类库 它人新建一个类库,在里面编写类和相应的方法,生成后出现一个dll文件,拿过来,放在自己的 程序文件夹里,在项目右键→添加引用→找到此dll类库文件添加,然后引用命名空间,就可以调用相应的类中的方法了

意类一定要是public访问权限
      类库使用是多公司联合开发时使用的方式,因为每个公司都有自己的核心技术,我允许你使用,但不允许你 知道我是怎么编写的,所以需要dll类库文件,因为dll文件是将源代码文件编译后的文件,看不到源代码, 所以你只能调用不允许更改

二、五大原则

1.单一职责原则SRP(Single Responsibility Principle)

是指一个类的功能要单一,不能包罗万象。如同一个人一样,分配的工作不能太多,否则一天到晚虽然忙忙碌碌的,但效率却高不起来。

2.开放封闭原则OCP(Open-Close Principle)

      一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。例继承。

      比如:一个网络模块,原来只服务端功能,而现在要加入客户端功能, 那么应当在不用修改服务端功能代码的前提下,就能够增加客户端功能的实现代码,这要求在设计之初,就应当将服务端和客户端分开,公共部分抽象出来。

3.里氏替换原则(the Liskov Substitution Principle LSP)

      子类应当可以替换父类并出现在父类能够出现的任何地方。

      比如:公司搞年度晚会,所有员工可以参加抽奖,那么不管是老员工还是新员工, 也不管是总部员工还是外派员工,都应当可以参加抽奖,否则这公司就不和谐了。

4.依赖倒置原则(the Dependency Inversion Principle DIP)

     具体依赖抽象,上层依赖下层

     假设B是较A低的模块,但B需要使用到A的功能, 这个时候,B不应当直接使用A中的具体类: 而应当由B定义一抽象接口,并由A来实现这个抽象接口,B只使用这个抽象接口:这样就达到 了依赖倒置的目的,B也解除了对A的依赖,反过来是A依赖于B定义的抽象接口。通过上层模块难以避免依赖下层模块,假如B也直接依赖A的实现,那么就可能造成循环依赖。一个常见的问题就是编译A模块时需要直接包含到B模块的cpp文件,而编译B时同样要直接包含到A的cpp文件。

5.迪米特法则(Law of Demeter)

     又叫作最少知识原则(Least Knowledge Principle 简写LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。

     英文简写为: LoD.迪米特法则可以简单说成:talk only to your immediate friends。 对于面向OOD来说,又被解释为下面几种方式:一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。 迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模块功能独立,相互之间不存在(或很少有)依赖关系。 迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系,也希望能通过它的友元类来转达。因此,应用迪米特法则有可能造成的一个后果就是:系统中存在大量的中介类,这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。 有兴趣可以研究一下设计模式的门面模式(Facade)和中介模式(Mediator),都是迪米特法则应用的例子。