很有道理，的確在一個正確的物件導向設計的模組中，功能執行者不應負責檢查前置條件合法與否，我想這一點，或許也是 OGRE 作者設計出這種使用方法的本意吧！

但從另一個角度來看，就現實層面來說，程式設計者可是以懶惰著稱的傢伙（我自己也是），許多人並不會嚴謹地遵循物件導向設計的思維理念，所以若要將前置條件交由模組的使用者自行檢查的話，仍然會產生一定的風險，不可不慎哪。

感謝你提供的設計思維！ ：）

view plaincopy to clipboardprint?
Animation* pkAnim = NULL;
String kAnimationName = “char_idle”;
// 先檢查存在性（不會拋出例外狀況）
if (mSceneMgr->hasAnimation(kAnimationName)) {
// 確認存在就可以取值
pkAnim = mSceneMgr->getAnimation(kAnimationName);
}

Animation* pkAnim = NULL;
String kAnimationName = “char_idle”;
// 先檢查存在性（不會拋出例外狀況）
if (mSceneMgr->hasAnimation(kAnimationName)) {
// 確認存在就可以取值
pkAnim = mSceneMgr->getAnimation(kAnimationName);
}
原來可以直接檢查 getAnimation() 回傳值是否為 NULL 值的方式，在 OGRE 中需要多出一個檢查的步驟，對於許多程式設計者來說，可能一時也難以習慣這樣的作法。”

我有不同的看法,其實OO中有個這樣的習慣或是說UC的約定，功能執行者不負責檢查前置條件是否成立，UC中，前置條件是功能正常執行的最小保證，應該由呼叫者來保證前置條件的正確性。在您說的這個例子中，getAnimation本身是類的一個public公開方法也就是說是一個對象提供的一個功能執行者，那麼的確不該在內部來檢查參數的正確性。但如果getAnimation是private或是protected的話，那麼他的參數就不是前置條件，在UC中應該定義為“約束”，“約束”也可以是參數，這時，約束便可以在內部作檢測，因為被命名為private或protected的目的就是不想在類外部來暴露這個操作，換言之，它就不是一個對象提供的一個功能執行者。

上面是在下的一點愚見。

在架構設計上，OGRE 真的有很值得學習之處，缺點也如同你所提的，過度使用 STL 容器以及低階演算法效能不佳等等。我想，以可用於商業化遊戲的免費資源來說，OGRE 已算是目前最完善也最活躍的繪圖引擎了。

我認為 OGRE 整體的設計理念與系統架構相當正確。做為一個開源專案，OGRE 的目標是先建構出精巧又可擴充的引擎設計架構，之後再逐步修改細節與底層的部分。當然，OGRE 的未來還有很大的進步空間、很長的路要走，就看開源社群和專案主導者 sinbad 的作為了。

國外有個使用 OGRE 的 MMORPG 正在開發中，大概要 18 至 24 個月後才會上市，我很期待那款遊戲作品的表現～ ^^

而Ogre最令人激賞是它的API設計,
完全follow OOP的精神, class切得細, 功能明確簡單, 很難看到一個class有上數十個member function,
而且object的ownership定義的很明確,
使業餘人士可以很快的掌握它的精神和使用它, 並且開發出小型作品。
當我是學生時, 只花了一個月就可以使用自如, 比起在業界經驗, Ogre的架構實在值得業界學習。

如果你們沒有非常熟悉程式設計的話，我會比較建議使用 XNA 喔。

因為 OGRE 實際上是一個「繪圖引擎」，如果要使用繪圖引擎完成一款遊戲作品，仍需要花費非常多的程式設計心力才有可能達成。而 XNA 則是屬於一個「遊戲框架」，天生就是拿來做為撰寫遊戲的用途。目前在市面上，有不少 XNA 相關的中文書籍，網路上也有許多簡體或繁體的中文網站資源可參考。

不過，不論是使用 OGRE 或者 XNA，一樣都需要花費大量的時間在撰寫程式碼上喔。

因為網路上看到的幾乎都是片段.學校也沒有書可以看…

我們只剩下不到一個月的時間必須要做出一半的遊戲…

謝謝