DCI和繼承並不矛盾

banq發表於2011-09-10
繼承
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 class="indent">


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

相關文章