2010-07-16 43 views
1

我在寫繪畫程序。我的基本類是:面向繪畫程序界面的OO設計

class Workspace { Bitmap b; List<Command> undoList; } 

    class Command { void execute(); } 

    class ClearScreen extends Command 

    class BlurEffect extends Command 

    class View { Bitmap screen; } 

    class Interface 

工作空間對象包含表示程序狀態的位圖。 Command類表示通過重置工作區狀態和重放舊命令來執行撤消操作的工作區上執行命令的命令模式。接口對象鏈接從用戶到命令的按鈕按下,視圖將工作空間狀態呈現給屏幕位圖。

我的問題是與表示命令。 ClearScreen命令很簡單;它只是告訴工作空間用白色填充位圖,它會立即發生。 BlurEffect命令更復雜;模糊需要一個模糊屏幕的參數,執行可能需要一些時間,用戶通常想在選擇模糊參數之前嘗試一些模糊參數(即在提交之前需要預覽模糊效果的樣子)。我如何修改上述以支持這種預覽?

我能想出的最好的是命令的東西,如延長:

class BlurCommand extends Command 
    { 
    void setBlurAmount(float x) ... 

    // View can use this to render a preview to the 
    // screen bitmap, where the workspace bitmap isn't modified in the process 
    void preview(Workspace w, Bitmap b) 

    void execute() // apply blur effect to workspace 
    } 

這樣的想法是,在界面中,點擊「模糊」按鈕,創建一個新的BlurCommand對象時,「渲染View中的屏幕「方法然後開始調用」預覽「方法來渲染屏幕,並且僅當用戶想要應用效果時才調用」執行「。

這是最乾淨的方式,我可以做到這一點?我試圖堅持模型 - 視圖 - 控制器設計,不希望我的預覽行爲複雜化。

回答

0

是的,或者您可以應用模糊,如果操作被取消,則撤消它,或者如果參數更改,則撤銷並重做。如果重放整個命令堆棧太耗時,則可以在應用模糊之前拍攝快照。

+0

謝謝,我也考慮過這個。模糊圖像比從磁盤加載快照快。在這種情況下,最好使用View的位圖來預覽圖像,而不是在Workspace的位圖上預覽結果,這會迫使我從快照中恢復以嘗試其他模糊。 – BobDuck 2010-07-16 13:01:51

0

你有任何單元測試測試你的繪畫程序的當前功能嗎?我認爲有一件事會真正幫助你達成一個可靠的設計,就是使用TDD(測試驅動開發/設計)。編寫一個模擬「預覽」類型動作的測試,然後通過測試。一旦你現有的測試和新的預覽測試全部通過,然後看看你的應用程序代碼是什麼樣的。

+0

我現在就在設計。當然,單元測試是一個好主意。 – BobDuck 2010-07-16 12:58:40

+0

關於TDD的一點是,您不要先設計代碼,先編寫測試代碼,並讓代碼的設計從測試期望系統的工作方式發展而來。 – 2010-07-16 13:03:29

+0

我不知道這是如何幫助這裏。有很多實現可以通過例如模糊預覽和模糊應用測試。我正在尋找一個乾淨的實現,而不僅僅是一個能夠通過測試的實現。 – BobDuck 2010-07-16 13:41:34

0

您的設計至今看起來不錯。這裏是我的觀點:你用blur命令面臨的問題是更多這樣的事情發生的一個指標,因此應該在你的設計中增加更多這樣的命令。因此,您可以爲命令創建兩個子類 - FastCommandSlowCommand。 FastCommand只有doItundoIt方法,並且只會執行並將其添加到命令堆棧中。 SlowCommand應該是一個異步命令,具有兩步處理過程 - 預覽&提交。第一次執行SlowCommand時,它應該被執行但不會被添加到命令堆棧中。相反,只要將它保留在工作區中作爲參考。當用戶實際確認動作時,再次執行(此時它執行實際操作),然後將其移至命令堆棧。

View類可能不是必需的。

來到SlowCommand的實際撤消重做機制,您可以根據性能和可用內存決定最佳方法 - 創建緩衝區副本,然後丟棄它,或者可以在同一緩衝區上運行逆算法。如果您發現您在應用程序中同時使用這兩種策略,則可以在命令中使用Strategy Pattern