読者です 読者をやめる 読者になる 読者になる

こすげのブログ

金髪エンジニアのブログ

【読書】「Code Complete 第2版 上 完全なプログラミングを目指して」の感想 その3

Kindle 読書

はじめに

今回は第2部高品質なコードの作成第6章 クラスの作成を読みました。

11時頃から読み始めてざっと2時間ほどかけてゆっくり読みました。

現状で39%の読了率となっています。

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

ハイライト

今回読んだ中でハイライトした部分をピックアップしてます。

第6章 クラスの作成

抽象化とは、複雑な処理を単純に見せる能力である。

6.2.1 | 良い抽象化

これはいい言葉だなーと思いました。

ま、当たり前なんですけどね...。


ListContainerクラスを継承することは、EmployeeCensusオブジェクトがListContainerオブジェクトであること(is a)を意味し、それは明らかに誤りである。EmployeeCensusオブジェクトの抽象化が検索やソートを可能にすることなら、それをクラスのインターフェイスに明示的な要素として組み込むべきである。

6.2.1 | 良い抽象化

同じ項で語られていた具体例です。

上記は抽象化のレベルが均一でないクラスインターフェースの話からの具体例です。

is ahas aはこの章でたくさん出てきました。


包含について考える方法の1つは、「has a」関係として考えることである。たとえば、社員は名前を持つ(has a)、電話番号を持つ(has a)、社会保険番号を持つ(has a)と考える。通常は、名前、電話番号、社会保険番号をEmployeeクラスのメンバデータにすることで達成できる。

6.3.1 | 包含(「has a」の関係)

これはhas aの関係の説明です。

ここまで明示的に書かれた文章を見たことがなかったのでかなり勉強になりました。


継承とは、あるクラスが別のクラスの「特化」であるという概念だ。継承の目的は、複数の派生(サブ)クラスの共通要素を規定する基底(スーパー)クラスを定義して、コードを単純にすることである。

6.3.2 | 継承(「is a」の関係)

こっちはis aの関係の説明です。

正直、継承ってやつを使いこなして作るほどのプロジェクトを手がけたことがないので、そこまで考えていませんでした...。

Swiftprotocol extensionもどっちかっていうと継承(「is a」)になるんですかね?


Andy HuntとDave ThomasはLSPを次のように要約している。「派生クラスは、ユーザーが基底クラスとの違いに気付かずに、基底クラスのインターフェイスを通じて使用できるものでなければならない」

6.3.2 | 継承(「is a」の関係)

LSPとは「リスコフの置換原則」だそうです。

ちょっとwikiりました

リスコフの置換原則

リスコフの置換原則(りすこふのちかんげんそく、英: Liskov substitution principle)とは、オブジェクト指向プログラミングにおける派生型の定義の一種であり、1993年、バーバラ・リスコフと ジャネット・ウィング(英語版) が論文 Family Values: A Behavioral Notion of Subtyping で提唱した。なお、これが派生型の唯一の定義ではない(データ型参照)。

この原則は、次のように簡潔に定式化されている:

T 型のオブジェクト x に関して真となる属性を q(x) とする。このとき ST の派生型であれば、S 型のオブジェクト y について q(y) が真となる。

すなわち、リスコフとウィングが定式化した派生型の定義は置換可能性 (substitutability ) に基づいている。S が T の派生型であれば、プログラム内で T 型のオブジェクトが使われている箇所は全て S 型のオブジェクトで置換可能であり、それによってプログラムの妥当性が損なわれることは無い。

リスコフの置換原則 - Wikipediaより

本当にWikipediaさんは難しい言葉が好きですよねー

多分それを簡単に言ったのが

「派生クラスは、ユーザーが基底クラスとの違いに気付かずに、基底クラスのインターフェイスを通じて使用できるものでなければならない」

になるのかなって思いました。


■クラスの名前を動詞にしない

振る舞いだけで構成され、データを持たないクラスは、実際にはクラスでないことが多い。DatabaseInitializationやStringBuilderといったクラスは、他のクラスのメンバルーチンにすることを検討する。

6.4.1 | 望ましくないクラス

当たり前なんですが...。よく間違える人が多いなと。

インターン生にクラス名やらの説明するときに使おうかなと思います。

ちなみに個人的な話なんですが、Objective-Cってクラスだけで構造体はあるけど使わなかったというか参考書に書かれていないというか...。

そのノリでSwiftをやり始めたインターン生がSwiftをやっているときに全てクラスで書いた時にどうやって教えればいいか悩んだことを思い出しました。

その時はQiitaさんの記事を読ませて使わせてみましたが...。

感想

クラスの作成ってすごい大事だなって思いました。

正直知らなくても物は作れますが、大規模のものや複数人での開発になるほどコミュニケーション能力ばりに活躍する力なのかと。

この前久しぶりにObjective-Cを触ったのですが、ヘッダーファイルと実装ファイル分かれているのがいいなーって思ったり思わなかったり。

第2部はもう一度読み直します。

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

終わりに

順調にkindleさんが活躍してくれています。

電車での読書もはかどります。