C++：不確定班級經理的關係

在我的項目中，我有一系列類，其中的實例由某些經理類進行管理，出於具體原因。C++：不確定班級經理的關係

例子是：

CSound的 - 文摘單個聲

CSoundManager - CSound的的朋友，提供用於創建 CSound的實例工廠方法，混合活性聲音一起

另外：CFont，CFontManager（用於字體訪問名稱），CSprite，CSpriteManager（用於繪製每一幀）等等。

這裏我的第一個問題已經：

是我在做什麼具體的命名設計模式？
大多數情況下，無論出於何種原因，這是一個壞主意嗎？如果是，爲什麼？

然後，我問自己：

應該如何創建和銷燬的對象？我是否應該允許在堆棧中創建它們，或者直接使用new，或者只使用相應的管理器類的方法創建它們？

（也毀滅：delete myFont;與FontManager.DestroyFont(myFont);）

來源

2011-03-08 Jasm

不要在班級名稱的開頭放置「C」。育。 – 2011-03-08 18:10:39

更好的問題是'爲什麼一切都以C開頭？'很多項目都是這樣做的，而不是命名空間。我能想到的最大的例子是虛幻引擎，它以'Un'爲前提（幾乎）所有東西。但是，這確實會使朗讀某些類名稱具有'UnFortunateConsequences' ... – James 2011-03-08 18:19:41

Microsoft對它們的MFC類也做同樣的事情。例如，他們也有CFont類。這是在你自己的課堂上不使用C的好理由！ – 2011-03-08 18:42:05

看起來像你正在使用某種形式的工廠設計模式的。不知道是什麼讓你覺得它是一個壞主意。

如果您將Manager視爲對象的容器，那麼它將控制這些對象的生命週期。但是，如果您的對象需要超出Manager的壽命，那麼您將使用新的方式創建它們，並且Manager可能不會負責銷燬。

來源

2011-03-08 18:18:57 Nilesh

聽起來像你可能違反了The Single Responsibility Principle (SRP)原則。

CSoundManager類負責創建和管理對象的生存期，還是負責混合主動聲音？名稱可以告訴你很多，而「經理」可以用許多方式來理解......

一般來說，如果你想讓這些經理類處理你的對象的生命期，那麼他們應該是唯一的方法實例化這些對象（即對象中的私有對象）。儘管你的實現有些不同，但請參閱Factory Design Pattern。

如果你這樣做，那麼客戶端代碼應該是從不請致電new或delete。手動調用delete容易出錯，應避免使用成語，如RAII。在這種情況下，Manager類應管理對象的生命週期，因此delete將永遠不會出現在客戶端代碼中。

來源

2011-03-08 18:21:11

通常你正在實現的是一個工廠方法模式，其中一個對象分配另一個對象。但是，由於您直接將分配類型綁定到工廠，而不是允許工廠抽象地管理所有內部，所以您不會從Factory類獲得好處。例如，你可以從任何文件，或只是該資源類型（CSoundManager）的工廠：new CSound（）;

如果是這樣，你就錯過了這一點，你基本上只有一個Singleton分配和管理一個對象。考慮抽象你的資源類型。如果CSound和CFont派生自IResource，那麼您可以擁有一個CResourceManager，它只需要一個枚舉類型或某種類型的該類型的標識符，並減少代碼庫中的耦合和依賴關係。無論何時你需要使用這個對象，你都可以暴露這個類型，但是更有可能的是你可以使用一個抽象管理器（CResourceManager）來使用通用接口（Update（），Create（），Destroy（）等來處理這些對象）。

對於您的聲音管理器案例，請記住聲音只需加載一次，並且可以使用獨特的狀態進行實例化。在該權利中，讓資源管理器管理實際資源（CSound），並且聲音管理器（CSoundManager）維護離散實例（例如CSoundInstance）並管理混合（通過CSoundMixer）。以有意義的方式專門化您的課程，管理複雜性並減少冗餘。

我以聲音管理器爲例，但這適用於大多數io系統（圖形，輸入，物理）。

來源

2011-03-16 16:34:51 SilentDirge

C++：不確定班級經理的關係

回答

相關問題