SOLID原則
オブジェクト指向プログラミングにおいて重要な5つの原則をまとめて言ってみたもの。
S = 単一責任の原則
O = 開放閉鎖の原則
L = リスコフの置換原則
I = インターフェース分離の原則
D = 依存性逆転の原則
そんなの知ってるよ、という人だったり、ゲームでそんなうまくいかないよ、という人だったり、意見あるとは思いますが、最近特にこの大切さを感じています。
SOLID原則の序列
5つにまとめられて語られるSOLID原則ですが、単一責任原則がブッチ切りで重要度は高いと思います。
これは個人の印象ですが、SOLID原則の中でも重要度の序列（守らなくてもいいケースの少なさ、みたいな）はあって、
S > O >= L > I >= D
の順で重要かなと思っています。
Sは最重要。クラスの名前は、可能な限り厳密に。名前の厳密さはそのままそのクラスの凝集度になります。ただ、「単一」の解釈を共有しづらいのと、依存の方向性が一方向に保たれつつある程度クラスの責任が明確であれば問題は無かったりするので、これに関する議論は非常に難しい。個人的には、妥協したとしても、ドメインから最も遠いレイヤー以外は徹底して守るべきだと思っています。
Oも守るべきですが、守らなかったときの被害はSほどではないでしょう。
Lも基本守るべきですが、MonoBehaviourを継承したクラスを作っている身としては、使われ方次第かなと言いたくなります。ちょっと屁理屈っぽいですが。 ところでこいつだけリスコフとか人名が入っているのが気持ち悪いです。
Iはプロジェクトの状況に応じて適切な粒度を見極めたいところです。
Dは選択肢として持っておくべきだとは思いますけど、実際に全部抽象に依存されたら不便極まりないので、「原則」とまで言うのは過言じゃないか？と思ってしまいます。
愚痴
自分の経験ですが、これらをちゃんと理解して実践できている人は多くはないです。これが実践できていると、保守コストがグッと下がり、運用に5人エンジニアが必要だったところが、4人、3人で済む、みたいなケースも普通にあり得ると思うので、その分別の機能追加に回せたり、全体に開発速度バフをかけられたりと、非常に強いスキルだと思います。
また、自分は、これらを守ってコーディングすれば、守らない場合よりも、短期的にも長期的にも開発速度は上がると思っているので、時間がないからできない、みたいなことを言う人は要注意だな〜とも思っています。こういう開発手法ってどうしても例がWEBサービスとか、アーキテクチャのレイヤーがわかりやすいものになっちゃうんですが、3Dのアクションゲーム、そのアクション部分であっても同様に、これらを守って開発した方が良いと思いますね。
