感想

ADTやリスコフの置換原則

などに触れながら、クラス、インターフェース、コンストラクタ、パッケージなどの抽象化をわかりやすくまとめているなあ。
て感じ。

詳細

見出しとしては、

1. クラスの基礎：抽象データ型（ADT）

2. 良いクラスインターフェース

3. 設計と実装の問題

4. クラスを作成する理由

5. 言語固有の問題

6. クラスを超えて：パッケージ

7. 参考資料

8. まとめ

てな感じ。

まずJavaや

C++、VBの開発現場でプロジェクト管理職やプロジェクト管理職を目指す人は、知っているだろうし、知らないなら知っておいて損はないなあって感じなんだけど。

GASやWEB関連、VBAやアプリ開発でも、作り慣れている人は、
無意識にやっていそう（自分がそうだし）
ってところで、
特に、クラスって概念を言っているだけで、
明確にclassと言っていない

クラス＝データとルーチンのかたまり

を指しているだけであって、

class ◯◯{
 処理
}

を指しているわけではなく、

言語によっては、モジュールなり、スクリプトなり、functionなりで、
（継承や包含といった）何かしら再利用される可能性のある処理群全て

ってところに気づければ、要は、

• 共通で使えるところは、ある程度の規則性を保って、再利用する。

• 再利用するために設けた何かしらの関数や列挙体、構造体の中に、さらに細かい呼び出しや処理が増えてきたら、さらに他の関数で細分化できないか考える。

• なんか全ての処理で使えるみたいな強気すぎる関数を設けるだけ設けて、最近は全くつかってないなあみたいな関数はないか確認する。

って視点を持ちなさいってことかな💦。

最近は

顧客なり管理者（＝要求を出す側）が、ここまで理解していて、

• 細かい要求

• 詳細設計

• DB設計

• GUI

なんかを最初から詰めている現場なんて滅多にないから、

• タイトな納期を決めない。

• 要求が出たら、まずは調査する。

• 調査結果で要求どおりに実現できるように、しっかり準備する。

• 発展型プログラミング手法で、作る。

をして、ある程度、仕様が固まったり、定型作業化できた段階で、

• 色々なところで使っている共通のプロパティ値

• 複数箇所で使っている同じメソッド

などをEnumなりfunctionなりで、再利用できるように

リファクタリング

する際に気をつけて見返した方が結局は、作業効率が上がるかなあって気がする。

最初の段階で要求や設計を固められないのであれば、リリースした後１週間でもいいから、

リリース後のリファクタリングをセットで予定に組む（＝後工程）

ようにしておけば、次回からの改修やバージョンアップがさらに楽になる。
ま、リファクタリング自体を甘えとか不要って考えて予算を出したくない経営者がひと昔前は普通だったんだけど、、、💦

コードもなく、要求もふわふわした状態なのに、いきなりインターフェースやクラスを決めるところから入ると、それが障壁になって、却って作業効率が落ちるかなあ。

まとめ

JavaやC＋＋、VBに限らんなあ〜
（現場や使うプログラミング言語次第で、この章が正解なこともあるから）
常にアクリエーション的な発想で、
ひとつの方法や見方、考え方に縛られない。
↓
💃自分もお客さんも幸せにする近道🕺