抽象的な Enum は作るな、具体的な Enum を作れ

ダイキチさんの 『Enumをむやみに増やさない』 という記事を拝読しました。

単純な問題提起だけではなく、ちゃんと対案も提起されている素晴らしい記事ですが、私には別の回答があります。

ダイキチさんの記事をみて私が伝えたい事は 『抽象的な Enum は作るな、具体的な Enum を作れ』 です。

例として出されていたケース

例えば、開発者Aさんが「開発期間」を表すEnumを作ったとします。

public enum Period
{
    開発前,
    開発中,
    開発終了
}

これが、ただの例であり、簡略化されたものではないという前提ですが、この時点で Period という enum 名があまりに抽象的過ぎて何にでも使えるように思えてしまうのが問題です。

その後Bさんが別の機能で「レビュー期間も判別したい」と考え、このEnumに要素を追加したとします。

ここで問題が顕在化しています。A さんの考える「開発期間」と B さんの考える「開発期間」の定義が一致していないのに、同じ Period という enum がそれを引き受けているのですから、そこに矛盾が発生するのは当然の事です。

結論、『抽象的な Enum は作るな、具体的な Enum を作れ』

「何にでも使える抽象的な定義」を行うには長い経験に基づく非常に高度な設計技術と慎重な判断が必要で、それは現実の開発現場では求めることが難しいものなので、往々にして簡単に破綻します。

一方で、「極めて具体的な定義」の方には未来予知能力は要りません。
現在見えている問題だけをしっかり分析すれば妥当な定義が可能なので、これは若手のエンジニアであっても真剣に取り組む限り実際に可能です。

実際の開発現場では「極めて具体的な定義」を行うように心がけるべきで、
この「極めて具体的な定義」は「再利用」の名のもとに別の場面で流用するべきではないのです。