DCI和继承并不矛盾

DCI背后概念是将交互行为从领域模型中分离出来，这些交互行为被放置于另外一个Role角色对象中，只有在业务需要的一个场景下，角色在运行时刻被分配(注射)给这个领域模型。

文章列车Ruby的DCI实现


class Person
  attr_reader :[author]name[/author]

  def initialize([author]name[/author])
    @[author]name[/author] = [author]name[/author]
  end
end

person = Person.new("Trygve Reenskaug")

module Buyer
  def buy(item)
    # buying logic
  end
end

module FootballPlayer
  def kick_ball(ball)
    # kicking ball logic
  end

  def run
    # running logic
  end
end

def FootballGameContext
  person.mixin FootballPlayer
  person.run
  person.kick_ball(ball)
  person.unmix FootballPlayer
end

def ShopContext
  person.mixin Buyer
  person.buy(milk)
end

FootballGameContext和ShopContext是人分别参与的两个场景：足球游戏和购物，人还是那个人，只不过在这两个场景下被赋予了角色的业务行为。

作者认为DCI是一个非常有前途的编程范式，解决了一些OOP问题，但他说没有看到什么大程度应用是用DCI写的，因此好像没有证据就此证明DCI用mixin或等设计模式会比传统OOP更清晰更可读。DCI因为不成熟缺乏模式遵循，主要问题之一是何时及如何定义一个场景上下文Context还比较模糊。(banq认为如果结合领域事件，场景隐含，由事件代表可解决这个问题)

继承是OOp传统基本技术，描述数据模型之间的"is-a"关系，继承会导致不可维护的代码，被一些人认为是邪恶的，有很多方法可替代继承，如Mixin 策略模式和适配器模式。

作者认为以他的经验，每种方式都有其最合适的使用前提和场景。

作者展示了继承和DCI一起使用的案例。

banQ观点：其实继承和DCI是从不同角度的思考，继承是从纯业务角度思考，儿子继承父亲，这是业务领域正常的方式，你只能用继承表达；而DCI则是一种软件实现方法，不是业务的映射工具或方法，而是处理业务的方法和工具，可以让业务更灵活一些，两个边界不同，无可比拟性。

[该贴被banq于2011-09-10 18:15修改过]