A Philosophy of Software Design, 2nd Edition (English Edition)
目次
- 目次
- はじめに
- 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。
- A Philosophy of Software Design
- ラムダ式について
- 良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方
- 参考資料
- MyEnigma Supporters
はじめに
最近良い資料が多いので自分用にまとめておきます。
私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。
このブログ記事、すばらしすぎる。一緒にプログラミングする人全員に配りたい。"私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。"：状態、結合、複雑性、コード量の順に最適化する - valid,invalid https://t.co/93l2uNjOJm
— Atsushi Sakai (@Atsushi_twi) 2022年1月31日
A Philosophy of Software Design
すばらしい、資料。この本読んでみたいな：A Philosophy of Software Design 前半 - Speaker Deck https://t.co/n6AQ2oR814
— Atsushi Sakai (@Atsushi_twi) 2022年3月1日
優れた設計の最も重要な目的の一つはシステムを明白にすることだ。
シンプルなモジュールをたくさん作るより、シンプルなAPIで複雑な(deep)なモジュールを少数作る
例外をthrowするより、何もしない、もしくは空のデータを返した方がいい
実装の前に、テストだけでなく、コメントも最初に書く。
ラムダ式について
プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書
オブジェクト指向はラムダ式が無かったときの技術であるため、ラムダ式を使うとオブジェクト指向の複雑さを減らすことができる場合がある。
共通処理の中で扱う値が違う場合は引数で抽象化できますが、共通処理の中で一部の処理が違場合にはラムダ式で処理を与えることができます。
クラスの継承を使う前に、ラムダ式での実装を考えるほうがいい場合も多い。
良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方
良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方
データと関数をまとめるのがオブジェクト指向の基本。無駄なデータクラスが沢山ある場合は、密結合、低密度になっている可能がある。
クラスの責務は、インスタンス変数を不正状態にしないこと。
分岐を書きそうになったら、interfaceで分岐を減らせないかを考える。特にisaメソッドでクラスの型判定を行っている場合は、大抵リスコフの置換原則に違反している。
関数の戻り値はプリミティブ型でなく、できるだけクラスにして戻り値の意図を表明する。
可能な限り動詞一語で済む関数名にすると、良いクラス設計になっている(Add, removeなど)
クラスは一つ責務だけを課す(単一責任原則)。複数の責務がある場合は分割する。特にprivate関数が多いクラスは、複数の責務を持っていることが多い。
形容詞をつけて説明をする必要があるクラスは、その形容詞をクラス名につけるようにする。
クラスや関数の名前は、できるだけ具体的で、意味の範囲が狭いものにする。
nullを返したり、渡すぐらいなら、専用のクラスなどを定義して返すようにする。
参考資料
A Philosophy of Software Design, 2nd Edition (English Edition)
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
