遺傳方法調用設計問題

我在使用Pharo設計面向對象應用程序時有點尷尬。遺傳方法調用設計問題

我有一個類Household，這個類有一個名爲tvConnection的屬性。此對象是Digital或Analog的實例。這兩個類都繼承了超級名字TVSubscription。

如果我想在一個電視添加到我的模擬有線電視訂閱我可以簡單地調用addTV: aTelevision我tvConnection屬性，然後將正確地調用該方法addTV:我在Analog類中實現。

數字連接不能連接電視機。這些必須是SetTopBox設備，而這些設備又可以將電視機連接到它們。

現在，我不得不拋出一個錯誤/顯示一些輸出，以防用戶試圖將電視添加到有數字連接的家庭。

我想我可以做兩兩件事：

1）我可以實現addTV：方法在Digital類，它只會執行什麼操作（例如顯示一個消息：「你不能這樣做！「）。但是這在很多方面似乎都是錯誤的......

2）我可以不執行該方法並捕獲引發的MessageNotUnderstood錯誤。當我做了以下這會發生：

**Adding a TV** 
--> call `addTelevision` in `Household` 
----> this `addTV:` on the `tvConnection` property 
----> catch error if any, which implies that a TV was being added to a digital connection

這兩種解決方案看起來非常髒了我。

來源

2013-11-25 Christophe De Troyer

如果我是你，我可能會實施addTV:數字，它可以將電視添加到一個盒子或說盒子丟失。

這看起來相當不錯。想想看這樣的：

TVSubscription>>addTV: aTV 
    self subclassResponsibility 

TVSubscription>>tvs 
    self subclassResponsibility

Analog有tvs變種。

Analog>>addTV: aTV 
    tvs add: aTV 

Analog>>tvs 
^tvs

Digital有box var。

Digital>>box: aBox 
    box := aBox 

Digital>>box 
^box 

Digital>>addTV: aTV 
    box 
    ifNil: [ Exception signal: 'Connect box' ] 
    ifNotNil: [ box addTV: aTV ] 

Digital>>tvs 
^box tvs

這只是第一個最好的想法。現在我會去睡覺，也許我會夢想一些更好的解決方案

來源

2013-11-25 23:15:27 Uko

我想我會採用這種方法。這看起來很簡單。我對這種可擴展性的唯一問題。我必須實現一個'Analog >> addSetTopBox'方法（顯示消息「不能將settopbox添加到模擬連接」）。假設我實現了另一種連接類型，例如'Sattelite'，它允許具有1或0個TV對象的'SatSetTopBox'設備。這意味着我將不得不爲所有對象實現一個'addSatSetTopBox'方法。這對我來說似乎是錯誤的？ –

爲什麼你需要區分這麼多？製作一個方法'addAdapter：'。然後讓班級決定他們是否可以使用這些適配器。你也可以更少限制。 E.I.允許連接任何適配器。但是當一個適配器不能理解其他適配器的消息時，事情就會崩潰。我認爲把事情放在更高層次的抽象上是很好的。所以你可以有適配器。然後每個訂閱應該知道它可以使用哪些適配器以及如何與它們交談 – Uko

也許你應該重新考慮你的設計。在我看來，tvConnection應該是一個連接對象，比如說TVConnection。 TVConnection可能有兩個小類DirectConnection和SetTopBoxConnection。 Digital和Analog將知道它們的連接類型，並且連接類型知道如何addTV:或更方便，Digital和Analog實施addTV:，並且簡單地委託給它們的TVConnection對象。

來源

2013-11-26 11:17:45

遺傳方法調用設計問題

回答

相關問題