■単一責任原則vsカプセル化

初投稿につき至らない点があるかもしれないが容赦してほしい。が、指摘は受け入れる所存。

俺はとあるUIコンポーネントライブラリ開発者だが、先日議論されたあるコンポーネントの設計について悩み続けている。

これを読んでくれた人の設計センスや知識、経験から、第三者の率直な意見を聞きたい。

悩んでいることの概要は、

• 単一責任原則に基づいて責務を減らすべきか、
• カプセル化するために責務を増やすべきか

ざっくり言えばこの2択だ。

どちらも間違った考えだとは思えないので、そもそもどちらかの捉え方がおかしいのだと思う。そういった意見も聞きたいが、まずは読んでみてほしい。

設計対象のコンポーネントは、よくある触って動かせるスライダーである。下記リンク先のようなものだ。

https://material-ui.com/components/slider/

前提として、このコンポーネントの構成要素を下記とする。

• 背景バー：全体を表すバー
• ノブ：選択された位置を表す、ユーザーが動かせる部分
• 進捗バー：バーの左端からノブの位置までを色づける部分

加えて、下記も前提としてほしい。

• 構成要素それぞれもコンポーネントとする
• 進捗バーは横幅を変えて表示するだけで見た目の要件を満たす

Sliderというコンポーネントクラスを作るとして、これらの構成要素をライブラリ-ユーザー間でどう分担するかという点で、AさんとBさんで意見が割れた。

それぞれの意見を要約すると下のようになる。Aさんはカプセル化を狙い、Bさんは単一責任原則を重視している。

• Aさん「Sliderクラスは構成要素3つを隠蔽し、ユーザーはSliderインスタンスだけを作成すれば良い。」
• Bさん「ユーザーは構成要素3つをそれぞれ作成してから、Sliderクラスにセットする。」

Aさんの構成イメージは下記のような感じ

画面
└ Slider         (ユーザーが作成)
   ├ 背景バー
   ├ ノブ
   └ 進捗バー

Aさん案の場合だと、Sliderクラス内部で勝手にそれぞれの要素を作成し、自分の子にするなりして表示する。

Bさんの構成イメージは下記のような感じ

画面
├ 背景バー     (ユーザーが作成)
├ ノブ         (ユーザーが作成)
├ 進捗バー     (ユーザーが作成)
└ Slider       (ユーザーが作成)
   ├ 背景バーへの参照    (ユーザーが指定)
   ├ ノブへの参照        (ユーザーが指定)
   └ 進捗バーへの参照    (ユーザーが指定)

Bさん案では、ユーザーが構成要素それぞれを作成し、Sliderにそれを食わせる。

SliderはAさん案のように各構成要素を構築する必要はなく、ノブの移動や進捗バーのサイズ変更だけすれば良い。

Aさんはユーザーが制御する必要のない背景バー、ノブ、進捗バーの構成を隠蔽(カプセル化)しようと提案したが、

Aさん案に対しBさんは、単一責任原則の観点から「各構成要素の構築や表示」という責任を外すべきだと訴え、Bさん案を提示した。

またBさんは、コンポーネントはユーザーが扱うべきものであり、コンポーネントがコンポーネントを内部で勝手に使用しているのは混乱を招くとの見方もしている。

ただしAさんの考えの通り、実際に各要素の構成をユーザーが制御するユースケースは存在しない。

その場では「単一責任原則」を持ち出したBさん案で決定された。

しかしなんとなくAさん案派だった俺はモヤモヤしたまま家に帰り、本当に単一責任原則に反しているのか、カプセル化よりも大事なのかと悩み続けている。

ここまでが事実となる。

さて本当にBさんが正しかったのか、あるいは単一責任原則の捉え方が間違っているのか、はたまた・・

第三者による意見が聞きたい。周りのコメントに左右されない率直な意見が望ましい。なんとなくな意見も歓迎する。

満たすべき機能は見た目だけではないがそこは置いておいてほしい。

以下は個人的な意見とか思ったことや疑問など。

• Bさんは日々アンチオブジェクト指向をうたっている。カプセル化もとい隠蔽が大嫌いであり参照透過性を重視したのかもしれない。Bさん案は参照透過なのだろうか。
• アンチオブジェクト指向のプロが設計した場合どうなるのだろう。
• Atomicデザイン的にはAさん案な気がする。

Permalink | 記事への反応(3) | 20:49

ツイートシェア