2009-08-07 40 views
3

我知道有幾個關於OOD的問題;這一個不是重複的(我希望),因爲它的特殊性 - 可以將數據處理成一個類的功能嗎?面向對象的分析和設計:過程是一個類嗎?

首先,一些背景。

這是我主管和我一起討論的結果。我本來應該寫一個視頻加載類。他的想法是擁有一個加載自己的Video類。

我想通過它,並提出了一個Video類,它存儲編解碼器,文件名,每秒幀數,更重要的是字節數組,以及一個VideoLoader類,它需要一個文件名,對Video類的引用,然後填充它。

我的主管說這是不正確的。 「一個班級應該總是有一個國家」。我假設他在這裏是指私人成員。 「VideoLoader只是一堆處理功能,它不應該是一個類」。我認爲我正在脫鉤。如果我們使用不同的庫(當前爲FFMPEG)加載視頻,未來的VideoLoader可能具有抽象基類。

雖然它仍然有點打擾我。 OOD總是描述找到動詞和名詞,而'僅處理類'很少從OOD設計中出現。 OOD中是否有指導?

+0

只是一個附錄是具體的,我正在尋找的是爲什麼方法是有效的,最好備份一些參考的原因。 – Extrakun 2009-08-07 08:08:50

回答

3

我同意你的方法。

考慮你的VideoLoader是一個助手類,它用於在你說視頻實例時用於實例化或填充。這是將責任分開,而不是將其全部納入一個實體的好設計的一部分。無論如何,在許多面向對象的框架中,不可能有沒有包裝類的獨立方法。

如果您希望取悅您的主管,您可以在您的Video類中放入Load方法,並使其成爲實例化視頻的唯一方法。

public class Video 
{ 
    private Video() 
    { 
    } 

    public Video Load (/* Parameters */) 
    { 
     Video video = new Video(); 

     // Set up this video object 

     return video; 
    } 
} 

你這樣做的方式實際上有一個術語 - Factory pattern

看看這裏:Factory method pattern。這正是你正在做的。您使用工廠來實例化各種類型的視頻類(編解碼器相關或其他)。

3

我總是有些可疑的名字以'er'結尾的類,比如Loader,Runner,Writer等等。通常,這些命名方式會讓你不能在那個momement想到更好的名字,或者您尚未正確識別該類的潛在角色。我對此無法避免,僅在昨天我創建了一個「Echoer」類。也許今天我會發現它應該被稱爲什麼。

關於缺少狀態,是的,我會說如果班級沒有狀態,只是一堆功能有問題。但我不會太擔心,你可能很快就會發現什麼是錯誤的,並發現修復它會引入一些狀態。

在一天結束時,面向對象的設計和編程是一個迭代的探索過程。不要太在意第一次把事情做好 - 面向對象技術的最大優勢之一是,通常可以在不破壞系統其他部分(如果有的話)的情況下進行更改和更正(又稱重構)。

1

這對我來說聽起來很好,而且你描述的方式(假設方法是非靜態的),它就是Strategy模式的一個例子。我從來沒有聽說過任何指示類必須總是有狀態的指南。

1

我真的不明白這個'班必須有州'的說法。一個類只是封裝功能的一種方式。無論是實際維護內部狀態,還是按需計算答案,以及該狀態是否可以由特定調用者訪問或更改,都是與我無關的所有實現細節。

想到的兩種模式是factory(由另一張海報提及)和flyweight。在這兩種情況下,在課堂上沒有實現這種模式的狀態是非常合理的。在你的情況你的VideoLoader類允許你選擇視頻實現。正如你所說,這似乎是一個有用的解耦的明顯例子(通過工廠)。

如果我實現了一個斐波那契類,它爲您提供的整數計算斐波那契數列,它是否對您產生影響,無論我實際計算它,還是爲您提供內部存儲爲「狀態」的緩存值?只要我給你正確的號碼,當你要求一個,合同保持。

使用沒有狀態的flyweight對象的一個​​例子是實現通用對象,如RPG中的岩石或金件。每個金片都是相同的,但你仍然想定義多種方法來允許與金片相互作用。例如,您可能想要更仔細地檢查金片,並收到一些信息。通過金件類提供這些信息是有意義的。每個金片對象存儲不能改變的相同狀態是沒有意義的。指向一個共享狀態的指針顯然是正確的。但從外部物體的角度來看,金片物體看起來就像任何其他物體一樣;只需要一個只讀的界面即可。

0

VideoProcessor可能有一個狀態。

  1. 已處理的字節數。
  2. 處理過程中的錯誤數量。
  3. 處理階段。