替代OOP中的C風格結構

我是一名主要進行程序設計的電子背景的學生。我越瞭解它，我越發現自己有多糟糕。我想在OO設計上變得更好。我一直在閱讀的一件事是使用Getters和Setters。替代OOP中的C風格結構

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1 http://typicalprogrammer.com/?p=23

現在我可以看到這一點，他們正在這裏，但我仍然無法看到走周圍的一些簡單的問題。這使我想起了我的問題（最後）。我正在AS3中設置一個簡單的塔防遊戲作爲學習練習。我希望敵人遵循方向點，所以我要製作一系列方向點，並使之成爲地圖對象的屬性。一個方法是成爲一個具有x和y屬性的對象（更像是一個結構體）。現在我可以看到，這正是這些文章令人沮喪的壞習慣，但我似乎無法想到一個更好的方法來做到這一點。任何一些有更多經驗的人的幫助將非常感謝。

來源

2010-02-28 Dan Walmsley

我不知道AS3的第一件事，而是一個智者曾經告訴我，打破習慣幾乎是不可能的，而是一個應該簡單地試圖獲得一個新的習慣代替它。 – Ken 2010-02-28 05:05:50

是的，這是我的目標，我只是需要一些指向正確的方向來獲得這些良好的習慣。 – 2010-02-28 05:30:18

我建議你編輯你的問題標題更具體。你想知道如何在OOP中使用結構，而不是關於打破習慣的一般建議。 – Stiggler 2010-02-28 19:21:41

首先推廣;雖然你現在想要敵人跟隨航點，但在我看來，你所擁有的是地圖的特定實例，以確定某物在哪裏移動。

讓我們稱敵人爲「GameEntity」（可能爲MoveableGameEntity）的一個實例。

你應該做的是告訴地圖管理相關的GameEntities，然後地圖可以保留這些對象的列表並根據需要移動它們。

代碼片段。

interface MoveableGameEntity 
{ 
    void positionNotify(Position new_postition); 
}; 

public class Barbarian implements MoveableGameEntity 
{ 
    void positionNotify(Position new_postition) 
    { 
     // do something 
    } 
}; 

// during initialisation. 
map.Add(new Enemy("Barbarian 1")); 
map.Add(new Enemy("Barbarian 2")); 

//during map processing 
Position new_position = new Position(); 
for (MoveableGameEntityList moveable : moveable_game_entity_items) 
{ 
    new_position = get_new_posistion(moveable); 
    item.moveTo(new_position); 
    moveable.positionNotify(new_position); 
}

的地圖將需要有一個方法get_new_position（MoveableGameEntity GE），這將決定新posisiton和敵人也只能通過positionNotify方法被告知他們的新posistion。

MoveableGameEntityList是一個將遊戲實體和它的位置綁定在一起的對象。這種方式遊戲實體不包含任何位置信息，這是由另一個對象管理。

來源

2010-02-28 12:44:49

我不希望看到這是壞習慣與好習慣，而是範式的轉變。不幸的是，這並不像翻轉開關那麼簡單。隨着你以不同的方式看待事物的經驗越來越豐富，這種情況就會逐漸發生。

我可以給你的最好的建議就是開始編碼。很多。

來源

2010-02-28 05:48:37 polygenelubricants

好吧，重要的假設如下：我認爲你對效率的考慮太多了。 OO編碼不是關於效率。這是關於優雅的設計。這是爲了儘量減少外部因素造成的副作用並保護內部狀態。這就是編譯器「優化」的原因。您應該主要考慮可維護性和編碼難度。您寫入的行數可能會大於非OO代碼。那不是重點。

試着將你的「對象」看作與對方交流的有形物品。該通信是一種協議（包括方法簽名）。你相互「說話」的語言。簡單明瞭。永遠不要假定任何物體都有能力操縱另一個物體超出其傳達建議或請求（封裝）的能力。

不要僅僅將getter和setter添加到沒有目的的所有東西。你會錯過整個觀點，而且可能會以另一種風格進行編碼。保護內部狀態。 Getters &安裝人員一切只是意味着，你將會普遍效率低下。安裝者&獲得者是守門員。而已。消除他們，如果他們沒有意義。在他們所在的地方使用它們永遠不要讓別的東西與你的內部狀態一起擰。它會造成混亂。

寫作遊戲時，這些做法會下降，但不會被放棄。優化您的關鍵環路&阻塞點。保留您的原始代碼&作爲優化代碼的鏡像模型。拿走你需要的快捷鍵，僅此而已。即使面對明顯效率低下，但考慮周全的設計，優化也總是會持續下去。

許多我曾經使用過的前Java代碼編寫器不必要地將屬性設置爲&屬性（每個屬性）。這只是他們習慣的。在10個案例中有9個沒有好處，但他們堅持這種模式。影響總是微不足道（每分鐘5萬用戶...當然，不使用Java ......但仍然）。在高層次設計中，getter & setter的總體影響是最小的。較低的水平，如在視頻編解碼器或OpenGL，它是巨大的。

您可以選擇無需思考就採用它們，或者在考慮適用性的情況下實施它們。你將找到許多教授告訴你，你是「錯」，因爲你省略了他們。記住你的課程期望。 :)

來源

2010-02-28 06:52:18 pestilence669

感謝您的建議，它確實清楚了一些事情。但是在我的例子中，是否有更好的方法來創建點對象的方式，使其不僅僅是兩個基元的持有者還是這是一個可接受的設計？ – 2010-02-28 08:35:51

這是可以接受的（在很多圈子裏都適用）。每當我使用簡單的座標時，我有時只使用內置數組（使用元組的壞習慣）。如果有意義的話，你可以將智力放入你的點對象中，但我不會建議你強制它。 – pestilence669 2010-02-28 21:40:33

有點無關，但如果你想進入OO設計，我有2個好書給你，容易理解&把握。

Head First: OOAD

Head First: Design Patterns

來源

2010-02-28 12:49:31 Jens