ちょうぜつソフトウェア設計入門を読んだ
Amazon.co.jp: ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用 eBook : 田中 ひさてる: Kindleストア
エッセンス
全体的な本の流れ
設計なんで必要なん？
長くメンテされてくソフトウェアは改修しやすく作るのが大事なんや(変更容易性)
変更しやすくするにはどうすればええんや？
高凝集で疎結合で安定したものに依存するように設計すればええんや
安定したものに依存？
クリーンアーキテクチャがその解の一つやで
それはどうやって実装したらええんや？
抽象に依存するように作っていくとええで
抽象？
オブジェクト指向が役に立つで
もっと具体的に...
まずはSOLID原則を覚えておきや〜
抽象的すぎてついていけへんが?
UMLを使うと図で外観できるようになって便利や
てかオブジェクト指向で設計するのむずくない？
TDDという設計手法で作ってみるとうまくいきやすいで
もっと具体的な話が聞きたい
DIとデザパタというのがあってやな...
とはいえ仕事に応用できますかね？
アジャイル/DDDというのがあり...
メモ
設計はなんで必要なん？みたいな話が最初に書いてある。
良いコード/悪いコードで学ぶ設計入門とかGoogleのソフトウェアエンジニアリングとかにも書いてるけど一言で言うと長く成長(変更)し続けられるソフトウェアを作るためというのが共通してる点
初手1章でクリーンアーキテクチャから始まってドリルダウンでそこに至るまでの各種要素を解説する形になっているっぽい
クリーンアーキテクチャは設計の方向性的な感じ
凝集度
関心の分離
依存
利用する・されるの関係箇所を減らす
安定度
変更頻度の高い事情に依存しない
クリーンアーキテクチャは前者2に加えて安定度に特に着目してる(いわゆる円の中心に向かって矢印が引かれているような図のアレ)
内側(中央)に行けば行くほど変更が少ない要素
1層: ドメインモデル
2層: ユースケース
3層: インターフェースアダプター
4層: インフラストラクチャ
クリーンアーキテクチャで一番不安定なのはアーキテクチャ内の最外殻
よく考えればそうだけどインフラストラクチャの外は自前のアプリケーションなんかよりよっぽど安定してるな
安定したものに依存しようぜ
= 抽象に依存しようぜ
実装の詳細に依存しないようにしようぜ
オブジェクト指向設計原則
だいぶ昔に読んだ記憶のある記事を読むと良いな
オブジェクト指向設計原則(Principles Of Object Oriented Design) - A Memorandum
7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
色々難しい原則があるが結局高凝集で疎結合な設計で変更に強いコードを書くための話なだけ
オブジェクト指向に対する著者のお気持ち
Youtubeの動画を観ると良い
https://www.youtube.com/watch?v=AjvRsrZZP6Y
構造化プログラミングとオブジェクト指向
構造化プログラミングは機能分解。それぞれの分解した機能やクラスが互いに結合しているイメージ
オブジェクト指向は本当の意味で独立した部品の組み合わせ。上位と下位が独立。抽象。それぞれが付け替え可能。
漫画のコマ、最初は意味ないと思ってたけどその場で扱ってる話題の「つまり」をギャグチックにまとめてくれてて便利だとわかってきた
SOLID原則
単一責任原則で責務を適切に絞り、あとはインターフェースを意識して組織していきましょうくらいで十分なんだよな...
テスト
バグは下位構造に向かって膨大に広がっている
ユニットテストで品質が一定保証された部品を作っておけばその下位構造へのバグ探索を特定の場所で打ち切れる
TDD
クラスやモジュール単位。設計手法。内部設計。
114. テスト駆動開発とは何であって、何でなかったのか？ w/ twada | fukabori.fm
よかった記憶がある
BDD
ユーザーの使い方単位
TDDは死んだ。テスティングよ栄えよ。 by DHH - やっとむでぽん
DHHの記事。もう10年前か...
TDDもBDDも仕様通りの振る舞いを保証するためのものという意味では同じ
デザインパターン = 設計パターン(not クラスの書き方。つまり関数で実装する場合も使える。)
継承による拡張が問題視されるのは疎結合なオブジェクトへの委譲で十分なところにより制約の多い実装継承をそうと知らずに盲信して無警戒に持ち込む場合です
これ
軽率にis-aに囚われるな・Template Methodで設計可能なのは一つの系に過ぎない
良い言葉。継承が使いづらい理由でもあるな...
オブジェクト指向プログラミングの本質 is 実態の多様性を隠蔽すること
ある世界とある世界同士の間で依存度を下げるため如何にして互いの情報を絞るのか？を結局のところやっているのだよな
Factory
Facade/Mediator
Proxy/Decorator/Adapter
composite
振る舞いの詳細を隠蔽した抽象 = オブジェクト指向。高階関数で構成してもそれはオブジェクト指向設計になる。
振る舞いを誰が生成し管理するか？
Strategy/State/Command/Observer/Visitor
データと振る舞いを分割して、必要なタイミングで振る舞いを差し込んだりデータを差し込む関数型の世界
デザインパターン = 再利用できるものを作るための普遍的に使える知恵
アジャイル
Entity/ValueObject/Service/Factory/Repository
DDD
モデル駆動設計がユビキタス言語を通じて要求の洗練のフィードバックを受けて育つ、このプロセスのこと
その目的を実現するユーザーとともにソフトウェア開発の最上位で意思決定を反服すること。
アジャイル開発 = 対話と再計画/DDDの反復プロセス
アジャイルソフトウェア開発宣言
code:txt
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
健全に変化を受け入れる/何度もプログラムに手を入れる
そのためにクリーンアーキテクチャがありTDDがありオブジェクト指向があり...という感じでつながっている
ブルックスの法則
https://ja.wikipedia.org/wiki/ブルックスの法則
読書メモ