ただはってくだけ
元記事
オブジェクト指向プログラミング by "@"kis
これは、なぜオブジェクト指向と言うときにオブジェクト指向分析・設計の話がされることはなくなってオブジェクト指向プログラミングを指すようになったかという話でもある。
— きしだൠ(K1S) (@kis) August 5, 2022
「オブジェクト指向はxxxという制限を加えれば全然使えると思う」みたいなコメントがつくことがあって、xxxの代表は継承を使わないとかなんだけど、それならオブジェクト指向じゃなくていいじゃーん他でできることをオブジェクト機能使ってやってるだけじゃーんってなるんよね。
— きしだൠ(K1S) (@kis) August 5, 2022
データとふるまいを一緒に書けるというのも、オブジェクトの依存はなるべくなくしましょうという話になった結果、ふるまいとしては設定データの検証か保持データの別表現くらいになっているので、そこまでキリッって言えるものか？っていう感じがある。
— きしだൠ(K1S) (@kis) August 5, 2022
アジャイル と DDD by "@"j5ik2o
総論として違和感ない。同じような印象かも。OOA/OODの統一化の失敗からの～アジャイルとDDDに関心が移った感じにみえたねー https://t.co/pCYjUt8dCK
— かとじゅん (@j5ik2o) August 5, 2022
Evans本として結実する以前でも、ドメイン分析の文脈ではいろんな書籍があるけど、XPなどのアジャイルの動向と共に勢いがついた？もしくは息を吹き返した？という側面はあるかもしれない。https://t.co/EQObjzAXnW
— かとじゅん (@j5ik2o) August 5, 2022
ユースケースならダグ・ローゼンバーグ先生のICONIXに繋がりが強そう。ICONIXも広義の意味ではドメイン駆動設計と解釈できそう。EvansはXPや責務駆動設計の影響を受けている気がします。ソフトウェア以外のシステムのユースケースや問題の対象に目を向けると言う点では共通してると思いますね。
— かとじゅん (@j5ik2o) August 5, 2022
ユースケース と XP(スクラム) by "@"HHany
たしかにオブジェクト指向方法論は要求定義・システム分析・設計・実装・テストをすべてオブジェクトの観点で統一的に扱うのだという理想にもえた運動でした。オブジェクトというかクラスが知識を載せるビィークルとして上流から下流までトレーサビリティを確保できるとの幻想があったのです。 https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
しかし上流はオブジェクトで整理できるほどそんなに安直じゃない。そこにユースケースのアイデアが登場し世界が歓喜しました。この部分は日本だと要求開発やRDRAに繋がっていまに至ります。世界的にはデザイン思考やサービスデザインでお茶を濁してる感じ https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
そして本丸の設計実装テストのところはJavaと関連フレームワーク群の妥当な取り仕切り方がEJB等の黒魔術を乗り越えてシンプルJavaへ、デザインパターン運動がオブジェクト設計原則へ、それらをXPが一気に統合して第一期のアジャイルに至る感じですかね https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
なので平鍋さんもいうように今しばらくは、レフトwingとしてプロセスマネジメント系はスクラムに、ライトwingの開発方法論系はXPによって担われているイメージでしょうか https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
カプセル化と先祖返り "@"kis
オブジェクト指向って継承による多態があるからこそなんだけど、継承が非推奨になって以降に雰囲気でオブジェクト指向を知った人って、継承はオプションでカプセル化だけでオブジェクト指向って言ってしまいがち。
— きしだൠ(K1S) (@kis) August 5, 2022
カプセル化はオブジェクト指向固有じゃなくて、クラスでカプセル化を実現してるだけ。
アランケイのオブジェクト指向だと、多態はメッセージによって行われるけど、いずれにせよカプセル化+多態というのが重要。
— きしだൠ(K1S) (@kis) August 5, 2022
ストラウストラップがCにクラスを組み込んでC with Classesを作ったとき、仮想関数はまだ導入されていなくて多態ができなかったので、クラスの機能はユーザー定義型機能と呼ばれていた。
— きしだൠ(K1S) (@kis) August 5, 2022
仮想関数が導入されてオブジェクト指向機能と呼ばれた。
クラスを使わないカプセル化、最近はいろんな言語にextensionとして導入されてる。多態はできない。
— きしだൠ(K1S) (@kis) August 5, 2022
実際のところこれってオブジェクト指向以前に戻る先祖返りなのよね。
AdaやModula-2はオブジェクト指向の特徴と思われてる機能を継承以外はもっていたけどオブジェクト指向言語と呼ばれることはなくて、継承可能なクラスを導入したAda 95やModula-3からオブジェクト指向言語と呼ばれた。
— きしだൠ(K1S) (@kis) August 6, 2022
アジャイル と 強い型付け言語 からの DDDの登場 by "@"HHany
オブジェクト指向方法論で狙っていた一貫したトレーサビリティというのは、現在では、「ストーリー」単位で企画し、「クラス」単位で設計・実装し、クラスとストーリー単位でテストすることで、「実行可能アーキテクチャ」を段階的に作り「検証」ながら、 https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
動的なアジャイルチームの人間系とセットでトレーサブルにするということに落ち着いたのでしょう。
— 羽生田 栄一 (@HHany) August 6, 2022
さらに強い型付け言語を用いて、型推論で柔軟性を確保しながらドメイン記述語彙として適切な型とその制約をどんどん定義していくことで、「実行可能アーキテクチャ」が妥当であることを検証し続ける https://t.co/P8oeT4bYnP
ユーザー目的にとってもシステム制約にとっても検証のベースになるというのが確立した。
— 羽生田 栄一 (@HHany) August 6, 2022
その流れの中で、DDDが意味を持つわけで、実装やシステム設計とビジネスドメイン仕様とを論理的に分離しつつも「実行可能アーキテクチャ」で常に検証はできる状態を保ちたいという欲求に答えるのがDDD登場理由 https://t.co/P8oeT4bYnP
ここでは、型と制約をクラスとメソッドで記述しても、関数型言語で記述してもいいわけなので、オブジェクト指向は乗り越えた議論になってる。 https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
同一のクラスで上流と下流をつなぐのではなく、ドメインという純粋にビジネスや業務のしくみに特化したモデルをビジネス関係者とコラボしてつくり、それをラッピングするシステム層(層というかなんというか)と分離して管理するソフトウェア技法がDDDということです。 https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
DDD と お手本不足 by "@"HHany
ところが現状のDDDは、ドメインとシステムのモデル分離の仕掛け実装にばかり頭が言ってしまっていて、ドメインの中身をどのようにモデルとして整理・表現すればよいかの部分がヒントがない・お手本がないということで困っているように見受けられます。 https://t.co/P8oeT3TP9H
— 羽生田 栄一 (@HHany) August 6, 2022
ところが現状のDDDは、ドメインとシステムのモデル分離の仕掛け実装にばかり頭が言ってしまっていて、ドメインの中身をどのようにモデルとして整理・表現すればよいかの部分がヒントがない・お手本がないということで困っているように見受けられます。 https://t.co/P8oeT3TP9H
— 羽生田 栄一 (@HHany) August 6, 2022
椿正明氏のTHモデルとか勧めると引く人多数と思うので、心の中でIT界の橋本治として勝手に尊敬する羽生章洋『楽々ERDレッスン』翔泳社2006を熟読玩味することをお勧め。上流のモデリングという意味では、羽生さんの『はじめよう! 要件定義 ~ビギナーからベテランまで』とセットで読むと最強です。 https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
ポスト OO の ベースラインの混乱 by "@"HHany
いまではWebサービス事業会社がアジャイルとDevOpsやSREと呼ばれる実践的なソフトウェア・エンジニアリングを推進しているわけだけど、それらのどこまでが基本的なソフトウェア開発技術でどこからが各組織の目的や成熟度に応じたオプションなのかが見極められずに混沌としているかも(某IPA見解)。 https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
レフト翼はようやくPMBOK７でアジャイルと組織運営の方法をフレーム化して自分たちでテイラーリング(取捨選択)するという方向で（お化けのように複雑な大規模アジャイル手法ではなく）DAベースで整理を進めようとしているところは望ましい動きと受け止めつつ、混沌はしばし続く https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
ライト翼はまさにポスト・オブジェクト指向方法論が出てこないといけないわけですが、組込みエンジニアリング界隈ではMBD(モデルベース開発)がそれなりに定着しつつある一方で、ビジネス系はいましばらくの混沌が。。ソフトウェア工学がGoogleソフトウェアエンジニアリングを再整理する必要性を感じる https://t.co/P8oeT4bYnP
— 羽生田 栄一 (@HHany) August 6, 2022
感想
分析設計論は分化していて、プログラミングそのものは型付けと制約による柔軟な検証装置が目的で(クラスまたた抽象データ型はさほど重要ではない)という感じで腑に落としました～～