OO之美2

面向对象并没有想象中那么神秘,以生活的现实眼光来看更是如此.把面向对象深度浓缩起来,可以概括为:
⑴目标:重用,扩展,兼容
⑵核心:低耦合,高内聚
⑶手段:封装变化
⑷思想:面向接口编程,面向抽象编程,面向服务编程
举例:在三层架构中,数据层与业务层是用接口作为隔离的抽象,而业务层和表现层同样是用接口作为隔离的抽象,这就保证了重用,扩展以及兼容性
软件任何的设计问题,都可以通过引入中间逻辑得到解决

依赖倒置:1,高层模块不应该依赖于低层模块,二者应该依赖于抽象.2,抽象不应该依赖于具体,细节应该依赖于抽象.你不要来调我,我来调你

当面试官问你为什么要依赖倒置时:你可以从以下几个点来回答
1,依赖倒置时保证开放封闭的前提和基础
2,依赖倒置是对抽象和依赖的基本原则和基本思想的哲学阐释
3,依赖倒置是框架设计的核心思想
4,依赖导致是控制饭庄和依赖注入的思想基础

以前的结构化编程高手一般一出手就是高层依赖于低层的典型套路.带来的麻烦往往是当低层出现了一点点变化,高层也要跟着变化.例如低层多了结果案例,则高层就多了几个if else
而现在依赖于抽象,则不管低层如何变化,高层都是不变的
所以说,当你的代码中没有出现依赖倒置,依然还是结构化编程,而非面向对象编程
就原理而言:
1,少继承,多聚合
2,单向依赖(低耦合,高内聚)
3,封装抽象
4,对依赖关系都应该终止于抽象类和接口
在此,引用BOb大叔三句话,
①任何变量都不应该持有一个指向具体类的指针或者引用
②任何类都不应该从具体类派生
③任何方法都不应该覆写它的任何基类中已经实现的方法.

典型的以new进行的对象创建操作,是对依赖倒置原则的典型违反,而通过依赖注入进行对象的创建解耦是常用的解决之道

一味的遵守原则,就等于没有原则.重要的是,需要把握平衡,在进行开发中适当地把握其程度.Bob在<>中也提到并总结了两个弊端,同样需要特别的关注:
1,######对抽象编程,需要增加必要的类和辅助的代码进行支持,某种程度上增加了系统复杂度和维护成本.#######
2,#######当具体类不存在变化时,遵守依赖倒置是多此一举.所以,如果具体或细节没有变化可能时,没有必要通过抽象转嫁依赖.#######

解构控制反转(IOC)和依赖注入(DI)

控制反转

简而言之,控制反转就是代码的控制器交由系统控制,而不是在代码内部,通过IOC,消除组件或者模块间的直接依赖,使得软件系统的开发更具有柔软性和扩展性.控制反转的典型应用体现在框架系统的设计上,是框架系统的基本特征,不管是.NET Framework抑或是Java Framework都是建立在控制反转的思想基础之上的.
控制反转很多时候被看作是依赖倒置原则的一个同义词,其概念产生的背景大概来源框架系统的设计,例如:.NET Framwork就是一个庞大的Framwork系统.在.net framework大平台上可以很容易的构建ASP.NET Web应用等等其他应用.很多时候,基于 .net framework构建自定义系统的方式就是对.net framework本身的扩展,调用框提供的基础API,扩展自定义的系统功能和行为.然而,不管是如何构建新的或者扩展自定义功能,代码执行的最终控制权还是回到框架中执行,再交回应用程序.所以控制反转强调控制权的反转,体现了控制流程的依赖倒置,所以从这个意义上来说,控制反转是依赖倒置的特例.

依赖注入(请关注Unity)

客户依赖于服务类的抽象接口,并在运行时根据上下文环境,由其他组件(例如DI容器)实例化具体的服务类实例,将其注入到客户类的运行时环境,实现客户类与服务类实例之间松散的耦合关系.
常见的三种注入方式
Ⅰ.接口注入,将对象间的关系转移到一个接口,以接口注入控制.
Ⅱ.构造器注入,客户类在类型构造时,将服务类实例以构造函数参数的形式传递给客户端,因此服务类实例一旦注入将不可修改.
Ⅲ.属性注入,通过客户类属性设置的方式,将服务器实例在运行时设定为客户类属性,相较构造器注入方式,属性注入提供了改写服务器类实例的可能.

经典设计模式
⑴创建型模式;工厂方法,抽象工厂,单例,创建者,原型模式
创建型模式的核心关注点就在于对象的创建的依赖关系上.将对象的依赖从new操作中解脱出来,隔离应用系统和类型实例化间的依赖.例如通过引入工厂,将对象创建职责委托于工厂类,解除了应用系统与类型对象在实例化过程中的直接引用.
⑵结构型模式:桥接,适配器,组合,外观,装饰,享元,代理
结构型模式,是将简单类型组合为复杂类型的过程.通过灵活的设计要素,最终保证不同类型间保持尽量间接的引用和尽量松散的耦合,在复杂类型有更多变化与诉求时.以最小的代价兼容变化,扩展诉求.例如,适配器模式的两种不同适配方式,分别代表了通过继承和组合方式实现对象适配的处理;而代理类模式,则通过引入代理,来隔离不同层次间的依赖,同时保证真实对象的安全性与封装性.
⑶行为型模式:模板方法,迭代器,中介者,职责链,解释器,命令,观察者,备忘录,状体,策略,访问者
行为型模式,关注对象行为的扩展和对象间数据关系的通信,以面向对象方式描述控制流.例如.职责链避免请求的发送者和接收者直接的直接耦合,而是将多个对象连成一条处理链条;而命令模式的核心则在于将行为的请求者和行为实现者之间通过封装的命令对象解耦.

总结:
关于依赖的哲学不规则总结
1,以new创建对象,是对依赖倒置原则典型的违反,可以通过工厂模式或者依赖注入来解决
2,一个对象持有另一个具体对象的引用可能破坏了依赖倒置
3,所有结构良好的面向对象都具有清晰的层次定义,每个层次通过一个定义良好的受控接口向外提供一组内聚服务.
4,依赖倒置预示着程序中的依赖关系不应该是具体的类型,而应该是抽象类和接口
5,依赖倒置适用于当一个类向另一个类发送消息的任何情况.