2016-03-07 18 views
1

我正在嘗試使用OOP範例設計一些簡單的現場模擬。我面臨的問題是,由於缺乏這種方法的經驗,我不知道如何以自然的方式定義「正確」的對象及其關係。因此,我的問題更接近於軟件架構,而不是更多的技術「如何實現這個或那個」。請注意,我正在做這個練習,正是爲了瞭解這個編程範例。如何在簡單的物理模擬中設計有意義的對象及其關係

模擬試圖解決空間2D空間中粒子之間的相互作用(碰撞,吸引等)。我想到的第一個對象是Particle。我已經實現了這個類的位置,速度,質量等。我創建了方法來啓動它們,更新它們的位置(根據一些物理規則),甚至在畫布中繪製它們。現在,當設置物理常量或繪圖參數(畫布大小,窗口數量,每秒幀數等)時,我的問題就出現了。現在我使用全局變量,例如重力或畫布大小。這就是人們在非OOP方法中所能做到的,並且它的工作原理很遠。但我一直在想如何用一個純粹的面向對象來處理粒子之間的共享參數。我可以預見各種選擇。

  1. 我可以使用圖形參數創建類Canvas,並使用常量(例如重力)創建Universe。然後,類Particle將是一個擴展類。但我應該從哪個遺產中獲益呢?儘管如此,該課程將得到擴展,但不會是對象本身...
  2. 另一個選項可能是創建UniverseParticle作爲獨立的類。然後,我會通過創建一個唯一的Universe對象來關聯它們。每個粒子將包含一個指向這樣的Universe對象的指針,所以他們可以訪問物理參數。我不確定這個指針的方法是甚至是OOP ...

雖然我知道有很多方法可以做到這一點,我不知道是否有一個更直觀和「標準「至少從學術的角度來看。我想它不包含在我提出的解決方案中,所以任何關於如何在這種簡單模擬中設計結構的暗示都將非常受歡迎。

+0

小心:OOP和性能可能難以結合。 http://programmers.stackexchange.com/questions/125753/does-object-orientation-really-affect-algorithm-performance –

回答

1

這是一個更實際的考慮,主要是從我自己的經驗,並嚴格試圖在基本設計考慮的水平。我會對反饋感興趣。

首先,從你的「帆布」和「宇宙」設計點似乎不同:我可以想像,帆布參數可能需要改變,而物理常數大概不會。

假設Canvas實體可能會改變,對我來說這將是一個單獨的類。我沒有看到你會希望你的Particle從此繼承;在我的理解中,這些在邏輯上是完全獨立的實體。至於在畫布上放置粒子的方便性,我會在不同的層次上處理,而不是繼承。

Particle本身很可能會用類的層次結構實現,但這取決於您的項目以及是否有不同種類(或行爲)的粒子。

至於固定參數,我在C++項目中使用了帶有顯式名稱空間的單獨頭文件。我沒有看到在Fortran中這不是一個可行的設計的原因,因爲要在常量中使用單獨的模塊。從這個意義上說,它們是全球性的,但是可以在使用中加以控制,而這正是它們的本質。這種方法也具有靈活性,以防您的常量集合發展更復雜,而不僅僅是少數數字。此外,如果證明需要,您可以稍後將其升級爲課程。

然後有些問題,這些問題如何與其他類相關,以及如何編寫它們的許多細節。這將在其他地方提出這個問題,並且我不太瞭解Fortran的全部OO功能(除寫作課程外)。

所以,我要說:「帆布」是一類與「宇宙」是一個模塊,無論是從粒子分開。

+0

感謝您的答案。我仍然擔心的是,我如何把「宇宙」和「帆布」聯繫起來?我會把一個簡單的檢查:我有一個真正的問題是畫布有一個標識窗口(這個ID用於低級繪圖子程序)的ID。我在「粒子」中有一個在給定座標中繪製圓的方法,但它需要這樣的標識。我怎樣才能讓粒子意識到它在一個給定的「畫布」中「生活」的事實?在我目前的實現中,這樣的id是類「Particle」的一部分,我認爲這是一個蹩腳的解決方案。 – Onturenio

+0

@Onturenio我不會在設計層面考慮這些因素。爲什麼_Particle_與_Canvas_糾纏?這僅僅是被策劃的,是的?它的行爲不受_Canvas_影響,對嗎?如果需要了解_Canvas_ propeties - 好吧,_Canvas_是一個包含您設計的接口的類(訪問方法),所以每個人都可以獲取他們可能需要的信息。你可以更緊密地整合它們,但是讓另一個繼承鏈中的一部分或者不適合我。 – zdim

+0

@Onturenio我在回顧我的舊帖時遇到了這個有趣的問題。你最終做了什麼?我也建議張貼,作爲未來這個網頁訪問者的答案。 (沒關係,如果這是最好的,那麼它很好。) – zdim

相關問題