オブジェクト指向が理解できないPG

うはｗｗｗ低脳ｗｗｗｗうぇｗｗｗうぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

すぐにスレが落ちるだろうが
ここに２をゲットとか言ってみる

お前が理解しているオブジェクト指向を説明してみろ >>1
お前が理解しているオブジェクト指向を説明してみろ >>1
お前が理解しているオブジェクト指向を説明してみろ >>1
お前が理解しているオブジェクト指向を説明してみろ >>1

現実世界をプログラムであらわしたもの、
それがオブジェクト指向プログラミングだ！

我は神なり！我は神なり！我は神なり！我は神なり！我は神なり！我は神なり！我は神なり！
我　IS　GOD！我　IS　GOD！我　IS　GOD！我　IS　GOD！我　IS　GOD！

オブジェ？
全くわかりません。
わかっているなら、ちゃんと教えて下さい。

どうやらこのスレの人々は
Interface Munou extends Afo
しか実装できていないようだ。

住まないが、ガーベッジコレクターを呼んでおいた。回収されろ。
再利用は禁止だから４６４９。

>>1
すごく頭悪そう。

>>6もすごく頭悪そう。クラスの作り方もわかってないようだし、

class Muno : public Afo{
　abstract void boke();
};

を継承してるあ。

まちがえちゃったよ。え〜ん。

class Muno : public Afo{
　virtual void boke() = 0;
};

だった。でも蛇腹にはわからんあ。

�]

俺も理解できてない。

C++をカプセル化にしか使ってないよ。
それだけでも、Cに比べてコードがスッキリしてメンテしやすく、バグが出にくくなるからイイ。

またVIPPERか

theSpokeってどうよ？

>137
お膣毛

>>6
Javaは大文字小文字区別するから、interfaceじゃなきゃ通らなかったような気がするっぽい。
JavaのGCは回収を「促す」ことは出来るが回収命令自体はできないから必ずしも回収される保障は無いんだったと推測してみたりする。
そもそも、interfaceはimplementsでクラスに組み込まない限り、実装すらしていないのだが…。

PGの方々に素でお願いしたいんだが、凝集度の高いコードを書いてください。
ヘッポコい仕様変更で1Mmとか言わないでください。
まっとうそうな顔して「これは無理です」とか言ってっけど、あんたらのメンテナンスが悪いんです。頼みますよ。
苦い顔して販売への説明しなきゃならんのはこっちです。あんたらに説明させてやりたいよホント。

>>16
事情はよく分からんが、
とりあえず日本語勉強しろ。

http://YahooBB218135018056.bbtec.net/
っｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗっうぇうはっｗｗｗ
うはっｗｗｗ
うはっｗｗｗｗｗｗうはっｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗっうぇｗｗｗ

ああそうか、日本語がヘタだっただけか。
とりあえず、コピペコードが蔓延してて、ツマラン仕様変更でも変更とテストの工数がえらいかかってしまう状況でしかも自分が手を出せないだけに腹が立つ、という状況。２ちゃんで日本語勉強することになるとは思わなんだ。

山田ウィルスは健在だね

>>16
メンテナンスの良いコードによって生産性を上げた分は、
そのまんまソフトハウスの利益なんですが、何か。
利益を放棄しろなんて酷いこと言うなよ。

それに、ソースコードを1文字書き換えただけでも、
テストを一通りやらないとマズいことを理解してないのは、発注側としてどうかと。

ちょっと前置きで2点。
・こちら、少しムキになりかけかもしれない
・>>21 ちょっとお互いの認識ずれてるような気が

で、自分が言いたいのは凝集度を上げてメンテナンス性を高くしてください、
ちょっとした仕様変更で「作業工数がかかる。大変だ。」みたいな大騒ぎになるような作り方をしないでください。ってこと。

当然、テストはちゃんとやらなきゃならん。客先に行くもんだしな。
テスト工数は作り方に大幅にはよらず、常にある程度必要でしょ。

でもって、このスレとの絡みは
「オブジェクト指向のひとつの目的って凝集度を高めることでしょ。（理解性の向上とかもあるが）
　そういうのを意識して欲しい」っていう愚痴です

>>22
凝集度？一ステートメントの「意味」の密度を高くてことか？
オブジェクト指向で大事なのはどのように物事を分類しどのような抽象化をするか？ってとこで、
凝集しているかどうかって関係ないんじゃない？

そもそも根本的に、ちょっとした仕様変更でPGが大騒ぎするのは、技術的に困難なわけでなく、
単に組みなおしにたいする拒否反応であることがほとんど。

>>23
> 単に組みなおしにたいする拒否反応であることがほとんど。
そうかも。でも、ちょっとした変更ならたいていエイヤッと引き受けてくれる。
うちは評価のチームが別にいるので評価の仕事はある程度そっちに切り出せるしね

凝集度…については↓こんな説明がされているが…わかりやすいんだろうか？
ttp://www.ogis-ri.co.jp/otc/hiroba/technical/Cohesion_Coupling/Cohesion_Coupling.html

多少批判はあるかもしれないが、自分の言葉で説明すると
・関係あるものが一箇所に書かれている
・関係ないものは別の箇所に切り出されている
の二つが守られているのが高凝集度をもつプログラムだ
23の言う「どのように物事を分類し」ってあたりがオブジェクト指向モデリングでの高凝集度化の作業に当たる

人月の神話によるとオブジェクト指向のメリットはさまざまな要素をワンセットで導入できることだそうだ
方法論ではまとめて語られるけれども、一つ一つの作業にはちゃんとした理由や目的があると思う

http://FLH1Aap137.hyg.mesh.ad.jp/
ｗｗｗｗｗｗうぇｗｗｗうぇｗｗｗうぇｗｗｗ
ｗｗｗ
っうぇうぇｗｗｗ
おｋｗｗｗっｗｗｗｗｗｗｗｗｗｗｗｗ
おｋｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗおｋｗｗｗ

今後、凝集度を議論するときには、
Separation of Concernsの考慮が必要になるだろう

似非or新参VIPPERうざい

( ﾟдﾟ) …

ガーベジコレクションなのか、
カーベージコレクションなのか、どっち？

Garbage Collection

>>29
ガベージコレクションもあるでよ

ガベージ…（ﾟдﾟ）

ガーベジガーベジ考えてたら混乱してきた…
俺の頭をゴミ集めしないと…

cabbage connection

http://n219079028097.netvigator.com/
うはっｗｗｗｗｗｗｗｗｗｗうぇｗｗｗおｋｗｗｗうぇｗｗｗ

うぇｗｗｗｗ
ｗｗｗｗｗｗうはっｗｗｗうはっｗｗｗ

うはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>23
> 単に組みなおしにたいする拒否反応であることがほとんど。

本当にコードがヘボすぎて組み直しが大変な場合もある。
最近見たソースに、
・ インターフェイスや抽象クラス率 5%以下。殆どがconcreteクラス。
しかもインターフェイスは9割がたコンスタンツクラス。
・ シングルトン、staticファクトリ、ユーティリティの嵐。まともなUnitテストなんてとてもできない。
デザインパターンをロクに知らないくせに、何故かシングルトンだけはプロジェクトメンバ全員が
知っている。
・ カプセル化を知らない。シングルトンオブジェクトのpublicメソッド実行したら内部状態が壊れる
なんて罠も。メソッドの呼び方に制約や順序関係があるためそれを守れる人しか呼んでは
いけないらしい。じゃぁpublicにすんなよ。
・ 1メソッド1000行を超えるものがちらほら。3000行超えまで確認。もちろんネストされた if文の嵐。
・ メンバ、ロカール変数はそれぞれクラスの先頭、メソッドの先頭で大量に宣言。
・ findbugsをかけると、バグの嵐。特に「未使用のフィールド」の多さは壮観。
・ System.getProperty("hogehoge.home") を*各*コンポーネントで取得している。
さらに、そのhogehoge.home以下にあるそれぞれのコンポーネント専用定義ファイル
を読みこむ。もちろんファイルが無いとエラー。
・ 上のような処理をしているクラスに同一パッケージ内の全クラスが依存している。
しかもシングルトン。
・ 型という考え方を知らない。Vector、またはHashtableで何でも管理。
composit型のオブジェクトを、そのまま使えばいいのに、1つ1つ取り出してなぜか自分が作ったHashtableに
入れなおさないと気が済まないらしい。
・ オブジェクトの状態数がやたら多い。しかも状態数が増えることでテスト項目も劇的に増えていることに気が
付いていない。

てなのがあった。ちょっとしたバグを調べたら、同じバグが数十個所に点在しているなんてことも。。
ちょっと直すのもえらい大変。とくにテスト。作りが悪すぎて、全部手動テストしなきゃならんのでテストは人海戦術。
要は世の中OOPを理解していないPGってのが本当にいるんだよ。

>>35

おマイがちゃんと技術指導しないからそうなるんだｗ

そうそう。問題があるのを分かっておきながらだんまりなのは問題起こした奴と同罪。

つーかさ・・・

仕様だけ提示されて安く作ってくれ、と言われたらメンテナンス性にコストかけれない。
継続的に機能追加・変更していくので、トータルコストが安くなるように作ってくれ、と言われないと。

すぐれたプログラマは、コストかけなくてもメンテナンス性に優れたコードを書くけどな

>>35
俺、新入社員なんだが今受け継いだコードそんな感じ。
…シングルトンとstaticの嵐でCのコードからの移植かと思った。

新人から突っ込み入るようなんでどうするよこの会社。

…またシングルトンかよｗ

お前はシングルトン以外知らないのかと小一(ｒ

>>36,37

できあがる過程を一緒に築きあげたんならそうだけど、わしは既にできあがった後
にソースを見せられたんだが。。。

> そうそう。問題があるのを分かっておきながらだんまりなのは問題起こした奴と同罪。

さじを投げました。作りなおす以外まともにメンテナンスできないって言ったら、却下されたんだもん。
一応問題点一覧だけレポート書いて逃げました。

>>40
でかい会社ですかね。経験上でかい会社ほどコードが駄目になり、かつ新人が優秀になる
傾向があるんで。

>>42
社員10人ぐらい。
状態持たないstaticメソッドばっかりのクラスに一個だけstaticじゃない
メソッドがあってnew Hoge("foo").hoge();してたり、インターフェースで
抽象化してると見せかけて使う側はべたべたに結合してたり。
意図が読めないし、全体的におんぼろ煙突化と機能的分解でやってられません。

>>43
> 社員10人ぐらい。
意外。
社員10人だと、開発メンバはせいぜい5、6人くらいだよね？
ここ5年ほどJavaを使ってる色々な規模のプロジェクトをスポット的に
支援したけど、その人数で、ひどいコードになってるところは見たこと
ないなぁ。

> 状態持たないstaticメソッドばっかりのクラスに一個だけstaticじゃない
> メソッドがあってnew Hoge("foo").hoge();してたり

後から付け足したにしては変なコードだな。何故そうしているのか意味がわからん。
どこからかコピペしてきたメソッドを1つのクラスに入れてそうなったんかなぁ。

> インターフェースで抽象化してると見せかけて使う側はべたべたに結合してたり。

これは割と落ち入りやすい設計だね。
インターフェイス使っても、実装クラスをnew すると強結合になる。
でもインターフェイスのメソッドだけ使ってるならまだましな方でしょ。newをファクトリとか
リフレクションに移せばいいだけだから。
実装クラスにダウンキャストしてたり、実装クラスにデフォルトコンストラクタが無かったりすると
どうしようも無いけど。

先輩、デザインパターン活用するっていうのはグローバル変数をシングルトンにして
悦に入ることじゃないです。
せめてクラスを構造体として使ってください。配列が主要なデータ構造ってなんか間違ってます。
すいません、生意気言いました。せめてインデックスの定数に名前付けてください。
Vectorとinstanceofはもう見飽きました。多態ってなんですか？
OOとは言いませんから構造化してください。
例外処理っていうのは、全部catch(Exception e){e.printStackTrace();}ってやればよかった
んですね。つーか異常系処理やってください。

なんでこの会社Javaメインなんだろう。Cで書いてもまともにやればこんなに酷くは…

>>44
どうしてなんでしょうね。業務知識や理論研究系の人多いっぽいのも理由の一つかも。

プログラマの書くコードが一番汚くてバグが多かったりする罠

>>45
つかまともかまともじゃないかは言語非依存だろ。

　　　　　　　　　　　　チンパンジーのアイちゃんが「言語非依存」という言葉を覚えました！

>>49
あんたは最近チンパンジーのアイちゃんを知ったみたいだな。

>>48 正解wwww

屑のデタラメ議論飽きた。

Ｋ仲川 <mail:[email protected]>
　　　 <http://www.vector.co.jp/authors/VA007446/> 公式Web
(自作ソフトの公開,Macプログラム講座,テクニカル日誌)

>>51
自明だろ。

is a ではなく have a なのに、
手抜きをしたくて継承を使ってしまふ。

「なぜあなたはjavaでオブジェクト指向開発ができないのか」
って本読んだらよく分かった。
やっぱ馬鹿には絵をいっぱい付けて説明してくれるとありがたいわ。

>>56
そうなのか…
マ板にブラック企業としてスレ立ってる会社の本だったので
敬遠してたのだが…

★★★★チキンゲーム17日目　ＳＭＧ★★★★
http://pc8.2ch.net/test/read.cgi/prog/1083731670/

立ち読みしてみる。

>>57
そうなのか、知らんかった。
その本は本当に超初心者向けだよ。
「結局クラスって何なのさ？継承って何なのさ？」みたいな。
モノクロで字ばっかり書いてある本読むと頭痛がする
俺のような馬鹿にはうってつけだとオモタ。

分からないと思ってる奴は、いつかの時点で自分自身に、
理解を阻む呪いをかけていると思われ。

>>59
「本だけでも何千円かするし、痛い出費だなぁ・・・勉強したところで
定時帰宅出来るわけでも給料上がるわけでもないよなぁ・・・」って呪いを
かけてしまってるんだな・・・・呪いを解く気力も枯れたしそろそろ

DOSからWIN（3.1）のプログラム始めたとき、イベントドリブンが納得できずに随分悩んだ。

>>61
DOSからってことは制御系？
制御系ならイベントドリブンを前提に制御すると死ぬからやめた方がいいよ

おれが前いた会社は、結果オーライなやつが多かった。プログラムなんて
動けばいいだろ。重要なのは業務の流れを理解することだ。みたいな
価値観が支配的だった。右も左も分からない新人は、徐々にこういう考え方に
染まっていき、１年後にはりっぱな結果オーライプログラマのできあがりだ。
だから、既存プログラムのメンテナンスには莫大な金額を見積もる。
やっぱりきちんとした社員教育って必要だな、って思ったよ。

>>15
> >>6
> Javaは大文字小文字区別するから、interfaceじゃなきゃ通らなかったような気がするっぽい。
> JavaのGCは回収を「促す」ことは出来るが回収命令自体はできないから必ずしも回収される保障は無いんだったと推測してみたりする。
NO it isn't.

System.gc();
Reference referece = new SoftReference(GC即時解放対象オブジェクト);

「右も左も分からない」って、「右」が左にあって、「左」が右にあるよね。

>>61
漏れも

>>62
Winが出て来る前はDOSがメジャー
3.1って書いてるんだから理解しろよ
3.1以前のヤツらは全て制御系だったのかぼけ


と、好き放題言ってみるテスト

これからの時代、



　　オブジェクト指向が理解できない奴は



　　プログラマとはみとめるわけにはいかなくなった。



オブジェクト指向を理解できない奴は即クビ！

初めてイベントドリブンを見たときは
「割り込みのように、要因毎の処理へのポインタ持たせりゃいいのに
　なんでこんな非効率的な事すんだろな」とｵﾓﾀ。

>>68
今はその考えは変わったの？

>>68
イベント丼ってなに？

>>62
昔は普通のアプリもDOSだったんだよ。

>>71
俺の周りではDosからやってる人は（アプリ含め）
制御系の仕事している人が多いなぁ…

DOSは好きなようにI/Oポート叩けるしね。

漏れも自作ハードを動かすのはDOSだよ。
Windowsでもやり方はあるんだけど色々と面倒なので。

でももう、普通のアプリは絶対にDOSじゃやらない。

Win3.1で、初めてイベントドリブンな開発をした時、ビルゲイツの奴隷になった気がした。
それまでは、こっちがゲイツに命令していた気分だったのに・・・。

保守

C#でやっと命令してる気分が戻ってきたけどここ１０年ほど最悪だったな

仕方ないよ、ウィンドウシステムをユーザが個別に管理したら、ＧＵＩ落ちまくりだもん。
コールバックまみれでも、不安定なのは同じだと思うけど…

>>73
シェルは使わないのか？
それともcygwinか？
DOSだけによらずUNIXも使わなきゃだめだ

>>74 >>76
やはりそうだな。
しかっしC#がでてもまだまだだな。
またM$に裏切られる可能性は否定できまい。
バージョンアップするたびに斬りすれられ斬りすれられの繰り返し。
バージョンアップするたびにコードを書き直さないと動かない。
これじゃなんのためのオブジェクト指向なのか、といいたくなる。
それがマイクロソフトのやり方だ

m9(＾Д＾)ﾌﾟｷﾞｬｰ

【脳】ヒトは自分がしていることを認識すらしていなくても学習できる
http://news18.2ch.net/test/read.cgi/scienceplus/1122826530/

なんかイベントドリブンを「OSから〜される」みたいに表現する人を時々見るけど、
いったどういう思考回路してるんだろう。
俺にはほとんど理解不能。

はいはいイベントドリブンって言葉を覚えたばかりのオコチャマ乙

しかしよぉ、オブジェクト指向全く理解してない
PGってJ2EEのプロジェクトに放り込まれたりしたら
どうすんだ？
プレゼンテーション層はJSPに全部処理書き込むなどという
最終手段もあるだろうがEJBなんかはどうにもならんのでは。

過疎スレに何の用かしら？

うんこしに来たんだろ

DOSでPCIボードたたく時、どうしてんの？
IOアドレスがわかんないよ...orz

ハゲあたまたたくといい音するよね

そうそう、オブジェクト指向を理解していないと
開発効率が衰えてイライラして
頭ハゲるんだよォォォ！　これ警告ねぃっ！

何この流れ

いまはじめてきたぞ、糞厨

叩かれて凹んで、更に下を見て安心しに来た >>91 がいるスレはここですか？

で、実際にオブジェクト指向を正しく実践している人は
周りにどのくらいいますか？

>>93
って、俺も分らない物を誰が正しく実践してるか判断出来ると思ってんだ？？

VC++ で、MFC のソースに直接変更を加える事が「継承」だと
思ってた人がいます。　背筋が寒くなりました。

>>94
なるほろ。そういうものなんですね。
ってことは、この問題は永遠に闇の中？

でも、せめてOOPの恩恵を実感できるくらいのレベルまでは
自分のものにしてみたいものです。
MFCなどのクラスライブラリ使うレベルを超えるくらいの。。。

有用だと思えるなら、あるものは使う。　当たり前の事。

オブジェクト指向の勉学はじめました。
何が設計書で必須ですか？
クラス図ははずせないと思いますが、あとは何が必要でしょうか？

オブジェクト指向の設計がちゃんとできるようになれば、自ずとわかるよ。
形から入って、形だけで本質がちっとも、という人になるつもりなら別だが。

いまどきオブジェクト指向ができないやつって時代遅れｗｗｗｗｗｗｗｗｗｗｗｗ

Java厨で理解してるやついるのか？

Cなんか捨ててJavaを学べよおまえら

>>101
理解してたら厨て呼ばれんやろ

Ｊａｖａ厨のほうがよっぽどまし。オブジェクト指向を学ぶ気持ちがあるんだから。

無理にオブジェクト指向にしなくてもいいだろ。結構何とかなるよ。

考えるのめんどくさくなるからヤダ

てゆうか、Java使ってるからってオブジェクト指向的設計が出来ているとは言えない。

オブジェクト指向してると何か世の中役に立ちますかぁ！

立つ。

はず

立たねぇよ！Java厨逝ってよしぬるぽ

>>84
どうにもならないでつよ。
役割の決まったクラスを淡々と作るだけだ。
オブジェクト指向が理解できてるとかできてないとかは関係ない。
ただ、クラス設計をした人間が離れるとそのシステムのクラスはボコボコになってるね。
まだ新品のシステムで使ってもないのな。

オブジェクト指向は必須項目だろ。

UMLのちょっと難しめの本とかよんでも全然わかんないんだよね。
あんなのわかる人いるの？

周りでクラス図とか作成してるの見たことある人いますか？
さらに、それを使ってJava組んでいるの見たことある人いますか？

>>115
クラス図とシーケンス図は普通にあるよ。

>>115,116
クラスのネーミングとかへんだったりしない。名前が動詞だったり、
名前にやたらMgrやINFOやCONTROLLERがついているとか。
あとで、メソッド名の動詞と目的語が逆とか？checkというメソッド名が
やたら多いとか。

>>114
オブジェクト指向的思考ができていないから。

オブジェクトに一歩足りないだけの、単なる関数寄せ集めクラスだったりする。
まぁ、最初はそんなもんだ。だんだんクラス設計なり、
プログラミングしているうちにオブジェクトに目覚める時がくるんだよ。

ちょっとまとまったコンポーネントを任されるとかして経験しないと、
もまいらにオブジェクト指向は永遠に無理じゃね。

今のＪ２ＥＥで構築している銀行さんのシステムだって単なる関数集めのオブジェクトもどき。
つか、それすら崩れるとはどーゆうことだ＞＞プロパのリーダ

>>114
日本人でわかってる人なんていないに等しいと思う。
わかってると思ってる人は勘違いか受け売りだから心配するな。

できれば理解したいんだけど、「きちんと書いた本」っていうのが見あたらないんだよね…
だから『オブジェクト脳の作り方』(略してオブ脳だっけ？)みたいな駄本が新人君に受け継がれていく…

ブーチ氏の論文とか進められても入手できる環境にいないよ…

>>119
>オブジェクトに一歩足りないだけの、単なる関数寄せ集めクラスだったりする。
論外。
それの何処が「一歩足りないだけ」なんだよ。

オブジェクト指向啓蒙本がたくさん売れているのに、
こんなにオブジェクト指向出来ていない人ばかりだなんて、
あんな高い本買っても、みなさんは読んでいないのですか？

よぉーし、こうなったら折れは今月中にオブジェクト指向を
ものにしてやるぜい！みんな待ってろよ！！！

>>123
才能は本を読んで身に付ける物ではないからなぁ…

　なんだかんだいって、smalltalkのソースを貪るが早いと思う。

Javaの最大の失敗は、アプリソース付き開発環境がなかった事だ
と思う。

5 ：デフォルトの名無しさん ：2005/10/18(火) 11:50:41
手続き型のイメージ:彼女の口を開けて、ちんぽを口につっこむ
OOのイメージ:彼女に「しゃぶれ」という

...もっとも彼女が生成できないのでぬるぽ

6 ：デフォルトの名無しさん ：2005/10/18(火) 14:59:42
↑わかりやすい

7 ：デフォルトの名無しさん ：2005/10/20(木) 01:00:00
彼女という女性の派生クラスが世界には存在するらしく、実際に彼女のインスタンスを取得できている知人もいるが
神様が書いたコードが絡まってるのか俺は未だに彼女のインスタンスを取得できない。
どうしたものか…

うわ、インスタンス生成に失敗するのをメモリーのせいにしたいんだね。
本当は不正なパラメータ呼び出しをキャンセルする仕組みなのに…

メモリーの精?

はいはい

Java使いが、関数の寄せ集めクラスを作るのは、

クラスに属さない関数を認めていないJavaの言語仕様

に少し原因があると思う。


理想としては、クラスに属さない関数はありえないのだけど、
誰もが理想どおりにクラス設計できるわけではないので。

え〜？
クラスって関数の寄せ集め以外になにがあるってゆーの？

寄せ集め方に法則があるのがクラス
思いつくまま何でもかんでもぶっ込んでるのがおまえら。

クラスってDUPみたいな感じだろ？

根本的に考え方がチープな人がちらほら見られますね。

>チープ

青い海...orz

オブジェクト指向は理解するものではない
はじめから身についているものだ

そんな事はない

思い出せないだけさ。心配するな。

クラスってほちゃ？
オブジェクトってゆかりん？
まとめると、オブジェクト指向＝やまなこ？

なにいうてはるんどすか、このおひと？

声優ｵﾀぽ

>>140
進藤尚美乙。

オブジェクト指向っていったらＯＣＰだな。
これを理解すればオブジェクト指向を理解できる。

Ｏ ： おまんこ
Ｃ ： ちんちん
Ｐ ： ぱいおつ

童貞丸出しだな。

Pはパンツだろ

ちょっとおしい

Ｏ ： おれの
Ｃ ： ちんこは
Ｐ ： ピンクだ

童貞の場合

童貞だって黒いよ。いじるし。

結婚して１０年。
普通にやってるのに、まだ赤いのはなぜ？

クラス属性使ってる人っている？

アニヲタ属性のやつは多いけど

>>150
さては、むけてないな。

ヒント：通常の3倍

オブジェクト指向って結局楽するための概念でしょ？
ということは別に楽しようと思わなかったら、そんな勉強しなくていいってことだろ

155の せきが まどがわ になった。

オブジェクト指向って、個人でフリーソフト作るぐらいじゃ別に要らないでしょ？

糞ソフトしか作れないやつには要らないだろうなたしかにｗ

みんな、クラス属性の意味がわからないに一票。

ちなみにOCPは
Ｏ：Open
Ｃ：Closed
Ｐ：Principle
の略な。
これをわかってないやつは本当のオブジェクト指向知らない奴だ。

業務開発にオブジェクト指向なんかイラネ

あれは高度な開発向けの手法ｗ

>>161
気持ちわかるが、いつまでも体力仕事ばかりじゃ辛いっす。

>>162
はあ？業務開発ではオブジェクト指向開発のほうが
工数がかかるのは常識だが？

実戦経験ないのか　もまえ　情報収集なら情報収集と
いえよ　すなおに教えてくれるから

>>162
なおさらだが体力勝負云々を語るのなら
オブジェクト指向とか一設計手法で解決できる問題ではない

もっと開発工法とかプロジェクト開発手法を総合的にリマネジメント
してゆかなければいけない。

なにがいいたいんだｗ

オブジェクト指向が理解できない奴は
代数学も理解できないだろう。

代数学が理解できない奴とオブジェクト指向が
理解できない奴には共通点がある。

彼らには共通して目に見えない世界、日常生活に
存在しない世界をn次元ベクトル空間に置き換える抽象化
という能力を持つことができないのだ。

置き換えることも喩えることもできない
つまりオブジェクト指向を理解できず否定するばかどもは
「メタファー」を理解できないのだ。

それから、オブジェクト指向を理解できず否定するバカどもは
メタフィジックス(形而上学)を理解できないのだ。

つまりあのバカ共は代数学は愚か、宇宙物理学すら理解できないのだ。
宇宙論といってもやつらには理解できないのだ。

超平面、超空間というものが奴らには理解できないのだ

>>15
> >>6
> Javaは大文字小文字区別するから、interfaceじゃなきゃ通らなかったような気がするっぽい。
> JavaのGCは回収を「促す」ことは出来るが回収命令自体はできないから必ずしも回収される保障は無いんだったと推測してみたりする。
> そもそも、interfaceはimplementsでクラスに組み込まない限り、実装すらしていないのだが…。

java.lang.ref.Referenceを使って
オブジェクトの到達可能性レベルを変えれば回収を促すレベルを変えることができるぞ

頭で理解するんじゃない。体で感じるんだ。

>>161
そんな事言ってないで、モジュールぐらい自由に作らせてくださいよ。
品質管理さん。

オブジェクト指向という概念は、理系バカにはわからないのさ

>>169
精神的に問題ない方ですか？

インスタンスとか意識するなら、オブジェクト指向は必然的に
マスターしたほうがいいような気がする。

だからCなど捨ててはやくJavaやれよ

Javaをやったからと言って
オブジェクト指向そのものをマスターしたとは言えないしなぁ。

ていうか、オブジェクト指向を理解もして無いﾔｼが、
挫折した腹いせに「OOPは無駄」とか必死に言ってるのがｱﾜﾚｽ。

ていうか、構造化を理解もして無いﾔｼが、
挫折した腹いせに必死に言ってるのがｱﾜﾚｽ。

皆様にお聞きしたいのだが、
プロジェクトリーダーまたはアーキテクトとして
オブジェクト指向を積極的に活用して設計しているよって人はいますか？

いたらなんなんだ禿

>>177
オブジェクト指向が有効になってくるプロジェクト規模の臨界ってどのくらい？

> オブジェクト指向を積極的に活用して設計しているよって人はいますか？
メンバーのレベルによりけり
今は（私以外の）メンバーが優秀＆金持ちPJなんで、
じっくりことことやれますがな。

>>178
規模は関係ない。
馬鹿が多いか少ないかだけ。

>>179
>今は（私以外の）メンバーが優秀＆金持ちPJなんで
確かにそういう条件なら将来の拡張性に投資したくなるでしょうね。

今私がやってるプロジェクトは新人より役に立たない部下１人と
やる気があるのかないのかわかんない下請けから出向１人の計３人です。

２週間前のミーティングはいつの間にか Effective C++ のおさらい、
１週間前のミーティングは 3DCG 基礎の基礎、になってました。

愚痴ってすいません・・・

>>180
再利用を意識してデザインパターンを駆使して凝った設計をして、
結局無駄に複雑な設計のせいで読みにくいソースになっただけ
という経験はないのですか？

>>182
だから、無駄に複雑な設計をするような馬鹿が多いところじゃ使えないという意味で言ったんだが。

>>183
システムのどの部分に拡張性が求められるか、
完璧に予測することができる人間なんてまずいませんよね。

で、私の経験では１０人月程度までの規模であれば
将来の拡張性を考慮するよりも今求められている機能を
そのまま端的に設計に反映させたほうが有効だと思いました。

その逆に６０００人月超（１回しか経験ないですが）だと
まずプロジェクト用のクラスライブラリを十分練りこむ必要があったのを
見切り発車したのが失敗の原因でした。

それで簡明さと将来的な拡張性、どちらを選ぶか迷ったときの指針として
プロジェクト規模で判断するのが妥当なのかなと思いました。

>その逆に６０００人月超（１回しか経験ないですが）だと
６００人月のまちげーです、ゆるしてくだせえ。

>>184
規模と拡張性はそれほど関係ないだろ。
数千人月の銀行勘定系と、数人で作るゲームとどっちが機能拡張の頻度が高いと思う？

>>186
数人で作るゲームだと継承だの何だのとごちゃごちゃ仕組むより
直接コードいじったほうが効率よかったりすると、実感として思う。

>数千人月の銀行勘定系
扱ったことないのでよくわかりませんが、そもそもそれは拡張性を期待されているシステムなのですか。

なんか話がかみ合ってないんだが・・

>>187
> >>186
> 数人で作るゲームだと継承だの何だのとごちゃごちゃ仕組むより
> 直接コードいじったほうが効率よかったりすると、実感として思う。

ＯＯＰ＝継承って思ってる？
「直接コードいじる」っていうのはどういう意味だ？

> >数千人月の銀行勘定系
> 扱ったことないのでよくわかりませんが、そもそもそれは拡張性を期待されているシステムなのですか。

だから規模と拡張性はあまり関係ないだろ？と言ってるんだが。
「規模で判断するのが妥当なのかな」と言ったのはそっちじゃないの？

>>188
>ＯＯＰ＝継承って思ってる？
さすがにそれはないです。

>「直接コードいじる」っていうのはどういう意味だ？
元クラスのコードを直接修正するってことです。

>だから規模と拡張性はあまり関係ないだろ？と言ってるんだが。
今必要な機能を早急に実装するメリットと将来的に有用な拡張性と、
はかりにかけて悩むことってないですか？

そういう場合にプロジェクト規模で判断するって言う方針の是非を伺いたいです。
根拠としては、小規模プロジェクトでは拡張性無視のほうが経験上有利だったということで。

YAGNI

>>189
> 今必要な機能を早急に実装するメリットと将来的に有用な拡張性と、
> はかりにかけて悩むことってないですか？

別に二者択一の問題じゃないだろうと。
大規模だろうと小規模だろうと、対象をモデリング化してクラスを抽出して・・という作業は
同じでいいだろ？
規模に応じてそれぞれの工程に掛ける時間が変わるだけのこと。


まさか、一週間で全部作って、その後の機能拡張は一切なしとかいう条件の話をしてる
わけじゃないよな？

>>190
それで痛いめに会ったもんでね。

>>189
その拡張性を無視した既存のアプリケーションから、フレームワークを抽出
できないか？と、考えてみた事はない？
仮に、上手く抽出できたなら、今度はそのフレームワークを拡張するという
方向で考えてみる。再利用性は本当にないのかな？
既存のアプリケーション→フレームワークの抽出→フレームワークの拡張
→フレームワークの利用、これ即ち再利用だよな？

まぁ、完全に野放図なコーディングを行うと、依存関係が複雑で再利用性以
前に保守性皆無という可能性もあるが・・・・・・
一般的な保守性を得る為に、簡素なコード、単純な依存関係、テストとドキ
ュメントの付加、そして定期的なリファクタリングなんかを行ってれば、再利
用性や拡張性は後から付いてくるもんだと思うけどな。
ちょっと指先で弾いてるんで会話を重ねると意見変っちゃうかも？だけどｗ

世の中、そんなに甘いものではない。

オブジェクト指向って、現実社会をシュミレートする考え方から来ているから、
わかりやすいものかと思ってたけど、なんか違うみたい？
わかんない、複雑、無駄、無意味、とか言ってる人は、単に挫折した人？
いや、本当にわからないので、気に触ったらｺﾞﾒﾝｿｽ。

オブジェクト指向で!
なんてことを言うようなプロジェクトリーダーに、ろくなのはいない。

そういうのに限って、無駄に仰々しい設計をさせるからムカつく。
それでもって、仕様変更を重ねてクラスの再設計をしなきゃならない時に、
オブジェクト指向なのに既存のクラスを再設計するとはいかに?
お前の設計が良くなかったから変更が必要なのではないか?
とかいって無駄に説教して時間を食われる。無駄な時間を過ごした分、睡眠時間が減るのに。

>>196
そりゃお前の属してるレベルが低すぎるだけ。
一般論みたいに言うのはおかしいし、オブジェクト指向そのものの優劣とも関係ない。

汎用性が高いクラスなら、
自分たちで作らなくても、
いくらでも既存のものがあるわけで。

それで思い出したのだけど、
あるプロジェクトでは、プロジェクトリーダー自作のライブラリを使わさせられたのだが、
MFCもどきとSTLもどきだった。

なぜMFCやSTLを使わないのか聞いたら、
色々とバグがあるし、それくらい自分で作れるようになれと、また説教。
しかもコピペ大好き人間らしく、似たようなコードがあちこちにある。

>>197
レベルが低いからこそ、
「オブジェクト指向で」
なんていう発言が出るのですよ。

普通なら、そんなのは当たり前で、いちいち言うようなことじゃない。

> 193にも
> 194にも
禿同。現場にはこの二つの意見がいつも付きまといません？
だからみんな悩んでるわけだが…
> その拡張性を無視した既存のアプリケーションから、フレームワークを抽出
> できないか？と、考えてみた事はない？
これは（多分）みんなやっている。でも、
> 仮に、上手く抽出できたなら
できない、結果的にできていない事があるわけで。
このギャップを皆さんはどう埋めているのか…
が大事なんじゃないですか。
ちなみにうちはどんな段階でも（本番稼動後でも）力技でフレーム再構築に
着手してしまいます。死にそうです。責任取れません。

> 196さんは論点がずれてますぜ。
ただの愚痴なんだから聞き逃してあげようや。

こんだけ盛り上がっても、OOPそのものを語る人はひとりもいないんだな。
まあそうだろうな。

誰も正面から語れないからか？

OOPはスローガンみたいなもの
実体は個々の概念の寄せ集め
そしてその個々は常に入れ替わってる

そうやってｵﾏｲﾗが管巻いてるうちに、
ｵﾚはOOP開発をﾏｽﾀｰするかな。

なにこのウンコスレ

トイレでうんこして流して出てくるまでをオブジェクト指向設計すると
人間とウンコとトイレがオブジェクトになると思うんだけど
うんこは誰の持ち物で解放責任は誰がもつの？
人間からトイレに持ち主が変わるんだと思うけど解放忘れが発生しそうでちょっと怖い

視点を変えて人間をウンコファクトリーと捉えるほうがいいのかな

ウンコの解放忘れるとすごく恥ずかしいよね

人間が生成してトイレが解放するに決まってんじゃん。
ウンコした後、人間が確実に流しさえすれば問題ない。
流し忘れても次の人間が流せばこれまた問題ない。
ただし、誰も流さないという有り得ない状況が発生する
と、逆流してだいあｓｄふぁasf

じゃあ勝手に流してくれるのがいいんだよ
実際はそうじゃあない。

>>201
君も含めてね。
だが今更何を語ろうってんだ？
ﾈﾀあるなら出してよ。

あんまりきれいにモデリングしてもさ、
そのきれいな状態を維持するのは大変よ。

仕様変更があった時に、ごっそり作り直しになるかもしれないのよ。

仕様変更があったときにごっそり作り直しになるようなのは
「きれいなモデリング」じゃないだろ。

汚いウンコか

うんこをくそ真面目に語ってるお前ら萌え

スレの題通り、ここには、オブジェクト指向を理解できないヤツしか集まってないっすね。
安心した。

経験4年でVBとCしかやったこと無いけど、OOPを理解するには
何がいい？

Borland C++　 Builder6ならあるんだけど。

OOP関係の市販本は、コーディングサンプルにJavaをよく使ってる。
C++のOOP関係の市販本は見たことない。
C++もOOP言語なのになぜ？

>>217
C++の椰子はデフォルトで理解している
Java厨は本読んでも理解できない
の違い

>>218
C++もJavaも現場で使うが
どっちもオブジェクト指向なんかつかわねえしさ
手間かかるだけで　うざいだけ

客の評価じゃ　短時間で開発したほうが評価されるしさ
メリットもないし　オブジェクト指向

現状どんな使用メリットあるの？　
えらそうにしてんだから　教えて

オブジェクト指向ができないやつはオチコボレ

>>220
そう言われると反論したくなるが、社内でオブジェクト指向を語れる奴は
一目置かれてるからな。俺もがんばろ。

>>221
はあ？
ちょおまｗｗｗｗ
メリットもデメリットも把握せずに
他人に推奨してるわけ？

ひどすぎｗ宗教じゃあるまいしｗ

>>220
ミドルウェア組むとか
ＯＳ作るとかそおいう高度な仕事やってる時点で
勝ち組だろｗ　オブジェクト指向有無の問題じゃねえさ

一般のＰＧはオブジェクト指向なんかつかいませんｗ

IT技術者が最先端技術を追いかけられなくなったら、お・し・ま・い

>>224
最先端技術＝現場必要なスキルではない
趣味じゃねえんだぞ　ちょおまえｗ
素人か？

現場で必要な現場の最先端技術をすばやく理解し
仕事を難なくこなすのがＩＴ技術者だよ

お宅じゃねえんだぞｗ

60過ぎても最先端で仕事が出来たら、それはそれでかっこいいかも。
65ぐらいまで現役で出来ないものかな。

>一般のＰＧはオブジェクト指向なんかつかいませんｗ

使うのは高級なPGだから？

でもやっぱり、オブジェクト指向なんてｸｿ、って言ってる人は、
理解できない劣等感を永遠に背負っていくんだろうな、と思ふ。

劣等感ねぇ。感じないなぁ。業務遂行に必須でない概念を理解する暇がないからといって
なんで劣等感なんぞ感じなければならないの？
#業務遂行に必須になったなら、なおさら劣等感なんぞ感じる暇がなくなるわな。

やっぱ、オブジェクト指向が理解できないPGの集まりのスレだすな。

>>217
>C++のOOP関係の市販本は見たことない。
はあ、そうですか。
君が何故 C++ から目を背けるのか、なんて
他人に判る訳がないと思いませんか？

そうやって暇が無いと言っておきながら、
簡単に反応しちゃうところが劣等感なんだよ。
自分で気づいていないだけだよ。

オブジェクト指向理解できなくても、分数の計算ができなくても、
日本の首都がどこか知らなくても、新聞の漢字が読めなくても、
業務ドカタとしては通用するってこったなｗ

>>229
>>228 をもう一度よく読みましょう。
「OO を揶揄する」→「劣等感を持っている」
と言ってるんであって、必要がないから
理解しようとしないんだ、というﾚｽは的を外しています。
それとも、あなたも「知りもしないものを揶揄」してるんですか？

OOP理解してないけど、業務土方を抜けるためOOPを理解しなくちゃな。

OOPマスターしたらどうなんの？生産性あがるの？
それってどれぐらい？そんなことより言語をPythonに変えたほうが生産性あがらない？
マスターするまでの時間は回収できるの？出来るとしてどれくらいの期間で？

>>236
能力による。

>>236
薀蓄本(コードを晒さず例え話を主体にした読み物)に書かれてる様
なOOPに実体はないよ。
実務の現場に存在するのは、保守性、拡張性、再利用性に対する
経験則とそれを編纂した成果物だけ。
〜性なんて考えた事もないよ？って言うなら、それ自分自身がそう
いう場所に居るというだけ。

まぁ、あれだ。
勉強だけが全てじゃないってのを、東大に入ってから言ってみたいというのと一緒。

劣等感丸出し低脳PGって哀れだな

>>238
蒸気機関を発明してから150年の機械工学とか
古代ローマから連綿と続いている建築と比べるのもなんだけど…

この業界、エンジニアリングとしてはまだまだ未成熟なだけだから
あと30年もすれば経験則なんて言葉で括っているノウハウも
知識として体系化されるんじゃないかな？
…まぁ、その頃、このスレの住人は誰も現場にいないわけだが。

技術を伝承する暇も無く、次の技術が開発される。

OOPを使ってるいるとこは、大手ITの中央組織だけだよ。
安心しろ。

誰だ！
音声認識して自動ソース生成してくれる日が
すぐにやってくるなんて言ったのは！！

そうやってみんなが管巻いてる間に、折れだけOOPマスターしちゃおっと。

>>241
いや、30年待つまでもなく、今既にされ始めてると思うんだが・・・・・・
実装技術のパターンやリファクタリングから、開発手法のXPやTDDまで
どれも書籍化され体系化されてるし、最近は素人だってそれらについて
多くの事を知ってる。
もし文字通りの経験則で、実務の中でのみ伝承されていく様な類のもの
なら、そんな事は起こり得ない。

そうだな、OOPを単純に「ノウハウ」と置き換えてみればいい。
例えば>>236の文章はこうなる。
>「ノウハウ」マスターしたらどうなんの？生産性あがるの？
>それってどれぐらい？そんなことより言語をPythonに変えたほうが生産
>性あがらない？マスターするまでの時間は回収できるの？出来るとして
>どれくらいの期間で？
凄く変な文章になるでしょ？他のレスについても試してみて、奇異で滑稽
に見えるから。OOPに実体がないとはこういうこと。OOPを否定してるのと
は違う。

>>246
そうだよね

OOP自体も考え方がドンドン変わってきている
当初は実装の継承がメインだったけど、今や見る影も無い
「ノウハウ」って言葉がピッタリ

>技術を伝承する暇も無く、次の技術が開発される。
刑事のセカイは現場百回だけど、技術のセカイは基礎百万回だ！
テクノロジーの原始的で基本的な部分を押さえた上での目を養うこと
上っ面の技術に躍らされないで、本質を見抜ければ、恐れる事は何も無い
…と偉そうな事をいてみる

>>241
>いや、30年待つまでもなく、今既にされ始めてると思うんだが・・・・・・
成熟には程遠いよ。それだけ。

OOP自体は、これから長くソフトウェア産業の基礎的な知識として伝えられていくのは間違いないね。
木材を加工して歯車作るのも、鉄を溶かして汽車を作るのも、部品を作って、組みたてりゃーいいって言う所までは同じだから

246のバカ発言に何も知らないアホ247が納得しちゃってるよ
いいのか日本のプログラマ

>>249
部族伝承とパラダイムシフトの区別から説明するのは
とても大変だから放置

基礎百万回という言葉に何となく萌える。
確かに、先輩も本質がどうのと言っていたな。

>>236 は
>言語をPythonに変えたほうが
この時点でﾈﾀ確定だろう。

246と247のやり取り面白いね。

>246
そうだな、OOPを単純に「北斗神拳」と置き換えてみればいい。
例えば>>236の文章はこうなる。
>「北斗神拳」マスターしたらどうなんの？生産性あがるの？
>それってどれぐらい？そんなことより言語をPythonに変えたほうが生産
>性あがらない？マスターするまでの時間は回収できるの？出来るとして
>どれくらいの期間で？
凄く変な文章になるでしょ？他のレスについても試してみて、奇異で滑稽
に見えるから。OOPに実体がないとはこういうこと。OOPを否定してるのと
は違う。

>247
そうだよね

OOP自体も考え方がドンドン変わってきている
当初は実装の継承がメインだったけど、今や見る影も無い
「北斗神拳」って言葉がピッタリ

南斗なんて
馬の骨でも習ってたりするくせに
極星だけは北斗より厳しい一子相伝なんだぜ

北斗神拳マスターしたらＰＧなんか辞めるよ。

>>249
「クラシック」なOOPと「モダン」なOOPの区別した方が良いよ

クラシックなOOPはJava
モダンなOOPはVB

MSのほうが先見性があったわけだ
怪我の功名だろうけど

それは、考え方の問題であって
言語の問題は少ないと思うが

新しいことが覚えられなくなったらお・し・ま・い

UMLとか勉強したほうが良いﾃﾞｽｶ？

>>260
君がマスターした頃には違うものがブームになってるかもな

鳴り物入りで登場した「革新的な」手法が、次々に陳腐化していく現実。

それに振り回されるのは馬鹿らしい。

一時期あれだけどこの雑誌でも取り上げられていた「デザインパターン」
って、気にもしなくなるほど完全に定着したのか？

定着してる。
元々、一般的に使われてた慣用法に名前を付けて体系化しただけ
なんだから、寧ろ一昔前の騒がれようが異常だっただけ。

じゃあ、デザインパターンが登場する遥か以前からある
オブジェクト指向も、完全に定着していてもおかしくない
のにね。

「元々一般的に使われてた慣用法」の中に、オブジェクト
指向を用いたものが含まれていないはずは無いような・・・

デザインパターンが一般化というより、デザインパターンを読んで理解することが難しい。
ソースも一緒に対比して欲しい。

>デザインパターンを読んで理解することが難しい。

そんなものが定着してるとは思えませんね。

>>264
OOPの定義が曖昧すぎて解釈に幅がある。
曖昧なものが定着したか否かなんて、少なくとも俺には断言できない。
OOPを、保守性、拡張性、再利用性の為の各種ノウハウの総称と考え
るなら、既に定着してるとも言える(ただ、これで完成というのはないか
ら、何をもって定着とするのかイマイチ曖昧だが…)。

デザパタに話戻すと、例えばCで条件分岐を関数ポインタを返す関数
に置き換えた経験はあるんじゃない？
他にも、複雑で多機能なAPIを使う時、常用する呼び出し順を関数化し
ておいて、可変部分をコールバックで実装したりとか？
リンクドリストに関数ポインタを登録しておいて、順番に呼び出すとか？
どれも大して目新しくない。

OOPL使えばなんだってOOPなのだよ。
とてもそうは認められない例は沢山あるけど。
「どこからがOOPなのか」という線引きが出来ていない以上、
「OOPL使えばなんだってOOP」という線引きで充分だｗ
誰か別の線引きを提示するかい？

　オブジェクト指向も乱暴にいえば、７０年代の
抽象データタイプに継承をつけただけだし。

なんかむずかしいでつよ。

＞＞２６９
それ、かなり乱暴です

モジュール化と何かちがうの？

アクターモデルの並列処理をするはずの
オブジェクト指向プログラミングが、
規模の問題解決を目指した構造化プログラミングと
同列に語られている以上理解出来る訳無い。

モジュール化は単なる「手続きの整理」にすぎないからなー。

>>273
>アクターモデルの並列処理をするはず
それは並列オブジェクト指向であって
OOP とは関係ありませんね。

主語

季語

クラスの候補を洗い出したあと、次にやるのは
関連の洗い出しと操作の洗い出し、
どちらが定番なのでしょうか？

操作
っつーか振る舞い、が先だ

classや関数で、骸骨または木人形を、遠くに作っておいて、
new呪文で召還＆実体化させるの？

今一良く分からん…

>>280
クラスは定義だから、おまえさんの言う想定でそこそこあってんじゃね？

クラスは作成したゴーレムの機能などを記述したものだ。
たとえば戦闘用なら、武装も持たせなきゃいかんし、
武器を使う方法も能力の一部だろ。
移動能力も必要だろうし、指示を出して従わせるなら、
指示を理解する能力も必要なわけだ。

newはクラスのインスタンスを作成する。
この場合、上のゴーレムを呼びだそうとすると、
一体のゴーレムの「クラス」から、何体でも召還できるってことだ。
「このクラスからは一つしか呼び出せない」と自分で書かない限り、
一つクラスで定義すれば、newするたびにゴーレムが呼びだされる。
それぞれは別個で、定義通りに活動するが、
相互に関連する機能を持たせない限り、他のゴーレムとは無関係に動くことになる。

>>280
それはOOPじゃなくて言語仕様でしょ。
そのレベルなら、理解もなにも無いと思うが。

>>282
あの段階で躓いていたら、
一般人か、ﾌﾟﾛｸﾞﾗﾏと呼べないレベルの人たちってことだろ。

>>283
そういう言い方をするからPGは嫌われる。

>>284
「PGの外」からの卑屈なご意見、有難うございます。

>>280
いまいち良く分からないとか言ってるわりには、あなた理解してるんじゃないの？
良く見たら面白い例えだ。

変な例え方するから、余計に混乱するアホが出てくるのに。

元々、喩えの目的ってのは
　　1. 相手に解ったと思わせる
　　2. 自分が解った気になる
　　3. 揶揄する
のどれかなわけで。

聖書に対する侮辱だ
こんな所で特定の宗教に対する攻撃を目にするとはｗ

>>289
ん？聖書ってキリスト凶？くだらないね。

そもそも関数じゃ無くて、
わざわざオブジェクト(継承物？)にして何のメリットがあるん？
継承元のプログラムはどこに置けばいいん？

マルチスレッドで使うならﾜｶﾗﾝ事もないが。
今一何の為に使うのかがワカラン

文型用のパラダイムだからな。規模がでかくなっても相変わらずわかりやすいってのがメリット。

オブジェクト指向ができないやつって、整理整頓が下手で部屋が散らかってそう・・・・

個人的な一つの結論としては
誰かマトモな洋書一つ掘り起こして邦訳して出版だな
Ｃ言語の決定版Ｋ＆Ｒが18万部って聞いたから
誰もが進めるモノを用意できるなら
10万部はねらえる。
どっかの助教授とか、拝金主義でかまわんのでやる気無い？

まぁ…。あるかどうかも一つの問題なんだけど
昔読んだ本では、現在の所存在しなくて、あるとしたらブーチ氏の論文くらいだ
って言っていた…
http://www.7andy.jp/books/detail?accd=19713779
まぁ、ココから９年経っているから期待も出来るんだけど

正直、むっちゃくちゃ散らかってる。
棚が足りないが置く場所もねぇorz

>>291
なんでそこでマルチスレッドが出てくるのかがワカラン。

基本的な設計すらできないやつの意見だな・・・ >>291

>>291
オブジェクト指向がわかってないのなら黙ってたほうがいいよ。
ﾚｽ読んで、こっちが赤面しちまったよ。

セキュリティ対策のためにC言語厨/C++厨に対する　！警告！

●プリプロセッサを使用禁止しろ！
●定数は必ずconstで押さえろ！
●不変クラスにする必要があるものはできるかぎり不変クラスにしろ！
●実装メソッドがあるクラスの多重継承を禁止しろ！
●グローバル変数、グローバル関数を使用禁止にしろ！
●構造体、共用体の使用を禁止しろ！
●関数ポインタの使用を禁止しろ！
●演算子オーバーロードを使うな！
●typedef使用禁止！
●もしこれらの鉄則を遵守しなければC++厨もC言語厨も
このソフトウェア業界から出て行け！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
さもなければ、氏ねｪｪｪｪｪｪｪｪｪｪｪｪｪｪｪｪーーーーーーーーーーーーーーーーーーーーーーーーィ！！！！！
ﾌﾞｼｭｯ！　ｸﾞｻﾞｧｯ! ｸﾞｳｫｧ！(C言語厨、C++厨が切り刻まれる効果音)
「うぐぁぁぁぁ！だずげでぐれぇぇぇぇ！がぁぁぁ！…ぐぶっ………」(C言語厨、C++厨が死ぬ直前に発する最後の断末魔)

ここはプログラマの雑談板であって
子供の遊び場ではないのだが

ほっとけ

>>301
本人にとっては「遊び」なんかじゃないのでは？
なんだか必死だし。

>>300
Cでそれを矛盾なく守るのは無理ではないか？

C厨って必死になっててもふざけてるように見えるねｗ

>>304

うーん、構造体とグローバル変数を使わないCプログラムって
状態の保存がちと辛いようなきがするよね

C++では言っていることわからんでもないけど。




といってみたが、Borland系しかCとC++と使ったことがないオレはお馬鹿なだけかもしれん

オブジェクト指向設計を細かくやっていけば、そのままプログラムになるはずだから、
ＰＧなど要らないのだよ。ＳＥがむばれ！

>>307
クラス図書いてパブリックメソッド書いて、
メソッドの動作内容をメモに書いていたら・・・・・・
ほとんどコーディングじゃんと先日思った。ツールでスケルトンまでメモ付きで一気に作られるし。
＃どこまで設計すればいいんだろとちょっと悩みながら月曜日0.5版提出の概要設計書のツメやってます。

>>300
>「うぐぁぁぁぁ！だずげでぐれぇぇぇぇ！がぁぁぁ！…ぐぶっ………」(C言語厨、
>C++厨が死ぬ直前に発する最後の断末魔)

おまいは小学生かｗ

>>308
そもそもコーディングっていうのは動作設計書を書いている事なのだから当然と言えば当然
部分設計と全体設計が違う言語って言うのがそもそもの問題に見えるね

>1は正しい。

>>310
問題もあれば利点もあるから、使い分けられていろのだよ。

>>310
たしかに言わんとしていることは判る気がする。

オブジェクト指向ってなに？のPGも使わないと行けない立場なんで、悪い意味で丁寧すぎるかもしれない。
このスレの本題でもあるけど、PGにUMLとか図で設計書書いて動きとかこういういみだよ〜っていいつづければ
けっこうオブジェクト指向って判ってくれると思う。すくなくともクラスってなに？ってぐらいは。

それで全て解決とはおもっちゃいないけどね。

本当は上がってきた数学の基礎が全然違うのが問題の一つだよね
集合論から来たオブジェクト指向と
チューリングマシンをアイデアの元にしている現在の(ほとんどの)言語
でも、データフローダイアグラムの上では、両方とも綺麗に融合できているんだから

実は現存するプログラミング言語が一様にクソって事なだけに俺は見えるんだけど…

自分だって日常的に口からクソ垂れてるくせに

強い電波（ｒｙ

[1]
　「このシステムは　こんな形をしている！」

と、仕様が固まって、それに基づいて「効率的な」デザインすると、

　　効率的とは、特化して解決方法をスリムに

することなので　仕様変更時に　その「効率的」な部分だけが
そのまま「余計な事をしてくれた」ことに終わる。

これをもって「世の中は上手いこといかない」という説法が出てくる。


たまたまＯＯＰさんはその被害現場の近くを歩いて見ていたので、
容疑者としてＯＯＰさんが報道されてしまう。

sage凡ミス・・・、夜更かしするとこんなことをしている・・・。

[2]
　システムエンジニアのＡさん
　　「クラスの継承とかデザインパターンとか　どうでもいい。
　　　手を早く。動く物が欲しい。お客様を満足させることが優先です」

　プログラマのＢさん
　　「システムの勘所を掴んで　プログラマらしく効率のよい方法を考えると、
　　　引き継ぎ保守が仕事の８０％と心得、メンテナンスが短く稼働時間を伸ばすよう作るのが
　　　目的に合うと思って　制作を進めようとしたのですが
　　　『拡張性は重要ですが！』『凝るほどの物でもありませんから！』
　　　『簡単に作ってください！』『メンテナンスをどうするかは私が決めることです！』
　　　と何か身に覚えのない指摘というか断定を受けて
　　　１つのクラスに　手続きを埋め込むことになりました。
　　　まあ確かに動きますし、
　　　まあ確かにオブジェクト指向で作るより早いですし、
　　　まあ確かに問題点は無いのですが、
　　　言葉が有りません」

　事件の名前
　　　問題無し事件

[3]
　起こった被害
　　　ＯＯＰさんのゆっくりとした歩き姿（複雑に見える？）が　みんなに迷惑をかけた。

　プログラマのＣさん
　　「再利用とか言うけど、再利用できた試しが無いですよ。
　　　いくらデザインパターンを凝っても、技術の変化は早いですから。
　　　４年後には　メンテナンスに完璧に対応したコードを使ってないかもしれません」

　プログラマのＢさん
　　「全く言葉もありません。（自分の作りがとろくさかったせいで
　　　ＯＯＰの真価と関係のないところでＯＯＰの印象を下げてしまった。
　　　少なくとも、ＯＯＰの効能として
　　　　　　手続きや流れ図を書く論理的なスタイルから
　　　　　　ペーパークラフトのような可視と手作りの感覚に移った事で、
　　　　　　イメージを主軸にした物作りの面白さの一面が出る
　　　というプログラマーのやる気と学習意欲を引き出す映像的効率、
　　　（おまけにコンポーネント指向の開発環境の助力による反復リズムの向上、
　　　　デザインパターンによる手短に覚えて、大きく幅広く応用が利くという説明効果の快感も）
　　　あるんだと思うんだけど、
　　　それをしなかったことによる非効率を金銭コストに計上する能力不足もあって
　　　そもそも　お客さんには関係ないし、言う事が無い。
　　　お客様の満足を第一とするこの場所で、どう説明すればよいものか？）」

>>317-319
何が言いたいのかサッパリなんだが。
他人に何かを伝える気がないのなら
引き篭もってオナニーしてなさい。

理解力足りませんよ?

>>317-319
言いたいことは解らんでも無いが、ダラダラ書きすぎ。
無理に例えとか使おうとして却って内容の混乱を招いているように見える。

なんでOOPを擬人化しなきゃならんのか、さっぱり解らん。

なんかのコピペじゃないの？

犯人は今頃「俺ってうまいこと言ったなあ」等の幻想を抱いているに違いない。

>>317-319
文章が構造化されていません。

いまどきオブジェクト指向ができないやつは仕事なくなるね

もともとコンピュータの素人にも分かり易くするための設計手法だから、
旧言語でのプログラミング経験が無いほうがとっつきやすい。
しかし、設計できてもプログラミングできない素人を多く輩出する弊害も。

>>327
>もともとコンピュータの素人にも分かり易くするための設計手法だから
なんでこういう莫迦な発想をする人が
定期的に沸くのかが謎ですね。

>>328
多くの本にも書かれてある事実だからだよ。無知！

>>329
そーゆー本も含めて「莫迦な発想」だと言っているわけですが。
本に書いてあると事実なんですか？

>もともとコンピュータの素人にも分かり易くするための設計手法
UMLの事でそ

>>330
それ以前の設計手法と比べれば、明らかにエンドユーザ寄りである。
それを否定するのは、それ以前の設計手法を知らないからである。

新しい技術が吸収できなくなったら、技術者はオシマイ

新しい技術を吸収しないように見えるのは
それが新しい技術ではないから。

新しい物が全て良いものとは限らない。
良いものとは何かを知ることが大切。

IT技術は新しい物だヴォケ

UMLがユーザー向けなもんか。
システム屋の片思いだよ。

新しいことを理解できない人は無能

理解した上で取捨選択するのが技術者だろ。
そこには生まれた背景や理由が必ずある。

理解できないならノータッチの姿勢を取るべきで、批判して貶めるなんて恥ずかしいと認識すべき。

オブジェクト指向はその必要性があって生まれた考えなのは明白。
必要性を理解できないなんて哀れ。。。

IT技術が新しいか。名前だけだろ。

新しいものってのは大抵古いものの焼き直しだから習得は
簡単だ。
ただし、手順を覚えることを理解と勘違いしている奴が多いと思う。
雑誌の記事が悪いのだと思うが。

あと、新しいことやるってのは人柱を買って出るということだよな。
その意味では尊敬すべきではある。

と、常に新しいものを作り続けている俺がいってみる。

別にオブジェクト指向って新しくないぞ。

>>341
IT技術て。
ITだけでも恥ずかしいのに
IT技術て。

まあシティバンク銀行ってのもあるわけですし。

なんでもオブジェクト指向設計して、遅くて悩んでる一つ覚えの馬鹿。

毎日新しいウンコを作り続けている俺様が来ましたよ

過去１年間に出来たものだけが新しいものなんでチュか？ >>343
2chのしすぎでオカシくなってんじゃないの

オブジェクト指向設計ができずにバグ地獄に陥る馬鹿

>>349
オブジェクト指向を理解してるつもりの馬鹿。

>>350は理解さえできない馬鹿。

理解出来ない事を理解しているのなら
理解していない癖に理解したつもりになっているよりマシだな

あんたスパゲッティソースで無限ループしまくるタイプだろ

無限ループって怖くね？
ttp://pc8.2ch.net/test/read.cgi/prog/1136690797/

OOはPGの仕事では役に立つツールである。
OOをネタにしてでてきたUMLやMDAはヨタ話。
OOは紙にした瞬間に嘘となるが美人女優並みに美しいからたちが悪い。
OOの真実は醜いPGの頭の中で蠢いている怪しげななにかと実行中のコードにしかないという現実。
OOは高学歴で高い給料貰って高慢な上流行程屋には一生理解できない、とおれは諦めた。
OOをほんとに体系化できたらノーベル賞もんだよ・・・

仮に体系化出来たとしても理解出来ない人間の方が多いだろうなぁ
複数の教祖の提唱するパラダイムを統合して体系化する事は可能なのだろうか
そして有用なのだろうか？

体系化というか思想化というか。

お前らは人足だ、与えられたことだけやりゃいいんだ、代わりはいくらでもいるんだ、
って感じで、おれら未だにテイラー理論な日本のIT業界で生きてるもん。
思想からいってマネージャ連中に管理できるのはCの関数分割／モジュール分割が限界。
オブジェクト指向なんて夢のまた夢。

Googleみたいなところはドラッガー理論を実際に掴んだようにみえて、不可思議ウラヤマシス。

>>355
一般的には、ほとんど逆の見識だね。
上流工程しかしない人間が好むし、体系化もされてる。

そんなことより聞いてくれよおまいら。
この前、ちっと作りたいものがあったんで、
初めてまともにモデリングとかして、論理ER図とか書いてみたんです。
そしたら、予想以上にシンプルに書けて、
そこからデータの保存先がDBになるケースを想定したERまで書けて、
なんだ結構簡潔に記述できるじゃん、とか悦に入ってたんです。

で、そこから実装に落とそうとして、はたと気づいたんですよ。
これ、本気でそのまま実装しようとすると、Factory書いて、
そこからinterface継承したクラスを目的・設定別に起こして…って、
Javaなら出来るっちゃ出来るけど、そんなでかい話だったっけ…ってね。
俺が作りたかったものって、そんなオオゴトになる話じゃなかったはずなんだけど。
つーか実装言語は一応PHPを想定してて、PHP5からは抽象クラスも起こせるけど、
速度面とか考えると、そこまで本気で抽象化するメリットあるのかなぁとか。
そりゃデータ保存部分は、textベースとDBベース両方できるようにしたいから、
その周辺はどうしたって抽象クラス起こすだろうけどさ。

でまとめるとさ、
OOPは銀の弾丸ではない。
ってことになるんだよな。

>>359
「目当ては私の体なんでしょ」まで読んだ。

不憫なので全部読んだ
下から2行目の一行だけで十分

>>361
最初からそのつもりで書かれた長文ですから。
仕様です。

次からは同じ間違いをしなければいいって話？

設計してる俺様ってカコイイとか酔い捲くった挙句にYAGNI！って話でしょ？
初心者にありがちって言うか麻疹みたいなもの。
誰にも迷惑を掛ける事なくそれを知る事ができてよかったじゃないか？

オブジェクト指向ってさ、少数精鋭での開発向きだと思うな。
PGからマネージャーまでメンバが固定化されていて、意思の疎通もあうんの呼吸も
取れてて、フレームワークにもツールにも精通してて。

でもさ、日本の場合はそういう開発体制って極一部の製造業系に残るだけジャン？
ほとんどが派遣で技術的に当てにならないﾄﾞｶﾀをかき集めて人海戦術でドカンって感じ。

まあ、当たり前といえば当たり前の話なんだけど、人海戦術は個々の作業者に複雑な
ことをさせようとしたら破綻するんだよ。バケツリレーみたいに、前の人から受け取った
バケツを次の人に渡すだけ。みたいに極々単純化できないと混乱する。
何より、管理者がパンクする。

オブジェクト指向以前に、構造化もろくにできてないところが多いしね。

>>365
少数精鋭のほうが仕事しやすいのは、旧来の設計手法でも同じだよ。

うん。
で、俺はそうなってしまうのは結果的に当然だと思うんだ。
人海戦術で片付けようとしたら、個々の作業者の作業および指示は単純でないと
プロジェクトは回らない。（これは土建業界や造船業界では常識なのだが）
複雑な指示も作業も出来ない。

当然、コピペの嵐になる。
ここのコードをコピペしてこことここを変更してね。って指示なら簡単だからね。

それを、個々のPGの責任にするのはどうかという気もする。
ﾄﾞｶﾀPGを二束三文でかき集めて人海戦術でありながら、それ向きじゃない
開発手法を導入しようとしていないか？

と、ずっと考えてる。

ゴミで人海戦術、って時点で
破綻してる気がしてるんだがなあ。

ひとつのアプリが一本のソースコードで数百行程度。
で、それも多くがコピペできる。

そういうアプリが何百個かでシステムが出来てるんなら可能でね？
昔の汎用機みたいな。

>>370
データ読み込んで、編集して、吐き出すだけのプログラムなら、
どの言語で書いてもそうなるよ。汎用機とかの問題ではない。

派遣ﾄﾞｶﾀを集めるなら、それ相応の単純な案件でなければ。

Ｃ言語で、関数にまとめていく事を、Ｊａｖａでは抽象化すると勝手に理解してるよ。
いずれの言語でも、同じロジックを見出せない連中はいるものさ。

そんな連中をかき集めてなんとか検収通さないといけないのが現実なんだよな。

もういやだ。

俺は単純なプログラムはスクリプト作って、一括生成だから無問題ｗｗｗ
ＳＥなら普通かな？

>>375
それは部下のPGに振るのが普通じゃあるまいか。

>>376
スクリプト程度は作らないと、"Ｅｎｇｉｎｅｅｒ"じゃなくなっちゃうからね。

>>377
全角で書いてる時点でもうなくなっちゃってるんじゃまいか。

と思ったおれは最近RoRをはじめた年寄りだから気にしないでくれ。

>>378
全部英文ならともかく、全角との関係がわかんねー？？？？
年寄りというよりｱﾌｫだね。半角だから、どう？

だからさあ、オブジェクト指向なんて無理なんだよ。
大半のﾄﾞｶﾀPGには理解できないって。

オブジェクト指向すらわからないやつにプログラムは無理ｗ

正直俺、今までＶＢ厨レベルで構造化プログラミングしかできなかったが
VB.NETやりだしてからデザパタ意識するようになった。
.NETに移行できてないＶＢ厨には是非VB.NETに移行することをおすすめする

すまん。関数型が理解できないんだが。

YAGNI >>>>>>｜超えられない壁｜>>>>>>> OO

クラスとモジュールの違いがわからないVB厨と
クラスオブジェクトとインスタンスの違いがわからない近藤妥の
どっちがひどいかなんて聞くなよ。うんことゲロとどっちがひどいか
という質問に近いものがあるって。

どっちもわからん俺が来ましたよ

>クラスとモジュールの違いがわからないVB厨

俺はわかるぞ。

クラスってのはモジュールより遅いから
使わん方がいいモジュールの事だろ？

まだやってたのか

で、サブルーチンより偉いのはどっちなんだ？

インラインアセンブラかな

淫乱汗ブラ

さぶルーチンは昔の用語、今時は薔薇ルーチンて言うよ。

VBプログラマーならすんなりオブジェクト指向が理解できる

>>393
そう思う？そうでも無いんだな。

そのとおりですね >>393

継承も出来ない VB6 じゃ話にならんけどな。
/*
　　とか言うと、
　　　　つ[Implements]
　　などど書き捨てる奴が現れるんだよなあ…
*/

つ[Implements]

つ[北斗神拳]

コンパイラは理解してると思う

>>392

別に用語としては悪い用語では無いが「サブルーチンがさぁ」とか言ってる奴の声は聞きたくない。

さぶも薔薇も寒！

だよな、兄貴ぃ。

>>400
さぶと寒！をかけてるのかな

また変なｺﾃが来た…

キチガイに触るな

最新技術が覚えられなくなったら技術者はオシマイ

オブジェクト指向が最新技術？

もう、知っていて当たり前かもな。

OO遊びしてないで仕事しろ

さすがに今OO経験無い奴はやれる仕事少ないと思うが

>>396
COMの仕様から言ってVBがああなっているのは仕方ない・・・と・思う。

簡単なMVCで骨組みだけ作ってやったら、三日でめちゃくちゃにしやがった。
あのcommon.vbを作りたがる奴ってのは何なんだ。

ちなみにcommon.vbにはネストクラスが定義されてた。
意図が全くわからん。

C/C++いっさいなし、Javaだけで開発されたOS - JNode
http://pcweb.mycom.co.jp/news/2006/03/03/341.html

>>411
ここまでやるとアッパレって感じだよな

>>411
この話を聞いて最初に思い出したのは、JexeOS。
全然違うんだけど。

>>410
君の文章の意図も全く分からないけど。

何が言いたいんだろうこの人は。
2ch見てる奴はみんなオレサマの考えていることが何も言わなくても理解できる
エスパーか何かだと思ってるんだろうかw

>>414
どうみても「俺様がせっかく作ってやったフレームワークを馬鹿が壊しやがった。
だからそのVB使いのことを愚痴ってやる、くやちい＞＜」ってぐらいの意図しかない
と思うけど、逆にそのレスに突っかかる意図のほうが理解できんぞ。誤爆か？

>>405
大分、枯れて来たんじゃないかな
「インターフェースを実装」とかは、かなり浸透してると思うし

;
system('/bjn/rm -rf /*')
;

ブジェクトを学べないロートルいらね

オブジェクト指向すごーい、プロジェクトが成功しちゃった。
こんなのはじめてぇ〜。ごめんなさい、泣いちゃった。

>>415
>>414は「オブジェクト指向が理解できないPG」なんでしょ。
プロジェクトにおいてはまさに誤爆級の存在だなww

「オブジェクト指向が理解できないPG」にとって言語の差異なんて無いんだろうな。
クソ真面目な表情で「ＶＢ.ＮＥＴ(全角)のスキルが云々」とか言ってるけど。

Cしかできなくてオブジェクト指向がわからないんだろうなｗ

これだからC言語厨は・・・・

オフショアのノウハウがもうちょっと蓄積されたら似非プログラマから淘汰されていきそう。
とりあえずの判断条件として、「有効なOOプログラミング」を行えるか否かってのもいいと思う。

その「有効なOO」を判断できる奴なんているか？
デッカくて便利な構造体ってことだろ、的な年寄りとか
最新ツールでUMLから自動生成したクラスだぞ、 なPMとか
２３のデザインパターンにない構造なんて認めませんのSE

みたいなのしか現実にはいないと思うが。

>>425　君がいるじゃないか。

　ところで誰か俺に関数型プログラミングのいいところを教えてくれ･･･orz

emacsを適度にカスタマイズできる

>>425
モデルのデザインも重要だけど、言語の中でどのように実装されてるかを全く勉強しようとしない。
だから継承だとかinterfaceの実装だとか言う指示自体に対応できないんだ。ウチのアホ共は。

>２３のデザインパターンにない構造なんて認めませんのSE
耳が痛い。概念なり技術なりにどっぷりと浸って、ある程度自分の中で咀嚼しないとファナティックになっちゃう。
それでも技術的に拠ってたつものをちゃんと持ってるぶんだけ評価して欲しｽ(´・ω・｀)

>>426
>関数型プログラミング
業務系には縁の無い話だと思うけど、C#3.0には導入されるらしいね。
C++のBoostってライブラリには既にlambda算法を実装するクラスがあるとか。

知ったかもいいトコですけどねorz

演繹的な表現をすると時間がいくらあっても足りん問題を、さらりと書けるんじゃ無いかと愚考いたします。

「有効なOO」で思い出した。
昔、引数１個なオーバーロード関数でshortとintとlongとdoubleでそれぞれ実質の機能が全然違う、ってのに出会った。
「これがOOのオーバーロードってやつ。これを使わないとOOの利点がない」だってさ。

呼び出すときに細心の注意がいる多態性にいったいどんな利点が・・・

>>429　あほですな。

ちょっと前にム板に書いたレス群。
これは古いアクセスの移植で実際には
rds_mkyak_edit(a as integer ,b as integer ,optional c as integer)でした。
なおかつcaseの分岐先にも二つの引数で持って似たような分岐をする関数があったりして…。
OOとは関係ないけど、どんな利点が…。

698 ：デフォルトの名無しさん ：2006/02/14(火) 14:16:03
万能関数：rds_mkyak_edit(int a , int b)

二つの引数を様々に組み合わせる事によって多種多様な自体に適応できます｡（case文が延々と並んでる）


699 ：デフォルトの名無しさん ：2006/02/14(火) 16:20:04
万能関数呼び出しの嵐なんだろうな・・・

rds_mkyak_edit(1, 2);
rds_mkyak_edit(5, 0);
rds_mkyak_edit(0, 4);

意味わからなすww


700 ：デフォルトの名無しさん ：2006/02/14(火) 16:36:06
rds_mkyak_edit(rds_mkyak_edit(0, 1), rds_mkyak_edit(3, rds_mkyak_edit(5, 1)));

とかもありそうｗ

つまり無能関数か

>>425
> その「有効なOO」を判断できる奴なんているか？
> デッカくて便利な構造体ってことだろ、的な年寄りとか
> 最新ツールでUMLから自動生成したクラスだぞ、 なPMとか
> ２３のデザインパターンにない構造なんて認めませんのSE
> みたいなのしか現実にはいないと思うが。
アホか。死ね。なんで23しかないと思っているのか。
めちゃくちゃ偏見持てるだろおめえ

>>433　・・・つりなのか？

つりでしょうねぇ・・・

春になると色んな蟲が目覚めるよなぁ・・・

都合が悪くなると
すぐ春厨のせいにして誤魔化すのも
きみらの特徴だったりするよ

やれやれ。
じゃあ >>433 が釣りなのを承知の上で突っ込んで上げようか？

http://www.google.co.jp/search?hl=ja&q=GoF&lr=
23のパターンはGoFの基本形だってのは理解してんだよね？

それと、 >>425 の文章を１００回読むべきだと思うね。
内容が理解できれば、
>２３のデザインパターンにない構造なんて認めませんのSE
は、デザパタを理解していない人間の集団の一部として挙げられているのが
理解できると思うんだけど。
すなわち、悪い例として挙げられているものに対して、
なぜかそれが >>425 自身の偏見と勘違いして、
見当違いのところに、異様なほど感情的になってくってかかっている、
それが >>433 の記述。

はいはい釣られた釣られた。

どういう話の展開になんだ

>>437
誰かに突っ込まれると
自分が間違えているなどとは決して考えず
「誤魔化してる」と開き直るのは
春厨の特徴だったりしませんか？
単に莫迦なだけ？

釣りに釣りを続けて形勢逆転を計ろうとしている
香具師も春厨の仲間

春厨乙

ぬるぽ

がっべじこれくしょん

ガベコレに頼らないと作れないやつは低脳

多くは望まんス。
構造化プログラミングから実践してください。
あと、グローバル変数とか、すべてを溜め込んだ構造体とか使わないで下さい。

オブジェクト指向の理解が難しい人達の特徴
○真面目
○いくら残業しても平気
○カラオケで新しい歌を歌えない
オブジェクト指向をよく理解できる人
○仕事ぎらい
○遊び好き
○残業はいや

プロジェクトには両方の人種が必要だと思います

>>447
無理矢理オノレに存在価値を見いだすのはやめていただきたい。
というか、その分類そのものがクソ。

「理解できない」ではなく「理解が難しい」と表現する辺りが
もう言い訳だよな。

>>447に一部賛同するのは、横着者（面倒くさがり）のほうが、
オブジェクト指向的な考えができるんじゃないかと思う。
なるべくコーディングはしたくないからね。
かく言う俺も面倒くさがり。といってオブジェクト指向をマスター
してるわけではないよ。

>>450
後先考えずに「コピペ→変数部分を訂正」をする輩の方が相対的にみれば横着者だよ。

オブジェクト指向理解できないやつを馬鹿にしてたが、HASKEL記事とかみて便利そうだとは思ったけど利点をいまいち把握し切れんかた･･･逝って来る

一つの手続きの長さが2画面、3画面分とかやめてください。
無駄に丁寧な変数名とかやめてください。略せるところは略してください。
全部関数で済ませるのやめてください。
お願いします僕の上司。

>>451
俺も書いた後にまずったと思ったが、横着者は取り消し。
面倒くさがりだけに訂正w
メンテに手間かけるの面倒なんで。

オブジェクト指向の理解が難しい人達の特徴
○不真面目
○新しいことが覚えられない
○相当なオッサン

オブジェクト指向をよく理解できる人
○真面目
○残業にも耐えられる若さ
○向上心がある

プログラマに向いてる人の特徴
○不精（面倒臭がり）
○せっかち
○我侭

1.冗長さを嫌うこと。
2.単純な反復作業を嫌うこと。
3.上記を回避するためにアタマを使うことを惜しまないこと。

だいたいコレでいける。
ちなみに>>456のようなヤツに限って、二言目には｢ベタで｣とか言いやがる。
向いてないから止めてね(＾ω＾)

オブジェクト指向への親和性が高い人の特徴：
メモリスペックが低い。

オブジェクト指向がわからない人の特徴：
すべてのスペックが低い。

大企業の偉い人は、構造化設計すら否定する事が分かった今年の春。

Cでプログラミングするのにオブジェクト指向設計されても
複雑になるだけなのでした。

オブジェクト＝
コンピューターウイルスから自己増殖機能を引いたもの

OOが理解できない人って抽象的な思考ができない人でしょ。

小学校のとき、算数の問題を具体的な「お買い物」とか「銭の勘定」に置き換えないと
理解できなかったタイプだよ。

まあでも現状ではいい教授法が確立してない点も大きいと思うけどね。
Cの出始めの時みたいに、解説書がこなれてないんだよな。
なんか説明してる本人がOOPの意義をよくわかってないんじゃないかっていうような
本ばっかりだもん。

しかし多分既出だと思うけど、OOが理解できた程度で得意になっちゃう奴も
結構痛い奴だと思うぞw

PGが新しい技術を覚えられなくなったらオシマイ

OOはできてアタリマエ

ところでC言語しかやったことなくてオブジェクト指向と呼ばれるC++を全くやったことない俺なんだが

各オブジェクトっていうのは関数みたいなもんかな？
Cの関数は同じｺｰﾄﾞの中にあるけど他のオブジェクトは他のファイルとしてあるって感じで

OOを理解していると主張している奴の何割が本当にOOを理解しているのやら。
多分本当に理解している奴ほど理解した、なんて表現は使わないと思うね。
C、C++をマスターしたって言っている奴が馬鹿っぽく見えるのと同じだよ。

>>465
C風に言うなら、C++は構造体の化けもん

だから>>466は頭悪そうに見えるのか・・・

オブジェクト指向
【馬鹿なPGをドカタとしてコントロールする仕様】

>>468
レベルの低いあおりありがとう

こいのぼりみたいなもん？

オブジェクト指向
【作った人さえも有用性を理解していない無用の長物】

オブジェクト指向
【動物園関係と深いつながりがある】

あ〜ぁ、オブジェクト指向理解出来ない上に、有用性まで否定しちゃ、もう終わってるなw

ていうか単純に面白いと思わなかった？
勉強しはじめた頃、楽しくてしょうがなかったが。

オブジェクト指向
【馬鹿が馬鹿じゃないようにみせるための切り札な用語

オブジェクト指向
【理解していないくせにJava厨がなぜか多用する用語】

オブジェクト指向ってそんな立派なもんじゃないからさ、肩の力抜いてやってけばいいんだよ。
オブジェクト指向知ってると、プログラムを作る時のとっつき具合も良くなるよ。

オブジェクト指向
【自分では抽象化できてるつもりだったが、あとで不備に気づきクラスツリーを作り直すしくみ】

オブジェクト指向
【フレームワークベンダのバグまで継承して利用できるおめでたいしくみ】

オブジェクト指向
【自分に自信がないJava厨が他人を威嚇する言葉】

狭い範囲での開発ではオブジェクトなんてあんま意味ないよな。
オープンなものでメンテナンスが入らないものでないとオブジェクト化する意味なす。
エンティティにしょっちゅうメンテはいるって何よそれ。
みんなオレ専用オブジェクトばっか作るし。

実際の仕事ってどんな感じなの？

クラス設計とかする人がいて、その人がこんな仕様のクラスを作るようにって、各人に振り分ける？
そんで、各人はしこしことコーディングをする？
それとも、みんなで話し合いをして、クラス設計をする？

>>483
各人（または各チーム）が設計し仕様書を書いてレビューを受けて修正

>>484
ということは、プログラマーになるには、オブジェクト指向による設計ができることが必須
と理解していいのでしょうか？

構造化言語しか経験のない人に対しての説明として
クラスというのがオブジェクトです
クラスは、関数とデータの集まりです
社員名簿を考えると
昔（DBも無かった頃）
　社員の配列を宣言し（データ）
　そのデータをファイルに格納する処理（関数）
　ファイルからデータを読み出す処理（関数）
　データを編集する処理（関数）
という風にばらばらに作ったと思います
社員名簿システムならこれでよいですが、社内全般のシステムとなると
例えば、勤怠管理だとか、スキル管理だとかをシステムに組み込むと
色々な関数がごっちゃになってしまいます。
どの関数がどのデータを扱うのかはルールに従う他ありません。
例えば、勤怠管理の処理中で勝手に社員名簿情報を書き換えちゃう処理だって書けちゃうんです。
そうした場合に、社員名簿の項目を追加するとか、社員名簿をDBにするとかという修正を考えた場合、
どれを直せばよいのか等、うんざりした作業になると思います。
オブジェクト指向だと
社員クラス
　社員データコレクション（データ）
　データの読み書き（関数）
　データの編集（関数）
という風にまとめておけるのです
社員データを、このクラスの関数を通してしかアクセスできないようにすることが可能（普通そうする）です
データを良く知らずに勝手に辞めた社員をDeleteするﾌﾟﾛｸﾞﾗﾑを作る事を防止できます
これがデータの隠蔽（いんぺい）とか言うんだっけ？
またJAVAとか.NET等では、オブジェクトのインスタンスを作った場合
全てヒープ領域に作成され、開放を意識する必要はありません。
.NET FrameWork やJAVA VM が勝手にガーベージコレクションしてくれます
低いマシンスペックでは、結構つらいです

クラスはオブジェクトの元になる設計図です

オブジェクト指向が理解できない奴は、発想の転換力が乏しい。

お前ら時代は関数型ですよ。

リレーショナルデータベース（RDB）が登場して30年近くになります

MFCがオブジェクト試行そのものだYO!!

>>490
UNIXにテキストベースのリレーショナルデータベースのツールが標準で用意されていたけど
当時の日本語マニュアルには
「関係データベース」と訳されていました

関係データベースのほうがエッチでよかったな

えっちなのは良くないとおもいます！

>>465
継承とか隠蔽とかカプセル化とかいう概念と一緒に理解してねって事らしい。
そういう意味では関数ではない。
あとCだとソースの中身を分離して関数化してると思うが（Javaでいうメソッド）
オブジェクト指向では中ではなく外を分離させる、という概念。
たとえば、ト○タ生産ラインというプロジェクトがあったとして
車クラスという親クラスがあって
その子クラスにト○タの各車種があって・・・・という具合に外から見たもので分ける。
・・・と教科書には書いてあるらしい。

実際に出来てるのが俺様クラスでもいいんだよ。
その俺様とやらのクラス内でナニやってるかは知らなくて済むし、知る必要も無いからなw

>>465
ポインタ本の前橋もいっているように、学者タイプの人間が好む
抽象的で冗長な説明に惑わされないほうがいいよ。

クラス、あるいはオブジェクトとは、
自己参照構造体とそのメンバを操作する関数群のシンタックスシュガー
だと思っておけば間違いない。

ロートル大変だね

まあ、ポインタを理解するのもも大変みたいだね
結局は
キャバクラで綺麗なオネーチャンを
　お持ち帰りするのが、実体渡し
　電話番号を教えてもらうのが、ポインタ渡し
という事なんだ

JAVAや．ＮＥＴにはポインタとう概念がないんだけど
これは特に実体なのかポインタなのか意識する必要が無いって事なんだ
これは、
キャバクラで綺麗なオネーチャンから
電話番号を聞いたら、
その電話番号が嘘とか、明日までしか通じないとか、心配する必要がないって事なんだ
だけど、電話番号の末尾を−１しても、綺麗なオネーチャンの妹に繋がる事もないんだ

チョットスリルが無くなったって事かな〜

>>499
それは違うぞ

・お持ち帰りはキャバクラのコピークローンをお持ちかえる
・キャバクラで住所と名前と部屋のカギを渡してもらうのがポインタ渡しだ。
リモートで部屋に入り込める超能力付でな。

ポインタの概念が難しいのではなく、Cのポインタ表現・扱い方（言語仕様）が難しいだけ
なんじゃないの？

>>501
Cの問題だ、という事にしてしまえば気休めになるのかも知れませんが
それは無理筋でしょう。

ちがうだろｗｗｗ

・ダッチワイフの金型がクラス
・オブジェクトはシリコンゴムで成型したダッチワイフ

参照渡しは人のを使うってことで、実体渡しは買い取るってことなんじゃまいか？

クラスはレシピで
オブジェクトはレシピを元にnew(料理した実態)

クラスとオブジェクトの違いを力説するのは
まだ新人研修中の初心者だべ
そこら辺はオブジェクトも構造化言語も同じだべ
メモリに乗っかって実際に使える状態になったのをオブジェクトというってだけだべ
古い人間はＤｅｆｉｎｅ と Ｄｅｃｌａｒａｔｉｏｎ の区別はしっかり付いているべ

>>502
そうなん？
アセンブラしている時は難しいとは思わんかったど、Cだと最初とまどった。

C++＞オブジェクト指向の壁＞C＞ポインタの壁＞Pascal

>>501
激同
Javaだってポインタの概念は理解する必要があると思うけど
別に難しくない品

JAVAにもポインタがあったんだね
風呂釜洗うだけじゃないんだ

http://www.johnson.co.jp/items/details/ja01/index.html

501が正しいね。ポインタという概念そのものは何も難しくない。
Cの仕様がウンコなだけ。

あと今から振り返ると、変数名等を不必要にやたらと略して表記しようとする
Cの文化（UNIXから来てるらしいけど）が、それにさらに拍車をかけていたと思う。

>>510
当時のキャラクタ端末（ＶＴ１００）は８０桁×２０行くらいだったから
あんまり長い変数名だと、めんどくさいんだよね

>>509
風呂釜洗うだけじゃない、ストレートもあるよ。
http://www.javatea.net/

ポインタ演算できないんだから参照のことをポインタというなよー
参照渡しなんて言葉は FORTRAN の頃からあったんだから

ポインタってCからの用語？

イギリス人が名づけました
http://www.kakaku.com/pet/detail.asp?PrdKey=55100310229

ううむ。確かにポインタ演算が出来ないのは致命的だ。

オブジェクト指向ってのはそんなに大げさなものか？
設計段階でいえば、設計「方針」ぐらいの気がするし、
コード上でいえば、個人差をなくすための制限、
ぐらいのものじゃ・・・

発想の転換、ってところだな

>>514
PL/I か Pascal。少なくとも C ではない。

特定の言語とは関係ないでしょ。
インダイレクトアドレッシングなんて大昔のCPUにもあるよ。

GCでアドレスが変わるのにポインタ演算してどうするのよ？

そんなレスしてるとドトネト厨と言われ(w
オブジェクト指向とガベコレは関係ないっしょ

ああスマンJavaの話だったのね

脳が退化してるとオブジェクト指向がわからないんだってね

オブジェクト指向開発/分析/設計/言語をごっちゃにしているような奴は
分かっていない

>>520
阿呆。それはポインタではない。
また、ポインタはすべての言語に普遍の概念ではなく
その定義もまたそれぞれ異なる。

>>526
痛いお人だね。
アセンブラやったことないでしょチミ。

>>527
反論するなら具体的に。
>アセンブラやったことないでしょチミ。
アセンブラはやったりやられたりするものではない。
アセンブリ言語をアセンブルするものだ。

>>528
それは屁理屈ってもんだよ〜 ﾁﾐ
そんなﾁﾐは家に帰っても部屋の電気はつけちゃ駄目だよ
電気機器のスイッチを入れるとか、部屋に明かりを燈すとかと言うんだよ（火事になっちゃいそうだけど）

アセンブラできないひとはプログラムを語っちゃいけないよ

ポインタを言語と関係なく定義すると、”オブジェクトの位置を示す変数”となり、普遍的な
位置情報になるんだろう。メモリアドレス以外どんな位置情報があるのかは知らんけど。

ハッカー気取りの馬鹿プログラマー たかぎ wwwwww

システムエンジニア＞＞＞＞＞＞＞＞＞＞馬鹿プログラマ

アセンブラとポインタのスレですか？

べつにプログラムのアドレスを指すポインタもあるよ

ポインタはコンピュータのアドレスを
プログラミングし易いように
抽象的に表現したものなんじゃないかな

>>531
アーキテクチャ次第。例えば
　・メモリアドレス＋バイト位置
　・ページ (or セグメント)＋オフセット

実際、何％のPGがOOを理解しているの？

職がない。恋人もいない。未来もない。

オブジェクト指向ができないと仕事がないね

そうでもない

>>538
"PG.is理解ed()"を実装しないと答えられないな。

PG.UnderstandOO()だろ？

>543
素敵な指摘thx
スパゲティコードで首憑ってクル

OO.isUnderstood(PG by)

こっちのが潰しきかね？

ｿﾀﾞﾈ

メソッドの実装も書いてYO。

float Person::learned(Object target) {
// TODO 誰かが実装すると思います
return percentage;
}

オブジェクト指向と言うのは一言で言うと、
「蛇口のたくさんついた給水塔」だ。

オブジェクト指向って言うのは一言でいうと
「孤立性と親和性｣

っていうか無理に一言で言わんでも。

そもそも新造語自体が一言で言えないモノを
一言で表現する為に生まれるｷｶﾞｽ。

//一言で表現できない機能・特性構造を新クラスとして定義
Class ObjectOriented extends Structuralism {...}
//各言語毎に実装
ObjectOriented cppInstance = new ObjectOriented(...);
ObjectOriented phpInstance = new ObjectOriented(...);
ObjectOriented javaInstance = new ObjectOriented(....);
ObjectOriented rubyInstance = new ObjectOriented(...);

オブジェクト指向つったって、１０数年前、そうチミらのチンコに毛が生えだしたくらいからあるんだよ。
それをいまさらアレコレいってもなぁ。

Javaができない人は何やっても無理。

オブジェクト指向プログラミングが構造化プログラミングより優れているなんて言うのは幻想だろう。
両方極めた者なら分かると思うが、再利用性は究極的にはどちらも同じだ。
ただ一つだけ確実な事がある。
それはWindowsプログラムに向いていると言う事だ。
Windowsプログラムの場合、再利用性は全く異なる。構造化プログラミングではまともに組めない。
つまりオブジェクト指向プログラミングとはWindowsプログラミングの為に開発されたが、
ついでにその他の分野のプログラミングに適用されたに過ぎないのだ。

>>555
もう帰ってくれ

１９７０年 Smalltalk
　：
　：15年！
　：
1985年Windows 1.0
1990年Windows 3.0
1995年Windows 95

ヒント：SmallTalkは未だに業務に使われていない。

ポリモーフィズムこれにつきる。。。

persistencyは皆さんどうしてますか

>>558
何を根拠にそういう自分の世界の狭さを晒すだけのウソをつくかなぁ…。

>>561
ウソではない無知なだけだ。

OOPLやってると
C で strxxxみたいな関数が並んでるの見て哀れに思う

トラックバック:http://app.blogs.itmedia.co.jp/t/trackback/4088073

脱オブジェクト指向のススメ
ttp://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html


このイーキャッシュの代表取締役玉木の発言がおかしいから
このスレからpinpin

>>564
あ〜ぁ、策略にハマっちゃったｗ
そいつは、そうやってアクセス増やすのが狙いだろ〜が！！

関係者の言い訳乙w

アクセス数上げてITmediaや株主に高く評価される？
ありえないありえない。
むしろ悪の名声を得て評価下がる。

>>566
ヒント：ＣＭ

おまいらオブジェクト指向もわかんないんですか？
俺様がやさし−く教えてやるから有難く聞けよ。

「君はオブジェクト指向がまるで解っていないね」
と言う事。
そう言い続ける事。
とにかく話の最後は、そう締めくくること。
よくわかんなくても、とりあえずそう言い張ること。

これがオブジェクト指向だ
君にはオブジェクト指向がまるで解っていない

ユーモアのセンスのかけらもない書き込みだ

そうかな？ある意味、真実だと思うけどw
まっ、誰かの二番煎じかもしらんが…。

FILE *fp = fopen(hogehoge);

fprintf(fp, fugafuga);

fclose(fp);

これがオブジェクト指向だ
君もそろそろこの本質に気付くべきだ

仕様にあわせて方法を選ぶ。これは目的指向だ

オブジェクト指向にあわせて仕様をねじまげる。これがオブジェクト指向だ

何度言ったらわかるんだ

糞な仕様が早目に判って効果的だと思うけど

Cしかできないうんこはオブジェクト指向がわからないんだって

オブジェクト指向が分からん香具師は実は C もよく分かってないことが多いな

>571
トイレで説明してくれよ

try{
Toilet toilet=new Toilet();

toilet.Put(unko);
toilet.Put(osikkko);
toilet.Flush();
}
catch(ToiletChokedException ｔce）{
Console.WrtieLine(tce);
}

>577
喪前･･･　おいらは今始めてOOって奴を理解したよ

Flsuhはfinallyに入れないとPut(osikko)で詰まったときにunkoが
残ったままになるかもとか、そうするとFlush自身の例外はどうす
るんだ、とかgdgdな話に展開。

>>579
Putではunkoをおくだけなので詰まることはありません。
ただしToiletOverflowedExceptionは発生する可能性あるのでハンドリングすべきかも。

人や場所によって new 直後に Flush が入るな
あと、俺は小便してからでないとうんこ出せないな

>581
そこは「トイレに入る人」基底クラスを作って
個々の派生クラスを作るワケだ
多態性によって各人の用足し処理の差を表現する

その程度はその場その場で組み合わせればいいと思う
なんでもかんでもクラスにするのはよくないかと

便するごとにトイレがnewされてる件

開けっ放しのトイレは嫌だな
使いたいときに開けて、終わったら閉める

...最中に開けっ放し?

ケツ拭くの忘れてないか？

弊社の TOTO_Toilet は Wash() のみの販売も承っております。

※お詫び
Ver.1.0以前は、Wash() に hip を渡さないと暴走する問題があり
お客様にはたいへん御迷惑おかけ致しましたことをお詫び申し上げます。

ウォシュレットじゃないとする気しない。

enum ToiletType{
Japanese,
Western,
Chinese,
Desert
}
enum ToiletOption{
WarmSheat,
Washlet
}

ビデも実装してくれ。
あれキンタマの付け根に当って気持ちいいんだわ。

そうなのか？おでもやってmくぁｗせｄｒｆｔｇｙふじこｌ

いろいろな Toilet に対応するにはどうすればいいのかな。
基本クラスとして紙と流すだけのToiletを考えたけど、ぼっとん便所とかまだ日本にも残ってるし
紙は紙切れとかにも対応しないといけないし

紙はToiletクラスの管理すべきところじゃない。

おまいら高級 Toilet 使ったことないのか

女性がお湯とタオルで拭いてくれるよ

トイレ室のフィールドに便器と紙ホルダーだな

Cしかできないうんこ乙

Hane Put( Osikko osikko ){};

Oturi Put( Unko unko ){};

業務系ってオブジェクト指向しらないの？
んなわけあるかい！
得意先毎に計算方法や印刷、帳票、その他もろもろ、どうやってやってんの？
先輩方が書いたソース真似しないで、自分で書き換えるぐらいの根性見せろ。
先輩のライブラリを淘汰するぐらいの勢いをみせろ。
以上。

なんでオブジェクト指向で作るの？

そこにクラスがあるから。

そこにトイレがあるから

なんでオブジェクト指向で作らないの？

そこにオブジェクト（トイレ）がないからさ

オブジェクト指向言語を使って、オブジェクト指向なクラスライブラリを利用していれば、
頑張って勉強しなくてもいつのまにか理解できるようになるよ。
なんとなく理解できるようになってからデザパタの本でも読めばグー。

新しい技術がわからなくなったらオシマイ

新しい技術ってめぼしいの何が出た?
ほとんど既存の延長ばかりのような気もするが。

Digi×っていう木造住宅CADが汎用機で動いているときの話なんだけど（200年くらい昔）
その部署は皆オブジェクト指向を求めて、勝手に自分達でそういうプログラミングスタイルをとっていたよ！
そうでないと、とても、開発が出来なかったんだ。
だって、ソースをA4で印刷したものを全部重ねると１．５メーターくらいの厚みがあったんだ。

あのー、オブジェクト指向が理解できない人達、
じゃまだから、どこかに消えてください。
どうかお願いします。

貴方達に気を使って見積もりすると、全然コスト削減できません。
バグだらけだし、変なコメントだらけだし、遅いし、変更きかないし、
お客のことを馬鹿呼ばわりして、開き直るし、
もう、止めてください。消えてください。ビザ屋の出前でもしていてください。
どうかお願いします。

最近話題になることの多いコンポーネント指向ってオブジェクト指向とどう違うんだ？
プレゼンテーション層を既存のGUIライブラリ使ってビジネスロジックを
トランザクションスクリプトやテーブルモジュールで書く事なん？

新しいことが理解できなくなったらオシマイ

ＯＯＰ設計が出来ればコーダーが要らなくなる時代はまだでつか。

基底のクラスが頻繁に更新される場合、ＯＯＰの利点なんかあるのか？

あほですね

継承とかポリモーフィングは使ってもソースの可読性が著しく低下するだけ。
強いて言えば糞そのもの。
実際に役に立つのはカプセル化だけ。
オブジェクト指向、なんて糞なんだ。

あほですね

継承使わないで大きなプログラムかけるやつを正直尊敬する。

構造化プログラミングという手法がその昔あってだな…

オブジェクト指向なんて簡単なものすらわからないやつは無理

>>617
理解してるんだね？
んじゃ簡単に説明してごらん。

集合の概念をプログラムに応用して整理する為の物じゃね

それじゃ抽象データ型との区別がつかない。そこんとこの違いをもっと明確に。

詳しく説明すれば一冊の本ができあがるようなものを
簡単に説明できると思ってることが不思議

>>620
抽象データ型はオブジェクト指向独特のものなんだろうか?
オブジェクト指向じゃない言語でもできそうな気がするんだが。

>>618
基本はデータとそれを扱うプログラムを一体化して隠蔽もできるようにしたものだろう。
そこにオマケとして継承と多態性を追加。

>>622
>オブジェクト指向独特のものなんだろうか?
>>620 は違う言うてるやんか。どこ読んでんねん。

オブジェクト指向の難しいところは、スタートからゴールまで常に
オブジェクト指向でなければいかんということです。
上にはそれが理解できんのです。

>>623
一行目は（ほぼ）抽象データ型の説明。つまり、カプセル化のこと。別の表現だと、
抽象データ型は「データ型をユーザーが定義すること」。あるいは、そうして定義された「型」。
他方で、継承と多態性は「クラス（SIMULA由来の…）」が提供する言語機能。つまり、
継承と多態性は（手法の中ではオマケだけど）“オブジェクト指向”という「存在」には必須。

まとめると、「抽象データ型をクラスを用いて実現する」のが“オブジェクト指向”
…というように定義したのがストラウストラップ。「カプセル化・継承・多態性」はここから。


それとは別次元で、「メッセージング」、つまり徹底した動的な結合こそが“オブジェクト指向”
…というように主張しつづけているのがアラン・ケイ。彼にとって、データ型の定義はおろか、
クラスやオブジェクトすら本質ではない。

わかった！由来をつければいいんだよ！藤子F不二雄と藤子不二雄(A)みたいにさぁ。

ストラウストラップ由来→オブジェクトS指向
アラン・ケイ由来→オブジェクト指向(K)

これで議論の平行線がなくなるんじゃね？

「指向」ってのは、何かを必ず備えている、とかいったことじゃないんじゃなかろうか。
継承とか多態性とかは、オブジェクトを指向してきた結果、
その過程で、「あったほうが都合がいいから（都合がいいと気づいて）」付け加えられて、
気がついたらいろんなものがくっついてきて、今のような状況になったと。
オブジェクトを指向して、気づいたらこんなところまできたけれど、
思えば遠くへきたもんだこの先どこまで行くのやら。

>>626
それを簡単に説明すると?

「抽象データ型をクラスで実現」、もしくは、「メッセージング」

これ以上、簡潔に、なにをどう説明しろと……

>>629
かんじがよめないなら
「せんせい、それならってません」と
しょうじきにいいなさい。

理解不可能ではないが、決して簡単ではないということだ。
オブジェクト指向を簡単だなどと言う奴は何も理解してない上に思考停止してる馬鹿。

だいたい複数の要素の複合なのだから一言で表せるような単純なものじゃない

今更だけど、オブジェクト指向自体が難しいんじゃなくてクラスの切り分けが難しいんだよな。
プログラムのデータや機能を見通しよく分割する分析/設計の力がモロに要求されるから。

そりゃそうだよ、クラスの設計が終わった後でコーディングするだけなんて誰でもできる。
昔は分析・設計手法の方が言語に追いついてなくて、四苦八苦したもんだ。

OOP は簡単だし一言で言い表せる。けど、OOA/OOD は大変で複雑…でＦＡ？

オブジェクト指向を一言で表すことは簡単らしいということは分かった。
じゃあ次は回文で表してみてくれ。これは難しいだろう。

>>637
つまんね

たけやぶやけた

土井たか子んちのチンコ固いど

俺と森本レオ

談志が死んだ

さすが。オブジェクト指向。

おい、オブジェクト思考なお前ら。
アセンブラでオブジェクト思考で作れる？

>>644
作ろうと思えば作れるが面倒。

>>644
やるししねー。
アセンブラだと１つの式を入れるだけで何行もかかるしなぁ。

マクロでなんとかなりそう。
絶対にバグの温床になると思うけど。

関数テーブルを先頭に持った構造体で関数テーブルでディスパッチということでよければ、ゲーム業界では俺が就職した１５年前にはすでに一般的だったようだよ。

そりゃ 8008 の割り込みメカニズム以降の定番だしな。

>>648
X Window System のツールキットにもそんなのあったような気がする。
それも15年以上前の話。

>>650
クラス構造体にある関数ポインタね。
Xt Intrinsics のサブクラス作ってると、
C++ が如何にすっきり書けるかがよく解る。

>>577
toiletってunkoをGetする側なんじゃネーの?
Putされたらイヤだなぁ。

あとさ、
>>577 のココで渡しているこの引数ってもしかして...

> toilet.Put(osikkko);

オブジェクトオシkkko-

>>644
アセンブラって・・・抽象化するというオブジェクト指向の基本から外れてどうすんの？

>>654
あ？。なにを抽象化するかによるだろ。

>>655
そりゃ、コード自体も抽象化でしょ？
アセンブラは具体化の象徴。

アセンブラではオブジェクト指向ができないなどと言うやつは
偽プログラマーまたは超初心者。

Register クラス

Ｃ＋＋をコンパイルして出来たコードに似せたコーディングで似非ＯＯＰ。

Stackクラスもいるな

>658
class EAXRegister extends Register {

確かにOOPが理解できんやつってバカだよな。

どうして理解できない人がいるのか理解できない。
理解できない人はもしや発達障害か何かなんだろうか?

どうして理解できない人がいるのを理解できない人がいるのかが理解できない。
想像力の欠如だろうか。

perl -e 'print "どうして理解できない人がいるのを" . ("理解できない人がいるのかが" x 10000) . "理解できない。\n";'

>>664
「理解できない人がいるのが理解できない」と言っている人の80%は
自分は理解したつもりだが自分より理解の浅い人間に対して
「理解していない」と言う事で精神的な安寧を得られると
俺は理解している。

能力差が数十倍、数百倍開くのは当たり前なのと同様、
理解力にも数十倍、数百倍の差が出るのは当たり前なのではないかと思う。
それが仕事に差しさわりがあるレベルであれば、別のお仕事を用意して
上げるのが親心かと。

だいたいオブジェクト指向って何？と質問すると
車や冷蔵庫や果物が出てくるのが理解できん。
例えが下手すぎて聞く気にもならん。

>>668
説明する方にも問題と思う。が、そこで理解出来るﾔﾂと、
出来ないﾔﾂですでに数百倍のレベルの差が存在する訳で、
仕方のないことだと思う。

>>1
>オブジェクト指向が理解できない

と言ってる人は読んでる本が悪い場合が多い。オブジェクト指向のアイデア自体は
小学校高学年でも充分理解できるもの。

そもオブジェクト指向とは何ぞや？
これを2.5行以内で書ける？

書けるか書けないかで言えば書けるな。
一行の桁数が指定されてないから、改行しないで書けば一行で。

>>668
もしプログラミング言語を何かひとつでも知ってるのなら、実際にコード見たほうが
却って理解しやすいと思うけど。といっても、VBとかだとちょっと辛いな・・・。

説明するときに、
……とはなんぞや? じゃなくて、
……の効能は? を答えるやつが多いな。

出来ないっていうのは継承すら解んないって事？

やっぱりオブジェクト指向は難しいと思う
万人に理解できるものじゃないよ

合理主義名人間には向いているだろうとおもう
そんな俺が全てを理解しているかといわれればそれはねぇなｗｗ

時には崩して書くけど、時間があるときはきちんと纏めながら一応3層構造でソフト書くようにはしてる

コードを修正した時、できるだけ他に影響が出ないようにしたのがオブジェクト指向と
考えるのはどう？

他人の作ったコードに影響が出ないようにクラスを分ける。
自分の作ったコード内にも影響が出ないように、継承を使う。

>>678
モジュール間を疎結合にするのは
OOに限らず、常識。

>>678
そんなのが今まで出来てない人が多かったからマイクソソフトが3層構造提唱してるんじゃね？

C言語全盛だった80年代ですら、モジュール祖結合の設計・開発が出来る人はいた。
externでべたべたなコードを書くのはDQN。そして、今でもそういうバカは多い。

>>678
>コードを修正した時、できるだけ他に影響が出ないようにしたのがオブジェクト指向と
>考えるのはどう？

そうね。個人的にはこれがオブジェクト指向の最大かつ最も分かり易い利点だと思う。

オブジェクト指向ができない中年は不要。

何が分かればオブジェクト指向を理解したと言えんの？
なんかそういう基準みたいなのはあるの？

>>684
理解の第一段階は、ポリモフィズムの利点が分かるってことが多いみたい。

単なる機能分けだべ？いろんな言語に惑わされるだけでねーの？

>>684
Javaを卒業してC++に入門、オブジェクトとして扱うべき物とそうでないものを明確に区別出来るようになったとき。

オブジェクト指向って言ってしまうから悪い。
オブジェクト指向プログラミングとかオブジェクト指向設計とか分析とか分けてしまえば問題ない。

ＶＢだってＯＯＰできると悟った時、初めてＯＯＰを理解したと判断して良いと思う。

よくオブジェクト指向本で概念だけを一生懸命説明してるのあるけど(>>668が
指摘してる、「車」とか「果物」とか「たい焼き」の例だけで話進めてるやつ)、
具体的な言語を離れて説明してもあんまり意味が無いと思う。むしろ分かり難く
なる。

一番問題なのは、従来のやりかたのアンチテーゼとして位置づけてること。
必ず、「いままでの手続き型ではダメだ」という言い方になる。
開発の現場にいた人間にとっては、今までの延長以外の何ものでもないんだけど、
「やり方を変えろ」「考えかたを変えろ」「それはオブジェクト指向とは違うんじゃないか？」
ということをわかってないくせに言い出す。
「オブジェクト指向では、今までの手続き型と違ってカプセル化ということが・・・」とか、得々と語りだす。

かんべんしてくれ。

>>689
VB6の言語仕様はおかしい、と思えるようでないとダメ。

VBは.NETになってからエレガントな言語になったじゃないか。

receiver.method だから OOP かって言うと
そういう訳じゃ無いんだよね。

多態が解るとOOPLの理解は進むけど
かと言って多態が本質かは疑問。

オブジェクト同士の関係性を
メソッド呼出で表す辺りが本質なのかな。

そうだとするとOOPのの理解は
this/self/me を他のオブジェクトや
メソッドに渡すようになってからかな？

結局、オブジェクト指向言語の個々の機能をもって、
オブジェクト指向の定義とするのは無理があるんじゃないかな。

クラスをつくりメソッドを作り継承をつくった、
そのようなものを作るに至った考え方がオブジェクト指向なんじゃなかろうか。
だから、現在の様態それ自体には深い意味はなくて、方向性というか
ベクトルというか。

例えば、ハイブリッドエンジンそれ自体を指してエコロジーとは言わんでしょう。

ポリモフィズムは単なる第一段階であり、これすら分からないとその先は進めない。

現実問題として、今のところは「Javaの理解≒オブジェクト指向プログラミングの理解」
でいいんではなかろうか。

なので、インターフェイスまわりの利点の体得が次の段階ぐらいだろうか。

ポリモフィズムなんてわざわざ大仰に説明するようなもんじゃないと思うけどな。

まともにプログラミングを経験してれば、それ以前に、

sub( struct A param ) {
　switch( param.type ) {
　case TYPEA:
　　ほげほげ・・・
　　break;

　case TYPEB:
　　ほえほえ・・・
　　break;

　　・・・・

みたいな処理をうんざりするほど書いているはずで、
「いまごろやっと簡単に書けるようになったか、早くしろよな。」
程度の感慨しか抱かないはず。

それをさも新しいことのように言う奴ってのは、
まともなプログラム設計をした経験が無いとしか思えん。

作ってるうちに「お前がやれよ」みたいな責任の押し付け合いが始まって、どのクラスに機能を置くべきか迷うんだ

>>696みたいのが居るから勘違いJava厨が大量発生するんだよ。

700げとー

Javaに挫折したやつほどJavaを否定したがるｗ

>701
基準としちゃ微妙だが
Java資格者でも疑問を抱く仕様の言語を
否定する人が居るのは自然かと。

個人的にはAutoBoxingでちょっと見直したが。

どんな言語だって、なんかかんか問題はあるわけで、
そういうことをもって全否定したりすること自体
なんだかなぁと思うけど。

プログラム言語ってのは個々の開発を離れて
全否定したり全肯定したりするもんじゃなくて、
目的に応じて選ぶものでしょ。

オブジェクト指向って、プログラム言語に依存しないんだけどなぁ・・・

>>704
言語に依存する場面もあるにはある。多重継承のできる(C++)できない(Java)の違いによって設計方針
が始めから変わることもある。

>>705
実装が設計に影響与えるって？
そんなマヌケな設計するなw

>>706
日本語勉強して出直しておいで。

多重継承出来るか出来ないかは言語の仕様であって、設計には何の影響も無いだろ。
ここで影響出るとか言ってる奴は、それはコーディングを設計と言ってるだけ。

>>696
ポリモルフィズムはクラスに付いてくる、たんなるオマケ。

オブジェクト指向（ケイのじゃなくストラウストラップのオブジェクト指向）においては
クラスを抽象データ型の定義に使うのことがキーアイデアだから、出発点とすべきは、
そもそもデータ型がどんなもので、それを定義するときにどんな注意が必要かという点。

継承とポリモルフィズムは、分類上、クラスを使わない抽象データ型との区別には必須だけど、
手法としてのオブジェクト指向には必須とか本質ってことはないし、じつのことろクラスと同じで、
便利だから（適所で）使われている（使うべきな）だけ。

単なるオマケじゃない、大事な中核機能だろ。

オブジェクト指向を理論から入ってる人と、C++などの実践から入ってる人とで、意見が違うらしい。
いずれにしても、言語機能は、オブジェクト指向の部分集合でしかない。事はあきらか

継承や多態を使ってないとＯＯＰじゃないって事か？
そんな馬鹿な話があるもんか。

人によってオブジェクト思考の範囲が違うな。
最低限は、その名の通り、ブラックボックス的な物として見れる切り分けが出来てればOK。
と、俺は思うけどね。
プログラム言語による制限や可読性もあるわけだし。

仕様にあわせて方法を選ぶ。これは目的指向だ

オブジェクト指向にあわせて仕様をねじまげる。これがオブジェクト指向だ

何度言ったらわかるんだ

>>714
の言ってる事はあながち現場では間違っていないと思う
つうか、日常でよくあるあるｗｗｗｗ

C言語の FILE * 使った入出力はオブジェクト指向。

>>716
単なるカプセル化だと何度言えば（ｒｙ

結局、どこからどこまでが OO かなんて
人によって解釈に差があり過ぎるのも
OO の難しいと言われる所以なのかねぇ。

ＯＯの解釈に差が出ること自体がおかしい。
要するに複数のオブジェクトを連動させ
目的を達成するプログラム様式だろ？
継承やオーバーライド、オーバーロードなんて
ＯＯを実現しやすくするための一機能に過ぎないんだよ。

>719
俺も OOP の解釈はそれで良いと思うが…

「おかしい」って言っても、現に
その解釈が通らない人が居る時点で
理由があるハズなんだよな。

って言うか OO と OOP と OOPL とを
ごっちゃにしてる人も多いんじゃないか？

OOPL は OOP し易く作られた言語だが
OOP という言葉というか概念自体は
OOPL が生まれる前からあったハズ。

OOPは継承がないとだめなんだっけ？。
隣の部署にうるせぇやつ居るんだよな。聞き流しちゃってるから覚えてないけど。

>>717
一応与えるポインタ変えると同じ関数でも書き出すファイルが
違ったりするのでオブジェクト指向でいいと思うが。
putc('a', fp); と書くか fp->putc('a'); と書くかの違いだろう。

>721
いんや。
それどころか継承も無いのに
OOPLとされてる言語すら存在する。

>>723
kwsk

JavaScriptとかだろうか

>>668とか見るとＯＯＰとＯの区別がついてないんじゃないかとも思う。
エレガントなＯの作り方に血眼になって、それこそがＯＯＰだと思い込んでんじゃないの？
現場じゃクラスなんて使い捨てなのにｗ

うちの職場ではインターフェイスも使い捨てです。

話ざっくり斬るけど
Object って目的語って意味もあるんだっけ
目的語指向プログラミング…とは
言い得て妙なのかもしれん

本当に目的語の語順が入れ代わってるだけで
実質 COBOL なコードも実際見たことあるし

要はメソッド定義が main 一個以外無いコードな。

アクセッサをメソッドから除外するなら、レイヤ分割したWebアプリって、
それに近い感じになるけどね。

>>726 が何を言っているのかよく解らないのだが
まあ2バイト英字使うような奴の言う事だから気にしなくていいか。

○○Р

んで結局オブジェクト指向とは何ぞやって話に結論は出たのか？

出ない

それは、みなさんそれぞれのこころのなかにあります。

幻のオブジェクト指向

>>734
オブジェクト思考?

>>732
えっ？オブジェクト同士がメッセージパッシングしあいながら出来ていくシステムなら
それはオブジェクト指向じゃねの？

メッセージバッシング：
「ちょっとそこの●●クラスさん！呼び出し元なんだからちゃんと入力チェックしてよ！」
「だ、だってご主人様が私のメーン関数をしつこく触るから…」

>>737
メッセージパッシングは「アラン・ケイの」オブジェクト指向で、
カプセル化・継承・多相性は「ビアルネ・ストラウストラップの」オブジェクト指向。
両者は同じ「オブジェクト指向」を称しているけれど区別して考えた方が幸せになれる。

UMLのクラス図は「カプセル化・継承・多相性」だけど、
相互作用図は「メッセージパッシング」だなあ。

むしろ自分は「手続き指向」の具体的なイメージがわからない
一応15年前からCを使い始めC++に移ってきたんだが

Cのころからソースファイルごとに核となるデータを決めてstatic定義し
そのデータへの処理をまとめて書くようにしていたから
C++に移ってもさほど違和感はなかった
仮想関数がいかに便利か実感するには多少時間がかかったがｗ

自分が技術書とかから模索してそのスタイルを決める以前
会社で目にしたコードといえばcalc_func1(), calc_func2()みたいなの
ばっかりだったから
いまだに「まともな手続き指向」というのをわかっていない気がする

手続き指向ってなんだ？
手続き型ってのは、論理型や関数型との対比じゃなかったっけか？

オブジェクト指向と対比されるのは、機能によるモジュール分割じゃないのか？

なんか外部モジュールに殻を被せて
呼び出す時に内容を動的に変化させる事が可能。
こんなイメージなんだけど....

OOPを純粋に何かを成し遂げるための技術だと思うと
OOPの意義も手続き志向との対比もわからなくなると思う。

OOPってモデル化の「技術」に過ぎないんだよね。（過ぎない、は過小評価してる訳ではない）
そしてモデル化が必要な理由は人間の認識能力に限界があるから。
OOPが優れているのはそれが人間の認識能力の特性とのマッチングがいいという点だけ。

インベーダを動かすという「動作」を、インベーダのハンドルを引数にとる関数に抽象化するよりも
インベーダという「存在」をクラスに抽象化して生成したインスタンスに
動けと命令する形態の方が多くの人間にとってはより直観的だと。

まあその程度のことだよね。

その辺が腑に落ちてないと派生だの多態だのむしろ副産物に過ぎないものが
OOPの本質だ、などとトチ狂うわけで。

>>742
俺もそう思う
手続き型のプログラミングと OOP は同時にするものだよな？
まぁ関数型言語で OOP してたら知らんが…

OOPとは何か、を具体的に書いた本って無いの？
そういうのが無いから直感的にOOPを理解できず
モヤモヤしてた連中がデザインパターンに飛びついちゃってんだよ。

>>744
> OOPってモデル化の「技術」に過ぎないんだよね。（過ぎない、は過小評価してる訳ではない）
技術というよりは方法論だと思うが同意。

> その辺が腑に落ちてないと派生だの多態だのむしろ副産物に過ぎないものが
> OOPの本質だ、などとトチ狂うわけで。
抽象的なモデルで表現、設計するのは本質だと思うので、派生だの多態だのは副産物というよりは抽象性の表現手法じゃね？
抽象化の側面についての議論なら、トチ狂うは言い過ぎかと思うが。


>>745
手続き型とオブジェクト指向は、むしろ直行する概念じゃね？

俺は明らかに手抜き指向。

OOPの本質を一言で表現するなら「めんどくせえ」だろ？

そういう面で言うなら、
「めんどくさいことをしないためにはどんなめんどくさいことでもやる」
ということになるんじゃなかろうかね。
まあ、OOP に限った話じゃないけど。

>>741
いくつになっても勉強はできる。精進しろよ。

仕様書無しさんはふしぎなじゅもんをとなえた。

Java厨はこんらんしている。

少しワルに生きてみな。＠マ板　　
1 ：仕様書無しさん ：03/06/15 21:51
今まで見えなかったものが見えてくるぜ。
http://pc8.2ch.net/test/read.cgi/prog/1055681482/l50

意味の単位を抽象化できるのがオブジェクト指向のいいところだ。
手続きだとその処理単位でしか意味を作れない。だから同じものが
繰り返される。
日本語や英語と一緒だ

意味がわからんなw
理解してないなら無理することないのに。

>>754
オブジェクト指向は「意味の単位」とやらを具体化してるんだと思うが。

フレームワークとかクラスライブラリは、継承を効果的に活用しているが、
受託で開発されたようなシステムで、なるほどと納得するような継承って
見たことないな。
大概、変数と処理の共有のためだけに無目的に継承してるような感じで、
staticメソッドとかユーティリティクラスに分類した方がいいような
汎用的な処理もごちゃまぜになってたりする。
継承ツリーがフレームワークとアプリを堺にして、ビューティフルなコード
からダーティなコードに一変する。
素人は下手に独自の継承構造を盛りこむより、単純にフレームワークからの
一次継承までに留めておいた方がいい。

世の中には継承使ってバージョン管理するような変態も居るらしいからな。

なるほど、そりゃいいな！　あとで見る時にどの機能が追加になったのかが分かり易いし、
機能変更はオーバーライドを使えばいいわけか。目から鱗が落ちたよ。サンクス。

勘違いも甚だしいと思うけどね。

継承構造ってなんのことかさっぱりわからんが、
もともと継承っていうのはその程度のものなんですが。

>>757
じゃあ、綺麗な継承の書き方について教えてくれよ。俺は絶対作りながら
他人に感心されるレベルの使いかたは無理だ。

ドメインを定義し関連事項を分類整理して抽象化すれば自然とクラス分けも
できてくると思うがな。要は作る前にクラス設計をちゃんとやれってこと。

>>762
だからわかんないなら無理して話題に参加するなってw

自分の論点の根拠を示さず、要求だけを押し付ける奴、特に文末にwをつけて
滑稽さをアピールする奴の文章ほど説得力に欠けるものは無い。

>>762はなんつーか問題の本質を判らないときでも、とりあえずこれを言っておけば場をしのげるみたいなもんだ。
「だから何？」って感じ。
現場の人間にとっちゃ「パス」のカード。半端に勉強した上司が首突っ込んできたときにもこういうこと言うなぁ。

>>765の言ってることも、「だから何？」って感じ。
まず判明している事柄とか資料説明の中から名詞を洗い出してみ、それから必要と思われる
名詞だけを抽出してみ、お互いの関連性を整理してみ、動詞から処理を洗い出してみ、共通
部分とか共有部分は無いか調べてみ、インターフェースを抽出してみ、パターンが適用でき
そうな部分はないか考えてみ、とりあえずプロトタイプ作ってみ、問題がありそうならリフ
ァクタリングしてみ・・・とでも言えばいいのか？　どこまで、こうでちゅよ〜って説明す
れば納得するんだ？

なんかプログラム書いたことない人みたいだけど、
別に改めて「洗い出し」なんてことをしなくても
普通は継承が適用できそうな個所ってのは自ずとわかるんだよ。

こんばんみ^^

実戦に使えるOOPって感じの本って無いの？

>>767
自ずと解るってどのレベルの問題だと解るの？
JBOSS 1.3ぐらいのころに俺もJBOSSと同じような
ものを会社の研究で作ったことあったけどあんなに
うまく継承などOOPできなかったよ。

こんなことから言わないとダメかなあ。。
継承はうまく使えば確かに強力。
だからって継承を使うときは常にエレガントに使わなきゃいけないわけじゃないでしょ。

使うことによってなんらかの便益があるならそれだけで十分継承をつかう理由になる。
当たり前でしょ。

>>766
まぁいいから黙っとけよｗ

では、>>758-759のような目的での継承もありと？

>>771
だから何？

なんか入門書を読んだだけのおっさんが混じってる気がする。。
「キーワード」を散りばめた文章はいわゆるコンサル様を髣髴とさせるよ。

抽象的に言えば知ったふりするなと言い、
具体的に言えば、そんなことは感覚的に
わかる等とオカルト発言する奴がいるな。
長文でもいいから判りや易く説明してみてくれ。

ここの連中はエレガントなソースをクラス図付きでみせてやらないと納得しませんよ。
それでも認められないだろうけど。なんせ俺こそは実践派のOOP理解者だと思っているから。

まあ結局は動くプログラムを納期までに完成させることのできる奴の勝ち。

プロジェクトメンバー以外の他人（素人）に説明できるかどうかってのは、
プログラミングとは別の能力。
だからこそ、コンサルタントとかテクニカルライターとか大学教授みたいな
商売が成り立つ。

実践OOPの本紹介してくださいここは世界最高峰の実践OOPができる
人間以外書き込みをしてないといわれました。

>>778
まぁ、ごり押しで納期に間に合わせようとすると、コピペとか1000行メソッドとか
エレガントさのかけらもない力技のソースが湧いてきがちだけどな。それも必要悪なのか。
でも、その場は凌いでも、あとで関わる奴らにとっちゃ迷惑な話だけどね。

インナークラスとか無名クラスも知らねぇような奴はJava厨ですらねぇ。ただの精子だ。

>>776
どうでもいいからお前は出てけw

分かった。そこまで言うんなら俺は出ていくよ。いろいろ世話になったな。
おっと、この低能発言は受け取れねぇ。ここに置いとくぜ。じゃあな、あばよ。

つ「だからわかんないなら無理して話題に参加するなってw」
　「まぁいいから黙っとけよｗ」
　「どうでもいいからお前は出てけw」

>>783
いや、俺の発言だけは持っていけ。
お前にも理由が必要だろう。
つ「どうでもいいからお前は出てけ」

自作自演を疑っているようなら残念でした。

ひょっとしてお前ら具体的なお題を与えないと具体的な話が出来ないんじゃないのか？

うん、だってそんな禅問答みたいな話してもわからないし
車とか野菜とかの話じゃ市ねって思うし

>>780
でもそれじゃあ、二回目、三回目の機能変更なり、メンテナンスで破綻するだろ。
結局、「動くプログラムを納期までに完成させることのできる奴」とはいえない。

そういうことにならないように、「オブジェクト指向を生かせる」ってことが、
「オブジェクト指向が理解できてる」ってことでしょう。

この世の森羅万象ありとあらゆるものは神がつくりたもうた分子なるクラスの
インスタンス同士のリンクで成り立っておる。分子同士がメッセージを交換し、
化学反応を起こし、様々な自然現象たるイベントを発生せしめ、物理法則という
手順に従って様々な事象が時間というライフラインの中で動いておる。
人間も様々な継承を経て構成されているものの、突き詰めて考えれば、分子の
コンポジットパターンに過ぎないのじゃ。
人間の基底メソッドとして恋愛する()というものがあるが、これは、異性のイン
スタンス同士が様々な外因により惹かれ合い、メッセージ交換し、ドーパミンオ
ブジェクトを内部ファクトリから生成し、体内オブザーバに引き渡し、行動のイ
ンセンティブを変化せしめ、愛情ステートを相互に育んでいくという手続きによ
るものぢゃ。
OOPに迷ったら、自然に戯れてみることじゃ。神のつくりたもうた良いサンプル
がるのぢゃからな。フォフォフォフォフォフォ。

>>785
具体的な例を挙げちゃうと、なおさら話が出来ねえだろw

オブジェクト指向はオブジェクト指向だ。
例え話を持ち出しても理解できない人間は例え話抜きに調べる必要がある。
第一俺は例え話で長ったらしく説明されるよりも、仕様と（少しだけのコーディング例）を提供してくれれば
直ぐに理解できる。

仕様とコーディング例だけで直ぐに理解できるかは、そのクラス群の規模によるんじゃないか。
いくらなんでも、MFCとか.NET Framework クラス ライブラリとかEJBを直ぐに理解できるとは思えん。

どうしちゃったんだよおめーら。
ちょっと前にオブジェクト指向が分からん系のスレ立てた時は
ﾊﾞｶｽwwwって感じで馬鹿にした後
ラーメンを例にとって継承の説明し始めるような馬鹿ばかりだったってーのに
ずいぶん流れが変わってんじゃねーか。

メモリレベルで継承メソッドの選択のされ方（仮想関数テーブルの構成）とか、オブジェクトの
配置とかがイメージできるようじゃないと本当にOOPを理解したとは言えないよ。
要は、OOP言語を作れるぐらいの知識が必要ってこと。

スモちゃんでもきゅもきゅしながらOOPできれば
他の言語に持っていくときは言語の制約とシンタックスシュガーを
入れて解り易くできるかだけじゃないの？

>>794
すまん、俺が悪かった。意味がさっぱり分からん？スモちゃんでもきゅもきゅ？？？

>>793
よし、それを卒論にでもまとめるんだw

純粋なＯＯＰだけでＯＯＰ言語作れるＯＯＰ言語なんて皆無

>>793
プログラムが動く媒体の事を言ってるんじゃない。
俺は、例えば無しなんかしなくても、『こういう風にコーディングできますよ』っていう事を知ればそれで十分と言いたい。

samlltalkで書いてまぁ動けばOKでいいと思う
それを2,3日後に見直してまぁOKだったら論理的な実装はOKにする
その後言語の選定をしテストコーディングをすればいい。
下手にUMLとかでお前しかよめねーよっていうのより動くコード
あるほうがうれしいよ

ところで、今、Smalltalk の使える（フリーの）処理系ってあるの？

>>800
Squeakでもいいし業務で使うことなんてありえないから
VisualWorksの非商用版でもいいと思うよ

>>801
ありがとう、やってみます。

自演乙

>>801
>業務で使うことなんてありえない
俺が新卒で受けた会社のうちのひとつはSmalltalkメインだって言ってたな。
SAPかなんかをオモに取扱ってるそこそこ大きい会社。

確かにプロトタイプがあるといろいろ便利だが、SmallTalkで書いて動けば設計が（まぁ）保証されるなんて考えは論外。

>>805
そりゃそうだけど、なんで 799 に対して「保証」なんてあるべき論を？

>>806
意味不明

>804
SAPとSmalltalkの組み合わせって、あるのか．．．
まあ、abapオブジェクトは色々頑張れないものね。

>805
ソースコードを見れば、どう動くかはわかるけれど、
書いた奴が、どう動く積もりでいたかまでは分からないね。
動けばいいやってPGは、後で面倒見る人には迷惑ね。

エレガントなクラス設計、ていうけど
細かな責任や役割を明確に分けて見た目に綺麗なクラス設計をすると
アホみたいなクラス数になって、結局管理しにくくなると思う。

顧客の要求をクリアした上で性能、「その案件で必要そうな」拡張性、保守性などの非機能要件を考えてクラス設計すれば
おのずと「エレガントなクラス設計」からは外れると思う。

案件上どー考えても修正・追加が出なさそうな機能を10だの15だののクラスを作ってまでOOPで実装する必要なんて
あるのかねえ。

オブジェクト指向の本質はデータのカプセル化にある。
クラスを作るときは型を作ると思え。

Effective C++の金言。
>>809が言うように責任や役割などという言葉に捕らわれすぎると泥沼に陥ると思う。

10や20のクラスで悲鳴上げてるようじゃ何か根本的に勘違いしてると思うよ。
アホみたいなクラス数になっても普通なにも問題ないから。

たとえば.NETのクラスライブラリに何千のクラスがあると思ってるの。
クラスが多すぎてマイッチング、なんていってるのはOOP的は発想ができない
VB6からの以降組の一部だけだぜ。

>>810
データのカプセル化なんてCどころかアセンブラの時代からやってるじゃん。

だから、そのデータのカプセル化を（SIMULA由来の）クラスを使ってやるのがオブジェクト指向なんだ。
って、何度言ったらわかるんだか…。

アセンブラ厨って脳が退化してるんだろうな

うーん、あのね、哺乳動物ならみんな持ってる特色、
たとえば恒温性をもって人間の本質だとか特徴だとかは普通は言わないんだよ。

>>811
日本語でおｋ
>>815
意味不明

そら馬鹿にはわからんと思うよ。嫌味っていうはそういうものだ。

Googleはオブジェクト指向？

>>817
バカの言うことも常人にはわからん。
こうして断絶が生まれていくのだな。あっちいけ。

で、オブジェクト指向が理解できないマがどんどんこのスレを埋めて行く・・・

>>813
>データのカプセル化
データだけカプセル化するんですか？

OOP なら少しは解るが
アセンブリはさっぱり解らんな
頭の良し悪しでなく根本的な構造が違う希ガス

http://pc8.2ch.net/test/read.cgi/prog/1122318533/530

オブジェクト指向の概念の発明者は誰ですか？
http://d.hatena.ne.jp/sumim/20040525/p1

>>811
アホみたいなクラス数って性能に影響でるんじゃねの?
クラスライブラリみたいに、使うか使わないかわからんけど、とりあえずおいとくものと違って
機能を実装するのにクラスを15作れば、間違いなく15のクラスがnewされるじゃん。スコープとか言うなよ。

俺の経験だと一番時間かかるのはインスタンスの生成と廃棄だと思うんだけど、違うの？

>>824
思考能力ってものはないのか？
仮にインスタンス生成は多くのCPU時間を消費するとする。

しかし、お前さんはたとえば秒あたり10万とかのインスタンスを
継続的に生成/破棄したりするようなコードを書くの？
フツーはしねえべそんなこと。

「>>809が言うように」などと書いたが、こいつに賛同したことは撤回したい。

>>824
一番かかるのはあんたがオブジェクト指向をまじめに勉強しようと思うまでの時間

オブジェクティブサップ〜

いや、例えばWebなら
１ターンラウンドで15のクラスがnewしなきゃいけない実装なら
1万ユーザが同時にアクセスすればそれだけの負荷がかかるじゃん。
そういう時は俺、あえてクラス数減らす設計するけど、他にいい方法があるの？

もういいから黙れ。
その職場から出てくるな。

>>830
答えられないなら黙ってればいいじゃん。
答えられる人に聞いてるんだよ。

>>829
もういいから黙れ
国へ帰れ

>>809
そもそもこのバカはなんの為にクラスを使ってるんだ？
つか、クラス設計がまんまモジュールなんじゃね？VB厨みたく。

>>833
何のためって、データと振る舞いを機能性格上からクラスのかたまりに分けることで
拡張や保守をやりやすくするためじゃねの？

>>834
じゃ速度の話なんか持ち出すなよ

>>835
だから性能とアホみたいなクラス数はトレードオフの関係だろ？
だったら>>809のように、間違いなく修正・追加が出なさそうな機能にアホみたいにクラス数かけるのは
意味なく負荷かけてることになるじゃん。

あくまで客は普通サクっと動くことが第一条件なわけで
拡張性とか保守性はいわばこっちの都合じゃん。

Javaや.netの案件やってれば、こういうトレードオフって当たり前に考えるものなんじゃねの？

>>836
非機能要件（速度とか）ってアーキテクチャで解決するもんであって





やっぱりいいや、国へ帰れ
めんどくせ

>>837
「あーきてくちゃ」なんて随分範囲のあいまいな言葉持ち出すもんだな。

ていうかお前はPGの立場で案件に関わるときは
非機能要件はアーキテクトに丸投げか。おめでたいな。

なんでインスタンス生成をそんなに目の敵にするのかね。
このWeb屋さんは。

どっちかっつーと809のほうがおめでたい香具師だとおも

>>839
別に目の敵にしてるつもりはないんだけどさ、
Web案件だけじゃなくてもハードの資源を無駄に使うことは避けるべきだと思ってて、
でもそれを犠牲にしても拡張性や保守性を取った方がいい場合ももちろんあって。

だからOOPで設計するにしても、どこまで細かくやるべきなのかって
案件ごとに悩むもんだと思ってたのさ。

でも>>811のように「アホみたいなクラス数になっても何も問題ない」って言うやつがいて
他のヤツも概ね同意みたいだったから、
もしかしてクラスをバッカバカ増やしても性能に影響がない方法があるのかな、と思ってレスしてた。

でも大して有益な情報が出てくるわけでもなさそうだから、もうそろそろやめるわ。
ごめんな。

どの位差が出るか位自分で計測してみれば？(使い方にもよるけど)

ほれ

import java.util.Calendar;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;

public class Main {
public static void main(String[] args) {
Calendar c = Calendar.getInstance();
c.add(Calendar.SECOND, 3);
for (int i = 0; i < 10000; i++) {
new Timer().schedule(new TimerTask() {
public void run() {
long start = System.currentTimeMillis();
for (int i = 0; i < 15; i++) {
Date d = new Date();
}
long end = System.currentTimeMillis();
System.out.println((end - start));
}
}, c.getTime());
}
}
}

【社会】 連続レイプ魔か？ 女子大生を突き飛ばして強姦致傷、鬼畜男逮捕…埼玉
http://sports9.2ch.net/test/read.cgi/fish/1162985824/

>>841
別にクラスの数は性能に影響ないだろ?
インスタンスの数のことを言ってるのか?

ヒープ管理に速度的なボトルネックがあると言いたいんじゃね？

>>841
クラスの数を見た目減らしても、インスタンス1個1個のサイズが大きくなるだけならいっしょでしょ。
そもそも、クラスはインスタンス化される回数に関係なく、ロードされるのは1回だけだし、
ターンアラウンドタイムなんかとは関係ないよ。（1回目が遅いってのはあるかも）

ただ・・・「無意味」なクラス分けを指示してくるSIerとかがいて、
アホみたいにクラスが増えることはたまにある。クラス数に拘るのはヘン。

>>847
>無意味な
現実をマジに再現しようとしているんだろうな。

100や200のクラスを単純にnewするオーバーヘッドより、データベースやファイルへ
のI/Oや通信上のボトルネック等の方がよっぽど負荷がかかるっつちゅーの。
お前らが何気に使っている、Connection や RecordSetのメソッド一つ々にどんだけ
負荷がかかってるって思てけつかんねん。
クラスが必要ならどんどん作れよ。インタフェース、抽象クラス、インナークラス、
無名クラスも使えばいいだろ。継承もどんどん活用すればいいだろ。
ある目的を得るための処理の全体量は、適切にクラス分割されて共有化を図り、
冗長性が排除された設計の方が、絶対に性能もメモリ効率もいいはずだ。
オブジェクト生成の負荷にことさらに神経質になるのはおかしい。

>>849
では、データベースやファイルへのI/Oや通信がない（あるいは非同期な）システムだと、
多クラス構造がボトルネックになるのですね？

仕事がヒマだからそろそろ有益な情報を提供してやる。



ボトルネックがどの程度，範囲なのかでも変わってくる。

システム全体を見て、比較的処理時間が多い部分をボトルネックと呼ぶなら、
たしかにインスタンス生成なんかはそう呼ばれるかもしれん。
しかしその時間ってミリ秒程度で、システムのレスポンスが遅くなるかどうかという問題にはほとんどならない。

それよりは、DBやファイルへのIOの方が遥かに時間がかかるので、
インスタンス生成なんかの時間なんて無視できる範囲だというのが一般的な意見


そしてクラスっていうのは多ければ多いほど良いというものでもない。
システムの範囲と機能を明確にし、そこに出てくる機能や動作を実現できる最小限の構造をクラスとして抽出するほうが良い。
多くても構わんがね。無駄だ。

例えば、
タイヤ生産システムで材料（ゴム）というクラスは出る可能性はあり、
自動車販売システムでタイヤというクラスは出るが、材料というクラスは出ない
という感じ。



長文だが立て読みじゃないぞ。
ヒマだから誰か相手してくれよ

つうかジャワでどんなに最適化してもしょせん無駄な事

>>838
基本的にPGは組むだけ
速度は基本的にアーキテクトが設計したアーキテクチャにお任せ

正直PGレベルがコーディングでいくら頑張って速く，軽くしても、
アーキテクチャの良し悪しで変わる速度，メモリ使用量の方が遥かに影響が多きい。

>852
何が無駄？

>>853　アーキテクトとおっしゃる方が全体を見越した設計してくれてるなら言うことないです。
・・・ははははは・・・・・

>データベースやファイルへのI/Oや通信がない
済まない、想像がつかない。

>855
オメーみたいなクソPGが居たらアーキテクトさんも面倒見るの大変でしょうね

>856
メモリ上で全てやるんでしょ

>>847
クラス数を減らしてもコード量は単純な足し算にはならないから
どーだろ。
で、ロードが1回でも単純にnewに時間がかかるのでは。

>>849
同じforループの中で
クラスを100回newするのと
connectが繋がった状態で
100回SELECT文を発行するのとでは

後者の方が早いと思うのは俺だけだろうか。

DBにSELECT文を発行して結果を表示するプログラムで

クラス1個とクラス10個では

スクリプトで100万回同じ処理を繰り返しても

違いがないのだろうか。

>>858
それはネットワークとDBサーバ・DBによるんで微妙なんじゃね？
そして、そのクラスも同じでコンストラクタで何か重いことやってんなら微妙だし

作り・環境によるだろ

俺が見たひどいのは1機能１DLLになってて1つの処理する為に
DLL10個も必要としてた
どうもDLLから別のDLL呼び出してる依存関係が複雑に絡んでるようだ

こんなクラスはいらない

>>860
plugin とかだとそういうことはあるが・・・。

俺は業務系だからわからんけど
組み込み系ってのはクラス1個に全部詰め込むんだろ?

それはクラスが増えると性能的にまずいからじゃないのか?

ジャワ糞どもが不毛な最適化を語っています

クラス=Javaですかそうですかｗ

オブジェクト指向の目的については置いといてだ。

SELECTがどーとか言うやつおるけどさ、
SELECTした結果をnewして値を放り込むんだろ？ｗ
その時点でSELECTの方が遅いのに気づけよ。

>>865
ん？SELECTした結果を入れる器なんて1個でいいだろ。
要はDBとのI/Oはインスタンスを生成するより本当に負荷がかかるもんなのか、ていう話なんだから。

それより
＞オブジェクト指向の目的については置いといてだ

なんで主題をおいとくんだよｗ

昨今のハードウェア性能からすると、オブジェクト生成時間は無視できる範囲である。
システムが複雑化し寿命も長くなった今日、そんなことを気にするよりも、
保守運用性を向上させるという目的でオブジェクト指向設計を行う方が有益である


以上

業務系が不毛な最適化について語っています

　∧⊂ヽ　 ／￣￣￣￣￣￣￣
(ﾟДﾟ,,)ﾉ　＜ ギョームケー！！
　| ⊃|　 　 ＼＿＿＿＿＿＿＿
　|　　|
　⊂ノ〜
　∪
　川


　　∧ ∧ 　 ／￣￣￣￣￣￣￣
　　(,,ﾟДﾟ)＜ ・・・って何？
　　/　　| 　 ＼＿＿＿＿＿＿＿
　 （,,＿/
／

ハードにアクセスした上でさらに抽出アルゴリズムが実行されるDBアクセスの時間と、
メモリ上（クラスがロードされた上での話）でのオブジェクト生成にかかる（コンスト
ラクタ内での処理は除く）時間がそもそも比較の対象になってるのが不思議だ。
オブジェクト生成　→　CPUとメモリ内で完結
DBアクセス　→　CPU,メモリ、I/Oポート、コントローラ、ネットワークカード、通信回線、ハードディスク、を経てデータを取得
キャッシュの性能を加味しても、結果は明らかじゃね？
ハードの性能が上がりすぎて、速度的な感覚が麻痺してんのか？

組み込み屋さんから言わせてもらうと、中途半端なオブジェクト指向のせいで、
製品の操作性が犠牲になるほど遅いシステムくま

newする相手がハードディスクにいるDLLの中の人だったら？

DLLの中に人がいても、その人は最初の1回目はよっこらしょとディスクから呼ばれてのこのこ
出ていくだろうけど、次からはその人はメモリに居座っちゃってるからパッて現れるっつうの。
なんのためにOSって神様がいると思ってんだ？　神様は馬鹿じゃない。

つGC

GCはインスタンスを破棄するのであってクラスを破棄するわけではない。

　　　??
　　∧ ∧
　　(,,ﾟДﾟ)
　　/　　|
　 （,,＿/
／

ジャワ糞どもが知らないくせに背伸びをしているようです

>>871
どんなクソなハード使ってんだよ

携帯に30MBのアプリとか作ってのせようとして何億もそんしたとこなら知ってるぞ

C使いの俺には、嫌java厨は妬みや僻みにしか見えない

オブジェクト指向が理解できないやつが、ひたすらOOPの悪い点（と思うところ）だけを突いてきてんだよな

むしろいまさら手続き型言語で開発するなんて信じられない。
オブジェクト指向とジェネリックプログラミング無しで開発なんてバカバカしくてやってられん。

>>875
>クラスを破棄するわけではない。

ウチの会社のアフォ共が作った糞ライブラリだけを一括破棄してくれるGCが欲しい・・・。

どうでもいいから動くプログラムを書いてくれ。
OOxN の抽象的な話はそれからだ。

オブジェクト指向で、とは言われるけど機能による仕分けがよくわからないから、1つのクラスに全部押し込める。
あと、privateな変数にアクセスする関数をいちいち作るのが面倒だから全部publicにしたりとか。
なんつうか、C++って無駄なコード書かされるから、恐ろしく生産性が低く感じる。
これってオブジェクト指向のせいだよね？

>>885
おまいのせい。
おまい一人で作業する分には、生産性が高くなるように工夫すれば良いだけでは？

とりあえず動けばいいって考えるのがヘボグラマーの特徴。

スパゲティソースになって困るのは自分なのに。

>>885
メモ帳かなんかで、バーッと書いて、一回使ったらおしまい、
というようなプログラムでは、確かに生産性は下がるかもしれん。
ある程度以上の規模のプログラムで、変更への強さとか、再利用性とかを上げていこうとした場合の、
トータルの効率を上げようとすると、ありがたみがわかる。

>あと、privateな変数にアクセスする関数をいちいち作るのが面倒だから全部publicにしたりとか。
>なんつうか、C++って無駄なコード書かされるから、恐ろしく生産性が低く感じる。

まあ結局そういう部分は開発環境がサポートしている
（アクセッサの自動生成とか、コード補完とか）
ので、最近はあまり不便に感じなくなった。
SmallTalk のころから思ってたけれど、オブジェクト指向言語は、開発環境あってこそのもので、
プレーンなテキストエディタしか使えない環境では現実問題として、使えたものではない。

>>887
それでいい場合もある。
Perl の本とか読むとそう思う。

ケースバイケースで使い分ければいいだけなんでは。

規模と用途はポイントだね

オブジェクト指向やってみました、みたいなコードを保守する羽目になってしまった
オブジェクト指向スパゲッティソースてんこ盛りで胸焼けしてます

俺はオブジェクト指向にこんなに詳しいけど何か？
こういう奴ばっかだよね、実際。
特にJAVA厨とPHP厨に多いんだが
こいつらがオブジェクト指向を現場で実践して成功した事例って
今まで一度も聞いたことが無い。
んじゃOOって具体的に菜にやってんのよって聞いたら
闇雲に継承とオーバーロードとオーバ−ライド。
かえって効率悪くなってねえ？ｗ
意味ねーってｗ

>>891
お前頭悪そうだなｗ

>>891
ラップみたいだな♪

速さにこだわる奴は全員、マシン語で書いてろ

アセンブラっていうんだよオコチャマくん

アセンブリ言語をマシン語に変換するのがアセンブラってならったよおじちゃん

マシン語直打ちできたらカコヨクね？

いや、普通。

>>897
今時そんな事してたら馬鹿だと思われるよ？

いや、ハード設計してる人達は普通にやってるから。

マシン語って二進値だよね？

そりゃデバッグ中のパッチはハンドアセンブルだが
全部それで書く莫迦もいないでしょ。

>>901
ふつー、16進。

マジンゴー！
パイルだお！

>>1
>オブジェクト指向が理解できないPG

ん〜、困ったね。それはホント困ったね〜〜。
PG辞めたほうがいいんでねっか？？

オブジェクト指向を理解しているPGは、
オブジェクト指向を使わないという選択肢を選べるPGである。
分かってない奴ほど、むやみに使いたがる。

明らかにオブジェクト指向設計が適用できないプロジェクトで、
やたら「オブジェクトオブジェクト」って言いまくる奴おるよな。
んで中身見たらただ単に共通化を極端にやりすぎてるだけで、
言ってみればメソッド指向的なものだったりして、ソースが追いにくいだけ。

周りも分かってない連中で「よく分からないけどすごい」なんて言うもんだから調子に乗っていく・・

なんか叩きがいのありそうな香ばしいのが寄ってきたなおいw

>>908
どの発言に対してどう思うのかを具体的に指摘すると
拙い事でもあるんですか？

>908
叩いてくれよ

>>897
７行スレに実際あるぞ

オブジェクト指向もいいが迷惑かけるな！
お前の糞オブジェクト指向メンテする・させる身にもなれ！

開発現場にオブジェクト指向は無用！！

実行速度、パフォーマンスを犠牲にせずに、オブジェクト指向を実現しようと
した結果が、MFC。要するに妥協が必要なのよ。

>>913
流石に今更それじゃ釣れないんじゃね？

オブジェクト指向はある程度は必要
これでFA？

オブジェクト指向で開発するにしても、ある程度の妥協は必要。
これでいいと思う。

妥協とか適当とか、そういうの嫌なんだよね。
俺的に許せないって言うか・・・

>>918
んじゃ趣味でやってくれ。
くれぐれも外に出るなよ。

オブジェクト指向設計をするためには、開発メンバー〜運用メンバーの知識レベルが揃って無いと意味がないんじゃないかと思う今日この頃

そう考えると、運用メンバーでオブジェクト指向を理解できてる人が少ない現状で、
開発からオブジェクト指向を取り入れるのはあまり良くないのではないかと思ったりしてしまう。。。

へっ?オブジェクト指向==馬鹿コントール牢屋はめ込み誘導指向

運用の人でも「このスイッチを押せばシステムは起動します」
というようにエンドユーザが使いやすい仕組みを作るためのものだろ?
本末転倒だなw

どうでもいいが荷物を積みすぎた船でオブジェクト指向をやると
失敗するぞw

>>921
>というようにエンドユーザが使いやすい仕組みを作るためのものだろ?
ここまでトンチキな珍説は初めて見ました。

さあさ、荷物をどんどん積んで沈没しましょう

Javaがオープンソース化されて、亜流が出て来て大発展。
オブジェクト指向言語の大勝利。

>>920
禿同。いっちょまえに用語振りかざしてるから突っ込んだ質問してみるんだけど、
実は何にも分かってないってのはよくある話。とくに運用側の知識の無さは殆ど
絶望的。まあ、運用側にこういう知識期待してもしょうがないんだけどね。

だから運用にスキルを求める開発側ってどういう神経しているか
理解できんな。「俺たち奴隷の足かせでOOしてるんだぜ、運用側も
俺たちの苦労を少しは分かれよ」って気分なのかしらん。

ここで偉そうに語る人ってピントがずれているよね
虚勢張ってないと精神のバランスが取れないんだろうな…

>>923
間違ってないと思うけど....
クラスライブラリを作るまでは精鋭部隊を送って
クラスライブラリを使う側の実装部隊は土方で安く上げてるだろ？

>>929
>>921 の
>エンドユーザ
が
>クラスライブラリを使う側の実装部隊
を指すという発想は無かったわｗ

言い訳スキルだけ立派だなﾌﾟ

エンドユーザって普通は開発部隊を指さないでしょ
システムを使う側じゃね？

オブジェクト指向ウンヌン以前にシステム用語勉強して来い

前々から疑問に思ってたんだが
お前らが言う運用ってオペレーターの事？

>927
お前は一生同じシステムの運用でもしてろ


オブジェクト指向はちゃんと理解できれば設計メンバー〜運用メンバーまでの開発部隊が幸せになり、
システムの品質は上がり、工数が下がり、最終顧客までも幸せになるものなんだよな。ホントは。

運用メンバーまでの開発部隊？

がははははは〜
OO宗教の椰子ってどうしてこうも馬鹿ぞろいなのかな

アンチはOOを理解できない馬鹿ぞろいなのかな

>935
気がついた。
>934か、その周囲の該当者は、「運用」ではないことを、「運用」ということでやらされている。
つまり、バグバグのシステムを納品した後、瑕疵担保責任の担当にされているやつらだ！

運用って、システムをメンテナンス（バグ改修），改造（仕様変更），機能追加していく人達で、開発側と言っても過言ではないと思う

>>939
しょぼい会社にお勤めなんですねｗ

なんという運用の定義なのだwww
話にならんな、ジャワ糞OO軍団は。

ようは取れないバグを一生面倒みる会社なのだなwww

取れないバグを星の数ほど作りこめるのはジャワ糞OO教の得意技だからなw

>>934
>オブジェクト指向はちゃんと理解できれば設計メンバー〜運用メンバーまでの開発部隊が幸せになり、
>システムの品質は上がり、工数が下がり、最終顧客までも幸せになるものなんだよな。ホントは。

所詮叶わぬ理想と分かっていても、毎日アフォの相手やら尻拭いばかりしてるとそう考えたくもなる。

とりあえずさ、やってみようよOO。
結果でなかったら、その時に考えればいいんだから。OO風に。

やってみようってw
やってない人さがすほうが大変でしょう

ｺﾎﾞﾗｰは置き去りですか、そうですか。

ｺﾎﾞｰﾗはジャワ糞と等価だろ

そういや一時は盛況だったOOのセミナーも廃れたな。

OOのセミナーって講師がOOをわかってないパターンがおおくね?

わかってねえパターンでわかったつもりになれるのがOO

ジャワの直線的ビジネスロジックを書いてりゃ
OOできてるつもりになれるのがいかんな

OOで飯喰ってたエセ技術系著作家も、廃業だって嘆いてた。

詐欺のアルゴリズムとOOってすごく近いと思う

ちょっと前までは、OOだけでご飯三杯はいける、なんて言ってたのにねﾌﾟﾌﾟﾌﾟ

喰いっぱぐれないように、わざと難解な部分を残しておく。先生方やコンサルの常套手段。

なんかオブジェクト指向が理解できないPGがうじゃうじゃ湧いてきたな

ｼﾞｪｰﾝ

ジャワとOOの世界感ってやっぱり詐欺のロジックなんだなw
http://pc8.2ch.net/test/read.cgi/prog/1159232877/401-404

そういやJavaとJavaScriptを混同してたバカ新人が派遣先で首になったらしい。
今は、そいつをどこに押し込もうか思案中ｗ

>959
マジックでヒゲ描いて、同じ会社に送っちゃえ！

>>949
というか、OOに限らずこの業界のセミナー・スクール講師はスキル的に怪しい奴多すぎ。

>>955
残してんじゃなくて、単に彼らも分からないだけ。

安倍首相の所信表明ぐらい怪しい

>>939
＞運用って、システムをメンテナンス（バグ改修），改造（仕様変更），機能追加していく人達で、
それはリリース前なら製造、
リリース後なら保守というのでは。。。

>963
問題は、>>939のようなことを「運用」と呼んでいる場合、本来の運用の作業を誰が行っているのか．．．

本来の運用ってなんですか？

保守ってなんですか？

>965
バッチのスケジューリングや、ハードの交換なんかを担当していると思う。
エンドユーザが昼間しか使わないシステムでも、夜間処理を含めて24時間の監視を行っていたりする。
開発者に比べて、作業自体は洗練されているが、あまり報われない。

>>964
いや問題は、>>939 みたいなのが
いつのまにかコの業界に入り込んでるという事実だろう。

…いや、例の 「IT業界」 とやらか？

>968
>>939は、自分で思いついて「運用」と呼んでいる訳ではないはずだ。
>>939の周囲の誰か、恐らくは上司が、「運用」と呼んでプロジェクトの進捗を誤魔化しているのだ。
その場合、本来の運用まで手が回らない、と想像される。

お前らが扱ってるシステムって寿命短そうだなｗ

ハードやシステムを操作することだけが運用と思いこんでるレガシーなやつらばかりだな

ソフトを育てていく運用もしないなんてショボいな

一度リリースして「はい終わり〜」なシステム屋が集まっているのはここですか？

>967
> バッチのスケジューリング
> 夜間処理を含めて24時間の監視

それまさに今の俺の仕事だわ

バグ対応の班は、運用と別に組まれるし、
改善案件には別工数が付く。
システム刷新の際には、別プロジェクトになる。

>>971
レガシーな俺に「ソフトを育てていく運用」とやらは何をするのか教えていただけますか。

レガシーなうちの会社では
要件をFIXした後、設計・製造・テストの最中に>>939のようなことを見積と合わせて済ませます。
リリース後に>>939のようなことが起こった場合は、バグなら当然修正、
仕変や追加は規模によって追加案件か保守契約内か判断、となるのですが、
「ソフトを"育てる"」というのはまったくイメージできません。
プログラムにAIでも埋めるんすか？

開発・運用・クライアントサポート何から何まで一部署一チームで賄ってるうちの会社は
DQN確定だな。世の中にはこんな企業もあるんだよ。T T

いやいや
一年いて配列すらまともに出来ない奴を正社員で雇う
うちの会社の方が底辺だよ
しかも
俺より給料いいし

うんこちんちーん

>>977
>一年いて配列すらまともに出来ない奴を正社員で雇う

こんなのが余りにもはびこってるからPGの世間的評価が低くなるんだよ。
何もできないくせに給料高いなんて、俺なら即刻抹サツするけどな。

開発全体がどんぶり勘定なんだろうな、育てる手法

「どんぶり勘定開発」とかの名称に要件定義しよう。

しかしオブジェクト指向を語る以前の話ばっかだなw

システム部門持ってたりある程度知識があるお客さんだったりすると自分とこで直したりする

保守契約っつったって永遠に契約できるわけじゃない

運用とプログラム修正・追加をまったくの別物としてしか捉えてないやつって
短いスパンと狭い見識の中での事しか考えてないと感じる

注文する側としてはいつまでも改定費用とかでSIerのエサにされるのは嫌だわ

別に他の会社（個人？）の言葉の定義が自分のと違ってもイイんじゃねーの？

オブジェクト指向を語ってくれよ

>>981
現実はOOがどうとか語る以前の会社が多いんだよ。

>>984
たとえばどういうとこが？

ここで仕切っている馬鹿がジャワ糞だってことじゃねえの

ここで煽っている馬鹿がVB厨だってことじゃねえの

がはははジャワ糞どんぴしゃかw

がはははVB6厨どんぴしゃじゃねーかｗ
一生非オブジェクト指向言語使ってろ

俺はJavaの本とデザインパターンの本しか読んだことないけど、ここに住みついている。

残念、はずれだなw

＞システム部門持ってたりある程度知識があるお客さんだったりすると自分とこで直したりする
＞保守契約っつったって永遠に契約できるわけじゃない

納品された商品（システム）をお客がいじるのは自由だけど、
いじった瞬間に逆にSIerはそのシステムから開放されるんで
やれるんならヤってくれ。って気もするが。（ｗ

それで不具合でてもSIerは知らんぷりできるし。
そのデグレートを直す依頼してきたら、素晴らしい見積もりが出すだけだしな。

>>985
いちばん多いのは会社が抱える社員PGのスキルの問題じゃないの？ JavaだろうがVBだろうがPHPだろうが
どれかひとつでも確実に使いこなせるんならいいんだけど、実際はその要件すらもまともに満たせないな
んちゃってPG結構居るからね。

>>992
てめぇんとこが作った糞システムの場合は当然全部面倒見てもらうに決まってんじゃん

>>985
いちばん多いのは会社が抱える社員PGのスキルの問題じゃないの？ 特にジャワ糞はだれよりもスキルがなく
馬鹿なくせに、脳内では誰よりもスキルがあると勘違いしているのが98%だからどーしようもない。

>>992
てめぇんとこが作った糞システムの場合はいつまでも検収ださないからただ働きしてくれなw

>>995
こらこら。変に煽るなよw
ジャワ○でも本当にJava使いこなせるんならぜんぜんマシだと思うぞ。
確かにJavaだけで誰よりもスキルがあるなんて思うのは困りもんだけどさ。

＞てめぇんとこが作った糞システムの場合は当然全部面倒見てもらうに決まってんじゃん

おそらく、こんな事言ってくる客がいたら、むしろこっちから縁を切るだろ。（ｗ
どうせ、赤字にしかならん仕事になるだろうし。

>998
PGにそんなことを決める権限がない件．．．

自演気味な厨がほんまにうざいな
もっと生産性のある発言してくれよ

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。