お前ら俺にオブジェクト指向を教えろや　２周目

当たり前だな。
ぐへへへ

いままでC#やらVBでコードを書くときに、イベントハンドラにロジックをベタ書きしてたけど、
これじゃいけないと思って、いまやってるプロジェクトでは、MVCの変形らしい、MVP(Model-View-Presenter)パターンと
いうので書いてみたけど、なんていうか、すごい手間がかかった。
どこまでをロジックで書いて、どこまでをViewで書くかとか、試行錯誤が多かったからそれで余計疲れたってのも
あるけど、それにしても手間がかかりすぎって印象だった。
オブジェクト指向っぽく書いて、unitとか導入まで考えてたけど、とてもそこまで手が回らないって感じ。

世間じゃ、まじでViewとロジックの分離とかやってるの?

>>938
普通にやる
つーか、やらないと後で困る

試行錯誤が発生するのは、慣れの問題
いつも分離して書いていれば、そのうちそれが普通になるし、
歳を食えば食うほど、分離して責任範囲を明確化するとか、
Unitテストでコア部分の実装を保証するとかやらないとやってられなくなる
OOPは年寄りに優しいからなｗ

ロジックとビューの分離なんて、構造化分析/設計の時代から言われてる
ことなのに、VB厨は時代に取り残されているというより最初から時代に
ついていっていないんだな。

構造化プログラミングすらしない・できない人たちのためにオブジェクト指向があるんだと最近思うんだ

オブジェクト指向の前に型理論

エージェント指向がいいと思うよ。
みんな人に置き換えて、中の人の仕事を書き出すのさｗ

そのうち、一人で全部の仕事をやって鬱になる人とか発生するわけですね、わかります！

全員に指示を出しても
８割が働いて２割が怠ける法則も発動ですね。わかります。

結局、エージェント内部が全実装なので何の解決にもなって無いというオチ。

それどころか、人工知能だよその要求仕様はｗ

動的オブジェクト指向を教えてください。

3本柱（今でもいうの？）を覚えてください。

何の？

>>949
？？？？？？？？？？？？？？

よし、スルー。

手塚に何か言われたのか

それ自身はオブジェクト指向というよりオブジェクトベースだけど、PowerShellはOOPを理解するのにとてもいいと思う

>>916-923
豆腐の話ってメモリマネージャで
メモリの切り出しみたいなことじゃないの？

クラス図を書けって宿題が出て困ってます

ポーカーゲームの「ディーラー」の属性は
「所属店」って書いて間違いじゃないですか？

それでいい。
お前天才じゃないか？

>>956さん
正直属性とかよくわかんなくて・・・
レスありがとうございました、これで自信を持って提出できます

なぁ、俺にオブジェクト指向でのプログラム再利用と関数化でのプログラム再利用の違いを説いてみやがれ。
ちなみにPHP最近はじめた俺です。

長文ゴメン

・関数化でのプログラム再利用
→
後に関数を修正したい場合、そのまま修正するか、
或いは、良く似た関数を追加することになる。
前者の場合で影響範囲が大きい場合にテストが心配。
後者の場合、良く似ている別の処理であるため、
その違いの認識が容易でない。保守が心配。
安易なコピー＆ペーストによって類似ソースが大量に発生しそう。
開発者が一人であるならともかく、複数の場合は深刻。
（安易なコピー＆ペーストをされたら、オブジェクト指向言語でも深刻ですが）

古い世代の言語においては、汎用的な関数を作成したつもりでも
「複数スレッドから同時実行」といったコンセプトでは正常動作しない
ケースも多く、現代の複雑なプログラム開発に耐えられるか疑問。

・オブジェクト指向の場合（俺はJavaしかわからん）
→
新しい仕様について、どのクラスに仕事をさせるか？
ということをあらかじめ想定してからコードを書く。
既存のクラスを修正する？継承？オーバーロード？オーバーライド？
昔に比べて若干選択肢が増えている。

同時実行に関しては、インスタンスを複数個作成し、
個別にメソッドを実行するという記述が容易。
古い世代の言語とは一線を画するかな、と思う。

c++だとオブジェクト指向とか意識してなくても関数の
オーバーロードが使えるし、意識してリエントラントに作らなければ
Javaだろうが何だろうがマルチスレッドで動かせば破綻する。

で、オブジェクト指向って何がありがたいんですか？

>>960
つひろみちゅ

ライブラリの処理の中で一部分だけ処理を変えたい場合に
その部分がオーバーライド可能な関数だとサクッと片付けられるよな

C++使ってるけど、
グローバル変数とかstatic変数とかが大量に使われてるので
マルチスレッドで動かせば変な動きになるだろうな。

synchronous 修飾子とかつけておしまいとか。

>>960
インスタンス化したオブジェクトをコネコネして目的を達成できる。
インターフェイスに着目して、実装から離れたレベルで、
コネコネさせあうことについて集中できる。
思考の中心にオブジェクトが座るようになる。

>>963
そこでMutexとSemaphoreの出番ですよ

というかマルチスレッドとオブジェクト指向って完全に直交した議論のような。

OOすべきプログラミングと非OOすべきプログラムの境界線ってどこらへんなんですか？

あとOOの使用を吟味する意味でも軽くプロトタイプを書いて、本設計するとうまくいくんですかね？

そうはっきり色分けできるもんじゃないとおもうけどな。

現場の人間と話し合え

ThoughtWorksアンソロジーの第5章ってこのスレ的にどうなんでしょう。
なんか第4,第5正規形なノリを想起しました。
setterの不必要な公開はともかく、インスタンス変数2つまでとか理想論な気がします。
顧客情報を表すクラスを考えて、一体どれだけのクラスが必要になるんだろうと。

>>963

　そんなにグローバル変数とか使う事あるか？通常のプラットフォーム向け
じゃまず必要ないし、ドライバ関連でも、グローバル変数とそれにアクセスする
関数だけをファイルスコープで纏めて可能な限り干渉を避るから影響はわずかだぞ。
　関係ないが、staticメンバー関数は使うがstatic変数は殆ど使わん。概ね関数の方は
friendメンバー代わり。staticメンバーを巧く使ってるやつっている？

>>968
メッセージングが必要か否か。
メッセージを送る必要が無ければ、
処理を確定して書けば良い。
まぁ、メッセージを送る必要が
あるってのはそもそもメッセージを送る
対象が不確定である事の裏返しなんだけどな。

OOとはなんぞ？なんて2005年前後までのネタが未だに続いてんだな。

構造化プログラミングも明示されてないしな。そろそろ20年位経つか。

>>975
その倍。４０年は経つよ。

構造化プログラミングが実はただアドレスジャンプ禁止令だということはあまり知られてない(笑)
try catchは異端者

コードでジャンプさせるなっていうだけで、内部的にはアドレスジャンプしまくり

>>977
またでた・・・。

それは構造化定理。
構造化プログラミングとは、モジュール化を支援する、作法、技法、技術、ツールを指すバズワード。

構造化定理が停止性の文脈から出てきたこととか、飼いならされた goto とかも知らないに違いない。

アドレスジャンプ（笑）

>>979
goto禁止令でいいんだろ
ぜってーまちがってねぇよ

真面目に聞くが、アドレスジャンプってなんのことだ。
アドレス指定でないジャンプがあるの？

ないよ
gotoのこと

>>979
>構造化プログラミングとは、
　　　(snip)
>バズワード。
頭おかしいんじゃないのか君は。

大手メーカーも気づいた事実。オブジェクト思考なんかどうでも良いということ。
メンテの容易さ云々語ってらソフト屋のカモにされて終わりだという事実。
開発経費が削減できたケースもほとんど無いし。偶然、低コストで済む内容の
仕事だっただけ。将来的にと語りたがるオブジェクト思考信者様、将来には
もっと画期的な技法が登場していると思いませんか。
そう、いま動けばいい!!　それがエンドユーザの要望なんだから。
以上、国内大手コンピュータメーカ主催のセミナーでの出来事でした。

>>984
それこそ俺の主張であるのだから、反論があるなら具体的にどうぞ。
俺を改心させるだけでなく、このスレを見ている半可通の理解を深めることにもなるのだから、
充分意義のあることだと思うよ。