2011-05-25 33 views
1

延伸的大型類我有一個處理武器在我的遊戲大抽象類。通過基本功能列表戰鬥循環:C#在贊成可讀性

OnBeforeSwing 
OnSwing 
OnHit || OnMiss 

我心裏有被移動的所有戰鬥傷害相關的計算到處理只是另一個文件夾。與傷害相關的計算。

我想知道是否通過使OnHit方法成爲擴展方法來做到這一點是正確的,或者什麼是最好的方法來實現這一點。

另外。週期性地有被修改的代碼OnHit的部分,命中傷害公式大是因爲它考慮到了大量的象電阻,變換咒語,項目獎金,特殊性能和其它的,類似的遊戲元素的條件。

這結束了一個500行OnHit函數,哪種令我感到恐慌。即使有地區指令,也很難在迷宮中迷失方向,甚至分散注意力。

如果我用這個函數來擴展武器而不是僅僅具有OnHit函數,我可以嘗試將攻擊的不同部分分解爲其他函數。

然後,也許我可以通過從武器類中的OnHit調用諸如CombatSystem.HandleWeaponHit之類的東西,而不使用擴展方法。這可能更合適。

基本上我的問題是,如果離開它像真的是最好的解決方案,或者如果我可以(應該?)移動這部分代碼到一個擴展方法或處理該損傷模型單獨的輔助類,以及是否我應該嘗試將這個功能分成更小的「任務」功能以提高可讀性。

回答

2

我打算出去走走,並建議你的引擎可能不夠抽象。請注意,除了您在OP中告訴我的信息之外,我只是在不瞭解您系統的其他任何信息的情況下提出此建議。

在類似的系統,我已經設計的,有作用和效果。這些是基礎類。每個特定的動作(機槍攻擊,特定咒語等)都是從Action派生出來的類。行動有一個或多個可應用於目標的特定效果列表。這是使用依賴注入實現的。

戰鬥引擎沒有做所有的數學本身。從本質上講,它要求的目標來計算它的防禦等級,然後通過所有活動的操作循環,並要求他們以確定是否適用於目標任何影響的。如果他們申請,它會要求該行動將其相關效應應用於目標。

因此,戰鬥引擎很小,而且每個效果都非常小,且易於維護。

如果你的系統是一個巨大的單片結構,你可能會考慮類似的體系結構。

1

OnHit應的事件處理程序,對於初學者。任何被擊中的對象應該引發一個Hit事件,然後你可以有一個或多個事件處理程序與該事件相關聯。

如果您不能將當前的OnHit函數分解爲多個事件處理函數,可以將其分解爲單個事件處理函數,但將其重構爲多個較小的方法,每個方法執行特定的測試或特定的計算。它會使你的代碼更具可讀性和可維護性。

+0

取決於命中的來源(咒語,武器),它的處理方式截然不同,我如何使用事件處理程序來反映我的代碼? – bevacqua 2011-05-25 18:08:12

0

恕我直言Mike Hofer給出了線索​​。

真實的一點不是它是否是擴展方法的問題。真正的一點是,對於如此複雜的一系列計算來說,單一的(擴展或常規)方法是不可想象的。

在考慮最佳實施之前,您顯然需要重新思考整個事情,以確定對物體的最佳責任分配。每一項基本計算必須由它適用的對象來完成。請務必記住GRASP design patterns,特別是信息專家,低耦合高凝聚力

一般而言,您項目中的每種方法應該總是隻有幾行代碼,不再多。對於每一項計算,請考慮哪些是適用此計算的所有類。然後讓這個計算成爲它們的通用基類的一個方法。

如果沒有公共基類,則創建一個新接口,並使所有這些類都實現此接口。這個接口可能有或沒有方法:它可以用作一個簡單的標記來標識所提到的類,並使它們具有共同點。

然後你就可以建立一個元素擴展方法就像這個假例如:

public interface IExploding { int ExplosionRadius { get; } } 

public class Grenade : IExploding { public int ExplosionRadius { get { return 30; } } ... } 

public class StinkBomb : IExploding { public int ExplosionRadius { get { return 10; } } ... } 

public static class Extensions 
{ 
    public static int Damages(this IExploding explosingObject) 
    { 
     return explosingObject.ExplosionRadius*100; 
    } 
} 

該樣品是完全俗氣而只是旨在使導線重新設計你的系統更抽象和maintenable方式。

希望這會幫助你!