nikkie-ftnextの日記

イベントレポートや読書メモを発信

読書ログ | #ちょうぜつ本 第3章 〜オブジェクト指向の理解度が、かなり上がった感覚!〜

はじめに

変更しやすいコードが書けないのにソフトウェア開発とか舐めているのですか
天使様1ごめんなさい〜、nikkieです

「かわいい」と技術書が夢の合体を果たした、ちょうぜつ本(『ちょうぜつソフトウェア設計入門』)!🤗
読書会と絡めて読み進めており、今回は第3章「オブジェクト指向」を読みました。

目次

前回のちょうぜつ本!

いわしまんさんの書評エントリがきっかけで、手に取りました。
2章まで読み進め、

Kodakさんの感想エントリがきっかけでパッケージ原則を整理して理解できました。

パッケージ原則に関しては『Clean Architecture』まで手を伸ばしています。

オブジェクト指向、「多態性」と「継承/汎化」の理解度爆上がり

クリーンアーキテクチャ、パッケージ原則と学んできて、3章はオブジェクト指向
これは抽象を意識したプログラミングを実践するのに役立つという導入でした(3章扉)。

オブジェクト指向は以下の3つの特徴が関連して同時に現れる(3-4)と解説されます2

多態性ポリモーフィズム

多態性プラグインのイメージ!
これはかなりしっくり来ました。
というのも、私、VS Codeのどうかしている拡張🎀を作った経験があるんですね3

  • 本体のソフトウェア(VS Codeから見ると、どのプラグインプラグインという大きなくくり(単一種類)
    • 私のどうかしている拡張(実装詳細)も、VS Code本体からしたら1つのプラグインであることに変わりはない
    • 個々のプラグインに実装されている個別具体な処理に、本体のソフトウェアは興味がない(1個1個気にしてたら成り立たなさそうですね)
  • VS Codeの拡張1つ1つは中身が違う実体
    • プラグインというくくりでは一緒くたにできても、個別具体な処理はぜんぜん違う
    • 私のどうかしている拡張🎀 v.s. Python拡張

本体のソフトウェアに大量の分岐がある(Python拡張だったら...、nikkieの拡張だったら...)のではなく、プラグインのつけ外しで済むので、プログラムのロジックが簡単になります!
うまいな〜と思ったのは、ログを書くか書かないかを切り替える例。
ログを書かない場合は分岐するのではなく、何もしないロガーを初期化して渡します。
ロガーのインターフェースを持っていることが重要で、使う側はlogメソッドを呼び出しますが、何もしないロガーは何もしません(ログは書かれません)。

継承/汎化

3-4のイラストのゆにっとさんの言

具象が実際になくても 抽象を使えばモノがあることにできる

な る ほ ど な 〜 !!

この節の例は、ニュースサイトの記事の取得・表示。
まず2つの抽象を作ります(具象はまだありません)

  • ArticleRepositoryInterface
  • ArticlePresentaterInterface4

これらの抽象って多態性の側面もありますが、この時点では何パターンにも対応させたいわけではなく、先に抽象を作っただけです。
これは具体のリポジトリとプレゼンターがあることにしているわけですね。
ArticleOperationにそれぞれのインターフェースを実装したクラスのインスタンス(計2つ)が渡るとして、抽象のまま処理を書いていけます(ArticleOperationクラスは抽象に依存するのでパッケージ原則も満たし、安定!)。

仮にインターフェースに依存しておく作戦なら、データベースの事情と画面の事情がわからないうちでも、先にArticleOperationの大枠を安定させられます。(Kindle 版 p.115)

抽象があるということは、継承によってオーバーライドさえすれば詳細はどうとでもなるということ(今すぐ作らなくてもよい!)。
なので、抽象を抽象のまま使える!

継承のメリットとして差分プログラミングが解説されることは多い印象ですが、差分プログラミングはおまけ
ポイントは、抽象を使うだけで具体があることにしている!
「"多"態性はひょっとすると、0〜無限なのかもな」と思いました。

その他感想

上で挙げた2点以外も3章は学びが深かったです。

  • 3-1 オブジェクト指向の定義はない
    • 世にはびこる「オブジェクト指向ってxxx」という誤謬をぶった斬っていく印象
    • 例:関数型との整理5
    • 補足資料
  • カプセル化は以下のQiitaの図がしっくり来ていて、他より若干理解していたのです
  • オブジェクト指向と構造化プログラミングの違いも明確に👏
    • 構造化プログラミングは機能分解(1つの責務の分解)。上位構造の正しさが下位構造の正しさに依存する
      • これが解消できないことが欠点(だけどオワコンとまでは言っていない)
    • オブジェクト指向は「上位構造が正しいことを下位構造なしに成立させられる (Kindle 版 p.123)」
      • ArticleOperationの例、具体なリポジトリやプレゼンターを作らずして、抽象を使って正しい処理を書ける
      • インターフェースに適合する具象を後で当てはめるようにできる
  • Pythonで実装する場合、Protocol? それともABC(抽象基底クラス)
    • 後発のProtocolに寄せていくことを考えたほうがいいのかな
    • 写経コードはこちら:
    • 多態性の例はProtocolを試してみてしっくり来た(ダックタイピングをサポートした型がProtocolと理解しているので)
    • 継承/汎化の例(抽象を先に作って具象があることにする)、これってProtocolでワークするのかな。私としてはABCにして、抽象メソッド実装漏れを怒ってほしい気持ち

終わりに

ちょうぜつ本 第3章でオブジェクト指向の理解度がかなり上がった感覚です。

✍️以下が同時に現れる!

  • カプセル化
    • 認識単位
    • 詳細を知らなくてよい
  • 多態性
  • 継承/汎化
    • 抽象を使って具象をあることにできる
    • 差分プログラミングはおまけ

✍️オブジェクト指向に定義はないが、構造化プログラミングとの違い(「機能する抽象」)はある

たしかに抽象を意識したプログラミングを実践するのに役立ちそう〜(導入を回収!)

Clean Architecture』にも構造化プログラミング・オブジェクト指向関数型プログラミングを扱った箇所がありました。
過去に一読して実力不足でいまいちわからんという感じでしたが、いまは特にオブジェクト指向について少しは深く理解できるかも。

ちなみに第3章の個人的最かわいいポイントは3-3の挿絵!
そけっとさんの多態性❤️。
しいたけ、かわいい

P.S. 7/21(金) 第3章「オブジェクト指向」のちょうぜつ本_読書py!

次回ちょうぜつ本_読書py(Python使い視点でちょうぜつ本を読む、みんなのアウトプット中心の読書会)は7/21(金)です!

常連さんも、お久しぶりの方も、はじめましての方もオブジェクト指向に興味ある方、大歓迎です! ぜひぜひお気軽にお越しください〜


  1. 元は「家事ができないのに一人暮らしとか舐めているのですか」です(『お隣の天使様にいつの間にか駄目人間にされていた件』)。こっちもごめんなさい〜
  2. Sphinx拡張も開発していますし 極めつけは先日entry pointsを知って、プラグイン機構(本体とプラグイン双方)の解像度が深まったこと!
  3. ママ引用しましたが、私はPresenter綴りだと思っています
  4. 斬られたと認識した事例(いまの私はこのラジオの説明よりちょうぜつ本の説明のほうを支持します) オブジェクト指向は万能の薬ではなかった。関数型の流行へ。【プログラミングパラダイム・シフト5】#68 - YouTube