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

マジでお願いしますm(_ _)m

m(_ _)m

ぬるぽ

以下、家電の話と動物の話禁止

>>1
抽象哺乳類クラスに抽象鳴くメソッドがある
抽象哺乳類クラスを継承して作った犬クラス、猫クラスがある。
犬クラスの鳴くメソッドでは、「ワン」と鳴いて
猫クラスの鳴くメソッドでは、「にゃん」と鳴く。

これが継承、多態性だよ！

こないだうちのコンビニにヤクザが来たんだよ。
レジ打ちするとき､会計が893円でおもいっきし笑っちった。
そのヤクザはメチャクチャ俺のこと睨みながら1003円出したんだけど、
そしたらお釣りが110円でさらに爆笑

直感でわかんだろ

>>1
VBを覚える（自分はVer5か6だった）。
とりあえずC++あたりでクラスを作ってみる。
とりあえず継承してみる。
抽象クラスを理解する。
以上。

オブジェクトと関数は何が違うの？

動物→鳴く
この場合、動物関数から鳴くという
関数を呼んでるだけでしょ？

なんだよオブジェクトって・・・。

動物関数→動物オブジェクト

その通り。関数を呼んでるだけです。
あなたは正常な感覚の持ち主です。

モジュール強度、モジュールの結合度という言葉を知っていますか？
知らなければ調べてみてください。

継承なんざそこそこにして、
とっととインターフェースと委譲の勉強にはいれ

>>11
ひょっとしてJava厨？

どうすればオブジェクト脳になれるのか。

クラスというといきなり動物を例える人が多いんだけど、
ゲームのキャラならともかく、業務でそのクラスの継承がどう有効なのか知りたいのだが・・・。

動物話はポリモーフィズムってなによってことを覚えるためのものだよな、たぶん

>>14
それくらいわからないのならプログラマーやめれ

オブジェクト指向をものにした奴は出世する。

>>1
業務っつうかシステムを絵で表すんだよ。
その絵で出てきたオブジェクトをクラスにしていくんだよ。
あとはクラス間の関係を整理していって、それをクラスのプロパティにしたりメソッドにしたりするんだよ。
似たようなクラスがでてきたら、共通の基底クラスを作ってみたりしてもいいかもな。
まあこのあたりは無理やると後悔するから慎重に。

いきなり全部作るんじゃなくて、コアな部分から作っていけよ。

あとまあデザインパターンは知っておいたらちょっとかっこいいかもな。

>>14
そういう文句いうｵｯｻﾝには、一生理解できないよ？

オブジェクト指向云々よりも、いきなりUMLやったほうが実は効率的だったりする

あいかーらずこの手の話題は
分析と設計と実装がごっちゃで
なんの話してるのかわからんなー。

動物話をそのまま業務に持ち込むのが無理な話。

そのまま持ち込めるほど単純な業務ならば、オブジェクト指向なぞ使うほどでもなくなる。

つまり、普段から無理にでもオブジェクト指向なプログラミングを心がけない限り理解は不能だという事だ。

ＵＭＬを勉強しないと絶対オブジェクト指向は理解できないとおもう

「なぜオブジェクト指向で作るのか」で、うんざりするほど
動物に例えるな！と書いてあった理由を垣間見た気がする。

大規模やって、何度か破綻したらオブジェクト指向の大切さに気付くさ。
そして神髄へ近づける。

>>23
変更管理をやらないと、絶対オブジェクト指向は理解できないと思う。

概念的に言うと、
構造化プログラミングがベルトコンベアだとすると、
オブジェクト指向のクラスは、たくさんの蛇口のついた貯水タンクです。

Ｃ言語の実装的に言うと、
クラスは構造体にたくさんの関数がついたものです。

>構造化プログラミングがベルトコンベアだとすると、
>オブジェクト指向のクラスは、たくさんの蛇口のついた貯水タンクです。

(ﾟДﾟ)ﾊｧ?

勘違いも甚だしい

A、B、Cていう３人に
「読み、書き、そろばん」という機能をつけるとする。

構造化プログラミングの考え方は
図書館、書道教室、そろばん塾に３人をそれぞれ呼び出す。
オブジェクト指向の考え方は
３人それぞれに本、習字セット、そろばんを渡して
「読んどけ」「書いとけ」「計算しとけ」と伝え、「終わったら電話しろ」と言う。

誰もがたとえ話に終始し、具体的なメリットを説明出来ないのはどういう訳だ。

要はオブジェクトに置き換えた時にオブジェクト単位での再利用が出来ると言う
キモの部分を以下の例で示します。

次の人どうぞ
↓

>>1
バカには教えても理解できないから無駄
とりあえず死んでけ

>>31
スレタイには「OOのメリットを教えろ」とは書いていない。
「俺にOOを教えろ」と書いてある。
つまり>>1はOOがどういう感じのものかがわかっていないわけで
じゃあわかりやすく説明しましょう、となるとたとえ話になる。

>33
知りもしないやつらが的外れのたとえするからだろ？

>>1

オブジェクト指向そのものを理解したいのならjavaやれ

ちなみにCできるならC++やったほうが分かりやすいかも

OOを知り尽くしている>>34が
的を得たたとえ話をしてくれるそうです。

>>36
喩えは誤謬にしかならんよ。

それより、的は射（ｒｙ

>>36
>>34に代わり、
今どき椎名林檎ばりの漢字の使い方をする>>37が説明するそうです。

>>36
的を得た　→　日本語をやり直すべき　（プログラミング言語どころではない）

オブジェクト指向プログラミングのメリットは以下の通りです。
・Windowsプログラムを作るのに適している。

ウィンドウ型のプログラムは、見た目が同じでボタンや動作が少し違うだけと言う物が多いです。
オブジェクト指向では継承があるため、異なった部分のみをコーディングするだけで、
簡単にプログラムが作れます。
ただし一番適しているかは不明です。

…………………………　馬　鹿　に　教　え　る　の　は　無　理　ぽ　…………………………

では簡単にまとめてみました。

オブジェクト指向とは？
「値を入れ物に入れて、取り出し方を変えることによって処理を行うという考え方」
継承とは？
「取り出し方を追加する事」
利点は？
「値が変わらないため、いつでも元の値を取得出来る」
「誰かの作った取り出し方を再利用出来る」

これで分からない方は居られるでしょうか？
居られたら、諦めます。

…………………………　馬　鹿　に　教　え　る　の　は　無　理　ぽ　…………………………

馬鹿は人に教えられないとも言える

…………………………　馬　鹿　に　教　え　る　の　は　時　間　の　無　駄　…………………………

くずスレには馬鹿レスがつくのは
いつものことですが。
ここのみなさんはまれに見る馬鹿ぞろいですね。
ソフト会社に掃除に来るおにいちゃん達ですか？

オブジェクト指向を理解していれば、完全犯罪にも応用できる。
犯罪に使う車や道具などはすべてカプセル化し、絶対に自分個人から派生させないようにする。

ｵﾌﾞｾﾞｸﾂｽｺｳ

オブジェクト指向を理解しているのは、筑紫の信者ばかりだ。
いい加減に目を覚ますべき。

>>49
素でそう思ってるなら
お前ホントに頭悪いな。
仕事なんてろくにできないだろ

>>1

どうしても理解できないのなら
Cで言うヘッダファイルをクラスと思っておけ

まぁ実際は違うけどね

…………………………　く　ず　す　れ　　に　　ば　か　れ　す　…………………………

>>31
＞要はオブジェクトに置き換えた時にオブジェクト単位で
＞キモの部分を以下の例で示します。

有能なだれか,まだ書かないのー？

書けないのー？

>>51
どこが同じなのか説明してほしいぞｗ

>>51
そう思いこんでいる奴はうちの開発チームには
加えたくないな

どうでも良いよﾏﾝﾄﾞｸｾ-。

ようするに一言で言うとサブルーチンみたいなもんでしょ。
かぶってる部分はなんでも共通化したいみたいな感じか。

>>57
・動的にインスタンスを生成できるかどうかと言う観点で見れば全くの別物。
・メッセージのやりとりができるかどうかと言う観点で見れば全くの別物。
・データを包含することができるかどうかと言う観点で見れば全くの別物。
・てか釣り？

俺的には多態性が一番のメリットでありんこ

AとBというものがあるが両方Cとして見る事も出来るから
Cとして管理しましょうってことだろ？

お前らコードでかけよ。

学校という建物があるとする

クラス　学校

関数　教師

あるいみ手続き型とプログラミングのアプローチが逆なんだよ
全体がどのようなオブジェクトで構成されているかをはじめに考えて
徹底的に分割･詳細化

学校と教師はそれぞれクラスで
1対多関連がいいんじゃないっすか。

型が木構造で繋がってるだけ
そこにどんな意味を見出すかは人それぞれ

オブジェクト指向の利点は「元の値を参照出来ること」ですが、
それを聞いて「それはすごい」と思った人は、センスのある人です。
「それってどこがすごいの？」と思った人は、普通の人です。

元の値が参照出来ると言う事は、いくら継承しても、元の性質が失われないと言う事を意味します。
つまり誰かが継承して作ったクラスを使う際に、もし気に入らない部分があれば、そこは使わずに
元のメソッドを使うと言う事ができると言う事です。

また「誰かの作ったメソッドを再利用出来る」と言う利点もありますが、
これには注意が必要です。
なぜならその誰かの作ったクラスを再利用する時には、そのクラスを使うべきか、
またそのクラスにメソッドを追加すべきか、またそのクラス自体を継承して、
新たに作るべきかなど選択することになります。
その際にはその誰かの作ったクラスの用途や意味を理解する必要があります。
このクラスの用途や意味が分かって、はじめて適切にクラスを作成、使用することができます。
まあ、適当に継承して作っても動きはしますが、仕様変更や再利用に耐えられない物になります。

このクラスの用途（意味）を知る＝オブジェクトを知るが前提になっているため、
オブジェクト指向と言われます。

ただ逆に言えばそれだけの事です。
オブジェクト指向プログラミングが、すばらしい物のように語られる事がありますが、
オブジェクト指向は不完全な物です。
実際にプログラムをしていくと、どうしてもオブジェクト指向の考え方では実現できない事があります。
Javaなどではその部分をオブジェクト指向的でない方法で回避しています。
詳しくは、暇だったら「Javaにはprintfがない？」「多重継承の混沌」で語られる事が
あるかもしれません。
申し訳ありませんが、長文で疲れてきたので寝ます。

勘違いしてるのに気づかない人ほど長文書きたがるな

はぁ？誰にでも因縁付けるのは賢くない振る舞いだと思うよ。
特に間違いがない、いやむしろ、オリジナリティ溢れる良い文章だと思うけどｗ

>66
「姉ちゃんがボクの」まで読んだ。

くんくん、くくーん

>>67
どの辺が勘違いなのか
もし宜しければ俺に教えろ。

>>68
いきなり「元の値を参照出来ること」なんていう
訳の判らん出だしから始まる辺り、
>>66 は何処かのコピペかと思うんだが。

オブジェクト指向における差分プログラミングの是非はさておいて。

継承が提供する差分プログラミングの仕組みを
「概念間の階層関係」以外の言葉で説明する試み
なんじゃねぇの

オブジェクト指向とはずばり物指向です。
物質的な快楽が世の中の全てです。

また馬鹿が来た

>>74
そりゃエピキュリアンじゃないのかと。

74番ってどこにあるんでつか？ｗ

文末に“ｗ”付ける奴って

この説明で理解できなきゃ無能とか言うけど
結局おまいら人に噛み砕いて説明できるほど理解できてないな。
役立たずどもが

>>79
どんなに噛み砕いても幼稚園児に因数分解を説明するのはムリ。
どんなにわかりやすくてもトンガ人に日本語で説明しても理解はできない。

理解するには、ある程度の基礎知識ってもんが必要なんだよ。

いまどきオブジェクト指向がわからないやつなんてコボラーしかいないだろｗｗｗｗ

>>80
だからその基礎知識の段階を省く香具師が多すぎるから理解できないんだろ
オブジェクト指向を理解するための基礎知識がどういうものなのか
理解できてないのが多いと思う

>>66
1行しか読んでないけど、書いとくね

プ、馬鹿が！

↑全文読んだ馬鹿

２ちゃんって、社会的弱者の集団の癖に、
妙に保守的なんだよな。

やっぱ人間、衣食住足りて文化住宅っつう奴か（謎

↑>1

みんあ、ここに馬鹿が馬鹿晒してるお

＞オブジェクト指向の利点は「元の値を参照出来ること」ですが、
＞オブジェクト指向の利点は「元の値を参照出来ること」ですが、
＞オブジェクト指向の利点は「元の値を参照出来ること」ですが、
＞オブジェクト指向の利点は「元の値を参照出来ること」ですが、
＞オブジェクト指向の利点は「元の値を参照出来ること」ですが、
＞オブジェクト指向の利点は「元の値を参照出来ること」ですが、
＞オブジェクト指向の利点は「元の値を参照出来ること」ですが、
＞オブジェクト指向の利点は「元の値を参照出来ること」ですが、
＞オブジェクト指向の利点は「元の値を参照出来ること」ですが、

車があるとする

車　プログラム
エンジン　クラス

エンジンの部品　関数あるいはメソッド

その他部品(クラス)多数


登山用リュックサックがあるとする

登山用リュックサック　クラス

弁当　関数

水筒　関数

>>88
何一つ、伝わらない罠。

>>89
通報しました

>>80
>どんなに噛み砕いても幼稚園児に因数分解を説明するのはムリ。

チャレンジしてみる。

「あのね、"インスーブンカイ" ってのはね、
よおするに "むずかしいこと" っていみだよ。

ね、わかったでしょ？

オブジェクト嗜好

「分かってしまうとOOなんて大して難しくない。」
というところからスタートすべきでは



OOPだろうがAOPだろうが、機能に対する視点の違い、としか理解してないが
そんな漏れはや（ｒｙ

>>88
arutosuru_list: arutosuru | arutosuru_list arutosuru;
arutosuru: SYMBOL "があるとする" member_list_ext;
member_list_ext: member_list | member_list "その他部品(クラス)多数";
member_list: member | member_list member;
member: function | object | class | program;
function: SYMBOL "関数";
object: SYMBOL;
class: SYMBOL "クラス";
program SYMBOL "プログラム";

もう少しで「ひまわり」を追い抜きそうだな。
がんばれ。

痛々しい自作自演だな。やめときゃいいのに

>>91
うぐぅ

オブジェクト指向だと
役割とか責任をオブジェクトごとに明確に分散できて
複雑なシステムも結局最後は簡単なオブジェクトで管理できるから
らくじゃんってだけでそ
つーかおまいら継承しすぎｗｗｗ
ネストがふけーんだよｗｗｗ

>>97
分かる人にしか分からない説明しても、無駄なんだよ。
でも、それ以上に噛み砕くのも、ある意味、時間の無駄。

ここの>>1は頭悪過ぎ

「元の値を参照できる」と言う表現に違和感を感じる方がおられるようですが、
おそらく「機能（または性質）を引き継げる」と書けば納得するのではないかと思います。
しかし機能を引き継ぐと言うのがいまいち明確でないため、２つに分けさせてもらいました。
落ち着いて考えていただければ、
機能を引き継ぐと言う事が、「元の値を参照できる」と「メソッド（取り出し方）を再利用できる」
でしかないことに気が付くのではないかと思います。

>>98
おまえに説明するのは時間の無駄って先輩に言われたか？
どうでもいい人間らしいが
がんばれ

継承よりも、先ずカプセル化を教えるべきじゃないかと。

OOがわからない、て人が
どの部分を理解できないのかを明確にすればいんじゃねの？

「責任の分担」
「差分プログラミング」
「クラスの関連性を薄める」

これはどういう意味？っていう言葉ある？

http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html
ここの2-2がスバラシイ解説だと思う。

以下、一部抜粋
＞オブジェクト指向では、内包性はクラス、外延性はインヘリタンス、属性はそのまま属性という形でモデリングすることができます。

はは

継承から考えるとワケ分からなくなる希ガス
OOを学ぶなら、継承はあくまで予備知識として知っとけばいいかと
そんな漏れはメソッドの引数にthisやらselfやらが渡せる利点に気づいた時から世界が変わった

Cライブラリで言うFILE構造体、Winプログラムで言うHANDLEのインデックス等の扱い方がOOと同じ。

というのが、取りあえずとても噛み砕けてて分かり易い説明ではないかな？

厨臭いｽﾚだな

>>108が「ぼくにもりかいできるようにしゃべってようわーん」って言ってるので
みなさんもう少しわかりやすくお話しましょうね。

あれだろオブジェクト指向って、目的の為なら手段を選ばずってやつだろ。

おまえらの言葉は信用できん！コード書けコード！

書くまえに設計だろ。
設計しないで書き出すやつは例外なく無能。

クラスという雛形から、与えられたパラメータを元にしてインスタンスという実体を生成する。
インスタンスは複数同時に存在でき、それぞれが独自に、変数と、それを処理する関数を持っている。
インスタンスの関数は、自分がどの変数を使って処理を行うべきか「知っている」

俺はこんな風に解釈してるけど、何か間違ってる？

>>57
お前みたいな40代のように思考が止まっているヴァカ
はうちのチームには入れたくない。
糞コード書いてバラ撒きそうだから。

コードにするとこうなります。Javaで書きます。
コンパイル環境が無いので、エラーがあるかもしれませんが、
ご容赦ください。

class Personal{
private String name = "";
private int age = 0;
public Personal(){
}
public String getName(){
return name;
}
public void setName(String nm){
name = nm;
}
public int getAge(){
return name;
}
public void setAge(int ag){
age = ag;
}
public boolean isYoung(){
boolean ret = true;
if(age > 20){
ret = false;
}
return ret;
}
}

この簡単なコードがオブジェクト指向です。
まずクラスを考え、それを構成する要素をフィールド変数として定義します。
そして何も考えずに値を取得するメソッド（ゲッターメソッド）と、
値を設定するメソッド（セッターメソッド）を作ります。
構造化Cの人には許せないと思える一見無駄なメソッドですが、
こういう物だと思ってください。継承後に役に立ちます

そして機能を追加します。
今回は若いかどうかを判定するメソッドと追加してみました。

そ　れ　が　ど　う　し　た　？

＞この簡単なコードがオブジェクト指向です。
＞この簡単なコードがオブジェクト指向です。
＞この簡単なコードがオブジェクト指向です。
＞この簡単なコードがオブジェクト指向です。
＞この簡単なコードがオブジェクト指向です。
＞この簡単なコードがオブジェクト指向です。
＞この簡単なコードがオブジェクト指向です。
＞この簡単なコードがオブジェクト指向です。

115,116は111さんに対する回答です。

毎　日　、　何　考　え　て　生　き　て　る　の　？

＞まずクラスを考え、
＞そして何も考えずに
＞こういう物だと思ってください。

継承による差分プログラミングや多態性の利益は大きいけど
外部に公開するものを限定することが本来の意味だと思う

本来の意味よりも付加価値のほうが意味がある気もするけど

むか〜し、むか〜しのことじゃった
エディターで文字列をコピーするときの操作は
まずコピー開始キーを押して
対象文字列を選択して
コピー終了キーを押すてなぐわいで操作してたんじゃ
それから数年経つと
対象文字列を選択して
コピーキーを押すって操作にかわったんじゃとさ
めでたしめでたし

>>114
お
は
糞

>>124
エディタだぁ？アホそれつい最近やないか。

まさかイマドキ、オブジェクト指向がわからないやつなんていないよね？ｗ

つくづく頭の悪いスレだなぁ

>>124
漏れの携帯電話の文字列コピー操作は、
そのむか〜し、むか〜しの操作方法なんだな
ちなみに F です

>>116
デザインパターンの説明をして初めてオブジェクト指向の説明を
したことになるだろ。

それだけじゃCでもできるとか言い張るヴァカを増殖させるだけ。

他人の批判ばっかの馬鹿は、
実は自分で書く事がないから他人の足を引っ張ってるだけだったりする。
金曜の晩に悲惨だなぁ

>>129
デザインパターンて業務系アプリ開発とかだとどうでもよくない？
GOFの何パターンかわかってれば十分な希ガス

フレームワーク開発とかなら違うのかなぁ

オブジェクト指向だ、って言ってUMLで設計しても、
結局、画面定義書だテーブル定義書だE-R図だ
DFDだなんだとUML以外の従来の仕様書を書くはめになって、
工数が増えただけ。

＞　テーブル定義書だE-R図だDFDだなんだと

爆笑

UMLはシーケンス図とクラス図だけで十分かなぁ

テーブル定義書とER図と画面設計書は必須だと思うが・・・

ER図とテーブル定義書は、DB設計/管理屋がちゃんといるプロジェクトじゃはずせない。
はっきり言うと、UMLでなんか書いて、それをDB設計/管理屋に渡す事はあんまりない。
だから、爆笑。

画面設計は、UML書いても必要つうより、
UMLでなんか書き始める前に作って、それを元にユーザさんと打ち合わせて、
場合によっては デザイナやUI専門家の意見をもらう事もある。
だから、やっぱ爆笑

もう教えなくていいや
お前らより詳しくなったから

>>1
削除依頼はやく出せ

>>138
てめーが出せよ。ゲスが

>>139　てめぇが出せチンカス

>>140
お前が出せ。じゃないと俺はこのスレを残すぜ
ざまーミロ　マンカスアフォーが

画面設計は、外部設計だから、分析工程で使うＵＭＬなんかより
後にやるものじゃないの？

>>1
とりあえずお前はオブジェクト

>>142
UI主導の開発手順　たとえばユースケース駆動や、プロトタイピング手法だと、
まだ仕様が確定しないうちから画面のモックアップを作って、お客と仕様を詰めるのに使う。
お客にとっては、業務のシステム化＝システムの画面操作、つうイメージが強いからな。

あとついでに
>>142 分析工程で使うＵＭＬ

あなたの想定する分析工程つうのがどの範囲なのか知らんが、
パッケージ開発ならともかく、SI系で分析工程にUMLを使う事は、
今現在の日本の現場では非常に少ない、というあたりは常識だと思う。

>>131

あのな　>>116の説明だけでは
そんなのはCで構造体+関数の組み合わせでもできる
からオブジェクト指向はいらないと抜かして勘違いして
実用的なオブジェクト指向しっかりと勉強しない怠けたバカを
量産するだけだ。

ウザイ奴が増えるだけだからデザインパターンによる実例も伝えるべきだ。
特に、継承、委譲、集約を使った組み合わせによるクラス設計されたプログラムを
使ってだ。少なくとも、Template Methodパターンくらいの説明があったほうがいい。

業務系アプリ開発だとどうでも良いだとは何事か。
それでオブジェクト指向を理解したつもりかドアフォ。
そんなデマをバカどもに垂れ流しているから糞コードが量産されて苦痛を味わう犠牲者が
続出するのだ。もっとちゃんとしっかり教育しろ！

特に40代の頭の悪いC厨の群れどもが糞コードをばらまく。
頑固で過去のしがらみから抜け出せない40代のジジイどもをもっとしっかりと再教育しろ！

>>131
>>116の説明だけでは
構造体と変わらないじゃないかとぬかすC厨がでる。

かといって継承だけで説明すると

とにかくクラスを継承しまくればそれだけで
オブジェクト指向で効率よく開発していると勘違いするバカを生み出す。
いままでそういうウザイソースコードを何度も見てきた。
そういうコードを書く奴は大抵30代後半から40代以降の年配者や
Cレベルのことしか解っていない低脳ども。

奴らのソースコードを見ていると奴らを殴りたくなるほど腹が立つ。
デザインパターンの一つもしらずにやたらと継承しまくって継承階層4段、5段にも
なってしかも一つのクラスにメソッドが何十もある。
しかも継承するたびにすべてのメソッドを無駄にオーバライドしやがる。
オーバライドしてるかと思えばそのまま上のクラスのメソッドを委譲しているだけで
ほかは何もしていない。おめえはオーバライドがどういうものかをわかってんのかと。
おかげで奴のコードを解析するのも余分に時間がかかった。
奴は『分割統治』という言葉も知らなかった。
メソッドが増えたらクラスで分けろっていってんだろがアホ。
メソッド内行数が数千行になったらメソッドを分割しろっていってんだろがクズ。

継承＝拡張と勘違いして新しい機能を思いつくたびに一つのクラスを何階層も
継承していったバカだ。バージョンアップするたびに継承すればいいと
勘違いしてやがるんだ。素人の知ったかぶりはホントにムカツクわ。
そんなバカには先輩ズラする資格すらねぇよ。


オブジェクト指向を理解したつもりで
オブジェクト指向を舐めたコードを書きがやって！　知ったかぶりの糞が。

ああC厨ウゼェ。思い出すだけでも吐き気がする糞コードだ。
C厨マジで氏ね。ウザイんだわ。C厨の書くコードはジジ臭くてよ。殴り頃してやりてぇ。

オブジェクト指向がわからないC厨ｗｗｗｗｗ

Ｃ＃って孫以下に継承すると変にならね？

アナリシス・パターンが使えるように書く
アナリシス・パターンを使って書く

のが、ＯＯの基本的な使い方だろうな。

にやにやしてんじゃないよ、そこのきみ！

ROMってるきみのことだよ！

>>1
削除依頼はやく出せ

ところでクラス設計書って何？
そういうの何で勉強すればいい？本とか

>>154
UML クラスダイアグラム

【綺麗】デザインパターンは美しい！【究極の美】
http://pc8.2ch.net/test/read.cgi/prog/1089077456/l50
　

>>155
ありがとうございます
探してみます

　　　　　　　　　　　　　　　　　　　　　　　　　　　業界外のキチガイのスレ

>>1
削除依頼はやく出せ

やっぱデザインパターンって、覚えなあかん？

>>159
自分で出せば？
俺は残すといってるだろが。
削除依頼の出し方も知らないアフォーだろお前？
悔しかったら削除してみろｗ

必死だなぁ

必死とか自演だろとか書くやつって
自分がそうだから先に指摘されないように書いてるとしか思えん

↑ここまで自演

自演かどうかなんて見抜くこと基本的に不可能だろ。
自分がやった自演以外、誰も自演かどうか判断できん。

>>165

だからなんだって言うんだい？＾＾

別にお前には言ってないよ( -_-)y-~~~

オブジェクト指向すらわからないやつっているの？ｗｗｗｗ

じゃお前が説明してみそ

>>168見たいな書き込みがなくなるのはいつになるんだろ

>>24
その本が出るより昔からさんざん言われてきたことですけどね。

>>66
値ってなんだよ

…………………………　花　粉　の　飛　ぶ　日　は　糞　ス　レ　が　多　い　…………………………

いっぱい本読んで、理解できんかったら、向かないってこった。
素敵なお姉さまに体でおせーてもらえってこった。

糞女の糞ｿｰｽを引き継いだら、ちったぁー、OOの有り難みが分かるってもんだ。

>>148
> 継承＝拡張と勘違いして新しい機能を思いつくたびに一つのクラスを何階層も
> 継承していったバカだ。バージョンアップするたびに継承すればいいと
> 勘違いしてやがるんだ。
どっちかちゅーとそりゃ包含だわな。COMプログラミングとかの。

今日も花粉飛んでるんかよ！

雨降ってるのに・・・

脳内花粉

中年コボラーだろ？　オブジェクト指向がわからないなんてｗ

>>178
スレ違い
http://pc8.2ch.net/test/read.cgi/prog/1115573816/

オブジェクトちんこ

最近、オブジェクト指向を教える機会があり、興味深い体験をしたので報告します。
「オブジェクト指向を知りたい」と言われ、実際のコードをベースに概念を説明したのですが、
話があまり通じませんでした。
そこで何が分からないのか詳しく聞いたところ、以下の通りでした。
１．標準のJavaDocを見た。クラスの多さに驚いた。
　　何使っていいか分からない。これ全部覚えるの？
２．プログラムをトレースしようとしたら、main()がない。（サーブレットのため）
　　どこから始まるの？
　　同じメソッド名で処理の違う物がある。どっちが動いてるの？
　　ところでモジュール構成図はないの？

つまり結局分からないのは、
１．使うクラス＆メソッド
２．メソッドが動く順序
でした。
既存のコードにブレイクポイント入れて、デバッカーでトレースするのを提案しました。

>>181
少し面白いけど・・・スレ違いのような

>181
君が一番わかってないような･･･

オーバーロードがわからないんだろうなｗｗｗ

そりゃだいぶ経験の浅いやつだね

>>181　あーあー　そりゃダメダメ　デバッガでトレースなんかしてたら
オブジェクト指向はわからない

「何使っていいか分からない」ってのはOO固有の話ではないし

もしかしてツリ？

いえ、「オブジェクト指向を教えてと言われたのに、
知りたかったことはオブジェクト指向と直接関係ない事だった。」
ということです。

もしかしたら、こういう勘違いで分からなくなっている人もいるのかと。
でも確かにコボルやスクリプト使いの人がいきなりJavaなどやると、
直面する問題ですね。対策も慣れろとしか言えませんし。

まぁちょっと環境をおごるかな、
PlugIn入れないと、
Servletをdebuggerにかけるのは面倒だが(w

コード見せて概念説明しても、何の意味も無い。
概念の説明をしてから、それを実現するのにどういうコードとなるかを説明しなければならない。

コボラーはオブジェクト指向すらわからないのかｗｗｗ

>190
古ぼら−にはオブジェクト指向は不要。

自分がオブジェクト指向の言語勉強したときのこと思い出すと、
とりあえず本の通りにクラス書いたり構造体書いたりして、自分で何とか書けるようになって
あとから概念ちょっとかじって、おお、あれがオブジェクトだったのか！
みたいにあとから気づいた、みたいな。

オブジェクト指向とは・・・・経験である

プログラムも書けないのが煽ってるな。

俺？ COBOLなんて糞は触った事もないけどｗ

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
プログラム書けないバカが、
オブジェクト指向を知っているフリをする痛いスレ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

お前ら俺にフォートランを教えろ矢
入出力フォーマットが複雑杉

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
プログラムを書く必要もないバカが、
プログラムを教えてもらうフリをする痛いスレ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

OOスレなんてそんなもんだろ。
ちょっとの知識をみんなに話す場だからなここは。

>>6
いまさらだがなんで１１０円だったら爆笑なんだ？？

call for police

オブジェクト指向がわからなくてヒガミ根性丸出しの人たちのスレｗ

最新技術についていけない人はホームレス確定

あのさ、プログラムもろくに書けない、
２ちゃんに入り浸りのお前風情に
偽オブジェクト指向を騙られると、
片腹痛いつうか、爆笑っつうか、痛々しいんだわ。

さっさと死ねよ

オブジェクト指向ができないんだろ？　やれって言われてるのにできなくて
焦ってるんだろ？　態度ありあり出てるなぁ　ｷﾞｬﾊ

オブジェクト指向を最新技術と言い切っちゃう奴もいるんだね。

はて？
オブジェクト指向よりも最新の技術って何か有りましたっけね？
研究段階の技術は持ってこないでねｗ
ベクトルの違う技術も持ってこないでねｗ

はて？オブジェクト指向って技術でしたっけね？
今まで思想とかパラダイムだとばかり思っていましたが

>206の痛さは次元を超えてるね。●違い？

オブジェクト指向なんて古めかしいものを未だに理解できないなんて・・・・ｗ

確かに、最近小坊レベルにまでマ板のレベルは落ちてる。

オブジェクト指向に関しては、文法書読んだらデザパタ本読め、
で答えが出てるだろう。

>210
おまえがレベル落としてるとしか考えられん
デザパタ読むのもいいけど
おまえの頭の中は所詮コーディングどまりだろ
意味ねーよ

設計できないコーダーはオブジェクト指向がわからないってか

コーダーレベルの人間にオブジェクト指向言語を与えても凶器にしかならない。

>>199
釣りか？　釣りなのか？？

====================================================================================

　　　　　　　　　　　　　　　　　　　　　　キ　チ　ガ　イ　専　用　ス　レ

====================================================================================

コーダーが嫉妬に狂ったかｗ

>>211
オブジェクト指向に何を期待しているんだ？

従来型の構造化設計に、いくらか文法的追加があっただけというのが
オブジェクト指向の実態だろう。別に神秘の力が宿ってる訳じゃない。

それとも、Ｗｅｂサービスや、分散処理など、アーキテクチャの話を
オブジェクト指向と絡めてしたいのか？

>>217
バカに突っ込まれる前に追加しておく。

オブジェクト指向はオブジェクト指向言語存在前から
関数のポインタと構造体を駆使する方法で実践されていた。
それに、オブジェクト指向は従来の構造化設計の拡張の手法にすぎず
やはり構造化設計の一種だ。

相対性理論は従来のニュートン力学の拡張の手法にすぎずやはりニュートン力学の一種だ
量子力学は従来の相対性理論の拡張の手法にすぎずやはり相対性理論の一種だ
・・・いや滅茶苦茶書いてしまったが。何が言いたいかと言うと
手法としてしか表現しないのは無理があり、「思想」とか「考え方」とか「アプローチ」とかのほうが適切かと

そして
手法が拡張されたなら、それは応用とか特殊化と呼ばれるが、思想が拡張されたなら、一般化とか汎用化と呼ばれる。
包含関係が逆で「オブジェクト指向は構造化設計の一種」ではなく
「構造化設計はオブジェクト指向の一種」ではないかと

#バカの突っ込みだった？

====================================================================================

　　　　　　　　　　　　　　　　　　　　　　キ　チ　ガ　イ　専　用　ス　レ

====================================================================================

>>217-218

みてみて

だったらなんでイマドキオブジェクト指向がわからない人がいるんだろう
関数とかポインタすらわからない？

>222
そもそもOOって関数とかポインタの話じゃないが
Javaに至ってはその２単語出てこない…ってのは蛇足か

>>222
そうだよ。
オブジェクト指向は行きすぎた従来的構造化の反省から
生まれたものだ、いや拡張例だ。
従って、従来構造化を知らない奴がいきなり手にできるもんじゃない。手にするにはもう一度従来構造化の欠点を経験することとなる。

ＯＯが分からない奴が多いのは、従来構造化に関する知識が不足しているから、ありがたみが感じられず、説明されても理解できない。

Ｊａｖａはさらに反省としてポインタを切り捨てたものであって、そのことを知らないならボインタを用いると同様の過ちをクラスを使って繰り返すことになる。従来構造化から削ったんであって、全く新しくポインタと無縁なモノを作ったわけじゃない。

＞＞２１９
がんばれ、厨房。
人生は長いぞ。

>>225　・・・いや。とうに折り返し点は過ぎていますが

厨房に始まり厨房に終わる悲惨なスレ

210=217はマジでコーダだったんだ。
こんな思慮の浅い人間がやっていけるソフト業界って
やっぱり素敵だ

いつの間にか、「オブジェクトが指向が分からない」と
言っている人がいなくなってませんか？

質問者がいなくなって寂しいので私が質問者になります。
「プログラム言語を一つも知らない新人にオブジェ指向を
教えるにはどうすればいいでしょうか。」
できれば、期間は「三カ月」
言語は「JavaかC++」
よろしくお願いします。

オブジェクト指向わかってる奴とわかってない奴がプロジェクトリーダーだったら
後者は大赤字出す危険性大。

>>229
>言っている人がいなくなってませんか？
解ってるふりなら誰でも出来ますからね。

>>230
PL と OO に何の関係が？
/* PL って、人月計算だけしかできない人でそ？ */

オブジェクト指向がわからないなんて、厨房だけだろ。

====================================================================================

　　　　　　　　　　　　　　　　　　　　　　キ　チ　ガ　イ　専　用　ス　レ

====================================================================================

>>1がキチガイだって？　ひどいやつだなｗ

>>235＝頭おかしい人

>>229
素人に3ヶ月でおしえるのは無理だと思う。
他にも覚えるべき事が山ほどあると思うし。
JavaでもC++でもいいけど、とりあえず標準API位自由に使えるように
勉強させればいいんじゃないのかな

>>219
「パラダイム」という用語があります。

既視感のある妄言を
泡のぬけたビールのように
つらつら書き連ねるだけの
痛いスレ

「お惣菜はスーパーで買ってきた方が、自分で苦労して作るよりも簡単で
早く食えるし、しかもおいしい」

ってことが、「オブジェクト指向」なんでしょ？

====================================================================================

　　　　　　　　　　　　　　　　　　　　　　キ　チ　ガ　イ　専　用　ス　レ

====================================================================================

>240
イコールにするのは間違い。
そういう面も持ち合わせてると言われればそうかもしれない。

そうめんで例えるぞ
1本だけ色の違う麺があるよな？
あれが不具合だとする
全部いっぺんに茹でてしまうと
どこにあるか探すのが面倒
だから束で分割してある
揖保の糸はオブジェクトそうめん

>243
>242

>>228
おまえこそ、設計やったことあるのか？
実装独立、機能独立はＣの時代から言われてた。
今のオブジェクト指向本のサンプル見てみろよ、それさえできてない。
クラスライブラリの機能紹介でもしたいかの様で、
ＣＡＳＥ使って既存のオブジェクトをペタペタ貼ってるだけだ。

ん？
俺は243だが 242は別人
時間かぶったからそう思うか
ちなみに俺はﾌﾟﾛｸﾞﾗﾏｰではない

プログラマでもねーならジャマだから去れ

プログラマじゃないからなんだって言いたいのかわからんが、「イコールにするのは間違い」って言われてるんだろ

>>228
おまえの言うオブジェクト指向は、
見えやすい単位でクラスに分けてるだけだ。
おそらくは、業務系ぐらいにしか適用できんだろ。
言い換えれば、紙芝居のアナロジーしか書けないわけだ。

まあ、いいんだよ。潤沢なリソースを使える時代なんだし、
書き直しが多いほど人件費で稼げるんだろうからな。

ポインタが栄華を極めた時代の遺産を継承してるやつと、
実質ＢＡＳＩＣ程度の設計しかやったことの無い奴では、
クラスの概念の見え方は全く違う罠。

後者にとっては新しいパラダイムだが、前者にとっては
一部表記がシンプルになっただけ。

====================================================================================

　　　　　　　　　　　　　　　　　　　　　　キ　チ　ガ　イ　専　用　ス　レ

====================================================================================

>>1を叩きすぎｗｗｗ

>250
なんでそんなにコーディングに拘るんだ？
本のサンプルソースは特定の機能についてのみ書いてあるわけで
実務に耐える作りにするわけないだろ。
オブジェクト指向で再利用性うんぬんは大昔に答えはでてる
再利用性よりも保守性を重視しろだ。

なんかわるかったなコーダいじめるつもりはないんだ。
必死になってやっとおぼえたﾌﾞﾋﾞが.netになってしまい理解できずに
取り残されたんだろ。
ここのみんなやさしいから教えてくれるぞ。
素直になって聞いてごらんよ。

>>253 横レスすまんが
>オブジェクト指向で再利用性うんぬんは大昔に答えはでてる
>再利用性よりも保守性を重視しろだ。
これは本当ですか？
素でソースが知りたいのだが教えていただけないか？

>>253
>本のサンプルソースは特定の機能についてのみ書いてあるわけで
そうなの？

>>253
＞なんでそんなにコーディングに拘るんだ？

俺も質問です。
ポインタを使ったＣとＢＡＳＩＣの違いが単にコーディングの違いなら、オブジェクト指向言語と、オブジェクト指向じゃない言語の
差は単にコーディングの違い
になっちゃうんじゃないですか？そうすると、オブジェクト指向って何になるんでしょうか？

オブジェクト指向＝オブジェクト指向言語ってわけね
おれの完敗です
降参
お手上げ
fuck up

>>257
どうしてそう、話が飛ぶんですか？
頭が弱いんですか？

>>254
２５３じゃないけど、思うに、結論なんて出てないよ。
どういう言語がオブジェクト指向に適してるかっていう話は決着してるらしいけど。
smalltalkまで行っちゃうんだと思います、最後は。

>>259
ｻﾝｸｽ。そうでしたか。>>253の該当個所は根拠なしでの発言でしたか。
>どういう言語がオブジェクト指向に適してるかっていう話は決着してるらしいけど。
>smalltalkまで行っちゃうんだと思います、最後は。
ああそれも妙に納得できます。ハイブリッドOOPLではなくピュアOOPL
というわけね

自作自演ご苦労様でつ

同意があると全部自作自演ですかそうですか

<丶｀∀´>イルボンの浅漬けクラスは、キムチクラスを継承してるﾆﾀﾞ
<丶｀∀´>スーパークラスとは、ガンダムみたいな物の事ﾆﾀﾞ

>>261
ここに粘着してるのはプログラム板を数年間にわたって荒らしまくって
廃墟にしちまったキチガイ。なめると痛い目に会うと思うよ。まぁム板はネタ板だけどｗ

Ｃの頃言われてた１関数１機能みたいなコーディングの基本って言うのは

なんで荒れるんだろうね。

>>253
＞なんでそんなにコーディングに拘るんだ？
オブジェクト指向は大きく分けて三つあるわけだけど、
そもそもは再利用生の高いコードを得るために始まって、
その後、コードを得るには設計、設計を得るには分析と
上流へ発展していったわけだ。

オブジェクト指向が言うところのオブジェクトは、
哲学的な概念じゃなくて、再利用生をあげるための
コーディング規約のメタファーでしかないんだよ。

チューリングマシンさながらに現実世界をシミュレート
しようなんて無茶な思想じゃないんだよ。

再利用性か。実現出来ているかははなはだ疑問だな
手段はあっても資源が不足していて実現出来ていない品質特性・・・かな
ということはOOPLを使わなければならない必然性が今一つ理解出来ないな

相変わらず厨房が繰言くりかえしてるのか

痛い所を指摘されると厨あつかいか

＞再利用性よりも保守性を重視しろだ。

これにはちょっとだけ同意
オブジェクト指向によって記述も設計も
直感的になり簡潔になる。
それで十分じゃね？

再利用性なんてほとんど考えないよ。
シンプルに対象を記述することが何よりも重要

オブジェクト指向は構造化より一歩進んだモノであることは確か
オブジェクトを組み合わせてればオブジェクト指向というのは猿的

オブジェクト指向が構造化より進んでいると言うのは、優れていると言う意味でしょうか？
時間的に後に作られたと言う意味なら分かりますが、私的には優れているとは思いません。
ウィンドウズプログラム向きだとは思えますが。
「シンプルに記述できる」と言うのも疑問です。それはプログラマの技能の問題で、
構造化でもシンプルに記述できると思います。
また「保守性に優れている」と言うのも実感できません。
これもプログラマの問題で、保守性を重視して作られた物は手法に関係なく
保守性に優れていると思います。

まぁイマドキ 構造化で10万行超のプログラムなんて
見るのも苦痛で放置されるのがオチだと思うが。
1000万行に近い線だと、構造化すら不充分なのがまかり通ったりしてるが（ｗ＞＞国内

>>274が今時行数を気にしている件についてｗ

>>271
末端コーダはのん気でいいな　おい

>>275

はぁ？行数や画面数でプログラムを計測するような所だから、
構造化すらおぼつかないんだろ。
なんでも突っ込めばいいってもんじゃねぇんだよ、
てめぇみたく平日昼間っからノンキに２ちゃん三昧のアフォ

WebProg板のRSS/RDFスレで
「オブジェクト指向しろ」とかいってる基地外もテメェだろ。

なんでも煽りゃいいてもんじゃねぇぞ。
・・・いろいろな経緯で、あの分野がOO〜ポストOOの適用で
一番進んでる、と言えなくもないのにさぁ。

平日昼間っからノンキに２ちゃん三昧のアフォが、ちょっと煽られたくらいで
むきになってるなｗ

>>273
仕様がシンプルなのしかやった事がないから
そう思うんでは？

よく考えられたものは後から見ると
シンプルに見えるよなー。

バカにはできないんだからあきらめろよ>>1-999

>>282
>>282
>>282
>>282
>>282

>>280さん
オブジェクト指向でも構造化でも大規模のをやっていますが、
むしろ構造化の方が大規模向きだと思います。
280さんが構造化されていない大規模プログラムを、
構造化されたプログラムだと勘違いしているのではないでしょうか？
Cで書かれているプログラムがすべて構造化プログラミングで
組まれている訳ではありません。

どうも金八です

>>284
＞オブジェクト指向でも構造化でも大規模のをやっていますが、
＞むしろ構造化の方が大規模向きだと思います。

安易にこういうことを書くなよ
書くんなら理由をきちんと書けよ
おまえの直感なんて知りたくもないんだよ

>>273
＞時間的に後に作られたと言う意味なら分かりますが、私的には優れているとは思いません。
理由は？
＞ウィンドウズプログラム向きだとは思えますが。
理由は？
「シンプルに記述できる」と言うのも疑問です。
理由は？
また「保守性に優れている」と言うのも実感できません。
理由は？

感想は脳内だけにしてくれ

オブジェクト指向は設計も含めたもの
猿がオブジェクトを積み上げてもオブジェクト指向とは言わない

>>284
オブジェクトを積み上げることを
オブジェクト指向と勘違いしていませんか

>>286
＞＞＞オブジェクト指向でも構造化でも大規模のをやっていますが、
＞＞＞むしろ構造化の方が大規模向きだと思います。

オブジェクト指向で現れるクラスは、グローバルでもローカルでもない、
グローカルな領域を作り出すことで、システムをモジュールの粗な結合
として表現することを可能にしたわけだ。

そこで、
小規模なシステムの粗結合によって大規模システムとするカプセル化が、
コードの再利用性向上（継承機能）と並ぶ２大機能として従来の構造化
言語に追加された。

>>273
＞オブジェクト指向が構造化より進んでいると言うのは、優れていると言う意味でしょうか？
Ｃ＋＋については、昔の構造化時代の反省から追加された拡張です。

＞私的には優れているとは思いません。
最悪、スタティック・クラスにメイン関数をおいて、その中で従来通りに書けます。

＞「シンプルに記述できる」と言うのも疑問です。それはプログラマの技能の問題で、
＞構造化でもシンプルに記述できると思います。
その通りだと思います。　でも、規模が大きくなってくると再利用性等を
高めるためコードが複雑になります。このときに可読性を高めたり、コンパイラに文法エラー
として警告して貰えると効率が上がります。

＞また「保守性に優れている」と言うのも実感できません。
＞これもプログラマの問題で、保守性を重視して作られた物は手法に関係なく
＞保守性に優れていると思います。

保守性の定義が不明なのですが、
グローバル関数を多用するより、クラスのメンバ変数を使えばソースコードの可読性
が向上し、保守性が上がります。

再利用性が連呼されているけど。「可能」ということと「出来る」ということは違うだろ。
OO支持する人達にたずねたいな。
パラダイムシフトをしてまでOOに移行するべき／移行しなければならないという
必然性がどこにあるかがわからないんだ。
まさか「流行に乗り遅れないため」とか「旧来のパラダイムでは生き残れないから」
なんていう情緒的な理由では無いと思うけど

>>292
言ってることが丸々負け犬じゃね？
いいのかそれで

>>287
＞＞ウィンドウズプログラム向きだとは思えますが。
＞理由は？
関数に個別の状態を持たせられるから、GUIの部品みたいに
ちょっと違うけど大体似てるものが沢山あるときに、独立性を
保ったまま共通化出来て便利だろ。

>>288
＞オブジェクト指向は設計も含めたもの
これが一番問題なんだよな。オブジェクト指向の考え自体は
理解できるんだけど設計手法まで強要する連中がいるのが好かない。

>>292
ＯＯの優位はどこから見ても明らかだよ。

ネジしかなかった世界に、ナットが生まれたようなもんだ。
ナットを使わないという選択肢が残されているように、
どこまでＯＯを徹底するかという点で裁量が残されている。
しかもこれは、使うか使わないかではなく、スケーラブルに調整できる！

そんな変な思想を抱くってことは、勉強が足りないんじゃないか？
何冊本を読んだ？　雑誌のＯＯ特集なんて数に入れないでくれよ。

そんなわけの判らない比喩を提示されてもねぇ

>>294
ああ、そこか
馴染む馴染まないが大きな差になってるのか

マ板のOOスレと言い、
なんかアンチOOな方が粘着してますね。
こちらへどうぞ。
http://pc8.2ch.net/test/read.cgi/prog/1115573816/

>>292
> 再利用性が連呼されているけど。「可能」ということと「出来る」ということは違うだろ。
「容易」ということと「困難」「不可能」ということも違いますね。

> 「旧来のパラダイムでは生き残れないから」
> なんていう情緒的な理由では無いと思うけど
情緒的ではないですが、旧来のパラダイムでは生き残れないと思います。

なんだ、キチガイの人ここでも頑張っちゃってるのね

おまえのいうオブジェクト指向は、単に「オブジェクト指向」という名詞がついているだけで、
実際のオブジェクト指向なんて理解もできてねぇし、
だいたいプログラムとか全然できねぇんだろ？


屑が無駄な努力をしても無駄（ぷ

>299

あなたは生き残れないと「思います」

劣等感丸出しレスｗｗｗ

起床

たばこの箱.開く
if たばこの箱.中身が空？ then
鬱
就寝
return;

吸わないのカヨ！

class EmptyTabacoCarton
　def 開く
　end
　def 中身が空?
　　true
　end
end

class Writer303
　def initialize
　　@たばこの箱 = EmptyTabacoCarton.new
　end
　def 起床
　　@たばこの箱.開く
　　if @たばこの箱.中身が空? then
　　　鬱
　　　就寝
　　end
　end
　def 鬱
　end
　def 就寝
　end
end

Writer303.new.起床

また今日もキチガイが頑張っちゃってるな（ﾜﾗ

ＭＦＣがなぜ難しくて、Javaや.Netが簡単なのか説明できるか？
ＶＢがＶＣの何を隠していたかわかるか？

キチガイ頑張れ。
VBなんて知るかよ(ﾌﾟｹﾞﾗｯﾁｮ

>>308
キタコレ。

>>309
そゲ？

ＶＢが理解できないキチガイｗｗｗｗ　ワラエル

VB、VCとありますが、VAは無いんですか！？
たぶん、VBより簡単だと思うので、キチガイなぼくでもVAなら理解できると思います！
皆さんはVDとかVEまで理解されてるのでしょうか？
やはりプロになるにはVZまで理解しないといけないのでしょうか！？

>>312
そういえば最近、VJを見なくなった。

>>299
>> 再利用性が連呼されているけど。「可能」ということと「出来る」ということは違うだろ。
>「容易」ということと「困難」「不可能」ということも違いますね。
可能であるにも関わらず、実現出来ていないことを利点として掲げても意味がない
という意図です
>情緒的ではないですが、旧来のパラダイムでは生き残れないと思います。
情緒ではなくそう「思う」なら、貴方は新しいパラダイムで生きれば良い。
根拠を示すことが可能ですか？。
あるいは根拠が無くても充分な説得力でその理由を説明できますか？

どうも懐疑を抱いているだけの人間も、アンチであると決めつけて
悦に入っている方がいるようですね

アンチはVBの優秀さが認められないんだねｗ

「可能」ということと「莫迦でも出来る」という事は違うね。少なくとも。

バカバカ言う人がバカの法則

歩いて東京から大阪まで行けるか？
というと「可能」だよな。

漏れは新幹線か飛行機にするが。

もちろんVB厨は歩くよな。「可能」だもん。

で、今は何の話してるんだ？

アンチVB厨って東京から大阪まで歩けるのかｗｗｗｗｗ　ダメだこいつｗｗｗｗ

>320
文章よく読んだか？

>>318
歩かんよ。行くこともない。
東京から大阪に行く必要性がないからだ。

もしかしてVBは遅いってことを言おうとしたのかｗｗｗｗｗｗ

いまどきのPCなら速いんだよｗ

>>318
ヴビチューには諷喩しても理解して貰えないようです。

アンチＶＢ厨痛すぎ

>>325
「アンチブビ」厨なのか
アンチ「ブビ厨」なのか
それより何より2バイト英字やめれ素人。

ブビだろうがジャヴァだろうが、金になれば仕事する。

安置ヴビ＝「俺は、ジャヴァできんだ。クラスもわかんねーだろ。こら」
ブビ＝「ジャヴァ出来て、そんなに偉いか、クラスがなんぼのもんじゃ、こら」

両方できて、しかも仕事選べるようになれば、「金がよくて、環境のいい仕事」選ぶでしょう？普通。

アンチ痛い

VBも、OOP理解してる人としてない人では
コードの質が違ってくると思う

オブジェクト指向が構造化に比べて全面的に優れていると思えないのは、
フォーマット変換をスタティックメソッドで、
多重継承をインタフェースで回避しているところです。
どちらも本来のオブジェクト指向的な思想でいくと、（実際にやるとひどい目にあいますが）
継承を使うべき所だと思います。
まあ、それを含めてオブジェクト指向だと言えばそれまでなのですが、
私はオブジェクト指向と言う建物を、構造化と言う金具で補強したような
不格好な印象を受けます。
構造化の場合は１つの概念で統一されているので、きれいな印象を受けます。

ただウィンドウズプログラムを作る点に関しては優れていると思います。
他の人も言っていますが、私の言葉で言うと、
ウィンドウにボタンを追加して新しいウィンドウを追加すると言う事が、
継承して新しいクラスを作と言う事に似ているからと、すでに多くの
クラスが提供されて、マニュアルも揃っているからです。

シンプルに記述できると言うのが疑問と言ったのは、
出来るか出来ないかはプログラマの問題で、構造化でもオブジェクト指向でも、
シンプルに書けるし、複雑にも書けるからです。

保守性が優れているのが疑問というのは、
実際に誰かの作ったプログラムを保守してみると、構造化の場合は
モジュール構成図を出してソースを追って行けば、なんとなくでも
実行イメージが掴めるのに対して、オブジェクト指向の場合は、
クラス図やJavaDocを出しても処理が追いにくい
（継承されたメソッドが実際にどれが動いているかわかりにくい）事です。
私の場合はEclipseのデバッカーで実際に動かして追ったりしていますが、
どなたかもっといい方法をご存じなら教えてください。

実際に自分の作った物でなく、他人の作った物を保守しようとすると、
理解までに時間のかかるのはオブジェクト指向だと思います。

ドキュメントないの？保守

オブジェクト指向を教えろ屋

オブジェクト指向の書籍などいろいろありますが、
利点ばかり書いてあって、欠点があまり書いてないのが多いと思います。
これらの本だけ読んでいたら、まるでオブジェクト指向が万能のように
思えてしまうかも知れませんが、そうではないと思います。

ただオブジェクト指向を否定する訳ではなく、利点も欠点も知った上で、
適材適所に使うべきだといいたいだけです。
ウィンドウプログラムやWEBプログラムを無理してCで組むのもなんですし、
速度が必要な大規模バッチプログラムをJavaで組むのもあまり良くないと思います。

>>332さん
ドキュメントがある場合もない場合もありますが、
ドキュメントがあって、それが正しいと言う事は非常に少ないですね。
あえて言わせてもらえば、実際の処理を知る上で最高のドキュメントはソースコードです。
また仕様を知る上で最高のドキュメントは顧客です。
まれに、どちらも信用出来ない場合もあります。

ちなみに関係無いですが、
VBは素晴らしい言語だと思います。

>継承されたメソッドが実際にどれが動いているかわかりにくい
これは、どういうことなの？
ある程度言語仕様は抑えてるんよねぇ？
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vbcn7/html/vaconWhenUseInheritance.asp?frame=true
そのソースでは間違った使い方をしている可能性もあるんだけど、
>多重継承をインタフェースで回避しているところです。
これを見る限りかなり誤解しているような気が。
回避しているんじゃなくて回避できるというだけ。
処理を追うより、まずは個々のクラスの役割を調べる&イメージするのが先決では？

VBなんて適当に組んだら出来るんじゃね？
変なコレクションの木みたいなのは良くわからないけど

このイタイコテハンまだ居たの？

何かイタイこと言ったとですか？ｗ

>>331
オブジェクト指向のプログラムが
見通しが悪いのは確かにそうだと思う
オブジェクトの組み合わせ方に節操が無いと
一歩先が見えなくなる

最強の武器も使う人間によっては最凶の武器になる

おまえじゃ釣れねーぞ

無駄にクラスを増やさないようにしないとな。

OOどうのという話はさておき、MFCの仕組みは嫌いです。

そんな俺は間違ってますか？

>>344
>そんな俺は間違ってますか？

ああ、レスの書き込み先がな。

ダメなクラスの実装例として MFC を持ち出すのはアリじゃね？

>>346
ありだな。
だがもっとダメな例としておまえのソース晒せ

・・・で、ここはＯＯマンセーな奴が
ＯＯの優位性は認めていながらパラダイムシフトに踏み切れない奴
を説得できないままダラダラと続いているスレ

ということでよろしいか？

>>346
ＭＦＣはクラスライブラリというより、スケルトンだからな。
複雑に見えるが、その分自由度も高い。

>>347
流石に MFC よりはマシですよ。
職業プログラマとしてはコード晒すわけには
いかないですが。

>>350
MFCのどこがまずいか言ってみ。

まず名前

MFCがヘボいのは常識だよな。

だからどこがどうまずいのか
自分ならこうするってのを書かなきゃ説得力ないよ

自分なら

Multiple Frame C++　＝　MFC

かな？

=================================================================
OOもわかんねぇキチガイの自作自演専用スレ
=================================================================

わかんないから「教えろや」ｽﾚなのだが

>>354
俺だったら、まず派生クラスで実装すべきものを基底クラスで実現してる
ところを止める。CWnd でスクロール実装する必要なんかない。
あと是非入れたいのが、GUI クラスのウィンドウサイズ管理機能。
(Xt Widget でいうところのジオメトリ管理)
それと、グループボックスが実は CStatic だとか、そーゆー楽しい実装も
止める。つか、そもそもコンテナとコントロールは分けたいな。
メッセージマップのマクロは…まあ実行時の効率考えたらしょうがないか。
でもどうにかしたいぞ。

>>358
CWndというクラス名に着目すればスクロール実装してるのが自然だろ？
名前の重要さに早く気付けよ。

>>336さん
PDAのためかリンク先は化けて見えませんでした。
（言語仕様かデザインパターンのベージでしょうか？）

>そのソースでは間違った使い方をしている可能性もあるんだけど、
まさにこれで、保守ではどんなソースに出会うかは分かりません。
うまく作ってあって

>これを見る限りかなり誤解しているような気が。
>回避しているんじゃなくて回避できるというだけ。
すもません、ちょっと書き方が良くなかったです。
インタフェースが悪いというより、多重継承自体に問題があり、
本当は多重継承をしなくて済むならいいのですが、実際にはないと困ると言うのが
最初にあって、継承で解決するならスマートなのですが、実際にやると
解読困難な物になってしまうと言うのが次にあって、
インタフェースでやるとそれなりにできるが、スマートとは思えない、
と言うのが最後にあります。
最後のは個人的意見と言われればそれまでかもしれませんが。

>処理を追うより、まずは個々のクラスの役割を調べる&イメージするのが先決では？
確かに実際には処理を追う前に「クラスの役割をイメージする」事になりますが、
コメントが入ってない場合もありますし、ドキュメントがない場合もあります。
結局、全部見てからイメージを構成して、それに合っているか検証するような
流れになると思うのですが、この検証が困難です。
また訓練してもイメージ出来ない人も少なからず存在します。

>>359
コントロールもCWndの派生クラスだって解ってる？
ボタンやスタティックテキストがスクロールするようなお茶目な GUI 使いたかねーぞ。

確かに楽しいな。

>>361
ダメだね。お前は一生OOを使いこなせないよ。

>>363
説明出来ないからってそーゆー逃げは如何なものか。

>>361
ＣＨＴＭＬＶｉｅｗはどうする？

コモンコントロールとその他のコントロールでクラスを分けるのか？
その方が煩雑だ。　だいたい、これは設計思想の問題で、
ＯＯの適応の欠点ではないだろ。

結局、ダメだダメだとどっかの雑誌の講評を受け売りしてるだけで
誰も自分の頭をつかってＭＦＣを批判できないわけか。
それが２ｃｈクオリティってやつか。

俺の意見を述べよう。

ＭＦＣは実によくできている。　従来のＯＯセオリーを見事に設計に生かしている。

しかし、問題がないわけではない。
一つ目の問題はこのＯＯ思想のレベルが、処理系等の提供するＯＯ機能より高すぎたことだ。
言い換えると、多数のセオリーを設計に生かしたため、クラスライブラリが深い継承による
クラス階層を持ち、新たな問題を生んだわけだ。　つまり、やりすぎたわけだ。

このため、
クラスライブラリに含まれるあるクラスに基づき、特化した新たなクラスを作成する場合に、
そのクラスの各先祖クラスと相互作用する多数のクラスを継承したクラス群をも作成する
必要があった。

この問題は、例えばＣ＃ではインタフェース思想を強化し、ＣＡＳＥによる支援や
処理系によるレイトバインディング等を可能とすることで大きく改善れている。

そして、もう一つの答えは、委譲より継承を重視しすぎたことだ。
もう少し継承の浅いクラスを多く作成し、委譲を利用したクラスライブラリであれば、
先の問題を緩和できたと考えられる。
しかし、特化クラスの作りやすさより使いやすさを優先すべきクラスライブラリでは
正しい判断であったのかもしれない。

これについても、タイプライブラリの不要化などで対策されている。

MFCは判り辛いんだけど、、、
誰か教えて。

MFCはあまりいいライブラリではないのは認めるが、理解できないのは能力の問題。

>>371
基礎力不足だろうな。
一般書店に置いてるＯＯ本って、ＶＢ使いかｐ入門者を対象にして書いてある。
おそらくは、著者もＯＯを深くは理解できてないし、実務者は忙しくて本なんて書けない
んだと思う。　洋書漁るしかないね。

>>372
あのさ、ちょっと教えて欲しいんだけどさ。
生ＡＰＩってのがあるじゃん？ ＭＦＣってのは、あの生〜に
Ｃ＋＋用のラップかけて使いやすくした、ってことでいいのけ？

洋書って、アンタ英語わかるのか。わからないくせに・・・・

>>373
本当に薄くラップしただけなので、API 使うのと大差ない場合が多い。
部分的には改悪されてる場所もあるんで、MFC はよくないという意見もある。
まあ直で API 触るよりはマシか。

今日からオブジェクト指向を勉強しようと思います。
とりあえず明日までに最強になります。

マイクロソフト
ファウンデーション
クラス

だもんな。下地にしかならんよな。

ＯＯなんて半日勉強すりゃわかるだろ。

じゃあ一日かかる事を教えろ

==================================================================
プログラムなどやったこともないキチガイが、延々と妄想を語るスレ
==================================================================

↑そんなスレを仕切ろうとする無意味な自治厨

>>379
○○と××を２つ勉強すれば一日

CreateGame〜陸海空オンライン〜
有志によるMMO製作！
ただ今、２Ｄ、３Ｄグラフィッカ募集中！

オブジェクト恥垢

「ＸＸＸＣｏｎｆｉｇクラスはＸＸＸＸの設定を表現しまつ」と説明して、
「で、ファイルはどう読むのとか？」と聞き返す奴は相手にしづらい。

まぁ、フルパワーで詳細まで考えているんだろけど。

Ruby

>>385
その手のズレは今話していることが要求定義、分析、設計、実装の何れのプロセス
に属しているのかを最初にはっきりさせておくだけで劇的に改善できるよ。

日本語がヘタだねチミら

>>384
陰嚢クラスを使って精子インスタンスを作るんでつね

陰嚢クラスからは陰嚢インスタンスしか生まれないだろ

陰嚢　→ 精子工場 → SpermFactory パターン。

下品なことに非凡を感じさせる>>389-391

キチガイスレ

精子はFlyweightパターンで実装だな。

OOができないPGの将来はホームレス

>395
OOができても将来はホームレスだと思うが。

ヒント：キチガイが粘着中

>>394
精子をＤＢにつっこんだ場合、
後に一精子毎にインスタンス化することなんてあるだろうか？

>>1-398
目の覚めるような痛快でわかりやすい教え方のできる野郎はいないのか？
具体例を挙げるとか、なんかいろいろ工夫して俺に教えろや。

わかる気の無い奴に説明しても無駄だ
つーか普通に組んでたらわかるだろ

普通に組んでると構造化になってしまう。

データ中心、カプセル化。
変数（構造体）に付随する関数をひとまとめにしたモジュール化。
モジュールの雛形（クラス）から、必要な変数の数だけの実体を動的に割り当てる。
とはいえ、関数は１つを共同利用するんだけれど。

かのダイクストラ先生曰く、simulaは構造化プログラミングの道具に適した言語だそうだ。
C++もそんな使い方に充分に応えてくれる。

やっぱりオブジェクト指向ってなんなのかわからない……。

OOができないPGの将来はホームレス

>>401
オブジェクト思考は構造化の先にあるものだからそれでかまわんと思う。
コーディングレベルだと
構造化をきっちり組むとデータとそれに対する操作を
データそれぞれにもたせたい場面があったり、
関数のインタフェースが変わった場合の
ソース変更を最小におさえたかったりするときくらいかなぁ

設計段階ではデータとそれに対する操作をまとめることによって
設計変更等の範囲が容易につかめる、ってくらいか

もちろん上記の「〜くらい」ってのが
結構な差があるのは当然だけど

「オブジェクト指向じゃなきゃ〜」とか口先だけの人間が組んだ設計は
「構造化から再教育うけてこい！」ってのが多い希ガス

構造化と構造体の区別が付いていないキチガイ

構造化プログラミングを誤解していないか？
それとも構造化定理と混同している？

手続きだけじゃなくてデータにも構造を持たせるのは当然
その両方を考えないと構造の分割なんてできない

いつも>>402とか>>404みたいに意味の無いこと書き込むくらいなら
もっといい事書けよ、って思ってたけど、書かないんじゃなくて書けないんだということにいまさらながら気づいた俺がいますよ。

どこをどう読んだのかわからんが
普通に>>403を読めば
「データ」ってのが構造体を含んでると読めるはずだが・・・

正直言うと、このスレに巣食っている連中の程度の程(低さ)を図りかねていて、
どこまでレベルを下げれば対応できるのか、全くもって理解に苦しむ。

・・・>>403は結局何を言いたいの？
　　そして、あなたの言いたい事は、>>1みたいな変なスレタイつける煽りに対して、
　　有効に伝わっていると思うの？

>>408
お前が一番低レベル

なんでそんなに必死なの？
もしかして匿名掲示板以外、
人とのつながりが無いとか？

orz
色々（プログラムで）話したいけど
ないっす、つながりないっす
え？荒氏はしてないですよ〜たぶん。

>>408 こそ、何を言いたいのか解らんのだが。
>>403 は >>401 に答えただけやん。
>>1 が煽りかどうかは知らんが、何の関係が…？

レベル低すぎて、対応するのが面倒臭杉

>>413
あ、逃げた。

いや俺は「今度は逃げない」っつってた人の被害者だよ

ほら見てごらん、 異常者>>414が粘着してるよ

>>399
ことここに至ったのだから、
言葉では理解できない／説明できない事項であるのかも知れない
という可能性を考えてみては？

>>417
そら、図を示しながら、例を上げながら、つらつら説明できりゃ楽な訳だが、、、
掲示板の内容で理解できるなら、すごい薄い本で良書が発売されててもおかしく無い罠。

結局このスレの全員がよく分かってないということが分かって安心した

オブジェクト指向ができないPGの将来はホームレス

>>418 いや、そうでは無く、言いたかった事は
道の道とすべきは常の道に非ず なのだが。

オムスビ嗜好がないLittleGirlの将来はモー娘。

>>420
オブジェクト指向は今の時代は重要ですねｗ

>>423
ＳＥ・ＰＧのお勉強は果てがない。

と考えるのが素人

>417
つまり身体に覚えこませるしか無い訳ですね？

結局、役割分担。
これができない奴は一生ＰＧ。

役割分担どころか、全部自分でこなせなきゃ一生底辺PGだよ

君らがこのスレにぐだぐだ書き込んでる間にも
職場のできるアイツは勉強をしているぞ

＞ 職場のできるアイツは勉強をしているぞ
アイツ＝>>1？

CreateGame〜陸海空オンライン〜
有志によるMMO製作だよ。

おぃ、お前らの中で、仕様書書ける奴いない？
ちょっと手伝って。

>>429
いや、実際ＯＯのいい本ってないよ。

あったら教えてくれ。

↑閉世界仮説 (知らないものは存在しないというドグマ)　の例。

↑悪魔の証明を使った詭弁の例。

>>432
この本は良書に入ると思う
http://www.amazon.co.jp/exec/obidos/ASIN/4894713861/ref=ord_cart_shr/249-7031815-9797930?%5Fencoding=UTF8&m=AN1VRQENFRJN5

>>432　これは？俺はこれでだいぶ理解できた(気になった)んだが。

憂鬱なプログラマのためのオブジェクト指向開発講座
http://www.amazon.co.jp/exec/obidos/ASIN/4881356194/qid=1119374664/sr=1-6/ref=sr_1_10_6/249-9167514-6114769

最近のトレンドは後々勉強するとして、基礎的なところは技術評論社の「Delphiオブジェクト指向プログ
ラミング」片手に適当にDelphi触っていれば自然に理解できますよ。

…と、オブジェクト指向が良く解らないから教えてクレクレと言ってきた、初対面で随分年上な知人の知
人に進言したところ、「はー、Delphi。へー、Delphi」と鼻で笑われたのを思い出した。
（善意の）丸投げに失敗したので仕方なくC++上で軽く講義を始めたら最中に「年下なのに偉そうだな」
とまた鼻で笑われたのを思い出した。臑を蹴られながら。

>>437　常に「この概念はなかなか理解し難いでしょうが」「まぁ初心者には難しいですがね」
と前置きしながら数秒おきに鼻で笑う＆ニヤニヤする。
・・・という態度で教えてやれ。
で最後に「やっぱりCOBOLぐらいにしといた方が身のためですよ（はーと）」と言い放て。

>>役割分担どころか、全部自分でこなせなきゃ一生底辺PGだよ
いや、そう直に意味をとられてもな、
漏れはオブジェクト指向でもっとも重要なスキルはモデリングにあると言いたかったのだ。
いかに機能、役割の共通点をさぐるり、オブジェクトに割り当てるかが重要。オブジェクト
の機能の常にシンプル、漏れの仕事も常にシンプルがベスト。まぁ、なにげにクラスが
増えてしまうけど、自分が楽をしているのでよいのだ。

>>439
キミはオブジェクト指向の勉強よりも，日本語の勉強を優先させたほうがいいようだね

>>440
キミは日本語の勉強よりも、人に嫌われない人間性の勉強を優先させた方がいいようだね

>>437の言う、オブジェクト指向の基礎学習にDelphiってどうなの？

>>439は、実践ＵＭＬに掲載されている「ＧＲＡＳＰﾊﾟﾀｰﾝ」の話だね。
オブジェクトを擬人化して役割や責務を明らかにする・・・
・・・CRCカード分析手法と親和性が高そうな設計手法で、
なんとなく アクター理論やエージェント指向のノリも感じられる。

　個人的には、ドメイン・モデリング (ＤＢモデリング以外を含むＯＯの基盤)との関係が不明確に感じられる点、
分析設計〜実装で、それなりの経験を積んだ俺には、なんかとても稚拙に感じられるので、
あまり共感しないのだが。。。

とにかく>>439は断片的な説明をするのではなく、
長文で大枠からちゃんとした説明をするか、
あるいは売り文句を書いて情報へのポインターを示した方がいいと思うよ、
２ちゃんはソフィストばっかだからまともな話は通じにくいし。

　

× 分析設計〜実装で、それなりの経験を積んだ俺には、なんかとても稚拙に感じられるので、
○ 説明されているﾊﾟﾀｰﾝ内容は、(少なくとも自分でそういうノウハウを培ってきた自分には)
　とても稚拙で不充分な話に感じられるので

先に、国語の勉強をしな

負け惜しみばっかだな（ぷ

いまさらOOの勉強をしてるやつって手遅れじゃん

考え方を最初に学ぶと良いのじゃない？
http://www.amazon.co.jp/exec/obidos/ASIN/4798107123/250-6664582-2159462

>>448
モテ力(チカラ)を鍛えろ！って、
なんかHotDogPressとか青少年向けファッション雑誌みたいな煽りだなぁ〜

サブタイトルが激しく厨臭いな。
個人的には評価するまでもない内容と推測。

同時購入多数の「UMLモデリングの本質」はなかなか興味深い本なんだが

厨には無理

コラム「DOAとオブジェクト指向の違い」
第5章「ビジネスモデリングへの適用」
あたりは、アナリシス・パターンと同様なテーマを扱っていて、
なかなか面白かった。
他にもいろいろなテーマを語っているんだが、
和書でここまで濃い本は、他には知らない。

>>451
その著者が訳している
「オブジェクト指向とコンポーネントによるソフトウェア工学−ＵＭＬを使って−」
はどうよ？　誰か読んだ？

Object Technology Series 11ね。
EJBの余波で、再利用可能なコンポーネントのあるべき姿は何か調べてた時、
その手の本をガサっとまとめ買いして、随分保守的な内容にがっくり来て、それから読んでない。
(エジンバラ大の学部教科書だよね？)

何か話題がありますか？

オブジェクト指向な設計で一番考えるのは、
ポリモーフィズムをどう生かせるかだよね？

どうでもいいから、動くプログラム書け、このやろーーーー
散々オブジェクト指向のうんちくたれてた奴のプログラムが動かないのはどういうわけだ。
ついでにそいつが居ないのはどういうわけだ。

なんで漏れがそのプログラムを読んでる？orz........

>>456
だね。
俺は基本クラスの組み合わせ方に一番気を使う。
呼び出し元が同じようになってくれるのが気分いい。
プロジェクトの統率もとりやすいしね。

コードの再利用だろ。そういえばいいのに。
なにその回りくどい言い方。

OOじゃなくてOOPを教えろってことなのか？

>>459
・・・それは「クラスの再利用」では？

お前ら俺にオブジェクト指向を教えるなや！！

オブジェクト指向の勉強方法を考案しました。
1:Javaでブログシステム作成（構造化）
2:仕様変更
3:機能追加
4:破綻
5:作り直し
上記繰り返し。

ゲームを作ってるんですが
勇者というクラスがあったとして
戦うとか話すとかアイテムを使うみたいなのは
メソッドとして入れたほうがいいんですか？

戦うクラス、話すクラスみたいに
それぞれクラスにするのはよくないですか？

よくないねぇ

>>464
ぶっちゃけるけど
正解はないから好きに作ればいいんだが
話すクラスと戦うクラスってのは俺だったら作らないな

class Yuusha {
int hp;
int kougekiryoku;

void hanasu(Npc menomaeniiruhito){
menomaeniiruhito.speakMessage();
}

void tatakau(Teki t){
t.hp -= kougekiryoku;
}
}

こんな感じかねぇ。

ありがとうございますた
>>466の感じで行くことにします。

確かに、破綻、作り直しを繰り返すと
問題をどういうふうに切り分けたら
楽できるか考えられるようになるかもね

>>464
>戦うクラス、話すクラスみたいに
行動クラス作って、そこから派生しとくと
動的に (ストーリー進行次第で) 行動を追加出来る気が。

>>464
勇者がいるなら
魔法使いも賢者も武道家もいて
モンスターも町の人も教会の人もいて、
みんな話すんだろ。
んで、モンスターと勇者チームは戦うこともできるわけだ。
だったら「生き物クラス」を作って、話すメソッドを入れて
生き物クラスを継承した「民間人クラス」と「戦闘者クラス」を作って
戦闘車クラスに戦うメソッドを入れて、
勇者は戦闘者クラスを継承して、勇者独自の動きを書く、
てのがOO的じゃねの？

なるほど

コマンドをオブジェクトとして渡すってパターンもあるにはある

キャラクタークラスを作って
敵とプレイヤーを派生クラスにする

戦闘メソッドをキャラクタークラスを用いて書けば

敵　→　敵
敵　→　プレイヤー
プレイヤー　→　プレイヤー
プレイヤー　→　敵

というコードが

キャラクター　→　キャラクター

と四分の一になる

１は下を読んどけ、
http://www.amazon.co.jp/exec/obidos/ASIN/489100455X/qid=1119610579/sr=1-1/ref=sr_1_10_1/250-5850679-6024231
http://www.amazon.co.jp/exec/obidos/ASIN/4891004568/qid=1119610579/sr=1-2/ref=sr_1_10_2/250-5850679-6024231

２冊で、たったの１２，８１０円だ。

>>474
安いよな
この職業になるまえは「たけぇ」と思ってたが
本当に必要な本は一冊で何日分もの節約になるからなぁ

安いかもしれんがｽﾚ違い

↑、スレ違いではない、もまいも買って読め。

>>474
まず読んだ後で感想聞かせれ。その後で薦めれ。そして読んだあと俺にくれ。

コードコンプリートいいなぁ。・・・お金ないから買えないよぅ

漏れの読んだ中では唯一凝集と結合について説明してある本だった

ライブラリやコンポーネントを凝集度と結合度で評価するというのは、
随分古い、構造化時代の尺度という気がする。

　＞凝集度と結合度という概念は、コンスタンチンとヨードンが、その共著である「構造化
　＞設計」において提案した関数の尺度です。言い換えれば、これらは構造化設計の中心的
　＞テーマで、構造図を書くのも、設計時にこの尺度で判断して品質を織り込むためなのです

実際新しい本で凝集度や結合度の章を持ってる本って、あんまない。
俺の読んだ範囲でそれが載っているのは「実践UML」のGRASPパターンくらいなもんだ。。。

って俺、釣られた？

そういえば、最近とみに２ちゃんで話題になってる旧：情報処理振興事業協会も、
90年代前半に「新ソフトウェア構造化モデル」つう怪しげな名称のプロジェクトやってたな。

「構造化」という時代錯誤なタイトルの下、
中身はエージェント指向や構成的プログラミングだったあたり、
研究者の苦労が偲ばれる・・・

>>481
そうなのか？
じゃあお前はどうやって評価をだすんだ？
純粋に興味がある。

古い尺度だがオブジェクト指向においても
その重要度は変わっていないと俺は考えてるのだが。

釣りなのかしらんが。

>>481
凝集度と結合度で評価するのは「ソフトウェアを分割して考える」という
発想における基本中の基本。
であるから、それが構造化時代にさかのぼるのは当たり前。
より凝集度を上げるために、より結合度を下げるために、という発想の元で
よりよい分割法としてオブジェクト指向やアスペクト指向は提案されたのだよ。
それが本の一つの章を占めないのは、あまりにも根本的な考え方だからにすぎない。

というか、結合度を下げて凝集度を上げる、という目的以外に
「ソフトウェアを分割して考える」理由がない。

要素還元主義とイデア論かい

アフォオの脳内ワールドは楽しいワールドだな。
結合度を下げ凝集度を上げるという単純素朴な考え方では、
密に連携するパターン所属クラス間の関係や、
はたまたフレームワークを説明できんだろーが。
どこで結合度を下げ (例: レイヤー間、具体的にはプレゼン層とビジネスロジック層の間、等)、
どこで凝集度を上げるか (例: 1.クラス, 2.パターン, 3.コンポーネント, 4.フレームワーク)、
つうレベルで考えてないとすると、かなりヤバイな

原始人が「一致団結して敵と戦うことが重要だ」と主張してるようなもんだな

>>486の要点
「結合度を下げて凝集度を上げる」ことを否定していない

論点ずれてますよ？

日本語でしゃべってくれ。
アンタの論点が読み取れない (推測はできるけどな)

>>484
>結合度を下げて凝集度を上げる、という目的以外に「ソフトウェアを分割して考える」理由がない。
逆です。
「ソフトウェアを分割して考える」ために「結合度を下げて凝集度を上げる」のですが。

>>490 GJ！

パターン使って連携が密になっちゃパターンの意味がないじゃん……。

結局>>483に対する答えは出てきて無い訳だが

>>490
あほか。
ただの視点の違いだと。
最終的な目的は「生産性の向上」であり
その手段をボトムアップで考えていけば
「結合度を下げて凝集度を上げる」ために「ソフトウェアを分割して考える」
になるし
ボトムダウンで考えれば
「ソフトウェアを分割して考える」ために「結合度を下げて凝集度を上げる」
になるだけ

>>484は前段でボトムダウン的な流れをきっちり明記している訳だが

結局整理整頓が出来るかってことだと思う

何のために「ソフトウェアを分割」するのかわかっていれば、わざわざ基準を数値化する必要は無し。

ボトムダウン の検索結果のうち 日本語のページ 約 154 件中 1 - 20 件目 (0.54 秒)

>>496
評価＝数値化ではないぞ
そして解っていても問題は起きる

>>482
> そういえば、最近とみに２ちゃんで話題になってる旧：情報処理振興事業協会
話題になってんの？

>>490
じゃあ何のためにソフトウェアを分割して考えるの？

>>492
突っ込むべきか悩むレスだが…

一個のソフトウェアを構成する全てのクラスは当然連携するに
決まってるだろうが。
パターンとは結合度を低く保ったままでうまく連携させるためのものだ。

>>498
このクラスはほかのいくつのクラスに依存している…などで
結合度の数値化はできるけれども、それだけが評価基準じゃないしねえ。
結局は「経験と勘」ってことだよな。

>>490
失敬。書き間違えた。
正しくは、結合度を下げて凝集度を上げる、という目的以外に
「ソフトウェアの分割の仕方を考える」理由がない、だ。

ソフトウェアの分割自体はチーム開発などの開発上の事情で必然的に起こるとしても、
たとえば「データベースへの接続開始とHTMLの生成とを担当する部分」と
「データベースからのデータ取得とHTTPリクエスト受付を担当する部分」に
分割することは普通ありえないだろ。
普通はもっとましな分割の仕方を考える。
で、凝集度が高いとか結合度が低いってのは、ようするに
その「ましな分割の仕方」ってのを小難しく言い換えたものだ。

プログラミングスキルより、コミュニケーションスキル磨けよ

じじいとコミュニケーションするとクラスが単なる関数の集まりになるし、話すだけむだ。
結局、実装フェーズでクラス設計を論理レベルからやることになる。じじいのやってる
基本設計はまったくもって無駄。早く死んでほしい。

>>504
漏前のプロジェクトの愚痴聞かされても・・・

要件定義レベルだと成果物の評価がまともに出来ないから・・・
ある程度の規模のプロジェクトで
人を急いで集めると年だけ食ってて実は使えない奴が集まってしまうのは良くあること

で設計以降が別会社でデスマが始まるのも良くあること




コミニケーションスキル、って言葉だと範囲は広すぎと思われ

目上を馬鹿にしてるやつは例外なく無能。

目下から馬鹿にされる奴は例外なく無能。

最近の新人はダメなのが増えたな

>>481
古いからダメってのがいかすね。
インターフェースと実装の分離は結合度を下げる役に立つし、Loki のポリシーは凝集度を上げると思うのだが、古いかね？

まあ、コードコンプリートの欄外を立ち読みして、Coding Horror のイラストでも見てきなさい。

>>509
「古いからダメだね」
みたいな事をゆう奴が
頓珍漢な設計をする場合が多い

古くて使えなくなったものと
古いが継承されているものとの区別が付いていない希ガス

あんたは間違った事を言って笑われているのではなく、
具体性が乏しく、現代のプログラミング技術から見ると素朴過ぎる単純議論をしつこく主張し、
しかもそれが否定されているかのような被害妄想的な下らない議論、ためにする議論を展開するから、
皆に疎んじられるんだ。

「何を」「どのように」「結合度を下げ凝集度を上げる」のか、
また現代的な設計/プログラミングのイディオムにおいて、どのように実現するか、
ってな話を抜きにして、「パターンとは結合度を低く保ったままでうまく連携させるためのものだ。 」
なんていう天下りな信念表明をしても失笑を買うだけ。

要するに、単純明快原理主義バカ

>>511
あんたは間違った事を言って笑われているのではなく、
具体性が乏しく、実際の議論から飛躍した主張をし、
しかもそれが否定されているかのような被害妄想的な下らない議論、ためにする議論を展開するから、
皆に疎んじられるんだ。

「何を」「どのように」「結合度を下げ凝集度を上げる」ために、
具体的にどのような手法を使ってるのか、
ってな話を抜きにして、「現代的な設計/プログラミングのイディオムにおいて、どのように実現するか 」
なんていう超越的な信念表明をしても失笑を買うだけ。

要するに、口先だけのバカ

馬鹿馬鹿いうやつが馬鹿の法則

プログラミングのイディオム・・・・ なにこのｷﾓﾁﾜﾙｲ言葉

それよりも
>現代のプログラミング技術から見ると素朴過ぎる単純議論
の方が面白い。これを言うためには
単純議論から筋道立てて自分の主張までの発展を理論展開しなきゃね

鸚鵡返しレスは正直飽きた

結局俺の問いに答えられる奴は現れなかった

>>1は何が分からないの？

レトルトの料理で喩えると分かりやすいかもよ。
カレーもシチューもパッケージを開けて、器に盛り付けて
電子レンジに掛ければ食えるものができる。←カプセル化、操作の抽象化

料理を作る人は、カレーとシチューの原料を知る必要はないし、鍋で煮るのか
フライパンで炒めるのかも知らなくていい。←責任の分担

さらに製造工場にとってカレーとシチューの製造工程は途中まで一緒で、
最後に何で味付けするのかで種類が決まる。←多態性，継承と差分プログラミング

↑まぁ、先生様はそう教えるけどな、実践じゃ役にたたんよ。
百戦錬磨、生き抜いた者だけが、オブジェクト指向のパラダイスを実感できる。

>519
オブジェクト指向なんてセコいもんじゃ
なくて地上の楽園でも行ったらどぉ？

レトルトばっかり食ってる貧乏人のセンスはまるでわからない

自己紹介乙

>>521
ファミレスの料理も厨房はあんな感じだよｗ

久々にちゃんとした町の洋食屋に行ったら、
ファミレスは要するにコンビニ弁当だと気付いた。

イマドキたった880円であんな感動が得られるなんて、
日本もまだまだ捨てたもんじゃない、と思った。

オブジェクト指向をたとえ話で説明されて分かりやすかったためしがない

オブジェクト指向だろうと手続き型だろうと、コンパイルしてしまえば全く同じになるでしょ。

ようするに、人間が管理しやすくするためだけの手法がオブジェクト指向。あくまで目的ではない。

ねぇ、ここに粘着してるキミは、
明日の仕事は無いのかな？
つか、未来永劫仕事無いのか？

・・・気楽でいいなぁ、落伍者は

たとえ話がワカンナイって人は、ソフトウェア業界に向いてないのよ。
抽象的な考え方ができなような、女みたいな脳ミソの人はべつの
業界に行った方がいいでしょう。その方がシアワセ。

無理して分からないことを、分かろうとするのは苦痛なだけ。

>>528
例え話は結構だが、如何せん誤謬に過ぎないわけで
それで説明した気になられても困るなあ。
>女みたいな脳ミソの人は
莫迦ですか？
学習タイプが違うだけでしょう。

これだけ本もたくさん出ているのにまだわからないなんてヤシは落伍者決定

わからないならわからないでいい。

>>529
>>528みたいな選民思想の人は、
特に一分野に関して飛びぬけて才能があるわけではなくて
一分野だけまともで他全ての分野に関して飛びぬけて無能だから
せめて人並みな一分野だけでも守っていかないと
自分がﾀﾞﾒ人間だと、人として生きていくうえでの基本的スペックが劣っていると
自ら認めてしまうことになるから必死なんだよ。
生暖かく見守ってやってほしい。

>>532
頭悪い文章だけど女かね？

俺こと>>1はもうわかったので、
この後は>>534がわからない代表を引き継ぎます。
それでは、>>534さん、お願いします。

言い忘れたけど、書き込んだ時点でOOがわからない人に強制的になるということで。でわ

あ！！　忘れた。

極論、クラス図とシーケンス図を使って設計すればＯＯ。

ははっ、面談でいきなり↑みたいな話になったな、なんか議論になってしまい、
結局、漏れがそのプロジェクトを断った。奴は「単なる絵だろ」だってさ。どうでもいいけどね。

>474 名前： 仕様書無しさん 投稿日： 2005/06/24(金) 20:00:24
>１は下を読んどけ、
>>http://www.amazon.co.jp/exec/obidos/ASIN/489100455X/qid=1119610579/sr=1-1/ref=sr_1_10_1/250-5850679-6024231
>http://www.amazon.co.jp/exec/obidos/ASIN/4891004568/qid=1119610579/sr=1-2/ref=sr_1_10_2/250-5850679-6024231
>
>２冊で、たったの１２，８１０円だ。

買うか迷ってるので、もうちっと情報をくだはい。
当方、田舎在住なもんで、現物が見れない。。。

っていうか、あんな分厚い本、気楽に読めないっす

>>539
漏れが読んだのは１０年位前で分冊される前だった。
いい本だったように記憶している。
今は誰に貸したかわからずに行方不明だ。

ほれ、
漏れの下で働く場合には、クラス設計は必読じゃ、
http://www.atmarkit.co.jp/fdotnet/bookpreview/codecomp2nd_index/codecomp2nd.html

>>533
そうゆう発想をするのは40代以上のオッサンだな。
自分独自の固定観念に囚われるアホですわｗ

>>543
要するに>>533=>>528ってことなんだろ。
図星突かれすぎて差別発言しか言い返す言葉がなかったと。
選民思想ならではの自己中なんだよ。

>>541
1994年8月31日初版発行のやつね。
第二版は本屋で立ち読みした限りでは、「同一なのはタイトルだけ」程度に内容が違う。
御確認をお奨めする

>>532が女で>>533が40代以上のオッサンであることだけはわかった。

>>546
>>543

>>534

>>534

>>534

　　　　　＞　＞　５　３　４

>>538
設計した後にＵＭＬにしたんじゃ、単なる絵になるけど、
それは設計に使ったとは言えないでしょ。

オブジェクト指向設計手法を統合した結果、ただの表記法となったというのは
興味深いよね。　表記法って大事なんだと思う。

おまいら、ショッピングカートのシステムくらいなら、ＯＯ使って何時間くらいで設計できる？
適当に条件設定して見積もってみてくれ。リスク無しでな。

>>549　

ﾊｧ？？？

単に、方法論〜開発プロセスは統一の対象となりえないから、
せめて表記法だけでも統一して、同じ土俵で対比できるようにしよう、
というのが当時の判断。方法論を無視するのは、枝を見て幹を見ない恥ずかしい行為。

ちなみに、UP/RUPの源流となった諸手法のうち、
・Shalaer/Mellor手法、MArtin/Odell手法、Rumbaugh OMTは、
　ある程度、反映しているものの、
・シナリオベース手法(JacobsonのOOSEやAlger/GoldsteinのOBA)に関して、
　ユースケース・シナリオは記法ではないので含まれていない
・Wirfs-BrockのCRCカード手法は、丸っきり含まれていない
というのが現状だ。

はたまたあんたUML判ってるつもりでも、
OCLなんてほとんど使って無いだろう。

つまり、あんたが見ているのは統一できた表記だ。
そして一番肝心な事は、表記だけでは開発はできない、という事だ。

>>550
与信部分の知識の有る無し/与信や決済に関する既存システム再利用の度合い
で随分変わって来るよ。。。
なんて話は、トイ・プログラムしか見た事のない厨房には理解もできないだろうな

ネットに転がってるソースをコピペって終了。５分くらいかな。

>>551
キーワードいっぱい書けてうれしそうだな。厨房。

>>552
ショッピングカートに勘定系までいれる気か、厨房は。

>>550
機能クラスには、顧客、商品、カート（注文、注文明細）、支払い手段、の５クラスくらいで想定して、
多少商品にイレギュラーな要求が入ったとしても、ん〜、８時間はかからないな。
ありがちなシステムだし。

実装クラスで、最低限のセキュリティ考慮して、ん〜、８時間かからないでしょう。
よって二日未満。

ありがちなシステムだとうまく見積もれないな。大きく言うのは簡単だけど。

なんだ、下らん。
「ショッピングカートのシステム」つうのは、
ネット通販サイトの商品カタログ＋ショッピングカート限定の話か。
そんな末端の仕事の見積もり作った事ねぇ〜よ

SIerじゃなくて、下請けWebプログラマのお仕事だね、
勘定系抜きのショッピングサイトなんて

俺は、ショッピングカートを下請けＷｅｂプログラマに投げる勇気はないな。
どんなコードになるのか予想付かん。

でも、このスレのレベルにはあってると思うけどな。

ところで、勘定系なんて分析プロセスの問題であって、
設計プロセスでは簡単、ありきたり過ぎて話しにならん。

>>559
素人乙

>>560
　>>559って、おまいが使ってる下請け業者じゃねぇの（笑

いや、>>559みたいなバカは使っていない

>>557
勘定系は皆何度も見てるので面白くないだろうし、
　不良品識別用の画像処理システム
　RFIDによるコンテナ追跡システム
ぐらいのネタで見積もってください。

コアな実装（例えば車周りのシビアなリアルタイム処理等）ネタ
はご遠慮下さい。

出来ないんだったら、ショッピングカートでも見積もっとけｗ
ってか？

>>563
いやさ、あんたが素人なのは発言の隅々に現れているから判るんだけど、
素人の癖に、
　＞勘定系は皆何度も見てるので面白くないだろうし、
これはないんじゃないか？
知ったかぶりで発言するのはやめたまえ。
電子商取引の決済系は、
会計分野の勘定系とは全く別のコアな技術が必要。
素人さんには難しすぎるかなｗ

>>565
そう厳しい言葉遣いをするなって。
単にWebでサイト作って、難しい所は他社のサービスに丸投げ、
みたいな末端の開発しかした事ないんだろう。

カード会社や信用情報サービスのような基幹を知りつつ、
Webサイト側もやっているという人間は、結構少ない。
だって前者は「金融系」って事になってるからｗ

クレカ周りの話しか…
ＯＯとは関係ない希ガス。

>>563
RFIDかぁ。たしかRFIDをメインに据えた研究所が、一昨年求人出してたな。
応募したら、「もう東京では営業しかとりません」とか言われてそれっきり。
国土交通省の実験に参加してた奴は、近所に住んでるけど、
あまり詳しい話は聞いてないな

>>566
横やりだが、
カード会社のサービスなんて、昨今、弱小企業でも使ってると思われ。

>>567
ぶー。EDI〜SOAに繋がる、かなりコアな話題だよ。
もちろんOOも関係する

やはりWEB系は厨が多いな

>>566
ごめん俺の周りにはメジャーな仕事やってる奴しか居なかったから、
弱小会社でカードの仕事って理解できない。単なる派遣か下請けでしょ、どうせ

でた。メジャーな仕事

>>570
そういうのやってるんだ。
名前は何度か聞いたことあるけど、
漏れの世界とは違うから、わからんかった。

>>571
ちなみに、Web系の技術は組込でも使う。
当然一般的な鯖とは違う。余談でした。

>>572
俺も知らない。　メジャーな仕事って測定機器か何か？
脈拍でも測ってるの？

>>569
ああ、判った。
俺の周りには、複数のカード会社に跨る与信や一つのカード会社の決済の、
基幹サービスの実験/設計/提供やってる奴が全然別系統で２グループ居たから、
そーゆー話題を一般の人は知っているのかなぁ？って意地悪質問をした。

あなたがおっしゃっているのは、そのサービスをユーザとして利用するって事ね。
もちろん上であがった課題の与信/決済は、そのサービスを使えば設計/実装できる。

>>575
お。それは学生時代の基礎研究だから。。。今は関係ない。。。

結論：Ｗｅｂ系の話しぐらいしか、共通点はない。

>そのサービスをユーザとして利用するって事ね。
毎回作ってたら大変だわな

マ板住人の履歴書が欲しいな。まったく。

書いてる内容でだいたい判るでしょ

わからない。
まるでバベルの塔だ。

>>581
まぁ俺の場合は、正規の履歴書/職歴書には載らない、
周辺部の話題しかしていないから、人物が特定される事はないと思うがｗ

何をわけの判らんことを

要するに、事実・真実のみを語るという俺のポリシーと、
匿名掲示板で身元を同定されるようなマヌケな行為はしたくない、
という矛盾した要求を、俺なりにこなしているということ

IWIか

だれも影の薄い奴の素性になど興味ないと思われるが

おっけ。
で、回答が来ても知らん振りの>>550は、
例によって例のごとく単なる素人さんでしたか。やっぱね

>>568
実験・・・ああ、某総研が企画・立案・運営やってる一連の話ね。
それは総研の方でも話を聞いた

>>583みたいな基幹系やってる人は
みんなこんなに偉そうなの？
要するに部品作ってる町工場じゃん。

>>590

>>583=>>588
こいつは、コンプレックスがあって自分に自信がないんだよ。
だから必死にＷｅｂをバカにしてみたり、素人認定してみたり、自分の履歴を偉そうに
語りたがったりしてる。ﾎﾝﾄかどうかも怪しいけど。
あと、ｼﾞｻｸｼﾞｴﾝもか。一方でOOの話しは怖くてできない。

この業界の不適合者は非常に多い。哀れなもんだ。
おまいらも気を付けろ。

単に住んでる世界、見ている視点が違うだけだよ。

で>>550は>>556の噴飯物の回答 (５クラス、８時間)　にどう反応するの？
また息を潜めて死んだフリか

問題定義が不充分な場合に、要求内容をインタビューして固めていくのも重要な仕事。
つか、それが一番時間がかかるんだよな

ショッピングカートのCGIをしこしこ書いてるPerlerおつｗ

で>>550は>>556の噴飯物の回答 (５クラス、８時間)　にどう反応するの？
また息を潜めて死んだフリか

>>595
おつかれ〜

５クラスか？
漏れは以前、面談で、「いくつクラスをつくりましたか」と聞かれ、
「しとつ」と答えたことがある。とくに突っ込みはなかった。

まぁ、５年くらい前ではったりJavaPGだったんだが。
概念モデルなら、５クラスでもいいけど、実装となるとクラスは増えるよな。

>>545
じゃ買ってくる。

かまって厨があばれてるな。
なにがどう噴飯なのか説明してみろよ。
お勉強できないんなら、せめて黙ってみてればいいのに。

真昼間から血圧高いヤシだな

そろそろまじめにオブジェクト指向を教えてくれてもいいだろ

>>602
この程度しか良いの見つかんないわ

http://www.g-m-o-s.com/join.php?tp=txt0630sample_title&id=321

>>603
d(>_･ ) ｸﾞｯ ｼﾞｮﾌﾞ!

埼玉ろそな銀行
所沢支店
普通4585754
ニシダテヒロタカ

には送金しないこと、お客様情報を知っているふりをしているだけ。
だが、ニシダテは実在するので、ﾀｲｰﾎ

そうだな、 埼玉ろそな銀行に連絡すれば口座凍結するだろ。

>>603
ﾊﾞｯｼﾞｮﾌﾞ　死ね
フィッシング詐欺師は厚かましいから消えろ

こんなフィッシング詐欺に引っかかるヴァカいるのか？
こんなので金払えとほざくなんて虫が良すぎるぜ

あまりにも問題なさ杉

↑の口座をATMで照会しようものなら、ﾋﾟｨｰﾎﾟ･ﾋﾟｨｰﾎﾟ・ﾋﾟｨｰﾎﾟ
さて何処に出没するでしょうか、

フィッシング詐欺ではないだろ、詐欺サイトそのものだから。

厨房大杉だなこのスレ

たしかに厨房は自作自演しまくるから、
一匹居るだけでも多過ぎだな

メールで抗議しときましたが、なにか。

兄貴、警視庁勤務ですがなにか？

>>615
こんなんでホントに動いてくれるの？
お前の兄貴よりも消費者相談センターの方が頼りになりそうだな

警視庁経理課の事務員だったりして

お金振り込んだけど何も連絡がありません。
もしかしたらちゃんと振り込まれてないのかと思い、もう一度振り込みました。
もう１日待ってみようと思います。

>>618
(？？∀？？)

＝＝＝＝＝＝＝＝＝＝
キチガイスレ
＝＝＝＝＝＝＝＝＝＝

オブジェクト指向できないやつって馬鹿だな

むしろこのスレ読んで分かったら神。

とりあいず、勉強のために説明してみます

もし機械にたとえたら、クラスが機械で、関数がその機械の部品
そして機械への追加機能として新たに部品が、付け加えられる事を継承

じゃおまえらチンポのクラスでも定義してみろ。
ちなみに女経験回数はprivate指定な。
俺の場合初期化時のまんまだからpublicにはしたくない…

>>622
確かにこのスレだけで分かったなら神だな。
まともな本を読んでも分からないのはただのヴァカだが。

>>625
それでも、何をクラスにするかっていう現実的な問題には
明確な方針は出てないけどな。

構造化解析ならこんな問題はなかった。
本を読んでわかった気になってる連中は、わかってないことに
気付いてないだけとも言える。

モノの捉え方だから人によって違う結果になる

Createしたら即効Destoy。

>>626　このスレにはそんな話題など出ていない。一般向け書籍には「何をオブジェクトとして検出するか」という話題は明示的もしくは例示的に示されている。

デザパタを勉強したおかげで本物のOOが見えてきた感じがする
今度はGoF本にチャレンジします

>>630
あくまでも感じがしてるだけね。

>>626
つまり、
俺に分からないのだから分かる奴などいるはずが無い。
俺に理解できないことが正しいことのはずが無い。
相対論も量子力学もインチキである。
と、言いたいのですね。

人によって何をオブジェクトにするか違うんじゃ再利用も糞もあったもんじゃねーな

ライブラリやフレームワークでカタにはめることで
再利用を促すという考え方もある

結局、「この本読んだだけでオブジェクト指向理解出来た！！」って人いるの？
なんか、理解出来た気がするとか、多分理解出来るだろう、的なのばかりだが。
実体験で本だけで理解出来た人の書き込み求む。（できれば書籍名も）

#そんな本は存在しない　と思うのは俺だけか？

書籍＆処理系セットで、俺のOO経験を少し説明。

1988年
処理系：Smalltalk/V
書籍：　宝島(!)のSmalltalk/V本 (小田嶋隆 著)
コメント：それまで書籍の上で想像するしかなかったSmalltalkの世界を
　　　　　実体験し、オブジェクト指向プログラミングの実態を見せてくれた
　　　　　環境＆本。
　　　　　小田嶋氏は現在、普通のライターさんをやっているのだが、
　　　　　本書籍ではMVCフレームワーク〜グラフィックス・プログラミングの事例、
　　　　　そしてObject〜MetaClassの階層構造まで一通りの説明を試みており、
　　　　　今思えばデザインパターンに通じる「イディオム」の存在を体感させてくれた。
　　　　　漏れにとってはForever Greenな思い出が一杯つまった良書。
　↓
1988年
処理系：Xlisp, Xscheme
書籍：　Winston's Lisp、Prolog/KR
コメント：Xlispは、Apple Dylan言語作者であるDavid Michael Bet'z氏作成のLisp処理系。
　　　　　X11にはHPのコントリビューションとして、Xlispベースのアプリ構築ツールが含まれている。
　　　　　またAT&Tの統計処理言語Sとよく似た目的で、Xlisp-statというのがあってそれなりに有名。
　　　　　Xschemeはバイトコードマシンによる実装がなされており、VMに関して学ぶ材料になった。
　　　　　Xlisp, Xschmeとも、Michael Bet'z氏独自のオブジェクト指向拡張がなされている。
　　　　 (階層頂点のObjectと、インスタンス生成用Classのみのシンプル構成)
　　　　　XlispはCommon Lisp準拠？のStatic Scopeだが、所詮インタープリタ処理系なので、
　　　　　ソース数箇所を変更するだけでDynamic Scopeに変更してProlog/KRの実習にも使えた。
　　　　　Winston's Lispには、Lispの基本的なアプリケーション例が網羅されており、
　　　　　「別の形のオブジェクト指向の可能性」を考えるのに役立った。
　　　　　Prolog/KR本には、Lispで書かれたProlog/KR (Uranus)や、Smalltalkコアが載っており、
　　　　　オブジェクト指向に限らずLispで言語実験をするというスタイルを学ぶのに役立った。

本を読んでもオブジェクト指向がわからない人っているの？

>>638
お前をはじめとしていっぱいいるみたいね。

実際にまともに設計したことのない奴程、わかった気になりやすい。

本を読んでも数学がわからない人っているの？

>>641
いるんでない？
公式とかだけ覚えようとして練習問題やらないとかさ。
オブジェクト指向も、ちょっとしたサンプルで自分で実験してないと、ちゃんと理解するのは
難しいとおもうけどな。

君之所読者、古人之糟魄已

慣れの問題なんだろうけど
オブジェクト指向とか意識すると
時間かかる

まあ、なんだかんだ言って手めぇの指ぃ使って覚えろってこった。

>>638
本読んだだけで理解するなんて並大抵のことじゃないよ。
｢理解した気になる｣ことなら簡単だがね。
やはり自分でちょっとした規模のアプリを設計してみないと身につかん。

>>603
ワンクリック詐欺つかまったで、

>>647
マ板はネタ板だから変なのが粘着するのはしょうがないけど、
あんたスレ違いの話題にしつこく粘着し過ぎ。
寂しい人生送ってる哀れな奴だと皆知ってるから誰も指摘しないけど、
そろそろコミュニケーションマナーを守ってはいかがか

結局は経験だろ。
本読んだだけでわかったなんてありえないとｹﾛﾛ軍曹もおっしゃってる。

性器　←ーー
↑ |
マンコ チンコ

インターフェースの実装はこれでいいですか？

相変わらずこのスレには下痢便がこびり付いてるな

さんざんクラスでないクラスを作った後、ふとオブジェクト指向のいうものがわかる。
プロジェクトには悪いが、そんなもんだろうな。とりあえず、Java docでも見せてもらえば、
オブジェクト指向であるかないか、漏れが判断してやる。

ちなに、今のプロジェクトの他チームが作っている通信用クラスは落第。
でも、他チームだし、漏れが口だしはできない。これが世の中の現実だ。

>>652
クラスでないクラスって、たとえばどうゆーヤツ？

おまえの、オブジェクト指向であるかないかの判断基準は？

他チームが作っている通信用クラスはどうして落第なの？

ここはおまえの愚痴スレじゃねーんだぞ。スレタイ読んだか？ ん？

>オブジェクト指向であるかないかの判断基準は
誰も答えられないから問題なんじゃね？

>>652はいつから人のクラスを「漏れが判断してやる」とか言える位偉くなったの？

>>654
するどい。
「このｽﾚの問題点の表象を正しく表現している」

オブジェクト指向に限らず、文系ちっくな知的仕事に付きまとう問題だな。
そしてセンスの良い人は、他人に説明されるまでもなく、良い道を選び取る事ができる。
オブジェクト指向も然り。素人に妥協しはじめると、どんどんスキルが低下する。
結局あんたら素人は、プロの仕事を見て自助努力しなさいってこった

素人でもいっぱしの意見を騙るが、
素人には実践を伴った充分な議論展開など大抵できない、
という意味では、心理学や恋愛論に通じるものがあるな。

その理由は、オブジェクト指向の本質の一つが「認識論」だからだ

>657
で、おまえは努力の真っ最中ってわけだな。

↑引き篭もりが一人前の口を利くなつうーの。

２ちゃんなら、バカでも相手にしてもらえてよかったね

じゃ、まずはオブジェクト指向の、"オ"、から、　どうぞ〜

頭悪過ぎ

>>658みたいな人いるよね
何もわかって無いのに、とんちんかんな屁理屈を
得意満面に話す人

オブジェクト指向なんてそんなに難しいもんじゃないだろ
屁理屈厨みっともないな

いまだにオブジェクト指向ができないリストラ寸前PGがもがくスレか

相変わらず哀れな奴だ

最後に人間と直接話をしたのは、何年前ですか

ここに粘着してる精神障害者って、引き篭もりなどという上等なもんじゃなくて、
世間への恨みつらみでいっぱいいっぱいの浮浪者なんじゃないかと思い始めた。

少なくともスレタイが理解出来ない人はいるね

PGの人って、P2Pやってる人とかいるのかなぁ？
会社とか密かにやってる人とかもいるのかなぁ？

そら世の中には居るだろ
むしろそういうの開発してるやつもおるだろうし
手軽なところでは Skype 辺りは職場で推奨してるところもあるだろう

でだ
おまいはそれを知って何がしたいんだ？

オブジェクト指向で書くようになって2年、
未だ「便利」というより「メンドクセ」という気持ちの方が強い。

やっぱり自分用のライブラリとか作る勢いで書かないとダメなんだろうか。。。　orz

>>671
俺様ライブラリというか部品集を作るのはイイよ。
普段から出来るだけ俺様ライブラリを利用＆拡張していくように
プログラムを書いていくと、じわじわと効いてくる

>>671
どこかで読んだが。
バージョンアップ五回目くらいでOOの恩恵が実感出来るようになる　との事

いまだにオブジェクト指向ができないリストラ寸前PGがもがくスレか

そうそう、>>667みたいな真昼間に煽ってる無職とかなｗ

無職に粘着するお前も相当・・
そっとしておいてやれっつーに

脊髄反射するヤツってかわいそう　ﾁﾝｹなプライドに固執してる感じ・・・・

>> 未だ「便利」というより「メンドクセ」という気持ちの方が強い。
そうなの、オブジェクト指向を完璧にマスターした漏れは実装が「楽」になったと感じる。

だだ、きちんと上流工程からオブジェクト指向設計をせず、クラス図すらないプロジェクトは
ｵｺﾄﾜﾘﾀﾞ。(曖昧模糊な基本設計書とやらを出されてもﾔｸﾆﾊﾀﾀﾝﾖ)

　 ,j;;;;;j,. ---一､ ｀ 　―--‐､_ l;;;;;; 　
　｛;;;;;;ゝ T辷iﾌ i 　 　f'辷jァ　 !i;;;;; 　 オブジェクト指向を完璧にマスターした
　 ヾ;;;ﾊ　　　　ﾉ　　　　　　　.::!lﾘ;;rﾞ
　　 `Z;i　　　〈.,_..,.　　　　　　ﾉ;;;;;;;;>　　そんなふうに考えていた時期が
　 　,;ぇﾊ、　､_,.ｰ-､_',. 　 　,ｆﾞ: Y;;f 　　　俺にもありました
　　 ~''戈ヽ 　 ｀二´ 　　 r'´:::.　`!

>>679　誰かがやると思った（笑）

ロンドン・ジ・エンド

> だだ、きちんと上流工程からオブジェクト指向設計をせず、クラス図すらないプロジェクトは
> ｵｺﾄﾜﾘﾀﾞ。(曖昧模糊な基本設計書とやらを出されてもﾔｸﾆﾊﾀﾀﾝﾖ)

上流工程(要件定義、外部設計、方式設計)を本当にオブジェクト指向でやる
能力がある上流工程担当者などほとんど居ない事を、
業界関係者なら知っている。

したがって、>>678は業界の外のひと。

OMT（古っ）も知らずに、UMLマンセーな奴はいっぱいいるがな（ｗ

>>682
自分の周りだけが業界だと思ってるんだね。
で、>>682の周りにそういうのしかいないと。
「類は友を呼ぶ」ってのはつくづく至言だな。

＞オブジェクト指向を完璧にマスターした漏れは実装が「楽」になったと感じる。

当面の問題はクリアしたってことでしょ。

俺も、設計は楽になったと思うよ。
データの仕様がちゃんとある場合はね。
ＤＯＡだと既存のＤＢの構造が出てきちゃうからね。

ただ、楽してる分、完成品の処理速度は落ちちゃうね。

なんちゃってフレームワーク（一応、日本製商用）を採用して、DAOと、ビジネスコンポーネントが分離できない。

それでも俺様が分離して見せたら、フレームワーク屋（一応、日本製商用）が
コンサルにきてそういう使い方は想定してないだと。
へぇー、へ、やっぱりJava風C言語（Java風COBOLとも言う）なんだよなぁ。
まぁ、上流工程のSEも理解できるしそれでいいか。

>>684
ほほう。それでは具体的企業名を教えてもらえませんか？
是非、今後の発注先の検討材料にしたいんで。

>>686
隣の板でフレームワークの議論バリバリやってるスレと丁度正反対の意見を書いてるんで、
萎えた。もっと詳しく。なんて言うのも面倒。

＝＝＝＝＝＝＝＝＝＝＝
世間に恨みつらみのある
浮浪者もどきが常駐煽り中
＝＝＝＝＝＝＝＝＝＝＝

俺の立てたスレがこんなに盛り上がってるなんて、感動です！！

　||￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣||
　|| ○荒らしは放置が一番キライ。荒らしは常に誰かの反応を待っています。
　|| ○重複スレには誘導リンクを貼って放置。ウザイと思ったらそのまま放置。
　|| ○放置された荒らしは煽りや自作自演であなたのレスを誘います。
　||　　ノセられてレスしたらその時点であなたの負け。
　|| ○反撃は荒らしの滋養にして栄養であり最も喜ぶことです。荒らしにエサを
　||　　与えないで下さい。 　　　　　　　　　　　　　　　　 Λ_Λ
　|| ○枯死するまで孤独に暴れさせておいて　　 ＼　(ﾟДﾟ,,)　ｷﾎﾝ。
　||　　ゴミが溜まったら削除が一番です。　　　　　 　⊂⊂ |
　||＿＿＿ ∧ ∧＿＿∧ ∧＿＿　∧ ∧＿　　　　　 |￣￣￣￣|
　　　　　　(　 ∧ ∧__ (　　 ∧ ∧__(　　 ∧ ∧　　　　￣￣￣
　　　　〜（＿(　　∧ ∧＿ (　 ∧ ∧＿ (　　∧ ∧ 　は〜い、先生。
　　　　　　〜（＿(　 　,,)〜（＿(　 　,,)〜（＿(　 　,,)
　　　　　　　　〜（＿__ﾉ　　〜（＿__ﾉ 　　〜（＿__ﾉ

オブジェクト指向の本質が認識論というのは俺は結構同意なんだけど
ここでは駄目か？

複数のクラスに上下関係を持たせず対等に扱いたい場合はどうすればいいかな
土台のクラスの上にメンバとして持たせるのが面倒なら
グローバルで持たせるのもあり？

オブジェクト同士の通信という見方で言えば
俺はありだと考えてるんだけど。

>>692
元々は知識表現（人工知能）の研究から派生してるんじゃないのか？

用語も図示の仕方もかなり似ている。

で、1は結局オブジェクト指向理解出来たの？

>>692
認識論ってどういうこと？ もっと具体的におしえてくれ。

インターフェイスも知らんアフォか

認識論：

この世界をどう見るか？どう認識するか？という問題。

認識は、人間の内部的な思考作用にすぎず、
何らかの形で外部化しなくては、現実世界に影響を及ぼす事ができない。

そこでここでは、認識の外部化の例を示そう。

オブジェクト指向で使われるUML表記では、
ソフトウェア分析/設計における複数の視点(ビュー)を、
下記のような複数のモデルで表現する。
これがUMLによる分析/設計対象の認識である。

( 静的モデル, 動的モデル, ) × ( 機能モデル, データモデル, 状態モデル, 手続きモデル, 協調モデル, 実装モデル )
　・ユースケース図　　・・・　動的/機能モデル
　・(ドメイン)クラス図　・・・　静的/データモデル〜
　・ステート図　　　　　・・・　状態モデル
　・アクティビティ図　 ・・・　動的/手続きモデル
　・シーケンス図　　　 ・・・　動的/手続きモデル
　・コラボレーション図・・・　協調モデル
　・配置図　　　　　　　 ・・・　実装モデル

エンタープライズ・フレームワーク(EA)の枠組みとして有名な「ザックマン・フレームワーク」では、
企業システムを下記のような枠組みで認識する。
(詳しくは、例えば@IT記事やZachmanのホムペを参照。)

　　　　 ＼　　専門軸(５Ｗ１Ｈ)→
　　　　　　＼
　　　　　　　 ＼　　　データ　　機能　　　ﾈｯﾄﾜｰｸ　　人　　　　ﾀｲﾐﾝｸﾞ　　戦略
　　　　　　　　　＼　 (What)　　(How)　　(Where)　　(Who)　　 (When)　　(Why)
抽　スコープ　　　　
象　　(計画)
度　企業ﾓﾃﾞﾙ
..・　　(ｵｰﾅ)　　　　
視　ｼｽﾃﾑﾓﾃﾞﾙ　　　
点　　(設計者)
軸　技術ﾓﾃﾞﾙ　　　
↓　　(開発者)
　　 詳細仕様　　　
　　　 (下請実装者)

>>699 に挙げたUMLの視点(View)には、実は重要な情報が抜けている。
それは、Zachmanフレームワークの５W１Hに相等する情報、
もっと具体的には、
　ビジネス分析/仕様策定/システム分析/設計
のどの段階で、誰がどのように各モデルを使うべきなのか、という情報である。

それらの欠落した情報はUMLの外側で、方法論や開発プロセスの形で与えられる。
これが「UMLはソフトウェア分析/設計の表記の統一に過ぎない」といわれる理由である。

更に悪い事に、最上流に位置し、後続のシステム分析/設計への影響が大きい
「ビジネス分析」には各種多様な慣習や方法論が存在し、
その分野に対するUMLの表現力/影響力は、極めて弱い。

更にもっと大きな枠組みで、企業システムのライフサイクル全体(計画〜運用)を考えると、
UMLの手には余る。
そのような意味で現在、「エンタープライズ・アーキテクチャー(EA)」による
企業システム全体の包括的な管理が、注目を集めている。

管理っつうより統治かな

統治っつうより吐鬱かな

また下痢便がこびりついてるな

下痢便っつうよりケビン・ベーコンかな

＝＝＝＝＝＝＝＝＝
キチガイ警報発令中
＝＝＝＝＝＝＝＝＝

unk粘着さんは二時半スレにも居たような気がするけど
最近相手にされなくなってきたので出張してきたんか？

先生！！
そろそろオブジェクト指向の講義を始めてください。
>>2-707の様な素人の戯言はもう結構ですから。

だいたい、オブジェクト指向ってプログラムが巨大になるにつれて
必要になってきたって言われてるじゃない？

オブジェクト1つが、小さなアプリケーションプログラムだと考えれば良いんだよ。
コマンドラインから使うCUIアプリね。
こういうプログラムってコマンドラインに引数を書くだろ？
その中にはプログラムの動作を決めるオプションや、データとなるファイルパスがある。
ほら、オプションはメソッド、ファイルパスはメソッドに渡す引数だ。

ファイルパスの代わりに、他のプログラムの実行結果を渡すこともできる。
これはオブジェクトにオブジェクトを渡すことに似ているだろう。

アプリケーションはバージョンアップしても使い方を似せる（互換性をとる）のが大事。
いちいち使い方が変わったんじゃバージョンアップしても使いにくい。
ただし、内部は変えてもいい。使い方を変えなければね。
これもオブジェクトと一緒。

ポリモーフィズム。これはほら-hでヘルプが見られるとか、大抵のアプリがパイプに対応しているとかあるでしょ。

カプセル化は言わずもがなだよな。

継承はちょっと分かり難いか。
バージョンアップというよりは別バージョン、亜種を作るわけだけど‥‥‥。
フロントエンドになるアプリを作るってところか？
既存バージョンには不具合があるが、そっちを直したくない場合、
新しいアプリを作り、不具合の原因になるデータを取り除いてから
既存バージョンを呼び出すといったような。

というわけで、オブジェクト指向は小さなアプリケーションプログラム指向と考えれば
実際のプログラミングに活かしやすいと思うよ。　　　

>>709
それは一歩間違えると機能分割になるね。

＞ポリモーフィズム。これはほら-hでヘルプが見られるとか、
＞大抵のアプリがパイプに対応しているとかあるでしょ。

いまどきオブジェクト指向がわからないやついるの？ m９(＾Д＾)ﾌﾟｷﾞｬｰ

オブジェクト指向もいいけど
もうちょっと強烈な手法が欲しいな

>>713
コンピュータの計算の原理は半世紀変わってないので、
おのずと限界が。

>>710

オブジェクト指向は分割手法の1つだよ。
分割してまとめる。

機能分割はOODにおけるアンチパターン

リファクタリングにおける「メソッドの抽出」がオブジェクト指向の真髄。
知ってる人に訊く。知ってる人にやらせる。

>>716
機能で分けたらダメじゃん。
小さなアプリってことは機能でまとまっているということ。

オブジェクト指向って主に分析・設計のことだろ？
プログラミングのほうはオブジェクト指向設計をコーディングしやすくするってだけのことで。

＞ハッカ
判ってるのか判ってないのか判断に苦しむ

>>720
そんな判断に意味があるか？

＞オブジェクト1つが、小さなアプリケーションプログラムだと考えれば良いんだよ。
＞コマンドラインから使うCUIアプリね。

これってオブジェクト指向というより構造化分析や関数型プログラミングといったパラダイムに近いだろ。

>>720
明らかに判っていない。
>709の継承に関する薀蓄は嘘八百だし、「分割してまとめる」自体は
間違っていないにしても、オブジェクト指向においてはそれは機能単位では
ないってことも判ってない。

特に継承に関するゴタクなどから察するに、インターフェースの共通化という
本質を理解せずに、単に実装の共有だけが重要だと思っているようだ。
十年以上昔の理解だな。

>>696
おいウンコ、おまえは>>698-702を理解できたのか？

頭の悪そうな質問に対して、せっかく時間を割いて答えてやっても
感謝の意を表さないお前には、いい加減うんざりだ。
返事しろ

長文読みたくないから読み飛ばされたんぢゃない？

開き直るなキチガイ

キミだいじょうぶ？

＝＝＝＝＝＝＝＝＝＝＝
>>727バカレス炸裂中
＝＝＝＝＝＝＝＝＝＝＝

これはもうだめかもわからんね

>>725
図星です。

>>724
すまん。もっと短めにわかりやすく説明しろ。おねがいします。

こいつにこれ以上簡潔にする能力はないだろ
無理なこと言ってやるな可哀想だろ

おいおい、どこが簡潔なんだ、オブ中毒やろう

煽って解答引き出したいのは判るが、
>>731-732 が態度悪くて相手にするの面倒だな。
実際「認識論」の説明は>>698の一行だけ、
後の>>699-702は「認識の外部化」の例を説明しているだけだが。

何度か２ちゃんに書いた事だが、
オブジェクト指向の根源を認識論に置く話は、
・オブジェクトテクノロジー研究所(旧OMGジャパン)の鈴木純一氏が、
　雑誌ComputerTodayに連載していた記事
・オブジェクトデザイン研究所のオブジェクト哲学者こと河合昭男氏が、
　@ITで連載していた記事
　ttp://www.atmarkit.co.jp/farc/rensai/column/world10/world10.html
・(株)豆蔵の羽生田栄一氏が、
　@ITで連載していた記事
・OGISオブジェクト指向の広場や、SRA青木氏の著作の中にも、
　同様な記事があるかもしれない
と枚挙にいとまがないので、実際にそれらの記事に目を通す事を薦める。

・・・ところで俺が>>698に書いたのは、認識論から得られる世界観の話だな、
と河合先生の記事を読み直して反省・・・。
　実世界の事象の描写としての
　　　オブジェクトモデリング ＝認識論
　オブジェクト指向のクラス　＝概念
　オブジェクト指向設計　　　 ＝世界観の構築
という感じかな。いい加減な事を書くのはこの程度にして、もっと精進する事にする
　

プログラムは多かれ少なかれ物事の認識の仕方だと思う
構造化も手順の認識の投影だし

ハッカ飴の言う説明は間違ってるのは分かったが、CLIコマンドを例にする所に、無謀な男のロマンを感じた。

>733
面倒だ言いながら律儀に答えようとしてるおまえさんは暇人
挙げ句無関係なやつを罵倒してまで教えたがる超暇人

プルグラマのレベルってこんなもんなのね
まっ土日ゆっくり休めや

オブジェクト指向って、Windowsの実装から生まれた手法に後付けされた概念だろ。
それを概念とか認識論とかから入るから、訳分からなくなるんだよ。

C++でCの機能だけ使ってWindowsプログラムを作った後に、バージョンアップ繰り返してみ。
オブジェクト指向の必要性と泥臭さが分かるから。

まぁ、Windowsから発生したという噴飯もののジョークはスルーするとして。

　　> 概念とか認識論とかから入るから、訳分からなくなるんだよ

俺もそー思っていた時期がありました。現場しか見えていなかった頃は。
企業の情報システム戦略を裏方でサポートしたり、技術コンサルして人に教えていくなかで、
やっぱ本質は「認識論」と「世界観の表出」かなぁ〜、などという技術的結論を得て、
これからしばらくそっち方面の基盤技術をやるつもりです。

要するに「『認識論』だ『世界観の表出』だ」というのは、
あくまでオブジェクト指向の工学的本質を言っているのであって、
素人相手にそんな説明して通じるとは思っていません。

素人相手だったら、プログラムスキルを伸ばして頂きながら、
UMLのビュー、EAのビュー、オブジェクト抽出〜分析設計の洗練の仕方
など教えるのだろうな、やっぱ。(洗練という言葉は漸次改良主義的なニュアンスがあって好きくないけど)

「教える」という行為で金をとらなきゃいけなくなっちゃった人は、
その教える内容を、たいしたもんだと思わせる必要がある。
さらに概念をパッケージ化したほうがありがたがられるので、
〜論とか〜主義とかいう言い方を多用する傾向がある。
われわれ技術者はそこんとこに注意して真の現場で通用する
ノウハウを抽出していかなければならない。

はぁ？カネはとってないよ。
俺ってすごく気前のいいスーパーエリートだから。

つかさぁ、>>741って相変わらずプログラムの一つも書けないのに
プログラム技術板とプログラマー板に粘着してて、
まるで商店街を徘徊する浮浪者のように嫌われてる奴だろ？

いい加減就業しろって

＝＝＝＝＝＝＝＝＝＝＝
浮浪者徘徊中 (>>741)
＝＝＝＝＝＝＝＝＝＝＝

たいしたもんだと思わなくても、ノウハウをマスターし、その出自を辿ることをすれば
必ずその背景となる思想／理論を再発見する。と書いたら荒らしかな。
何が言いたいかというと、
表層だけの抽出に終始してしまえば理論を発展させうる立場には立てないのではないか。
だよ。・・・ああそんな事は求められていないのか

すばやい食いつき、ありがとう♪

魚影が濃いわけか

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
この釣師きどりのバカ、なんとかしる
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

>>741＝>>746＝情報システム板を何年も荒らし続けてるコテハン「出張３２」

99 名前： 非決定性名無しさん 投稿日： 2005/06/30(木) 18:40:50
　昔のログ見てたら自称プログラマーがプログラムの事で徹底的にやられてるログ発見
　http://tmp5.2ch.net/test/read.cgi/tubo/1117805574/
　-----
　803 名前： ◆Rb.XJ8VXow 投稿日：04/06/01 08:52
　>>797
　つまらんな。
　私の残していたネタを勝手に暴くんじゃねぇ！！！！！！

　ボケがぁ！
　遊べなくなるじゃんけ！！！

　806 名前： ◆Rb.XJ8VXow 投稿日：04/06/01 08:55
　ってことで、390君は、どうやら元々判ってたうえで嘘を吐き私を陥れようとし
　墓穴を掘りそうになったので「軌道修正」して逃げ出したと言う訳だ。

　愚かな奴決定だな（爆笑！
　-----
　>>803 で追い詰められすぎて口調が変わってるのが笑える
　その後806で相手を愚かな奴呼ばわりして体面保とうとしたけど、もう遅すぎですからー

100 名前： 非決定性名無しさん 投稿日： 2005/07/01(金) 20:59:04
　p84bedc.osaknt01.ap.so-net.ne.jp

101 名前： 非決定性名無しさん 投稿日： 2005/07/02(土) 21:23:08
　ついでに、運営板に沸いて出た時の負け虫ﾃﾞｭｱﾙ糞のリモホ。
　http://qb5.2ch.net/test/read.cgi/sec2chd/1115205599/
　154 名前：雑音 pd3fc89.osaknt01.ap.so-net.ne.jp　投稿日：2005/05/07(土) 01:07:48 ID:oW/NSQrd
　164 名前：雑音 p84bfc5.osaknt01.ap.so-net.ne.jp　投稿日：2005/05/07(土) 12:19:01 ID:MzCt9tXW

ｿﾈか　厨が好きそうだな

>739
マジそう思うのか？
プログラム辞めてコンサルに回った奴は、半年も経つと概念とか思想とか言い出すんだよな。
特にUML最高とか言い出す。テストもJunitすごいとか、開発方法もXp最高とか言い出す。
自分で使ったことはなくて、雑誌で読んだだけなのにな。
はきり言って昔かなり出来た奴でも半年でズレ出す。
もしコンサルやってる連中がいるなら、たとえ少しでもコーディングしておけ。
偽コンサルにこれ以上増えられると迷惑だからな。

まぁマネージメントやるからね、視野がおのずと変わってくるよ。
ついでに言うと次の仕事はバリバリ短期コーディングで伸るか反るかの仕事だったりする。。。

>738
正直言って・・・・

Windowsみたいの作ってバージョンアップなんて感じの仕事あったらやりたいですね。
到底そんなレベルでない単純な仕事しかしたことないっす。
Cで泥臭さ感じるのは、主に基本設計がダメだったからと感じたことが多いな。

作りこみのし易さとか保守性とかカスタマイズし易さとか実行速度が大事
オブジェクト指向言語が上記ポイントにかなっていると思えたプロジェクトは未だ未経験

一番簡単なのは、JAVAでも品質が良くて似たプロジェクトのものコピペ　
⇒カスタマイズで作成
これ最強

たいしたプロジェクトじゃないのにオブジェクト指向で
１から設計なんてするなら、Cの方がよっぽどイイ

というのが個人的な感想

Javaの場合はさぁ、
・エンタープライズ・システムのアーキテクチャをどうするか、
・そのために必要なフレームワークは何か？
ってな視点を持たないと面白くないと思うよ。

オブジェクト指向もできないPGに未来なし

オブジェクト指向はPGよりも、SEやPMこそ把握しておくべきものだとおもう。

俺はPGのほうが把握しておくべきだと思う
なんちゃってオブジェクト指向で組んでしまうと
泣きを見るのは自分だし

色んな所でこのレスがついてるけど
オブジェクト指向プログラムと
オブジェクト指向設計がほんとごっちゃになっとるな

オブジェクト指向は分析・設計に用いるもので、PGがやるのはSE・PMが用意した設計図をもとにコードに落とすだけだろ。
PGが理解していると思っているのはOOAやOODではなくてOOP。
よって、まともなSE・PMがいないところでは苦労するだろうな、と思いながら俺は風呂に入りますよ。

>759
コードに落とすだけの作業なんてあまりにも簡単すぎるような。
そこまで詳細の設計図をかけるなら、SEがPG兼務した方が効率が良い
と思われ。

まぁSEの大半は、コード・イメージ皆無で文書作成＆お絵かきするだけだが。
よって設計〜詳細設計の任務は大抵PGに任されるのであった。(除く：オフショア開発)

業務ﾏﾝｾ
プログラムﾏﾝｾ

駄目だよ、もまいら。

>>762
煽ってる暇あったらさっさと定職に就け

俺は分析設計と実装は切っても切り離せないと思ってる。
俺の中ではオブジェクト指向といえば
実装はおろか言語仕様まで含んでいる。

>>764
おおむね同意なんだが、粒度の違いは意識しとかないと
うまく分業できないので注意って感じかね。

>>764
>>765
そうなんだよね。　切っても切れないけど、切り分けないといけないんだよね。

>> PGが理解していると思っているのはOOAやOODではなくてOOP。
OOA,OODを理解せずにOOPはできないと思うが、

>>767
その通り。
だがVBプログラマがプログラムを知らずに開発してるように
ほとんどのプログラマはOOPでコーディングしてるだけ。
切ない現実。

759って本気でそう言ってるのか？
本気でそう言ってるエライ方がいたんだが、そいつはエライんで部下は何も言えなかったようだ。
俺が忠告してやろう。
SE→機能設計、詳細設計
PG→キーパンチャー
なんて言うCOBOL時代の開発手法は15年前に終わってるぞ。
今は、
SE→提案、機能設計、詳細設計、コーディング、テスト、保守
PG→詳細設計、コーディング、テスト
キーパンチャー→死滅
だからな。
759のせいで苦労した部下がいるはずだから、メシでもおごってやれ。

７５９はSI大手の社員ですから、そう思っているのですよ。
実装の現実は深夜にしかないので、日曜の９時前にお風呂に入る７５９には決して現実は見えないのです。
７５９が永遠に会社に在籍するためにがんばりましょう！

漏れは深夜に備えこれから風呂にはいりますよ。（さっき帰ってきた）

>>769
　つまりＳＥやＰＧにはOOAは不要だと。

OOPだけしか理解していない、というような状況はありえるだろうか。
OOPの中にすでにOOAとかOODの概念が内包されてるのではないだろうか。
ちがうか？オマイラ

X ほとんどのプログラマはOOPでコーディングしてるだけ。
○ほとんどのプログラマはOOPのつもりでコーディングしてるだけ。

>>773
OOPL 使ってりゃ OOP だと思ってるのまでいる始末。

>771
すまんがOOAって何？
文脈から見るとOOAってのはオブジェクト指向設計で、オブジェクト指向実装と分けているようだが。
他の誰かも言っていたが、言語仕様も設計も実装も含めて分かっていないとダメだ。
宗教として設計だけ切り出して崇めるのは構わないが、個人的にやっててくれよ。迷惑だから。

>すまんがOOAって何？
驚いた。

>>759の
＞ PGが理解していると思っている
この表現にヒントがありそう

スーパーマリオって、異常にジャンプ力あるよな

＞ OOPの中にすでにOOAとかOODの概念が内包されてるのではないだろうか。
そのとおりだが、上位概念OOADと下位概念OOPの違いってことだろう。
上位概念をものにできたら、概念設計ができるようになる。チームの中では白眉と呼ばれるかもしれない。
下位概念をものにするのはある意味必修。JAVAや.NETのようなもの。でも下位概念だけでは概念設計はできないのと同じ。

こんな感じかなぁ

分析(OOA)：現状で何が欲しいのかを調べる
上位設計：何を作る／作らない／後回しにするか。機能仕様とかＤＢやフレームワークの選択とか
設計(OOD)：どう作るか。クラス図作成とかデザインパターン適用とか
実装(OOP)：作る

アーキテクチャ設計(方式設計)：何をどう作るか/フレームワークの選択とか。

分析、設計、実装いずれもクラス図は必要やで

>>780
＞分析(OOA)：現状で何が欲しいのかを調べる
＞上位設計：何を作る／作らない／後回しにするか。
これは要求定義。

まあOOA/OODと、各メーカ由来の工程区分はまるっきり別体系だから、
同じ仕事に別の名前がついててもしゃーないつかよくある事だが。
OMGのSPEM技術メモの付録を見ると、各社の工程名対応表が載ってるくらいバラバラ。
ついでに名前が対応させられてるからって、進め方が一緒とは限んないっつうバベルの塔

独自の工程名、開発プロセスを客に仕込めば、客を囲い込めるつう考え方は、
いい加減、前世紀の遺物と化してほすぃわけだが

OOAって工程名なのか？
それなら分からなくても驚くほどじゃないだろう。>776
しかし要求定義と方式設計じゃ全然違うな。

ところでPGで、クラス図が必要な奴っているのか？
普通、画面設計書（画面なしならシーケンス図）とDB仕様書（またはIF仕様書）があれば作れるよな。

>>786
いや、>>775 が知らない事に驚いた。
オブジェクト指向 == OOP と思ってる奴、最近は多いのかねえ？？

> 要求定義と方式設計じゃ全然違うな。

違うねぇ。それが何か？

SA/SDの方式設計≒RUPのアーキテクチャ設計
仕事内容：(ビジネス要求を、情報システムとしてどう実現するか「外部仕様」みたいな形で決めた上で)
　　　　　　　それではシステム要求を具体的にどう実装するか、
　　　　　　　ミドル/フレームワークの未定部分からサンプルコードまで決める

　　　　　　　＋非機能的要求(速度、データ処理量、品質、生産性、セキュリティ要件等)
　　　　　　　　　の実現方法を決め、最終的に上記要求が満たされるように各種調整を行う
つのも重要な仕事だわさ。

そいえばIDGから雑誌「ITアーキテクト」出たね（藁

>>ところでPGで、クラス図が必要な奴っているのか？
おまいは大手SIのSEか、
偽装請負のOOPしてるつもりのPGだな。

結局OOP、OOA、OODの違いははっきりしていないのか？
おれはずっと>>780のイメージだったんだけど。

OOA=分析、OOD=設計、OOP=プログラム

>>オブジェクト指向 == OOP と思ってる奴、最近は多いのかねえ？？

「OOPはオブジェクト指向でない」と聞こえるのだが、違うよね。

OOPはOODやOOAとは異なる
もしOOP==オブジェクト指向であるならば、OODやOOAはオブジェクト指向でないことになる
よって、OOPはオブジェクト指向とは異なる

民明書房刊　『陰陽二進法演算機』より

>>792
無論、「オブジェクト指向 ⊇ OOP」のつもり。

OOP言いたいだけちゃうんかと

オブジェクト指向でもっとも適用が難しいのはプログラミング。
わかったつもりでもオブジェクト指向プログラミングは簡単にはできない。
そして誰もオブジェクト指向プログラミングかすら判断できない。

>>そうだろう、デスマの戦士たち。

とりあえず今日も巨人は負けてますが、どうよ？

いつものことだろ

OOPとOODは同じこと。
一般的に、使う言語やツールの違いで分けられているに過ぎない。

分析と設計を同じという奴に仕事を任せてはいけません

テンプレートってオブジェクト指向に含まれるん？

>>801
まったく無関係です。

>>801
テンプレートではなくインターフェースなら含まれると言っていいでしょう

オブジジェクトとは、データに対する階層的なインタフェースである。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　- 俺 -

オブジェクトはオブジェクトだ馬鹿

でもオブジェクト指向を知らなくても、VBみたいなツールがあればいいんじゃない？
GUIでオブジェクト配置して、プロパティー変更して完成！！みたいな。

くだらないことに頭を回す前にスペースとタブコードを混ぜた
インデントをやめていただけないか

設計しやすくするためのオブジェクト指向だ、難しいわけがない

VB並みに簡単だよ

はいはい、あんたの話はいつ聞いても笑えるね。面白い面白い。あーつまんね

オブジェクト指向ってプログラミング以外に使い道あんの？
オブジェクト指向型分析とか、
オブジェクト指向型生産管理とか、
オブジェクト指向型猫の飼い方とかあんの？

唯物論とはオブジェクト指向である。

そもそも、
全宇宙はオブジェクト指向である。
日常生活もオブジェクト指向である。
人間もオブジェクト指向である。
しかし、プログラミングでオブジェクト指向を取り入れられないのはなぜか？
それは、人間自身が当オブジェクト指向を理解できていないからだよ。
人間は、自分の脳が何をやっているか理解できていないのに似ているんだ。
今必死でオブジェクト指向を語っている>>1-811の人たちは、わかっているようで本質はまだ理解できていないんだ。パゲだよね、パゲ。

もうこのスレもおわりだな。しかしよく続いたよ
８００レスだぜ！８００！

OOについて語りたい香具師が多いってことだろう。
次スレはたつのか？

既出だったらすまないけど、前橋和弥（ポインタ本の人）のOOP論についてはどう思う？
俺はこの人のOOP論は倒錯してると思うんだけど。

どう倒錯してるかは気が向いたら書きたいと思うけど、簡単に言えば言語のOO化の
副産物に過ぎないものをOOPの主目的と取り違えている。

その倒錯は恐らく、「図解の技術」―― 分かり易い設計図の書き方に関する技術であるOOを、
要は人間の脳へのアプローチであるOOを、「工法」―― 地震に強いとか防音といった
新しい機能を実現するための技術、要はコンピュータへのアプローチと混同し
取り違えているところから来ていると思われる。

>>815
あんた相当ずれてまっせ。
ゴタクはプログラムできるようになってから言えって

脳内OO薀蓄っぽいな、>>815みたいな意味不明なのは。

>>816
ずれているとは？
何がずれているのか言えないのなら、それは批判ではなくたんにクダを巻いているだけだ。
批判は歓迎するがクダを巻くお子様に用はない。

オブジェクト指向できない人って、切羽詰ってて、カコワルイ

>>815
意味がわからん。初めて読む人にもわかるように書いてほすぃ

>>815
OOは、「『図解の技術』―― 分かり易い設計図の書き方に関する技術」
あるいは「人間の脳へのアプローチ」
では決してない。
もしそのように言う人が他に居るのであれば、リンクを示せ。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　いじょ

わかってて馬鹿の相手する馬鹿ほどどうしようもない生物はないな

追伸

OOが主要に使われる業務アプリケーションの世界では、
建築の耐震性や防音性に相当するもの
・・・例えば安全性、堅固さ、フェールセーフ、機密性・・・
は、「機能」ではなく「非機能特性」と呼ばれる。

つまりアンタは二重のバカ。ほら、そこで自作自演で涼しい顔してるアンタだよ

もって回った言い方をすれば、どんなバカな発言も受け入れてもらえると考えてる>>815が哀れ。
つかもっとくだけたしゃべりでえぇ〜やん、
ややこしい言い方はじめると、あんた中身に気が回らなくなるみたいだし。

オブジェクト指向は単なる指向。
技法でも手法でも方法でもない。
頭の片隅に「オブジェクト指向」
と置いておくことで少し幸せになれる、
その程度のもんだ。

「クラス図がシステムの静的な状態を表しており、
あとは機械的なコーディングだけである。」
そんなことありえねー

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
哀れな人が今日の粘着作業を開始しました。

つかせっかくの土曜日なんだし、
誰かと食事にでも行ったらどうなんだろうね？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

まぁせっかくネタ振った>>815が可哀想だし、
議論の方向を整理してみるか。

議題1. OOは「図解の技術」―― 分かり易い設計図の書き方に関する技術であるかどうか
議題2. OOは要するに人間の脳へのアプローチであるかどうか
議題3. OOは「工法」―― 地震に強いとか防音といった新しい機能を実現するための技術、
　　　　 要はコンピュータへのアプローチではないのかどうか

回答1. OOの分析設計手法のノーテーション部分(記法：例えばUML)だけ見れば、
　　　　　確かに「図解の技術」を含んでいる。
　　　　　それは建築、造船、音楽、等、リアル対象の思考検討でノーテーション(記法)
　　　　　が重要な位置を占める分野ではどこでもそう。
　　　　　そして上記の分野全てにおいて、記法は全てではない。
　　　　　これは文字表現だけで成り立つ文学とは決定的に異なる。
　　　　　更にいうと例え文学であっても、記述内容と作者と読者という、
　　　　　現実の世界の関係性の中にしか、その拠り所となるものはない。

回答2. 脳内で認識し思考した結果を、現実世界に実現する作業を
　　　　 　「脳へのアプローチ」と呼ぶならば、そうかもね。
　　　　　その意味では建築も造船もスポーツ(特にルール性が高かったりベテランの模倣が重要なもの)
　　　　　もそうだけど
回答3. OOがコンピュータとは無関係に存在しうる体系だ、という主張をする人を初めて見た。
　　　　　よく居るんだよね、耳年増だけどリアル体験が無い奴って、
　　　　　リアルの体験を妄想でシミュレーションして議論しだすから、童貞くんだって一発で判る。

議題2は要するにモデリングにおける概念抽出だけにスコープを限定して、
素人なりになんとか解釈しようとして出てきた結論なんだろうな。

「概念を洗い出したり、概念について考える作業」＝「認識論」＝「脳へのアプローチ」
とか勝手に結びつける短絡思考回路が、脳内のニューロンレベルでできちゃってるとか。めでてぇーな。　

あと、あんた勝手にスコープ限定してますから、スコープ限定の話をスコープの外側には適用できませんから。
残念
　

OOに限定せず、プログラム言語、開発方法、ひいては情報システム全般について、
下記のような関数モデルを想定する事ができるだろう。

　入力：　「人手や旧システムで実際に行われている処理」　＋　「処理方法に関する理論」
　出力：　「情報システム上の処理(ハード、ソフト、運用方法等含む)」
　処理：　人間が扱いやすいやり方で、上記の入力から出力へのマッピングをする

OOは、上記「処理」部分のやり方の一つである。

>>827
全然論旨を理解してもらえていない。
まあ、俺の文章の稚拙さ、舌足らずさは大いに認めますが。
俺の論旨は、

■ ソフトウェア工学の技術は、ある視点から２つに大別できる。

■ 一つは、コンピュータであることを実現するための方法論。
　　もう一つは、プログラムを作成するときに障害になる、人間の能力の限界を
　　乗り越えるための方法論。

■ 前者は説明は不要だろう。後者は、例えば変数という「仕掛け」はどうだろう。
人間が十分に有能であれば、変数名は全部a000, a001, a002, ……でいいはずだ。
いや、そもそもプログラム言語なんて必要ないだろう。直接バイナリコードを記述すれば.......
だが、現実にそれで不自由しない、という人間はまずいないはずだ。

■ この分類では、OOPは後者に属する、少なくとも後者寄りの技術だと私は思う。

■ 前橋和弥のOOPの議論に感じる倒錯は、OOPに前者の技術であることを
　　暗黙的・無自覚的に期待していることからくるものではないか。

追伸
OOがコンピュータとは無関係に存在しうる体系だ、なんて主張をしたつもりも
するつもりも全くありませんから。

ああそう。おつかれだね。
あんたの区分が、現実世界できっちり区別できるものだとは思わないし、
ましてやあんたが思ってる内容はOOだけじゃなくプログラム言語にも当てはまる内容だから、
別にこのスレで必死に主張する必要は無いと思う。
実際現在多くの人が、オブジェクト指向なしでプログラムするなんて考えられないと思ってる。
その一方で、ソフトウェアやアセンブラより下側の、例えばハードウェア設計の世界を考えると、
確かにその上にもプログラム言語みたいな環境があるが、そんなに普及しているとは言えないだろう。(PLD,FPGAは除いて)

>>830見ると必死に箇条書きしてるんだけど、
結局、仮定と論理的飛躍と思い込みしか書いていない、
可哀想な人の文章だと思った。

・・・なんつかさ、あんたが勝手に判断した内容を、断定口調で書かれてもねぇ。
「ああ、あんたの思い込みは違うよ」としか言いようが無い

>>832
いやさ、この人は「自分は主観的に素晴らしい事を言っているのに周りが理解してくれない」
という妄想を持っているだけだと思う。

まず、>>815と>>830で書いている事が変わっている。
そしてその変化は、実は>>827でもたらされた変化だ。
俺が>>827を書いた時には、きっと>>815の脳内論理はこうだろう、と思いやり、推定して、
説明をかいてやった。
ところがやっこさんは、自分がちゃんと説明していないのに、
なんか>>827と>>815〜>>830に食い違いを感じて
　「全然論旨を理解してもらえていない。」
とかのたまっちゃう・・・

・・・単に、人とかみあった会話をして、議論を進める能力に問題がある、痛い奴だと俺は思った

>>833
>単に、人とかみあった会話をして、議論を進める能力に問題がある、痛い奴だと俺は思った
言いたくないけどこういわざるをえないね。
オマエガナー。

>>832 仮定と論理的飛躍と思い込みしか書いていない

あと付け加えるならば、
・仮定の証明
・「思い込み」を相手に共感させる努力
・論理的飛躍を埋める努力
が必要だと思う。

もし「そんなややこしい説明をする義務などない」とか言い出したら、
こいつはキ印扱いで放置しようと思う

>>834
じゃ放置って事で。もうお前はこのスレに書き込まなくていいよ

>>831は何を言いたいのだろう。
なにか、私の文章がOOPを否定するものであるかのように
>831は受け取ったように読めるが、いったい私の文章のどこにOOPを否定するような
くだりがあるというのだろう。

なんとなく「しんちゃん」と呼ばれているをさーんを思い出した

>>836
なんと幼稚臭い物言いだろう。
別に君に頼まれて書いているわけでなく、自分の意志で、自分が書きたいと思うから
書いているのだが。

>>832
こういう文章を書く人物に論理だてて物事を語る能力があるとはとても思えないが
あえて一応たずねておこう。

論理的飛躍とは、具体的にどの部分でしょうか？

>>838
しんちゃんも>>815も同じ。
こっちは口は悪いが相手の言っている事を理解しようと努力してるんだが、
こいつらは、自分が理解できないレスは聞き返す事もなしに全部無視、
議論の要点がつかめなくなると、「お前は自己主張が強い」とか言い出す。
しまいには「オマエガナー」。

どうせこいつら酒かっくらって議論うやむやにするクズみたいな人生送っているから、
議論で問題解決しようとするのは無駄骨もいいところだと思う。
リアルにこんなのが来たら「ああ、お疲れですね。いろいろ溜まってるみたいですし、今夜一杯いかがです？」
とお誘いでもかけるが

あぁあ。博士課程でてサイエンスやってる俺が、
なんでこんなバカの相手してるんだろう（呆

>>835でもいい。
「仮定の証明」というが、証明を要するような非自明的な仮定とはいったい
何を指しているんでしょうか？

そして論理の飛躍とは？

オブジェクト指向のお勧め本
　翔泳社：オブジェクト指向開発講座　です。

　ただ、実際にはＭＶＣ（Module View Control）に基づいた
VB.NET の開発で取得しました。
　もう２度と、VB6以前とVB.NETを同じ見積もりはいたしません！！
（プロジェクト　大ハマリ）

>>841
うやむやねえ。。
私の目には、議論をうやむやにしようとしているのは君の方に思えるが。
もし本当に議論をうやむやにするのがけしからんと思うのなら、
「人格攻撃」ではなく「問題」について語ったらどう？

いや、できないなら無理することないですよ。

>>841
そーいえばあんた、会社辞める前日にしんちゃんと一日かけて議論してたな。
傍で見てていかにもダメSEの、自己主張だけ強くて筋の通らない議論に
延々付きあってるあんたは、傍で見てて痛々しかった。
あーゆー手合いは「相手したら負け」というのが実務的判断だと思う。

ええーと、相変わらずバカが「反論するなら説明せい」と必死になっているわけだが。
>>815, >>830に関する説明義務はアンタにあるんだよ。
俺はアンタの妄想は、正すべきだとは思うが、別にこっちは義務背負ってるわけじゃーない。
バカの相手しても損するだけだから。

表面的な挑発にいちいち乗って、感情高ぶらせて胸どきどきさせてるのは、
あまり頭のよくない行為だ。
例えば>>835がとても親切な指摘をしてくれている。そのあたり、きちんと対応してみてはいかがか

>>847
対応してると思いますが。
だから、説明を要するような非自明的な仮定とはなんですかと聞いている。

いや、君でもいい。
「妄想」とは具体的に私のどの主張でしょうか？

まぁできるだけ公平なものの言い方をすれば、

>>830は「アナタ」という個人がその経験に基づいて
帰納的に導きだした、経験則、仮説、信念に類するものであって、
そのあなたの内部的な経験則が、我々の共有する現実世界の事象とどのように対応しているか、
そして対応関係を皆が理解した上で、はたしてその経験則は客観的に正しいか、
という説明が必要だと思う。そして、>>830にはそれらの説明が一切ない。
これが第三者には「論理的飛躍」に見える。

もし>>830が経験に裏付けられた信念であるならば、
その信念を、第三者にも判る客観的な形で説明してはどうだろう？

そこの説明を避け、反論にも感情的に対応するのであれば、
あんたは単に議論がしたいだけの寂しい構ってクンだ。

>>849　単に議論がしたいだけの寂しい構ってクンだ。

いや、構ってクンなんていう生易しいもんじゃなくて、
荒唐無稽な説を主張し、誰かに反論してもらう事を通じて、自己成長を行う
痛い人だと思う。

俺の学生時代にもそんなんが居た。
ネットニュースとMLに没頭し、あちこちで議論を吹っかけ、
普段は存在感がないのに、とつぜん自信たっぷりに怪しげな説を主張し始める・・・
・・・忍者ハッタリくんって呼ばれてたな、そいつ。
修論の時には随分苦労させられたよ、アイツには

>>849
説明を避けてなんかいないと思いますが。
だから私の語っている中で、説明を要するような、非自明的な、単なる経験則とは
どの部分ですかと聞いている。

そういうのだから、当然異論があるということでしょう。
しかし私はエスパーじゃないので、他人が私の見解についてどのような異論を持っているかは
当然ですがわかりませんよ。
わからないものについては答えようがないじゃないですか。

単に議論がしたいだけの寂しい構ってくんどうのはそのとおりだから別に構わない。
だが、だったらなんだというんだろうか。

>>849
正解だったようだね。

仮説・信念と、共通認識の差を理解できないとは。
学問的訓練が足りないんとちゃうか

>>851
おまえさ、自分で論文とかレポートとか、書いた事ある？
このさい、理系とか文系とか一切関係なしで。

>>852
意味がわからない。
根本的に知能が低い人物に何をいっても無駄だろうが、
だから非自明的な仮定とは何かと聞いてる。

お前の仮定は共通認識（？妙な言葉だ）でない、というのだから当然異論があるわけで、
だったらその異論を述べればいいと思うのだが。

ま、人格攻撃しかできないのはこの種の人物の常。

まず815は、>>815および>>830の主張は、
あなた固有の主張であって、そのような共通認識はなされていない、
という事を理解する必要がある。

次に815は、自分の説に関心を持ってもらい、かつ、自分の説に対して理解を深めてもらうために、
　>>821
　>>823
　>>827
　>>828
　>>829
という意見に対して、きちんと回答する必要がある。
そこを怠ったまま「全然論旨を理解してもらえていない。」などと子供じみた我侭を言い出すから、
バカ扱いされる。

そして815は、何故「前橋和弥」というあまり有名ではない著作者に対して
執念を燃やし続けるのか、合理的かつ気持ちのいい説明をする必要がある。
正直言って、議論の原点にとても気持ちの悪いものが燻っているので、
この議論に健全な関心を持つ人間はあまり居ないと個人的に感じる。

最後に、この議論がダメなのは、
「815の主張」「815が認識したと称する前橋某の主張」を対比している所だ。
「前橋某の著作」にインスパイアされて「815の主張」が発生しました、
という「前橋某」へのレスペクト、謝辞が必要だと思う。
そこの所を勘違いして、批評家みたいに上からピント外れな批評をするから、
あんたの議論はとてつもなく気持ち悪い

盛り上がってまいりました

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
言うまでも無い事ですが、
>>815は前橋某を叩き、
次にこのスレの住人を叩きまくっている
「今週の痛い人」で〜す。

知能に劣等感を持つ人間を相手に、
かみ合った議論、より良い議論を展開するには
どうしたら良いか、このスレが良い事例となるよう
生暖かい目でヲチしませう（笑
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

>>849
やっぱ大正解。つかこのバカ「出張３２」でしょ。
このグダグダな展開、これまで何百回も見てきたんで、

　も　う　飽　き　た　

　　　　　　>>815は、論文もレポートも書いた事のない低学歴と判明

　　　　　　つか普通、中学や高校でもレポート書かされるよな。

　　　　　　理科実験とか校外実習とか読書感想文とか。

　　　　　　こいつ中高時代ナニやってたんだ？ヒキー？

愚問を・・

>>855
私は別にアンチ前橋じゃありませんが。
むしろアンチ○○なんていう下らない存在様式には一切興味がない。
別に前橋なる人格にケチをつけているのではなく、前橋のなしたOOPの議論には
倒錯しているところがあるのじゃないかと思っているだけ。
ポインタ本についてはリスペクトしてますし。
意見と人格の区別がつかない君自身を私に投影しすぎじゃないの。

＞〜という意見に対して、きちんと回答する必要がある。
なんか「為にする議論」、ようするにイチャモン付けの匂いがしないでもないが。
>>823なんて答える必要があるとは絶対に思えないが。。

>>821は私の>>815の書き方がまずかったせいで言いたいことがうまく
伝わらなかったようだから申し訳ないとしか言いようがない。

まあ>>823にも一応答えておくと、これは単に>>823の頭が悪いだけ。
高校一年の数�Tを勉強しなおせといいたい。
『「機能」ではなく「非機能特性」』といっているが、機能⊃非機能特性でしょ。
要はリンゴは果物だから植物じゃないって言ってるのと同じで馬鹿丸出し。

>>827 >>828 >>829 はこんなの何答えればいいの？

＞「全然論旨を理解してもらえていない。」などと子供じみた我侭を言い出すから、
意味わかりませんが。>>815が理解されないのは無理もないと>>830にも書いてるでしょ。

仮説１　　　■ ソフトウェア工学の技術は、ある視点から２つに大別できる。
　　　　　　　■ 一つは、コンピュータであることを実現するための方法論。
　　　　　　　　　もう一つは、プログラムを作成するときに障害になる、人間の能力の限界を
　　　　　　　　　乗り越えるための方法論。

飛躍１　　　■ 前者は説明は不要だろう。
事例説明１ ・後者は、例えば変数という「仕掛け」はどうだろう。
　　　　　　　　 人間が十分に有能であれば、変数名は全部a000, a001, a002, ……でいいはずだ。
飛躍２　　　 ・いや、そもそもプログラム言語なんて必要ないだろう。直接バイナリコードを記述すれば.......
仮説２　　　 ・だが、現実にそれで不自由しない、という人間はまずいないはずだ。

信念１　　　■ この分類では、OOPは後者に属する、少なくとも後者寄りの技術だと私は思う。

仮説３(信念２)
　　　　　　　■ 前橋和弥のOOPの議論に感じる倒錯は、OOPに前者の技術であることを
　　　　　　　　　暗黙的・無自覚的に期待していることからくるものではないか。


【補足】
・仮説１は、この業界の共通認識とは異なる。
・飛躍１は、仮説１の正しさに関する説明を怠っている箇所。
・飛躍２は、プログラム言語が仮説１のどちらに大別されるかきちんと示していないため、意味が曖昧。
・仮説２は、飛躍２を前提とした仮説なので、意味が不明。
・信念１は、仮説１を前提とした信念表明なので、説得力がない。
・仮説３(信念２)は、この文章の結論であるはずなのだが、
　２つの仮説、２つの飛躍、１つの信念の上に立った仮説に過ぎない。
　そして上記２つの仮説の正しさを説明していないため、これはもはや信念表明にしか見えない。

つかさ、ソフィスト>>815さんよ、
仕事で言語解析やってるプロを、なめんなよ。

>>862　機能⊃非機能

なんだ、単なるバカの寝言か。

おまいらめちゃくちゃ親切だな。感動した。

でもこんな板で質問する程度な香具師は結局何にも活かせないだろうし
実戦で活かせるかと言われれば疑問符が付くな

うむ。いっぱいスレたってるけど、いずれもクソの足しにもならん。
ただ時間だけが浪費されていくだけ。まあ、こんなとこでまともな見解を
探そうなんて思ってるヤツいないだろうから、結局ここも便所の落書きだわな。

>>864
ｸｿ本書くなよ。

>>863
なんかこういう中学生みたいな恥ずかしいことがよく書けるよなあ。。
まあ、どの変が「恥ずかしい」か、例をあげれば.........

＞飛躍２　　　 ・いや、そもそもプログラム言語なんて必要ないだろう。直接バイナリコードを記述すれば.......
＞仮説２　　　 ・だが、現実にそれで不自由しない、という人間はまずいないはずだ。

この仮説とか飛躍とか信念とかいうラベルの区別は何なの？と突っ込みたくなるがまあそれは置いておくことにする。

>>863は、（彼のいう）仮説2は（彼のいう）飛躍2を前提としており、飛躍2は意味があいまいなんだと言う。
しかし、飛躍2 = 「人間が十分に有能であれば、明示的な変数名もプログラミング言語も必要ないはずだ」
という内容のどこがあいまいだというのだろうか。
本気で書いているとすれば、それは単に>>863の言語能力の問題といわざるをえない。

>>863は、（彼のいう）仮説2は前述の理由で意味不明だという。
（彼のいう）仮説２ = 「明示的な変数名もプログラミング言語も必要としないほど有能な人間はいない」
これを意味不明だとのたまう彼に、理解可能な文章ってどんな文章だろう。

>>864
そういう「虚勢」を普通の人間は意味論的に
『ああ彼は臆病だから虚勢を張っているのだな』と受け取って舐めるんだと思うけど（笑）

まあ、私は虚勢を張るような種類の人物に一切興味はない。
捨てハンつけてくれれば以降無視できるのに。

>>871
>捨てハンつけてくれれば以降無視できるのに。
m9(｀・ω・´)ｿﾚﾀﾞ!

ああ、肝心なことを書き忘れた。
>>863は、

■ 前橋和弥のOOPの議論に感じる倒錯は、OOPに前者の技術であることを
　　暗黙的・無自覚的に期待していることからくるものではないか。

これが、
＞２つの仮説、２つの飛躍、１つの信念の上に立った仮説に過ぎない。
こう言うのだが、大丈夫だろうかこの人？

この仮説が成立（実証ではない、単に仮説が仮説として成立するということ）するか
どうかが依存しているものといえば、

　　(1) 私のいうコンピュータ工学の技術の２分類が分類として妥当であるかどうか。

　　(2) 前橋和弥のOOP議論が倒錯しているかどうか。

この2つであって、彼のいうようなものではない。

まあそもそも、「仮説に過ぎない」という物言いに頭の悪さが伺われる。
「仮説に過ぎない」言説以外の言説がこの世に存在するとでも思っているのだろうか。

相変わらず必死だなぁ。
おまえ何歳？
学歴どうよ？
いまの収入は？
で、お前がなんか勝手に持論展開して、
それ皆が付いてくと思ってる？

もっと謙虚になれ。
それがオブジェクト指向極めて、もう次の分野始めてる俺から送る言葉だ。
アディオス

なんだ、>>873は「俺が言っているのは>>863とは違う」と言うワリに、
結局言ってる事は同じじゃん。

なんていうか、人の議論パクるだけの超賎人かよお前

>>873(1)(＝>>863 仮説１)： 妥当ではない
>>873(2)(＝>>863 仮説３)： 妥当でない仮説(1)に依存した仮説なので、判定のしようがない。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　いじょ

まぁ相変わらずこのスレには、
何故か超必死な>>815と、
クールでクレーバな漏れ様の二人しか居ないわけだが（藁

ちゃんと人と会話できるようになれよ、>>815

残念ながら端から見ると池沼二人がわめいてるだけ

はいはい、あんたのレス面白いよー。最高。超受ける。

満足したら、さっさと壺に糞を詰める作業に戻るんだ

>>877 がいい事言った。まったくそのとおり！
オブジェクト指向とか以前の問題だな...

なんだ、議論で徹底的に論破されると、
議論を丸ごとゴミ箱に捨てるのか。
負けず嫌いのジジイの将棋や囲碁と一緒だな。

>>841
> どうせこいつら酒かっくらって議論うやむやにするクズみたいな人生送っているから、
> 議論で問題解決しようとするのは無駄骨もいいところだと思う。

正解だったね

>>723
> 特に継承に関するゴタクなどから察するに、インターフェースの共通化という
> 本質を理解せずに、単に実装の共有だけが重要だと思っているようだ。
> 十年以上昔の理解だな。

その部分にもちゃんと触れているのに。
頭固くない？

以上という概念とメリットと具体的使用例を教えてくれませんか？

以上　×
委譲　です

>>735
> ハッカ飴の言う説明は間違ってるのは分かったが、CLIコマンドを例にする所に、無謀な男のロマンを感じた。

オブジェクト指向を何かとてつもなく崇高な思想のように思ってないか？
これまでのプログラミングの延長上にあるものだろ。
あと、CLIじゃねぇよ。ユーザーインターフェイスの話なんだから。

>>738
> オブジェクト指向って、Windowsの実装から生まれた手法に後付けされた概念だろ。
> それを概念とか認識論とかから入るから、訳分からなくなるんだよ。

俺はこの考えを支持するな。
ここにはオブジェクト指向を哲学のテーマのように思っている奴がいるが。

>>885
オブジェクト指向を感覚で理解できてないんじゃね？

>>739
> まぁ、Windowsから発生したという噴飯もののジョークはスルーするとして。
> 　　> 概念とか認識論とかから入るから、訳分からなくなるんだよ
> 俺もそー思っていた時期がありました。現場しか見えていなかった頃は。
> 企業の情報システム戦略を裏方でサポートしたり、技術コンサルして人に教えていくなかで、
> やっぱ本質は「認識論」と「世界観の表出」かなぁ〜、などという技術的結論を得て、
> これからしばらくそっち方面の基盤技術をやるつもりです。

それ技術じゃねぇよ。

違う概念を違う概念として受け入れられずに
既存の概念を通してしか見れてないんじゃね？
なんか年寄り臭い

つーか、「教えろや」と言っている奴に、書き込み1件に収まらないほどの薀蓄を押し付けるのはどうよ？
現実的に行こうぜ。

>>888
> 違う概念を違う概念として受け入れられずに
> 既存の概念を通してしか見れてないんじゃね？

要はそこじゃなくて、そういう見方が間違っているかどうかだな。

継承てのは性質を受け継ぐこと
その上で大きな視点で見て共通の物（基本クラス）を
一括して処理できるようにしたり
一歩進んでオブジェクトに合った処理を出来るようにしたのが
ポリモーフィズム

だいたいCUIアプリ云々の例えじゃ
間違ってるかどうか以前に誰もわからないかと

委譲を教えろ。今すぐ
もたもたすんな

委譲てなんだっけ

大手が下請けに丸投げすること？

class Foo {
Bar bar;
Foo(Bar bar) {
this.bar = bar;
}
void doIt() {
bar.doIt();
}
}

>>882
委譲は利用したいオブジェクトに全く手を加えずに利用する。
例はそこいらにあるんじゃね？

>>885
> >>738
> > オブジェクト指向って、Windowsの実装から生まれた手法に後付けされた概念だろ。
> 俺はこの考えを支持するな。
もう帰ってくれ。

>>896
詳しく

委譲なんて機能があるのか！やつぱりＣはすげぇなぁ
オーバーロードじゃなくて？

>>898
>>895に例が出てる
>>894がメリット

下請けにまるなげしてしまえば、実装する手間もはぶけるし
信頼できる下請けなら成果物は安心して使える。
気に入らなくなったら別の会社にきりかえることができる。
継承は社内に新部署つくる感じだ。
上の本部がよけいな口出ししてくるかもしんない。
新部署を作ってしまい、
後悔して雇ってしまった人を解雇したり
組織変更するのは大変な負荷になる。
推してはかるべし
ネタではありません。

>>900
わかったことにしておく。そして900ゲットおめでとう

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
スレは伸びてますが、内容の進化はありません。残念
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

オブジェクト指向ができないPGじゃ食えないねｗ

>903
そうだな。
おまえがいい例だ。
今日はビル掃除のバイトか？

904って仕事してなさそう・・・。

＞９０５のむなしい反撃にﾜﾛｽ

今日祝日だってことに気づかず、朝ダッシュで駅まで走っていった俺がいました。

オブジェクト指向ができないPGじゃ食えないねｗ

むりしなくていいんじゃね？

いまゆきのじょおうみてます

>>909
いいよね。
結局だれもわかってないみたいだしね。
のんびり逝こうよ
きっと全てうまく逝くよ

次スレの名前は、「誰かが必死でオブジェクト指向を説明するスレ」でいいですか？

そもそもわかるわからないとかいう難しいもんでもないと思うが。

>>913
堂々巡りｷﾀｰ

次スレのタイトルは、
「オブジェクト指向について」
で十分盛り上がれる希ガス

わかったからオブジェクト指向をUMLで表現してみろよ。
まずはオブジェクトは何ぞやから。
話はそれからだ。

>>900
なんかわかりやすくていいな。

>>907
今日の朝、祝日だと気づいて歓喜してジャンプまで読んじゃった俺は勝ち組。ってか君激しくﾜﾛｽ

今気づいたんだが、JavaとかC++って、OOPとかいわれるじゃない？
でも、無理にOOしなくてもプログラム組んでいいんだね。
俺みたいな初心者でも無理やり構造化してやりましたよ、大佐!!

>>918
構造化とOOPは相反する概念じゃない。十分に両立が可能

クラス1つだけ。
あとはスタティックメソッドの塊ってのも
立派なJavaのコードだ。

# 笑い事ではなく実際にそういうコードに出くわしたことがある。

>>920
えぇ〜っとね。
初期のi-appliのコードはそんな感じだよ。
10KB制限の内側でクラスを三つも四つも定義すると、
クラス情報だけでパンパンになってコードがロクに書けない。

結果として、i-appliを継承したクラスと、GUI表示用のPanelクラス継承したクラスだけ作って、
あとはひたすらBASICみたくシコシココード埋めるっつう感じ。

この問題を解決するために、最初はプリプロセッサを探したんだけど(eppかな？)、
実はその作者の人がAOP使ってクラスとは別のやり方でアプリケーションを機能モジュール合成で作る、
という研究結果と実装系を出していた。。。それが日本発AOPとして有名なMJ (MixJuice)。

というような発展的な問題解決を視野に入れておく事は、
力任せで低レベルな土方仕事になりがちなこの業界を良い方向に導く上で、
とても重要なことだとおもふ。

遅レスすまぬが、

>>815
あんた「脳」とか安易に言い出すから、叩かれまくってるのとちゃうか？

そもそも「脳」の働きを解明する研究で、科学の基本である「実証」が充分行える状況にはまだまだ到達していない。
世の中には「脳」を表題に入れた大衆書、疑似科学書、ビジネス書が溢れかえっているが、
その多くは、「脳」って名前のついた学問分野の人が、間接的な測定手段や推測でモデルを立てて説明し、
あるいはそのモデル説明を鵜呑みにして応用が可能であるかのような妄想を書いているだけなんだ。

こーゆー悲惨な状況は20年近く前から想像できたんで、
俺自身「脳科学」本体ではなく「脳の物理的計測手段」を学生時代の研究テーマにしたくらいだ。

あと物理的計測手段では到底扱い難いのだが、人間の思考や概念など脳の周辺で科学的に扱いたいテーマもいろいろある。
そういったテーマは、いきなり脳とか言い出さず、まずは脳の外側に出てきたものを科学的に扱うべきなんだ。
だって、生きている脳が高度な知的作業を行っている時に、脳の内側で何が起こっているのか、
計測する手段はほとんど無いのだから。(補足：血流とか、ヘモグロビン濃度とか、化学物質移動を、マクロに観測するのがせいぜい。)

ってなわけで、計測手段や実証方法に関して無責任なまま
「脳へのアプローチ」などというハッタリめいた言葉を吐かれると、
同じ業界人としてとても哀しいし、脳研究の入り口に少しでも関わった人間として、すごく迷惑なんだ。

そこのところ、理解した上で自重してくれ。

＞「脳へのアプローチ」などというハッタリめいた言葉を吐かれると、
悪いけどそれは君の読書経験が ―― 読解力が足りないからだよ。
>>830では一応へりくだって「俺の文章が舌足らずだった」と書いたけれどもね。

こんなところで俺の拙い文章の「読書会」をしてもしょうがないけど、
>>815では二つに分類した技術のそれぞれにつき３通りの別の表現をしてるでしょ。
これは単独でそれを表現できる適切な言い回しがないからそうしてるに決まっている。
ベタに読んでもらっては困るぜよ、ってね。

それを片言節句を捕らえて、「脳へのアプローチ」って言葉にだけ短絡的に反応するのは
あまりに単細胞といわざるをえない。はっきり言えば幼児的。

まあ、理科系の人間って読書とか嫌いだから理科系に進んだって人間も多いんで（俺自身が
そうだし）、ああいう文芸的な表現をしたのは迂闊だったとは思うけど。
俺自身も本当は人に偉そうに言えるほど読書経験なんてないし。

まあそれでも、>>815は中学三年生レベルの読解力で文意が読み取れる文章だとは思うけどね

突然ですがスレの流れを完全に無視しつつ
オブジェクト指向講座です。

あなたはプログラマ、オブジェクト指向ってなんだろうと思っているプログラマ。
ゲームのＲＰＧのキャラクターのお金管理を作るのが現在の仕事です。
ゲームに興味のない人は銀行の入金管理の話だとみなしてください。

さて、あなたが作らねばならないものの仕様は

主人公キャラクターはモンスターを倒すと100円ゲットできます。
ただし上限である1000円を超えてはなりません。

というものです。
あなたは小一時間頭をひねってさっそく実装しはじめました。

if (モンスター倒した){
　　　　所持金 += 100

　　　　if 所持金 > 1000
　　　　　　　　所持金 = 1000 //いくらかせいでも1000円までよ
　　　　}
}

こんな感じです。
よかった完成。いい仕事したぜ俺。
あなたは得意満面・・・（つづく）

続・オブジェクト指向講座

しかしふと気づくとあなたの後ろに意地悪上司がたっています。
ネチネチとどうでもいいことで小一時間いじめられました。
しかも仕様追加を命じられました。
どうやら宝くじとやらを実装したので、
当たったときの入金管理を追加せねばなりません。
当たると200円げっとできるそうです。

動揺をかくしきれないまま
あなたは宝くじ当たりの実装にはいりましたが、
うっかり上限を忘れて

if (宝くじ当たっちゃったひゃっほーい){
　　　　所持金 += 200
}

などと書いてしまいました。とほほ・・（つづく）

続続・オブジェクト指向（完結編）

さてあなたは所持金の上限処理部分（同じ内容だ）を再度
宝くじ処理に書けばいいのでしょうか。
でもこのあと意地悪上司が
所持金まわりの追加仕様（多分わざと小出しにしてる）を
またもってくることも考えられます。
それなら入金部分を関数化してやればいいでしょう。

しかしながら、その関数を使いわすれてしまうこともあるかも。
おなじみデスマーチで徹夜状態になったあなたは関数の存在すら忘れ、
上限も忘れて

所持金+=200//もう寝かせて

などと書いてしまうかもしれない。
そこでオブジェクト指向です（おしまい）

そこで止めるのかよ

>>918
>JavaとかC++って、OOPとかいわれるじゃない？
言われません。
Java が OOPL と呼ばれる事はありますが。

俺も遅レスですが…

>>815さんに提案なんですが、>>830であなたは、
「前橋和弥のOOPの議論に感じる倒錯は…」と書いてますが、
↑実際に、あなた自身が倒錯を感じた、
前橋氏本人が書いてる文（←あなたの読まれた書籍？HP？）
の一部を引用して、ここにコピペ、または書いてみたらどうです？

その方が、前橋氏の書籍やHPを読んでいようがいまいが関係なく、
より具体的に>>815さんが何を言いたいのか分かりやすくなると思いますよ。

前橋氏の主張している要点だけでも良いんで…

「これこれこういう風に書かれている部分があったんだけど、
俺はそれに関して、これこれこういう風に考えたんだよね。
だから>>830のようなことを書いたんだ」

…みたいな対比をすると、かなり分かりやすいと思います。

そうすれば（さらに突っ込まれる可能性もありますが…）
議論が噛み合ってない場所を、お互い客観的に検証しやすく
なると思うんですけど、どうですかね？


>>926
続編を、ぷりーずｗ

>>929
それは徐々にそうしていく予定だったんですがね。。
話の「つかみ」に乗っかってくれる人がいれば。
唐突にある程度ボリュームのある議論ふっかけてもウザかろうと思ったので。

ちなみに、まあ周知のことと思いますが俎上に上げた前橋氏のOOP論とはこれです。
http://kmaebashi.com/programmer/object/index.html

今日はちょっと忙しいんで前橋氏の議論に感じた倒錯の内容は明日展開したいと思う。
イラネって言われそうだけど。

オブジェクト指向講座（補足編）

大変わかりにくいと評判のオブジェクト指向講座、
補足です。

前回までであなたは既存の開発手法の限界を
身をもって体験しました。
つきつめれば所持金がいかなる手段でも
アクセスできてしまうことが起こした悲劇です。

オブジェクト指向であれば所持金はprivateに宣言して
専用のアクセサ（入金するための唯一のメソッドだ）
に上限処理をちゃんと書いておけば、
もう前回までのような失敗はありません。
専用アクセサ抜きでは
所持金にアクセスすることすらできません。
確実に上限処理を織り込んだ形で
データを保護することができるのです。

（つづいたりつづかなかったり）