No more Death March

あるSEのチラシの裏 C# WPF

インターフェースを考える(14)考えを整理(出来ていない)

C#実践開発手法のシングルメソッドインターフェースで色々書いてきたけども、
途中途中浮かんだ考えをだぁーっと箇条書きにしてみる。

  • 処理は小さく、抽象化されており、組み換え可能であることが望ましい。
  • シンプルな処理であればあるほど、コードを修正する可能性は低くなる。
  • 小さいクラスは設計・開発・テストのサイクルがシンプルで作業を理解しやすい。
  • コードに修正の余地が無ければ、たった一つでも仕事をしていれば資産と言える。
  • コードを修正して機能を増やすことよりクラスを増やして機能を増やしていく。
  • クラス数が増えるのは問題ではない、増えたクラスがライブラリや名前空間で整理されていないのが問題。
  • 複数の処理を持っているクラスはその分コードを修正する可能性が高くなる。
  • 修正の可能性が低いコードほど堅牢で修正の可能性が高いコードほど脆弱なコードになる。
  • 10の機能を持った1つのクラスを作るなら、1つの機能を持ったクラスを10個つくれば良い。
  • 具体的な処理は不変であり、コラボレーション部分のみが修正の対象となれば良い。
  • 分岐を目的としたパラメータを持つメソッドはパターン毎にメソッドを分割出来るはず。
  • 条件分岐はパターン毎の処理を実行するという責務と、パターン毎に振り分けを行うという責務に分離する。
  • シングルメソッドインターフェースは構造化プログラミングとOOPのポリモーフィズムのおいしいとこ取りをしている。
  • 複数の処理を持ちたければ振る舞いクラスに委譲すれば良い。
  • インターフェースのみに依存する場合、またはクラスに依存していても行き着く依存先がインターフェースのみであれば静的クラスの利用も悪くない。
  • 何かを呼び出して戻り値を受け取る処理はまた別ななにかを呼び出して依存する。戻り値が必要無いように組み替えれば余計な依存関係は生まれない。
  • プログラムの仕様変更が入った時のことを想像する。それがそのまま責務を分割する糸口になる場合がある。
  • 思い切ってクラスの継承は無いものと考えた方が設計が捗る。
  • ドメインモデル・ドメインオブジェクトは人の理解を促すために組み立てるもの。と考える。具体的な処理は小さくて組み換えやすいクラスに委譲する。