オブジェクト指向入門 第2版 原則・コンセプト

読書メモ。適宜更新。

1. ソフトウェアの品質

外的品質要因と内的品質要因の話。外的はユーザやクライアントに見えるもの、内的はそうでないもの。ここでは外的品質要因だけ紹介されている。正しく動くこと、拡張しやすいことなどのほか、UIの使いやすさや予算の話まで出てくるのが意外。

2. オブジェクト指向の基準

どういう機能があればオブジェクト指向と言えるのかという定義の話。クラス・カプセル化・例外処理・ジェネリクス・ポリモーフィズム・GCなど色々。ビルドツールや依存関係管理、ライブラリまで話を広げている。環境まで揃って初めてオブジェクト志向が効果を発揮できるという話と認識した。

2.2.17 動的束縛

こういうやつ

List<String,String> list = new ArrayList<>();

たまに具象クラスだけが持つ便利関数使いたくて動的束縛やめるときあるけどいいのかな

3. モジュール性

外的品質要因である拡張性・再利用性を得るためのモジュール化の話。モジュール性があるということの定義から、それを満たすための原則(開放閉鎖原則・単一責任選択の原則など)について触れている。

3.2.1 直接的な写像

業務モデルとコードのモデルを合わせろっていう話？ドメインモデル作れということかな。

3.3.1 言語としてのモジュール単位

「モジュールは使用される言語(UMLなどの仕様言語含む)の構文単位に対応していなければならない。」とのこと。OOPに則った単位でモジュールを作成するよう設計しているのに、実装ではOOPをサポートしていないC言語を使おうとするような状況が例として書いてある。仕様定義〜実装まで、決めたモジュール単位をサポートしている道具を使いましょうという話か。

3.3.2 自己文書化の原則

ドキュメントとソースコードが独立して作られることを危惧している。かといってソースコードそのものはドキュメントとしては粒度が細かすぎるため、モジュールの中にソースコードとドキュメントが含まれているのが正しいとしている。詳しくは11.13.2章。

3.3.5 単一責任選択の原則

ifやcaseの変更・追加による修正点が複数箇所あってはいけない。ポリモーフィズムや動的束縛でどうにかする。

4. 再利用性へのアプローチ

OSS時代になって大きく変わった部分だと思うし、「たくさん再利用して、少しだけやり直す」というのができてるように思える。言語が変わると実装や人材が再利用できなくなるのは仕方ないのかな。PythonとCみたいな関係性がどのくらい便利なのか分かってないけど…