DCI和继承并不矛盾

11-09-10 banq
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
<p>

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修改过]

猜你喜欢