こちらの続き。このテキストに沿って勉強してきた内容のまとめ記事の、最後の記事になります。

最早表題の「Javaで～」関係ない分野に入ってきましたが、シリーズということで一応、そのまま。

オブジェクト指向的に開発するには

よーしオブジェクト指向で開発すっぞ！　と思っても、今までのウォータフォール式の開発手法では、せっかくのオブジェクト指向の良さが引き出せないままに、なんとなくオブジェクト指向っぽいけど……というアウトプットになってしまいがち。

ちゃんとオブジェクト指向「らしい」プログラムにするためには、オブジェクト指向らしく開発できる開発手順を踏まなければなりません。

昔ながらの開発手順では、

・まずどんな機能が必要なのか要件定義をする
・定義した要件を元に、どうやって実装するか設計を行う
・設計したとおりに基本機能を作る
・細かい部分を作る
・細かい部分をテストする（単体テスト）
・全体を繋げてテストする（結合テスト）
・実際に使う人にテストして貰う

という流れになります。

でも、この通りの手順でオブジェクト指向プログラムを作ろうとしても、良さを生かし切れません。最初にどんなオブジェクトが必要か全て定義してから作り始めるようになってしまいます。

これまで勉強してきた通り、オブジェクト指向プログラミングでは、まず狭い分野の関心ごとに注目してクラスを作り、そのクラスが動くようになったら関連する次のクラスを……と広げていく作り方が向いています。

また、要件を分析して設計するところは、ドメインモデルを設計するチームが担当するのがオブジェクト指向プログラミングの基本です。

そこで、ドメインモデル設計チームは、要件を分析して設計したら、大量のドキュメントを作る代わりに、直接ソースコードで表現してしまいます。オブジェクト指向の基本に忠実に設計していけば、ソースコードがオブジェクトの説明文になり、業務の説明文にもなっているはずです。要件を知っている人がコードを書くので、要件の抜け漏れも少なく出来ます。

ドキュメントを沢山つくる代わりに、業務の担当者と対話して、ラフスケッチなどを手がかりに業務知識を増やし、スケッチや対話内容はそのままの形で保存しておくと良いでしょう。消えちゃうと忘れてしまうので、ちゃんと残しておくのが大事です。

一方で、「全部ソースコードに書いてある☆」だけでは、プログラマ以外のスタッフには不親切が過ぎます。ですので、利用者向けのドキュメントをきっちり整理しておくことも大切です。また、そのほかにもデータベースのテーブル名やカラム名などもわかりやすくしておきましょう。

また、オブジェクト指向的に開発するには、「要件を理解して、設計して、コードを書く」までを一人、もしくは一つのチームが担当することになります。なので、「コードは書けるけど、業務の詳細に興味はないな～」とか「要件定義には慣れてるけどコードは書けませーん」という人が担当してしまうと上手く行きません。コードが書ける人の中で、業務内容を勉強することに意欲のある人を上手にアサインする必要があります。

ちなみに私ねえ、そういう要件を整理するような作業、大好き。

オブジェクト指向を勉強するには

オブジェクト指向、わかりにくい問題。

こうやってつらつら記事をまとめてきてはいますが、実際のところ、オブジェクト指向の良さって「わーーーーーーーーーーーーーーこのコード修正するの無理～～～！！！誰かもっとちゃんと整理してよぉおお！！！」を体験してみないと分かりづらいところがあります。

実際「クラスは設計図」とか「クルマの設計図と実際の車が」言われても絶対ピンとこないですもんね。みんなそう言う。

そこで、オブジェクト指向らしさを身体に叩き込むためのトレーニングが紹介されていたので紹介します。今度やってみよう。

・ルール1：1つのメソッドにつきインデントは1段階までにすること
・ルール2：else句を使用しないこと
・ルール3：全てのプリミティブ型と文字列型をラップすること
・ルール4：1行につきドットは1つまでにすること
・ルール5：名前を省略しないこと
・ルール6：全てのエンティティを小さくすること
・ルール7：1つのクラスにつきインスタンス変数は2つまでにすること
・ルール8：ファーストクラスコレクションを使用すること
・ルール9：getter、setter、プロパティを仕様しないこと
（『現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法』増田亨著 2017 P301より）

ルール7の辺りとかちょっと厳しいかなーとか、必要に応じて2個に制限する必要はないんじゃないかなーとかも思いますが、まあ、際限なく増やさないようにするトレーニングということで。

また、長くだらだら書いてしまったコードのリファクタリングを通して学ぶのも有効です。

重複を整理してメソッドに切り出し、おなじ関心ごとに関するメソッドを1つのクラスにまとめていくことで、「あっ、便利」という気づきを通して「あっ、クラスってこういうことか」という理解が深まることと思います。

私もそうやって、ぐっちゃぐちゃのコードを前にして「なるほどこれとこれとこれを、はいはい、こうして、こうしてこうして使うと、あーーーーなるほど便利ーーー！」と悟ることでなんとなくオブジェクト指向やクラスの仕組みの輪郭が見えてきたところです。

と言うわけで、テキスト読了です。お疲れ様でした。
大変勉強させて頂きました。ココにまとめられたのは本当にほんの一部なので、興味を持たれた方、正しい知識をお求めの方向けに、改めて購入リンクを貼っておきます。

まだまだ勉強することが沢山あるので、引き続きへっぽこ学習日記は続いていきます。