あるエンジニアの備忘録

読んだ本、記事の備忘録

【書きかけ】読書メモ:アジャイルソフトウェア開発の奥義(第2部)

アジャイルソフトウェア開発の奥義の読書メモです。 厚い本なので全6部に分けるつもり。今回は第2部。

1部はこちら

第2部 アジャイル設計

第7章 アジャイル設計とは?

貧弱な設計とはどのようなものか?それを避けるためのアプローチ(=アジャイル設計)は何かを説明している。

貧弱な設計の特徴は次の通り。

  • 硬さ:設計変更が困難
  • もろさ:設計が壊れやすい
  • 移植性のなさ:設計の再利用が困難
  • 不必要な複雑さ:行き過ぎた設計
  • 不必要な繰り返し:マウスの使い過ぎ
  • 不透明さ:整然としない表現

これらを避ける助けとなるのがオブジェクト指向の原則(第8章~第12章)である。 悪臭を放つのは原則を満たしていないのが原因である。

この章では、以下の文章に感動した。 良い設計とはなにか?なぜ良い設計を行うのか?の解になると思う。

アジャイルな設計とは「プロセス(流れ)や「イベント(事象)ではない。ソフトウェアの構造や可読性を向上させるために、原則、パターン、そして、プラクティスを継続的に適用する行為である。またそれは、システムの設計を可能な限り、シンプル、クリーン、かつ、わかりやすく保つために献身的な行為である。

第8章 単一責任の原則(SRP)

単一責任の原則(SRP: The Single Responsibility Principle)について説明している。

クラスが複数の役割を背負っている場合、それらの役割は結合してしまう。その結果、ある役割が変更を受けるとそのクラスが担っているほかの役割も影響を受け、不具合が生じる可能性がある。こういった類の結合は、ある部分が変更を受けると、予想もしない形で壊れてしまうようなもろい設計を生み出してしまう。

役割というと分かりづらいが本書では役割=変更理由と定義されている。クラスを変更するのに2つ以上の理由がある場合、そのクラスは2つ以上の役割があるのことである。また、永続的なシステム(データベースなど)とビジネスルールを包含するのは典型的なSRP違反とのことだ。

書いてある内容は納得しつつも、役割が何か?と言われると想像力を働かせる必要があるので難しい。ここに強くなるには想像力とドメインの知識が不可欠だと思う。

第9章 オープン・クローズドの原則

オープンクローズドの原則(OCP: The Open-Closed Principle)について説明している。

この原則はぱっとはわかりづらい。単純に考えると「拡張に開いて修正に閉じるってどういうこと?拡張する=修正するじゃないの?」と思ってしまう。これを理解する鍵はオブジェクト指向の抽象化の概念にあった。

第10章 リスコフの置換原則(LSP)

リスコフの置換原則(LSP: The Liskov Substitution Principle)について説明している。

書きかけ

第11章 依存関係逆転の原則(DIP

DIP: The Dependency Inversion Principle

書きかけ

第12章インタフェース分離の原則(ISP

ISP: The Interface Segregation Principle

書きかけ

ここまでの感想

書きかけ