なかなか挑戦的なタイトルの本です。
なぜ僕はJavaでオブジェクト指向開発が出来ないんでしょうか。
その謎を解き明かしていきたいと思います。
Javaでと書くとJava以外だと出来るみたいに見えますが出来ませぬ…
全体の感想
モデリングの考え方が特に参考になった。
・仕様を見て何をクラス化するのか
・そのクラスから生み出されるインスタンスにどういう属性を持たせるか
・どういう操作を持たせるか
は時間をかけてしっかり吟味する。
吟味するためにも仕様はしっかりと書き出す。
モデリングにただ一つの正解はない。
自分ではわかりやすいつもりでも他の人から見たらわかりにくいかもしれないことは頭に入れておく。
デザインパターンを使えるといいのはこういうところだと思う。
コラムも凄く良かった。
ただオブジェクト指向プログラミングに全く触れてない人だと難しいかもしれない。
オブジェクト指向プログラミングの入門書を読んでみて、その入門書に書いてあることはなんとなく理解できるけど実際の現場でどう使うのかがわからないとか、使えているかどうか自信がない人向けだと思う。
今後の自分の課題
- クラス設計を簡易にするために難しい例でも仕様をしっかりと書き出せるようになること(ユースケースをマスターする)
- UML図を使いこなせるようになること
- メモリ管理を意識したプログラムを書けるようになること
以下簡単なまとめ
Lesson 1 オブジェクト指向をなぜ難しいと感じるのか
オブジェクト指向は、ソフトウェアを効率的に開発するために生まれた技術
効率的というのは拡張とか再利用しやすいとかってことだと思う。
プログラミングの手順は、3つのステップに分かれている
- コンピュータに行わせたいことを理解する
- 理解したことを説明できるレベルまで整理する
- コンピュータにわかる言葉に翻訳する
プログラミングができない理由は１と２が出来ていないことが多い。
自分が先生とコンピュータが生徒という例えはしっくりきた。
人に何かを教えることができている ＝ 自分が理解できている
１、２が出来ていないというのは自身がコンピュータに教える内容を理解できていないということだと思う。
Lesson 2 オブジェクト指向は本当に必要なのか
プログラミングにおいて最も難しいのは、仕様のわかっているソフトウェアを最初から作ることではありません。一度作ったソフトウェアに対して変更や機能追加をしていくことなのです。
全くもってその通りだと思うし、以前自分が書いたコードを最近後輩に触ってもらうことがあって修正しにくいコード修正させているなあと思った。
ほんとごめんなさい笑
極論を言うと変更、機能追加がなければプログラムはどんなに見にくくても要求通り動いてさえいればいいと思う。
変更、機能追加があることの方が多いので変更や機能追加がしやすくなるように初期の段階から考えていかなければならない。
ただし、
- 既にそうなっていないもの
- 初期の段階では想定できなかったもの
- 想定して開発したつもりが後々手を付けてみると変更が難しかったもの
- 時間の制約によりそこまで手が回らなかったもの
等に関しては後々適切にリファクタリングを行いたい。
一度作成されたプログラムの変更は根本的に難しい
これもっと世に広まってほしい…簡単と思われると辛い…笑
出来るだけ初期の段階で良いものを作りたい
Lesson 3 オブジェクト指向でのソフトウェア開発
- オブジェクト指向とは人間の言葉をできるだけそのままコンピュータへ伝えるための方法として考えられたもの
- オブジェクト指向で度々使われる操作とはメッセージをきっかけとしたオブジェクトの振る舞いのこと
余談だがコード例の下の辺りはenumを使って管理した方がいいとeffective javaに書かれていた気がする。
public static final int STONE = 0; // グー
public static final int SCISSORS = 1; // チョキ
public static final int PAPER = 2; // パーLesson 6 より複雑なソフトウェアの作成
オブジェクト指向で重要なのは明確に役割を分担すること
現実世界にできるだけ合わせるのはそうしたほうがわかりやすいためでありマストではない。
あくまで役割を明確に分担が最優先
モデリング手順
- 仕様を決める
- クラスを抽出する
- オブジェクト間のメッセージを考える
- 各クラスの操作を洗い出す
- 各クラスの属性を洗い出す
■仕様を決める
仕様を決定する段階ではユースケースという手法が一般的。
ユースケースとは
ユーザがソフトウェアをどのように利用するかというシナリオを文章として記述する。
ユースケースを書くことによって、ソフトウェアを使う側の視点に立って、それが「どうあるべき」を明確に整理することができる。
■クラスを抽出する
絶対的な正解があるわけではない。
どれをクラス化してどれをしないかをしっかり考える。
クラスの抽出に関しては、後に行う洗い出しの最中にまた戻って分析した方がいいこともある。
■オブジェクト間のメッセージを考える
以下の３点を考える
- どのクラスからどのクラスへメッセージを送るのか
- どのようなメッセージを送るのか
- メッセージを受け取った結果、どのように振る舞うのか
クラス間に関連がある = それらのクラス間で何らかのメッセージをやり取りする可能性がある。
・各クラスの操作を洗い出す
そのインスタンスがどういう振る舞いをするのか
・各クラスの属性を洗い出す
外部に影響しない属性は不要
1〜5のモデリングが終わったらクラス図にまとめる。
Lesson 7 既存のソフトウェアの再利用
Lesson 8 再利用を考慮したソフトウェアの設計
Lesson 9 フレームワークを利用したソフトウェア開発
オブジェクト指向を使ってソフトウェアを効率的に開発していくには？
継承とか移譲とか自作フレームワークとかを使って共通点をモデリングしていく
例えばトランプの場合、全部でカードが54枚ということは共通している
ゲームによってはジョーカーを使用しない場合があるので52枚とジョーカー２枚でそれぞれクラス化した方がいいのかもしれない。
手札を使うゲーム(ババ抜き、大富豪)、使わないゲーム(神経衰弱)などもあるので、ここでも分けることもできる。
継承(is-a)や移譲(has-a)をうまく使っていく。
継承は誤るとわかりにくくなるので注意
モデリングのキレイなプログラムがよいプログラムがよいプログラムか？ → △
近年だとコンピュータの処理速度が高くなっているため、拡張性・再利用性ばかり重視されて実行速度はあまり気にされないことが多い。
とはいえ無駄なループ、無駄なオブジェクトの生成はしないようにしっかり注意する。
結論：自分がJavaでオブジェクト指向開発が出来ない理由
モデリングが雑すぎることが一つの大きな原因だと思った。
振り返ってみるとモデリングを雑に起こっているがために
コーディング中にこのメソッドが足りなかっただの、これはいらなかっただの
ってことがある。
さらにいけないのがそれをその場で修正して結果的にそのクラスのインスタンスに相応しくない属性やメソッドが入っていたりするケースがあった。
もちろんプルリク通らず修正し直した。
今後は、
・自分がコンピュータに説明できるまで理解できているか
・Lesson 6 にあったモデリング手順の実践
・コーディング中にモデリングが甘かった部分が出てきたら手順を振り返ってクラス図を見ながら吟味する。
を意識して開発を行っていきたいと思った。
モデリングするための課題も見えたのであわせて学習していく。