JJUGナイトセミナー「オブジェクト指向プログラミング入門」に参加しました。オンライン開催。簡単に所感をまとめます。
所感
Software Design 2021年3月号 の特集を執筆された3名によるセッション。設計やオブジェクト指向についてどう考えているかを聴けて面白かったです。
増田さんの話は自身の経験をベースにしてるんだろうけど、こういう話を体系的に整理して説明できるところがすごい。
あと、建築の設計はぜんぜん詳しくないけど、システム開発の設計は建築の設計よりもっと上流のフェーズにあるようなものな気がして、対比して語るのはちょっと違和感あるかなって。
小クラス主義については、全体的な設計の見通しを立てるために (分割する前提で) 最初は大きく作ることはあるかもしれないけど、難しいところ。
個人的には、設計は全体を俯瞰するプロセスで、プログラミングはもっとスコープが小さい話かなと思っています。で、犬猫とか車とエンジンみたいな例え話はプログラミング言語の文法を学ぶときに有用かなと思っていて、設計を身に付けるならシステムを図とか文章で書き起こして全体を理解するところから始めるとよさそうかなと思いました。たぶん。
以下、メモから抜粋。
なぜ設計を学ぶ必要があるのか
- 設計はシステム具象化の準備
- システムを抽象的に捉える
- 抽象, 捨象
- 見積もりや設計は過去の経験の抽象化
- プログラミング=具象 と 設計=抽象 を往復する
- 抽象化能力を経験以外から学べるか
- 設計を学問として学ぶ
オブジェクト指向と関数型を組み合わせる
- 関数型とオブジェクト指向は直交する
- 関数型の利点
- オブジェクトの不変性
- スレッドセーフ
- オブジェクト指向の利点
- メソッドがクラスに所属する
- 関係する演算はクラスの public API を見ればわかる
- 不変クラスの設計
equals()
,hashCode()
,toString()
- Record
クラス設計本格入門
- オブジェクト指向プログラミングはクラス設計
- クラス設計はプログラムの分割
- クラスはロジックとデータの集約
- 小クラス主義
- 小さく分割, 変更の影響の局所化, 部品としての再利用
- 不変
- 分割と統合の労力
- リファクタリング (分割の改善) を少しずつ積み立てる
- 分割したクラスを組み合わせるのは容易
- 分割
- メソッド/クラスの抽出 & 名前付け
- パッケージ/サブパッケージ & 名前付け
- パッケージ/クラスの名前で分割意図の表現を明確にする
- クラス/パッケージの凝集度を上げる
- ビジネスアクションの表現, ビジネスルールの表現
- ビジネスルールのクラスに void はありえない
- 対象領域(ドメイン)の関心事で分割する
- 周りにある関連語彙を増やして知識を広げる
- 基本の言葉のまわりにはさまざまな決め事 (ビジネスルール) がある
- 範囲や区分のカプセル化
- コレクション操作のカプセル化
座談会
- 不変性を実現するにはハードウェア進化の恩恵が大きい
- サブタイプ, サブクラス の違い
- immutable な Collection ライブラリ欲しい
- String クラスは役割持ちすぎ
- File IO は役割わけすぎ
- InputStream, Reader/Writer とか
- Files でわりとラクになった
- Stream は微妙に物足りない
- static or インスタンスメソッド
- static にすると mock にできない
- DBUtil, FileUtil, ...
- 継承可否を言語仕様で提供するのは?
- 継承できないのがデフォルトでよい
- 実装継承は使わない方がよい
- テストしやすいならデフォルト private でよい
- package private はバランスよい