第14回　オブジェクトの切り方２ - OOP講座

14. オブジェクトの切り方２

さて今回は、最後にして、もっとも基本的な所への言及を試みたいと思います。

「基礎にして初歩に非ず」。基本的なところであると同時に「最も言及が困難である」と言っても過言ではないところ、ではあるのですが、ここを逃げてしまうと色々と始まりませんので、頑張っていきましょう。

まずそもそもとして、「なぜオブジェクト指向でものを組むのか？ 組みたいのか？」を、もう一度改めて問うてみましょう。

このあたりは本当に各論あると思うのですが、筆者が普段業務でオブジェクト指向を使う理由は、ほぼ一つに絞られます。
それは「変更/修正が容易である」ということです。ちなみに次点として「複雑なものが(比較的)簡単に組める」という側面もあります。これは「GUIを組む」あたりを言及すると色々展開できるのですが、そのあたりは、またいつか機会があればなにがしか皆様のお目に触れるようなものが書ければ、と思っております。

では、オブジェクト指向の利点が「変更の容易性」にあると定義したとして、どうやったら「変更がより楽になる」のでしょうか？
こういうことを考える場合、いつもの通りまずは真逆に「変更が厄介である」ケースを想定してみましょう。
ゆっくりと心を過去に傾けてみますと…。

まずなによりも先に思い浮かぶのは「そもそもどこを変更したらいいかわからないほど処理が散り散りになっている」ケースですね。
糅てて加えて「１つの変更のために複数箇所を変更する必要がある」などという状況も厄介ですし、ましてや「全く異なる処理が中途半端に混ざっている」と、真っ当なはずの修正が「よくわからないところに影響したりする」のもまた頭の痛いところです。

そんな事を念頭に置いて考えますと、とりあえず「異なる処理は別々の場所にあり」「１つの処理は一箇所にちゃんとまとまり」「処理の流れがある程度わかりやすいようになっていたり、そのようなネーミングになっていたりする」事が、何よりも肝要であるように感じられます。
…とまぁ、そのあたりが、前回の話のべからず集の元ネタになっていたりするわけです。

では「どの処理や役割が一緒で」「どの処理や役割が異なっているのか」を、どうやって切り分けていくのでしょうか？
ここを失敗すると、前回の話にあるような「DBハンドルの管理とSQL文の発行がごちゃ混ぜになったり(どちらも「RDBに対するアクション」という意味では一緒なので)」「極端に細かすぎる役割分担になったり」してしまうわけですね。
そのあたりを考える上で、参考になりそうな単語をまずはいくつかピックアップしてみましょう。

まず「単一責任の原則」という言葉があります。これはオブジェクト指向を学ぶ上で、割合によく出てくる単語ですね。
意味はごくシンプルかつ文字の持つ印象値の通りで「１つのクラスは１つの役割だけを持つ、という原則」になります。そうすれば「異なる処理は別クラスになって」「同じ処理はちゃんと１つのクラスにまとまる」ので、後はgoodなネーミングさえ付けられればOK、なのですが、この原則はそれこそ「諸悪莫作 衆善奉行」と一緒で「3歳の子供でもわかりそうなくらいにあたりまえな事ではあるけれども、実際にそれを違うことなく実践するのは80歳の翁でさえもなお難しい」原則です。ただ、という事は「如何に近づけるか」というのが、一つ考察として大切なのではないかろうか、と思いますので、是非しっかりと念頭に置くようにしましょう。

では「１つの役割」を切り出す時に、或いは「どこまでをまとめて良くて、どこからを分離すべきなのか」という粒度をコントロールする時に、どんな風にミスをしてしまうものなのでしょうか？

筆者がよく見かけるのが「間違えているのではないか？ と感じられる切り口から役割をみている」ケースです。
そうして、そういう切り方をしている方と話をして比較的多いのが「今現在、自分が見ている"以外の"切り口(視点)を全く持っていない」事です。 実際問題として、正解がどこにあるのか、或いはそも「正解なんてものがあるのか」どうかすら、わからないのが設計だと思います。
であるとするのであれば、常に「よりよい設計はないのか？」という自問自答が必要で、そのために、まずは「様々な切り口/観点から、役割について考察をしてみる」事は、とても大切なのではないかと思います。

続きまして。経営学や経営コンサルティングの領域あたりでよく使われる単語に「MECE」という単語があります。
Mutually Exclusive and Collectively Exhaustiveの略です。
日本語に訳すると「何も不足部分がなく、かつどこも重複していない」とかって感じになるんでしょうか。或いは「ダブらず、漏れず」とか。何も足さない 何も引かない」というのはウィスキーのCMでしたが。

この考え方も一つ「１つだけの役割を持つクラス」という発想と、なにかかみ合うところが多いように思います。
このあたりの「１つだけをちゃんとやる」という発想は、UNIXも全く同じ考え方を持っていますね。
「UNIXという考え方」という書籍は大変に優れた書籍ですので、是非一読される事を強くお勧めいたします。

なんてあたりをまとめて考えますと、クラス切りは

• １つの役割だけをもつクラスを
• それぞれの役割は、どこも重複しておらず、かつ全体としては不足がない状態で
• 各クラスは「自分の役割だけを」きちんとやる

ように作るとうまくいきそうです。

…というところで文章を収めますと、ごく一部の「上級者」の方々にとってはともかく、そうではない「これからオブジェクト指向を学んだり、ようやく習熟しかけていたりする」大半の方々にとっては「クラス切りが完璧じゃないとダメなんだ」という、間違った強迫観念を植え付ける結果にしかならないので。
もう少し、今度は「緩める」方向に、文章をつながせていただきたく思います。

とりあえず理想を「基本現実をドン無視して」書かせていただきますと、きちんとした「親方」レベルの上級者がいて、その下に「熟練職人」がいて、その下に「見習いがいて」という環境がまずあります。その中で「業務の流れに沿って見習いたちの仕事の成果は随時チェックされ、必要な修正や指導を受けて、正しく訓練が施されていく」のが、本来の「正しい現場のありかた」だと思います。

ただ、では「現在ソフトウェアを組むお仕事をしている方々」を対象に「"きちんと尊敬できるレベルの"上の人がいて、きちんとそういった人たちから教育をしてもらっていますか？」という類のアンケートをとってみたと仮定しますと、その結果の数値については、若干の不安を感じてしまうように思われるのは気のせいでしょうか？

実際問題一番よいのは確かに「現場でその場で実務に沿ってちゃんと習う」なのですが、これが「もし仮に万が一」出来ない環境にいる場合。やむを得ず「自己学習」を前提にせざるを得ない部分があるのではないでしょうか？
というのが、これから先の文章の本音になります。