シンプルだから使い勝手が良いとは限らない

渡辺さんの下記記事を拝読しました。

意外にも、あえて一部を複雑にすることで、システム全体の保守性が向上することがあり得るということだ。開発者はシステム全体の保守性を考えつつ、各モデル要素（データモデル、業務モデル、機能モデル）の複雑さを塩梅しなければいけない。

「シンプル・イズ・ベスト」はややこしい: 設計者の発言

あえて一部を複雑にする有り難みを僕も最近気づくようになった。

どんなシステムを作るにせよ、机上の想定通りに業務ができる事はない。かといって、先回りして完成形を提示しても無駄骨になりやすい。なので、最低限業務上必要な情報をCRUD出来るものを作るのが第一段階になる。僕はいつもこのやり方を取る。

その次に何があるかというと、CRUDの主体者(ドメイン？エンティティ？わかんね) によって、個別に行いたいことが出てくる。要は「ふつーはこれでいいんだけど、この場合だけこうやって欲しい」という例外処理の類が増えてくる。プログラムで頑張るか、テーブル追加するか、カラム追加するか、スルーするか・・・

このような例外処理に対応すると、設計にもよるけれどコードが徐々に個別最適化されてしまう。でも、個別の事情を吸収するから「痒いところに手が届く」という話になる。

個別の事情を吸収するには、「変更ではなく追加」で対応するのが望ましい。既存の構造から何かを取り除くのは多くの場合困難だ。動いているものから何かを削除するのは変更・追加より気をつかう。

個別の事情が発生する所にはc#のデリゲートメソッドをよく使う。WPでいう所のフィルターフックだね。例えばある時だけは在庫を引き当てないのなら、引き当てるメソッドをデリゲートにしてある時が発生するモデルに何もしないメソッドを使ってもらうという。

フィルターフックではなくてオーバーロードで対応する人もいるけど、PHPの場合は基本的にオーバーロードがないし、キリがないからやめた方がいい。某動画配信サイトでは引数が20個近くあるPHPのソースがあったらしいですよ。function haishin($a,$v,$b,$d,$e = null,$fe = null,$eee = array())みたいなコードを見たら死にたくなるやろ。

また、フィルターフックもフックのフックで何やねんみたいなことがあるので、気をつけてほしい。フックしたメソッドの中で別のフックを叩いたら意味が無い。全然吸収できていないだろっていう。

状態管理をするためにテーブルのカラムを追加するのは仕方のない時もある。ただ、追加する区分値は0か1だけのスイッチのような使い方でないとあかん。ON/OFFの判断だけなら、そのドメインで吸収できる。2の場合はあれで、1でそれがBならこれ、みたいな判断基準がカラムのデータに含まれると死ねる。

状態が異なることによって処理が違うなら、Stateパターンを使おう。状態自体をオブジェクトにしような。わかり易い例として、エアコンの暖房、冷房、ドライ、送風の例をよく使う。分かるっしょ、言いたいことがｗ

シンプルに対応するために構造は複雑にしておくのだけども、複雑と混沌は違う。Do More With Less. これな。