koboriakira.com

ブレイクスルー(PythonのDependency Injection)

April 15, 2020

2020年4月8日、水曜日。

以前買ったバターケースを使ってないことを思い出してさっそく使う。バターをケースに入れる前に10gずつに等分したのだけれど、これをケースにしまうのが大変だった。外にいようが家にいようが、日常ってのは面白いものだ。

ひきつづき『clean architecture 達人に学ぶソフトウェアの構造と設計』を読む。第Ⅲ部の途中まで。

  • 第7章: SRP:単一責任の原則

    • モジュール(ソース、関数、データをまとめた凝集性のあるもの)はたったひとつのアクターに対して責任を追うべきである
    • アクターの異なるコードは分割するべきである
    • 解決策のひとつとして「データを関数から切り離す」戦術がある

      • 同じクラスを利用せず、アクター別のクラスを用意する
      • 異なるクラスが増えすぎて収拾がつかない場合にはFacadeパターンを利用する
      • 切り離す前のクラスに重要な(共通的な)メソッドとFacadeパターンを載せる戦術もある
    • 単一責任の原則は、関数レベルの原則であり、コンポーネント・アーキテクチャレベルでも単一責任の原則はある(名前は異なる)
  • 第8章: OCP:オープン・クローズドの原則

    • ソフトウェアの振る舞いは、既存の成果物を変更せずに拡張できるようにすべきである
    • この原則はクラスの設計指針というより、むしろコンポーネントのレベルを考慮したときに重要なものとなる
    • コンポーネントからコンポーネントへの線(依存)は、すべて一方通行にする
    • コンポーネントは、「自分自身を変更したときに影響を及ぼしたくないコンポーネント」に対して依存させる

      • 感想: ここでいう「影響」は実際の処理だけではなく、前述されているデプロイなども含まれているだろう
    • アプリケーションの中心となる関心事を処理するビジネスルールをふくむコンポーネントは特権的な位置づけを得るべきである
    • 特権的なコンポーネントは、他のすべてのコンポーネントの変更による変更の必要をなくすようにする

Pythonのパッケージ、モジュールのimportについて。やっとひとつ理解できた。まだ言語化できていないのだけれど、揮発しないうちに頑張って実践してみる…ということでかれこれ4,5時間熱中して株プログラムの依存関係を整理してみた。IDEでもうすこし楽にできればいいのだけれど、とりあえずは全部タイピングして血肉にできた。

このあたりの実装ができるようになると、あらためて設計の難しさに立ち戻ってくる。もう何度か忘れてしまったけれど、もう一度DDDをやりなおそうか。


Kobori Akira

IT業界の社会人。音楽、パッカーズ、スワローズ、ポーカー。
読む価値のある記事はQiitaやnoteに投稿する予定です。
過去人気だったブログ記事はこちらから。