面向对象的五大基本原则
单一职责原则（SRP）
开放封闭原则（OCP）
里氏替换原则（LSP）
依赖倒置原则（DIP）
接口隔离原则（ISP）
单一职责原则（SRP）
一个类应该仅有一个引起它变化的原因(最简单，最容易理解却最不容易做到的一个设计原则)
职员类例子：
比如在职员类里，将工程师、销售人员、销售经理这些情况都放在职员类里考虑，其结果将会非常混乱，在这个假设下，
职员类里的每个方法都要if else判断是哪种情况，从类结构上来说将会十分臃肿，并且上述三种的职员类型，不论哪一种发生需求变化，
都会改变职员类！这个是大家所不愿意看到的！
开放封闭原则（OCP）
既开放又封闭，对扩展是开放的，对更改是封闭的！
扩展即扩展现行的模块，当我们软件的实际应用发生改变时，出现新的需求，就需要我们对模块进行扩展，使其能够满足新的需求！
更改封闭即是在我们对模块进行扩展时，勿需对源有程序代码和DLL进行修改或重新编译文件！
这个原则对我们在设计类的时候很有帮助，坚持这个原则就必须尽量考虑接口封装，抽象机制和多态技术！
里氏替换原则（LSP）
子类可以替换父类并且出现在父类能够出现的任何地方
这个原则也是在贯彻GOF倡导的面向接口编程！
在这个原则中父类应尽可能使用接口或者抽象类来实现！
子类通过实现了父类接口，能够替父类的使用地方！
通过这个原则，我们客户端在使用父类接口的时候，通过子类实现！
意思就是说我们依赖父类接口，在客户端声明一个父类接口，通过其子类来实现
这个时候就要求子类必须能够替换父类所出现的任何地方，这样做的好处就是，在根据新要求扩展父类接口的新子类的时候而不影响当前客户端的使用！
依赖倒置原则（DIP）
传统的结构化编程中，最上层的模块通常都要依赖下面的子模块来实现，也称为高层依赖低层！
所以DIP原则就是要逆转这种依赖关系，让高层模块不要依赖低层模块，所以称之为依赖倒置原则！
ISP 接口隔离原则
这个原则的意思是：使用多个专门的接口比使用单个接口要好的多！
在实际编程中，为了减少接口的定义，将许多类似的方法都放在一个接口中，最后发现，维护和实现接口的时候花了太多精力，
而接口所定义的操作相当于对客户端的一种承诺，这种承诺当然是越少越好，越精练越好，过多的承诺带来的就是你的大量精力和时间去维护！
IOC
控制反转（Inversion of Control，英文缩写为IoC）是框架的重要特征，并非面向对象编程的专用术语。它与依赖注入（Dependency Injection，简称DI）
和依赖查找（Dependency Lookup）并没有关系。
优缺点编辑
IoC最大的好处是什么？
因为把对象生成放在了XML里定义，所以当我们需要换一个实现子类将会变成很简单（一般这样的对象都是实现于某种接口的），
只要修改XML就可以了，这样我们甚至可以实现对象的热插拔（有点像USB接口和SCSI硬盘了）。
IoC最大的缺点是什么？
（1）生成一个对象的步骤变复杂了（事实上操作上还是挺简单的），对于不习惯这种方式的人，会觉得有些别扭和不直观。
（2）对象生成因为是使用反射编程，在效率上有些损耗。但相对于IoC提高的维护性和灵活性来说，这点损耗是微不足道的，除非某对象的生成对效率要求特别高。
（3）缺少IDE重构操作的支持，如果在Eclipse要对类改名，那么你还需要去XML文件里手工去改了，这似乎是所有XML方式的缺陷所在。
实现策略编辑
IoC是一个很大的概念,可以用不同的方式实现。其主要形式有两种：
◇依赖查找：容器提供回调接口和上下文条件给组件。EJB和Apache Avalon 都使用这种方式。这样一来，组件就必须使用容器提供的API来查找资源和协作对象，
仅有的控制反转只体现在那些回调方法上（也就是上面所说的 类型1）：容器将调用这些回调方法，从而让应用代码获得相关资源。
◇依赖注入：组件不做定位查询，只提供普通的Java方法让容器去决定依赖关系。容器全权负责的组件的装配，它会把符合依赖关系的对象通过JavaBean属性或者
构造函数传递给需要的对象。通过JavaBean属性注射依赖关系的做法称为设值方法注入(Setter Injection)；将依赖关系作为构造函数参数传入的做法称为
构造器注入（Constructor Injection）
实现方式编辑
实现数据访问层
数据访问层有两个目标。第一是将数据库引擎从应用中抽象出来，这样就可以随时改变数据库—比方说，从微软SQL变成Oracle。不过在实践上很少会这么做，
也没有足够的理由未来使用实现数据访问层而进行重构现有应用的努力。第二个目标是将数据模型从数据库实现中抽象出来。这使得数据库或代码开源根据需要改变，
同时只会影响主应用的一小部分——数据访问层。这一目标是值得的，为了在现有系统中实现它进行必要的重构。
模块与接口重构
依赖注入背后的一个核心思想是单一功能原则（single responsibility principle）。该原则指出，每一个对象应该有一个特定的目的，而应用需要利用这一目的
的不同部分应当使用合适的对象。这意味着这些对象在系统的任何地方都可以重用。但在现有系统里面很多时候都不是这样的。
随时增加单元测试
把功能封装到整个对象里面会导致自动测试困难或者不可能。将模块和接口与特定对象隔离，以这种方式重构可以执行更先进的单元测试。按照后面再增加测试的想法
继续重构模块是诱惑力的，但这是错误的。
使用服务定位器而不是构造注入
实现控制反转不止一种方法。最常见的办法是使用构造注入，这需要在对象首次被创建是提供所有的软件依赖。然而，构造注入要假设整个系统都使用这一模式，
这意味着整个系统必须同时进行重构。这很困难、有风险，且耗时。