考慮下列設想一個基類是這樣的:受保護的基類中的靜態屬性在派生類之間共享數據的良好做法?
internal class ResolveVariableStrategyBase
{
...
protected static EntityFieldVariable EntityFieldVariable { get; private set; }
protected static EntityPropertyLoader EntityPropertyLoader { get; private set; }
protected static FunctionInvoker FunctionInvoker { get; private set; }
protected static string Variable { get; private set; }
protected static object EntityValue { get; private set; }
protected static object VariableValue { get; set; }
...
protected ResolveVariableStrategyBase() { }
internal ResolveVariableStrategyBase(
EntityFieldVariable entityFieldVariable,
EntityPropertyLoader propertyLoader,
FunctionInvoker functionInvoker,
string variable,
object entityValue,
object variableValue)
{ ... }
internal virtual object Execute() { ... }
}
和幾個派生類是這樣的:
internal sealed class RelationStrategy : ResolveVariableStrategyBase
{
internal override object Execute()
{
var result = resolveRelation();
base.VariableValue = result;
return resolveRelation();
}
...
}
是真的是一個好主意,
具有靜態在基類中的特性,以便爲所有的派生類設置相同的(內部)構造函數基類,像這樣電子領域:
internal RelationStrategy( EntityFieldVariable entityFieldVariable, EntityPropertyLoader propertyLoader, FunctionInvoker functionInvoker, string variable,
object entityValue, object variableValue) : base (entityFieldVariable,propertyLoader,functionInvoker,variable,entityValue,variableValue)
或者這只是懶惰優先於精心設計的代碼?
什麼是最佳解決方案?
這是一個快速的解決方法,但代碼的作者可能有其他解釋應該被聽到。 – Shark
我對這段代碼沒有很好的感覺,並且想知道它是否必須改變。我自己寫的是試圖將現有的功能重構爲戰略模式,但我並不完全幸運,因爲我不確定這些靜態屬性是否是好設計。 –
如果有效,請不要修復它。 KISS原理在這裏很有幫助,因爲我在某種程度上相當確定,即使你不想向客戶端發佈蹩腳的代碼,你也不希望通過不必要的代碼重構來引入新的未知錯誤那甚至沒有破裂。 – Shark