無效的默認值基本上是您設計中的變體。該對象在創建時無效。你應該避免,當它是合理的。絕不應該「不惜一切代價」避免它。
有些問題需要您在變型狀態下啓動。在這種情況下,你有在思想上推理該無效值。如果你避免命名它,你就會積極地使你的代碼不那麼富有表現力。考慮一下你和那些稍後必須維護代碼的人之間的溝通。
順風對付它令人討厭。你從一個變體狀態開始,但是到了相關的時候,你希望它不再是變體。我更喜歡的策略是允許用戶忽略變體狀態,並在錯誤發生時拋出。
namespace FooType {
enum EnumValue {
INVALID = 0
,valid
};
}
struct Foo {
Foo() : val(FooType::INVALID) {}
FooType::EnumValue get() const {
if (val == FooType::INVALID)
throw std::logic_error("variant Foo state");
return val;
}
FooType::EnumValue val;
};
這可以讓您的用戶免於理解您的差異,這是值得爭取的。
如果你無法擺脫這種情況,我通常寧願降級到安全和不安全的界面。
struct Foo {
Foo() : val(FooType::INVALID) {}
bool get(FooType::EnumValue& val_) const {
if (val == FooType::INVALID)
return false;
val_ = val;
return true;
}
FooType::EnumValue get() const {
FooType::EnumValue val_;
if (!get(val_))
throw std::logic_error("variant Foo state");
return val_;
}
FooType::EnumValue get_or_default(FooType::EnumValue def) const {
FooType::EnumValue val_;
if (!get(val_))
return def;
return val_;
}
FooType::EnumValue val;
};
這些類型的接口對於像數據庫這樣的可能會出現空值的東西是很好的。
那麼你可以通過添加MONITORING_STATE值讓監控類'擴展'enum嗎? – dchhetri
我可能不完全理解這個建議。在這個特殊的例子中,MONITORING_STATE從作業的角度來看仍然沒有什麼意義,並且按照[鏈接](http://stackoverflow.com/questions/1804840/extending-enums-in-c)我不能擴展枚舉監控類(理想情況下使用eJobStates作爲私有變量)。 – ellimilial
是的,我意識到你不能自然地擴展枚舉。 monitoring_state只是一個名字,但你絕對可以使用job_state_unknown。我的建議是在監控班增加額外的枚舉。您可以通過獲取eJobStates的最後一個枚舉值並將其加1並將其作爲監視類的開始枚舉狀態值來完成此操作。畢竟,通過枚舉,你只需比較代表狀態的整數。如果你想要更具體的東西,那麼就像鏈接中建議的那樣,你可以創建一個Enum類,或者爲每個狀態創建一個狀態對象。 – dchhetri