意図によるプログラミング2 ~変更に強いプログラムをつくるためには、結果(状態)を公開しプロセスを隠せ~

最近自分のなかでひらめきがあったのでメモ書きがてらに。

ほしい結果を上位に、プロセスを下位に書く

以前意図によるプログラミングに関してこのような記事を書いた。
https://zenn.dev/dove/articles/2f0ec6786dba10

現在自分のなかで思考がアップデートされた。
現在の結論は次

• トップレベルでほしい結果(状態)にする関数を書きpublicにする
• その結果を得るためのプロセス関数を書きprivateにする
• プロセス関数もまた、できる限りほしい結果(状態)を上位に置く

ハンバーグの場合

// 一番トップレベルの状態関数
public function makeハンバーグ(肉、たまねぎ){
  たね = makeItたね状態(肉、たまねぎ)
  // 以下続いていく
}

// たねを得るためのプロセス状態関数
private function makeItたね状態(肉、たまねぎ){
  サイコロ状態のたまねぎ = makeItサイコロ状態(たまねぎ)
  たね状態 = こねる(肉、サイコロ状態のたまねぎ)
}

// サイコロ状態のたまねぎを得るためのプロセス状態関数
private function makeItサイコロ状態(たまねぎ){
  return サイコロ状態のたまねぎ = みじん切り(たまねぎ)
}

// プロセス関数
private function こねる(肉、サイコロ状態のたまねぎ){
  // 何かしらの処理
  return たね状態
}

// プロセス関数
private function みじん切り(たまねぎ){
  // 何かしらの処理
  return サイコロ状態のたまねぎ
}

なぜこう書くのか

たまねぎのサイコロ状態のことをみじん切り状態というが、このみじん切りは様々な方法が存在する。
つまり一般的にプロセスは複数存在する。しかしほしい結果は１つであることが多い。つまり状態名をなるべく上位に持ってくる設計にしたほうが、変更箇所が内側に留めやすくなる。

もちろん、プロセス関数自体を引数にとってポリモーフィズム化するのもあり。
この書き方の副次効果として、プロセスが分離されやすいためポリモーフィズム化しやすいのもある。

また、下位のプロセス関数の汎用性を高めることを意識すれば、似たような処理のときに再利用しやすくなる。おそらくほぼ最下位のプロセス関数は、lodashのようなutility関数の薄いラッパ関数のようになるはず。