きしだのはてな

masterq 2014/07/19 01:12 UMLやMDAについても一言おねがいします。

masterq 2014/07/19 01:37 あ、それから現在において、設計の安全性に貢献しない高階な型をいま良かれと思って使っている風習もそのうち同じ結論をたどるかもしれません。。。

疑問点 2014/07/19 03:09 これって一切の再利用をしない前提の使い捨てプログラムの話ですよね？

ヒゲ 2014/07/19 05:51 使い捨てプログラミングという前提はどこにも無い。それどころか「差分プログラミング」とまではっきり言っている。

ティーケーエムアール 2014/07/19 09:45 > むだにHogeインタフェースとHogeImplクラスがあったり、
What(問題領域)の世界をインタフェースや抽象クラスで表現し、Howのところを具象クラスでやるっていう感じなんでしょうかね。
ただ、以下のいずれにも「該当しない」のであれば無駄だと思います
　(1)問題領域を解く方法がそんなに変化しない、
　(2)問題領域を解く方法を変更してもほかに大きな影響がない、
　(3)さまざまな環境で運用されることが想定され、問題領域を解く方法が環境毎に変化する、かつ変化が頻発(いろんな環境で使われる)する

まあ、設計的にいえば抽象化を一段噛ますのであれば、ちゃんと変化点と影響範囲見極めろ、ってことですかね。。。


>どこで値が設定されてるかわからないオブジェクトがひきまわされてたり
これは困りますね。ただ、パッケージ間インタフェースやレイヤリングの設計をミスっているとどんな言語でも起こる気がする。あとはデータフローがちゃんと設計されてないだけかも。。。

というか、書籍化されたオブジェクト指向の解説って、エンプラ系の新規システム開発に特化してる気がする。。。組み込み系/Web系、あるいは派生開発でそのまま使うのは難しいのもしれない。

オージス総研の人に話を聞いてみたいなあ。。。

IG 2014/07/19 13:02 ここでいう「オブジェクト指向」は、「ファンタジックな指標を与え」るものとしての「オブジェクト指向」ということですね。Joel on Software では「宇宙飛行士」と称していましたが。初期の J2EE が失敗例として挙げられることが多いですね。Sun（当時） の開発者自身が失敗と認めていましたね。コードを書かずに、「オブジェクト指向設計のドキュメント」で先に設計したのが大失敗の原因だったと。

つまり、ここでいう「オブジェクト指向」は、現実のプログラム コードの機能・性能に何ら貢献しない「オブジェクト指向」のことでしょう。「そのようなオブジェクト指向は、窓から投げ捨てるべき」というのは、そのとおりと思います。

gomocoro 2014/07/19 14:51 タイトルは過激だけど、一言でいうと「下手くそなオブジェクト指向はやめろ」ということであって、それはそのとおりだと思います。ただ、指摘している内容とタイトルがあってないので、初心者の方の誤解を生むし、このタイトルは良くないと思いました。沢山の人に呼んでもらうために、過激なタイトルを付ける手法かと思われます。

プログラミングは眠るのも忘れて 2014/07/19 22:46 あー、なんとなく同感するところあるわー
オブジェクトって、変数にインターフェース（メソッド）つけたもの、
って理解しておくのがよさそう。

鋼のアーキテクト 2014/07/21 16:45 言わんとしている事はわかる。
が、OOP禁止はやりすぎ。禁止してしまうとフレームワークがうまく設計出来なくなる。
アーキテクチャチーム（もしくは方式チーム）のようにフレームワークや共通部品を作るチームにはOOPは必須だと思う。
業務ロジックを実装するチームはその部品を使うだけだろうから、無くても困らないと思うが。

名無し 2014/07/24 13:15 どこぞやの関数型の性質を持ったプロトタイプベースOOPが最強ということでよろしいか？

babydaemons 2014/07/24 22:42 鋼のアーキテクトさん：
ここで言うOOP禁止というのは、携わる業務に特化したフレームワーク・共通部品（RubyではDSL）を
作れないITドカタやコピペプログラマは無理してOOPで作るな、人様が作ったフレームワーク・共通部品の恩恵に
預かっておけと言うように理解しました。

勉強中 2014/07/25 15:10 IGさんへ
　＞初期の J2EE が失敗例として挙げられることが多いですね。
　＞Sun（当時） の開発者自身が失敗と認めていましたね。
　＞コードを書かずに、「オブジェクト指向設計のドキュメント」で
　＞先に設計したのが大失敗の原因だったと。
この辺の事を詳しく知りたいので、もし何かlink先や記事を御存知でしたらお教え下さい。

もり 2014/08/26 00:03 >「複雑度を下げることを指標としてプログラムを書いていると、
>「オブジェクト指向する」という感覚にはならない。単にプログラム言語と向き合うだけになる。」
複雑度を下げるために責務とか、凝集度等を考えることになると思いますが。
機能的に考えるだけで複雑さが下がるという考えは
プログラムを作成するときに発生する問題を単純化しすぎだと思います。

nowokay 2014/08/29 20:58 結局は、メソッドの呼び出し数とか、状態の持ち回り数とか、そういう話になると思います。
責務とか凝集度とかは、その方向性のヒントになるだけで、最終的にはコードがどうなるかというイメージを持ってコードを書くのがいいと思います。最後には必ずコードになるわけで、そこを最適化するのが目標なので。

chungzee 2014/09/02 15:35 メイヤーを読了したのであればちょっとご意見を聞かせてください。
メイヤーが「オブジェクト指向入門」で言及しているOCPと、ボブマーチンが「アジャイルソフトウェア開発の原則」で述べているOCPは同じだと思いますか？違うとすればどのような点ですか？

あ 2015/01/18 01:15 自己満足な記事ですね

ぺーぺー 2015/12/18 08:59 OOPで大事なのはブラックボックスで協調するという点のみ
重要なのは再利用性だけだから、ライブラリがついているなら問題無い。
作成されたオブジェクトにどの程度の成約事項がついているか、実行速度がどの程度かそれだけが指標。

また他人が作ったオブジェクトについて、ソースの中身に言及するのがナンセンス、そういうのは教育の現場でのみやること。

foobar 2016/12/11 23:23 ＞むだにnewするだけのcreateメソッドがあったり
これよくある、笑ってしまったｗ
無駄に色んなデザインパターン詰め込んであるけど、
自己満足のためだけでまったく利用されてないやつねｗ
インターフェイスとImplを分けてるのも、
他の利用者がろくにifクラスを使わなくてほとんど意味なかったりとかｗ

信者 2016/12/18 17:53 面白い意見だと思いました。デザインパターンとアジャイル開発についてはどう思われるのでしょうか。

nowokay 2016/12/27 05:53 デザインパターン、GoFのデザインパターンについては、90年代のC++の言語制約上できなかったことをいかに実装するかという話で、ほとんどが関数式がある言語では不要になっているし、フレームワークという考え方のほうが広く使われるようになったしで、4月ごろに雑誌にでる気の利いた記事を読んで今でも使ういくつかのパターンを知っておけばいいかな、という感じです。
アジャイルは、よくわかんない。というのが答え。あと、変なこというと刺される雰囲気がある。

オブジェクト指向の謎 2018/06/23 21:26 JavaやC#の謎は関数を定義するために名前空間とクラスを必要とするところだ
名前空間はまだわかる、なんで関数(static method)の宣言にクラスが必要なんだ？
正直Javaで関数書く気なんてしないし、言い換えればJavaでプログラム書きたくない
関数こそプログラミング抽象化の基礎であり、オブジェクト指向論者が好んで用いるSOLIDや再利用性を本当に満たすのはクラスじゃなくて関数だと思う
(純粋)純粋関数的に実装していれば、再利用性も組み合わせ利用もソース記述も比較的シンプルに行える。それではほしい分のパフォーマンス出ないから状態使いますよ、それをうまいこと隠蔽しますよってならクラス使う意味が凄くわかる。
オブジェクト指向が提唱する概念ってほとんどがオブジェクト指向がサポートしない概念、言い換えればないものねだり、UNIXのシェル(パイプ)とか関数型言語のmap reduceのほうがどう考えても再利用性が高いしインターフェースが簡潔に保たれている
当時のマイクロソフトやサンが営業攻勢にかけていたから、オブジェクト指向は広く普及したが、数学や哲学的なバックグラウンドが無いに等しいから中途半端だ
再利用性を求めるなら関数型プログラミング、パフォーマンスを求めるなら弱い型付けのビット列の変換としてCで書く、その折衷案であるオブジェクト指向から入るとどっちつかずにしかなれない