关于面向对象的的设计原则的使用

关于面向对象的原则,相信大家都很清楚.但真正使用时,我想我们都会违反一些原则,因为要遵守这些原则,我们必须要多写好多代码.最后得不尝试. 下面我就关于这些原则发表一下个人的看法:

一、单一职责原则    就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。 
  这个很重要 ,我在程序开发中都会遵守这个原则.

二、“开一闭”原则讲的是：一个软件实体应当对扩展开放，对修改关闭。 这个规则说的是，在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。 从另外一个角度讲，就是所谓的“对可变性封装原则”。“对可变性封装原则”意味着两点： 1 .一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。同一种可变性的不同表象意味着同一个继承等级结构中的具体子类。 2.一种可变性不应当与另一种可变性混合在一起。即类图的继承结构一般不应超过两层。 做到“开—闭”原则不是一件容易的事，但是也有很多规律可循，这些规律同样也是设计原则，它们是实现开—闭原则的工具。 
   这个也比较重要,但现实中也是比较难实现,经常由于业务规则变了,我们不得不更改我们的类.除非一些我们可预见的,比如缓存,我们有多种实现的方式,所以通过定义接口的方式.如果我们要换一种缓存方案,我们只要换一个实现类就行了.

三、里氏代换原则： 如果对每一个类型为T1的对象o1,都有类型为T2的对象o2，使得以T1定义的所有程序P在所有对象o1都换成o2时，程序P的行为没有变化，那么类型T2是T1的子类型。 即如果一个软件实体使用的是基类的话那么也一定适用于子类。但反过来的代换不成立。 如果有两个具体类A和B之间的关系违反了里氏代换原则，可以在以下两种重构方案中选择一种： 1 .创建一个新的抽象类C,作为两个具体类的超类，将A和B共同的行为移动到C中，从而解决A和B行为不完全一致的问题。 2 .从B到A的继承关系改写为委派关系。   
    这个我们也经常用到,我们经常会把一些类共同的东西,抽象到基类里去实现,比如增加,删除,修改,查询等.同时我们也会用一些vitual函数,和override去重写一些基类行为.

四、依赖倒置原则 依赖倒置原则讲的是：要依赖于抽象，不要依赖于具体。即针对接口编程，不要针对实现编程。针对接口编程的意思是，应当使用接口和抽象类进行变量的类型声明、参量的类型声明，方法的返还类型声明，以及数据类型的转换等。不要针对实现编程的意思就是说，不应当使用具体类进行变量的类型声明、参量的类型声明，方法的返还类型声明，以及数据类型的转换等。 依赖倒置原则虽然强大，但却不易实现，因为依赖倒置的缘故，对象的创建很可能要使用对象工厂，以避免对具体类的直接引用，此原则的使用还会导致大量的类。维护这样的系统需要较好的面向对象的设计知识。 此外，依赖倒置原则假定所有的具体类都是变化的，这也不总是正确的。有一些具体类可能是相当稳定、不会发生变化的，消费这个具体类实例的客户端完全可以依赖于这个具体类。 
   这个东西我们就会经常违反的.比如我们的三层架构,我相信很多人都是直接new一个对象去操作的.如果那么多表,我们都是针对接口编程,我们会发现这些东西其实用处不大.因为我们大部分项目的dal层,bll层是不变的.其实我也用过一个框架,那里就是所有的dal,bll层都基于IOC编程的.结果我发现,用起来真的很麻烦的. 我们想增加一个方法要在4个地方写函数. 而且想用F12跟进去查看代码,是跟不进去的.只能跟到接口那里.  最要命的就是它那个报错.经常会报配置错误,其实一查根本不是配置错误.只是生成的类有问题

五、接口隔离原则 接口隔离原则讲的是：使用多个专门的接口比使用单一的接口要好。从客户的角度来说：一个类对另外一个类的依赖性应当是建立在最小的接口上的。如果客户端只需要某一些方法的话，那么就应当向客户端提供这些需要的方法，而不要提供不需要的方法。提供接口意味着向客户端作出承诺，过多的承诺会给系统的维护造成不必要的负担。 
  这个也是我们要去遵守的.

六、合成、聚合复用原则 合成、聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部份，新的对象通过向这些对象的委派达到复用已有功能的目的。这个原则有一个简短的描述：要尽量使用合成、聚合，尽量不要使用继承。合成、聚合有如下好处： 新对象存取成分对象的唯一方法是通过成分对象的接口。 这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不到的。 这种复用可以在运行时间内动态进行，新对象可以动态的引用与成分对象类型相同的对象。 合成、聚合可以应用到任何环境中去，而继承只能应用到一些有限环境中去。 导致错误的使用合成、聚合与继承的一个常见原因是错误的把“Has-a”关系当作“Is-a”关系。如果两个类是“Has-a”关系那么应使用合成、聚合，如果是“Is-a”关系那么可使用继承。 
  这也是我们经常用到的.

七、迪米特法则 迪米特法则说的是一个对象应该对其它对象有尽可能少的了解。即只与你直接的朋友通信，不要跟陌生人说话。如果需要和陌生人通话，而你的朋友与陌生人是朋友，那么可以将你对陌生人的调用由你的朋友转发，使得某人只知道朋友，不知道陌生人。换言之，某人会认为他所调用的是朋友的方法。 以下条件称为朋友的条件： 当前对象本身。 以参量的形式传入到当前对象方法中的对象。 当前对象的实例变量直接引用的对象。 当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友。 当前对象所创建的对象。 任何一个对象，如果满足上面的条件之一，就是当前对象的朋友，否则就是陌生人。 迪米特法则的主要用意是控制信息的过载，在将其运用到系统设计中应注意以下几点： 在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。 在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。 在类的设计上，只要有可能，一个类应当设计成 在对其它对象的引用上，一个类对其它对象的引用应该降到最低。 
    这个也是我们要去遵守的.

上面是在对oop使用原则的理解,不知道大家是如何理解的.