部品と機能のすり合わせ

設計するときに普段あまり意識することはないけど、実際にはトップダウン的な考え方とボトムアップ的な考え方の両方を使っている。何がしたいという機能的な面からも検討するし、どんな部品があるかボトムアップ的にも検討する。特に下層の部分はいかに部品として独立しているかを考える。用語的に正しいかどうか自信がないけど、機能を考える時はトップダウン的で、部品を考える時はボトムアップ的かなあという気がする。

トップダウン設計とボトムアップ設計 - Wikipedia
用語集た行　 トップダウンとボトムアップの混合

そして、修正を重ねていくうちに設計が崩れていくのは、部品と機能のすり合わせでどちらにしわ寄せを入れるかがはっきりしてない事が原因になってることが多いのかなあという気がしてきた。

例えば、色をRGBの数値で管理する下層の部品があり、その数値の設定と表示を行う上層のユーザインターフェースがあったとする(実際にはこういうソフトを作ったことないのでいい例になるか分からない)。色管理部品のインターフェースは数値を入力するようになっている。
一度それで作りこんで完成した後、今度は色の名前でも表示できるように変更したくなったとする。その時の変更方法としては、名前は色管理の本質ではないとして色と数値の対応テーブルを表示側に作る方法と、名前を含んだ「色」というまとまりで色管理部品を作り直す方法を考えると思う。

たぶんどちらにも一理ある。
名前を部品側に入れてしまうと、じゃあ、多言語対応しようという事になったときに、言語の違いまで色管理の中に入ってしまう。そう考えると部品としては名前は入れない方がいいような気がする。
けど、名前を部品の外に出してしまうと、今度は別のソフトでも色管理部品を再利用しようとなったときに、そっちのソフトにももう一度色と数値の対応テーブルを作らなくてはいけない。

これは色管理部品と表示部の2層だけで考えているからこうなるわけで、たぶん色と数値の対応テーブルは新しい一つの部品として分けたほうがいいのだろう。けど、なかなかそれが難しい。そして蟻の穴からダムが決壊するように、あまり考えずに入れた小さい変更から徐々に整合性が崩れていく。特に時間に追われていたり複数人で分担していたりした場合に。
層で分ける時には、部品と機能の間に接着層みたいなのを最初から想定しておいた方がいいのかも。