まとめ
メニューを開く-
満期の計算ならまだしも、金利やポジションの計算とかになるとよほどうまく抽象化しないとポリモルフィズムの恩恵にはあずかれなくて、しかし、そこまでの努力が本当に労力に見合ったものであるかというのが難しいところなのです。 -
もちろん、デリバティブや多通貨会計、外国為替みたいに本質的にオブジェクト指向とマッチングしやすい分野もあるわけで、やっぱりドメインごとに適用するテクノロジーは異なるという結論にならざろうえないのです。
-
OOADやその方法論を作ってきた技術者の責任は重いと思います。一方ではOOPのマルチパラダイム化、AOP、MDDなどで実装技術を進化させてきたのに、それらを適切に使い切るための設計法をいい加減にしてきた。それでどれだけのシステム構築が失敗し、大きな損失を出したか。 -
OOADの問題はTony Hoare氏のNull Referencesの問題よりも深刻かもしれません。http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
-
結局、開発言語やフレームワーク、デザインパターンを作る方が分析設計法を作るよりは好まれるということでしょう。これはRDBMSやKBSを作る方が、関係モデルや正規化を作るよりは好まれるということ。論理学や数学の素養がソフトウェア技術者には不十分だからでしょうか？
-
フレームワーク化とその支援ツールを進めることで、分析設計法を真摯に捉えなくてもアジャイルのようなアプローチで何とかできると考えるのでしょうか。しかし、それは問題の本質を解決しているとは思えない。もっとも分析設計法だけでも問題は解決しない。
-
でも、古典であるオブジェクト指向入門をもってしてもやっぱり僕が今直面しているビジネス・エンティティへの責務の振り方、適切なOOADっていうのは良く分からなかった。というか、ますます分からなくなったｗ
-
しかし萩原さんもおっしゃっていたけど、実装技術の進歩に対して、要求、分析、設計の技術の進歩があまりにも遅れすぎていて、うまく実装技術を使いこなせていないという感は僕にも強くあるなあー。
-
未だにドメインモデルを名詞抽出法からはじめるとか40年前より後退すらしている感があるのに、それを現場では平然と是とする・・・名詞は簡単に動詞になりうる、動詞は簡単に名詞になりうるから名詞抽出法は罠に嵌りやすいアプローチだというのに。
-
後、ユースケースって本質的にオブジェクト指向と関係ないのに、OOSEやRUP、ICONIXが前面に出してきたからなんかオブジェクト指向分析やるときには必須のように思われているけど、むしろこれまた罠の方が多い。ユースケースをシーケンス図で分析して責務を振るとかもね
-
これはオブジェクト指向入門でも書かれていて前から僕も疑問だったところだけど、ユースケースとそれをシーケンス図化して責務を振るという方法を使うと、本質的な計算依存ではなく、単なる記述上の前後関係を依存関係と勘違いしてしまう可能性があり責務の粒度が適切でなくなる可能性大。
-
もっと恐ろしいのが、その本質的な計算依存ではない、単に書き手が良く考えないで記述した記述上の前後関係に対するシーケンス図による分析は「トランザクション・スクリプト」になりがちで、まったくドメインモデルじゃなくなってしまうこと。
-
＞述語は常にエンティティの間にしか存在しないんですから。 ここが深すぎる・・・何をやってきたのか僕は・・・
-
より抽象化すれば、ものとものの間にあるのがこと。ことはまたこととつながります。そうして、こともものも述語として扱います。述語は真偽を示す命題。その命題が真になるコンテキストでものとことは記述される。これでビジネス領域はほとんど記述できます。
-
Content from Twitter
コメント