１章から２章までの内容を振り返り、
まとめていきます。
ただ読むだけでは、
理解できていない気がする。
実務の中での活かしかたを考えていきたい。
１章 オブジェクト指向パラダイム
システムを作成するとき、
オブジェクト指向で考えるコツ。
二つの観点で考える。
一つ目の観点は下記２つ。
プログラムに持たせる責任を考える。
何をさせるかというよりは、何をして欲しいかを考える。
- 名詞：オブジェクト
- 責任：メソッド
例：「コメダ珈琲にいる自分（カネコチ）」がオブジェクトであり、「注文する必要がある」がメソッド。
２つ目の観点は下記３つ。
「概念」
責任の集合体であり、作るべきソフトウェアとは関係無く考える。（オブジェクトのこと）
「仕様」
ソフトウェアを考慮した責任の集合であり、それらの紐付きを考える。（インターフェースを考えること）
「実装」
プログラミングにあたる部分。どう責任を果たすかを考える。
システムの設計を考える上で「動詞」を元に考えることが多かった。
しかし、「責任」を元に考えるというのは、
「動詞」より納得感がある。（うまく言語化できないが…)
責任（やって欲しいこと）をベースに、
必要なものは何かという考え方は今後設計、製造の時に使っていきたい。
２章 UML統一モデリング言語
本章はこの後の章で利用されるUML図に限って、解説している。
クラス図、シーケンス図が解説されていた。
UMLは様々な図を用いて、
チームメンバや顧客とコミュニケーションを行なうためのツール。
形のないシステムの設計を分かり易く伝える。
表現を統一することにより、
スムーズなコミュニケーションをはかれる。
図の正しい書き方は気にしなくて良い。
相手に伝わる書き方をすることが重要であり目的。
UML内のアクセス可能性の表記法。
Public：どこでも
プラス記号（＋）
Protected：対象のクラス、派生クラスなら
シャープ記号（＃）
Private：対象のクラスだけ
マイナス記号（−）
クラス間の関連の表現の型。
１．コンポジション
is-a関係。
クラスの一部になっているクラス。
例：車の一部のタイヤ、エンジン。
２．集約
has-a関係。
クラスが他のクラスを「保持」。
uses-a関係。
クラスが他のクラスを「使用」。
何とか関係の記載なし。
クラスが他のクラスを「生成」。
カーディナリティ
1…0などオブジェクト間のか関係性の数を表す。
まとめというか感想
<p>
オブジェクト指向の基礎的なところを詰め込んだ内容という感じ。
</p>
<p>
１章の内容にあった「責任」を考えることで、
</p>
<p>
オブジェクト指向での設計をするというのは、
</p>
<p>
新しい発見だった。
</p>
<p>
<!-- START MoshimoAffiliateEasyLink -->
<br />
</p>
<div id="msmaflink-XCiHU">
リンク
</div>
<p>
<!-- MoshimoAffiliateEasyLink END -->
</p>