05/08/17 01:14:18
浅い経験と狭い視野で物事を語る奴が多くてかなわんな。
そろそろOOに話を戻さないか？
201:仕様書無しさん
05/08/17 01:45:58
>>200
深い経験と広い視野で、OOを語ってくれないか？
202:8仕様書無しさん
05/08/17 08:57:04
>196
なるほど言いたい事は分かったが、それは誤解だ。
俺は構造化では途中リターンはダメだと言いたくて、途中リターンはいいのではないかと言う意見に対して、
「途中リターンしている構造化ではないプログラム」を提示して、途中リターンを残したまま、
構造化になるように修正してくれと言った訳だ。
結果的に175が途中リターンを廃した（無理にreturnが残っているが不要にできる）コードを提供して
くれたわけだから、途中リターンはダメだと言うのは分かっただろう。
203:8仕様書無しさん
05/08/17 09:09:49
一応、構造化されたコードを提供しておこう。
int func(){
int ret = 0;
FILE *fp1;
FILE *fp2;
char buff1[100];
char buff2[100];
if(NULL == (fp1 = fopen("file1", "rb")){
ret = -1;
}else{
if(NULL == (fp2 = fopen("file2", "rb")){
ret = -1;
}else{
if(1 > fread(buff1, sizeof(buff1), 1, fp1){
ret = -1;
}else{
if(1 > fread(buff2, sizeof(buff2), 1, fp2){
ret = -1;
}
}
fclose(fp2);
}
fclose(fp1);
}
retrun ret;
}
俺は201ではないが、201と同意見だ。
200にはOOを語ってもらおうでなないか。
できれば、どこかへのリンクではなく、自分の経験と視野で語ってくれるとありがたい。
204:仕様書無しさん
05/08/17 09:25:25
構造化の意味わかってんのかな
205:仕様書無しさん
05/08/17 12:01:50
>>202
まともなプログラマならリソースにからむような所で
途中リターンなんて使わないんだから、
使いもしない所で途中リターンを使えと言われても無理な話だ。
元々使わないんだから、途中リターンがダメな理由に
リソース開放うんぬんは関係ないだろ？
>>203
コンパイルエラー
括弧の数も数えられないのかい？
206:ウンコ
05/08/17 12:05:30
>>1
おれは教えたがり屋だー！
だから、おしえてやるー！
けど、教えたいことが多すぎて、とても書ききれないー！
だから、>>1は、Ｃ＋＋どのぐらいやってるのか、そして、
今までどういう本を読んだか？ 不明な点はどうやって調べてきたか？
（ 例えば.NETのオンラインヘルプでいつも調べてる、とか、）
得意な学問など教えてくれれば、多分、とっても詳しく、
しかも的確に教えてやれると思うぞ？
特に数学に関してはどのぐらいのレベルか書いてくれるとよろしいぞ。
どうだ？
まあ、「どうしてオブジェクト指向と数学が関係あるだよ！」
というようなら、おれの教える相手ではないな。
がはは！
207:仕様書無しさん
05/08/17 12:15:58
>>203
１０個のファイルオープンがあったとするなら
そんなコードの組み方ではとんでもない事になるぞ。
208:仕様書無しさん
05/08/17 13:24:32
Javaメインだから後処理はfinallyに任せて途中リターンしまくりだなあ。
C++はあんなに機能一杯なのにfinallyが無いのが信じられない。
209:仕様書無しさん
05/08/17 19:36:27
そろそろ終了か
210:1
05/08/17 21:54:36
>>206
今だから言うが、別に俺に教える必要は無い。
俺は俺で勉強してるし、聞く必要があったら上長に聞く。
このスレはつりなのだよ。わかるかね？
わからんか？！ ああ？ 死ねよｗ
211:仕様書無しさん
05/08/17 22:12:53
オブジェクト指向とは死ぬこととみつけたりぃ!!!
212:仕様書無しさん
05/08/17 22:16:55
>>209
＞このスレはつりなのだよ
大半の厨達は当然気づいている。無視しろ。
213:仕様書無しさん
05/08/17 22:17:33
>>209 ×
>>210 ○
214:仕様書無しさん
05/08/17 22:22:15
ハガレンを全巻読み直して、強気になった1がきたなｗ
215:8仕様書無しさん
05/08/17 23:08:05
まともな反論もなくなって来たようなので、構造化プログラミングは完了って事でいいだろう。
そろそろ本題のオブジェクト指向に移るとするか。
まあ実際俺もオブジェクト指向を、構造化のように簡潔に説明しろと言われても、できない訳だ。
つーわけでオブジェクト指向を簡潔に、いやこの言い方は悪いな。
オブジェクト指向型のプログラムを組む方法を、具体的に説明出来る勇者求む。
200はどうした？早く出て来い。
204でもいいぞ。
205だと、まともなプログラマはオブジェクト指向できるから説明いらないとか言いそうだな。
216:仕様書無しさん
05/08/17 23:17:42
オブジェクト指向まわりの愚痴はこのスレでいいのかな？
俺はオブジェクト指向や設計の話をするときに、ソースコードを要求する奴がウザクてかなわない。
お前はなんでそんなに馬鹿なのかと、頭ひっぱたきたくなる。
てゆうか、ホントそいつが馬鹿なことについて小１時間問い詰めたくなる。
なんでソースがいるのかと？
お前はどこの時代からやってきたのかと？
設計の話でなんでソースを出さなきゃわからないのかと？
根本的に想像力が足りないっつーか、そんなんじゃ一生オブジェクト指向なんて理解できねぇよっつーか、
人としてその程度で終わってて満足なのかっつーか、もうホント救えない。
あーすっきりした。じゃあね。
217:ウンコ
05/08/17 23:24:11
釣りか・・・。
なーんだ。
218:仕様書無しさん
05/08/17 23:25:27
ベタだけどやっぱソースより醤油だよな。
219:仕様書無しさん
05/08/17 23:28:52
>>215
「誰に何をやらせるかを考えて設計する」でどう?
220:仕様書無しさん
05/08/18 00:01:46
設計で一番大切なのはアプリケーションの抽象モデルを正しく理解する
あるいはおおむね正しく理解することだと思う
その点で入門書的なOOは非常に問題がある。
人と犬は哺乳類から派生して･･･というやつだ
人と犬のBaseクラスを作るべきかどうか、作るとして哺乳類かどうかはアプリケーションによる
アプリケーション内の現実をどうやってモデル化するか？という問題のはずだ
これをリアル世界で人も犬も哺乳類だからといういう理由で哺乳類Baseを作るのは設計の基本が
なっていないと思うがどうよ
正直設計に王道はないし、確立された方法もないと思う。OOが有効なのはOOPってのが俺の結論
221:仕様書無しさん
05/08/18 00:22:44
設計ならCRCカードとか結構使えると思うぞ。
ほんとにカード使うとふざけてると思われるので
ホワイトボードとかにエッセンスだけ使うとOO知らない人でも
結構通じるみたいだぞ。
222:仕様書無しさん
05/08/18 00:24:33
>>215
で、君はファイル１０個オープンという前提なのに>>203のような
コードを書くのかい？
223:仕様書無しさん
05/08/18 00:39:01
>>221
CRCは悪くないと思うが箇条書きやホワイトボードやUMLと比べて
特に優位性はないと思う。
設計はいろんな手法を織り交ぜて、さまざまなレベルで繰り返し考えて
完成させるものだと思うので特定の技法が支配的にはならないと思う
224:仕様書無しさん
05/08/18 00:50:21
>>222
if～elseの多用はアホグラマーの常套手段だからしょうがない
225:仕様書無しさん
05/08/18 00:58:59
「ネストの上限は5とする」という規約を決めたい
226:仕様書無しさん
05/08/18 01:11:29
>>223
まあ確かにね。
227:8仕様書無しさん
05/08/18 09:30:44
>222,224
一応RESしとこうかな。他の人は分かってると思うので読み飛ばしてくれ。
もし10個のファイルの同時使用が必要ならば、10段のネストにするよ。
しかし実際に同時に必要なのは3段ぐらいに収まるはずだから、3段のぐらいのネストにして、
その中は関数にするよな。
すまん、本気で疑問に思ってるとは思わなかったんで無視してた。
228:8仕様書無しさん
05/08/18 10:02:41
>220
俺もそう思う。
大昔に読んだオブジェクト指向の入門書もそんな感じだった。
「ドラ○ちゃん」は「ドラ○もん」の派生であるとか、ドラ○もん製造機がどうのとかの内容だった。
その頃はCの全盛期だったんで、Cとの違いを調査していたのだが、継承の説明が簡略されてて意味不明だった。
そのため、その本を読んだだけでは、
「外部変数を撤廃して関数をカプセル化すればオブジェクト指向と同じ」
と言う無茶苦茶な結論に達した。
ただ、そんな訳はないだろうとの事で、
「きっとほとんど説明されていない継承がすごいんだろう」
と言うことになってその時は保留になった。
つまり入門書にドラ○もんや哺乳類が出て来たら、捨てた方がいい。
229:8仕様書無しさん
05/08/18 10:10:21
>206
俺は1じゃなくて、オブジェクト指向マスター済みだが、みんなのために教えてくれ。
対象は、
・C++は未経験だが、Cは3年の経験。構造化マスター済み。
・読んだ本はオブジェクト指向の入門書で、哺乳類の事が書かれてるやつ。
・検索はグーグル。趣味は自作とアニメ。
・数学は小学生レベルで、四則演算マスター済み。
以上で、よろしく。
230:仕様書無しさん
05/08/18 10:29:09
ちょっと聞きたいんだが、貴様らの中でruby厨の奴、
もしいたら手上げろ。市場調査したい。
別にここに聞く必要は無いが、なんとなくだ。別にｗ
こないだ宇宙戦争見たんだけどよ、50年前の映画をまあまあ忠実に再現してると思うぞ。
収拾のつけ方はたぶんあれしかないし、主人公が科学者という矛盾もなくなってよかったじゃねーかよ。
この映画の落ちがだめだとか言ってるヤローはたぶんオリジナル知らない奴だな。ＤＶＤ借りて情報仕入れとけよ。糞が。
矢口マリ、テメーだよ。
231:仕様書無しさん
05/08/18 11:08:16
rubyは興味あるが今のところ使用する用途がない。
宇宙戦争ってたしかH.G.ウェルズのSF小説が原作じゃなかったっけか？
100年前だぞ。
232:仕様書無しさん
05/08/18 11:43:19
映画は50年前にやってたんだよ。
233:仕様書無しさん
05/08/18 11:57:43
>>220
モデルの理解と入門書的OOの批判とモデリングの方法論不在を同時に語っていて
論点が不明瞭だな
>どうやってモデル化するか？という問題のはずだ
ここだけ同意
234:仕様書無しさん
05/08/18 13:29:13
>>230
ヤグチマリが糞かどうかわ知らんが，オリジナルを知らんと面白さがわからんような映画は糞だろ
235:仕様書無しさん
05/08/18 13:38:09
落ちが糞といってたからな。映画は普通だが、矢口は間違いなく馬鹿だ。
236:仕様書無しさん
05/08/18 13:45:15
矢口が馬鹿だということは誰もが認めるところだろ。
映画通ぶってるけど、ほとんど何も知らないみたいだし。
宇宙戦争って言うのはほとんどのエイリアンものの元になった映画。インディペンデンスデイでは落ちをパクってるくらいだし。
237:仕様書無しさん
05/08/18 13:48:54
問題は矢口にどうやってOOの真髄を教えるかだな。
238:仕様書無しさん
05/08/18 13:52:45
今日の勉強の成果を発表する。
ドラえもんとガンダムは、
どちらもロボットクラスから派生したものである。
public class ドラえもん extends ロボット {
public 道具 ポケット();
}
public class ガンダム extends ロボット {
public ビーム 鉄砲();
}
239:仕様書無しさん
05/08/18 14:00:47
ってことは明日はロボットクラスの実装に入るんだな！
240:仕様書無しさん
05/08/18 14:15:52
>>227
１０段のネストだろうが関数だろうが同じ事だろｗ
241:仕様書無しさん
05/08/18 14:26:56
>>229
まずは参考にオブジェクト指向マスター済みのあなたの講釈が聞きたいな。
ぜひ、ご教授いただきたい。よろしく。
242:仕様書無しさん
05/08/18 14:30:11
無駄な関数で溢れ返るなら、ためらい無くネストを深くするなぁ俺は
243:仕様書無しさん
05/08/18 14:42:14
括弧の数も数えられないのにオブジェクト指向マスターとか言われてもなぁ（汗
244:仕様書無しさん
05/08/18 14:53:02
ネストを深くすると見ずらい上に拡張性の希薄なコードになるからな。
無駄に階層増やすより、できるところは一本道で組めるように心がけてる。
245:仕様書無しさん
05/08/18 14:59:00
「自称○○の専門家」 ほど怪しげな職業は無いです
246:仕様書無しさん
05/08/18 15:05:40
「～をマスターしてます！」とかって採用面接でよく言う奴いるけど
実際テストしてみるといろはのいの字も知らない奴ばかり。
プログラマは常に創意工夫の上に成り立っている職業なので、
マスターしたと思う事は途中で投げ出すのと同義だと思ってる。
247:仕様書無しさん
05/08/18 15:09:44
>>246
＞マスターしたと思う事は途中で投げ出すのと同義だと思ってる
同感。途中で投げたか、あるいは飽きたか
248:仕様書無しさん
05/08/18 16:30:55
>>238
リスコフの置換原則を守ってない。
安易な継承はいけません！
249:仕様書無しさん
05/08/18 16:43:58
>>248
悪いが、>>238 は守っていると思う
250:仕様書無しさん
05/08/18 17:30:59
>リスコフの置換原則について
このスレ初のためになる議論を頼む
251:仕様書無しさん
05/08/18 18:05:46
>>250
SubClass extends SuperClass の時、SubClass は SuperClass と置換可能であることが望ましい
掻い摘んで言うと、SubClass は SuperClass と同じように振舞う事が理想だということ
ガンダムってロボットと同じように振舞えるんじゃないの？
252:仕様書無しさん
05/08/18 18:13:32
ごめん文章が微妙に変だ
SuperClass は SubClass と置換可能である事が望ましい
要は SubClass は最低限 SuperClass と同じ仕事をこなせることが理想と
253:8仕様書無しさん
05/08/18 23:06:55
>240
何がｗなのか分からん。ネストを深くするのに抵抗がある人なのかな？
見にくいって言う人もいるけど慣れの問題だよ。拡張性が希薄ってのも何を指してるのかわからんな。
まあしかし、Javaとかではネストが浅くなるし、finallyもあるから途中リターンOKだから、
現代向きと言えば言えるな。
さてそろそろオブジェクト指向の説明に移るとするか。
254:8仕様書無しさん
05/08/18 23:17:58
ではお待ちかねのオブジェクト指向プログラミングの説明だ。
まず最初に言っておくが、これは俺のやり方なので、誰でも出来るかは分からない。
さらに完全版ではない。また他にいい方法もあるかもしれないので、自分で研究して開発してくれ。
まずオブジェクト指向プログラミングには、経験とセンスが必要だ。
多少の訓練をすれば誰でも出来る構造化プログラミングとはちょっと違う。
新人で出来ない人でも気にする必要は無い。3年ぐらいの実務経験を積んでからチャレンジすれば良い。
5年の実務経験があって、半年勉強しても分からない人は諦めた方がいい。
それはセンスの無いためだが、センスが無くても普通の業務ぐらいはこなせるから、
無理して覚える必要は無い。
まあ、俺の経験ではプログラマの中で30%ぐらいは、頑張ってもオブジェクト指向を理解出来ない人がいる。
255:仕様書無しさん
05/08/18 23:24:07
終始センスかよ
256:8仕様書無しさん
05/08/18 23:32:39
オブジェクト指向型プログラミングの方法には2種類ある。
1.構造化プログラミングで作成した後に、作成された構造体をクラスにして、
それに関連する関数を作成したクラスのメソッドとして追加する。
2.使用するデータをDB設計の手法を用いてテーブルとして作成し、それをクラスとする。
その後にそのデータに関連する処理をメソッドとして作成する。
1の方法は非常に困難である。まず構造化手法で脳内で作成して、分解、分類を行うため、
相当の熟練者でなければ不可能である。また一度に作成出来る量も少なくなる。
そのため、1の方法は推奨しない。長年構造化をやってきた人がオブジェクト指向に移るために
最初に行うのはいいかもしれない。
次に2の方法だが、まずDB設計が出来るのが前提である。
DB設計と言うのは非常に高度な作業で、経験と学習が必要である。
経験というのは設計から保守までを言う。
最初に設計しただけではだめで、多くの仕様変更に耐えたDBを設計運用した経験が必要である。
また経験だけでもだめで、学習が必要である。最低でも正規化ぐらいはマスターしておいて欲しい。
では2の方法で説明しよう。今日はここまで、また次回。
257:仕様書無しさん
05/08/19 00:16:35
>>254,256
他の書き込みを完全に無視した長文お疲れ
258:仕様書無しさん
05/08/19 02:10:00
>>256
OOPとRDBは仮面夫婦。
本質的に仲が悪いのに世間体のために同居している。
そんなことも知らんのか。
259:仕様書無しさん
05/08/19 04:14:20
オブジェクト指向をマスターしたのに完全版ではないとはこれいかに
260:仕様書無しさん
05/08/19 04:19:47
そう言っておく事で突っ込みの言い訳する逃げ道を作ってるんだろｗ
261:仕様書無しさん
05/08/19 06:18:47
>>256
ＤＢ設計手法はオブジェクト指向型プログラミングに適したものではないな。
根本的に違うものだから。
262:8仕様書無しさん
05/08/19 09:47:07
>258
そうかな？
オブジェクト指向と仲の悪いのは、DB自体でなく「SQL」だろ。
そんな事もしらんのか？とは言わないが、ちょっと考えてみてくれ。
>259,260
分かった分かった。
突っ込まれたら「完全ではないで逃げない」事にするから、ちょっとは内容に突っ込んで見たらどうだ？
>261
根本的に違うのは承知の上だが、データ分けする部分などの正規化の部分が利用出来ると思う。
DB設計の知識の方が膨大だが、その一部をオブジェクト指向に利用する物だと考えてくれ。
また、反論の時は具体的な理由も書いて欲しいな。
こっちが反論する時に対象が曖昧になるからな。
「～するときに、～が問題になる」形式だと助かる。
263:8仕様書無しさん
05/08/19 09:57:51
>241
ほらおまえの番だぞ。
264:248
05/08/19 10:07:57
>>249
おわー賑わってる。遅レスすまんです。
痴漢原則に則ると、これが望ましいと思われます。
public class ドラえもん extends ロボット {
public 出るもの 出す(){
return new 道具;
};
}
public class ガンダム extends ロボット {
public 出るもの 出す(){
return new ビーム;
};
}
もちろん、道具とビームは出るものの子クラス。
せっかく同じロボットクラスを継承した兄弟なんだから
インタフェースは極力一緒にしたい。
そうすれば、コンテキスト側を変える事無く
ドラもガンムも使える事になる。
ただ、メソッド名が汎用的すぎて不明瞭てのはあるかも。
そこは思案のしどころだね。
265:248
05/08/19 10:13:18
おっと失敬、セミコロン消し忘れがあった。
あと、ロボットクラスはどうせならインタフェースにしたい。
public interface ロボット {
public 出るもの 出す();
}
>250
こんなんでためになる？
なんか皆さんには釈迦に説法みたいで恐縮なんですが。
266:仕様書無しさん
05/08/19 11:12:24
>>262
＞2.使用するデータをDB設計の手法を用いてテーブルとして作成し、それをクラスとする。
＞ その後にそのデータに関連する処理をメソッドとして作成する。
DB設計的に良い分割がOO的には役に立たないと思う
OOの基本のひとつに隠蔽、データ抽象があるけど、これとDBの正規化は真逆の概念でしょ
ただ現実世界ではObjectを永続化する必要があるわけで、そのときにRDBを使うならORマッピング
は避けて通れない。ORマッピングを苦労するくらいならOO的な美しさを捨ててDB基本主義で作る
っていうのは賛成する
でもそれはOOの敗北であって、決してOOとRDBが仲がいいということではない
267:仕様書無しさん
05/08/19 11:14:18
俺も白いものがある部位から出てくるので
public class 俺 extends ロボット {
public 出るもの 出す(){
return new 白いもの;
}
}
でOKか？
268:仕様書無しさん
05/08/19 11:26:10
>>263
２の方法での説明とやらはどうしたんだい？
269:248
05/08/19 12:32:04
>>267
オーケーオーケー。
ただロボットはinterfaceにしたいから
implementsだとありがたいです。
これじゃ多態性ってより、多態・性ですね。
270:248
05/08/19 12:55:07
いったんまじめな話に戻ると
>>252
に書いてある事だと継承はただの差分プログラムになっちゃう。
ロボット型変数でガンダムのインスタンスを受けた時、
鉄砲メソッドを使おうとするとガンダムにキャストしなきゃいけない。
だから置換原則に反してると思った訳です。
出すメソッドをオーバーライドする形ならキャストは要りません。
簡単に白いものも飛ばせるようになった事でも
interfaceへのプログラミングの柔軟性が判りますね。
まあやりすぎはソースが読みにくくなっていやんだけど。
出すメソッドって名前じゃ抽象的すぎるし。
こんなんでどうでしょう。
271:仕様書無しさん
05/08/19 14:07:25
ロボットクラスの例って設計時の手順のヒントにもなってるね。
1. ドラえもんクラスとガンダムクラスをつくろうとした。
2. ドラえもんクラスはポケットメソッド、ガンダムクラスは鉄砲メソッドを持つ
3. ポケットメソッドと鉄砲メソッドを出すメソッドで抽象化できることに気づいた
4. ロボットインターフェースで出すメソッドを定義しドラえもんクラスとガンダムクラスで、
出すメソッドを実装した
5. 俺クラスもロボットインターフェースをインプリメントできることに気づいた
こういう流れでクラス設計してくのって結構ありがちじゃない？
272:仕様書無しさん
05/08/19 16:17:08
>>256
ぐぐるだけでどこにでも書いてあるような事を
自論であるかのように得意げに語られても困るわ。
273:仕様書無しさん
05/08/19 17:02:25
ホリエモン無所属かよ
まあ小泉の独裁政治に加担するよりましだな
274:仕様書無しさん
05/08/19 17:03:58
ｽﾏﾝごばくったorz
275:仕様書無しさん
05/08/19 17:15:08
>>273
いやいや、無所属だが小泉自民のバックアップつきだぞ
276:仕様書無しさん
05/08/19 17:40:30
で、ホリエモンクラスは何を出すんだ？
277:仕様書無しさん
05/08/19 18:08:24
>>271
そうですねえ。
オブジェクトは現実世界のなんちゃらとかゆうよりも
だんぜん現実的。
このスレ初のためになる議論になったかな。
そうでもないか。
278:8仕様書無しさん
05/08/19 20:38:05
>272
本当にどこかに書いてあるなら、俺の考えと同じ考えの人がいるって事で、
俺の正当性が増したってことだな。
さらに272自身が内容自体に文句を言ってないって事は、272も内容に異存はないって事で、
さらに正当性が増したって事だな。
おつかれ。
279:8仕様書無しさん
05/08/19 20:42:52
ロボット説明はドラ○もん説明や哺乳類説明と同じで、オブジェクト指向を知っている人にしか分からない。
で、オブジェクト指向知っている人が、分かりやすい説明だとか言うから、
知らない人に「キ○ガイが集まるスレはここですか」と言われる。
280:仕様書無しさん
05/08/19 21:06:48
>>271
お世辞にもいいサンプルとはいえないな
共通のベースクラスを作るのに【ポケットメソッドと鉄砲メソッドを出すメソッドで抽象化できることに気づいた】
が理由というのはOO覚えたての初心者によくある「なんでもいいからOO使いたい病」にしか見えん
281:仕様書無しさん
05/08/19 21:23:53
>>271
俺だったら、
class Robot
{
public:
virtual void gun() = 0;
//または virtual void gun(){} か？
virtual void pocket() = 0;
//または virtual void pocket(){} か？
};
class Doraemon : public Robot{};
class Gandom : public Robot{};
のようにするな。gun や pocket でいったい何をするのか
さっぱりわからんがｗ
C++ですまん。
282:仕様書無しさん
05/08/19 21:27:04
>>281はCからの転向組。
283:仕様書無しさん
05/08/19 21:35:24
「オブジェクト指向で開発をする」
と言いつつ、結局最後には昔ながらの開発スタイルになってやがる。
そして残ったのは、開発を始めた頃に書かれた誰も読まなくなったUMLの各種設計書・・・
284:仕様書無しさん
05/08/19 21:48:02
>>283
それほどまでに「オブジェクト指向開発」は難しいものなのだよ。さて、ここでオブジェクト指向
開発を最後まで持続できる方法に関するヒントをあげよう。
ヒント：「適度な忍耐力」と「割り切り」と「切り捨て」
285:仕様書無しさん
05/08/19 22:00:10
>>284
割り切ってオブジェクト指向を切り捨てよう
すると忍耐もいらない。
286:仕様書無しさん
05/08/19 22:08:12
オブジェクト指向なんて子供のおもちゃですよ。
それで給料が上がるわけじゃない。
287:仕様書無しさん
05/08/19 22:14:00
>>278
別に否定するつもりは元からないから。ただつまらんだけだ。
３流サイトの丸写しで満足かい？
君にしかできない身のある説明をしてくれ。
288:仕様書無しさん
05/08/19 22:20:58
>>287
俺は278ではないが、君は批判しかしていないだろ。
君こそ、君にしかできない身のある説明をしてくれよ。
289:仕様書無しさん
05/08/19 22:22:50
自演乙
290:仕様書無しさん
05/08/19 22:25:44
>>288
そういう君こそ、君にしかできない（ｒｙ
291:仕様書無しさん
05/08/19 22:28:16
結局のところ、ここには身のある説明ができる人は一人もいないって事でＦＡ？
いたら説明してくれ。マジで。
292:仕様書無しさん
05/08/19 22:30:25
結局、糞の集まりだな。
293:仕様書無しさん
05/08/19 22:39:14
そろそろこのスレ終了かな。
ためになる事一つもないからもういいよ。
といいつつage
294:仕様書無しさん
05/08/19 22:48:28
オブジェクト指向やってるとこあります？
やっぱ専用の開発ツール必要ですよね？
295:仕様書無しさん
05/08/19 22:51:33
こりゃまたすごい質問がきたな
296:仕様書無しさん
05/08/19 22:52:21
緊急告知！
今ＶＩＰと韓国サイバーテロ集団が火花をあげて戦っています！
この夏の思い出作りに是非貴方達ももこの祭りに参加しませんか？
↓↓↓詳しくはは↓↓↓
ｽﾚﾘﾝｸ(news4vip板)
ご協力、よろしくお願いします。
【VIP】抗議文を考えてくれ
ｽﾚﾘﾝｸ(english板)
297:仕様書無しさん
05/08/19 22:59:29
犬＝オブジェクト
犬．尻尾を追っかけてクルクル回る
犬．俺に前足を掛けて腰を振る
まっ、そういうことだ。
298:仕様書無しさん
05/08/19 23:19:33
>>280
元がネタだしな。
- ロボットを戦わせるゲームをつくる
- ロボットのみを後からリリース可能で、ゲームに追加できる
という前提をつけてみたら?
299:仕様書無しさん
05/08/19 23:34:28
今日は、ファクトリーパターンというものを教えてもらった。
public class ４本足Factory {
public ４本足 factory(String 特徴) {
if (特徴.equals("背もたれ")) {
return new 椅子();
}
if (特徴.equals("ぬれた鼻")) {
return new 犬();
}
}
}
300:仕様書無しさん
05/08/19 23:47:08
戦争だ。援軍頼む。
ｽﾚﾘﾝｸ(news4vip板)
301:仕様書無しさん
05/08/19 23:47:54
>>299
それでは椅子が食えないから中国人が文句たらたらだろ。
302:仕様書無しさん
05/08/20 00:09:46
>300
チョンと同レベルの阿呆は(･∀･)ｶｴﾚ!
303:仕様書無しさん
05/08/20 01:41:39
はいはいワロスワロス
304:仕様書無しさん
05/08/20 10:22:15
2chでまじめな話するのはいやだが、
しょうがないから業務システムでありそうな例考えてみた。
- なんちゃら申請書が何種類もある
- 申請書は上司の承認が必要である
- 申請書の入力項目はまちまちである。
- 申請書は書きかけでもシステムに保存できる
- ほとんどの申請書は上司に提出する前なら書いた本人が削除できる。
ただし、タクシー代清算申請書は金額が低ければ、上司に提出後
上司が削除できる。
- 削除できない場合は画面上に削除ボタンは表示しない。
- 今の開発は第一フェーズで第二フェーズで申請書の種類が増えるが
仕様は全く決まっていない。
こんな感じのときお前らどう作る?
305:仕様書無しさん
05/08/20 10:30:18
素直に助けてくださいって言えよ。
306:仕様書無しさん
05/08/20 10:36:49
>>304
助けてください。
なーんて、実は昔作ったのとほぼ一緒の内容。
俺は単純に
申請書ベースクラスで表示可か不可を返すメソッドを実装してディフォルト動作とし、
タクシー代清算申請書で上書きした。
二次フェーズで削除可不可のロジックがまたいろいろ出てきそうだったしね。
もちろんOOしなくても書けるし、OOでも他にやりかたあんだろうね。
他人がどうするか見てみたい。
307:仕様書無しさん
05/08/20 10:41:20
レス番を間違えるあたり、>>306の必死さが覗える
308:仕様書無しさん
05/08/20 10:43:33
>>307
せっかくまじめな例出してやったのにそんないいかたするなよ。
で、お前はどうするよ。
309:仕様書無しさん
05/08/20 10:49:01
夏休みの宿題は自分でやろう
310:仕様書無しさん
05/08/20 10:53:06
おいおい。
つまらん連中だな。
311:8仕様書無しさん
05/08/20 11:11:05
>287
本当にあるようなので、そのサイトのアドレス教えてくれないか？
いや287への攻撃って意味じゃなくて、そのサイトでどういう説明しているのか見てみたい。
大体、コピペかどうかは本人がよく知っている訳だから、俺にコピペだって批判されても、
そうじゃないとしか言えないな。大体、長文で本当のコピなら見れば分かるだろう。
312:8仕様書無しさん
05/08/20 11:26:30
>266
266に反論するつもりだったんだが、304で面白いのが出て来たのまた今度。
>304
やっとホネのありそうな奴が出て来たので、解答を考えて見る事にする。
是非ともロボットマニアの方々の設計も見せて頂きたい。
大口叩いた連中は、クラス分けぐらいでも見せてみろよ。
（俺が一番大口というのは別棚）
313:仕様書無しさん
05/08/20 11:28:16
はいはいワロスワロス
314:仕様書無しさん
05/08/20 11:36:47
いい反論が思いつかないから先延ばしって事なんだろうねー
315:仕様書無しさん
05/08/20 11:40:27
>>304
漏れもそんな感じの設計１週間で完了しろって言われたよ。
316:仕様書無しさん
05/08/20 12:01:36
お、頼むよ。
期待してるよ！
317:仕様書無しさん
05/08/20 12:45:32
>>304
申請書の規定クラス作って、そこにそれぞれの種類の申請書クラスをぶら下げるだけだろ？
318:仕様書無しさん
05/08/20 12:54:09
全体的に実装すべきことは、大別して、
・申請書の登録、更新、削除
・申請フロー制御
・各ユーザごとの権限制御
だな。
319:仕様書無しさん
05/08/20 13:03:51
どの申請フローを通るかは、申請書ごとに決定するわけだから、
申請書には、申請フロー情報がぶら下がる。
ただ、出した人間の部署によって、各所属の部課長の承認が必要な可能性があるな。
そうすると、申請フロー図の各ノードに乗る承認者は、１ユーザであったり、役職であったりする可能性があるな。
あと、承認者不在時の代行処理や、申請迂回も考慮した方がいいかもな。
誰か一人いないせいで、処理が止まってしまっては、使えないから。
あと、一つの承認レベルに複数の承認者がいる可能性もあるな。
3人が承認して、初めて次のレベルの承認者に書類が回されるけど、
この3人のレベルは同じで、下位のレベルで承認された場合は、3人同時に書類が届かないといけない、みたいな。
逆に、一つのレベルに複数の承認者がいて、誰か一人承認すればよい、みたいのもありうる。
ないならないで、いいが、全く考慮しないのはあぶないな。
この辺を考慮して申請書フローのクラス構造を考えないと、あとで直しが大変だな。
320:仕様書無しさん
05/08/21 00:47:07
申請書はDBに保存するんだろ?
ならBaseクラスはLoadとSaveのメソッドを持たなくてはいけないな
後必要そうなのは
・申請(Person 提出者)
・承認(Person 承認者)
・却下(Person 承認者)
そして振る舞いをオーバーライドしたいから
・virtual On申請されたとき()
・virtual On承認されたとき()
・virtual On却下されたとき()
プロパティとしてその報告書特有のフィールドがあるだろう。そしてそれはDBの各カラムと対応しなければならない
俺なら定義書ファイルからDBのTable作成のためのSQLとソースコードを同時に作成するスクリプトを作る
そのほかに全ての報告書に共通のプロパティとして
・承認フローのタイプ
・申請者
・承認状態
・申請時間
などがあるかな
321:仕様書無しさん
05/08/21 12:45:14
>319,320
おれはO-Rマッピングツール、ワークフローは出来合いのものを使ったのでその辺は楽ちんだった。
その辺自分で作るとなると結構大変だよな。
322:仕様書無しさん
05/08/21 17:49:10
ちょっと待てｺﾞﾗｧ！
323:仕様書無しさん
05/08/22 19:35:17
オブジェクト指向プログラミングではグローバル変数が存在しないって本当ですか？
324:仕様書無しさん
05/08/22 19:48:40
>>169
超効率悪いな。
わざと言ってるだろ
325:仕様書無しさん
05/08/22 20:21:12
オブジェクト指向ならこんなにスッキリ！
#include <string>
#include <cstdio>
class FileReader
{
std::string fname;
FILE *fp;
char buf[100];
public:
FileReader(const char *pfname, const char *mode) : fname(std::string(pfname)), fp(NULL)
{ if( NULL == (fp = fopen(fname.c_str(), mode))) throw "fopen error : " + fname; }
~FileReader() { if( fp ) fclose(fp); }
char *read_byte()
{ if( 1 > fread(buf, sizeof(buf), 1, fp)) throw "fread error : " + fname;
return buf;
}
};
int func(){
try{
FileReader fr1("file1", "rb");
FileReader fr2("file1", "rb");
char ch1 = *fr1.read_byte();
char ch2 = *fr2.read_byte();
}catch(...){
return -1;
}
return 0;
}
326:仕様書無しさん
05/08/22 20:50:02
>>325
try catch があればこんなにスッキリ
なら理解できるけど
どのへんがOOかをもっと詳しくお願いしたい
327:仕様書無しさん
05/08/22 21:08:12
>>326
見るところはtry-catchじゃなくてﾃﾞｽﾄﾗｸﾀでのｸﾛｰｽﾞだろ？
328:仕様書無しさん
05/08/23 00:05:29
>>169
import java.io.file;
//(ry
public class FileIoDemo{
private File file;
public FileIoDemo(File file){
this.file = file;
this.file.createNewFile();
}
329:仕様書無しさん
05/08/23 00:07:38
public int func(){
PrintWriter writer = null;
try{
writer = new PrintWriter(
new PrintWriter(
new OutputStreamWriter(
new FileOutputStream(fp1), encode
)
)
);
while(何か処理){
writer.write(何か書き込む);
}
330:仕様書無しさん
05/08/23 00:09:29
} catch(IOException e) {
e.printStackTrace();
} catch(FileNotFoundException e) {
e.printStackTrace();
} catch(Exception e) {
e.printStackTrace();
} finally {
try {
if(writer != null){
writer.close();
}
} catch(IOException e) {
e.printStackTrace();
} catch(Exception e) {
e.printStackTrace();
} finally {
}
331:仕様書無しさん
05/08/23 00:09:42
publise UsingDemoClass{
public static final void main(final String[] args){
File directory = new File("/usr/local/apps/examples/io/");
if(!directory.exists()){
directory.mkdirs();
}
File fp1 = new File(directory, "file1");
File fp2 = new File(directory, "file2");
List<FileIoDemo> fileIoDemoList = new ArrayList<FileIoDemo>();
FileIoDemo fileIoDemo1 = new FileIoDemo(fp1);
FileIoDemo fileIoDemo2 = new FileIoDemo(fp2);
}
}
これはどう？
332:仕様書無しさん
05/08/23 00:20:27
もともとのお題が良くないから別になんともって感じだね。
サブルーチンがメンバメソッドに変わった程度じゃね、、
ＯＯって程のもんじゃないでしょ。
333:仕様書無しさん
05/08/23 01:24:48
なにを書やりたいのか意味不明なお題だよな
334:仕様書無しさん
05/08/23 01:25:30
なにを書やりたいのか意味不明なレスだよな
335:仕様書無しさん
05/08/23 05:47:59
>>332
サブルーチンなんて死語を今どき使うお爺さんがいるとは
336:仕様書無しさん
05/08/23 05:53:14
>>332のような分からず屋のために
>>328を改良したほうがよさそうだ。
改良型FileIoDemoの実装としては
フィールドにWriterを追加だ。
そしてFileIoDemoにclose()メソッドを委譲させる。
そして、Listオブジェクトをwhile()で回して
close()メソッドの記述を一回で済ませる。
それとimport文を忘れている。
import java.io.PrintWriter;
import java.io.BufferedWriter;
import java.io.Writer;
import java.nio.charset.Charset.;
import java.io.FileWriter;
import java.io.OutputStreamWriter;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.FileNotFoundException ;
あとはまかせた、
337:仕様書無しさん
05/08/23 05:56:08
ささ、抽象クラスを作ってあげたから継承しなさい！
public abstract class 改良型FileIoDemoAbstract {
private Writer writer;
public 改良型FileIoDemo(Writer writer){
this.writer = writer;
}
public abstract void close() throws IOException {
}
//あとは任せた
}
338:先生
05/08/23 05:56:38
こうやって絶えずリファクタリングするんだよ
339:仕様書無しさん
05/08/23 06:57:27
こうやって、前に進んでいるようで進んでいない
予算ばかりかかるプロジェクトは破綻していくんだよ
340:仕様書無しさん
05/08/23 10:14:30
専門学校生が学習中の中途半端な知識をひけらかして悦に入るスレはここですか？
お前らさ、何を得意げに無意味なゴミコード晒してんの？
341:仕様書無しさん
05/08/23 10:30:59
そういやこの前しゃべり場でスキルを身につけるために
大学よりもコンピュータ専門学生に行く事を選んだとかいってた
馬鹿がいたな。
そういう奴らが集まって恥部を晒すスレか
342:仕様書無しさん
05/08/23 14:47:48 BE:624370289-
>>339-340
あんたらネガティブだねえ
>>340
思うんだが、専門学校卒業した香具師が
バイト先にいるんだがオブジェクト指向なんて全然しらないのが
不思議でしょうがないんだけどなあ。
ちなみに漏れは大学院生ね
>>341
オブジェクト指向教育は専門学校ですらやらないところが多そうだがなあ。
とりあえず、デザインパターンの本でも読んでみなよ。
専門学校なんて行かなくても
オブジェクト指向スキルが身に付くから。
343:仕様書無しさん
05/08/23 14:52:34 BE:182107973-
スーパークラスに
publiv Writer getWriter(){
return this.writer;
}
を追加しないといけないね。
public class 改良型FileIoDemo extends 改良型FileIoDemoAbstract {
public 改良型FileIoDemo(Writer writer){
super(writer);
}
public void close() throws IOException {
this.getWriter().close();
}
//さらにあとは任せた。
public void write() throws IOException {
//任せた。自分で実装してくれ
}
}
ついでにスーパークラスにこいつも追加ね
/**
* 書き込み.
public abstract void write() throws IOException;
344:252
05/08/23 15:34:56
>>270
亀だがすまぬ。なんか返信したつもりでしてなかったみたいで
リスコフの置換原則ってのは具体例を挙げて言うと、
『ガンダムはロボットを継承している。ならばロボットにできることはガンダムにもできてしかるべきだ』
って言うこと。
この原則に反する設計は、スーパークラスの振る舞いをキャンセルするような設計だ。
んで >>238 はその原則をとりあえず守ってるみたいなんだな。
ついでに言うと、
＞ロボット型変数でガンダムのインスタンスを受けた時、
＞鉄砲メソッドを使おうとするとガンダムにキャストしなきゃいけない。
ロボットにできない筈の事をしようとしているんだから、ある意味キャストは自然だよな。
こんなの置換原則でもなんでもない。
345:270
05/08/23 16:59:33
>>344
レスありがとう。
でも原則の定義がちょっと違うと思います。
それだと差分プログラムでしかないでしょう？
『派生型は基本型と置換可能でなければならない。』
これが要約。つまり、コンテキスト側で
ガンダム.出す()
と書いてある所を、
ロボット.出す()
って置換しても振る舞いが変わらないようにしなきゃいけない。
これがLSPだと、俺はずっと思ってたんだけど、違うのかな？
少なくともR.マーチンの文章からはそう読んだんですが。
もちろん原則は原則であって、やぶったら絶対にいけないって訳じゃないから
キャストくらいする局面は幾らでもあるでしょう。
でも、なるたけそれは避けようぜ、って話ですね。
346:270
05/08/23 17:01:10
あわわ間違えた。
＞置換しても振る舞いが変わらないようにしなきゃいけない
振る舞いは変わるんだよ！バカだなー。すまそ。
347:252
05/08/23 17:25:13
>>270
あれ？と思って調べてみたら
＞派生型はその基本型と置換可能でなければならない
＞基本クラス型を派生クラス型に置き換えても正常に動作しなくてはならない
の両方を見つけたよ
URLﾘﾝｸ(www.atmarkit.co.jp)
俺は下の方をリスコフの置換原則だと思ってたけど原書ではどうなんだろ
けど、２個目の文の直ぐ下にも
＞そのためには派生クラスは基本クラスの振る舞いの妥当性を維持する必要がある。
＞基本クラス以下の機能しか持たない派生クラスは、基本クラスと置き換えることはできない
って書いてあるし
348:252
05/08/23 17:31:01
良くわからんが、リスコフの置換原則は負の可変性をできる限り無くしましょうって話じゃないのか？
親クラスの振る舞いをキャンセルする子クラスが無いようにしましょうって
349:270
05/08/23 19:24:20
>>347
継承はis aの関係でなくてはいけないってのが
そもそもだから、上と下両方でしょうね。
俺はリスコフの原書じゃなくて
R.マーチンの『アジャイルソフトウェア開発の奥義』で
初めて知ったんだけど
兎に角親クラスだろうと派生クラスだろうと
何が来ても正常に動作するように設計するのが
よろしいって話でした。
350:仕様書無しさん
05/08/23 19:26:29
「派生 is a 基本」はいいけど、「基本 is a 派生」はなりたたないんでね？
351:350
05/08/23 19:27:22
んなこたわかってるね。失礼しました。
352:252
05/08/23 19:43:07
>>349
上と下と両方なのか。了解でし
最初の例に戻るけど、「ロボット」に「鉄砲を撃つ」メソッドを付けることはできないんだから、
このメソッドは、たとえ置換原則に反してでも「ガンダム」に付けるのが正しい設計なんじゃないかな
無理してトリッキーな事するよりも、よほど自然な設計だと思うけど
353:仕様書無しさん
05/08/23 20:33:14
ロボット::指を動かす();
ガンダム::ビームライフルを撃つ()
{
if( ビームライフル != NULL )
{
指を動かす();
;
}
}
354:270
05/08/23 20:41:42
>>352
そうですねー。ドラえもんも道具をポケットから出すし、
それで「出す」メソッドに抽象化してみたんですけど、
やっぱり直感的じゃないですな。
まあ俺の考えるLSPにのっとった設計の例、って事で許して下され。
元々のロボットクラスの例がネタだし。
355:仕様書無しさん
05/08/23 22:02:52
俺はメイヤー先生の本で最初に知った
メイヤー先生はAssertion大好きなのでBaseクラスのメソッドのAssertionをパスする入力は
派生クラスのAssertionも通らなくてはいけない。
同じようにBaseクラスのメソッドが約束する振る舞いは派生クラスのメソッドも満たさなくてはいけない
という原則をうたってたなぁ
これは数学的だなとおもったよ
356:仕様書無しさん
05/08/23 22:54:35
専門学校で本格的なOO教えるとこ
なんかあんのか？
OOに限った事じゃないけど、独学ばっかりで
なんのために学校通ってたのかわかんなく
なってたよ。
357:仕様書無しさん
05/08/23 23:11:04
あらゆるジャンルの専門学校で役に立つとこってほんとにあんのか
358:仕様書無しさん
05/08/23 23:25:14
>>357
学ぶ人間の資質が一番重要だが、
スペシャリストを輩出する専門学校はそれなりにあるよ。
でも殆どはゴミ生産工場。特ににコンピュータ関連は酷いね。
359:仕様書無しさん
05/08/23 23:35:43
俺は現役専門学校生だけど俺が通ってる学校は
せっかく2年間もあるのに内容を薄く薄く伸ばした授業しかないよ
そんな授業にもついていけてない連中がSE、プログラマーとして内定取ってたりするの見てて
プログラマーになるの怖くなったよ。趣味が一番なのかな？
360:仕様書無しさん
05/08/23 23:36:29
書いてから気づいたが思いっきりスレ違いだな…スマン
361:仕様書無しさん
05/08/24 10:22:42
>>359
まあ大抵は実務をこなしながらスキルアップしていく訳だけど、
人間性も含めプログラマとしての最低限の資質を兼ね備えてない奴は
デスマ引き起こしたり精神患ったりしてるわな。
362:仕様書無しさん
05/08/24 10:39:05
スキル不足だけが原因の長時間残業は、デスマとは呼ばないけどね
363:仕様書無しさん
05/08/24 14:22:48
派生 基本という用語がでているが
UML命名規則に従って統一しないか
派生する, 継承, 拡張 -> 汎化
派生 -> サブクラス
基本 -> スーパークラス
メンバ変数, フィールド, プロパティ -> 属性( 注 : C#の属性と間違えないように !)
メンバ関数, メソッド, サブルーチン -> 操作
364:仕様書無しさん
05/08/24 14:32:36
>>363
どうでもいい
365:仕様書無しさん
05/08/24 16:19:29
どうでもよくない！ ｶﾞｼｬﾝ！
366:仕様書無しさん
05/08/24 16:36:01
>>363
お断りだ。
367:仕様書無しさん
05/08/24 17:25:47
とりあえず
オブジェクト -> おっぱい
でいいんじゃない
368:仕様書無しさん
05/08/24 19:19:53
もうこのスレ終わりか。
8なんたらも講義の続きができないみたいだからな。
369:仕様書無しさん
05/08/24 20:43:22
>>363
「派生する, 継承, 拡張」は、「汎化」の逆の方を言うんじゃなかったっけ？
370:仕様書無しさん
05/08/24 20:58:21
派生・継承は「特化」。たしかに汎化とは逆の筈
371:仕様書無しさん
05/08/25 01:05:00
お前ら愚鈍どもに聞きたい
最高ですかーーー？
372:仕様書無しさん
05/08/25 01:08:00
>>362
いや、デスマの原因は営業の交渉能力に依存する。
営業がバカであればデスマは簡単に起こる。うちのバイト先がもろにそうだ。
バイト先を見て思ったが
バカに営業はやらせないほうがええな。
バカに営業やらせるとできないこともすぐできると大嘘ばかりつく。
バカな営業をクビにしたいところだが、そいつ、会社役員なので
それができない。しかも威張ってる。最悪だ。
そのとき思ったよ、
技術がろくに解ってない奴なんかに営業なんて絶対やらせるべきじゃないと悟ったね。
技術が解ってない奴は中身が見えてないから
どんなものでも魔法のようにすぐに簡単にできると勘違いしている。
顧客がバカでも営業が賢ければ多少は救いようがあるのに
営業がバカで威張ってるからこの会社はいつもデスマで土日も休みがない。
しかも残業代は一切無いし(嘲笑
ああ、こんな会社の社員じゃなくてよかったw
373:仕様書無しさん
05/08/25 01:08:29
>>366
UMLに逆らう奴は氏ね
374:仕様書無しさん
05/08/25 01:12:01
UML命名規則が嫌ならJavaキーワードに従おう
拡張, 派生 -> 継承
子クラス, 派生クラス ->サブクラス
基本クラス、親クラス -> スーパークラス
純粋仮想関数 -> 抽象メソッド またはabstractを使って表現
メンバ関数、操作 -> メソッド
メンバ変数、プロパティ、属性 -> フィールド
C#の属性、Javaのアノテーション -> アノテーション または@を使って表現
375:仕様書無しさん
05/08/25 01:15:16
不変クラスの作り方
setterメソッドは使用禁止。
インスタンスフィールドはすべてfinal宣言し
コンストラクタを呼び出した時点で
すべてのインスタンスフィールドへの代入を直ちに完了させる。
getterメソッドを用意する。
メソッドの操作によってオブジェクトの中身が変更されることはあってはならない。
一度生成したオブジェクトは、その後、いかなるメソッドを呼び出しても
メソッド呼び出し後、呼び出し前とでは全く同じオブジェクトになり
Object#equals()を呼び出しても必ずtrueになるようにする。
クラスはfinal宣言する。
376:仕様書無しさん
05/08/25 22:11:08
委譲の話が異常に盛り上がったので、以上で終了します。
377:仕様書無しさん
05/08/25 22:17:18
>>376
頼むから死んでくれ
378:仕様書無しさん
05/08/26 00:02:13
>>377
ブ・ラジャー！！
379:仕様書無しさん
05/08/26 04:25:16
>>376
だめだ。許さん！ ﾋﾞｼｯ! ｶﾞｶﾞｯ!
380:仕様書無しさん
05/08/26 04:26:49
委譲 -> Delegation
集約 -> Aggregation
コンポジション集約 -> Compisition
継承 -> Generalization, Extension, Inheritance
381:仕様書無しさん
05/08/26 23:49:23
>>379
100万円差し上げますのでどうか許してください
382:仕様書無しさん
05/08/28 11:33:26
100万円？
匿名掲示板でそんなこといっても信じねぇぞｺﾞﾙｧ
100万円に相当する情報を匿名掲示板に無料でばらまいてみろ。
マスコミに目が届くほど100万円に相当する力を発揮してみろ。
383:仕様書無しさん
05/08/28 15:22:41
子供銀行券の100万円に決まってんだろうが
何あつくなってんのﾁﾐ
384:仕様書無しさん
05/08/28 17:40:08
なぁ…つまらない奴の存在ってのは罪だと思うんだが、どうだろう。
385:仕様書無しさん
05/08/28 18:38:19
「あぁ、お前のことか」と言う
386:仕様書無しさん
05/08/28 20:29:17
>>385
ちょっと長いよ
387:仕様書無しさん
05/08/29 00:10:24
がっかりだぜ
388:仕様書無しさん
05/08/30 23:39:50
お前らは今までに食ったパンの枚数を覚えているのか？
時は今！
場所はここだ！
389:仕様書無しさん
05/08/31 14:17:27
時は宇宙、所は未来
390:仕様書無しさん
05/08/31 16:19:00
時間と空間は等価ってヤツですね！
391:仕様書無しさん
05/08/31 23:09:32
いや、上手くないし。
なんだその得意げな顔は。
392:仕様書無しさん
05/09/01 03:48:38
やれやれだぜ
393:仕様書無しさん
05/09/01 04:00:32
394:仕様書無しさん
05/09/02 18:57:55
緊急アンケート開始
あなたは
１、クンニ派？
２、指派？
395:仕様書無しさん
05/09/03 17:20:09
３，ちんこ派
396:仕様書無しさん
05/09/03 17:31:46
４．おもちゃ派
397:仕様書無しさん
05/09/03 17:55:25
オブジェクト指向の講義の続きまだー？
398:仕様書無しさん
05/09/03 18:01:08
５．貝合わせ派
399:仕様書無しさん
05/09/04 03:39:48
６、はぐれ刑事、童貞派
400:仕様書無しさん
05/09/04 03:57:03
７．貧乳支持派
401:仕様書無しさん
05/09/04 12:08:50
それは「微乳」と呼ぶのだ
402:仕様書無しさん
05/09/07 15:35:21
8. あなたの尻の穴を舐めさせてください派
403:仕様書無しさん
05/09/07 20:48:01
毎度毎度、迷惑メールはフィルタリングでゴミ箱逝きのメール環境だが、
なんとなくゴミ箱の迷惑メールを見てみたら笑えるのが来たので報告します。
≪日本人以外の女性も多数在籍中≫
※日本在住の女性中心です。
URLﾘﾝｸ(1191.jp)
逆援・エッチなチャットや電話、メール交換・1-対-1 のセックス・秘密の関係・SM調教・女装や男装・・・・・・・から選んでピッタシの女性をお探し下さい。
URLﾘﾝｸ(1191.jp)
お試し登録の方に完全10000万円分差し上げます。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
●NO.I don't veceive your mail●
sweet_as_candy_700@yahoo.fr
●今後、受信を拒否する場合は●
sweet_as_candy_700@yahoo.fr
ちなみに、クリックしてしまうとどうなるか分からないので自己責任乙。
404:仕様書無しさん
05/09/07 20:55:22
> お試し登録の方に完全10000万円分差し上げます。
この部分が意味不明で凄過ぎです。1億円もらえるっぽいです。
405:仕様書無しさん
05/09/18 12:17:30
この前はじめてオブジェクト指向のプログラムの作り方教わったけど
ハッキリ言ってオブジェクト指向ってショボイね。
もっと凄いもんかと思ってた。
406:仕様書無しさん
05/09/18 12:18:03
>>405
いやいや、作るのは大変なんですって。
407:仕様書無しさん
05/09/18 12:21:46
作るの大変だしメンテもそれほど楽とは言えない。
開発者のオナニーの塊がオブジェクト指向ということで結論は出ている。
408:仕様書無しさん
05/09/18 12:23:52
イメージの出来てない人間のやるオブジェクト指向は似非だ
似非オブジェクト指向は本当にひどいプログラムを生み出す
409:仕様書無しさん
05/09/18 13:53:13
>>405
>この前はじめてオブジェクト指向のプログラムの作り方教わったけど
OO を知らずに OOP だけ教わったんじゃあ、話になりませんね。
410:仕様書無しさん
05/09/18 13:59:36
OOPSは教わった
411:仕様書無しさん
05/09/19 18:05:49
＞ OO を知らずに OOP だけ教わったんじゃあ、話になりませんね。
実際には、OOPを習って自分で書いてみて初めてOOが理解できるという構図が一般的。
なぜならOOだけ勉強してもあまりにも概念的過ぎるから。
とりあえずOOPでOOしないで組んでみて、それをOOに直していくっていうのがいまフィリピンで大ブーム。
できる奴ならOOAとOODをやって、OOPはほかにまわす。これが南アでひそかなブーム。
412:仕様書無しさん
05/09/19 19:02:36
まあ、OOだけ知ってるってやつよりはOOPだけ知ってる、ってやつのほうが仕事しやすいけど。
413:仕様書無しさん
05/09/19 19:42:11
「OOP だけ知ってる」 ってやつは大抵 「とにかくクラスを１つでも作れば OOP」 って思ってる奴だと思う
414:仕様書無しさん
05/09/19 20:27:54
んなこたあないだろう。
OOP知ってる、って言う場合、
大抵Javaや.netのプロジェクトにPGとして参加したことがあるやつだろ。
415:413
05/09/19 20:37:13
む、実は学生だからその辺良くわかんない
何というか、俺はみたことあるのよ
クラス１つ作って input, process, output の３つの引数なしメソッドを追加して 「これが OOP だ」 って言っちゃった人を
しかもその人、java の継承については差分プログラミングの部分しか説明して無いし
あれじゃ講義に出た人は、絶対に曲解しただろうに
416:仕様書無しさん
05/09/19 21:57:19
OOだけ知ってる奴→「みかんは果物の継承でだなぁ…」とかいう受け売りを得意げにばらまく。プログラムは組まない。
OOPだけ知ってる奴→C++をベターCとして使う。Javaを関数型言語として使う。
417:仕様書無しさん
05/09/19 22:05:39
>>416
＞OOPだけ知ってる奴→C++をベターCとして使う。Javaを関数型言語として使う。
ごめんよくわかんない
418:仕様書無しさん
05/09/19 22:11:56
OOPってOOも含むんじゃないの？
419:仕様書無しさん
05/09/19 22:15:11
>>416
>OOPだけ知ってる奴→C++をベターCとして使う。
これは出来るが・・・
>Javaを関数型言語として使う。
これは無理。原理的に。
420:仕様書無しさん
05/09/19 22:35:46
DelphiをVisual Pascalとして使う
って言い回しがあったなあ（涙）。
421:仕様書無しさん
05/09/19 23:30:41
>>418
OO を使ってプログラミングすることを OOP と言うんだ
422:仕様書無しさん
05/09/19 23:32:05
OO －継承→ OOP
423:仕様書無しさん
05/09/19 23:34:28
継承じゃないだろ
424:仕様書無しさん
05/09/19 23:35:26
集約？
やっぱ継承じゃね？
425:仕様書無しさん
05/09/19 23:41:27
OOP is OO …… なのか？
OO は概念、OOP はプログラミングテクニックだから、俺は継承じゃないとは思ったが
426:仕様書無しさん
05/09/19 23:41:51
プログラムの側から見れば
プログラム → OO
オブジェクト指向の側から見れば
OO → OOP
切り口をどちらに取るかによって関係が変わるけど
オブジェクト指向は抽象クラスであって
OOPという具体的な形にしないと使えないと思われ
427:仕様書無しさん
05/09/19 23:43:43
＞プログラム → OO
プログラム → OOP
に訂正
428:仕様書無しさん
05/09/20 00:18:16
切り口の意味がわかんないっす
429:仕様書無しさん
05/09/20 00:25:06
クラス分けするときの見方のこと
どういった側面から物事を見るかで
クラスの分け方が変わってくると思う
>>426の例でいえば
プログラムを元に考えるかオブジェクト指向を元に考えるかで
どちらが基本クラスになるかが変わってくる
この辺の考え方はこれで合ってるよね？
430:仕様書無しさん
05/09/20 00:30:13
ごめん。俺の考えと異なるからうまくわかんないわ (-∀-)
俺は最初の段階でプログラムの完成図を OO でマッピングしちゃうから
431:仕様書無しさん
05/09/20 00:32:15
俺も我流だから自信ないんだよね・・・
パス。
432:仕様書無しさん
05/09/22 19:02:38
OOとは～とか、OOが分かったとか、漠然としすぎだよな。
デザパタで無理やりJavaってみて初めてCと違うと気づく。これでいいんじゃね？
433:仕様書無しさん
05/09/22 19:19:44
そだね
434:仕様書無しさん
05/09/23 09:52:25
結局必然性が感じられないから、いつまでたっても理論家の一人よがりに見えるんだろうな。
実際に使ってみれば、本当に綺麗なプログラムってやつが記述できるんだが。
いかんせん、規模がでかくて、構造が複雑で、変更や拡張を前提としているプログラムでないと、
ひたすら「余計な手間」に見えてしまうというのは、確かに効果が見えにくいかも知れない。
見えやすい効果としては、今までライブラリの中に漫然と並んでいた関数郡が、
階層化された構造の中にある、ってだけでも恩恵あると思うんだが。
でもそれで魅力を語ろうとすると、「いや、それはOOの本質じゃない」とか言われるんだろうなｗ
435:仕様書無しさん
05/09/23 11:14:52
＞でもそれで魅力を語ろうとすると、「いや、それはOOの本質じゃない」とか言われるんだろうなｗ
俺はそれが本質だと思う
どんな手法も結局整理整頓の方法の一つだと思う
436:仕様書無しさん
05/09/23 11:34:38
>>434-435
そういう議論になっても、「本質」という言葉の定義が各自バラバラだから
議論がかみ合わないｗ
437:仕様書無しさん
05/10/22 16:48:11
ｽﾚﾘﾝｸ(tech板:5-7番)
438:仕様書無しさん
05/10/27 16:50:37
初心者です。
オブジェクト指向って皆さんはどのようにして勉強されたのですか？
やはり何か書籍とか読んだのですか？
439:仕様書無しさん
05/10/27 16:52:31
何年も掛けて慣れた
440:仕様書無しさん
05/10/27 17:17:00
C++やJAVAを使っているだけでオブジェクト指向と言ってる人もいれば、
ちゃんと考え方まで取り入れて設計している人までさまざまですね。
実際はどちらが多いのでしょうね？
441:仕様書無しさん
05/10/27 17:24:58
絶対に前者
442:仕様書無しさん
05/10/27 17:31:05
>>440
８０：２０の法則に乗っ取ってるかも。かも。
443:仕様書無しさん
05/10/27 17:41:12
UML描ける人はオブジェクト指向してると思っていいのかな？
今、勉強中だけど。。。
444:仕様書無しさん
05/10/27 17:45:39
ゆるさん
445:仕様書無しさん
05/10/27 17:46:42
どゆこと？
446:仕様書無しさん
05/10/27 18:12:10
指向って言葉の意味を考えれば
厳密な定義があろうはずもないじゃないか
447:仕様書無しさん
05/10/27 18:16:13
厳密な定義が無くても、それなりの概念はあると思うのだが。
でなきゃ、OOP言語やら書籍など巷にあふれないもんな。
オブジェクト指向に挫折した人って、
そう言い訳していつも逃げてるのかしら？？？
煽ってんじゃないのよ。
避けてる人、挫折した人の本音が知りたいのよ。
448:1/2
05/10/27 18:29:46
いまさらだが、上がってたのでロボットクラスに関してレス
結局目的が定義されずに分類だけ進んでる事が問題。
public 出るもの 出す() メソッドが、
ロボットたるもの、何かを出せてしかるべきだ。
というコンセプトで設計されているなら、出てくるものが道具でもビームでも置換原則は守れている。
しかし、
ドラえもん：便利な道具を出してマスターを助ける。
ガンダム：宇宙空間で敵と戦う。
のようなコンセプトであるならば、出す()メソッドを抽象化する必要性があまりない。
どちらかというと継承ではなく、ロボットクラスをハードウェアとして、委譲して持っているべきではないか。
449:2/2
05/10/27 18:31:11
実際のOO開発では、現実世界で考えられる振る舞いを全て実装する事はなく、
プロジェクトにあった必要最小限なものだけを実装するわけだが、ここで現実世界とのギャップが出てくる。
たとえば、上の例でロボットを新しく追加したいが、出す()メソッドが必要ない。（出すものがない）といった仕様変更が来た場合どうだろう。
現行のプログラミングでは全てロボットは何かを出せる。として設計してあった場合に困った事になる。
つまり、OO設計とは、現実世界の「一部」を抽出する行為であり、
その一部の範囲に含まれない仕様変更があった場合に破綻をきたす。
しかし大きなプロジェクトほど、ありえない仕様変更が多い。
現実世界を完全に投影できれば最強だが、一部しか実装しない場合は破綻する可能性がある。
ならば変なルールなど作らずに、修正の容易な（影響範囲が少なくてすむ）設計でもいいのではないか？
という意見もなくなくなくなくなくない？と思ったりもする。
450:仕様書無しさん
05/10/27 18:43:51
どこのスレでロボットが出てきたのかと思えば、このスレだったのか。忘れてたな。
＞ロボットたるもの、何かを出せてしかるべきだ。
＞というコンセプトで設計されているなら、出てくるものが道具でもビームでも置換原則は守れている。
『何も出さないロボット』 が登場し、親クラスが想定していない動作……
例えば null を出す場合や、例外を搬出する等を行った時には、リスコフ置換原則は守られていない。
逆に、親クラスで 『何も出さないときには例外を出す』 とか定義しているなら、
実は置換原則は守られていたりする。
# ちなみに、親クラスに 『出す』 が無い場合には、置換原則はそもそも関係ない。
意外と親クラスがどこまで物を考えているかに関係しちゃったりするんだよなぁ。
けど、親クラスの変更は子クラスまで伝播するから、親クラスを改変しないことを第一に考えるべきかと思ったり。
451:仕様書無しさん
05/10/27 19:55:37
>>414
ハッタリC言語厨は>>413に挙げられる例を醸し出す香具師が多いのも事実なわけで
452:仕様書無しさん
05/11/06 04:58:20
ていうか、オブジェクト指向を理解もして無いﾔｼが、
挫折した腹いせに「OOPは無駄」とか必死に言ってるのがｱﾜﾚｿｽ。
453:仕様書無しさん
05/11/06 13:00:53
>>452
…と、ﾏﾙﾁしてる君の方が必死に見える。
454:仕様書無しさん
05/11/06 13:15:07
まあ、ダメな人間ってのは、何をやらせても自分のせいではなく、周りのせいだと思うものだし。
自分の置かれている状況と、チーム内の人間と、開発体制と仕様書にけちつけて自己弁しつづけるよな。
455:仕様書無しさん
05/11/14 13:15:43
オブジェクト指向プログラミングの場合、
マスターファイルをトランザクションファイルで更新するというプログラムは
どうやって組むんですか？
456:仕様書無しさん
05/11/14 14:35:45
仕様による。
457:仕様書無しさん
05/12/26 11:53:40
あんなにクリスマス～って騒いでても、
一瞬の出来事だったね。
今度は大晦日～って盛り上がるんだろうけど、
来週の今頃って、もう来年だよ。
それも、既に元旦過ぎてる。
458:仕様書無しさん
05/12/29 01:45:24
『オブジェクト指向でなぜつくるのか』
つー本読んだが・・・やっぱ理解できない
このシリーズの中でこの本だけ判り難いとおもた
今日
459:仕様書無しさん
05/12/29 16:18:16
とりあえず、このスレ見ててオブジェクト指向が理解できて無い奴は
憂鬱本は読んだ上で言ってるんだよな？
460:仕様書無しさん
05/12/29 16:19:06
つーか、次回から最低でも憂鬱本の紹介はテンプレに入れろ。
461:仕様書無しさん
05/12/29 19:16:21
憂鬱本って？
462:仕様書無しさん
05/12/29 19:36:19
ぐぐったら１・２・３番目に出てくるじゃないか
463:仕様書無しさん
05/12/29 19:36:23
>>461
URLﾘﾝｸ(tito.fc2web.com)
URLﾘﾝｸ(tito.fc2web.com)
憂鬱なプログラマのためのオブジェクト指向開発講座 ― C++による実践的ソフトウェア構築入門
Tucker (著)
翔泳社(1998) ISBN:4-8813-5619-4
デザパタはあくまでパターンなのでオブジェクト指向の理論とは関連が薄いから
実質2ch一番人気のオブジェクト指向本となる。
464:461
05/12/29 20:03:53
サンクスです
アマゾンの書評みたら。。。
『全米が泣いた！！』みたいな感じでｗ
明日から読んでみよう
でもってまだわかんなかったら
ここに粘着
465:仕様書無しさん
05/12/30 11:26:57
古め（？）の本が多いみたいだから
モダンな ooもどうぞ
例えば
URLﾘﾝｸ(www.amazon.co.jp)
466:仕様書無しさん
05/12/30 11:28:46
オブジェクト指向なんて全然大したこと無いよ
ようは関数の概念をちょっと弄って使いづらくしただけ
オブジェクト指向考えた奴ってアホだな
467:仕様書無しさん
05/12/30 13:11:14
>>466←こういうのもう相手にしなくていいっしょ？ｗ
468:461
06/01/03 15:08:24
憂鬱本読み終わりました
目から鱗でした
でも、図が書けない実装できない
急に面白くない状態になりました
469:仕様書無しさん
06/01/06 06:55:37
アナリシスパターンとかよく使うんですか？
470:仕様書無しさん
06/01/06 09:53:37
仕事で？使わないよ
471:仕様書無しさん
06/01/06 19:29:36
アナル挿すパターン
472:仕様書無しさん
06/01/06 21:25:37
イベントドブリン型も知らないで何がオブジェクト指向だか・・
最近の若いプログラマーは流行だけを追いかけて頭でっかちで全然使い物にならん
473:仕様書無しさん
06/01/06 21:29:22
ドブリンかい
474:仕様書無しさん
06/01/06 23:15:51
全然関係ないけどドリブンってドライブの過去分詞だけど、
微妙に直感的じゃないんだよな。
イベント駆動とかイベントドライブとかの名前にしたほうが全然わかりやすかったと思う。
厨房のころ「イベントドンブリ？なんかよくわかんね」って投げ出した思い出あり。
475:仕様書無しさん
06/01/06 23:19:29
>>474
>イベント駆動とかイベントドライブとかの名前にしたほうが全然わかりやすかったと思う。
安心しろ。
それは、お前に説明する為に作られた言葉ではないから。
476:仕様書無しさん
06/01/06 23:42:28
イベントドブリン型も知らないで何がオバジェクト指向だか・・
最近の若いプログラモーは流行だけを追いかけて頭とっかちで全然使い物にならん
477:仕様書無しさん
06/01/06 23:47:32
今時イベントドリブンを知らんプログラマなんかいるのか？
478:仕様書無しさん
06/01/06 23:49:08
だから、
イベント【ドブリン】じゃなくてイベント【ドリブン】だって。
まぁ、コピペの釣りだからしかたないか。
479:仕様書無しさん
06/01/06 23:49:35
イベント丼か
480:仕様書無しさん
06/01/06 23:49:51
>>477
あまりにもありふれすぎててその名前を聞かないだけだと思うんだが。
481:仕様書無しさん
06/01/07 00:39:50
きちんとインストロールしないからだ
482:仕様書無しさん
06/01/07 00:50:48
>>476
たしかに自己満足のコード書いて自慢する新人が増えてるね
俺の配下からは追い出してやったけど
483:仕様書無しさん
06/01/07 01:15:08
イベントドンブリ
484:仕様書無しさん
06/01/07 09:36:57
>>1
とりあえずどんなOSでもいいからGUIシステム実装してみろや、出来上がるころには確実に身についているはず。
485:仕様書無しさん
06/01/08 16:56:05
つか、何故オブジェクト指向スレにきてイベント丼の話をしだすのか不明。
あんなの適当にめっさげが降ってくるだけじゃん。
スウィッチケースでテキトーにわけて処理核だけじゃん。
何えばってんの？この人。
頭弱いんじゃない？
豆腐だな豆腐。
486:仕様書無しさん
06/01/08 18:39:11
>>485 m9（＾Д＾）ﾌﾟｷﾞｬｰ
487:仕様書無しさん
06/01/10 11:36:50
>>485
>あんなの適当にめっさげが降ってくるだけじゃん。
めっさげてｗ
マッサージの読み方も知らんのかｗｗ
488:仕様書無しさん
06/01/10 14:17:30
うますぎて付いていけん
489:仕様書無しさん
06/01/10 14:44:23
「冬厨になりきって冬を満喫するスレ」かと思った
490:仕様書無しさん
06/01/10 16:09:00
自分は、「降ってくる」ではなくて「上がってくる」という感覚なのですが。
491:仕様書無しさん
06/01/10 19:34:50
>>490
マジレスですか？
Win32APIをベタで書きで、「降ってくる」ようなイベントの記述もあったような希ガス(めちゃ汚いソースだが)
じゃばらーのイベントのイメージはやっぱり「上がってくる」って感じ？
492:仕様書無しさん
06/01/10 23:03:24
「上がってくる」のは例外かな・・・
俺は後で呼んでもらうために参照を渡しておく程度の感覚しかない
493:仕様書無しさん
06/01/31 09:03:26
エロで検索してたら良スレﾊｹｰﾝ
494:彦麻呂
06/02/26 20:08:09
うわぁーーー
プログラムの 分割民営化やー
495:仕様書無しさん
06/03/23 14:11:05
オブジェクト指向を理解できないやつは、どんな仕事も非効率な無能人間。
496:仕様書無しさん
06/03/23 23:27:03
コボラーのことか？
497:仕様書無しさん
06/03/24 01:05:59
うわぁーーー
プログラムのノルディック復号や
498:仕様書無しさん
06/03/24 02:16:24
うわぁーーー
プログラムの年末工事や
499:仕様書無しさん
06/04/23 15:28:47
ロボットの話に戻るけど、
顧客から「ガンダムやドラエモンからも白い物を出させたい」って
言われたらどうするの？
500:仕様書無しさん
06/04/23 15:37:31
ロボットクラスの出るものをコレクションにすればいいのかな？
これだとスーパークラスを変更しなくちゃならないけど。
501:仕様書無しさん
06/04/23 17:06:35
「これ、何に見えます？」
「えぇ～っ飛行機をロボットにぃ！？」
502:仕様書無しさん
06/04/23 22:03:18
>>501
二重継承ですか。
503:仕様書無しさん
06/04/24 11:05:41
>>499
しごく
504:仕様書無しさん
06/04/24 22:10:25
白いものって、白けりゃ何でもいいのか？
煙くらいなら、デフォでガンダムとか出るんじゃまいか？ｗ
505:仕様書無しさん
06/06/13 01:03:37
トラックバック:URLﾘﾝｸ(app.blogs.itmedia.co.jp)
脱オブジェクト指向のススメ
URLﾘﾝｸ(blogs.itmedia.co.jp)
このイーキャッシュの代表取締役玉木の発言がおかしいから
このスレからpinする。
オブジェクト指向のことをまったくわかっていません。
というか、かなり勘違いしています。
そのくせにオブジェクト指向を否定しています。
あまりにも突っ込みどころが満載です。
これで代表取締役が務まるのですから
思いっきり叩いてやっちゃってください
506:仕様書無しさん
06/06/13 11:42:23
>>505
「IT」業界の人の言う事ですから
コンピュータ業界とは違う常識があるんでしょう。
507:仕様書無しさん
06/06/14 22:48:06
読みやすいプログラムとか、拡張しやすいプログラムにしようとすると
知らないうちにオブジェクト指向的なものになることが結構あるんだがな・・・
508:仕様書無しさん
06/06/15 00:31:31
>>505
んー結構あってんじゃない？
なんか間違ってる？
なんか最近オブジェクト指向って言葉を拡大解釈してる奴がいてうざいけど
オブジェクト指向自体は何も生まんし、生産性なんかあがらんし、再利用なんて狙ってないし、
ただ、ただ、単にオブジェクト単位でクラス作ろうぜってだけなんだけど。
なんか、これ以外の意味をもたせることに必死なボーヤがいるようなんだよね。
オブジェクト指向自体はオブジェクト単位でクラス作るってただそれだけしか説明してないし、
こう作るとうまくいくっぽいよ。マジで。としかいってない。
なにせ、しょっぱなはシミュレーション用に作られたもんでオブジェクトごとに作るといいっぽいよってホントただそれだけで
別に何がどうとかカニがどうとかそんなもんはこれっぽっちもなかったはずだよ。
509:仕様書無しさん
06/06/15 09:11:18
>>508
ラリった中年のような文章だ。
510:仕様書無しさん
06/06/15 20:21:17
508は最初の最初は避妊に失敗して産まれたんだけど、
そのうちに偉大な人間になるようにと願をかけられて、
結局今のていたらくがあるわけだ。
511:仕様書無しさん
06/06/15 21:52:30
508が痛すぎる件について
ネタか釣りかコボラーだよな、な？
512:おじゃばさま
06/06/16 09:11:47
オブジェクト指向で再利用を狙っていない？
確かにオブジェクト指向を信仰している奴は多いが、再利用を狙っていないと言うのはおかしいな。
元々は再利用のための技術だぞ、それも「Windowプログラム」のな。
構造化CでWinやXのWindowアプリケーションをつくってみろ、そうすれば分かる。
今はそれが他のプログラムにも転用されているがな。
513:仕様書無しさん
06/06/16 09:38:06
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(www.rubyist.net)
オマエラが好きそうな厨房系天才プログラマの２人も同じようなこと言ってるけど
これについてはどう思うんだ？
514:仕様書無しさん
06/06/16 21:26:07
やねうらおは所詮8bitアセンブラで思考が止まっちゃったような人だからな～・・・
515:仕様書無しさん
06/06/16 21:32:15
>>512
嘘吐くな。
オブジェクト指向は元々はシミュレーションのためのもの。
再利用しやすいってのはあくまでおまけ。
516:仕様書無しさん
06/06/16 22:23:40
再利用つうのは大昔からソフト業の悲願なんだよ。
おまけであろうがなかろうが「再利用可能」つうのは
何よりも大きなウリなんだ。
もちろん「可能である」ということは
「誰にでも再利用可能なものを作る事ができる」
という事では無いことは御承知だと思うけど。
517:仕様書無しさん
06/06/16 22:34:42
>>516
それ、お前の勝手な考えだろ？
再利用なんてのはプロジェクトが完全に終わってからでないと
それがよかったか悪かったなんて判断できないだろ。
ＡクラスとＢクラスの両方で使われているＣクラスが
プロジェクトの最後までＡクラスとＢクラスの両方で使われる保障なんてそうそうあるもんじゃない。
ちょっとした仕様変更で
Ａクラスで必要なＣクラスとは似て非なるＡＣクラス、
Ｂクラスで必要なＣクラスとは似て非なるＢＣクラスが
いつどういう形で必要になるかは正直予想できない。
このとき、ＡＣとＢＣが共通のつもりで使っていたＣクラスを継承することで
できるかどうかだってやっぱりわからない。
また、再利用ができたって、だからどうしたって思うんだがな。
具体的に何がどういいんだ？
メリットとそれと同じ数のデメリットを抱えるだけの話であっていいだけでは終わらない話だと思うんだがね。
ただ、まったくやらないという話ではなくて、あくまでシステム的に自然とそうなるものであって
再利用を狙ってやるようなことは「俺は」無いけどね。
518:仕様書無しさん
06/06/16 23:05:08
>>517
>それ、お前の勝手な考えだろ？
匿名掲示板は自分が思う事を書く場所さ。
「勝手な考えだ」と思うならそう思いなさい。それはお互い様だ。
OOPLを広める為に「これは再利用可能なプログラムを書くことができます」
という表現が多用されたのは事実だよ。
>具体的に何がどういいんだ？
俗に言うアプリケーションコンテナを使った事はありますか？
519:仕様書無しさん
06/06/16 23:09:37
>>518
質問に質問で返すアホとは会話できません。
520:仕様書無しさん
06/06/16 23:56:13
一つのファイルで複数のオブジェクトプログラムが作れる→なんか楽→ｳﾏｰ
という漏れの考えは間違ってますか？
521:仕様書無しさん
06/06/17 00:42:37
オブジェクト指向って、別に具体的なメリットを求めてるわけではないと思う。
手続き型よりオブジェクト指向のほうが直感的だと思う人がいて、そして
そういう人たちにとって直感性に優れることから、派生的になにがしかの
メリットが得られるという感じ。
522:仕様書無しさん
06/06/17 01:00:05
>>521
そうそうそんな「感じ」。
その「感じ」ってのをつかむのが一部の人間にとっちゃ難しいってのがオブジェクト指向だと思うんだよね。
はじめシミュレーションで活躍してたってところからなんとなくイメージしてみてよって感じだが。
ホント大事なのはこの「感じ」って部分だと思う。
523:仕様書無しさん
06/06/17 11:28:47
>>515
>オブジェクト指向は元々はシミュレーションのためのもの。
と強弁してるのは多分君だけ。
事実だとしても、「元々」 が今の話にどう関係してくるんだ？
524:仕様書無しさん
06/06/17 13:35:50
>>523
なにそれ？
今と昔でオブジェクト指向の意味が違うとか言い出す気？
525:仕様書無しさん
06/06/17 13:46:03
>>523
URLﾘﾝｸ(ja.wikipedia.org)
これが最初だボーヤ。
526:仕様書無しさん
06/06/17 13:51:20
>>524
十数年も経てば違って来ているとしても不思議はない。
増してや、お前のいう「シミュレーション」以外に応用しようとするなら。
527:仕様書無しさん
06/06/17 13:52:45
…Simula かよ…
そりゃ OOPL の始まりであって
OO の最初じゃないだろうに。
528:仕様書無しさん
06/06/17 14:00:01
>>526
じゃあ、何を規準に正しいとするわけ？
まあ、変わったと主張するとしても今と昔でどう変わったのかも知っておいたほうがいいんじゃないの？
俺は最近のオブジェクト指向を唱える奴ってのは
はっきりいって勘違いした、間違ったままのことを言ってる奴が多いと思うね。
まあ、雑誌とかでも平気でそういうことが書かれてるからそれが正しいと思っちゃうのかもしれんけど。
いま、ものすごくごちゃごちゃになってるよね？
オブジェクト指向って結局なんなの？ってのがわからないのをいいことにみんながみんなテキトウなこと言ってるから。
始めは
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、というものである。
気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
ってことなんだよ。
そんな難しいこと書いてないだろ？
もしかしてちょっといいんじゃね？程度だ。
別に開発期間がどうだとか、再利用がどうだとか、そこまで計算されてねぇよ。
529:仕様書無しさん
06/06/17 14:01:10
>>527
はぁ？ちゃんと読んでよ。
なお、Simula当時「オブジェクト指向」という言葉はまだない。
この用語はアラン・ケイがSmalltalkの概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味ではSmalltalkが世界最初のオブジェクト指向言語であり、
Simulaは「オブジェクト指向として再認識が可能な最古の言語」ということができる。
530:仕様書無しさん
06/06/17 16:55:28
>>529
そうだね。クラスやオブジェクトは、実はオブジェクト指向とは関係ないところで考え出された。
ストラウストラップは C に「Simula のクラス」を使って、抽象データ型、つまり、ユーザーが型を
定義できる機能を付加した。これがオブジェクト指向プログラミングのスタート。
それとは別にアラン・ケイの「メッセージング」というパラダイムに基づくオブジェクト指向がある。
この２つがごっちゃにされているから、言語間宗教戦争とか、おかしなことになるんだ。
URLﾘﾝｸ(d.hatena.ne.jp)
「オブジェクト指向の概念の発明者は誰ですか？」
531:仕様書無しさん
06/06/17 17:23:39
アランケイのオブジェクト指向とSIMULAのオブジェクト指向は別物だな。
アランケイのオブジェクト指向はなんか複雑なだけで恩恵は無い気がする。
532:仕様書無しさん
06/06/17 17:26:34
俺はストラウストラップ自身もSIMULAのオブジェクト指向（？）は理解できてなかったと思うけどね。
なんかいってること違うしね。
533:仕様書無しさん
06/06/17 18:59:03
いや。理解するも何も、Simula にオブジェクト指向はないんだって。
クラスやオブジェクトを拝借したストラウストラップがリスペクトして「オブジェクト指向言語」だと
言っているだけで。本当は、彼のオブジェクト指向にてらしても、Simula はその範疇にない。
534:仕様書無しさん
06/06/17 19:00:53
>>531
アランケイのオブジェクト指向は単純だと思う。なんでもメッセージ、それだけ。
あえて難しくいうと、疎結合とか、徹底した動的性なんだけど、まあいいや。
535:仕様書無しさん
06/06/17 21:30:24
>>533
いや、でも>>528の気体分子の例は明らかにオブジェクト指向だと思う。
これをオブジェクト指向といわずに何をオブジェクト指向と呼ぶのか？ってぐらい。
536:おじゃばさま
06/06/20 08:14:01
>528
とても参考になりました。
528の言う事が非常に納得できるので、シミュレーション派に寝返らせていただきます。
シムラ万歳！！
537:仕様書無しさん
06/06/21 13:07:17
Cでオブジェクト指向プログラミングするとしたらどうなるのよ
ひとつの処理をファイルに纏めるの???
グローバル変数をstaticで宣言するの???
set_**** って感じで上の変数に入れるの???
教えて
538:仕様書無しさん
06/06/21 13:09:47
>>537
// コンストラクタ
FILE* fopen(const char* filename, const char* opt);
// デストラクタ
int fclose(FILE* fp);
539:537
06/06/21 13:26:18
なるほど
例えば リスト処理の時もあちこちにコードを書かないで
add()
del()
と書けばいいのですね?
リストからtitleの値を取り出すとき
get_title(list)
とするか
list -> title
とするかどっちがいいですか?
540:仕様書無しさん
06/06/21 15:22:51
知らんがな
541:仕様書無しさん
06/06/21 15:48:45
晒しage
542:537
06/06/22 11:02:55
回答待ちage
543:sage
06/06/22 14:26:24
sage
544:sage
06/06/22 15:27:35
sage
545:仕様書無しさん
06/06/22 19:58:11
>>542
別に普通にできるじゃん。
そんなのもわからないならはやく死ねよ。
546:仕様書無しさん
06/06/22 21:12:07
>>542
あーお前さんの言う
「オブジェクト指向プログラミング」
ってのが何を想定してるのかがわからんのだが
データとメソッドの融合は無理すりゃCでもできるけどメリットない
けど「オブジェクト指向設計」は十分Cでもメリットある
無論「オブジェクト指向言語」を使ったほうが
設計と実装の乖離が少ない分メリットは大きいが
547:仕様書無しさん
06/06/22 23:21:18
URLﾘﾝｸ(www.sage-p.com)
548:仕様書無しさん
06/06/22 23:50:54
>>542
こんな感じで構造体の中身を外部から隠して抽象データ型を表現するのは、
オブジェクト指向が流行る前からあったテクニックだよ。
ヘッダファイル(list.h)
typedef struct list *LIST;
LIST list_make(初期化パラメータ);
int list_free(LIST);
char *list_title(LIST);
int list_add(LIST, x);
int list_delete(LIST, x);
本体ファイル(list.c)
struct list
{
char *title;
…;
};
char *list_title (LIST l) { return l->title; }
int list_add (LIST l) { … }
int list_delete (LIST l) { … }
549:537
06/06/23 10:16:44
よくわからんが
>>538
みたいな感じで書けばいいの?
550:仕様書無しさん
06/06/23 14:17:00
>>549
Cでオブジェクト指向風のコードを書くなら、Cの構造体はC++のように必要なメンバ変数だけ
隠したり公開したり出来ないんで、パフォーマンス的にシビアな場面でない限り、>>539の前者のように
実装は完全に隠して関数を通してだけアクセス出来るようにしたほうが安全で変更に強い。
551:仕様書無しさん
06/06/23 14:48:53
>>550
C++ でいう viratual を実装するのに 関数へのﾎﾟｲﾝﾀをﾒﾝﾊﾞに持たせたことはあるが…
直接呼出しの obj_ptr->func() よりも、
関数呼び出しｽﾀｲﾙの func(obj_ptr) で記述するほうが、間違えﾄﾗｯﾌﾟしやすいしね。
設計&整理の手法を真似て、記述法は真似ない というあたりが落とし所かな？ と思った
# 単継承限定でも C++ to C ｺﾝﾊﾟｲﾗ があれば良かったんだけどね…
552:仕様書無しさん
06/06/28 06:09:46
age
553:仕様書無しさん
06/06/28 21:09:10
>>551
ポインタの保持はグローバル変数やgotoと並ぶ大罪だぞ。
javaはこれを無くすためにごちゃごちゃやってあるが、
逆にインスタンスがよくわからなくなって失敗してるがｗ
554:仕様書無しさん
06/06/29 06:45:53
>>553
ﾊｧ?
555:仕様書無しさん
06/06/29 06:56:49
>>553
ゲームだとDirectXでD3DDeviceを各クラスで保存しちゃって
Alt+Tabでロストしたとき、どうしようもなくなっちゃうお馬鹿なプログラムがよくある。
556:仕様書無しさん
06/06/29 11:06:16
ヒープ(?)を指すポインタとstaticな関数ポインタを
ごっちゃにしてしまうような人が来るのは、
やはり無闇にageた所為でしょうか?
557:仕様書無しさん
06/06/30 03:11:45
>>556
すいません。>>553の「ポインタの保持」だけに脊髄反射しました。
558:仕様書無しさん
06/08/18 00:54:46
ネットで「オセロをオブジェクト指向で考える」と言うのをよく見かけます。
盤面オブジェクトってのが出てきて、石の状態は盤面オブジェクトが管理
していたりします。
プレイヤーオブジェクトの役割といえば、次の一手を考えるだけです。
不自然じゃないですか？
現実世界では、石の管理もルール解釈も次の一手もプレイヤーが行います。
このギャップは何なのでしょうか。
このギャップがオブジェクト指向の理解を妨げているのではないでしょうか。
559:仕様書無しさん
06/08/18 01:33:28
世界の切る際に、切ることに何を求めるか。
大抵は ある程度の規模・期間で作るときのコスト低減を狙うと思うので
それを実現するために（多様な）プレイヤ実装を念頭において
盤面オブジェクトに 現実にはプレイヤにある機能を移すんじゃないかなと。
560:仕様書無しさん
06/08/18 07:18:59
>>558
それは動作じゃね？
まず、設計時点ならそれぞれの情報を
各オブジェクトが内包している状態さえクラスで表現できればいい。
例えば盤に並んでるオセロの石が表か裏か配置されているかどうか
配置されてるならどこに配置されてるかってのを表現できればいい。
>プレイヤーオブジェクトの役割といえば、次の一手を考えるだけです
>現実世界では、石の管理もルール解釈も次の一手もプレイヤーが行います
これはセンスだな。
オブジェクト指向ってのはあくまでできるだけオブジェクト単位で処理するってことしかいってない。>>525参照。
つまりクラスにわけた時点でオブジェクト指向は終わっている。
別にわかり易くなるならプレイヤーと審判、オセロの石管理者みたいなのを用意してもいい。
561:増殖するオブジェクト
06/09/02 13:39:26
オブジェクト指向とは何か？
宗教です。
562:増殖するオブジェクト
06/09/02 13:42:51
これからは自律オブジェクト指向の時代だよ？
オブジェクトは意思を持ってます。
オブジェクトは自らのバイナリイメージを書き換えて成長します。
でも、環境の変化に弱く、環境(CPU)が変わると息絶ることがあります。
563:増殖するオブジェクト
06/09/02 13:45:48
自律オブジェクトは生みの親の顔を覚えています。
親の電子証明書を期限切れにすると成長が止まります。
ウィルスではありません。
自律品種改良です。
564:仕様書無しさん
06/09/02 16:12:06
全く無知の俺が
２ヶ月でC++をマスターする。
その為に独習C++と言う本を買って来たぜｗ
さぁて早速始めてみるか…
つかCは飛ばしたけどこの本の内容…理解出来るかな…
565:仕様書無しさん
06/09/02 16:33:53
>>564
出来るよ。マスター出来ないとは思うけど。
一通り読み終わるには２ヶ月で十分な時間だよ。
で、それから、いろいろ作るうちに少しずつ理解できるからがんばれ～って俺は思う。
566:仕様書無しさん
06/09/02 17:37:39
>>564
なんで憂鬱本買ってこなかったんだ。
URLﾘﾝｸ(www.amazon.co.jp)
人気書籍ぐらい調べてから勉強はじめろよ。
567:仕様書無しさん
06/09/02 17:52:22
憂鬱本はC++をマスターするための本じゃないし。
568:仕様書無しさん
06/09/02 17:56:41
>>567
色んな本を読むべきだと思うよ。
色んな本を読むのはいいことだ。
物事を色んな視点から見る目を養ってくれる。
１つの本だけを集中的に読んでもそれは１人の人間だけの考えを深く知るに過ぎない。
569:仕様書無しさん
06/09/02 18:41:26
>>565
この本Cを読者が知ってる者とします…
って書いてあったが大丈夫かな…
まぁ頑張ります
>>566-567
オブジェクト指向がなんたらって奴はこの本読み終わったらやろうと思う
>>568
㌧
色んな本を読んでみるよ
頑張ります！
570:仕様書無しさん
06/09/02 18:48:30
>>569
本の読み方が下手糞。
はじめに２～３冊買って見比べながら読むのが効率のいい読み方。
571:仕様書無しさん
06/09/30 02:27:51
>>565
君の書き込みを読んで俺は、ふーんと思った。
572:仕様書無しさん
06/09/30 17:35:49
「脱オブジェクト指向のススメ」
URLﾘﾝｸ(blogs.itmedia.co.jp)
573:仕様書無しさん
06/10/01 00:14:34
>>572
玉木 栄三郎 （ たまき えいざぶろう ）
イーキャッシュ株式会社代表取締役。
創業に技術担当非常勤取締役として参加するもその後経営不振により、製品開発、営業を担当するようになり、気が付けば代表取締役に。
業績のV字回復を達成するも、株主と社員に挟まれる中間管理職として日々苦悩している。
略歴など
1972年。香川県生まれ。
麻布大学獣医学部獣医学科卒（獣医師免許取得）
東京医科歯科大学医学部大学院博士課程修了（学位取得セズ）
動物病院勤務医、フリーランスエンジニア、大手メーカーなどを経て現職。
2006年1月より、Microsoft Regional Director に就任。
574:仕様書無しさん
06/10/07 02:04:25
最近参画したプロジェクトでは、
データを保持するクラスのメソッドはgetterとsetterのみが許されていて
値をいじるのは制御側という構造になってて
ちょっと萎えた
575:仕様書無しさん
06/10/12 20:34:26
VBでボタンクリックしたらクリックイベントが実行されるだろ
それがイベントドリブンだ
576:仕様書無しさん
06/10/16 02:25:30
腹をくだすと下痢になるだろう。
それがトイレットゲリベンだ。
577:仕様書無しさん
06/10/16 02:45:31
びみょ
おもろない
578:仕様書無しさん
06/10/27 22:16:21
>>572
その内容は、なんちゃってオブジェクト指向マスターに対する皮肉だと思われ。
579:仕様書無しさん
06/11/02 10:52:09
きのうオブジェクト指向が理解できた
半年かかった
580:仕様書無しさん
06/11/02 11:50:45
>>1
感謝するぜ。
大昔にＣ言語をちょとかじって構造化やカプセル化といったことは
概念的に理解した後、しばらくＶＢ漬けになってんで
いわゆるオブジェクト指向の考え方がとんとわからない
浦島太郎状態だったんだけど
なんとなく色々理解できてきたよ。
なんていうか新しい概念とかそういう捉え方ではなく
何々の発展形って表現してもらえると非常に自分には
わかりやすい！
とにかくありがとさん！！！
581:仕様書無しさん
06/11/07 14:23:38
>>528
>>530
参考になりました。
オブジェクト指向プログラミングに関する理解、知識が深まりました。
582:仕様書無しさん
06/11/12 11:05:47
オブジェクト指向で重要なんは、
Ｃだろうが、Ｃ＋＋だろうが、Ｃ＃だろうが、
ＶＢ（ここじゃ.netに限定）だろうが、
１ソースファイルには機能に限定したもんしか、
書かんことが重要や
その意味ではクラスを定義できる言語は
綺麗なソースになりやすいんや
Ｃはグローバル変数をexternするなんてことすると
読みにくてかなわん
583:仕様書無しさん
06/11/12 11:28:09
そんなアセンブラの時代から当然の、オブジェクト指向と何の関係もない話を
何を得意げにいってるんだろうな。
いや、というかexternが問題だという奴初めてみたよ。w
それが問題なら最初からファイルスコープっていう概念がないC#とかVBは
もっと問題じゃん。
584:仕様書無しさん
06/11/12 12:05:50
>>583
お前も得意気だな
585:仕様書無しさん
06/12/09 13:27:34
素人が作ったソースのカプセル化、隠蔽にメリット無し。
586:仕様書無しさん
06/12/16 20:30:01
それやってるうちに学んでいって上達していくんだから、
メリットなしというのは本末転倒。
587:仕様書無しさん
07/01/01 00:10:40
同意
588:仕様書無しさん
07/01/01 13:24:07
間違いに気付かずにそれを覚えられたら大変だな。
メリットなしというより、大きな賭けなのでは？
589:仕様書無しさん
07/01/02 01:23:09
どんな奴でも多かれ少なかれ間違って覚えてることはあるよ。
経験を積むうちに勝手に修正されていくから無問題
590:仕様書無しさん
07/01/04 19:55:17
OOに固有の話題ではないな
591:仕様書無しさん
07/01/27 22:35:57
クラス図を描ける便利なフリーウェアってあれば
教えてください。
592:仕様書無しさん
07/01/29 11:21:15
新Visual C++6.0入門 シニア編 林晴比古/著
新C言語入門 ビギナー編 林晴比古/著
を新入社員に薦めている会社ってありますか？
593:仕様書無しさん
07/01/29 11:40:55
>新Visual C++6.0入門 シニア編
新C言語入門 シニア編
です。
594:仕様書無しさん
07/01/29 12:11:07
>>593
うちの会社では「新Visual C++ .NET入門シニア編」を使ってます。
595:仕様書無しさん
07/01/29 18:24:13
何人かの知人に聞いたところ、
私のところもそうですが、林晴比古シリーズ使っている人が
多かったです。（なんで？そんなに良書なの？）
596:仕様書無しさん
07/01/29 20:06:46
ウチはハルヒ子禁止。
597:仕様書無しさん
07/01/30 18:54:39
>>596
何故？禁止にするのか！
598:仕様書無しさん
07/01/31 06:55:21
>>595
次のステップにいけない本だけどなｗ（書いてる本人が一番わかってるだろうけど）
とりあえず、使うだけだけどＭＦＣはそれじゃ組めない。
ちょっとだけ遠回りになるけどＷｉｎ３２ＡＰＩでのプログラムを理解しないとすぐにドツボにハマル。
本当にＶＣ＋＋が組めるようになりたいなら
「猫でもわかるWindowsプログラミング」がいいと思う。
何度も何度も理解できるまで繰り返し読むといいと思う。
599:仕様書無しさん
07/02/05 10:45:41
>>598
猫から出発した俺はいまだに MFC 使えない…
Doc View 構造を強要されるのが好かんな。