第一是将数据库引擎从应用中抽象出来,这样就可以随时改变数据库—比方说,从微软SQL变成Oracle。不过在实践上很少会这么做,也没有足够的理由未来使用实现数据访问层而进行重构现有应用的努力。[1]
第二个目标是将数据模型从数据库实现中抽象出来。这使得数据库或代码开源根据需要改变,同时只会影响主应用的一小部分——数据访问层。这一目标是值得的,为了在现有系统中实现它进行必要的重构。
模块与接口重构
依赖注入背后的一个核心思想是单一功能原则(single responsibility principle)。该原则指出,每一个对象应该有一个特定的目的,而应用需要利用这一目的的不同部分应当使用合适的对象。这意味着这些对象在系统的任何地方都可以重用。但在现有系统里面很多时候都不是这样的。[1]
随时增加单元测试
把功能封装到整个对象里面会导致自动测试困难或者不可能。将模块和接口与特定对象隔离,以这种方式重构可以执行更先进的单元测试。按照后面再增加测试的想法继续重构模块是诱惑力的,但这是错误的。[1]
使用服务定位器而不是构造注入
实现控制反转不止一种方法。最常见的办法是使用构造注入,这需要在对象首次被创建是提供所有的软件依赖。然而,构造注入要假设整个系统都使用这一模式,这意味着整个系统必须同时进行重构。这很困难、有风险,且耗时。
有0 个人打赏