なぜオブジェクト指向は嫌われているのか？3
なぜオブジェクト指向は嫌われているのか？
http://pc11.2ch.net/test/read.cgi/prog/1183255047/
なぜオブジェクト指向は嫌われているのか？2
http://pc11.2ch.net/test/read.cgi/prog/1184258633/
スレ違い多発注意。
・教育論
煽りは華麗にスルー推奨。
http://pc11.2ch.net/test/read.cgi/prog/1183255047/
なぜオブジェクト指向は嫌われているのか？2
http://pc11.2ch.net/test/read.cgi/prog/1184258633/
スレ違い多発注意。
・教育論
煽りは華麗にスルー推奨。
|
|
|
2 ：仕様書無しさん：2007/07/26(木) 00:43:27
好きですけど？
オブジェクト指向を導入してる、という現場で見たのは、
わからんちんが混乱して、理解してる奴のフォロー負荷が高かったということ。
わからんちんが混乱して、理解してる奴のフォロー負荷が高かったということ。
4 ：仕様書無しさん：2007/07/26(木) 00:59:40
やっぱ、OOよりC言語でカーネル、デーモンいじりほうがめがっさいいだろ。
ま、>>１ 乙
ま、>>１ 乙
5 ：仕様書無しさん：2007/07/26(木) 01:04:21
よくわからんが、オブジェクト指向は嫌われているのですか？
１、どの辺が嫌われているのか？
２、オブジェクト指向にプラスはないのか？
３、非オブジェクト指向言語ですべて丸く収まるか？
４、引田テンコウはなぜ打撲だったのか（八つ裂きにされていたのならわかるが）？
１、どの辺が嫌われているのか？
２、オブジェクト指向にプラスはないのか？
３、非オブジェクト指向言語ですべて丸く収まるか？
４、引田テンコウはなぜ打撲だったのか（八つ裂きにされていたのならわかるが）？
6 ：仕様書無しさん：2007/07/26(木) 01:14:45
長らく OOP 信者だったが関数型言語に開眼した。
別に嫌いになったわけでもないんだが。
別に嫌いになったわけでもないんだが。
関数型とかって言い方ならOOも関数型。
OOと非OOの違いは、
責務や役割に着目して作るのか、機能に着目して作るかの違いだけ。
OOと非OOの違いは、
責務や役割に着目して作るのか、機能に着目して作るかの違いだけ。
最近このスレめっさ盛り上がってんな
どうしちゃったんだ一体
どうしちゃったんだ一体
>>9
それは。OOというプログラミングのパラダイムがあって。
そのパラダイムの特性のひとつの「理解の深さが多層的であること」が原因だ。
だから「何年か前には俺もこのように考えていたなぁ」と思えるレスがスレ内にあふれ、
そう思ったPGに「レスつけてみよう」という衝動が湧くわけだよ。
それは。OOというプログラミングのパラダイムがあって。
そのパラダイムの特性のひとつの「理解の深さが多層的であること」が原因だ。
だから「何年か前には俺もこのように考えていたなぁ」と思えるレスがスレ内にあふれ、
そう思ったPGに「レスつけてみよう」という衝動が湧くわけだよ。
アホコテが突っ込みどころが満載のアホレスをするからじゃねーの
人それぞれ違う事言うからじゃない？
13 ：仕様書無しさん：2007/07/26(木) 08:52:51
オブジェクト指向が嫌われてるわけじゃなく、
あんちも信者も、それを特別と思ってる人が嫌われてるだけ。
あたかも魔法のように思ってたり、禁呪のように嫌ってたり。
あんちも信者も、それを特別と思ってる人が嫌われてるだけ。
あたかも魔法のように思ってたり、禁呪のように嫌ってたり。
雑誌とかが妙な風に煽りすぎ。
オブジェクト指向の問題点 １／２
・クラスが増えすぎる
→ 単純すぎる機能のためにクラスが作られる（いわゆる『低脳クラス』）
→ 例：キーと値のペアを保存する型が欲しい！⇒Bean
文字列の分割がしたい！⇒Tokenizer
→ しかも再利用できず、再入可能性も無く、状態も持たなかったりする
→ そもそも独立したクラスであるべき理由すら無い
→ 目的の機能（メソッド）を持っているクラスを探すのが面倒
たとえば、 ファイル操作という当たり前の機能のために、5個以上のクラスを使ったりする
→ クラスのことで頭がいっぱいになり、例外処理などの本当に重要な部分が疎かになる
→ くだらない例外やエラーでシステムが落ちる
・機能が複数のファイルに分散しがち
→ 依存関係が複雑になりすぎる（可視化が難しいことがさらに問題を深刻化させる）
→ 役立つ機能があっても、他のソースに絡み付いていて部品化できない
→ 最初からプロジェクトを本体とライブラリに分けてしまえば多少はマシになるが、
それはそれでクラスが分散するため、複雑化に貢献してしまうこともある
→ インターフェイスが把握し辛い
→ 本当に重要な（非常に多く使われている）メソッドと、そうでない『おまけ』メソッドの区別がつかない
→ 大抵は、書いた本人もよく分かっていない
→ まともなサンプルを見るまで誰も満足に使えない
・クラスが増えすぎる
→ 単純すぎる機能のためにクラスが作られる（いわゆる『低脳クラス』）
→ 例：キーと値のペアを保存する型が欲しい！⇒Bean
文字列の分割がしたい！⇒Tokenizer
→ しかも再利用できず、再入可能性も無く、状態も持たなかったりする
→ そもそも独立したクラスであるべき理由すら無い
→ 目的の機能（メソッド）を持っているクラスを探すのが面倒
たとえば、 ファイル操作という当たり前の機能のために、5個以上のクラスを使ったりする
→ クラスのことで頭がいっぱいになり、例外処理などの本当に重要な部分が疎かになる
→ くだらない例外やエラーでシステムが落ちる
・機能が複数のファイルに分散しがち
→ 依存関係が複雑になりすぎる（可視化が難しいことがさらに問題を深刻化させる）
→ 役立つ機能があっても、他のソースに絡み付いていて部品化できない
→ 最初からプロジェクトを本体とライブラリに分けてしまえば多少はマシになるが、
それはそれでクラスが分散するため、複雑化に貢献してしまうこともある
→ インターフェイスが把握し辛い
→ 本当に重要な（非常に多く使われている）メソッドと、そうでない『おまけ』メソッドの区別がつかない
→ 大抵は、書いた本人もよく分かっていない
→ まともなサンプルを見るまで誰も満足に使えない
オブジェクト指向の問題点 ２／２
・デバッグし辛い
→ 過度のカプセル化（あるいは情報公開機能の欠如）のせいで問題点が把握できない
→ さらに、あまりにも多くのオブジェクトが絡み合った構造体が作られる
→ テキストとしてダンプできない
→ 人間が読めない
→ ダンプできるようにしたくても、修正すべき箇所が多すぎる
→ しかも半機械的な作業だったりするので、誰もやりたがらない
（※よくアスペクト指向によるソリューションが語られるが、それもまた対症療法でしかない）
→ 生成方法が存在しないか、生成が難しい『謎の』オブジェクトがある（例：HttpServletRequest）
→ これらに依存していると、そもそも単体テストができない
・オブジェクト脳になりすぎて、『サブルーチン的』な解決策に目が向かない
→ 例外処理のためにコードがどんどん縦に伸びていっても、何も感じない
→ 同じようなコードのコピペが繰り返されていても、
『こういうフレームワークだから』で納得してしまう
→ オブジェクト指向を部分的に捨てて共通関数ライブラリを作れば
劇的にコードが読みやすくなるのに、それをしない。
→ にも関わらず、単機能のいわゆる『低脳クラス』を量産する
・デバッグし辛い
→ 過度のカプセル化（あるいは情報公開機能の欠如）のせいで問題点が把握できない
→ さらに、あまりにも多くのオブジェクトが絡み合った構造体が作られる
→ テキストとしてダンプできない
→ 人間が読めない
→ ダンプできるようにしたくても、修正すべき箇所が多すぎる
→ しかも半機械的な作業だったりするので、誰もやりたがらない
（※よくアスペクト指向によるソリューションが語られるが、それもまた対症療法でしかない）
→ 生成方法が存在しないか、生成が難しい『謎の』オブジェクトがある（例：HttpServletRequest）
→ これらに依存していると、そもそも単体テストができない
・オブジェクト脳になりすぎて、『サブルーチン的』な解決策に目が向かない
→ 例外処理のためにコードがどんどん縦に伸びていっても、何も感じない
→ 同じようなコードのコピペが繰り返されていても、
『こういうフレームワークだから』で納得してしまう
→ オブジェクト指向を部分的に捨てて共通関数ライブラリを作れば
劇的にコードが読みやすくなるのに、それをしない。
→ にも関わらず、単機能のいわゆる『低脳クラス』を量産する
17 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/26(木) 20:35:34
流石糞コテ
言い訳もアホ丸出し
言い訳もアホ丸出し
>>15-16
いいたいことはよくわかるが
それって実装の都合で適当にクラス作って膨れ上がっただけじゃね？
もはや、当初の設計図などは無視で機能追加による継承とか使いまくった後だろ？
要はオブジェクト指向をよくわかってない奴が組んだソースだな
いいたいことはよくわかるが
それって実装の都合で適当にクラス作って膨れ上がっただけじゃね？
もはや、当初の設計図などは無視で機能追加による継承とか使いまくった後だろ？
要はオブジェクト指向をよくわかってない奴が組んだソースだな
21 ：仕様書無しさん：2007/07/26(木) 21:08:12
「ここだけ1990年代のスレ」かと思った
22 ：仕様書無しさん：2007/07/26(木) 21:09:02
自意識過剰、で解らないのなら、クソガキとしかいえんな。
いまどきの中二はもっと大人だよなぁ
いまどきの中二はもっと大人だよなぁ
23 ：仕様書無しさん：2007/07/26(木) 21:21:33
OOOは良い意味のメンドクサがりな人に好まれて
悪い意味でのメンドクサがりな人に嫌われるってイメージ。
バリバリのPG職人気質の人はOOOをそれほど重要視しないかもしれないが、
果たしてこのスレに職人的なほどPGに入れ込んで仕事してる人が
どれほどいるのかってお話じゃないですか？
悪い意味でのメンドクサがりな人に嫌われるってイメージ。
バリバリのPG職人気質の人はOOOをそれほど重要視しないかもしれないが、
果たしてこのスレに職人的なほどPGに入れ込んで仕事してる人が
どれほどいるのかってお話じゃないですか？
24 ：仕様書無しさん：2007/07/26(木) 21:22:28
おーぷんおふぃすどっとおーぐ。
25 ：仕様書無しさん：2007/07/26(木) 21:23:45
オープンソースな人はソースコードを見せるのが仕事だから入れ込むんじゃね？
26 ：仕様書無しさん：2007/07/26(木) 21:30:39
よく分からんけど、「学校の勉強なんて役にたたねーよ」の人みたい。
学校の勉強が役に立たないんじゃなくて、学校の勉強を役に立たせる能力が
お前にどうのこうの。
学校の勉強が役に立たないんじゃなくて、学校の勉強を役に立たせる能力が
お前にどうのこうの。
設計だっつのに実装テクばっかり披露してくれる人が多いんだよ。このスレ
28 ：仕様書無しさん：2007/07/26(木) 21:36:11
国政や国会で使われる言葉と日常会話で使われる言葉は目的が違う。
国会で使われるような突っ込みどころの無い言葉は実用性が無く、
かといって日常で使われるような言葉だけでは幅広い対応は難しい。
適材適所で言葉を選んで臨機応変に対処できる人がすごいのであって、
言葉そのものは手段であり道具である。
それ以上でもそれ以下でもない。
言葉遊びが好きなら研究機関に行くべきだし、泥臭い言葉だけしか使えないなら
一生ドカタ。
言葉や手法は数あれど、最終的には使う奴の脳みそ次第。
国会で使われるような突っ込みどころの無い言葉は実用性が無く、
かといって日常で使われるような言葉だけでは幅広い対応は難しい。
適材適所で言葉を選んで臨機応変に対処できる人がすごいのであって、
言葉そのものは手段であり道具である。
それ以上でもそれ以下でもない。
言葉遊びが好きなら研究機関に行くべきだし、泥臭い言葉だけしか使えないなら
一生ドカタ。
言葉や手法は数あれど、最終的には使う奴の脳みそ次第。
じゃあそろそろ>>27の設計テクを拝聴しようか
良い実装ってのは割と自明だよな
良い設計ってのはどんなだ？
良い設計ってのはどんなだ？
設計と実装の切り分けができない状態で
オブジェクト指向なんて覚えようとするからおかしいことになるんだな
オブジェクト指向なんて覚えようとするからおかしいことになるんだな
良い設計とは、渡されたコーダが、
思わずにっこりと微笑むような設計。
思わずにっこりと微笑むような設計。
良い設計は、基本に乗っ取った設計を元に、
コーダの利便性を考慮したような独自色を微妙に盛り込んでくれているもの。
コーダの利便性を考慮したような独自色を微妙に盛り込んでくれているもの。
設計の目的ってなんだよ
みんなの笑顔
ローカル変数は小文字、
定数は大文字。
改行は分かりやすく、インデントを統一。
これが良い設計。
定数は大文字。
改行は分かりやすく、インデントを統一。
これが良い設計。
実装ｗｗｗ
>>35
とりあえず基本情報処理試験的に言うとウォーターフォールだと
設計には外部設計、内部設計、プログラム設計があってそれぞれ
・外部設計
ユーザ側の立場で、システムの機能や性能などを決める。
画面、帳票、コード、論理データなどの設計を行う。
・内部設計
コンピュータの処理に適した設計を行う。
機能分割・構造化、物理データ設計、入出力詳細設計。
・プログラム設計
プログラムの構造設計を行う。
機能ごとにプログラムをモジュールに分割し、モジュール間のインターフェースを決める。
って書いてある
資格試験も馬鹿にならんなｗ
とりあえず基本情報処理試験的に言うとウォーターフォールだと
設計には外部設計、内部設計、プログラム設計があってそれぞれ
・外部設計
ユーザ側の立場で、システムの機能や性能などを決める。
画面、帳票、コード、論理データなどの設計を行う。
・内部設計
コンピュータの処理に適した設計を行う。
機能分割・構造化、物理データ設計、入出力詳細設計。
・プログラム設計
プログラムの構造設計を行う。
機能ごとにプログラムをモジュールに分割し、モジュール間のインターフェースを決める。
って書いてある
資格試験も馬鹿にならんなｗ
「ウォーターフォールだと」という前提条件がついた文章を
このスレで開陳する >>39 について
このスレで開陳する >>39 について
僕はプロトタイプちゃん！！
>>40
他にプロトタイピングモデルとかスパイラルとかあるけど
現実的じゃねーじゃん。
プロトタイプなんて後から出てくる要求に対して金貰えればいいけど
はじめに総額決まってるのに後から要求出てきて
「これができなかったらオタクとの仕事はもうなしねｗ」なんて言われたら最悪じゃん。
やらないほうが懸命。
スパイラルはサブシステムごとに組むとか言ってるけど
結合したときの不具合が怖すぎてこんなの現実的じゃないし、
それに工数が見積もれ無い。
正直、「見積もる時間を見積もってｗ」的展開になることは目に見えてる
なんでウォーターフォールが一番いいと思うな。俺的には。
それとプロトタイプとスパイラルに関しての設計って説明に書いてないな。
書いてないけどフェーズの流れが違うだけって内容はいっしょって俺は受け取ったけど同じでいいんじゃね？
他にプロトタイピングモデルとかスパイラルとかあるけど
現実的じゃねーじゃん。
プロトタイプなんて後から出てくる要求に対して金貰えればいいけど
はじめに総額決まってるのに後から要求出てきて
「これができなかったらオタクとの仕事はもうなしねｗ」なんて言われたら最悪じゃん。
やらないほうが懸命。
スパイラルはサブシステムごとに組むとか言ってるけど
結合したときの不具合が怖すぎてこんなの現実的じゃないし、
それに工数が見積もれ無い。
正直、「見積もる時間を見積もってｗ」的展開になることは目に見えてる
なんでウォーターフォールが一番いいと思うな。俺的には。
それとプロトタイプとスパイラルに関しての設計って説明に書いてないな。
書いてないけどフェーズの流れが違うだけって内容はいっしょって俺は受け取ったけど同じでいいんじゃね？
ウォーターフォールこそ設計が重要になる
たしかにウォーターフォールなら取り返しがつかないからいい。
妥協してもらいやすい。はんこさえもらっちまえば下に丸投げできる。
不具合を時間のせいに出来る。
いざとなったらとんずらしやすい、といいことづくめだよな。
理想的だよね。
妥協してもらいやすい。はんこさえもらっちまえば下に丸投げできる。
不具合を時間のせいに出来る。
いざとなったらとんずらしやすい、といいことづくめだよな。
理想的だよね。
>>45
そういう反抗的な捉え方をしなくても
あんまりめちゃくちゃな設計だったときは前のフェーズに戻ったほうがいいし、
細かい部分なら担当者同士のすり合わせでなんとかなると思うから
ウォーターフォールのがいいと思う
そういう反抗的な捉え方をしなくても
あんまりめちゃくちゃな設計だったときは前のフェーズに戻ったほうがいいし、
細かい部分なら担当者同士のすり合わせでなんとかなると思うから
ウォーターフォールのがいいと思う
ただ、戻れないからってホントに詳細まで馬鹿みたいに設計に時間を掛けた挙句
実装する時間がほとんどなくてそこでも結局不具合発覚とか勘弁してほしいと思う
実装する時間がほとんどなくてそこでも結局不具合発覚とか勘弁してほしいと思う
まあ、例えば、一億円で一年のプロジェクトがあったとしますよね。
そのプロジェクトに、半年後にストップをかけて、
その時点での生産物に 5千万円の価値があるかと。
そのプロジェクトに、半年後にストップをかけて、
その時点での生産物に 5千万円の価値があるかと。
>>48
何がいいたいのかさっぱりわからん
何がいいたいのかさっぱりわからん
それはざんねん
>>48
まず、結論を書いてから詳細を書いたほうがいいと思う
まず、結論を書いてから詳細を書いたほうがいいと思う
52 ：仕様書無しさん：2007/07/27(金) 00:07:39
何打このスレの速さは？
>>54
>だいたいウォーターフォールかスパイラルかによって設計の目的は変わるのか？？
かわんねーんじゃん？多分
基本情報処理試験の参考書から書き出しただけだから
謎があったらGoogleで検索してくれれば設計の目的とかちゃんと書いてあると思う
ただ、外部設計、内部設計、プログラム設計ごとの目的が書いてあったから書き出してみただけ
>だいたいウォーターフォールかスパイラルかによって設計の目的は変わるのか？？
かわんねーんじゃん？多分
基本情報処理試験の参考書から書き出しただけだから
謎があったらGoogleで検索してくれれば設計の目的とかちゃんと書いてあると思う
ただ、外部設計、内部設計、プログラム設計ごとの目的が書いてあったから書き出してみただけ
>>57
マジか？ｗ
●このアプリケーションには起動画面にウルトラマンとか出てきません
●外観をMacOSのアプリに近づけようとする人がいますが今回はそれをしません
●GUIをエクリプスだかなんだかの礼儀にのっとって作ろうとしてる人がいますが今回はそれをしません
・
・
・
とか延々どうでもいいこと書くの？ｗ
マジか？ｗ
●このアプリケーションには起動画面にウルトラマンとか出てきません
●外観をMacOSのアプリに近づけようとする人がいますが今回はそれをしません
●GUIをエクリプスだかなんだかの礼儀にのっとって作ろうとしてる人がいますが今回はそれをしません
・
・
・
とか延々どうでもいいこと書くの？ｗ
大事なことじゃね？
一方的な「しません」内容じゃなくて、
「こういうことをします。しかしこのようにはなりません」
っての。
土壇場で決まってなくてもめるのは大体これ系だし。
一方的な「しません」内容じゃなくて、
「こういうことをします。しかしこのようにはなりません」
っての。
土壇場で決まってなくてもめるのは大体これ系だし。
>>55
>>56
設計の目的っていういい方がまずかったのかなあ
「究極の設計」ってのがどっちの方向にあるって方向感みたいなものが知りたかった
んで、オブジェクト指向は設計に対して何を寄与するのかってことが知りたい
>>56
設計の目的っていういい方がまずかったのかなあ
「究極の設計」ってのがどっちの方向にあるって方向感みたいなものが知りたかった
んで、オブジェクト指向は設計に対して何を寄与するのかってことが知りたい
確かにあるな
ホストからクラサバに移行する場合とかで
ベンダーは完全移行のつもりなのがユーザーは両方稼動のつもりだったとか
不治痛の得意技とも言う
ホストからクラサバに移行する場合とかで
ベンダーは完全移行のつもりなのがユーザーは両方稼動のつもりだったとか
不治痛の得意技とも言う
>>59
語尾が「しません」なのか「します」なのか間違ってそうなったのか
意図的にわかりにくく書いたのか喧嘩になるだけじゃね？
しないことを書くってのは喧嘩の元だよ
そうとしかとれないような文章をちゃんと書くほうが大事じゃね？
語尾が「しません」なのか「します」なのか間違ってそうなったのか
意図的にわかりにくく書いたのか喧嘩になるだけじゃね？
しないことを書くってのは喧嘩の元だよ
そうとしかとれないような文章をちゃんと書くほうが大事じゃね？
>>62
はっきりと「しません」って書く方がユーザにとってもありがたいだろ。
そう書いてあれば
「いや、それはやってもらわないと困ります」
もしくは、
「それはその通りやらなくていいです」と言えるし。
ベンダーも安心するだろ。書面に残ってる方が。
はっきり書いてないから後々になって揉めるわけだし。
はっきりと「しません」って書く方がユーザにとってもありがたいだろ。
そう書いてあれば
「いや、それはやってもらわないと困ります」
もしくは、
「それはその通りやらなくていいです」と言えるし。
ベンダーも安心するだろ。書面に残ってる方が。
はっきり書いてないから後々になって揉めるわけだし。
どうでもいいけど、何かをするかしないか
とりきめた文書は仕様書だろ
仕様書は要件定義のときにつくるやつだろ
設計書って設計のためのドキュメントだろ条項
GoogleのDesignDocみたいなやつのことだろ
とりきめた文書は仕様書だろ
仕様書は要件定義のときにつくるやつだろ
設計書って設計のためのドキュメントだろ条項
GoogleのDesignDocみたいなやつのことだろ
要件仕様書
設計仕様書
実装仕様書
導入仕様書
運用仕様書
・・・
設計仕様書
実装仕様書
導入仕様書
運用仕様書
・・・
仕様書と設計書、、もはや言葉遊びだな
大事なのは顧客満足度であって
向こうがやらないで困るならこっちの選択肢はないといっていいと思うけどね
そんときにお金要求するかどうかの話であって
そんなもの書いておいて何に使うんだか・・・
やることの確認なんてメールで確認しておくだけで十分だろ
向こうがやらないで困るならこっちの選択肢はないといっていいと思うけどね
そんときにお金要求するかどうかの話であって
そんなもの書いておいて何に使うんだか・・・
やることの確認なんてメールで確認しておくだけで十分だろ
>>68
はあ？SpecificationとDesignって全然ちがうだろ
はあ？SpecificationとDesignって全然ちがうだろ
>>69
どこの個人商店ですか？
どこの個人商店ですか？
いや、その分の超過コストは誰が負担するの？
おまいら、いくらなんでもスレ違いが過ぎるだろ
>>73
だって派遣社員（俺ねｗ）の残業代なんてたかが知れてるじゃない（俺が言うのもなんだが・・・ｗ）
絶対に残業させまくって作っちゃったほうが後々問題なくていいよ
それを材料に次の仕事貰うって交渉してもいいわけだし
だって派遣社員（俺ねｗ）の残業代なんてたかが知れてるじゃない（俺が言うのもなんだが・・・ｗ）
絶対に残業させまくって作っちゃったほうが後々問題なくていいよ
それを材料に次の仕事貰うって交渉してもいいわけだし
>>76
でも実際そうでしょ？
開発（実装）がプロジェクトの予算のネックになることなんてありえない
設計は実装もある程度考慮しなきゃ駄目だが、
同時に予算と仕様も考慮せずに行うこともできない
開発（実装）のコスト増がそんなに大したことないからしわ寄せが全部こっちにくる
って正社員の開発にいる人が言ってた
ああ、たしかに理に叶ってるなぁ、と関心したよ
だから、別に実装フェーズで設計フェーズの不具合を吸収する話は現実とズレた話じゃないんだよ。
でも実際そうでしょ？
開発（実装）がプロジェクトの予算のネックになることなんてありえない
設計は実装もある程度考慮しなきゃ駄目だが、
同時に予算と仕様も考慮せずに行うこともできない
開発（実装）のコスト増がそんなに大したことないからしわ寄せが全部こっちにくる
って正社員の開発にいる人が言ってた
ああ、たしかに理に叶ってるなぁ、と関心したよ
だから、別に実装フェーズで設計フェーズの不具合を吸収する話は現実とズレた話じゃないんだよ。
現実とズレとるかどうかは知らんが、少なくともスレタイとズレとる
>>78
たまにはいいと思うんだけどな
再利用なんてプロジェクトにとってなんの価値もねーことだってわかるし
実装フェイズなんてちょっと長引いたって実は誤差みたいなもんだ（単価が安いんだからｗ）
仕様決め−設計−実装
ってなっててどのフェイズが一番金かかるかって上流のが金がかかるってわかってないと
頓珍漢なところの削減はじめられても迷惑なだけだろ
まあ、俺も実装の話しはじめる奴がいると「スレ違い」連呼するキチガイだからこの辺で止めとこうかｗ
たまにはいいと思うんだけどな
再利用なんてプロジェクトにとってなんの価値もねーことだってわかるし
実装フェイズなんてちょっと長引いたって実は誤差みたいなもんだ（単価が安いんだからｗ）
仕様決め−設計−実装
ってなっててどのフェイズが一番金かかるかって上流のが金がかかるってわかってないと
頓珍漢なところの削減はじめられても迷惑なだけだろ
まあ、俺も実装の話しはじめる奴がいると「スレ違い」連呼するキチガイだからこの辺で止めとこうかｗ
80 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/27(金) 08:58:51
仕様書に書くか書かないかは問題の本質ではない。問題の本質は、客より業務に詳しいかどうかだ。
普通は詳しくないので、修正に強い構造で対応しようというのがOOの狙いだ。
普通は詳しくないので、修正に強い構造で対応しようというのがOOの狙いだ。
ＯＯが修正に強いなんてデマ流すなよ。
修正に強いのは、冗長性を持たせた設計かどうかだろ。
構造化設計だって修正に強い構築は出来るしな。
実装レベルで修正を見越したコードだって書くし。
盲信しすぎｗ
修正に強いのは、冗長性を持たせた設計かどうかだろ。
構造化設計だって修正に強い構築は出来るしな。
実装レベルで修正を見越したコードだって書くし。
盲信しすぎｗ
82 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/27(金) 09:08:02
83 ：仕様書無しさん：2007/07/27(金) 09:11:10
85 ：仕様書無しさん：2007/07/27(金) 09:17:25
>84
たぶん、彼はこういうだろう。
それはきちんとOOを理解してない云々。
それは、他の手法も同じなのに。
銀の男根は存在しないのにね。ｗ
たぶん、彼はこういうだろう。
それはきちんとOOを理解してない云々。
それは、他の手法も同じなのに。
銀の男根は存在しないのにね。ｗ
さて、ここからおじゃばの理解度と、
それを指導する力が問われるな。
それを指導する力が問われるな。
>85
残念、それは私のおいなりさんだ
残念、それは私のおいなりさんだ
88 ：仕様書無しさん：2007/07/27(金) 13:39:06
89 ：仕様書無しさん：2007/07/27(金) 14:19:09
>>87
お前のおいなりさんはooだろう
お前のおいなりさんはooだろう
おいなりさんは小さいほうがいい
俺のおいなりさんは○○って感じだが
おいなりさんは小さい方が便利じゃね？
おまいら、頭に冷えピタ張っとけ（´；ω；｀）
オーバーヒートするにはまだ早い。夏はこれから。
オーバーヒートするにはまだ早い。夏はこれから。
94 ：仕様書無しさん：2007/07/27(金) 18:00:02
扇風機しか持ってない俺は熱耐性持ち。
イオにだって耐えてみせらあ！
でもイオナズンだけは勘弁な。
イオにだって耐えてみせらあ！
でもイオナズンだけは勘弁な。
で、何でｵﾌﾞｼﾞｪｸﾄ指向は嫌われるの？
>>95
おいなりさんが大きすぎるからだよ
おいなりさんが大きすぎるからだよ
97 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/27(金) 21:55:21
>>84
ではCのファイル操作と、Javaのファイル操作を比べてみよう。
Cではfopen()とfgets()/fread()を知っていれば事足りる。ファイルを扱うには問題ない。
しかしファイルから別のリソースになったら、全く別の関数で書き直す必要がある。
JavaではFileクラスやFileInputStreamクラスなど、いくつか知らないとダメだ。
しかし入出力が抽象化されているため、変更が容易になっている。
つまり、ファイルに限らず、ネットワークデータや特殊デバイス等の、同様の入出力に変更が容易だ。
OOの場合はこのような抽象化をクラス単位で行うため、クラス単位で変更が容易になっている。
ではCのファイル操作と、Javaのファイル操作を比べてみよう。
Cではfopen()とfgets()/fread()を知っていれば事足りる。ファイルを扱うには問題ない。
しかしファイルから別のリソースになったら、全く別の関数で書き直す必要がある。
JavaではFileクラスやFileInputStreamクラスなど、いくつか知らないとダメだ。
しかし入出力が抽象化されているため、変更が容易になっている。
つまり、ファイルに限らず、ネットワークデータや特殊デバイス等の、同様の入出力に変更が容易だ。
OOの場合はこのような抽象化をクラス単位で行うため、クラス単位で変更が容易になっている。
Cよく知らないのに背伸びしちゃうとこがかわいいな、おじゃば。
そこでfclose()を書けないとこがまさにJava厨w
言語レベルの話しかできないからいつまでたっても相手が素人なんだぜ。
やれやれ。
そこでfclose()を書けないとこがまさにJava厨w
言語レベルの話しかできないからいつまでたっても相手が素人なんだぜ。
やれやれ。
おじゃばはいつまで経っても実装レベル・言語レベルの話しかしないのな
そこまで言っちゃうと、はっきり煽りってばれちゃうから。
>100
･･･ひょっとしていままでばれてなかったのか？んなあほな。
･･･ひょっとしていままでばれてなかったのか？んなあほな。
人
. ●（＿_） .● ))
| （＿＿） .|
(( ∩ ・∀・）∩ ｳﾝｳﾝ♪
〉 _ノ
ﾉ ノ ノ
し´（＿）
では、GOF や アミーゴス級の人が降臨するまで、
ウンコーが踊りながら保守します。
. ●（＿_） .● ))
| （＿＿） .|
(( ∩ ・∀・）∩ ｳﾝｳﾝ♪
〉 _ノ
ﾉ ノ ノ
し´（＿）
では、GOF や アミーゴス級の人が降臨するまで、
ウンコーが踊りながら保守します。
だれか言ってやれよ。
言語の差であって
オブジェクト指向はまったく関係ない。
言語の差であって
オブジェクト指向はまったく関係ない。
おいなりさん指向>>>>>>>>>オブジェクト指向
オブジェクト指向
冷静に名前を見ると、
絶対に売れない名前だな。
冷静に名前を見ると、
絶対に売れない名前だな。
107 ：仕様書無しさん：2007/07/27(金) 23:19:30
108 ：仕様書無しさん：2007/07/27(金) 23:40:52
またアホがファイルがどーのとか頓珍漢なこと言ってるな
ファイルの扱いは既に抽象化されてるってまるで理解してないのな
おじゃばは新人教育なんてやるな
新人があわれだ
ファイルの扱いは既に抽象化されてるってまるで理解してないのな
おじゃばは新人教育なんてやるな
新人があわれだ
109 ：仕様書無しさん：2007/07/27(金) 23:50:18
抽象化されてると言う割にUNIXとの親和性は皆無だけどな。
110 ：仕様書無しさん：2007/07/27(金) 23:59:30
某言語はURIを抽象化しましたとか吹いてるくせに、結局HTTPのリダイレクトやHTTPSの認証すらまともに扱えない。
SCPやSFTP、IMAPなんかは視界にすら入ってないのでは？
ほとんどの主要プロトコルに追随できず、バグは消えず、実装はお粗末の極み。ほんと詐欺だよ。
部品を使って楽がしたいならPerlでも使ってたほうがマシ。
OOなんて名前空間だけの見かけ倒しだ。
SCPやSFTP、IMAPなんかは視界にすら入ってないのでは？
ほとんどの主要プロトコルに追随できず、バグは消えず、実装はお粗末の極み。ほんと詐欺だよ。
部品を使って楽がしたいならPerlでも使ってたほうがマシ。
OOなんて名前空間だけの見かけ倒しだ。
なんかすぐ具体的な実装の話になるよな。
前スレで電卓の話してた奴も実装しろとか滅茶苦茶叩かれてたし。
OOスレなんだからもっと概念とか上流工程の話とかしてろよ。
前スレで電卓の話してた奴も実装しろとか滅茶苦茶叩かれてたし。
OOスレなんだからもっと概念とか上流工程の話とかしてろよ。
よし
誰か要求定義から実装までの流れのセオリーについて語ってくれよ
誰か要求定義から実装までの流れのセオリーについて語ってくれよ
>>112
右から左へ受け流す
右から左へ受け流す
114 ：仕様書無しさん：2007/07/28(土) 00:44:41
設計と実装を分けるっていう間抜けなやり方をひたすら盲信してるバカにとっては
実装技術なんて下々のゴミどもがやるもんだって思ってんだろうなぁ。
日本中のほとんどの会社の奴が洗脳されてるけど、本当に日本のソフトウェア関係者ってアホばっかだ。
実装技術なんて下々のゴミどもがやるもんだって思ってんだろうなぁ。
日本中のほとんどの会社の奴が洗脳されてるけど、本当に日本のソフトウェア関係者ってアホばっかだ。
そろそろ型チェックのある言語とない言語でのOOPの違いについて語ろうか
117 ：仕様書無しさん：2007/07/28(土) 01:22:28
仕事で、オブジェクト指向らしいコードを見たことがない。
おれが零細企業の底辺PGだからかもしれないと思ってたけど、
某大手の優秀な人たちが作ったというふれこみのシステムのC++のコードを見る機会があって、
それもやっぱりウンココードだった。
おれが零細企業の底辺PGだからかもしれないと思ってたけど、
某大手の優秀な人たちが作ったというふれこみのシステムのC++のコードを見る機会があって、
それもやっぱりウンココードだった。
119 ：仕様書無しさん：2007/07/28(土) 01:37:35
自律してこそオブジェクト。クラスは構造体の延長ではない。
わかるか！
わかるか！
オブジェクト指向でやらなきゃならないほどのものはそうそう無い。
121 ：仕様書無しさん：2007/07/28(土) 02:01:09
オブジェクト指向でやらなきゅてもいいほどのものはそうそう無い。
きゅきゅ
そうそう
ないない
GUIやらない人がなに言ったってオブジェクト指向の良さなんてわからんよ。
ていうか、デザインパターンもいいけど
みんなちゃんとアルゴリズムやろうぜ。
ていうか、デザインパターンもいいけど
みんなちゃんとアルゴリズムやろうぜ。
このスレって
オブジェクト指向嫌い→理解できないから嫌い（ていうか怖がってる）
オブジェクト指向好き→理解できないけど頭良さげ？だから好きなつもり
だね。痛…
オブジェクト指向嫌い→理解できないから嫌い（ていうか怖がってる）
オブジェクト指向好き→理解できないけど頭良さげ？だから好きなつもり
だね。痛…
人
(( （＿_）
（＿＿） ●
●（ ・∀・）/ ｺｯｺ♪
と つ ))
ﾉ ノ ノ
し´（＿）
(( （＿_）
（＿＿） ●
●（ ・∀・）/ ｺｯｺ♪
と つ ))
ﾉ ノ ノ
し´（＿）
>>116
書かれたクラスそのままソースに反映するだけじゃない？
ソース出してもこんな感じであることを確認するぐらいしかないと思うんだけど
なんでソースが必要？どこをみたい？
//液晶パネル
class panel{中身省略};
//ボタンクラス
class button{中身省略};
//表示レジスタクラス
class drawreg{中身省略};
//計算クラス
class ope{中身省略};
//計算機クラス
class opemsn{
//中身省略
private:
drawreg dr;
ope op;
};
//電卓
class calc{
//中身省略
private:
panel pa;
button bt;
opemsn om;
};
書かれたクラスそのままソースに反映するだけじゃない？
ソース出してもこんな感じであることを確認するぐらいしかないと思うんだけど
なんでソースが必要？どこをみたい？
//液晶パネル
class panel{中身省略};
//ボタンクラス
class button{中身省略};
//表示レジスタクラス
class drawreg{中身省略};
//計算クラス
class ope{中身省略};
//計算機クラス
class opemsn{
//中身省略
private:
drawreg dr;
ope op;
};
//電卓
class calc{
//中身省略
private:
panel pa;
button bt;
opemsn om;
};
>書かれたクラスそのままソースに反映するだけじゃない？
ソースに反映するまえのクラスは何で書かれているの？
ソースに反映するまえのクラスは何で書かれているの？
uml
機能分類で設計するときは実装方式なんか考えずに、
「こういう業務を満たしてね♪」
ってな設計書を書けば済んだわけ。
コーディングはPGに任せるスタイル。
でもOOの場合はそうはいかない。
設計書を書く段階で役割（クラスとか）をきちっと決めないと
設計者の思った通りにコードに落ちない。
コーディングは設計者も考える必要があるスタイル。
「こういう業務を満たしてね♪」
ってな設計書を書けば済んだわけ。
コーディングはPGに任せるスタイル。
でもOOの場合はそうはいかない。
設計書を書く段階で役割（クラスとか）をきちっと決めないと
設計者の思った通りにコードに落ちない。
コーディングは設計者も考える必要があるスタイル。
>>130
その uml で書かれたクラスと「現実モデル」の関係は？
その uml で書かれたクラスと「現実モデル」の関係は？
134 ：仕様書無しさん：2007/07/28(土) 10:15:27
設計者が無駄に綺麗にモデル化しすぎてパフォーマンスが出ないことも多い。
というか設計はコードレビューに参加しろ。コードから自動生成したUMLを見て何か気が利いたことでも言え。
実装（現実）と設計（理想）の差を理解する努力をしろ。無責任に投げっぱなしとかやめれ。
というか設計はコードレビューに参加しろ。コードから自動生成したUMLを見て何か気が利いたことでも言え。
実装（現実）と設計（理想）の差を理解する努力をしろ。無責任に投げっぱなしとかやめれ。
>>134
きれいにモデル化して機能要件を満たした後に一部パフォーマンスが劣るところを
速いコードに置き換えるのがオブジェクト指向での定石。
最初から高速化を狙って書くと、柔軟性や見通しの点で難のあるソースにしかならない。
見通しがよく、柔軟性の高いコードは問題点を特定しやすく、変更も容易なのでパフォーマンスを改善しやすい。
きれいにモデル化して機能要件を満たした後に一部パフォーマンスが劣るところを
速いコードに置き換えるのがオブジェクト指向での定石。
最初から高速化を狙って書くと、柔軟性や見通しの点で難のあるソースにしかならない。
見通しがよく、柔軟性の高いコードは問題点を特定しやすく、変更も容易なのでパフォーマンスを改善しやすい。
137 ：仕様書無しさん：2007/07/28(土) 11:24:51
モデリングだけする人、コーディングだけする人って分けたがるバブル世代とかそれより上の世代ってさー
本当にセンス無いよね。頭悪いっつーか。ソフトウェアを作ることに興味が無いっぽい。
いつまでたってもソフトウェアは人月と根性で作るもんだって主張して
新しい技術や概念なんか勉強しようとしないんだもの。
本当にセンス無いよね。頭悪いっつーか。ソフトウェアを作ることに興味が無いっぽい。
いつまでたってもソフトウェアは人月と根性で作るもんだって主張して
新しい技術や概念なんか勉強しようとしないんだもの。
138 ：仕様書無しさん：2007/07/28(土) 11:32:53
ソフトウェアは人月と根性で作るもんだ
は絶対に正しい、絶対にだ。
は絶対に正しい、絶対にだ。
人月と根性は必要だが、人月と根性だけではうまくいかないときもある。
141 ：仕様書無しさん：2007/07/28(土) 12:43:40
つ「人月の神話」
これくらい読んどいてくれよマジで
これくらい読んどいてくれよマジで
プロトタイプ⇒非OOPで作る又は動的OOPで作る
製品⇒プロトタイプをリファクタリングして、良い設計のOOPで作り直す
俺のところでは、上記で良い成果が出ているけどな。
非OOPのスペシャリストは、すごいアイディアとすごいコーディング速度で
プロトタイプを作ってくれる人が多いもんね。
OOPの人ってアイディアが固まっている人が多いような気がする。
製品⇒プロトタイプをリファクタリングして、良い設計のOOPで作り直す
俺のところでは、上記で良い成果が出ているけどな。
非OOPのスペシャリストは、すごいアイディアとすごいコーディング速度で
プロトタイプを作ってくれる人が多いもんね。
OOPの人ってアイディアが固まっている人が多いような気がする。
143 ：仕様書無しさん：2007/07/28(土) 12:45:50
結構適性というか能力が必要だからな。
構造化が中学数学、ニュートン力学としたら、オブジェクト指向は
微積分、相対論みたいなもん。
口先だけのノースキルには扱えないだろ。
でも自分では「ボクの能力では無理です」とは言えないし思いつきもしない。
だから「俺は無能じゃない。オブジェクト指向が使えないシロモノってだけ」
って思おうとしている。
精神の防衛機構だろ。
というか単なる馬鹿。
馬鹿にもそこそこ出来るようにするための技術じゃなくて、
頭いい人がさらに効率を上げるためのシステムだからさ。
扱う能力がないなら、使わない方がマシだしな。
構造化が中学数学、ニュートン力学としたら、オブジェクト指向は
微積分、相対論みたいなもん。
口先だけのノースキルには扱えないだろ。
でも自分では「ボクの能力では無理です」とは言えないし思いつきもしない。
だから「俺は無能じゃない。オブジェクト指向が使えないシロモノってだけ」
って思おうとしている。
精神の防衛機構だろ。
というか単なる馬鹿。
馬鹿にもそこそこ出来るようにするための技術じゃなくて、
頭いい人がさらに効率を上げるためのシステムだからさ。
扱う能力がないなら、使わない方がマシだしな。
144 ：仕様書無しさん：2007/07/28(土) 12:55:45
>>143
その通りだと思う。
その通りだと思う。
145 ：仕様書無しさん：2007/07/28(土) 13:03:53
シンプルにレスされたぁぁ！！
いや、いんですけど。
いや、いんですけど。
>>143
>頭いい人がさらに効率を上げるためのシステムだからさ
なるほどー。PGには頭のいい奴居ないから普及しないよな
PGドカタ諸君、OOあきらめようぜ。
だからよ、C言語で構造化プログラミングしようぜ。
>頭いい人がさらに効率を上げるためのシステムだからさ
なるほどー。PGには頭のいい奴居ないから普及しないよな
PGドカタ諸君、OOあきらめようぜ。
だからよ、C言語で構造化プログラミングしようぜ。
分析から実装までを行ったりきたりする開発プロセスってあったよね
会議には顧客も含めてほぼ全チームが参加するってやつ
会議には顧客も含めてほぼ全チームが参加するってやつ
149 ：仕様書無しさん：2007/07/28(土) 16:22:24
OOを神格化して、なにかとてつもなくすごい技術と勘違いしているようだな。
結果、出来上がったプログラムは良くなるどころかその逆以上。
結果、出来上がったプログラムは良くなるどころかその逆以上。
神格化されてるといえばエージェント指向だな
151 ：仕様書無しさん：2007/07/28(土) 16:34:06
>>149
すぐ上で言われてるけど、優れた人が使うと凄い技術。
それ以外の人間が使うと単なる混乱の元。
君に自覚があるなら、OOとは金輪際関わらない事。
デメリットしかもたらさないよ。
上手くごまかして早く管理職になるといい。
スキルある新人からは嘗められてコケるだろうけど。
すぐ上で言われてるけど、優れた人が使うと凄い技術。
それ以外の人間が使うと単なる混乱の元。
君に自覚があるなら、OOとは金輪際関わらない事。
デメリットしかもたらさないよ。
上手くごまかして早く管理職になるといい。
スキルある新人からは嘗められてコケるだろうけど。
152 ：仕様書無しさん：2007/07/28(土) 17:09:29
>>151
お気遣いありがとう。おいらは大丈夫だよ。
お気遣いありがとう。おいらは大丈夫だよ。
>>147
簡単なモデルだったらいざ知らず、複雑なモデルの
確からしさをどうやって検証してるの？
それと、モデルの良し悪しはつまるところ扱いやすさっていう観点で
測るものだと思うんだけど、それはどうやって確かめる？
結局、なにかしら動くものつくって動かしてみるしかないんじゃない？
簡単なモデルだったらいざ知らず、複雑なモデルの
確からしさをどうやって検証してるの？
それと、モデルの良し悪しはつまるところ扱いやすさっていう観点で
測るものだと思うんだけど、それはどうやって確かめる？
結局、なにかしら動くものつくって動かしてみるしかないんじゃない？
マーチンの法則集とかにのってる各原則に対して検証を行うとか
実際に動かすのはその後でもいいでしょ
まぁ力ある人だったらいきなりテストプログラム製作するのもいいけどさ
実際に動かすのはその後でもいいでしょ
まぁ力ある人だったらいきなりテストプログラム製作するのもいいけどさ
155 ：仕様書無しさん：2007/07/28(土) 17:34:37
力ある人ほど手順をしっかり踏むんだよね。
それでも死ぬほど早いんだけど。
ノースキルの馬鹿なのに、自信過剰で手順すっ飛ばしてハマる馬鹿には死んで欲しい。
それでも死ぬほど早いんだけど。
ノースキルの馬鹿なのに、自信過剰で手順すっ飛ばしてハマる馬鹿には死んで欲しい。
あんまり能力の無い人にとっては元に近いモデルのまま扱うようにした方が安全だと思うんだよね。
コードのレベルにまで落とし込むのって結構気を使わないといけないし…
だからコードに落とし込む為の分析設計や、
その下書きが脳内で瞬時にかつ確実に出来る人ならそれが一番早いだろうが、
そうでなければ結果的により遅くなってしまうんじゃないかな？
それぐらい朝飯前に出来ないとプログラマとして駄目とか言われたらそれまでだけどさ。
コードのレベルにまで落とし込むのって結構気を使わないといけないし…
だからコードに落とし込む為の分析設計や、
その下書きが脳内で瞬時にかつ確実に出来る人ならそれが一番早いだろうが、
そうでなければ結果的により遅くなってしまうんじゃないかな？
それぐらい朝飯前に出来ないとプログラマとして駄目とか言われたらそれまでだけどさ。
>>147
自分は「ソースが必要」なんて話はしてない。
>>116
>>128
>>129
の流れで、 「現実モデルをそのままソースに落とすのがOO」という発言の
具体的な意味が知りたいだけ。
君が、「現実モデルをそのままソースに落とすのがOO」と思ってないなら、
君には関係無い（君が話の流れを知らずに妙な解釈をして途中で割り込んできただけの）話だし、
君が、「現実モデルをそのままソースに落とすのがOO」と思っているのならば、
「なんでソースが必要？」という質問には、君が自分で答えるべき。
自分は「ソースが必要」なんて話はしてない。
>>116
>>128
>>129
の流れで、 「現実モデルをそのままソースに落とすのがOO」という発言の
具体的な意味が知りたいだけ。
君が、「現実モデルをそのままソースに落とすのがOO」と思ってないなら、
君には関係無い（君が話の流れを知らずに妙な解釈をして途中で割り込んできただけの）話だし、
君が、「現実モデルをそのままソースに落とすのがOO」と思っているのならば、
「なんでソースが必要？」という質問には、君が自分で答えるべき。
>>153
>結局、なにかしら動くものつくって動かしてみるしかないんじゃない？
明らかに設計できるレベルじゃないのにこのスレくるから
いちいちソース要求するんだな
時間的にも経験的にももっとたくさんソースを組んだり読んだりする必要があると思う
現にソースっぽいもん出したって次の質問は
>>129
>ソースに反映するまえのクラスは何で書かれているの？
とか、出したソースに〜の情報が足りないからこれを出してほしい
ってもんじゃなくてソースと全然関係無い質問したでしょ？
要は自分の必要な情報とか結論を出すために必要な情報がわかってないから
場当たり的にただの情報をごちゃごちゃ集めてるだけなんだよ。お前
それで集めるだけ集めれば自分が意識しないでも
まわりを見渡せば必要な情報がどっかにそろってるのがこれまで経験してきたパターンなんだろうけど
掲示板の場合それができないから意味不明なこと連呼し続ける
お前の積み上げてきたもんはそんなもんだ
オブジェクト指向云々の問題じゃなくて仕事に無駄が有りすぎる
ちゃんとスタートからエンドまで筋道たてて一つ一つ検証して積みたてた仕事ってやったことないでしょ？
それが露骨にこういうところで出てる
>結局、なにかしら動くものつくって動かしてみるしかないんじゃない？
明らかに設計できるレベルじゃないのにこのスレくるから
いちいちソース要求するんだな
時間的にも経験的にももっとたくさんソースを組んだり読んだりする必要があると思う
現にソースっぽいもん出したって次の質問は
>>129
>ソースに反映するまえのクラスは何で書かれているの？
とか、出したソースに〜の情報が足りないからこれを出してほしい
ってもんじゃなくてソースと全然関係無い質問したでしょ？
要は自分の必要な情報とか結論を出すために必要な情報がわかってないから
場当たり的にただの情報をごちゃごちゃ集めてるだけなんだよ。お前
それで集めるだけ集めれば自分が意識しないでも
まわりを見渡せば必要な情報がどっかにそろってるのがこれまで経験してきたパターンなんだろうけど
掲示板の場合それができないから意味不明なこと連呼し続ける
お前の積み上げてきたもんはそんなもんだ
オブジェクト指向云々の問題じゃなくて仕事に無駄が有りすぎる
ちゃんとスタートからエンドまで筋道たてて一つ一つ検証して積みたてた仕事ってやったことないでしょ？
それが露骨にこういうところで出てる
モデリングそのものを記述する言語ってあるかな？
UMLあたり？
UMLあたり？
すいませんでした。ごめんなさい。
とりあえず現実モデル→ソース野郎の完全敗北ってことでもういいよな
次の話題
↓
次の話題
↓
168 ：仕様書無しさん：2007/07/28(土) 18:47:24
↓
伊藤真紀は最高のAV女優だった件について
伊藤真紀は最高のAV女優だった件について
結論
オブジェクト指向とは別にこのスレにいる奴は馬鹿ばっか
馬鹿に出せる結論は所詮馬鹿な結論しかない
オブジェクト指向とは別にこのスレにいる奴は馬鹿ばっか
馬鹿に出せる結論は所詮馬鹿な結論しかない
は、置いておいて、
素晴らしいネタが投下されるまで、
ウンコーが踊りながらスレを保守します。
人
（＿_）
（＿＿）
●（ ・∀） ｳﾝ♪
と つ−● ))
(( （ Ｏ ﾉ
ﾞ（,_,,/
人
.● （＿ ）●
（( | （＿＿）|
(（・∀・ /ﾞ) ｺｯｺ♪
ヽ, 〈
ヽ (⌒ﾉ)
l,_,ﾉ )）
素晴らしいネタが投下されるまで、
ウンコーが踊りながらスレを保守します。
人
（＿_）
（＿＿）
●（ ・∀） ｳﾝ♪
と つ−● ))
(( （ Ｏ ﾉ
ﾞ（,_,,/
人
.● （＿ ）●
（( | （＿＿）|
(（・∀・ /ﾞ) ｺｯｺ♪
ヽ, 〈
ヽ (⌒ﾉ)
l,_,ﾉ )）
>>168 ふるいわぁっ！！ イトマキｗ
馬鹿な奴は実装だけしてればいい、といっておきながら
お前らは馬鹿だから俺の設計が理解できないんだ！という矛盾
お前らは馬鹿だから俺の設計が理解できないんだ！という矛盾
∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
（ ´∀｀）＜ このスレにいる奴は馬鹿ばっか
（ ） ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
｜ ｜ |
（_＿）＿）
>>173
設計と実装を別にすれば矛盾しないじゃん
設計と実装を別にすれば矛盾しないじゃん
>>175
設計が理解できないのにどうやって実装するんだ？
設計が理解できないのにどうやって実装するんだ？
>>176
理解しなくていいから設計図どおりにクラス作ってこい
理解しなくていいから設計図どおりにクラス作ってこい
>>177
どこまで詳細に書くつもりだよｗ
どこまで詳細に書くつもりだよｗ
179 ：仕様書無しさん：2007/07/28(土) 19:20:15
>>178
仕様書とC++のクラス定義が同じ行数になるくらいだろ。
仕様書とC++のクラス定義が同じ行数になるくらいだろ。
180 ：仕様書無しさん：2007/07/28(土) 19:21:40
>>171
ふるいけど、今見てもいいぜ。
ふるいけど、今見てもいいぜ。
>>181
自分で実装したほうが早くね？
自分で実装したほうが早くね？
つか、実装レベルのクラスを設計者が考えてるとか思ってる時点で素人まるだし
UMLとか見るとかなり全部書いてあるけど
実際にUML使ってる現場ってどうなの？
実際にUML使ってる現場ってどうなの？
188 ：仕様書無しさん：2007/07/28(土) 20:58:28
映画「トランスフォーマー」
は、プログラマーの一種ですか？
は、プログラマーの一種ですか？
>>185
自分用のクラス図ぐらいしか書いた事無いんだよな。
どうせならUMLで書いとくかって感じで。
今は、テキストエディタにクラスとメソッドメモっておいて、
ソース書いたらリバースエンジニアリングでUMLのクラス図にしとく
って感じ。
>>184
フレームワークのクラスを一回継承してってレベルなら何も指示しない。
もっと必要な場合は、打ち合わせする。
自分用のクラス図ぐらいしか書いた事無いんだよな。
どうせならUMLで書いとくかって感じで。
今は、テキストエディタにクラスとメソッドメモっておいて、
ソース書いたらリバースエンジニアリングでUMLのクラス図にしとく
って感じ。
>>184
フレームワークのクラスを一回継承してってレベルなら何も指示しない。
もっと必要な場合は、打ち合わせする。
190 ：仕様書無しさん：2007/07/28(土) 21:38:32
>>187
うちは提出物だぜ。UMLで描いたクラス図とシーケンス図。
最初は上の命令どうり、分析設計をUMLでやってレビューしてそれをパスしてから実装してたけど
もうこれだと話が全然進まない。
UMLのクラス図シーケンス図で詳細なところまで設計しても誰も他人の図なんか読めないからな。
しょうがないから俺なんかはもうノートにすげーラフにクラス図とシーケンス図書いて、
それを基に個人で設計実装テストをサイクルさせて、出来上がったら図をちゃんと作って提出することにしてる。
うちは提出物だぜ。UMLで描いたクラス図とシーケンス図。
最初は上の命令どうり、分析設計をUMLでやってレビューしてそれをパスしてから実装してたけど
もうこれだと話が全然進まない。
UMLのクラス図シーケンス図で詳細なところまで設計しても誰も他人の図なんか読めないからな。
しょうがないから俺なんかはもうノートにすげーラフにクラス図とシーケンス図書いて、
それを基に個人で設計実装テストをサイクルさせて、出来上がったら図をちゃんと作って提出することにしてる。
UMLは考え方を知らないゆとり向け
物を考えられないゆとりでもUMLを使って試行錯誤すれば時間は掛かるものの
何も考えずに組む事を思えば遥かにまともなものを作ることが出来る
物を考えられないゆとりでもUMLを使って試行錯誤すれば時間は掛かるものの
何も考えずに組む事を思えば遥かにまともなものを作ることが出来る
UMLはroseやEA等の各種CASE(笑)ツール上で扱ってやっとまともに使える
手作業で書くのはドラフト用途のみおｋ、それ以外はソフトの力を借りないと時間が掛かってしょうがない
手作業で書くのはドラフト用途のみおｋ、それ以外はソフトの力を借りないと時間が掛かってしょうがない
ＵＭＬで表記したものが何で実装段階で変わっちゃうのか。
それは、実装した言語の制約や自由度がＵＭＬとは違い過ぎるから。
いちばん面倒なのは、ＵＭＬのクラス図は静的な相関関係を表してるとこ。
でも、普通のプログラムは動的な相関関係を記述するからね。
それは、実装した言語の制約や自由度がＵＭＬとは違い過ぎるから。
いちばん面倒なのは、ＵＭＬのクラス図は静的な相関関係を表してるとこ。
でも、普通のプログラムは動的な相関関係を記述するからね。
>>193
レスすんなゴミめｗ
レスすんなゴミめｗ
やっぱ分析設計は使われて無い感じか。
クラス図でも関連とかコンポジションとかまで書けば、
実際にコンポジションの関係、単にメソッドなりで利用されてるだけの関係
まで現せるとかいってたけど、それでも動的じゃない感じ？
実際にコンポジションの関係、単にメソッドなりで利用されてるだけの関係
まで現せるとかいってたけど、それでも動的じゃない感じ？
分析工程については、UMLの問題というよりツール側の問題だなあ。
業務分析で帳票の項目を資料化する場合でも、
UMLツールってのは大量の属性を一度に登録するというようなことを
考慮してないから、Excel 表をまず先に作るしかない。
おおまかなフローを追うようなことには便利だと思う。
フローで抽出したオブジェクトに肉付けしてドメインモデルを作っていく、
というようなことができるから。
ただ、詳細化する過程で上記の問題が生じる。
業務分析で帳票の項目を資料化する場合でも、
UMLツールってのは大量の属性を一度に登録するというようなことを
考慮してないから、Excel 表をまず先に作るしかない。
おおまかなフローを追うようなことには便利だと思う。
フローで抽出したオブジェクトに肉付けしてドメインモデルを作っていく、
というようなことができるから。
ただ、詳細化する過程で上記の問題が生じる。
処理順番なんてどうでもいいし、シーケンス図って無駄に紙面割いててうざい。
その設計が
そのソースコードが
美しいかどうかが問題なんだ。
わかるか。
そのソースコードが
美しいかどうかが問題なんだ。
わかるか。
まあ、そう思うならコラボレーション図を使いなされ。
>>201
久々に聞いたな
久々に聞いたな
>>200
動作がよくわからんソースに対して書かせてみるのはいいかもしれない
動作がよくわからんソースに対して書かせてみるのはいいかもしれない
204 ：仕様書無しさん：2007/07/29(日) 00:30:40
設計者気取りのバカがUMLとか使いたがるのは本当に困るよな。
マイクロソフトとかIBMの宣伝雑誌の記事に踊らされて「これからはモデル駆動開発だ！」とか言ってんの。
モデルだけ書けばコードは自動生成とかもうね、本当にバカ。
マイクロソフトとかIBMの宣伝雑誌の記事に踊らされて「これからはモデル駆動開発だ！」とか言ってんの。
モデルだけ書けばコードは自動生成とかもうね、本当にバカ。
EAも例に出してくれよ
最近じゃroseより人気あるぜ
最近じゃroseより人気あるぜ
206 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 03:43:22
207 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 03:57:15
208 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 04:57:40
んだ、そういうときはシーケンス図じゃなくて状態遷移表を残して欲しい。
その上で一部の代表的な流れを解説するためにシーケンス図を使うんなら
一向に構わんけど。
その上で一部の代表的な流れを解説するためにシーケンス図を使うんなら
一向に構わんけど。
209 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 06:15:54
コテハンがいないとまともに流れるな
210 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 07:09:08
だって糞コテは自分に酔ってるだけで空気読めなかったんだから仕方ないじゃない
つーか死んだひとのことはもう忘れましょう
つーか死んだひとのことはもう忘れましょう
211 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 07:49:17
すげー実装よりでちっともオブジェクト指向理解できてねぇのばっかだったじゃん
そのくせ人に教えてあげたい気満々で議論もしようとしないで一方的に垂れ流すだけ
もうとっくに専ブラのＮＧワード入り
そのくせ人に教えてあげたい気満々で議論もしようとしないで一方的に垂れ流すだけ
もうとっくに専ブラのＮＧワード入り
212 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 08:26:41
オブジェクト指向で開発する、ってなっただけで
技術者に求めるレベルが上がる。
正確に言えば、オブジェクト指向に対応できる設計者が少なすぎるということ。
それは、開発終了後のリスクが高い、ということにつながる。
開発終了後の保守段階になって緊急対応が必要になった場合、
そのときにスキル保有者をすぐに呼べるかどうかが疑問。
技術者に求めるレベルが上がる。
正確に言えば、オブジェクト指向に対応できる設計者が少なすぎるということ。
それは、開発終了後のリスクが高い、ということにつながる。
開発終了後の保守段階になって緊急対応が必要になった場合、
そのときにスキル保有者をすぐに呼べるかどうかが疑問。
213 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 08:42:48
>>212
設計者なんてそんなにいらねぇよ
俺１人でだって２００人規模のもん設計できるぜ
逆に多いから何もできない
加えてみんな自分の利権のために動く
正に「船頭多くして船山に登る」
ソフトウェア開発がわからん奴にとっていかにわからんものかってことだな
誰を信じていいかわからない
いままで人しか動かしたことがないし、奴等はだれでもできる仕事を誰かに振ってきたに過ぎない
暗中模索の中で均等に仕事を割り振るとたまに重要な仕事がアフォのところにいくって話さ
そんな難しい問題じゃない
設計者なんてそんなにいらねぇよ
俺１人でだって２００人規模のもん設計できるぜ
逆に多いから何もできない
加えてみんな自分の利権のために動く
正に「船頭多くして船山に登る」
ソフトウェア開発がわからん奴にとっていかにわからんものかってことだな
誰を信じていいかわからない
いままで人しか動かしたことがないし、奴等はだれでもできる仕事を誰かに振ってきたに過ぎない
暗中模索の中で均等に仕事を割り振るとたまに重要な仕事がアフォのところにいくって話さ
そんな難しい問題じゃない
214 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 08:56:17
でも幾ら小さいプロジェクトでも数人は設計者は必要でしょ
一人の人間の視野って結構狭いし
かといって巨大プロジェクトだからといって大量の設計者を集めるのは明らかな誤りだとも思うけど
一人の人間の視野って結構狭いし
かといって巨大プロジェクトだからといって大量の設計者を集めるのは明らかな誤りだとも思うけど
215 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 09:24:07
>>214
>でも幾ら小さいプロジェクトでも数人は設計者は必要でしょ
俺は逆の意見だな
本当は必要ない
でもみんな不安だから責任を誰かに押し付けたいんだ
だから必要だと狂言を吐く
だからやろうと思えばどんな無茶な納期でも間に合ってしまう
ホントは１人でできる仕事だ
選択の間違いを自分のせいにしたくない
時間がない、予算がすくない、人がいないのを理由にしたいんだ
だから今の状態がある
>でも幾ら小さいプロジェクトでも数人は設計者は必要でしょ
俺は逆の意見だな
本当は必要ない
でもみんな不安だから責任を誰かに押し付けたいんだ
だから必要だと狂言を吐く
だからやろうと思えばどんな無茶な納期でも間に合ってしまう
ホントは１人でできる仕事だ
選択の間違いを自分のせいにしたくない
時間がない、予算がすくない、人がいないのを理由にしたいんだ
だから今の状態がある
216 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 09:28:08
オブジェクト指向やそれにともなうよくわからん長い名前の付いた学問や設計手法は
「こんな最新の方法を使って開発しちゃいました♪」
だから見逃してください、いい方法でやったんです
だからボクは勉強してるでしょう？なんたって学者様の発表したばかりの方法です
ボクは勉強してる、ボクがわからない問題なんて誰もわからないに決まってる
ボクは悪くないんだ
っていうためのいいわけｗ
こんな情け無い奴が設計やってるから利益なんてでないわけ
「こんな最新の方法を使って開発しちゃいました♪」
だから見逃してください、いい方法でやったんです
だからボクは勉強してるでしょう？なんたって学者様の発表したばかりの方法です
ボクは勉強してる、ボクがわからない問題なんて誰もわからないに決まってる
ボクは悪くないんだ
っていうためのいいわけｗ
こんな情け無い奴が設計やってるから利益なんてでないわけ
217 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 09:33:29
それってただ単に天才を求めてるだけじゃないか
218 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 09:54:20
絶対に失敗しない人間がいるならそいつ一人に任せて良いだろうけど
んな人間世界中探したっていないだろう
んな人間世界中探したっていないだろう
219 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 09:57:59
200人規模で設計１人とか、人集める前に何年かけて設計やってんのって話だよ。
220 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:02:39
>>219
すぐ終わるって
みんな頑張ってるなんてのは幻想だ
少なくとも馬鹿混ぜて進捗のたびに説明会やる時間削れるだけでも御の字だろ
つーか、なんもわかってないやつにわかってる奴が説明する時間がそもそも無駄だろ
自分の知識がない不安を払拭ための会議とかそんなんばっかだぞ＞時間とるのは
わかってる担当者のところは速攻でおわっちまうしな
すぐ終わるって
みんな頑張ってるなんてのは幻想だ
少なくとも馬鹿混ぜて進捗のたびに説明会やる時間削れるだけでも御の字だろ
つーか、なんもわかってないやつにわかってる奴が説明する時間がそもそも無駄だろ
自分の知識がない不安を払拭ための会議とかそんなんばっかだぞ＞時間とるのは
わかってる担当者のところは速攻でおわっちまうしな
221 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:09:41
>>わかってる担当者のところは速攻でおわっちまうしな
これは同意
これは同意
222 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:10:38
>>207
開発工程って
要求分析 → システムの設計 → モジュール単体の設計
→ 詳細設計 → コーディング →（以下略）
だと思うけど、OO設計でいう設計って
コレで「設計」って付いてるとこ全部だと思ってたんだが違うのか？
開発工程って
要求分析 → システムの設計 → モジュール単体の設計
→ 詳細設計 → コーディング →（以下略）
だと思うけど、OO設計でいう設計って
コレで「設計」って付いてるとこ全部だと思ってたんだが違うのか？
223 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:17:15
>>213>>220
213と220が同じ人間かどうかは分からんけどさ。
それで君らが事故って死んだら、200人規模のプロジェクトが止まって大損害だ。
そういうリスクの対策も含めて「設計者は複数で」だよ。
213と220が同じ人間かどうかは分からんけどさ。
それで君らが事故って死んだら、200人規模のプロジェクトが止まって大損害だ。
そういうリスクの対策も含めて「設計者は複数で」だよ。
224 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:21:35
225 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:26:10
仮に設計者が一人で全部設計したとして、
その設計が正しいことはどうやって保証するの？まぁ設計者が100人でも同じなんだけど。
設計に問題があったらやり直さなきゃならんことが増大するわけだが、
設計者のみなさんはそこをどうやって保証しようと思ってんだ？
ちなみに俺も設計者だが、オブジェクト指向開発では一発で完璧な設計が出来ない事を前提にして、
プロトタイプを作ってテストしてそこからさらに設計を改善するって方法を取ってる。
必然的に時間がかかるので、一人で何十人分の仕事をするってのは無理になる。
そこらへん無視して全部俺が設計してもいいけど、そしたら最終的にかかるコストと時間はもっと酷いもんになるけどね。
その設計が正しいことはどうやって保証するの？まぁ設計者が100人でも同じなんだけど。
設計に問題があったらやり直さなきゃならんことが増大するわけだが、
設計者のみなさんはそこをどうやって保証しようと思ってんだ？
ちなみに俺も設計者だが、オブジェクト指向開発では一発で完璧な設計が出来ない事を前提にして、
プロトタイプを作ってテストしてそこからさらに設計を改善するって方法を取ってる。
必然的に時間がかかるので、一人で何十人分の仕事をするってのは無理になる。
そこらへん無視して全部俺が設計してもいいけど、そしたら最終的にかかるコストと時間はもっと酷いもんになるけどね。
226 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:27:24
227 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:45:46
>>225
>その設計が正しいことはどうやって保証するの？
そんなものは誰にも証明できない
それは何百人いたって何千人いたって同じことだ
じゃあ、聞くけどお前は、全員で案出して、
何かの決定をすべて多数決でやればいいものができると思ってる？
俺は収集がつかないだけだと思ってる
どんなに人数そろえようが結局だれかが責任をとらなきゃ駄目で
大半の奴が決定権をだれかに渡すようになると思う
人数なんてのは虚構の安心感を求めてるに過ぎない
>その設計が正しいことはどうやって保証するの？
そんなものは誰にも証明できない
それは何百人いたって何千人いたって同じことだ
じゃあ、聞くけどお前は、全員で案出して、
何かの決定をすべて多数決でやればいいものができると思ってる？
俺は収集がつかないだけだと思ってる
どんなに人数そろえようが結局だれかが責任をとらなきゃ駄目で
大半の奴が決定権をだれかに渡すようになると思う
人数なんてのは虚構の安心感を求めてるに過ぎない
228 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:47:39
凝り固まってるのか場数を踏んで絶対的な自身を得たのか
どっちにしろ俺ら常人には理解できない考え方だ
どっちにしろ俺ら常人には理解できない考え方だ
229 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:51:32
>>227
プロトタイプとテストの結果が完全に仕様を満たしていることを保証してくれてるけど？
ま、多数決だろうが最優秀設計者だろうがどっちでもいいよ。
実績のある設計、テストをパスした設計ってことを保証してくれれば。
少なくともUMLのお絵かきツールでクラス図やシーケンス図をお絵かきしただけのものは
設計とは呼ばないよ、俺は。それはただのお絵かきだよ。会社じゃ設計って呼ばれてるけども。
プロトタイプとテストの結果が完全に仕様を満たしていることを保証してくれてるけど？
ま、多数決だろうが最優秀設計者だろうがどっちでもいいよ。
実績のある設計、テストをパスした設計ってことを保証してくれれば。
少なくともUMLのお絵かきツールでクラス図やシーケンス図をお絵かきしただけのものは
設計とは呼ばないよ、俺は。それはただのお絵かきだよ。会社じゃ設計って呼ばれてるけども。
230 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:53:46
>>228
言ってることわからんかなぁ
人数なんていたって無駄で誰かが「えいや」って決める必要があるってだけさ
俺が凝り固まってる脳みその持ち主かどうかは関係ないのさ
集団になるとみんな馬鹿になる
普段はそうで無い奴も含めて
言ってることわからんかなぁ
人数なんていたって無駄で誰かが「えいや」って決める必要があるってだけさ
俺が凝り固まってる脳みその持ち主かどうかは関係ないのさ
集団になるとみんな馬鹿になる
普段はそうで無い奴も含めて
231 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 10:57:02
232 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 11:01:10
>>230
みんなで設計して開発工数が削れるかどうかは
プロジェクトメンバーのレベルが揃ってるかどうかで変わるんじゃない？
どっちにしろ>>223とかの理由で、設計に限らず、
まず複数人で1つのことを進めることが当たり前。
その上で、無駄な説明やら進捗やらの会議時間を
品質落とさずにどう削っていくかがミソ。
まぁ、予算とか人足とかカツカツのところはそうも言ってられんだろうけど。
みんなで設計して開発工数が削れるかどうかは
プロジェクトメンバーのレベルが揃ってるかどうかで変わるんじゃない？
どっちにしろ>>223とかの理由で、設計に限らず、
まず複数人で1つのことを進めることが当たり前。
その上で、無駄な説明やら進捗やらの会議時間を
品質落とさずにどう削っていくかがミソ。
まぁ、予算とか人足とかカツカツのところはそうも言ってられんだろうけど。
233 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 11:03:22
大人数開発→責任の大きさによる不安の増大→パニック発生→
→暴徒化→ゾンビ化→レイプ・虐殺→
→「俺、知りませんよ、みんなして暴徒と化しているだけです」→
→輪姦→遠心力により大変な暴力に→
→軍隊なんだから市民を守れ→
→俺達だって人間だ、お前ら悪党は氏ね→
ズココンバキューン！！
ごめ、デスマで頭が…
→暴徒化→ゾンビ化→レイプ・虐殺→
→「俺、知りませんよ、みんなして暴徒と化しているだけです」→
→輪姦→遠心力により大変な暴力に→
→軍隊なんだから市民を守れ→
→俺達だって人間だ、お前ら悪党は氏ね→
ズココンバキューン！！
ごめ、デスマで頭が…
234 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 11:07:57
235 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 11:08:23
設計の話になってもやっぱりOOと関係無い話のほうが盛り上がるなｗｗｗ
236 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 11:11:41
OOなんて沢山ある視点の中のひとつにしか過ぎないんだし
237 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 11:21:04
クイズ ヘキサゴンやってたけどすごいな。
松坂の玉を頭で受けたせいで記憶力ゼロなんだろうな。
238 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 11:26:46
経験的に、
OOで優秀な人は考え方がシンプルな人が多いので複雑な事は仕様的に行わない(もっと良い方法を考える)
非OOで優秀(と言われる)人はどんなに複雑な事でも実現する
適材適所どちらも必要ですね
OOで優秀な人は考え方がシンプルな人が多いので複雑な事は仕様的に行わない(もっと良い方法を考える)
非OOで優秀(と言われる)人はどんなに複雑な事でも実現する
適材適所どちらも必要ですね
239 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 11:51:17
開発手法なんてものは趣味グラマが挫折しない為に使う工夫程度の用途しかないんだよ
240 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 13:00:12
オブジェクト指向での設計がどうのこうのより、もっと根本的な問題がある。
オブジェクト指向で設計できる要員を確保できないという問題。
何人で作業する、とかの話は各プロジェクトによって異なるし。
納期・品質・コストの面からでね。
根本問題である要員確保の難しさがあるのに、
「再利用できる」「可読性があがる」「品質があがる」
などと言った謳い文句だけで突っ走ろうとすることが間違い。
オブジェクト指向で設計できる要員を確保できないという問題。
何人で作業する、とかの話は各プロジェクトによって異なるし。
納期・品質・コストの面からでね。
根本問題である要員確保の難しさがあるのに、
「再利用できる」「可読性があがる」「品質があがる」
などと言った謳い文句だけで突っ走ろうとすることが間違い。
241 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 14:13:25
解りやすく修正が容易なコードを書けばOOだろうが非OOだろうがどちらでもOKだと思うな
時と場合によって使いこなせるバランス感覚が重要だね
時と場合によって使いこなせるバランス感覚が重要だね
242 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 16:37:09
243 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 17:01:25
Java使いの中でUML書ける奴ってどんぐらいいるんだ？
HやNのプロパーは全然書けないんだよな。
HやNのプロパーは全然書けないんだよな。
244 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 17:33:54
凄腕SE様いわく
「UMLやUPなんて馬鹿が技術者の真似事する為の道具」
「UMLやUPなんて馬鹿が技術者の真似事する為の道具」
245 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:10:43
べつにUMLなんて描けなくもいいだろ。仕事に問題無ければな。
俺は描けるけど。
俺は描けるけど。
246 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:12:11
最近、C言語だと別の型でポインタをキャストするのを禁止してる客先が多い
構造体とdefineのクラスもどき擬似オブジェクト指向ができない
構造体とdefineのクラスもどき擬似オブジェクト指向ができない
247 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:35:07
＞C言語だと別の型でポインタをキャストするのを禁止してる
こんなこと言い出したらmallocですらアウトなんじゃねえの？
こんなこと言い出したらmallocですらアウトなんじゃねえの？
248 ：名無しさん＠そうだ選挙に行こう：2007/07/29(日) 18:56:10
http://imepita.jp/20070729/673600
http://puka-world.com/php/upload/ren/img-box/1185701027059.jpg
http://tvde.web.infoseek.co.jp/cgi-bin/jlab-dat/s/68242.jpg
http://puka-world.com/php/upload/ren/img-box/1185701027059.jpg
http://tvde.web.infoseek.co.jp/cgi-bin/jlab-dat/s/68242.jpg
249 ：仕様書無しさん：2007/07/29(日) 21:19:18
私は３９歳の現役PGですが、現在はオブジェクト指向を利用した、DB系の仕事してます。
私より若い衆のほうが、ポインタも再起も理解できないし、設計もお粗末。
クラスは誰かが作ったものをNEWするものというレベルｗ
私はアセンブラ、構造化言語、オブジェクト指向言語 一通りやってきたからね。
バブル世代には負けないよ。
しかし、BASICしか知らない上司には本当に困ってる(苦笑
私より若い衆のほうが、ポインタも再起も理解できないし、設計もお粗末。
クラスは誰かが作ったものをNEWするものというレベルｗ
私はアセンブラ、構造化言語、オブジェクト指向言語 一通りやってきたからね。
バブル世代には負けないよ。
しかし、BASICしか知らない上司には本当に困ってる(苦笑
250 ：仕様書無しさん：2007/07/29(日) 21:20:47
>>249
なんだろう。
釣りなんだろうか。
再帰の字も知らない低学歴なんだろうか。
マネジメントにもコンサルにも行けずに底辺でコーディングして
40ちょいで無職になる（というか今現在無職のフリー？）のが
嬉しいんだろうか。
分からない。
なんだろう。
釣りなんだろうか。
再帰の字も知らない低学歴なんだろうか。
マネジメントにもコンサルにも行けずに底辺でコーディングして
40ちょいで無職になる（というか今現在無職のフリー？）のが
嬉しいんだろうか。
分からない。
その話は荒れるでやめやぁ。
オレは知ってる、周囲は知らない
ってな話はスレ違い
ってな話はスレ違い
フリーかぁ。結局俺はフリーにはならなかったなぁ。
さんそうけん仕事は結局キャンセル、
(俺自身取りに行くつもりなかったからしょうがないかｗ)
この夏は何故か銀行通いで過ぎ去りそうな今日この頃
皆様お元気に過ごしておられますか？
さんそうけん仕事は結局キャンセル、
(俺自身取りに行くつもりなかったからしょうがないかｗ)
この夏は何故か銀行通いで過ぎ去りそうな今日この頃
皆様お元気に過ごしておられますか？
日本語でおｋ
つか会社大丈夫？
すぐ逃げちゃう星人伝説はもう過去のもの？ｗｗｗ
すぐ逃げちゃう星人伝説はもう過去のもの？ｗｗｗ
コンサルとかマネジメントっておもしろいかぁ？
俺は絶対嫌だね。プログラム組んで方が楽しい。
俺は絶対嫌だね。プログラム組んで方が楽しい。
なんだ一気にレスがなくなったな。
やっぱいつもの一人芝居だったのか。
> 俺は絶対嫌だね。プログラム組んで方が楽しい。
まぁさぁ、俺もそう思うけど、
いい歳こいてくると仕事を拾ってくる仕組み作りとか、
基礎的なアーキテクチャを研究開発するような仕組み作りとか、
いろいろな仕事が出てくるんじゃないかな。
好きか嫌いか、ではなく、好きな仕事を続けるための義務みたいなもん。
そこらへん、３９にもなって無責任で居れる？うらやましい性格だな
やっぱいつもの一人芝居だったのか。
> 俺は絶対嫌だね。プログラム組んで方が楽しい。
まぁさぁ、俺もそう思うけど、
いい歳こいてくると仕事を拾ってくる仕組み作りとか、
基礎的なアーキテクチャを研究開発するような仕組み作りとか、
いろいろな仕事が出てくるんじゃないかな。
好きか嫌いか、ではなく、好きな仕事を続けるための義務みたいなもん。
そこらへん、３９にもなって無責任で居れる？うらやましい性格だな
若造だけじゃソフトは作れないぜ
オブジェクト指向を知らない・学ばない世代が設計担当なんだよな。
知らない世代なんて、もう定年年齢じゃないの。
２０代でも知らない奴が多数派である事実
設計ミスはオブジェクト指向以前の問題だろ。
そのミスを軽減するためのオブジェクト指向で
オブジェクト指向じゃないからどうという話じゃない。
で，コミュニケーションを唱えて不備を隠蔽してる奴らは
ハナからそういう方法論を論じる気がないので
オブジェクト指向は嫌われると。
そのミスを軽減するためのオブジェクト指向で
オブジェクト指向じゃないからどうという話じゃない。
で，コミュニケーションを唱えて不備を隠蔽してる奴らは
ハナからそういう方法論を論じる気がないので
オブジェクト指向は嫌われると。
４行目以降も日本語でおｋ
264 ：仕様書無しさん：2007/07/30(月) 00:19:12
「日本語でおｋ」とは
主にウェブ上で、わけのわからない発言(解読しづらい文字列や意味の通らない文章など)をした者に対して言われる表現。
主にウェブ上で、わけのわからない発言(解読しづらい文字列や意味の通らない文章など)をした者に対して言われる表現。
日本語でおｋ
とか書いてくる奴は、大抵まともな話に付いてこれない
困ったちゃんだから、スルーでおｋ
とか書いてくる奴は、大抵まともな話に付いてこれない
困ったちゃんだから、スルーでおｋ
設計の不完全さを口頭でのやりとりでなんとかしようって発想だと
設計手法を論じること自体に意味を見出せなくなるってこと。
どんなにいい加減な仕様書書いても後から口頭で一々確認とってりゃ
設計思想も糞もない。
設計手法を論じること自体に意味を見出せなくなるってこと。
どんなにいい加減な仕様書書いても後から口頭で一々確認とってりゃ
設計思想も糞もない。
いい加減な仕様書通りに黙って実装しちゃう、
悪辣なPGは俺です。
悪辣なPGは俺です。
268 ：仕様書無しさん：2007/07/30(月) 19:19:53
>>267のようなやつが、偉い人達をうまくごまかしちゃうから
設計がうまくいってると思われて、あとになって被害を受けるのは俺だな
設計がうまくいってると思われて、あとになって被害を受けるのは俺だな
269 ：仕様書無しさん：2007/07/30(月) 20:36:09
>>269
実装開始後の仕様変更は追加料金になります
実装開始後の仕様変更は追加料金になります
271 ：仕様書無しさん：2007/07/30(月) 22:20:06
>>271
お前の所と取引が無くて本当に良かったと思うよ
お前の所と取引が無くて本当に良かったと思うよ
そうやってすぐ喧嘩するの好きなんだね君達
変更以前に仕様があやふや
仕様書がおざなり
仕様書がおざなり
154 名前：仕様書無しさん[sage] 投稿日：2007/07/30(月) 21:58:27
どんな仕様書読んでも全て中途半端でいちいち聞きに行くのが面倒臭いんだが
どうにかならないのかな？
助詞や助動詞の使い方も理解してない代書屋はいかんせんムカつきますな
どんな仕様書読んでも全て中途半端でいちいち聞きに行くのが面倒臭いんだが
どうにかならないのかな？
助詞や助動詞の使い方も理解してない代書屋はいかんせんムカつきますな
仕様変更という名の応急処置は多いけどな。
privateがpublicになり、コンストラクタが増え、クラス内部の奥の奥に
オブジェクトを渡すための引数を延々と追加。
完成させなきゃ終わらないから、従うしかない。
privateがpublicになり、コンストラクタが増え、クラス内部の奥の奥に
オブジェクトを渡すための引数を延々と追加。
完成させなきゃ終わらないから、従うしかない。
C++ならconst_castとかmutable使いまくりで
折角の設計を台無しにしてしまうような応急処置もされてたんだよね…
でコレをメンテナンスした人間は確実に「C++はなんて酷い言語なんだ」って
C++アレルギーを持つという
折角の設計を台無しにしてしまうような応急処置もされてたんだよね…
でコレをメンテナンスした人間は確実に「C++はなんて酷い言語なんだ」って
C++アレルギーを持つという
279 ：仕様書無しさん：2007/07/30(月) 23:24:05
結論：
仕様変更に強いOOを使えば全てが解決する
さー、OOの勉強再開だ
仕様変更に強いOOを使えば全てが解決する
さー、OOの勉強再開だ
IT関係はヲタクと精神障害者と知能障害者しか居ないので在籍する必要性は皆無です
>>279
ｦｲｦｲ糞ｺﾃが湧いてくるぢゃ内科ww
ｦｲｦｲ糞ｺﾃが湧いてくるぢゃ内科ww
あぁ〜またホラ吹き登場だw
そういえば、コテ今日どうしたのかな....
なんかいないとちょっとさびしい気がするな
結構、コテの俺おれ論を聞くのもオモシロイんだよな
なんかいないとちょっとさびしい気がするな
結構、コテの俺おれ論を聞くのもオモシロイんだよな
284 ：仕様書無しさん：2007/07/30(月) 23:41:01
>>279
XMLを使いまくればもっと修正が楽になるんだぜ？
XMLを使いまくればもっと修正が楽になるんだぜ？
EAが吐くUML図はXML形式なんだぜ
AOP をうまく使えば、確かに修正が楽になるが、
これは OO のおかげというべきか、 XML のおかげというべきか。
これは OO のおかげというべきか、 XML のおかげというべきか。
288 ：仕様書無しさん：2007/07/31(火) 00:19:20
XMLを使えばC++のソースコードを変更することなくプログラムの修正ができる
C++で面倒な処理もXMLで記述すれば(ry
大学の教授はXMLが大好き。全部XMLで書けって勢いだったなぁw
C++で面倒な処理もXMLで記述すれば(ry
大学の教授はXMLが大好き。全部XMLで書けって勢いだったなぁw
CASE(笑)はそれを行うためのツールが必要だけどね
XML大嫌い
XMLは規格だからなぁ。好きとか嫌いとかいう問題ではないような。
同意
YAMLでいいやん
YAMLでいいやん
オブジェクト指向での開発が順調に終わって祝杯をあげた翌日に
Nがサーバー発注を忘れてやがって
自分で買った持込端末を仮サーバーとするからよこせと言われている俺がきましたよ
Nがサーバー発注を忘れてやがって
自分で買った持込端末を仮サーバーとするからよこせと言われている俺がきましたよ
特定しますた
>>293
開発機にＶＣ（および開発環境全部）入れて納品なんてところもあるから別に驚かない
開発機にＶＣ（および開発環境全部）入れて納品なんてところもあるから別に驚かない
まあ開発機が用意できないから、運用機で開発なんて
日常茶飯事だから。
日常茶飯事だから。
ていうかさ、ここでいうオブジェクト指向ってなんなんだ。
雰囲気的にはOOD臭いけどなぜか実際の文句はOOPにだよな。
雰囲気的にはOOD臭いけどなぜか実際の文句はOOPにだよな。
298 ：仕様書無しさん：2007/07/31(火) 13:07:01
基地PGはミクロのさきっちょは語れるけど、マクロを語れないから。ｗ
>語れないから。ｗ
代わりにあなたが語ってください。
代わりにあなたが語ってください。
よしきた。
#define
#define
>>300
no macro name given in #define directive
no macro name given in #define directive
302 ：仕様書無しさん：2007/07/31(火) 14:06:04
虚勢を張るなよ
＞＞２８０
ちゃんと自覚できてるやん。
はやくびょうきなおせ（母より)
ちゃんと自覚できてるやん。
はやくびょうきなおせ（母より)
そんなに固持しないで、個人個人で「OOのほうが組みやすい」とかでいいんじゃね？
それ以外の仕事がきたら「もとのソース書いた人死んじゃえばいいのに」って呟きなら仕事するといいと思うよ。
それ以外の仕事がきたら「もとのソース書いた人死んじゃえばいいのに」って呟きなら仕事するといいと思うよ。
個人の思い込みにならないように気をつけないとw
307 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/08/02(木) 21:32:31
田中真紀子を応援してたやつ → Ruby使い
小泉を応援してたやつ → OO使い
小泉を応援してたやつ → OO使い
妙な空白がありやがるｗ
UMLなんかゴミじゃね？何の役にも立たないし。１０年も経ったら誰も書かない気がする。
OOもクズだよ。全然生産性なんかあがんねーし、クラスが再利用できるとかでたらめもいいところ。
あれだな夜中の通販番組並にだまされやすい馬鹿が多いって事だな。
OOであなたの人生が変わるんですよ。すぐお電話をってな。
OOもクズだよ。全然生産性なんかあがんねーし、クラスが再利用できるとかでたらめもいいところ。
あれだな夜中の通販番組並にだまされやすい馬鹿が多いって事だな。
OOであなたの人生が変わるんですよ。すぐお電話をってな。
OOが当たり前の存在になってる今、気づいたら知っていたレベルだと思うが
>>309
それはおまいさんとこの設計担当が鈴頭だからだ。
それはおまいさんとこの設計担当が鈴頭だからだ。
>>312
それが普通だろ？ なんのために導入してるんだ？
それが普通だろ？ なんのために導入してるんだ？
>>313
無駄な仕事を増やすためだろ？
無駄な仕事を増やすためだろ？
再利用たってソースの再利用は不可能だな
設計の再利用ならいいかもな
まあ、でも一番困るのは
使ってる姿が全く想像できないもんを作るときだな
設計の再利用ならいいかもな
まあ、でも一番困るのは
使ってる姿が全く想像できないもんを作るときだな
316 ：仕様書無しさん：2007/08/03(金) 01:24:01
これは本当のことです
層化学会であなたの人生が変わるんですよ。すぐ入信をしなさい。
層化学会であなたの人生が変わるんですよ。すぐ入信をしなさい。
318 ：仕様書無しさん：2007/08/03(金) 09:06:47
UMLなんぞ記法にすぎぬということを理解できないうちは、ooぐらいだね。
ちいさいいなり。
大事なのはそれを書く脳みそなのに、書き方覚えたらOKみたいな。
せめてOOぐらいになれよ。
おおきなふぐり。
ちいさいいなり。
大事なのはそれを書く脳みそなのに、書き方覚えたらOKみたいな。
せめてOOぐらいになれよ。
おおきなふぐり。
Rubyでクラス大量生成してたが、小泉も真紀子も嫌いだぞ俺は
でも、池田先生は大好きなのです。
ＯＯは理解できたので、次はプログラミングの勉強を盆休みに集中して行う予定です。
初めてのプログラミングなのでＲｕｂｙが良いかなと思っています。
どうでしょうか？
初めてのプログラミングなのでＲｕｂｙが良いかなと思っています。
どうでしょうか？
好きにすれば？
RubyやっとればRubyを知らない奴よりはいいかもしれん
>ＯＯは理解できたので、次はプログラミングの勉強を
ここがネタなんだろ
ここがネタなんだろ
>>324
普通に死ねって思うなｗ
普通に死ねって思うなｗ
プログラミングもできねえのにOOとかマジ笑える。
数学は理解できたので、次は物理の勉強を〜って言ってるくらいアホ。
ゆとってねえで両方やれｗ
数学は理解できたので、次は物理の勉強を〜って言ってるくらいアホ。
ゆとってねえで両方やれｗ
>>326
OOが理解できたからプログラミングするってんだから、むしろ物理は完璧に理解したから、次は算数を（≠数学）って言ってるようなもんじゃね？ww
OOが理解できたからプログラミングするってんだから、むしろ物理は完璧に理解したから、次は算数を（≠数学）って言ってるようなもんじゃね？ww
初心者は学習する順序を知らないだけだろ。
そう叩くなよ。
そう叩くなよ。
そもそもOOを理解したってなんだw
何をもって理解したと言うんだw
何をもって理解したと言うんだw
ミッションクリティカル系リリース間際の不具合対応＆次案件見積もりで死にそうになってる今日この頃、
やっぱここに来てる人って、とてつもない暇人なんだなぁ、と妙に感慨深い暑い夏の夜
皆様お元気でせうか（ｗｗｗ
やっぱここに来てる人って、とてつもない暇人なんだなぁ、と妙に感慨深い暑い夏の夜
皆様お元気でせうか（ｗｗｗ
嫌われている理由は想像に難くない。
例えば、現実に矛盾なく回っている業務があったとして、その当事者がいたとする。彼が
自分、および周辺の業務を言語できちんと概念化して説明ができるか。そうとは限らないし、
むしろできないことが多いと思う。
じゃあ、何で仕事が実際にはできるのか。それは、個別具体的に、こういう場合はこうやる
ことになっている、この場合にはこっちだ、といった発想で動いており、且つその業務の
ある期間における経験的な積み重ねから、矛盾が取り除かれているからだ。
しかし、矛盾なく動いている業務にはそれを可能にしている構造が必ずある。その構造を
捉え、その地平で考えること、これは一般的に現場の人間にはピンとこないし、嫌がるものだ。
システム開発も同じ。一般の現場のプログラマは自分の開発経験から積み上げたノウハウ
から発想するが、オブジェクト指向というのは逆に考えることを要求する。それが気に入らない。
結局のところ構造ではなくて、個別具体的な、例えば「ここにこんな表示させたいんだけどできる？」
とか、そんな地平で考えている開発者が大半だということだろう。
例えば、現実に矛盾なく回っている業務があったとして、その当事者がいたとする。彼が
自分、および周辺の業務を言語できちんと概念化して説明ができるか。そうとは限らないし、
むしろできないことが多いと思う。
じゃあ、何で仕事が実際にはできるのか。それは、個別具体的に、こういう場合はこうやる
ことになっている、この場合にはこっちだ、といった発想で動いており、且つその業務の
ある期間における経験的な積み重ねから、矛盾が取り除かれているからだ。
しかし、矛盾なく動いている業務にはそれを可能にしている構造が必ずある。その構造を
捉え、その地平で考えること、これは一般的に現場の人間にはピンとこないし、嫌がるものだ。
システム開発も同じ。一般の現場のプログラマは自分の開発経験から積み上げたノウハウ
から発想するが、オブジェクト指向というのは逆に考えることを要求する。それが気に入らない。
結局のところ構造ではなくて、個別具体的な、例えば「ここにこんな表示させたいんだけどできる？」
とか、そんな地平で考えている開発者が大半だということだろう。
また駄ホラ吹いちゃったｗ 正確には
× ミッションクリティカル系
◎ ミッションクリティカル業界 にしては珍しくライトでお気楽な (はずだった) システム
× ミッションクリティカル系
◎ ミッションクリティカル業界 にしては珍しくライトでお気楽な (はずだった) システム
>>331
お前の文章は、ダラダラ思ってること書くだけで、
他人に認めてもらえるような意見も結論もない。
つまり、お前の文章は無駄ってこった。
言いたい事簡潔にまとめて、
他人に受け入れられるような書き方をしろってこった
お前の文章は、ダラダラ思ってること書くだけで、
他人に認めてもらえるような意見も結論もない。
つまり、お前の文章は無駄ってこった。
言いたい事簡潔にまとめて、
他人に受け入れられるような書き方をしろってこった
>>333
何か気になるところに触れたのか？w
オブジェクト指向の最も重要なことは、矛盾の無い業務があり、それを矛盾の無い仕様として
表現できたならば、それを全く等価な形で実装可能である、そう確信できる点にある。
実際の実装の場面でそれが守られるかどうか、そんなことどうでもいい。大事なのは仕様
確定時に実装上の都合を考えなくてよいということ。
何か気になるところに触れたのか？w
オブジェクト指向の最も重要なことは、矛盾の無い業務があり、それを矛盾の無い仕様として
表現できたならば、それを全く等価な形で実装可能である、そう確信できる点にある。
実際の実装の場面でそれが守られるかどうか、そんなことどうでもいい。大事なのは仕様
確定時に実装上の都合を考えなくてよいということ。
結局の所、いつも彼の発言は
「工場生産〜事務計算といったトロ臭い業務を、
現場労働者とは異なる高い視点で整理しモデル化する事」
＝オブジェクト指向の本質
とった類の、彼固有の世界観の発露に終始する。
彼はきっとそういった、知的レベルの低い労働者ばかりの業務分野しか知らないのだろう。
「工場生産〜事務計算といったトロ臭い業務を、
現場労働者とは異なる高い視点で整理しモデル化する事」
＝オブジェクト指向の本質
とった類の、彼固有の世界観の発露に終始する。
彼はきっとそういった、知的レベルの低い労働者ばかりの業務分野しか知らないのだろう。
「知的レベルの低い労働者ばかりの業務分野」
なんて存在しないぞ
なんて存在しないぞ
338 ：仕様書無しさん：2007/08/05(日) 10:24:07
339 ：仕様書無しさん：2007/08/05(日) 11:12:18
>>333
俺も無意識に読み飛ばしてて、アンタの書き込みみて気づいたわ。
1行目だけ読んでみて、やっぱり読む価値ないってわかったけど。
この書き出しって分かってない奴が知ったかぶりと独りよがりの意見書くときの
常套句だよな。
俺も無意識に読み飛ばしてて、アンタの書き込みみて気づいたわ。
1行目だけ読んでみて、やっぱり読む価値ないってわかったけど。
この書き出しって分かってない奴が知ったかぶりと独りよがりの意見書くときの
常套句だよな。
340 ：仕様書無しさん：2007/08/05(日) 12:23:05
オブジェクト指向デザインどたらとかデザインパターンこうたらって
講釈たれてるヤツに限って、基本的なプログラミングスキルが無いのはなぜ？
講釈たれてるヤツに限って、基本的なプログラミングスキルが無いのはなぜ？
341 ：仕様書無しさん：2007/08/05(日) 12:29:48
>>340
プログラムの組み方がわからないのを誤魔化すために身に付けた自衛手段だからｗ
プログラムの組み方がわからないのを誤魔化すために身に付けた自衛手段だからｗ
単なる知ったかぶりか
この板は現場バンザイ主義なんだな。
プログラミングの問題に全く引きずられずに仕様確定が可能であるということ、
これが重要なのだよ。
ま、現場連中特有の経験主義の意見しか出なくて残念だね。読む価値無いとか
オレはプログラミングスキルあるぞ、とか的外れなこと言ってないで、もっと自分の
意見を述べてみたまえ。
プログラミングの問題に全く引きずられずに仕様確定が可能であるということ、
これが重要なのだよ。
ま、現場連中特有の経験主義の意見しか出なくて残念だね。読む価値無いとか
オレはプログラミングスキルあるぞ、とか的外れなこと言ってないで、もっと自分の
意見を述べてみたまえ。
俺はITに転職してくる前に、総務・経理・営業と経験してきたが、矛盾なく回ってる業務なぞ見たためしがない。
それぞれ何かしらの矛盾を抱えていて、それを現場の知恵と経験で埋めているパターンが大半のような気がするのだが。
それぞれ何かしらの矛盾を抱えていて、それを現場の知恵と経験で埋めているパターンが大半のような気がするのだが。
>>337
> 「知的レベルの低い労働者ばかりの業務分野」
> なんて存在しないぞ
んじゃさ、
「知的レベルが相対的に特別高いとは言えない」 SEが
「知的レベルが相対的に特別低いとは言えない」 労働者/経営者の裏をかいて、
画期的な視点で業務を整理して、
無矛盾な業務定義を取り出す手順をとくと説明しろよ。
実際の現場では、客観的に見て何か根本的に業務の進め方に間違いがある、
ってあたりは割と誰でも気付くのだけど、
そういう業務形態が現場で受け入れられているのにはそれなりの理由があるわけで、
そこの慣性 (一度転がり出した玉はなかなか止まらない) に逆らって
新しい業務手順/システムを押し付ける事こそ、大変なんだろうと思う (第三者モード
> 「知的レベルの低い労働者ばかりの業務分野」
> なんて存在しないぞ
んじゃさ、
「知的レベルが相対的に特別高いとは言えない」 SEが
「知的レベルが相対的に特別低いとは言えない」 労働者/経営者の裏をかいて、
画期的な視点で業務を整理して、
無矛盾な業務定義を取り出す手順をとくと説明しろよ。
実際の現場では、客観的に見て何か根本的に業務の進め方に間違いがある、
ってあたりは割と誰でも気付くのだけど、
そういう業務形態が現場で受け入れられているのにはそれなりの理由があるわけで、
そこの慣性 (一度転がり出した玉はなかなか止まらない) に逆らって
新しい業務手順/システムを押し付ける事こそ、大変なんだろうと思う (第三者モード
つかさ、ここオブジェクト指向スレだよな？
なんで事務系業務屋がのさばってるの？
マルチメディア系OOPの延長線上に関わりはじめたと思ってたら
またぞろ事務系業務に絡む羽目に陥ったオイラにしてみると、
ホント事務系業務って完全無視したいとこなんだけどｗ
なんで事務系業務屋がのさばってるの？
マルチメディア系OOPの延長線上に関わりはじめたと思ってたら
またぞろ事務系業務に絡む羽目に陥ったオイラにしてみると、
ホント事務系業務って完全無視したいとこなんだけどｗ
>>347
組織とヒエラルキーにおける政治的な手法と業務プロセスの改善手法の話が一まとめになってるのは何なの？
あとそれがなんで業務分野と知的レベルの話に何で関係してくんの？
全く意味わかんないんだけど。
組織とヒエラルキーにおける政治的な手法と業務プロセスの改善手法の話が一まとめになってるのは何なの？
あとそれがなんで業務分野と知的レベルの話に何で関係してくんの？
全く意味わかんないんだけど。
>>344
＞プログラミングの問題に全く引きずられずに仕様確定が可能であるということ、
「仕様」って何の仕様のこと？
最初に作られる要求仕様は言語とかの問題とは比較的切り離し易いけど、
そこからの設計仕様作成は「要求仕様を実装する方式を決定する作業」な訳で、
この作業をプログラミング(実装)と切り離して考えるのはナンセンスだと思うがどうか。
＞プログラミングの問題に全く引きずられずに仕様確定が可能であるということ、
「仕様」って何の仕様のこと？
最初に作られる要求仕様は言語とかの問題とは比較的切り離し易いけど、
そこからの設計仕様作成は「要求仕様を実装する方式を決定する作業」な訳で、
この作業をプログラミング(実装)と切り離して考えるのはナンセンスだと思うがどうか。
>>349
> 組織とヒエラルキーにおける政治的な手法と
> 業務プロセスの改善手法の話が一まとめになってるのは何なの？
ふーん、両者を完全に分離して取り扱う事ができるんだ。
すごいね。その草の根改善運動みたいなのは、どうやって組織化してるの？
> あとそれがなんで業務分野と知的レベルの話に何で関係してくんの？
それは今、>>331に聞いている所だ。
現場の人間にはピンとこない業務改善を、
現場の人間とさしてレベルの変わらない人間が
どうやって提案し、実現していくのか、非常に興味深い。
> 組織とヒエラルキーにおける政治的な手法と
> 業務プロセスの改善手法の話が一まとめになってるのは何なの？
ふーん、両者を完全に分離して取り扱う事ができるんだ。
すごいね。その草の根改善運動みたいなのは、どうやって組織化してるの？
> あとそれがなんで業務分野と知的レベルの話に何で関係してくんの？
それは今、>>331に聞いている所だ。
現場の人間にはピンとこない業務改善を、
現場の人間とさしてレベルの変わらない人間が
どうやって提案し、実現していくのか、非常に興味深い。
352 ：351：2007/08/05(日) 20:55:20
つか、このスレ相変わらず空理空論野郎が粘着してるようだな。
こいつにまともな話をするとすぐ
「お前の話は言葉遊びだ」とか言い出すんだが、
こいつ自身の発言こそ
現実の概念や技術とは遊離した「言葉遊び」っぽいな。
暇人って、とことん暇だよな（ぷ
こいつにまともな話をするとすぐ
「お前の話は言葉遊びだ」とか言い出すんだが、
こいつ自身の発言こそ
現実の概念や技術とは遊離した「言葉遊び」っぽいな。
暇人って、とことん暇だよな（ぷ
353 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/08/05(日) 20:56:40
じゃあ実証で決着つけよう
つうとOO厨は蜘蛛の子を散らすように逃げるじゃんか
つうとOO厨は蜘蛛の子を散らすように逃げるじゃんか
353 名前： あぼ〜ん [あぼ〜ん] 投稿日： あぼ〜ん
あぼ〜ん
あぼ〜ん
Googleじゃない方のたかひろは、
最近なにやってんの？
生産管理システム？
最近なにやってんの？
生産管理システム？
暇人って、とことん暇だよな（ぷ
普通に仕事してたら、こんなスレに来ている暇などない
普通に仕事してたら、こんなスレに来ている暇などない
>>331=おじゃばの一人二役見るのは疲れるな
どのあたりが一人二役？
レス番挙げてみれ
レス番挙げてみれ
359 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/08/05(日) 21:09:22
934 <丶｀∀´>（´・ω・｀）（｀ハ´ ）さん sage New! 2007/08/05(日) 21:07:47 ID:joDcgeY8
>>926
＞いかに深く読むかは論語を学ぶ人の力量にかかっている。
これこそ儒教の犯した最悪の罪だよな。
孔子の言葉の一言一句に振り回され、ありもしない意味を読み取ろうとして、
どんどん神格化し、結果とてつもない化け物を生み出してしまった。
>>926
＞いかに深く読むかは論語を学ぶ人の力量にかかっている。
これこそ儒教の犯した最悪の罪だよな。
孔子の言葉の一言一句に振り回され、ありもしない意味を読み取ろうとして、
どんどん神格化し、結果とてつもない化け物を生み出してしまった。
>>346
「知らずにできる」。これは当たってるね。構造的に矛盾の無い仕様があるならば、
それは実装「できるはずだ」と確信できること、これがオブジェクト指向開発の重要な点だ。
「知らない」というのは、単に無知だとかそういう意味じゃあない。例えば僕等の大半は
自分が生きるために必要な食物の作り方なんか知らなかったりする。自分の衣服の
作り方を知る人間がどれぐらいいるだろうか。
それらと同じ意味で、実際に記述されるコーディングの都合なんぞ考えなくても仕様を
確定できるし、その仕様は実現可能なのだと確信できること、これが重要なんだな。
「知らずにできる」。これは当たってるね。構造的に矛盾の無い仕様があるならば、
それは実装「できるはずだ」と確信できること、これがオブジェクト指向開発の重要な点だ。
「知らない」というのは、単に無知だとかそういう意味じゃあない。例えば僕等の大半は
自分が生きるために必要な食物の作り方なんか知らなかったりする。自分の衣服の
作り方を知る人間がどれぐらいいるだろうか。
それらと同じ意味で、実際に記述されるコーディングの都合なんぞ考えなくても仕様を
確定できるし、その仕様は実現可能なのだと確信できること、これが重要なんだな。
361 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/08/05(日) 21:10:05
普通に仕事してたら日曜日は休んでるだろ>>356
>>361
うぜぇよ暇人
うぜぇよ暇人
363 ：仕様書無しさん：2007/08/05(日) 21:14:08
>>351
> 現場の人間にはピンとこない業務改善を、
> 現場の人間とさしてレベルの変わらない人間が
> どうやって提案し、実現していくのか、非常に興味深い。
開発屋が別に業務コンサルを兼ねる必要なんか全く無い。開発屋は自分たちが
実装できるようにヒアリングできればいいし、それ以上は畑違いってものだ。
結局要件定義というのは、無意識に分かってはいるけれども意識的に考えた
ことがないことをあえて考えるということだ。改善とかではなく、単に日々普通に
行っている業務などを言葉に起こすという作業。
> 現場の人間にはピンとこない業務改善を、
> 現場の人間とさしてレベルの変わらない人間が
> どうやって提案し、実現していくのか、非常に興味深い。
開発屋が別に業務コンサルを兼ねる必要なんか全く無い。開発屋は自分たちが
実装できるようにヒアリングできればいいし、それ以上は畑違いってものだ。
結局要件定義というのは、無意識に分かってはいるけれども意識的に考えた
ことがないことをあえて考えるということだ。改善とかではなく、単に日々普通に
行っている業務などを言葉に起こすという作業。
責任分解点の明文化？
しかし、言葉に起こした仕様は、実装可能か？或は、それは言葉で記述されるのと
同じ程度に簡単に実装可能なのだろうか？という問題がある。オブジェクト指向開発は、
その点において力強く「YES」と宣言する開発手法なのだ。
同じ程度に簡単に実装可能なのだろうか？という問題がある。オブジェクト指向開発は、
その点において力強く「YES」と宣言する開発手法なのだ。
> 「知らずにできる」。これは当たってるね。構造的に矛盾の無い仕様があるならば、
> それは実装「できるはずだ」と確信できること、これがオブジェクト指向開発の重要な点だ。
それは、あなた固有の信念に過ぎません。
構造化であろうとデータ中心であろうと、
「矛盾のない仕様があれば、それは実装できるはずだ」
と思い込む事は、可能です。無知蒙昧を恥じずに強弁する心臓があれば。
他方、例えば科学技術分野や、数学的なアルゴリズムを必要とする分野では、
計算可能性 と、計算量 の二つの観点から、「実現可能性」を判断する必要があります。
例えば気象予測の場合、全球1kmメッシュのシミュレーションは
アルゴリズム的には計算可能ですが、
計算量的には、現時点では計算不可能です。
また、初期値となる測定データを1kmメッシュで得る事も、
事実上無理と言えるでしょう。
空理空論で計算可能な事と、
実際に計算可能な事の間には、
大きな溝があり、その溝を埋める事こそが
(OOに限定せず) IT技術者の仕事だと考えておりますが、
いかがでしょうか。
貴殿のご意見を賜りたく存じます。
> それは実装「できるはずだ」と確信できること、これがオブジェクト指向開発の重要な点だ。
それは、あなた固有の信念に過ぎません。
構造化であろうとデータ中心であろうと、
「矛盾のない仕様があれば、それは実装できるはずだ」
と思い込む事は、可能です。無知蒙昧を恥じずに強弁する心臓があれば。
他方、例えば科学技術分野や、数学的なアルゴリズムを必要とする分野では、
計算可能性 と、計算量 の二つの観点から、「実現可能性」を判断する必要があります。
例えば気象予測の場合、全球1kmメッシュのシミュレーションは
アルゴリズム的には計算可能ですが、
計算量的には、現時点では計算不可能です。
また、初期値となる測定データを1kmメッシュで得る事も、
事実上無理と言えるでしょう。
空理空論で計算可能な事と、
実際に計算可能な事の間には、
大きな溝があり、その溝を埋める事こそが
(OOに限定せず) IT技術者の仕事だと考えておりますが、
いかがでしょうか。
貴殿のご意見を賜りたく存じます。
匠の手にかかればオブジェクト指向があっという間にバズワードに
>>367
IT技術者って連中がそんな高尚なことやってるとは思えないがw、あなたの
言っていることは質的問題と量的問題をごっちゃにしているだけでしょう。
「できる」が、それは恐ろしくパフォーマンスが悪いものになる。或は途方もない
開発費がかかる。そういう問題は常に付きまとう。それは量的な問題であって、
昔ちょっと流行した金持ちプログラミングが許容される土台が整えば解消される。
それよりも重要な点は、質的に可能か否か？という点だ。
IT技術者って連中がそんな高尚なことやってるとは思えないがw、あなたの
言っていることは質的問題と量的問題をごっちゃにしているだけでしょう。
「できる」が、それは恐ろしくパフォーマンスが悪いものになる。或は途方もない
開発費がかかる。そういう問題は常に付きまとう。それは量的な問題であって、
昔ちょっと流行した金持ちプログラミングが許容される土台が整えば解消される。
それよりも重要な点は、質的に可能か否か？という点だ。
議論がずれてきてるよ
とりあえずレスつけるのやめて最初に戻れ
とりあえずレスつけるのやめて最初に戻れ
> IT技術者って連中がそんな高尚なことやってるとは思えないがw、あなたの
> 言っていることは質的問題と量的問題をごっちゃにしているだけでしょう。
ああ、ドカタSEの方、突然高尚な話題を振りまして御免なさい。
おいらは国立研の研究支援SEとかやってたもんで、
そこいら辺の問題には敏感です。
上記の計算量の問題は、単に予算があれば解決できるレベルではなく、
俗にNP問題と呼ばれる指数関数的に計算量、複雑性が増大するクラスの問題です。
このような問題の場合、例えば地球シミュレータクラスの計算機の100000倍の計算能力を
現時点で調達するのは事実上無理なので、それでは現時点では何を計算すべきか、
という問題整理を行う必要があります。
同様にいわゆる「業務系」と呼ばれる３K IT分野においても、
空理空論では実現可能なはずだが、
現実の組織/活動を前提に実現するのは難しい (現実の否定が必要になる)
といった問題にはしばしば直面する事と存じます。
いわく「経営者がもっと物わかりが良かったら・・・」「業務形態を根本的に変える事ができたら・・・」等々。
そういった、完全否定ができない前提条件の下で、
実現可能な改善策を提供する事は、一般のドカタIT技術者にも求められている使命かと存じますが、
いかがでしょうか
> 言っていることは質的問題と量的問題をごっちゃにしているだけでしょう。
ああ、ドカタSEの方、突然高尚な話題を振りまして御免なさい。
おいらは国立研の研究支援SEとかやってたもんで、
そこいら辺の問題には敏感です。
上記の計算量の問題は、単に予算があれば解決できるレベルではなく、
俗にNP問題と呼ばれる指数関数的に計算量、複雑性が増大するクラスの問題です。
このような問題の場合、例えば地球シミュレータクラスの計算機の100000倍の計算能力を
現時点で調達するのは事実上無理なので、それでは現時点では何を計算すべきか、
という問題整理を行う必要があります。
同様にいわゆる「業務系」と呼ばれる３K IT分野においても、
空理空論では実現可能なはずだが、
現実の組織/活動を前提に実現するのは難しい (現実の否定が必要になる)
といった問題にはしばしば直面する事と存じます。
いわく「経営者がもっと物わかりが良かったら・・・」「業務形態を根本的に変える事ができたら・・・」等々。
そういった、完全否定ができない前提条件の下で、
実現可能な改善策を提供する事は、一般のドカタIT技術者にも求められている使命かと存じますが、
いかがでしょうか
オブジェクト指向の何が嫌われてるのか教えてくれ
>>373
こんなｽﾚが誕生するから
こんなｽﾚが誕生するから
つか、国内のオブジェクト指向業界で、
みんなに愛されてる奴なんて居るんか実際。
海外有名人、といった種類の距離感があったなら、
生臭く嫌な部分は見えなくなって、
「とってもだいしゅきぃ」って言えなくもないものかもしれんがｗ
みんなに愛されてる奴なんて居るんか実際。
海外有名人、といった種類の距離感があったなら、
生臭く嫌な部分は見えなくなって、
「とってもだいしゅきぃ」って言えなくもないものかもしれんがｗ
好き好き大好きオブジェクト指向ﾀﾝ
ってなスレタイにして、OSｷｬﾗのXPﾀｿ (アキバblog等参照)に負けない
萌えｷｬﾗ設定すれば良し、と判断
ってなスレタイにして、OSｷｬﾗのXPﾀｿ (アキバblog等参照)に負けない
萌えｷｬﾗ設定すれば良し、と判断
結論：オブジェクト指向はキモい
オブジェクト指向ﾀｿは、妹属性を持つか否か？
UML図上において、妹属性はフィールドとすべきか、妹クラスの参照とすべきか、etc.
UML図上において、妹属性はフィールドとすべきか、妹クラスの参照とすべきか、etc.
381 ：Symbolics Genera環境下でLispﾀﾝの萌えエージェントきぼんぬ：2007/08/05(日) 21:50:41
しっかし。
Lisp解説の「同人誌」が出てるっつう話題には
さすがに引いたっけ。
Lisp業界＝同人誌ヲタかよ！
Lisp解説の「同人誌」が出てるっつう話題には
さすがに引いたっけ。
Lisp業界＝同人誌ヲタかよ！
研修で継承を説明する際に使えそうだな。
派手で可愛いビューたんと
眼鏡っ子で奥手なモデルたんと
この二人の仲を取り持つコントローラーたんが
相互にメッセージを送りあって実現するのがMVCアーキテクチャ
眼鏡っ子で奥手なモデルたんと
この二人の仲を取り持つコントローラーたんが
相互にメッセージを送りあって実現するのがMVCアーキテクチャ
>>384
ﾛ、ﾛ、ロシア娘はそんなにアレが激しいでありますか？
ﾛ、ﾛ、ロシア娘はそんなにアレが激しいでありますか？
>>386
OH!YEAH!!
OH!YEAH!!
吸い取られるぅぅぅぅぅ
ということで
オブジェクト指向＝萌え＆激しいロシア娘
ということに決定いたしました。
オブジェクト指向＝萌え＆激しいロシア娘
ということに決定いたしました。
好みが分かれそうだな……
オブジェクト指向だとコード量は増えるからな。
そのくせ大手ベンダーは未だに
ステップ数とバグ数の比率を気にする文化。
言語や方法が変わっても測定方法は変わらないというイビツな構造。
オブジェクト指向の特性を理解せずに、
今までと同じように品質と納期とコストを求めようとするしな。
まったくどうなってんだ、と。
毎回毎回同じような失敗プロジェクトをしてるくせに、
毎回同じ結果を求めようとする。
そのくせ大手ベンダーは未だに
ステップ数とバグ数の比率を気にする文化。
言語や方法が変わっても測定方法は変わらないというイビツな構造。
オブジェクト指向の特性を理解せずに、
今までと同じように品質と納期とコストを求めようとするしな。
まったくどうなってんだ、と。
毎回毎回同じような失敗プロジェクトをしてるくせに、
毎回同じ結果を求めようとする。
>>390
まさにオブジェクト指向そのものじゃないかwww
まさにオブジェクト指向そのものじゃないかwww
393 ：仕様書無しさん：2007/08/05(日) 22:13:20
> そのくせ大手ベンダーは未だに
> ステップ数とバグ数の比率を気にする文化。
> 言語や方法が変わっても測定方法は変わらないというイビツな構造。
一応マジレスしとくと、
それは構内請負ベースの大規模開発固有の「文化」だと思うよ。
まともな開発者が主導するプロジェクトでは、
今更ステップ数など相手にはしない。
> ステップ数とバグ数の比率を気にする文化。
> 言語や方法が変わっても測定方法は変わらないというイビツな構造。
一応マジレスしとくと、
それは構内請負ベースの大規模開発固有の「文化」だと思うよ。
まともな開発者が主導するプロジェクトでは、
今更ステップ数など相手にはしない。
> 構内請負ベースの大規模開発
より正確に言うと、
協力会社とやらを召集して画面数×数倍の人月をかけるような
レガシーで３Kでリスキーな開発を好むオッサン達が取り仕切るような
しょーもない現場の事。
おｲらがメーカ系SIerに居た時も、あいつらは別世界の人間だったっけ。
より正確に言うと、
協力会社とやらを召集して画面数×数倍の人月をかけるような
レガシーで３Kでリスキーな開発を好むオッサン達が取り仕切るような
しょーもない現場の事。
おｲらがメーカ系SIerに居た時も、あいつらは別世界の人間だったっけ。
396 ：仕様書無しさん：2007/08/06(月) 01:30:04
経験からすると、
オブジェクト指向の存在を初めて知ったとき
感動したものだがな。
オブジェクト指向を理解したとき
また、大きな感動をしたものだがな。
そして、好きになったものだがな。
感動したことがないやつらは、
好きになれるはずはないがな。
オブジェクト指向の存在を初めて知ったとき
感動したものだがな。
オブジェクト指向を理解したとき
また、大きな感動をしたものだがな。
そして、好きになったものだがな。
感動したことがないやつらは、
好きになれるはずはないがな。
がながながながな
関数ポインタくらい用意しとけ>java
ここに居る奴って、↓みたいな発言が好きだねぇ
----------------------------------------
371 名前： 仕様書無しさん [sage] 投稿日： 2007/08/05(日) 21:32:45
議論がずれてきてるよ
とりあえずレスつけるのやめて最初に戻れ
----------------------------------------
こんな事ばかり言っているから、相手にされないんだろお前
----------------------------------------
371 名前： 仕様書無しさん [sage] 投稿日： 2007/08/05(日) 21:32:45
議論がずれてきてるよ
とりあえずレスつけるのやめて最初に戻れ
----------------------------------------
こんな事ばかり言っているから、相手にされないんだろお前
>>401
ずれるのは論点だろ
ずれるのは論点だろ
403 ：仕様書無しさん：2007/08/06(月) 07:58:17
>>396
感動したはｗｗｗｗｗ
感動したはｗｗｗｗｗ
404 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/06(月) 09:21:33
休暇を取っていたので流れてしまったが、オブジェクト指向の説明は97で分かったかな？
ついたレスが、ボケなのか本気なのか分からないので、とりあえず無視しておこう。
次はOOが嫌われている理由か。
C習得者がJavaを勉強する過程で良く聞く話が以下の点だ。
・クラスが多すぎて何を使うのか分からない。
・Exceptionがgotoみたいで嫌だ。
・フィールド変数がグローバル変数みたいで嫌だ。
・ゲッター、セッターメソッドのような、単純なメソッドが大量に発生するのが嫌だ。
・継承されると、どのメソッドが呼ばれるのかが分かりにくくて、処理を追うのが困難だ。
・新しい事を覚えるのが面倒だ。
ついたレスが、ボケなのか本気なのか分からないので、とりあえず無視しておこう。
次はOOが嫌われている理由か。
C習得者がJavaを勉強する過程で良く聞く話が以下の点だ。
・クラスが多すぎて何を使うのか分からない。
・Exceptionがgotoみたいで嫌だ。
・フィールド変数がグローバル変数みたいで嫌だ。
・ゲッター、セッターメソッドのような、単純なメソッドが大量に発生するのが嫌だ。
・継承されると、どのメソッドが呼ばれるのかが分かりにくくて、処理を追うのが困難だ。
・新しい事を覚えるのが面倒だ。
405 ：仕様書無しさん：2007/08/06(月) 10:01:34
OOが嫌われている
というよりは
OO信者が嫌われているだけだと思う
というよりは
OO信者が嫌われているだけだと思う
406 ：仕様書無しさん：2007/08/06(月) 10:21:03
オブジェクト指向は「ゆとり教育」みたいなもの
演習率を3で丸めてしまうアホのための仕組み
演習率を3で丸めてしまうアホのための仕組み
と、演習率を3で丸めてしまうアホが申しております。
演習率(←何故か二文節に分割しないと変換できない)
381 名前：Symbolics Genera環境下でLispﾀﾝの萌えエージェントきぼんぬ [sage]：2007/08/05(日) 21:50:41
しっかし。
Lisp解説の「同人誌」が出てるっつう話題には
さすがに引いたっけ。
Lisp業界＝同人誌ヲタかよ！
384 名前：仕様書無しさん [sage]：2007/08/05(日) 21:56:29
>>381
次はMacsyma＆MAXIMAの萌え同人誌を期待。
60過ぎて20代のロシア娘と結婚し、腹情死を遂げたMAXIMAメンテナーに敬意を表して・・・
389 名前：仕様書無しさん [sage]：2007/08/05(日) 22:05:46
ということで
オブジェクト指向＝萌え＆激しいロシア娘
ということに決定いたしました。
しっかし。
Lisp解説の「同人誌」が出てるっつう話題には
さすがに引いたっけ。
Lisp業界＝同人誌ヲタかよ！
384 名前：仕様書無しさん [sage]：2007/08/05(日) 21:56:29
>>381
次はMacsyma＆MAXIMAの萌え同人誌を期待。
60過ぎて20代のロシア娘と結婚し、腹情死を遂げたMAXIMAメンテナーに敬意を表して・・・
389 名前：仕様書無しさん [sage]：2007/08/05(日) 22:05:46
ということで
オブジェクト指向＝萌え＆激しいロシア娘
ということに決定いたしました。
411 ：仕様書無しさん：2007/08/06(月) 14:05:42
創価教が嫌われているというより
創価信者が嫌われている。
いやいや、一番問題なのは犬作
創価信者が嫌われている。
いやいや、一番問題なのは犬作
>>404
簡単に貶せそうなものばかりそろえたなｗ
簡単に貶せそうなものばかりそろえたなｗ
休暇と書いてほとぼりと読むｗ
414 ：仕様書無しさん：2007/08/06(月) 21:44:01
OOで大事なのはOOPじゃなくOODなんだよ、
OOPは出来なくて問題ないが、OODが出来ないとPG/SEっていえないぞ。
OO、それはOODだ、OOPではない。
立派な人になりたければ池田犬作先生に帰依しろ！！！！！
OOPは出来なくて問題ないが、OODが出来ないとPG/SEっていえないぞ。
OO、それはOODだ、OOPではない。
立派な人になりたければ池田犬作先生に帰依しろ！！！！！
416 ：仕様書無しさん：2007/08/06(月) 22:14:35
ま、オブジェクト指向も
わからんやつと一緒に仕事するのは
実際問題きっついよね
自称Java職人でＯＯわかってないやつとか
どんだけ〜ｗｗｗｗ
わからんやつと一緒に仕事するのは
実際問題きっついよね
自称Java職人でＯＯわかってないやつとか
どんだけ〜ｗｗｗｗ
417 ：仕様書無しさん：2007/08/06(月) 22:22:23
>>416
とりあえず、おまえ、おじゃばさまに弟子入りしろ
とりあえず、おまえ、おじゃばさまに弟子入りしろ
みんな大きなソフト作ってるんだね
419 ：仕様書無しさん：2007/08/06(月) 23:54:37
>>417
だが断る！
だが断る！
420 ：仕様書無しさん：2007/08/07(火) 00:05:57
俺も断る！
421 ：sage：2007/08/07(火) 01:06:24
オジャバクト指向は嫌いだがな
422 ：a ◆cgN2BzM20g ：2007/08/07(火) 01:11:44
a
おじゃばは「会話上達本」とかこういった本読んどくといいかも。
上の方でも散々指摘されてるけど、
おじゃばの文面は人をイライラさせる書き方なんだわ。
技術についてはこだわりがあった方がいいけど、
それを相手に伝えるのであれば、ちゃんと伝えないとね。
自分の口調のせいで孤立するより、会話が成立する方がいいでしょ。
上の方でも散々指摘されてるけど、
おじゃばの文面は人をイライラさせる書き方なんだわ。
技術についてはこだわりがあった方がいいけど、
それを相手に伝えるのであれば、ちゃんと伝えないとね。
自分の口調のせいで孤立するより、会話が成立する方がいいでしょ。
なんか自意識過剰なのがいるな
構造化は確実にわかってないよな、おじゃば。
427 ：仕様書無しさん：2007/08/07(火) 09:04:45
>426
OO以前というか、構造化ってOOに内包される要素でしょ。
OO以前というか、構造化ってOOに内包される要素でしょ。
428 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/07(火) 09:04:48
オブジェクト指向プログラミングも、構造化プログラミングもそんなに難しい物ではない。
内容についても我流でもこだわりでもなく、一般的な事を言っているだけだ。
ちなみに俺が言っているオブジェクト指向は「オブジェクト指向プログラミング（OOP）」の事で、
「オブジェクト指向設計（OOD）」の事ではない。
構造化も「構造化プログラミング」の事で、「構造化設計」の事ではない。
実装寄りと言っている人がいるのはそのためだろう。
内容についても我流でもこだわりでもなく、一般的な事を言っているだけだ。
ちなみに俺が言っているオブジェクト指向は「オブジェクト指向プログラミング（OOP）」の事で、
「オブジェクト指向設計（OOD）」の事ではない。
構造化も「構造化プログラミング」の事で、「構造化設計」の事ではない。
実装寄りと言っている人がいるのはそのためだろう。
実装方法なんて、どうでもいいよ。
派遣の連中使って量産するだけだからな。
動かなきゃ動くように直させるだけだしな。
それより、設計とかちゃんとやっておかないと、痛い目に合うのは自分だからな。
派遣の連中使って量産するだけだからな。
動かなきゃ動くように直させるだけだしな。
それより、設計とかちゃんとやっておかないと、痛い目に合うのは自分だからな。
実装がどうでもいいって、意味不明なんだけど
ゴミみたいな実装されちゃったら設計の意味ないじゃん
ゴミみたいな実装されちゃったら設計の意味ないじゃん
431 ：仕様書無しさん：2007/08/07(火) 09:38:27
そりゃ設計の粒度にもよるが、実装者が設計無視したらどうしようもないし。
つうか、Pだけを語るってのは実務的じゃないがきのすることでしょ。
不可分なんだから。
つうか、Pだけを語るってのは実務的じゃないがきのすることでしょ。
不可分なんだから。
不可分なのはあくまでプログラム設計とOOPだろ
OOAやらOODをPに落とし込むのは通常一工夫も二工夫も必要なんだが
実装者が設計無視とかいいながらOODの話しようとしてるのには違和感があるな
OOAやらOODをPに落とし込むのは通常一工夫も二工夫も必要なんだが
実装者が設計無視とかいいながらOODの話しようとしてるのには違和感があるな
OOD オブジェクト指向設計 おぶじぇくとしこうせっけい
オブジェクトを中心とした設計手法の総称。
オブジェクト指向プログラミングとの名前の類似性により、
それらに関係があるとよく誤解されるが実際にはあまり関係はない。
オブジェクトを中心とした設計手法の総称。
オブジェクト指向プログラミングとの名前の類似性により、
それらに関係があるとよく誤解されるが実際にはあまり関係はない。
434 ：仕様書無しさん：2007/08/07(火) 14:06:26
オブジェクト指向って４，５０年前からあったんだよなぁ。
それでも浸透しない理由。
ソフトウェア工学を理解できる、かつ、有効性がを理解できるやつが、極めて少ないってことでしょ。
UMLだってまともに書ける人探すのだって結構大変なのに。
それでも浸透しない理由。
ソフトウェア工学を理解できる、かつ、有効性がを理解できるやつが、極めて少ないってことでしょ。
UMLだってまともに書ける人探すのだって結構大変なのに。
435 ：仕様書無しさん：2007/08/07(火) 14:09:39
436 ：sage：2007/08/07(火) 19:39:40
OODとOOPは自信を持ってできると言える
だが、OOAは明確にはやったことはない。
というか、できる人(やっている人)に出会ったことがない。
そいいう人がいないのは地方だけなのかな？
ファウラーのアナリシスパターンの本とか難しすぎなんだが
だが、OOAは明確にはやったことはない。
というか、できる人(やっている人)に出会ったことがない。
そいいう人がいないのは地方だけなのかな？
ファウラーのアナリシスパターンの本とか難しすぎなんだが
sageすらまともにできない奴にOOができるとは到底思えない
>>437 同意ｗ
「実装は関係ない」は突き詰めるとプログラミングとは関係ないまで行きそうだな
OODが出来るがOOAをやったことがないって一体どういうことよ？
普通は在り物のミドルとかフレームワーク使うからOODはやらないけど、
OOAはアプリ固有だからやるしかないだろ。
普通は在り物のミドルとかフレームワーク使うからOODはやらないけど、
OOAはアプリ固有だからやるしかないだろ。
441 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/07(火) 22:42:28
構造化については、「構造化分析」「構造化設計」「構造化プログラミング」とあり内容も目的も違うが、
それぞれ明確に定義されているので自分で調べてくれ。
問題は「オブジェクト指向設計」だ。
オブジェクト指向設計が理解されにくい問題点は2つある。
一つ目は定義が曖昧な事だ。元々、構造化に対して同様の分類をしただけで、
オブジェクト指向分析に対してはほとんど名前だけ、オブジェクト指向設計に対しても、
「オブジェクト指向プログラミングの手法を設計で使用する」程度の定義しかない。
そのため人によって認識が異り、統一的な説明が難しい。
次にオブジェクト指向設計が有効に作用する分野が少ない事だ。
結論から言うと、シミュレーションの分野には向くが、多くの一般業務の分野には向かない。
それぞれ明確に定義されているので自分で調べてくれ。
問題は「オブジェクト指向設計」だ。
オブジェクト指向設計が理解されにくい問題点は2つある。
一つ目は定義が曖昧な事だ。元々、構造化に対して同様の分類をしただけで、
オブジェクト指向分析に対してはほとんど名前だけ、オブジェクト指向設計に対しても、
「オブジェクト指向プログラミングの手法を設計で使用する」程度の定義しかない。
そのため人によって認識が異り、統一的な説明が難しい。
次にオブジェクト指向設計が有効に作用する分野が少ない事だ。
結論から言うと、シミュレーションの分野には向くが、多くの一般業務の分野には向かない。
まあ
ＵＭＬは
意味ねえな
ＵＭＬは
意味ねえな
UML理解してから考えても遅くはないよ君
UMLの０．．１とか１とか０．．．ｎとか、それぞれの意味は分かるが、
いまだになにをとらえて１としているのか、０．．１としているのかわからんｗ
いまだになにをとらえて１としているのか、０．．１としているのかわからんｗ
>>441
なんだそりゃ？
一般業務の分野に向かない？
そりゃお前が仕事の仕方分かってねーからだろ。
「設計はしねーけど実装はする」
「設計をちゃんとやってないから実装したあとに変更が多数入る」
「でもこのやり方はOOだと対応が容易だから問題なし」
これがお前のやり方だと以前言ってたが、
これは業界一般ではデスマーチって言うんだよ。
いいからお前は”仕事の進め方”を少しは学習しろ。
新人相手でふんぞり返ってるだけでも本読む時間ぐらいあるだろ。
なんだそりゃ？
一般業務の分野に向かない？
そりゃお前が仕事の仕方分かってねーからだろ。
「設計はしねーけど実装はする」
「設計をちゃんとやってないから実装したあとに変更が多数入る」
「でもこのやり方はOOだと対応が容易だから問題なし」
これがお前のやり方だと以前言ってたが、
これは業界一般ではデスマーチって言うんだよ。
いいからお前は”仕事の進め方”を少しは学習しろ。
新人相手でふんぞり返ってるだけでも本読む時間ぐらいあるだろ。
>>446
システム側の図ならオブジェクトのインスタンス数と思えばだいたいわかるじゃん
システム側の図ならオブジェクトのインスタンス数と思えばだいたいわかるじゃん
>437
核心を衝いた
核心を衝いた
モデルもアーキテクチャもごっちゃにしてクラス図って呼ぶから混乱するんだ
書き方も書く意味も全然違うのに
書き方も書く意味も全然違うのに
ER図をいくら書いてもテーブル設計はうまくならんわな
モデル分析なんて極端な話DBのテーブル設計と似たようなもんだし
データの構造に柔軟性があるところと非永続データを扱うところが違う位だろ
そう考えるとUMLばっかりなんぼ書いてもモデル分析は一向に上達せん希ガス
モデル分析なんて極端な話DBのテーブル設計と似たようなもんだし
データの構造に柔軟性があるところと非永続データを扱うところが違う位だろ
そう考えるとUMLばっかりなんぼ書いてもモデル分析は一向に上達せん希ガス
ER図とかUMLって図→実装→図
を経験で繰り返す＋１プロジェクトでも繰り返すから価値があるんじゃないの？
一発で完璧な設計なんて無理だしそこに初めて経験の価値があると思うよ
を経験で繰り返す＋１プロジェクトでも繰り返すから価値があるんじゃないの？
一発で完璧な設計なんて無理だしそこに初めて経験の価値があると思うよ
UMLはアホなドカタPG向けの設計図で分析のためのツールじゃないだろ
ER図かー
サーバーのどっかに最初のころに作った奴があるかもしれんなー
保守？何それ？
って奴がリーダーやってるとこんなもんか
サーバーのどっかに最初のころに作った奴があるかもしれんなー
保守？何それ？
って奴がリーダーやってるとこんなもんか
458 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/08(水) 09:52:21
>>447
オブジェクト指向プログラミングをするから、オブジェクト指向設計をしなければならないと言う事ではない。
構造化設計→オブジェクト指向プログラミングでも問題ない。
また447は機能設計と詳細設計の区別が曖昧なようだから言っておくが、
以前に言っていたのはオブジェクト指向プログラミングなので、詳細設計の事だ。
詳細設計というのはクラスやメソッド分割を言う。
今言っているのは、オブジェクト指向設計なので、機能設計のことだ。
機能設計というのは機能分割やDB設計、外部IF設計などを言う。
オブジェクト指向プログラミングをするから、オブジェクト指向設計をしなければならないと言う事ではない。
構造化設計→オブジェクト指向プログラミングでも問題ない。
また447は機能設計と詳細設計の区別が曖昧なようだから言っておくが、
以前に言っていたのはオブジェクト指向プログラミングなので、詳細設計の事だ。
詳細設計というのはクラスやメソッド分割を言う。
今言っているのは、オブジェクト指向設計なので、機能設計のことだ。
機能設計というのは機能分割やDB設計、外部IF設計などを言う。
自分で理解できてないことを調べてくれなどどぬかす。
自分で説明できないことは難しいとぬかす。
こんな教育係についた新人は哀れだのー。
みんな馬鹿じゃないからさっさと見切ってくだろーがね。
自分で説明できないことは難しいとぬかす。
こんな教育係についた新人は哀れだのー。
みんな馬鹿じゃないからさっさと見切ってくだろーがね。
どっちかっつーと自分でも何言ってるかわからんレベルのようにしか思えん
461 ：仕様書無しさん：2007/08/08(水) 12:45:49
だから、知ってる言葉を並べてるだけなんだって。
さるのじい。
さるのじい。
462 ：仕様書無しさん：2007/08/08(水) 14:52:16
>>458
なんか、根本を捕らえてないな。
なぜオブジェクト指向というものが生まれ、なぜUMLなどの設計技術ができたのかを捕らえてないように見える。
基本を抑えれば、外部設計だからとか内部設計だからってことはない。
なんか、根本を捕らえてないな。
なぜオブジェクト指向というものが生まれ、なぜUMLなどの設計技術ができたのかを捕らえてないように見える。
基本を抑えれば、外部設計だからとか内部設計だからってことはない。
オブジェクト指向そのものがなぜ生まれたかってのは、ありていには
「偶然生まれた」という他ないわな
「偶然生まれた」という他ないわな
プログラミング馬鹿
465 ：仕様書無しさん：2007/08/08(水) 18:38:39
UMLを学習する際に絶対はずされない図
それす
シーケンス図
馬鹿のひとつ覚えのようだな
それす
シーケンス図
馬鹿のひとつ覚えのようだな
466 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/08(水) 20:58:29
>>459
構造化分析、設計は基本情報処理に出てくるぐらい有名な内容だ。
試験勉強したことある人なら知っているだろうし、検索すればすぐに出て来る。
オブジェクト指向設計の説明はしているだろう？
「OOPの手法を設計で使用する」と。
読む以前に理解する気がないんじゃね？
>>460,461
用語が分からないのか？これも基本情報処理レベルの用語と内容だぞ。
設計の話を聞く前に、受けなくてもいいから、基本情報処理の勉強をした方がいいと思う。
>>462
オブジェクト指向が生まれたのは偶然ではなく、シュミレーションの分野で生まれた物が、
Windowシステム（Xを含む）の分野で広まったためだ。
UMLが生まれたのはコーディング否定派の学者が、モデルから直接プログラムを作ろうとして失敗した
名残が、設計分野で使われだしたからだ。
外部設計と内部設計の違いは、説明するまでもないだろう。これも基本情報処理レベルだ。
構造化分析、設計は基本情報処理に出てくるぐらい有名な内容だ。
試験勉強したことある人なら知っているだろうし、検索すればすぐに出て来る。
オブジェクト指向設計の説明はしているだろう？
「OOPの手法を設計で使用する」と。
読む以前に理解する気がないんじゃね？
>>460,461
用語が分からないのか？これも基本情報処理レベルの用語と内容だぞ。
設計の話を聞く前に、受けなくてもいいから、基本情報処理の勉強をした方がいいと思う。
>>462
オブジェクト指向が生まれたのは偶然ではなく、シュミレーションの分野で生まれた物が、
Windowシステム（Xを含む）の分野で広まったためだ。
UMLが生まれたのはコーディング否定派の学者が、モデルから直接プログラムを作ろうとして失敗した
名残が、設計分野で使われだしたからだ。
外部設計と内部設計の違いは、説明するまでもないだろう。これも基本情報処理レベルだ。
原理主義者の俺がきましたよｗ
オブジェクト指向は元はシミュレーションから生まれ、
はじめは気体分子のシミュレーションから（ｒｙ
オブジェクト指向は元はシミュレーションから生まれ、
はじめは気体分子のシミュレーションから（ｒｙ
おれも嫌いだな。
なんか媚びすぎというか声が嫌い。うるさすぎなんだよ、タカタ。
つーかジャパネット思考なんてだれが持ってんだ？
なんか媚びすぎというか声が嫌い。うるさすぎなんだよ、タカタ。
つーかジャパネット思考なんてだれが持ってんだ？
>>466
OO設計でよく使われるUMLは用件定義から
クラスの相関やインターフェースまで記述出来て、
残ってるのはメソッドの中身ぐらいだと思うが、
どれが機能設計でどれが詳細設計なんだ？
UMLはクソだ、というんで終わるだけならそれはそれで良いけどさ。
OO設計でよく使われるUMLは用件定義から
クラスの相関やインターフェースまで記述出来て、
残ってるのはメソッドの中身ぐらいだと思うが、
どれが機能設計でどれが詳細設計なんだ？
UMLはクソだ、というんで終わるだけならそれはそれで良いけどさ。
>>466
＞オブジェクト指向が生まれたのは偶然ではなく、シュミレーションの分野で生まれた物が、
＞Windowシステム（Xを含む）の分野で広まったためだ。
＞UMLが生まれたのはコーディング否定派の学者が、モデルから直接プログラムを作ろうとして失敗した
＞名残が、設計分野で使われだしたからだ。
こんな事実の羅列が根本なわけないだろ。
設計思想とか採用したアプローチとかそういう方向から説明しないと意味ない。
＞オブジェクト指向が生まれたのは偶然ではなく、シュミレーションの分野で生まれた物が、
＞Windowシステム（Xを含む）の分野で広まったためだ。
＞UMLが生まれたのはコーディング否定派の学者が、モデルから直接プログラムを作ろうとして失敗した
＞名残が、設計分野で使われだしたからだ。
こんな事実の羅列が根本なわけないだろ。
設計思想とか採用したアプローチとかそういう方向から説明しないと意味ない。
ぶっちゃけ最初の思想なんてどうでもよくなってきてね？
はじめはシミュ（ｒｙ
設計思想 = 動けばいいやｗ
だからゲームの業界では２０年も前からオブジェクト指向やってんぞ。
> はじめは気体分子のシミュレーションから（ｒｙ
それはねぇな。
アボガドロ数オーダー＝マクロスケールどころか、
数万分子単位のメゾスコピックな振舞いだって、
今ですらシミュレーションは困難だろｗ
やっぱりバカの薀蓄はバカなりに馬鹿げた(ryaku
閑話休題。
国内でOO派が弱い原因は、なんとなく判った。
あーゆー考えを推し進めるべき主体っつうーのは、
最初はユニークなアイデアを持った研究者、
次はベンチャー系やお子様コンサル層みたいな
怖いもの知らずで妙に自信たっぷりの奴らであるべきなんだ。
業務系だ、セキュリティだ、請負業務のヒエラルキーだ、
なんていう世の中のネガティブ面や難しい面を知らずに、
理想で突っ走れる年代。
国内のOOの主力なんて、じじいばっかだろ。
だからブレークしねぇんだよ。共感されねぇんだよ。
（俺もじじいなのかな？可愛くていつも女の子に囲まれてる自称研究者を目指してたんだが、20年前はｗ
それはねぇな。
アボガドロ数オーダー＝マクロスケールどころか、
数万分子単位のメゾスコピックな振舞いだって、
今ですらシミュレーションは困難だろｗ
やっぱりバカの薀蓄はバカなりに馬鹿げた(ryaku
閑話休題。
国内でOO派が弱い原因は、なんとなく判った。
あーゆー考えを推し進めるべき主体っつうーのは、
最初はユニークなアイデアを持った研究者、
次はベンチャー系やお子様コンサル層みたいな
怖いもの知らずで妙に自信たっぷりの奴らであるべきなんだ。
業務系だ、セキュリティだ、請負業務のヒエラルキーだ、
なんていう世の中のネガティブ面や難しい面を知らずに、
理想で突っ走れる年代。
国内のOOの主力なんて、じじいばっかだろ。
だからブレークしねぇんだよ。共感されねぇんだよ。
（俺もじじいなのかな？可愛くていつも女の子に囲まれてる自称研究者を目指してたんだが、20年前はｗ
>>475
なんだとてめー
http://ja.wikipedia.org/wiki/Simula
ちゃんとはじめはシミューレーションだって書いてあるだろ
ってまあ、なんか雑誌とかは発祥はどうでもいいみたいだし
なんか今の使われ方って馬鹿が勘違いして広めた結果もあってか全然別物になっちゃったみたいだしね
俺みたいな原理主義だとＪａｖａとか言語から馬鹿に見えて仕事し難いしね
みんなと話合わせるって面ではＯＯ原理主義者にはならないほうがいいと思うね
でもはじめにシミュ用途で出来たＯＯの根本的な設計思想はなんにでも応用が効くと思うんだよね
俺にとってのオブジェクト指向の一番いい部分ってのはわずらわしい設計やら図やら覚えることじゃなくて
一番シンプルなこの部分だと思うんだよね
そんだけｗ
でもなんかもう勝手にしやがれ感はあるなｗ
なんだとてめー
http://ja.wikipedia.org/wiki/Simula
ちゃんとはじめはシミューレーションだって書いてあるだろ
ってまあ、なんか雑誌とかは発祥はどうでもいいみたいだし
なんか今の使われ方って馬鹿が勘違いして広めた結果もあってか全然別物になっちゃったみたいだしね
俺みたいな原理主義だとＪａｖａとか言語から馬鹿に見えて仕事し難いしね
みんなと話合わせるって面ではＯＯ原理主義者にはならないほうがいいと思うね
でもはじめにシミュ用途で出来たＯＯの根本的な設計思想はなんにでも応用が効くと思うんだよね
俺にとってのオブジェクト指向の一番いい部分ってのはわずらわしい設計やら図やら覚えることじゃなくて
一番シンプルなこの部分だと思うんだよね
そんだけｗ
でもなんかもう勝手にしやがれ感はあるなｗ
＞ ちゃんとはじめはシミューレーションだって書いてあるだろ
おまえがバカだという事をよく再確認できた
これってさ、Wikipediaのエントリー書いた奴が勝手に気体分子の話出してるだけだろ。
実際には気象シミュレーションやってた人たちだったと思うよ。
うーん、俺とOOって、環境科学方面でもつながりがあったんだな。今になって気付いた。
俺ってもしかしてOO業界のエリート？
おまえがバカだという事をよく再確認できた
これってさ、Wikipediaのエントリー書いた奴が勝手に気体分子の話出してるだけだろ。
実際には気象シミュレーションやってた人たちだったと思うよ。
うーん、俺とOOって、環境科学方面でもつながりがあったんだな。今になって気付いた。
俺ってもしかしてOO業界のエリート？
ﾌﾟｹﾞﾗ
気象シミュレーションではなく、
もっと抽象的に「オペレーションズリサーチ(OR)」って書いてあるけどｗ
気象シミュレーションではなく、
もっと抽象的に「オペレーションズリサーチ(OR)」って書いてあるけどｗ
ちょっと話題が高尚になるが。
Simulaの開発者の一人 Ole-Johan Dahlって、
オブジェクト指向を扱う形式手法もやってたんだね。
一体なんて手法なんだろう。
久々にOO関係で、真面目に考えておきたいテーマの話題にぶつかった
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%AB%E3%83%A8%E3%83%8F%E3%83%B3%E3%83%BB%E3%83%80%E3%83%BC%E3%83%AB
Simulaの開発者の一人 Ole-Johan Dahlって、
オブジェクト指向を扱う形式手法もやってたんだね。
一体なんて手法なんだろう。
久々にOO関係で、真面目に考えておきたいテーマの話題にぶつかった
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%AB%E3%83%A8%E3%83%8F%E3%83%B3%E3%83%BB%E3%83%80%E3%83%BC%E3%83%AB
>>475 は抽象化をなんだと思ってるんだ。
だいたい気体分子のシミュレートだってとりあえず100や1000のオーダーからでも有意なデータが取れる。
>>476 だって、原理主義者と名乗りたいならまずケイのオブジェクト指向かストラウストラップのオブジェクト指向か
どちらかを明らかにしないと意味が通じない。
Javaだって実用言語として悩んだ末のプリミティブ導入であって、時代の要請があった事も忘れてはいけないぞ。
(もちろん言語設計者の不勉強ゆえにその障害をスマートに解決する事ができなかったと言う事実は否定しないが)
だいたい気体分子のシミュレートだってとりあえず100や1000のオーダーからでも有意なデータが取れる。
>>476 だって、原理主義者と名乗りたいならまずケイのオブジェクト指向かストラウストラップのオブジェクト指向か
どちらかを明らかにしないと意味が通じない。
Javaだって実用言語として悩んだ末のプリミティブ導入であって、時代の要請があった事も忘れてはいけないぞ。
(もちろん言語設計者の不勉強ゆえにその障害をスマートに解決する事ができなかったと言う事実は否定しないが)
∧⊂ヽ ／￣￣￣￣￣￣￣
(ﾟДﾟ,,)ﾉ ＜ オペレーションズリサーチ！ ！！
| ⊃| ＼＿＿＿＿＿＿＿
| |
⊂ノ〜
∪
川
ε= ☆ =3
(ﾟДﾟ,,)ﾉ ＜ オペレーションズリサーチ！ ！！
| ⊃| ＼＿＿＿＿＿＿＿
| |
⊂ノ〜
∪
川
ε= ☆ =3
482 ：仕様書無しさん：2007/08/09(木) 00:21:32
>>480
ぶっちゃけ、俺、そいつら両方違う気がすんだよね
正直、ケイもストラップもオブジェクト指向を理解してなかったと思う
だってそいつらのオブジェクト指向ちっともシミュレーションにいいと思わない
（この辺からすでにズレていた？）
まあ、このへんは学者、語るために誤魔化してたんだろう・・・
Ｃ＋＋もなんか違う方向いったと思うぜ
俺がＣ＋＋でいいと思うのはＣ言語＋クラスの部分だけだし
はじめの気体分子の例しか俺のオブジェクト指向ってピンとこない
見えるもんを見えるように組むってただそんだけのような気がすんだよね
少なくともはじめの設計思想はそんなところだと思うぜ
ぶっちゃけ、俺、そいつら両方違う気がすんだよね
正直、ケイもストラップもオブジェクト指向を理解してなかったと思う
だってそいつらのオブジェクト指向ちっともシミュレーションにいいと思わない
（この辺からすでにズレていた？）
まあ、このへんは学者、語るために誤魔化してたんだろう・・・
Ｃ＋＋もなんか違う方向いったと思うぜ
俺がＣ＋＋でいいと思うのはＣ言語＋クラスの部分だけだし
はじめの気体分子の例しか俺のオブジェクト指向ってピンとこない
見えるもんを見えるように組むってただそんだけのような気がすんだよね
少なくともはじめの設計思想はそんなところだと思うぜ
オブジェクト指向言語の形式化
っつうテーマは、俺も10年ほど前にずいぶん気になっていたなあ。
っつうテーマは、俺も10年ほど前にずいぶん気になっていたなあ。
485 ：仕様書無しさん：2007/08/09(木) 00:25:11
今のグローバルスタンダードはOOで、そして、これは強力なITの武器である。
しかし、OOは欧米の論理的思考を超活用する手法で、感情的思考が中心の日本人の思考には合わない。
故に日本のITドカタはOOを使いこなせないでいる。
OOを理解し使いこなしたいなら、感情的思考を捨て論理的思考を磨け！
しかし、OOは欧米の論理的思考を超活用する手法で、感情的思考が中心の日本人の思考には合わない。
故に日本のITドカタはOOを使いこなせないでいる。
OOを理解し使いこなしたいなら、感情的思考を捨て論理的思考を磨け！
定義が荒れるオブジェクト指向が現場でまともに活用できるわけがない
とりあえず、>>483本人がさっきから書いている駄文は全部スルーして
しばらくモノローグモードでいろいろ書こうと思う。
その目的はいくつかあって、
1. 今やってる仕事で人集めをしたい。
ついては、世の中の底辺部に対して話題と展望を提供して、
そっから上がってくるおっちょこちょいを捕まえて仕事に取り込みたい。
2. OO関係最近元気なさ杉だから、そろそろテコ入れしたい
3. その他：しばらく安定した生活を送れそうだから、
俺本来の主旨に戻って、私的に研究生活など送りたい
というあたり。
まあ焦らず急がず、週数件の見積もりと提案の合間にいろいろ書いてこうか、と。
しばらくモノローグモードでいろいろ書こうと思う。
その目的はいくつかあって、
1. 今やってる仕事で人集めをしたい。
ついては、世の中の底辺部に対して話題と展望を提供して、
そっから上がってくるおっちょこちょいを捕まえて仕事に取り込みたい。
2. OO関係最近元気なさ杉だから、そろそろテコ入れしたい
3. その他：しばらく安定した生活を送れそうだから、
俺本来の主旨に戻って、私的に研究生活など送りたい
というあたり。
まあ焦らず急がず、週数件の見積もりと提案の合間にいろいろ書いてこうか、と。
はじめはシミュレーション用として――
うんぬん語る奴多すぎ。
５０年も前の考え方で縛られる必要ないだろ。
話は簡単なんだよ。
１．オブジェクト指向を理解している技術者が少ない。
↓
２．言語仕様だけの知識でも物は作れる。
以下、１〜２のループしてるだけ。
おまぃらがどんなに優秀で学習好きでも、
周りがそうでないなら知識を生かす場が無いってこと。
うんぬん語る奴多すぎ。
５０年も前の考え方で縛られる必要ないだろ。
話は簡単なんだよ。
１．オブジェクト指向を理解している技術者が少ない。
↓
２．言語仕様だけの知識でも物は作れる。
以下、１〜２のループしてるだけ。
おまぃらがどんなに優秀で学習好きでも、
周りがそうでないなら知識を生かす場が無いってこと。
おじゃばさまが構造化手法にかぶれててワロタ。
結局、このスレはOOP自体を否定してる奴はほとんどいないのに
OOA/OODを理解して実践してる奴もいないから話が空回りして
延々と不毛なレスが垂れ流されるんだな。
結局、このスレはOOP自体を否定してる奴はほとんどいないのに
OOA/OODを理解して実践してる奴もいないから話が空回りして
延々と不毛なレスが垂れ流されるんだな。
>５０年も前の考え方で縛られる必要ないだろ。
俺もそう思う
現場では原理原則なんてどうでもよくて、アプリ開発する上で便利な要素を
オブジェクト指向から拾って使えばいいだけ
俺もそう思う
現場では原理原則なんてどうでもよくて、アプリ開発する上で便利な要素を
オブジェクト指向から拾って使えばいいだけ
でも現場は派遣だらけなのでプロジェクトの度に文字操作関数を一から書いているという現実
OOPできるプログラマがそろっていても
OOA，OODをできるプロマネなりリーダーなりが
いないケースが多い気がしる
OOA，OODをできるプロマネなりリーダーなりが
いないケースが多い気がしる
ガンダムＯＯ
495 ：仕様書無しさん：2007/08/09(木) 04:37:14
すいません８ビットのＢＡＳＩＣとかでもオブジェクト指向とかあるんですか？
そもそも「８ビットのＢＡＳＩＣ」というのが意味不明なんだが
TINY BASICみたいなのでも16bitの整数くらいは扱えるしなあ
TINY BASICみたいなのでも16bitの整数くらいは扱えるしなあ
498 ：仕様書無しさん：2007/08/09(木) 09:00:59
UMLを設計手法とか技法とかいっちゃうやつって、UMLを理解してないだろ？
ただの記法であって、それを記述する脳みそはUMLのどこにも定義されてないが。ｗ
ただの記法であって、それを記述する脳みそはUMLのどこにも定義されてないが。ｗ
499 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/09(木) 10:02:25
>>470
シミュレーション分野で発生した理由は、属性の違いにより結果を変えたいと言う事と、抽象化された
オブジェクトをベースにして、色々なオブジェクトを作りたいと言う事のためだ。
ウィンドウシステムの分野で広まったのは、ベースのウィンドウにボタンボタンを付けたり、
メニューを書き換えたりと言う作業が、オブジェクト指向の特徴に一致したためだ。
UMLが広まったのは、ドキュメント統一運動の人がUMLに目を付けたためだが、成功しているとは言い難い。
UMLには大量の形式があるが、使われているのは、ユースケース図、シーケンス図、クラス図程度だ。
UMLだけでは設計書には不十分だし、UML使わなくても設計出来る。
現実の使われ方としては、提出用書類か新人研修だろう。
>>475
日本でOOは弱い訳ではない。分野や人による。
OOを推し進めなければならないのは、20年PGやってるような人だ。
シミュレーション分野で発生した理由は、属性の違いにより結果を変えたいと言う事と、抽象化された
オブジェクトをベースにして、色々なオブジェクトを作りたいと言う事のためだ。
ウィンドウシステムの分野で広まったのは、ベースのウィンドウにボタンボタンを付けたり、
メニューを書き換えたりと言う作業が、オブジェクト指向の特徴に一致したためだ。
UMLが広まったのは、ドキュメント統一運動の人がUMLに目を付けたためだが、成功しているとは言い難い。
UMLには大量の形式があるが、使われているのは、ユースケース図、シーケンス図、クラス図程度だ。
UMLだけでは設計書には不十分だし、UML使わなくても設計出来る。
現実の使われ方としては、提出用書類か新人研修だろう。
>>475
日本でOOは弱い訳ではない。分野や人による。
OOを推し進めなければならないのは、20年PGやってるような人だ。
教訓：
ステレオタイプが強いかつ頭が悪いかつ人の話を聞かないって救いようがないな
このアホコテみたいに
ステレオタイプが強いかつ頭が悪いかつ人の話を聞かないって救いようがないな
このアホコテみたいに
＞現実の使われ方としては、提出用書類か新人研修だろう。
なんかUMLじゃなくておじゃば本人の使われ方みたいだな。
自分がマンセーするOOが役立つ仕事に縁がない恨みかね。
OOじゃなくておじゃばが役に立たないんだっつーのｗ
なんかUMLじゃなくておじゃば本人の使われ方みたいだな。
自分がマンセーするOOが役立つ仕事に縁がない恨みかね。
OOじゃなくておじゃばが役に立たないんだっつーのｗ
503 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/09(木) 20:48:06
万能に見えるものほど何もしない
クラスで隠蔽化されすぎてて、単純な配列の値が何であるのかを知るために、
5つぐらいのソースをたどって、ようやく中身が分かった。
。。。こんなソースはﾎｼｭできません。
5つぐらいのソースをたどって、ようやく中身が分かった。
。。。こんなソースはﾎｼｭできません。
C++しか使わない開発者は、OOの利点がよく見えないんじゃね？
OOA/OODの成果物なんて、出来合いのライブラリやフレームワークの手厚い庇護無しじゃ
冗長すぎて実装する気になりゃしないし。
OOA/OODの成果物なんて、出来合いのライブラリやフレームワークの手厚い庇護無しじゃ
冗長すぎて実装する気になりゃしないし。
やっぱり実装はすごく大事なんだな
C++はOOだけじゃないからな
ジェネリック、メタプログラミング、関数型プログラミングと
様々なパラダイムのスタイルを組み合わせてやっと使えるようになる
ジェネリック、メタプログラミング、関数型プログラミングと
様々なパラダイムのスタイルを組み合わせてやっと使えるようになる
509 ：あるじゃーのん ◆0aR9pKWx3A ：2007/08/09(木) 21:41:09
気体分子の話は固体だからまあいいけど
気象である程度の気体の塊を扱うのってMpegのブロック単位の管理に似てる。
つまり並列処理に向いてるのか。
でも事務処理とかには向いてないかも。
並列目的じゃなければ普通にC言語で処理書いただけでいいし。
気象である程度の気体の塊を扱うのってMpegのブロック単位の管理に似てる。
つまり並列処理に向いてるのか。
でも事務処理とかには向いてないかも。
並列目的じゃなければ普通にC言語で処理書いただけでいいし。
オブジェクト指向という手法を強いる言語は糞。
511 ：あるじゃーのん ◆0aR9pKWx3A ：2007/08/09(木) 21:47:05
単純にファイルとか装置とかを処理で結ぶのに比べて
それの中身を細分化するのがオブジェクト指向なら、
単純処理と比較してシステムは２倍以上に複雑になって当然か。
それの中身を細分化するのがオブジェクト指向なら、
単純処理と比較してシステムは２倍以上に複雑になって当然か。
>>501
いや、考え方の根本（発祥）が腐ってたらそもそも駄目だろうｗ
スポーツやら競技やら名物やらそういうのとはちがって基本理念じゃん
ここを飛ばしていくら派生部分をどうにかしようとも糞を飾っても所詮糞
どうにもならん
それと、最近、原理主義者の俺もＯＯに疑問が湧いてきた
気体分子のリンクよく貼るの俺なんだけどさｗ
これ、何がいいんだ？
仮に気体分子Ｎ個、壁６枚（密閉空間を表現するために６枚）があったとして
気体分子自身のプログラムをクラスでまとめたとしても
一番複雑な部分は気体と気体の衝突部分（１対Ｎも含む）とか気体と壁の衝突部分（１対Ｎも含む）
それと衝突後の他オブジェクトへの影響やら衝突した部分の補正処理じゃん
別にクラスで気体分子だけをまとめるまでもなくこんな部分はテキトーに作り終わるんじゃねぇの？
正直、これだけみたときのオブジェクト指向って根本的な複雑さを何も解決できてないと思うぜ
いや、考え方の根本（発祥）が腐ってたらそもそも駄目だろうｗ
スポーツやら競技やら名物やらそういうのとはちがって基本理念じゃん
ここを飛ばしていくら派生部分をどうにかしようとも糞を飾っても所詮糞
どうにもならん
それと、最近、原理主義者の俺もＯＯに疑問が湧いてきた
気体分子のリンクよく貼るの俺なんだけどさｗ
これ、何がいいんだ？
仮に気体分子Ｎ個、壁６枚（密閉空間を表現するために６枚）があったとして
気体分子自身のプログラムをクラスでまとめたとしても
一番複雑な部分は気体と気体の衝突部分（１対Ｎも含む）とか気体と壁の衝突部分（１対Ｎも含む）
それと衝突後の他オブジェクトへの影響やら衝突した部分の補正処理じゃん
別にクラスで気体分子だけをまとめるまでもなくこんな部分はテキトーに作り終わるんじゃねぇの？
正直、これだけみたときのオブジェクト指向って根本的な複雑さを何も解決できてないと思うぜ
以上、ネタレスでした
抽象化なんだからオブジェクト指向でしかできないことは無い。
出来ないのは人間の能力が足りないから。能力が足りないから手法で補う。
出来ないのは人間の能力が足りないから。能力が足りないから手法で補う。
516 ：あるじゃーのん ◆0aR9pKWx3A ：2007/08/09(木) 23:45:19
ああ個体ね
シミュレーションして意味があるのはエンジンとか燃料電池の反応とか
化学変化を伴うもので個体数が変わっちゃうから難しいけど。
シミュレーションして意味があるのはエンジンとか燃料電池の反応とか
化学変化を伴うもので個体数が変わっちゃうから難しいけど。
オブジェクト指向では、物事ってレイヤと各レイヤ上でうごめくモデルで
表現されるわけじゃん
オブジェクト指向って別に、ひとかたまりのモデルが内包する複雑さの
軽減を目指してるわけじゃないよな
あくまで、あるモデルを考える時によそのモデルの内部的な複雑さから
開放されて自分のことだけに注力したいってことだよな
つまりは、シミュレーションとか気体分子の話が良く出てくるけど
オブジェクト指向がシミュレーションそのものに何か便利ってわけじゃ
なくて、シミュレーションのためのロジックに注力するために下位層の
コードを分離したかったって、ただそれだけだよな
表現されるわけじゃん
オブジェクト指向って別に、ひとかたまりのモデルが内包する複雑さの
軽減を目指してるわけじゃないよな
あくまで、あるモデルを考える時によそのモデルの内部的な複雑さから
開放されて自分のことだけに注力したいってことだよな
つまりは、シミュレーションとか気体分子の話が良く出てくるけど
オブジェクト指向がシミュレーションそのものに何か便利ってわけじゃ
なくて、シミュレーションのためのロジックに注力するために下位層の
コードを分離したかったって、ただそれだけだよな
>>517
はじめにオブジェクト指向を提案した奴とか
シミュで使ってた奴に何がよくてそんなもん使ってたのか
聞いてみるのが一番速いんだけどな
クラスにするのはわかったぜ
で、そのクラスよりも遥かにでかくて
素のままではオブジェクトとして扱え無い（無理矢理オブジェクトですって言えばそうだが・・・美しくない・・・）
気体分子同士の衝突時の処理や
壁と気体分子の衝突時の処理をどこに定義するのが
オブジェクト指向的にいいのか一度聞いてみたい気がするな
はじめにオブジェクト指向を提案した奴とか
シミュで使ってた奴に何がよくてそんなもん使ってたのか
聞いてみるのが一番速いんだけどな
クラスにするのはわかったぜ
で、そのクラスよりも遥かにでかくて
素のままではオブジェクトとして扱え無い（無理矢理オブジェクトですって言えばそうだが・・・美しくない・・・）
気体分子同士の衝突時の処理や
壁と気体分子の衝突時の処理をどこに定義するのが
オブジェクト指向的にいいのか一度聞いてみたい気がするな
>>518
つまり、エンベロープをどの様にオブジェクト指向に持ち込むかという話か。
一応、GOFのデザインパターン的にはオブザーバー(観測者)が判定して通知するのが王道だよな。
まともにやると、各オブジェクトが他の全オブジェクトの座標や影響を常に判断しなければいけないから
当時としては100%死亡。現在でもまず死亡。
シミュレートする際には各オブジェクトのパラメータを細かく変更して、何度も追試をしたくなる。
そのときにオブジェクト指向すると考えやすかったってだけじゃないかな。
オブジェクト指向だって、あくまで現実世界や、プログラマの理想世界を
コンピュータに写像するための一記法でしかないって考えるべきだろうな。
つまり、エンベロープをどの様にオブジェクト指向に持ち込むかという話か。
一応、GOFのデザインパターン的にはオブザーバー(観測者)が判定して通知するのが王道だよな。
まともにやると、各オブジェクトが他の全オブジェクトの座標や影響を常に判断しなければいけないから
当時としては100%死亡。現在でもまず死亡。
シミュレートする際には各オブジェクトのパラメータを細かく変更して、何度も追試をしたくなる。
そのときにオブジェクト指向すると考えやすかったってだけじゃないかな。
オブジェクト指向だって、あくまで現実世界や、プログラマの理想世界を
コンピュータに写像するための一記法でしかないって考えるべきだろうな。
なんでこのスレって異様なまでにアホなコテが寄りつくん？
ネタレスしてくれるやつがいるからだろうな。
あまりに噛み合わないと、年金システム何とかスレみたいになるけどｗ
あまりに噛み合わないと、年金システム何とかスレみたいになるけどｗ
522 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/10(金) 09:22:19
シミュレーションでは衝突計算のようにIFを統一すると言う利点とは別に、
既存のオブジェクトを継承して新たなオブジェクトを作成すると言う利点がある。
簡単に説明すると、紅茶を継承してミルクを追加してミルクティーにするとか、
レモンを追加してレモンティーにするとか。これらを個別に定義してたら大変だろう？
既存のオブジェクトを継承して新たなオブジェクトを作成すると言う利点がある。
簡単に説明すると、紅茶を継承してミルクを追加してミルクティーにするとか、
レモンを追加してレモンティーにするとか。これらを個別に定義してたら大変だろう？
オメー今時参考書レベル以下の文章で
誰を納得させたいん？
誰を納得させたいん？
説明になってねーよ。
ミルクティーとレモンティーは別のメニューだろうが。
ラーメンを継承して味噌ラーメンとタンメンができたわけでもあるまい。
ミルクティーとレモンティーは別のメニューだろうが。
ラーメンを継承して味噌ラーメンとタンメンができたわけでもあるまい。
その突っ込みもよくわからんが
おじゃばの ミルクティー extends 紅茶 に比べると
味噌ラーメン extends ラーメン はあんまり違和感ないな。
「紅茶」という言葉を「紅茶の様々な飲み方の総称」として捉えるなら
それで良いかも知れんが、俺はあくまで
「紅茶にミルクを合わせたのがミルクティー」
つまり、紅茶とミルクという別々の飲み物を合わせた物だと思う。
お店のメニューとしてなら、紅茶もミルクティーもラーメンも味噌ラーメンも
「メニュー」を継承すべきなんだろうし。
味噌ラーメン extends ラーメン はあんまり違和感ないな。
「紅茶」という言葉を「紅茶の様々な飲み方の総称」として捉えるなら
それで良いかも知れんが、俺はあくまで
「紅茶にミルクを合わせたのがミルクティー」
つまり、紅茶とミルクという別々の飲み物を合わせた物だと思う。
お店のメニューとしてなら、紅茶もミルクティーもラーメンも味噌ラーメンも
「メニュー」を継承すべきなんだろうし。
とするとだ、ミルクティーは紅茶とミルクを多重継承したものだが
味噌ラーメンはラーメンの味付けインタフェースを味噌で実装したモノになるわけだな。
チャーシューメンがラーメンを単純継承してチャーシューを付加したのとは違う。
なるほど、わかりやすいｗ
･･･タンメンは？
味噌ラーメンはラーメンの味付けインタフェースを味噌で実装したモノになるわけだな。
チャーシューメンがラーメンを単純継承してチャーシューを付加したのとは違う。
なるほど、わかりやすいｗ
･･･タンメンは？
ミルクティーは多重継承じゃなくてミルクを包含だろ。
自分なら紅茶ではなく水から始めるが。
水のブランドだっていまや星の数ほどあるんだから。
自分なら紅茶ではなく水から始めるが。
水のブランドだっていまや星の数ほどあるんだから。
物事を捉える範囲が明確じゃないのに何を継承するとかしないとかいう話なんてよくできるよな。
タイヤ製造工場と車製造工場ではタイヤの捕らえ方って違うってことに気がつけよ
タイヤ製造工場と車製造工場ではタイヤの捕らえ方って違うってことに気がつけよ
再三言ってるけど、客観的な視点を持たないモデルをいくら分析したって無意味だよ
サブジェクト指向じゃないんだから
動物<-哺乳類<-人間とかそういうのは、オブジェクト指向の理解を促すためのモノの例えであって
実際にこんなふうに分析するわけではない
サブジェクト指向じゃないんだから
動物<-哺乳類<-人間とかそういうのは、オブジェクト指向の理解を促すためのモノの例えであって
実際にこんなふうに分析するわけではない
中国で汚水をかけて発酵を早めた茶葉で作ったお茶でも，お茶はお茶だしなｗ
そうそう，モンゴルでは中国製ラーメンで死人が出たんだっけ。
>529>530はラーメンでひとくくりにしてればいいさ。
どうせ自分が食べるんじゃないだろうけど。
そうそう，モンゴルでは中国製ラーメンで死人が出たんだっけ。
>529>530はラーメンでひとくくりにしてればいいさ。
どうせ自分が食べるんじゃないだろうけど。
いったい何の話を
> 中国で汚水をかけて発酵を早めた茶葉で作ったお茶
しかし気に掛かるｗ 安い茶は危ないのか。
しかし気に掛かるｗ 安い茶は危ないのか。
>532
ラーメンの話。
ラーメンの話。
>532
え？
ラーメン喫茶を新規オープンするんだろ？
で，食の安全が問われる昨今，
トレーサビリティを前面に打ち出したメニュー作りをしようってときに，
>529>530といった自称ITコンサルが茶々を入れてきたわけだが。
どう考えてもおかしいのは連中のほうじゃないかと。
え？
ラーメン喫茶を新規オープンするんだろ？
で，食の安全が問われる昨今，
トレーサビリティを前面に打ち出したメニュー作りをしようってときに，
>529>530といった自称ITコンサルが茶々を入れてきたわけだが。
どう考えてもおかしいのは連中のほうじゃないかと。
でたｗ このスレ伝統のカオス状態。
味噌ラーメンをcreateした札幌にはこんな店がある。
>ttp://lifestyle.nikkansports.com/gourmet/noodle/20070723-41884.html
まさに、JITと言えようw
>ttp://lifestyle.nikkansports.com/gourmet/noodle/20070723-41884.html
まさに、JITと言えようw
538 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/10(金) 19:36:36
よく分かっているじゃないか。
説明でミルクティーを使ったが、本当は適切な表現ではない。
紅茶とミルクティーは、現実の世界では別メニューだ。
それにミルクティーが紅茶の継承なのか、ミルクの継承なのか、多重継承なのかも分からない。
現実世界の多くの物が、オブジェクト指向設計に向かないのはそのためだ。
つまり、多くの現実の物は誰かの言う「客観的視点」が明確で無いからだ。
シミュレーションの分野ではこれを明確にできるので、使えるということになる。
説明でミルクティーを使ったが、本当は適切な表現ではない。
紅茶とミルクティーは、現実の世界では別メニューだ。
それにミルクティーが紅茶の継承なのか、ミルクの継承なのか、多重継承なのかも分からない。
現実世界の多くの物が、オブジェクト指向設計に向かないのはそのためだ。
つまり、多くの現実の物は誰かの言う「客観的視点」が明確で無いからだ。
シミュレーションの分野ではこれを明確にできるので、使えるということになる。
きたなチャーシューwww
現実世界では客観的視点が曖昧だけど、
アプリなりの設計者としてはそれは明確になる(出来る)って言ってるんじゃないの
何にしてもラーメンのスレで紅茶の話するのはスレ違い
アプリなりの設計者としてはそれは明確になる(出来る)って言ってるんじゃないの
何にしてもラーメンのスレで紅茶の話するのはスレ違い
542 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/10(金) 20:44:49
>>540
存在しないと言っている訳ではなく、明確で無い事が多いと言っている。
例えば、デパートのシステムがあったとする。
多くの場合、販売システムと在庫管理システムが連動していたり、販売予測や給料計算システムも
含んでいたりする。そうなると、販売と在庫管理の観点ではオブジェクトの意味が変わって来る。
シミュレーションの分野では、目的が単一の事が多いため、オブジェクトの意味が統一しやすい。
逆に言うと、目的を特化した物ならオブジェクト指向に向くと言える。
例えばデパートのシステムでは、販売予測システムだけに特化した...つまりシミュレーションになる訳だ。
存在しないと言っている訳ではなく、明確で無い事が多いと言っている。
例えば、デパートのシステムがあったとする。
多くの場合、販売システムと在庫管理システムが連動していたり、販売予測や給料計算システムも
含んでいたりする。そうなると、販売と在庫管理の観点ではオブジェクトの意味が変わって来る。
シミュレーションの分野では、目的が単一の事が多いため、オブジェクトの意味が統一しやすい。
逆に言うと、目的を特化した物ならオブジェクト指向に向くと言える。
例えばデパートのシステムでは、販売予測システムだけに特化した...つまりシミュレーションになる訳だ。
>>542
>シミュレーションの分野では、目的が単一の事が多い
そうなのか？じゃなにも「変更に強い」オブジェクト指向で作ることはなさそうだけどな。
だいたい現実のシミュレーションの分野って、計算量多いからFortranで書いてたりするんじゃないの？
>シミュレーションの分野では、目的が単一の事が多い
そうなのか？じゃなにも「変更に強い」オブジェクト指向で作ることはなさそうだけどな。
だいたい現実のシミュレーションの分野って、計算量多いからFortranで書いてたりするんじゃないの？
>>541
お茶から派生してジャワティーをメニューに加える。
ほら，スレ違いではない。
しかし，競合店の妨害工作は予想以上だ。
工作員の排除もままならない以上，侵攻計画の練り直しをせねばなるまい。
販売と在庫管理という”サブジェクト”を指向しているところに
>>542のまやかしがあって，オブジェクトの観点から見ればどちらのサブジェクトに関する属性も等価だ。
問題は客観的かどうかではなく系が閉じているかどうか。
閉じた系の中では関連も属性も有限なので完全な分析が可能だ。
系が閉じていなければシステムは分析の段階で破綻する。
シミュレーションはそもそも閉じた系でなければシミュレーションの意味を為さないので意識するまでもない。
そしてシステム化の要求は大抵の場合，時間を経るごとに拡大していくものなので，
中長期的視点ではシステムを閉じた系とみなすのは実利的ではないということ。
これが閉じた系を前提とするオブジェクト指向の嫌われる理由だと思われる。
厳密に言えば継承によってある程度の拡張性を持たせている点で他より多少マシなのだが，
その中途半端さが余計に嫌われる理由なのかも。
実用的にはそれでもないよりはマシなんだが。
お茶から派生してジャワティーをメニューに加える。
ほら，スレ違いではない。
しかし，競合店の妨害工作は予想以上だ。
工作員の排除もままならない以上，侵攻計画の練り直しをせねばなるまい。
販売と在庫管理という”サブジェクト”を指向しているところに
>>542のまやかしがあって，オブジェクトの観点から見ればどちらのサブジェクトに関する属性も等価だ。
問題は客観的かどうかではなく系が閉じているかどうか。
閉じた系の中では関連も属性も有限なので完全な分析が可能だ。
系が閉じていなければシステムは分析の段階で破綻する。
シミュレーションはそもそも閉じた系でなければシミュレーションの意味を為さないので意識するまでもない。
そしてシステム化の要求は大抵の場合，時間を経るごとに拡大していくものなので，
中長期的視点ではシステムを閉じた系とみなすのは実利的ではないということ。
これが閉じた系を前提とするオブジェクト指向の嫌われる理由だと思われる。
厳密に言えば継承によってある程度の拡張性を持たせている点で他より多少マシなのだが，
その中途半端さが余計に嫌われる理由なのかも。
実用的にはそれでもないよりはマシなんだが。
この人意見が一環してないんだよな。
さっきまでの意見と簡単に食い違う。
一環する答えが無く、他人の意見も認められないならコテなんて辞めればいいのに。
ま、その辺がコテたる所以かｗ
さっきまでの意見と簡単に食い違う。
一環する答えが無く、他人の意見も認められないならコテなんて辞めればいいのに。
ま、その辺がコテたる所以かｗ
一環してどうどうめぐり。
意見は「一貫」してくれ。
仕様とか概念とか上っ面ばかり見てないでたまには下とか横から見てみろよ
山口県迷惑行為防止条例
(卑わいな行為等の禁止)
第三条 何人も、公共の場所又は公共の乗物において、人を著しく羞恥しゆうさせ、又は人に著しく嫌悪の情を催させるような方法で、次の各号の一に該当する行為をしてはならない。
一 略
二 他人の身体又は下着(これらのうち現に衣服等で覆われている部分に限る。
以下同じ。)を見る目的で行う、手鏡を他人のスカートの下に差し出す行為、
他人のスカートの下からのぞき込む行為、
~~~~~~~~~~~~~~~~~~~~~~~~
他人のスカートをまくり上げる行為その他の周囲の状況からみて著しく異常な行為
以下略
(卑わいな行為等の禁止)
第三条 何人も、公共の場所又は公共の乗物において、人を著しく羞恥しゆうさせ、又は人に著しく嫌悪の情を催させるような方法で、次の各号の一に該当する行為をしてはならない。
一 略
二 他人の身体又は下着(これらのうち現に衣服等で覆われている部分に限る。
以下同じ。)を見る目的で行う、手鏡を他人のスカートの下に差し出す行為、
他人のスカートの下からのぞき込む行為、
~~~~~~~~~~~~~~~~~~~~~~~~
他人のスカートをまくり上げる行為その他の周囲の状況からみて著しく異常な行為
以下略
>>550
素直にフイたが、お前は一体何が言いたいｗ
素直にフイたが、お前は一体何が言いたいｗ
紅茶にラーメンか
まさしく「なんでもかんでもオブジェクト」だな
まさしく「なんでもかんでもオブジェクト」だな
一般的によくあるような、
DB読んで、ファイル作って、送信して〜
ってな業務ではOOは混乱する
自分もOOを気になりだして学習しだしたときは、
こういう業務にはめこもうとして全然わからず、
「自分ってアホなんやろか・・・」
と落ち込んだもんだが、
あるときゲーム製造作業のときにあっさり解決。
アホなんじゃなくて、無茶をしてたんだと。
できんことは無い。
できんことは無いんだが、
関数型でフロー通りに作った方がいいならそっちの方がいい。
DB読んで、ファイル作って、送信して〜
ってな業務ではOOは混乱する
自分もOOを気になりだして学習しだしたときは、
こういう業務にはめこもうとして全然わからず、
「自分ってアホなんやろか・・・」
と落ち込んだもんだが、
あるときゲーム製造作業のときにあっさり解決。
アホなんじゃなくて、無茶をしてたんだと。
できんことは無い。
できんことは無いんだが、
関数型でフロー通りに作った方がいいならそっちの方がいい。
大勢で大量に書かなきゃならない時以外はオブジェクト指向なんて必要ないんだよ
OOは実装を助けてはくれないからな
大勢で大量に書くと決まった時点でもう無理
557 ：仕様書無しさん：2007/08/11(土) 00:55:14
いいからお前ら抽象データ型の勉強してこい。話はそれからだ。
558 ：仕様書無しさん：2007/08/11(土) 01:00:46
過去ログ読むのﾒﾝﾄﾞｸｾ、誰か纏めろよ
559 ：仕様書無しさん：2007/08/11(土) 01:28:12
なぜオブジェクト指向は低能グラマに理解できないのか？4
Javaは儲かる
>>559
日本語でおｋ
日本語でおｋ
俺、グラマなら低能でもいいや。おっぱいおっぱい
記述が冗長になることが一番のデメリットだろうな。
数文字の短いキーワードをスペースで区切って並べる、という
長らく続いた開発言語のセオリーを壊してしまった。
数文字の短いキーワードをスペースで区切って並べる、という
長らく続いた開発言語のセオリーを壊してしまった。
数文字の短いキーワードをスペースで区切って並べる、という
オブジェクト指向言語があったらＯＯＰの一番のデメリットが解消されるのか？
オブジェクト指向言語があったらＯＯＰの一番のデメリットが解消されるのか？
それは、Pascal あたりから（というか COBOLぐらいから）始まったことで、
OO 固有の話じゃないな。
OO 固有の話じゃないな。
DB１項目ずつゲッター、セッター、ってアホかと
複数項目扱えるゲッターセッター書けばいいだけの話
変数一つにゲッターセッター付けるくらいの意味ならpublicにしてくれたほうがいいな
OO的には何でもメソッドでやりたいんだろうがプログラミング的には無意味な隠蔽はよくないと思う
OO的には何でもメソッドでやりたいんだろうがプログラミング的には無意味な隠蔽はよくないと思う
どっちでも。
DBで定義されたフィールドに依存してるなら、
すでにぜんぜん隠蔽になってないし。
DBで定義されたフィールドに依存してるなら、
すでにぜんぜん隠蔽になってないし。
>>568
本質的なＯＯＰでは、
「クラスの利用者にメソッドなのかフィールドなのか」
の区別すら強制しない。
だから
・ＯＯはメソッドでやりたがる
・でもフィールドをpublicにしたほうがプログラミング的に良い
ってのは何か前提がおかしくないか？
本質的なＯＯＰでは、
「クラスの利用者にメソッドなのかフィールドなのか」
の区別すら強制しない。
だから
・ＯＯはメソッドでやりたがる
・でもフィールドをpublicにしたほうがプログラミング的に良い
ってのは何か前提がおかしくないか？
おまえらまるで盲と象の話にそっくりだな
相変わらずくだらねぇ話題で自作自演してるバカが居るな
オブジェクト指向の本って言うと、
大体が実務とかけ離れた例だったりするんだよな。
トランプゲームだとか、客が店で物を買うとか。
なんでもかんでもオブジェクト症候群。
しかしこんなハードとソフトの切り分けもしないやり方では
実際にまともな設計なんかできるはずもなく、
うまくいかずにJavaだけど機能分類するしかねーよ、
みたいなことになる。
オブジェクト指向での設計ってのは
時間がかかるってのを上が理解してないってのも問題なんだけど。
大体が実務とかけ離れた例だったりするんだよな。
トランプゲームだとか、客が店で物を買うとか。
なんでもかんでもオブジェクト症候群。
しかしこんなハードとソフトの切り分けもしないやり方では
実際にまともな設計なんかできるはずもなく、
うまくいかずにJavaだけど機能分類するしかねーよ、
みたいなことになる。
オブジェクト指向での設計ってのは
時間がかかるってのを上が理解してないってのも問題なんだけど。
>>575
>オブジェクト指向での設計ってのは
>時間がかかるってのを上が理解してないってのも問題なんだけど。
ああ、まともにオブジェクト指向やろうとすると
設計だけで許されてる開発期間の半分は必要だからな
>オブジェクト指向での設計ってのは
>時間がかかるってのを上が理解してないってのも問題なんだけど。
ああ、まともにオブジェクト指向やろうとすると
設計だけで許されてる開発期間の半分は必要だからな
>>576
どんな設計やら開発手法やらでも、開発期間の半分はテストだと思うんだが
どんな設計やら開発手法やらでも、開発期間の半分はテストだと思うんだが
578 ：あるじゃーのん ◆0aR9pKWx3A ：2007/08/12(日) 13:42:24
つまり設計に５０％
コーディングに５０％
テストに１００％
デバッグに５０％
納品後トラブル対処で５０％
当初見積もりの３００％かかる
これは計算どーり
コーディングに５０％
テストに１００％
デバッグに５０％
納品後トラブル対処で５０％
当初見積もりの３００％かかる
これは計算どーり
遊園地を作る費用で出来たのはただの切り株でした
その切り株には遊園地を作るのと同等の価値があると考えるのさ
581 ：wolf ◆8VH3XAqjlU ：2007/08/12(日) 14:06:47
>>578
なかなか面白いですね
ＩＴ土方は製造業と言うよりサービス業ですから程度問題ですが
コア・フェーズに金型の製造を含んでいる所から問題が生じているのでは
非ＯＯ開発でも部品（サブルーチンなど）開発が先行した方がいいですが
金型が未整備でコア・フェーズだけで時間が結構タイトな1-Phase ＯＯ開発は自殺行為と言えるかな
金型開発込でいくには労働条件は変わりませんが（長時間を意味する）
スパイラル（２週間反復〜）にするしかないと思っています
ただ金型が一通り揃うまでは徹底的にデキの悪い開発メンバーを排除する必要も有りますが
なかなか面白いですね
ＩＴ土方は製造業と言うよりサービス業ですから程度問題ですが
コア・フェーズに金型の製造を含んでいる所から問題が生じているのでは
非ＯＯ開発でも部品（サブルーチンなど）開発が先行した方がいいですが
金型が未整備でコア・フェーズだけで時間が結構タイトな1-Phase ＯＯ開発は自殺行為と言えるかな
金型開発込でいくには労働条件は変わりませんが（長時間を意味する）
スパイラル（２週間反復〜）にするしかないと思っています
ただ金型が一通り揃うまでは徹底的にデキの悪い開発メンバーを排除する必要も有りますが
糞コテども次から次にわいてくんじゃね
誰か殺虫剤よろ
誰か殺虫剤よろ
583 ：あるじゃーのん ◆0aR9pKWx3A ：2007/08/12(日) 14:38:24
はいはい糞コテスパイラル
>>584
ｗ
ｗ
586 ：あるじゃーのん ◆0aR9pKWx3A ：2007/08/12(日) 14:59:15
クソコテの意味も分からないクソコテを見た。
…と釣られてみた。
…と釣られてみた。
OOの場合、設計期間の見積もりってどんぐらいなんだろ。
要件定義〜納期までを１00とした場合、
要件定義１０、
基本設計３０、
詳細設計２０、
製造（単体テスト込）２０、
総合テスト２０
・・・なんか違うな
要件定義〜納期までを１00とした場合、
要件定義１０、
基本設計３０、
詳細設計２０、
製造（単体テスト込）２０、
総合テスト２０
・・・なんか違うな
>>538
「客観的」視点である必要はないと思うけど
紅茶屋さんの視点でみれば、ミルクティーは紅茶を継承したものだし
ミルク屋さんの視点でみれば、牛乳を集約した飲み物の一つだし
でこれを抽象化すると、飲料のバリエーションや原材料の関係になるんでしょ
で、この抽象化された関係を元に演繹的に具体化すると
新商品のクラスができて、
それを具体的な材料を使って作ると
客に提供するインスタンスができる
「客観的」視点である必要はないと思うけど
紅茶屋さんの視点でみれば、ミルクティーは紅茶を継承したものだし
ミルク屋さんの視点でみれば、牛乳を集約した飲み物の一つだし
でこれを抽象化すると、飲料のバリエーションや原材料の関係になるんでしょ
で、この抽象化された関係を元に演繹的に具体化すると
新商品のクラスができて、
それを具体的な材料を使って作ると
客に提供するインスタンスができる
多くのオブジェクト指向言語は、中の人をクラスとして定義する。
まず「男キャラ」「女キャラ」のようにして中の人を宣言し、
「女キャラ」を実体化して「香織」「素子」などを作る(実体化したものをインスタンスと呼ぶ)。
実体には、パラメータなどを格納することができる(これをメンバ変数と呼ぶ)。
「香織」「素子」は、パラメータは異なっているが、中の人は同じである。
実体へのアクセスは、かならず中の人を通しておこなう。
これには「会う」「話す」などのメソッド(メンバ関数とも呼ぶ)と呼ばれる関数を
定義しておこなう。
しかしながら一般業務は上記のような萌える要素がほとんど無いため、
オブジェクト指向が立ち入る隙が無い。
そのため開発者はPCの周りに萌えグッズを置き、
現実世界のオブジェクトと製造目的のオブジェクトの区別が付かなくなる傾向がある。
このようなオブジェクトに対する萌えが理解されにくいことから、
オブジェクト指向が浸透しない原因の一つとなっている。
まず「男キャラ」「女キャラ」のようにして中の人を宣言し、
「女キャラ」を実体化して「香織」「素子」などを作る(実体化したものをインスタンスと呼ぶ)。
実体には、パラメータなどを格納することができる(これをメンバ変数と呼ぶ)。
「香織」「素子」は、パラメータは異なっているが、中の人は同じである。
実体へのアクセスは、かならず中の人を通しておこなう。
これには「会う」「話す」などのメソッド(メンバ関数とも呼ぶ)と呼ばれる関数を
定義しておこなう。
しかしながら一般業務は上記のような萌える要素がほとんど無いため、
オブジェクト指向が立ち入る隙が無い。
そのため開発者はPCの周りに萌えグッズを置き、
現実世界のオブジェクトと製造目的のオブジェクトの区別が付かなくなる傾向がある。
このようなオブジェクトに対する萌えが理解されにくいことから、
オブジェクト指向が浸透しない原因の一つとなっている。
オブジェクトって時点で客観的なもんだろ
サブジェクトに対してオブジェクト、わかる？
オブジェクト＝モノは誤訳に近い
モノならマテリアル指向だろ
抽象的なモノまで含めるのなら、それは日本語では「概念」すなわちコンセプト指向となる
サブジェクトに対してオブジェクト、わかる？
オブジェクト＝モノは誤訳に近い
モノならマテリアル指向だろ
抽象的なモノまで含めるのなら、それは日本語では「概念」すなわちコンセプト指向となる
改めるもクソもないだろ
単に英語力の問題だ
単に英語力の問題だ
はい、言葉遊びスタートです
やぁみんな
今晩も空理空論で盛り上がってるねぇ
いつまでたっても自分で勉強せずに
半可通な言葉を振り回して
ほんと進化しないなぁ
今晩も空理空論で盛り上がってるねぇ
いつまでたっても自分で勉強せずに
半可通な言葉を振り回して
ほんと進化しないなぁ
ｴﾛｲ人教えて。
DBとかファイルを使ってFTPやらTCP/IPで送受信するようなよくある業務を
オブジェクト指向で設計するのは
無謀なの？普通なの？
DBとかファイルを使ってFTPやらTCP/IPで送受信するようなよくある業務を
オブジェクト指向で設計するのは
無謀なの？普通なの？
597 ：仕様書無しさん：2007/08/13(月) 02:03:29
>>597
お前センスないから消えろ。な？
お前センスないから消えろ。な？
>>596
OO禁止。以上。
OO禁止。以上。
内容でOOかどうか決めるのはアフォだろ。量で決めろよ。
モジュール化による共通処理の統合と再利用、実装依存部の切り分けすら駄目なの？
>>602
ちがうだろ
馬鹿がオブジェクト指向ならそれだけで解決できると勘違いして玉砕→オブジェクト指向使えねパターンが多いだけだろ
ちゃんと細かいところまで仕様を考えずに設計やりだすのが一番の原因
別にオブジェクト指向使わなくてもデスマになる
ちがうだろ
馬鹿がオブジェクト指向ならそれだけで解決できると勘違いして玉砕→オブジェクト指向使えねパターンが多いだけだろ
ちゃんと細かいところまで仕様を考えずに設計やりだすのが一番の原因
別にオブジェクト指向使わなくてもデスマになる
>603
どんだけ書く必要があるのかだよ。いやどの言語使って書くのか知らないけどさ。
どんだけ書く必要があるのかだよ。いやどの言語使って書くのか知らないけどさ。
フロー通りにとか書いてあったからCOBOLでガリガリ書くようなのを想像してしまったぜ…
やっぱいるんだな。
Javaで製造＝オブジェクト指向でやってます、
って勘違いしてる奴。
Javaで製造＝オブジェクト指向でやってます、
って勘違いしてる奴。
616 ：格之進 ◆xiPQGz7lVI ：2007/08/13(月) 02:33:20
>>613
まあ、なら、オブジェクト指向でなくてもいいじゃないですか。
まあ、なら、オブジェクト指向でなくてもいいじゃないですか。
>610
言語がOOを想定してなければそれは本物OOとはいえないだろ。
言語がOOを想定してなければそれは本物OOとはいえないだろ。
>>613
は？それ勝手に脳内で定義して勝手にしゃべってない？
俺はオブジェクト指向はみんながそう認識するものを具現化できるもんだと思うんだけど？
プログラムで書いちゃったらみんながよくわからない構造になっちゃうお前のオブジェクト指向は
何か間違ってるような気がするけど変なやり方やってない？
は？それ勝手に脳内で定義して勝手にしゃべってない？
俺はオブジェクト指向はみんながそう認識するものを具現化できるもんだと思うんだけど？
プログラムで書いちゃったらみんながよくわからない構造になっちゃうお前のオブジェクト指向は
何か間違ってるような気がするけど変なやり方やってない？
>>618
よくわからんなあ。
業務フローの通りにオブジェクト指向って、
１．DBの参照・更新用のクラスを作る。
２．ファイルの作成・削除クラスを作る。
３．ファイル、電文の送受信クラスを作る。
ってことか？
もしそうならこれのどこがオブジェクトなんだ？
よくわからんなあ。
業務フローの通りにオブジェクト指向って、
１．DBの参照・更新用のクラスを作る。
２．ファイルの作成・削除クラスを作る。
３．ファイル、電文の送受信クラスを作る。
ってことか？
もしそうならこれのどこがオブジェクトなんだ？
>619
そのOOっぽい工夫を仕様にしたのがOOじゃね。いや言ってることはよくわかるけど。
そのOOっぽい工夫を仕様にしたのがOOじゃね。いや言ってることはよくわかるけど。
618が
「客」がなんとか画面のなんとかボタンを押す
とか言い出したらウケるｗ
「客」がなんとか画面のなんとかボタンを押す
とか言い出したらウケるｗ
>>591
間主観っていう考え方があるよ
関係者間で合意のとれた主観
まず、一人でクラス図なり描いてみて、他の人がそれを見て認識の違いを修正する
それを繰り返して合意するんじゃねーの？
UMLとかのちゃんと記述方法が決まったやり方で描いて、
その解釈の仕方が判らない人には、解釈方法を教えればいいじゃん
間主観っていう考え方があるよ
関係者間で合意のとれた主観
まず、一人でクラス図なり描いてみて、他の人がそれを見て認識の違いを修正する
それを繰り返して合意するんじゃねーの？
UMLとかのちゃんと記述方法が決まったやり方で描いて、
その解釈の仕方が判らない人には、解釈方法を教えればいいじゃん
626 ：仕様書無しさん：2007/08/13(月) 02:44:38
>>623
はぁ？少なくとも「業務」を
>１．DBの参照・更新用のクラスを作る。
>２．ファイルの作成・削除クラスを作る。
>３．ファイル、電文の送受信クラスを作る。
なんて言っちゃう奴より１０００倍ましだろｗウケルｗ
はぁ？少なくとも「業務」を
>１．DBの参照・更新用のクラスを作る。
>２．ファイルの作成・削除クラスを作る。
>３．ファイル、電文の送受信クラスを作る。
なんて言っちゃう奴より１０００倍ましだろｗウケルｗ
なんか酔っ払いがいるな
最近可哀想なほど馬鹿な子増えたな
オブジェクト指向っつか日本語からもう駄目そうなの
まあ、良書も減ったし、会社の人材育成止めたし、しょうがないっちゃないか
オブジェクト指向っつか日本語からもう駄目そうなの
まあ、良書も減ったし、会社の人材育成止めたし、しょうがないっちゃないか
>>629
そうだよな。句読点知らない子とか悲惨だよな。
そうだよな。句読点知らない子とか悲惨だよな。
ぶｗ
逃げたｗｗ
逃げたｗｗ
なんかヘンな人がいるんですが、
夏だからですか？
夏だからですか？
夏だな〜
>>633
逃げの人生ｗｗｗｗｗｗｗ
逃げの人生ｗｗｗｗｗｗｗ
>>634-635
むしろ、何か例だしてオブジェクト指向でのプログラミングを
設計から実装までやってもらおうとか考えてる馬鹿が多すぎｗ
こっちこそ夏かよっていいたくなるぜ
オブジェクト指向の入門書でも買ってこい
あーウザ、死ね
むしろ、何か例だしてオブジェクト指向でのプログラミングを
設計から実装までやってもらおうとか考えてる馬鹿が多すぎｗ
こっちこそ夏かよっていいたくなるぜ
オブジェクト指向の入門書でも買ってこい
あーウザ、死ね
トゲトゲしい奴だなあ
お茶でも飲んでもちつけ
お茶でも飲んでもちつけ
ペルセウス座流星群みてこよっと
おまいらも見れ
おまいらも見れ
DBやらファイルやらFTPやらTCP/IPは全部手段だろ
手段じゃなくて目的の方を分析するんだよ
手段じゃなくて目的の方を分析するんだよ
642 ：仕様書無しさん：2007/08/13(月) 03:36:22
流れ星キターーーーーーー
DB更新＆電文送受信 中心の業務システム
のオブジェクト指向設計といえば
まずはJ2EEなんだけど (ﾆｶﾞﾜﾗ
J2EEでピンと来ない阿呆の子には
ひがちゃんやはぶさんのモデルがおしゅしゅめ
例のakonさんが関わって没になった方法論の発展形。
あれ見てようやく、たかひろと俺の認識のズレを埋める事ができたｗ
のオブジェクト指向設計といえば
まずはJ2EEなんだけど (ﾆｶﾞﾜﾗ
J2EEでピンと来ない阿呆の子には
ひがちゃんやはぶさんのモデルがおしゅしゅめ
例のakonさんが関わって没になった方法論の発展形。
あれ見てようやく、たかひろと俺の認識のズレを埋める事ができたｗ
× たかひろと俺の認識のズレを埋める事ができたｗ
○ たかひろのやり方に対し、俺が感じた大きな違和感を多少解消し、
進むべき方向がちょっと見えたｗ そっち進む気ないけどｗ
○ たかひろのやり方に対し、俺が感じた大きな違和感を多少解消し、
進むべき方向がちょっと見えたｗ そっち進む気ないけどｗ
また伊賀者か。
Javaはどーでもいいべ
649 ：仕様書無しさん：2007/08/13(月) 10:50:41
ミクロで特定言語で特定個所しか語れないんだからしょうがねーだろ？
>>649
ム板いけ
ム板いけ
JAVAはきちんと理解した上で書けば必然的にOOになる。
OOPになるかもな。
けど設計には関係ない。
けど設計には関係ない。
OOの本義は効率よく大量に書けて設計も楽になるということ。
でもどう設計するかは助けてくれない。それはどんな手法でも同じだがな。
でもどう設計するかは助けてくれない。それはどんな手法でも同じだがな。
>>655
50年前の考え方に縛られるのも（ｒｙ
50年前の考え方に縛られるのも（ｒｙ
OOでコーディングが楽になんかなんねえだろ。
むしろくだらないコードがどのクラスにも乗っかって
くだらないデバッグをみんなしなきゃならないバカな状況があったりする。
だれも実装に責任取りたくないようなくだらない処理が
微妙に仕様違いで散在して至る所にBUGをバラ撒く。
むしろくだらないコードがどのクラスにも乗っかって
くだらないデバッグをみんなしなきゃならないバカな状況があったりする。
だれも実装に責任取りたくないようなくだらない処理が
微妙に仕様違いで散在して至る所にBUGをバラ撒く。
>>660
6500カ所に対応入れるより、１カ所に対応入れる方が費用も少ないぜ。
しかも、品質保証も１カ所で済むからな。
結果、実際には影響の広い処理は十分に動作確認されるから、そんな事は事実上皆無。
6500カ所に対応入れるより、１カ所に対応入れる方が費用も少ないぜ。
しかも、品質保証も１カ所で済むからな。
結果、実際には影響の広い処理は十分に動作確認されるから、そんな事は事実上皆無。
>>661
>実際には影響の広い処理は十分に動作確認されるから
はい、嘘
誰もブラックボックスを開けようとせず
なんかおかしい動作をするときとそうでないときとがある
でも全体の動作はとりあえずそれっぽく動いており誰もその関数を見ようとは思わなかった
とかアリガチだぜ
実はよくあります
>実際には影響の広い処理は十分に動作確認されるから
はい、嘘
誰もブラックボックスを開けようとせず
なんかおかしい動作をするときとそうでないときとがある
でも全体の動作はとりあえずそれっぽく動いており誰もその関数を見ようとは思わなかった
とかアリガチだぜ
実はよくあります
>>663
そりゃおまいのとこの業務怠慢だろw
そりゃおまいのとこの業務怠慢だろw
OO原理主義者はOOをギャップを少なくするための手段だと。
そんなんじゃ理解できるわけがない。
そんなんじゃ理解できるわけがない。
>>666がOOの本義を語ってくれるそうです
>>666がGoogle検索中です。
しばらくお待ちください。
しばらくお待ちください。
>>669
>普通はおかしい動きをした時点で原因の解析をする
へー、どうやって？
でかすぎてできないとか難解でだれもわからないとかあると思うけどね
だからほっといたんだし
いままでできなかったもんがいきなりできるようになるなんてありえねぇ
開発の時間も限られてるしそんなことホイホイできる職場なんてそうあるわけない
>普通はおかしい動きをした時点で原因の解析をする
へー、どうやって？
でかすぎてできないとか難解でだれもわからないとかあると思うけどね
だからほっといたんだし
いままでできなかったもんがいきなりできるようになるなんてありえねぇ
開発の時間も限られてるしそんなことホイホイできる職場なんてそうあるわけない
さらに動いたと誰かがお墨付きを与えた箇所なわけだし
政治的要因もあってそこの動作が不安定であることは抹消される確率は高いなｗ
政治的要因もあってそこの動作が不安定であることは抹消される確率は高いなｗ
納品後はバグではない。
仕様だ。
とM$から学んだ俺ガイル
仕様だ。
とM$から学んだ俺ガイル
674 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/13(月) 20:05:30
前にも言ったが、クラス分けはオブジェクト指向プログラミング（OOP）の分野だ。
DBや通信がどうのとか変数がどうのとかは、OOPの話になる。
俺が変更しやすいのが利点だと言っていたのは、OOPでの事だ。
オブジェクト指向設計（OOD）は、機能分割の分野で抽象化を使おうという考え方だから、
OOPの利点がそのままOODの利点になるとは限らない。
例えば体育館を管理するシステムを作るとしよう。オブジェクト指向設計を用いて、体育館をプールや
他の公共施設に変更出来るシステムにしたとする。
しかし普通は体育館をプールにする事はないので無駄な設計だ。
それなら最初からプールを管理するシステムを作った方が早い。また無理に抽象化しようとしすれば、
体育館の機能すら満足に管理出来ない物になりかねない。
よく、オブジェクト指向設計で何でも出来るようにすると、何も出来ない物になると言うのはこのためだ。
DBや通信がどうのとか変数がどうのとかは、OOPの話になる。
俺が変更しやすいのが利点だと言っていたのは、OOPでの事だ。
オブジェクト指向設計（OOD）は、機能分割の分野で抽象化を使おうという考え方だから、
OOPの利点がそのままOODの利点になるとは限らない。
例えば体育館を管理するシステムを作るとしよう。オブジェクト指向設計を用いて、体育館をプールや
他の公共施設に変更出来るシステムにしたとする。
しかし普通は体育館をプールにする事はないので無駄な設計だ。
それなら最初からプールを管理するシステムを作った方が早い。また無理に抽象化しようとしすれば、
体育館の機能すら満足に管理出来ない物になりかねない。
よく、オブジェクト指向設計で何でも出来るようにすると、何も出来ない物になると言うのはこのためだ。
おじゃばは「例えば」を出すととたんにぼろが出るから、
そこさえやめれば、こんなに馬鹿扱いされないような。
そこさえやめれば、こんなに馬鹿扱いされないような。
676 ：仕様書無しさん：2007/08/13(月) 20:30:19
>676
対等な立場で会話できる人間がいないからだと思われ。
対等な立場で会話できる人間がいないからだと思われ。
>676
リアルでも嫌われ者で
対等に話せるような友人が居ないからに決まってんだろ
可哀想なこと聞いてやるなよ
リアルでも嫌われ者で
対等に話せるような友人が居ないからに決まってんだろ
可哀想なこと聞いてやるなよ
たとえって適切でなければ話を混乱させるだけで意味ねーだろ
むしろ余計悪い
本人は適切だと思ってんだろうなぁ( ´-`)=3
むしろ余計悪い
本人は適切だと思ってんだろうなぁ( ´-`)=3
なぜオブジェクト指向以外の話題の方が盛り上がるのか？
>>673
品質が落ちることを分かっていても、
そのバグによって困る人が少なければ出荷しちゃう場合もあるでしょ。
そのバグ修正にかかるコスト＆出荷が遅れることによる不利益を考えたら、
「バグってようが売っちゃったほうが儲かる」って結論になることもアリなんだよ。
会社なんてぇのはそんなもんさ。
品質が落ちることを分かっていても、
そのバグによって困る人が少なければ出荷しちゃう場合もあるでしょ。
そのバグ修正にかかるコスト＆出荷が遅れることによる不利益を考えたら、
「バグってようが売っちゃったほうが儲かる」って結論になることもアリなんだよ。
会社なんてぇのはそんなもんさ。
>>681-682
スレ違い
スレ違い
>>687
お前、こんな奴、もうみんなＮＧワードにしてるぞｗ
お前、こんな奴、もうみんなＮＧワードにしてるぞｗ
ま だ や っ て い た の か
毎 晩 毎 晩 暇 人 だ な
あと付け加えるなら
O O P が 判 ら ん 池 沼 に
O O D は 無 理 ｗ
毎 晩 毎 晩 暇 人 だ な
あと付け加えるなら
O O P が 判 ら ん 池 沼 に
O O D は 無 理 ｗ
実装と設計と方法論を別物として扱おうとする奴は
大抵物事の本質を判っていないクズだろう。
相互の連続性をきちんと理解した上で各論騙れよクズ
大抵物事の本質を判っていないクズだろう。
相互の連続性をきちんと理解した上で各論騙れよクズ
騙るのかい？
設計・実装って言葉がまずだめ
フェーズとタスクがごっちゃになってる
RUPの分析フェーズとか見てもらえばわかるが
インプリメンテーションも一定量やるんだよ
フェーズとタスクがごっちゃになってる
RUPの分析フェーズとか見てもらえばわかるが
インプリメンテーションも一定量やるんだよ
RUPやOOA/OODの意図する所とか、C++屋にはちっとも理解できんだろうな。
事実上Java屋/.NET屋に特化した方法論だ、あれは。
事実上Java屋/.NET屋に特化した方法論だ、あれは。
C++ on railsやりたいです><
>>693
仕事上設計と実装でやる人が変わるんだからしょうがない
仕事上設計と実装でやる人が変わるんだからしょうがない
>>696
ああ、それで実装段階で火を噴くんだよな
ああ、それで実装段階で火を噴くんだよな
設計と実装で人変えてやってるところってまだあるのか？
一社で設計〜実装までやるところだったら、設計が終わるまで実装の人員が遊んでることになるし
設計が終わったら設計の人員がやることなくなるじゃん。
下請に出すときは、実装・テストだけ出すんじゃなくて丸投げする場合が多いし。
（元請はスケジュール管理・レビュー・検収試験だけ）
一社で設計〜実装までやるところだったら、設計が終わるまで実装の人員が遊んでることになるし
設計が終わったら設計の人員がやることなくなるじゃん。
下請に出すときは、実装・テストだけ出すんじゃなくて丸投げする場合が多いし。
（元請はスケジュール管理・レビュー・検収試験だけ）
>>698
もしかしてプログラム詳細設計は設計に入ってる？
もしかしてプログラム詳細設計は設計に入ってる？
プログラム詳細設計なんて工程知らないよ
詳細設計とプログラム設計のことか？
詳細設計とプログラム設計のことか？
まぁプログラム設計か
設計って、基本設計からプログラム設計まで？
703 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/14(火) 21:12:20
>>675,676
設計の場合はプログラミングに比べて、例が抽象的になってしまうのは仕方ない事だ。
それでも例を出すのは、物事を多角的に説明して少しでも曖昧性を排除したいからだ。
俺は物事の内容に触れずに、自分の意見をどうとも取れるようにぼかして発言するのは、
間違った事を言って恥をかくより恥ずかしいと思っている。
>>677,678,687
プログラミングや設計に関して、対等に議論出来る人が少ないのは確かだ。
でも友人は多い。
設計の場合はプログラミングに比べて、例が抽象的になってしまうのは仕方ない事だ。
それでも例を出すのは、物事を多角的に説明して少しでも曖昧性を排除したいからだ。
俺は物事の内容に触れずに、自分の意見をどうとも取れるようにぼかして発言するのは、
間違った事を言って恥をかくより恥ずかしいと思っている。
>>677,678,687
プログラミングや設計に関して、対等に議論出来る人が少ないのは確かだ。
でも友人は多い。
704 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/14(火) 21:31:19
工程について明確にしておこう。
・要件定義
・機能設計（別名、基本設計、また要件定義を含めて基本設計とする場合もある）
・詳細設計（別名、プログラム設計）
・コーディング
・単体試験
・結合試験
・総合試験
機能設計と詳細設計以降を別の人で行うの一般的だ。
詳細設計とコーディングを別の人で行うのは少ない。
また最近は詳細設計を省略してコーディングする事が多い。
オブジェクト指向設計が使われるのは、機能設計。
オブジェクト指向プログラミングが使われるのは、詳細設計及びコーディング。
一変的に設計と言うと、「機能設計」または「機能設計＋詳細設計」を指す。
・要件定義
・機能設計（別名、基本設計、また要件定義を含めて基本設計とする場合もある）
・詳細設計（別名、プログラム設計）
・コーディング
・単体試験
・結合試験
・総合試験
機能設計と詳細設計以降を別の人で行うの一般的だ。
詳細設計とコーディングを別の人で行うのは少ない。
また最近は詳細設計を省略してコーディングする事が多い。
オブジェクト指向設計が使われるのは、機能設計。
オブジェクト指向プログラミングが使われるのは、詳細設計及びコーディング。
一変的に設計と言うと、「機能設計」または「機能設計＋詳細設計」を指す。
2chで言い訳しても、自分がダメになる一方だとなぜわからないのか。
OOPが解らない奴よりも、そっちのほうが不思議。
だいたい、「友人は多い」って書いちゃうかふつー？
友人クラスのインスタンスをcreateした数くらいにしか思ってないの見え見え。
OOPが解らない奴よりも、そっちのほうが不思議。
だいたい、「友人は多い」って書いちゃうかふつー？
友人クラスのインスタンスをcreateした数くらいにしか思ってないの見え見え。
誰に向かって発言してるのか、という視点がないね。
ひょっとして、最初から自分の発言をずっと読んでる奴がいるとでも
思ってないか？＞おじゃば
頭おかしいぞそれ。他人はリアルでもここでもそんなにお前を気にしてないぞ。
俺はやさしいからｗつっこんでいい気になってるがね笑
ひょっとして、最初から自分の発言をずっと読んでる奴がいるとでも
思ってないか？＞おじゃば
頭おかしいぞそれ。他人はリアルでもここでもそんなにお前を気にしてないぞ。
俺はやさしいからｗつっこんでいい気になってるがね笑
>>704はバリバリのウォーターフォールだな。
最近でもやっぱウォーターフォールが主流か。
最近でもやっぱウォーターフォールが主流か。
反復とか口にだそうものなら気狂い扱いですよ
でも、定期的なマスター更新してるプロジェクトでは、事実上スパイラルだよ。
あのな、おじゃば。
おまえはもう来るな。荒れるから。
おまえはもう来るな。荒れるから。
711 ：日々是ソース読み＆見積：2007/08/14(火) 23:50:03
692 名前： 仕様書無しさん [sage] 投稿日： 2007/08/14(火) 11:51:53
>>690
仕事でやってる人でも連続性を理解しているなら、出須磨は無いだろ。
現実は
なんだよ、仕事の中身も判らずに金貰ってる詐欺師が多いのか、お前の周りは。
悲惨な境遇だな。
>>690
仕事でやってる人でも連続性を理解しているなら、出須磨は無いだろ。
現実は
なんだよ、仕事の中身も判らずに金貰ってる詐欺師が多いのか、お前の周りは。
悲惨な境遇だな。
>>711
携帯とかマジそんな感じ
携帯とかマジそんな感じ
ところで最近小野ちゃんは何作ってんの？
おまいは付き合いないのか？最近は
おまいは付き合いないのか？最近は
自演臭が凄まじいな
>>716
ヒント：劣等感に苛まれると話題をずらす彼
ヒント：劣等感に苛まれると話題をずらす彼
またこの流れか
正直言うと、お前の話題って十年一日の如く毎日同じだからつまんねぇ
じゃあ、元はシミュが原点っていう話でもしようか？
毎日が夏休みの彼は、
夏休みになると集中砲火を浴びて大変だなｗｗｗ
夏休みになると集中砲火を浴びて大変だなｗｗｗ
奴は１年中365日24時間、人とのｺﾐｭﾆｹｰｼｮﾝに飢えているから
集中砲火すら嬉しいんだと思うよ。
711 名前： 日々是ソース読み＆見積 [sage] 投稿日： 2007/08/14(火) 23:50:03
712 名前： 仕様書無しさん [sage] 投稿日： 2007/08/14(火) 23:51:17
↑時間差に注目。
集中砲火すら嬉しいんだと思うよ。
711 名前： 日々是ソース読み＆見積 [sage] 投稿日： 2007/08/14(火) 23:50:03
712 名前： 仕様書無しさん [sage] 投稿日： 2007/08/14(火) 23:51:17
↑時間差に注目。
>>725
頭ウニ＆性癖＝マゾなんだろうな
頭ウニ＆性癖＝マゾなんだろうな
727 ：仕様書無しさん：2007/08/15(水) 00:16:40
>>726
つか、単なるメンヘルだろう。
つか、単なるメンヘルだろう。
>>725
そのぐらいの時間差は普通にあると思うが・・・
そのぐらいの時間差は普通にあると思うが・・・
ウニっつーより腐ったプリン
自演に煽りにスレ違いか
夏だなあ
夏だなあ
731 ：仕様書無しさん：2007/08/15(水) 00:19:17
>>730
ｵﾏｴﾓﾅｰｗ
ｵﾏｴﾓﾅｰｗ
732 ：仕様書無しさん：2007/08/15(水) 00:19:33
次スレ
なぜ無職メンヘル２ちゃん常駐な彼は皆に嫌われているか？
なぜ無職メンヘル２ちゃん常駐な彼は皆に嫌われているか？
嫌われているというより、
空気のようにスルーされているだけだろ。
話題がつまんねぇから
空気のようにスルーされているだけだろ。
話題がつまんねぇから
うんうん、そうだねそうだね。
オブジェクト指向やってればいいよ。
オブジェクト指向やってればいいよ。
735 ：仕様書無しさん：2007/08/15(水) 00:25:45
なんつか、オブジェクト指向で出てくる「分析」ってのが浸透してないと思ってる今日この頃。
言葉も作業も。
言葉も作業も。
737 ：仕様書無しさん：2007/08/15(水) 00:29:12
ヒント：国内ＯＯ業界従事者は大抵下請けだから。
そりゃ下請けは業務分析やシステム分析とは縁が薄いもんな
基地外と低学歴のドカタが的外れなOO解釈を繰り広げてるだけなんだよな
再利用も設計は再利用できるけど実装はできないって聞くしねｗ
この時間になるとこうやって三流煽りを入れる奴、
寂しすぎだぞ。
寂しすぎだぞ。
743 ：仕様書無しさん：2007/08/15(水) 00:39:54
基地が暴れだした！
つまんないので寝る
つまんないので寝る
>>743
おまぃ、粘着すごいなｗｗ
おまぃ、粘着すごいなｗｗ
この基地は日本語が不自由な基地ですね。
>>745
おまぃ、粘着すごいなｗｗ
おまぃ、粘着すごいなｗｗ
在日マゾ基地人
749 ：仕様書無しさん：2007/08/15(水) 00:47:05
↑基地粘着中↓
ちょっと話は変わるんだけど、JavaでWebアプリつくるとき
Strutsっていうフレームワーク使ったりするじゃん。
入力チェックとかするときはXMLに設定するだけでできちゃうんだけど、
その設定値決める作業って設計になるの？実装になるの？
Strutsっていうフレームワーク使ったりするじゃん。
入力チェックとかするときはXMLに設定するだけでできちゃうんだけど、
その設定値決める作業って設計になるの？実装になるの？
設計
うそつけ実装だよ
設定値って時点で設計
実装終わった後の話なんだし
ついでに言えばスレ違い
実装終わった後の話なんだし
ついでに言えばスレ違い
コード書いたことないSEが、どうやってStrutsのXML設定できるわけあるんだよ。
ソース読みこまなきゃ無理なのばっかじゃねえか
ソース読みこまなきゃ無理なのばっかじゃねえか
うんこっここおっこおここｋ
ぴつゆちゅつつつつつとうおあぴぴぴｐっつっつｊつつｔ
ぐちょｃｈちゅｈこｈこほちょほほちょちょちょｈｃふぉほｈちょこｈこｈこｈふぉよちょｈ
うぬちゅぶりゅぶりゅりゅりゅりゅｒ
ぴつゆちゅつつつつつとうおあぴぴぴｐっつっつｊつつｔ
ぐちょｃｈちゅｈこｈこほちょほほちょちょちょｈｃふぉほｈちょこｈこｈこｈふぉよちょｈ
うぬちゅぶりゅぶりゅりゅりゅりゅｒ
オブジェクト指向
１．作業者をフルイにかけて選別することの意。
２．それぞれ思い思いの行動を取り、決してまとまらないこと。
３．お題目が立派なさま。
４．曼荼羅図の経典。
１．作業者をフルイにかけて選別することの意。
２．それぞれ思い思いの行動を取り、決してまとまらないこと。
３．お題目が立派なさま。
４．曼荼羅図の経典。
759 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/15(水) 10:25:52
>>705
友人クラスをcreateした数？一人を何回もカウントしていると言いたいのかな？
さすがの俺も抽象化された友人はいないぞ。
>>706
優しいな。
でも工程の話をするのは5回目ぐらいだからだから、最初から読まれているとは思っていない。
>>707-709
工程管理上はウォーターフォールだが、実際は「機能設計、詳細設計、コーディング、単体試験」の時間を
使ってプロトタイプで行う事が多い。
>>710
荒れないだろう、話題が止まるだけで。
>>751
実装。
友人クラスをcreateした数？一人を何回もカウントしていると言いたいのかな？
さすがの俺も抽象化された友人はいないぞ。
>>706
優しいな。
でも工程の話をするのは5回目ぐらいだからだから、最初から読まれているとは思っていない。
>>707-709
工程管理上はウォーターフォールだが、実際は「機能設計、詳細設計、コーディング、単体試験」の時間を
使ってプロトタイプで行う事が多い。
>>710
荒れないだろう、話題が止まるだけで。
>>751
実装。
「もったいない」は今や世界の共通語。
だが捨てるべきときに捨てる決断ができない理由が
その時点においてそれが価値を喪失していないことだとするならば，
そのこと自体が結果に対する責任の一端を担うことにはならないだろうか。
つまり，捨てたくないのさ。
だが捨てるべきときに捨てる決断ができない理由が
その時点においてそれが価値を喪失していないことだとするならば，
そのこと自体が結果に対する責任の一端を担うことにはならないだろうか。
つまり，捨てたくないのさ。
764 ：仕様書無しさん：2007/08/15(水) 14:22:33
話題は全然変わるが。
ミッションクリティカル系お客様から、
ケアレスミスに起因した不具合の原因と対策の説明求められて、
QC七つ道具の特性要因図使って説明書こうと思ってるんだけど、
これOO分析っぽくて存外におもしれーな。
特性要因図とは何か簡単に説明すると、
発生した問題を、主な要因(つかカテゴリー。例えば製造業なら人、方法、機械、原料、測定等とか)毎に原因究明(問題→機械の故障→故障原因)して、対策を検討する方法。
図としては、魚の骨(つか枝分かれした木)みたいのを書く。
(ビジネスモデリングのFishboneとはたぶん全然別物)
…IT分野で何を最初の主要な要因として選択するか、だいぶ悩むがｗ
(ITの場合、原料も機械も測定も、人かソフトか方法に帰着するから、
要因分析しずらい)
ミッションクリティカル系お客様から、
ケアレスミスに起因した不具合の原因と対策の説明求められて、
QC七つ道具の特性要因図使って説明書こうと思ってるんだけど、
これOO分析っぽくて存外におもしれーな。
特性要因図とは何か簡単に説明すると、
発生した問題を、主な要因(つかカテゴリー。例えば製造業なら人、方法、機械、原料、測定等とか)毎に原因究明(問題→機械の故障→故障原因)して、対策を検討する方法。
図としては、魚の骨(つか枝分かれした木)みたいのを書く。
(ビジネスモデリングのFishboneとはたぶん全然別物)
…IT分野で何を最初の主要な要因として選択するか、だいぶ悩むがｗ
(ITの場合、原料も機械も測定も、人かソフトか方法に帰着するから、
要因分析しずらい)
765 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/15(水) 20:30:34
>>760
要件定義と機能設計？
プロトタイプは動く物を見せるから、最低でもコーディングまでは含む。
また要件定義まで戻ると、それはすでに別物だから、見積も計画も想定出来なくなる。
要件定義と機能設計を繰り返し行うのか？
その設計方法は見た事あるが、俺の中ではそれは「デスマーチ序章」と言う。
>>762
紅茶の例が適切でない件については、訂正と説明を行った。
内容に対する意見を避けたコメントや、理由や根拠が記載されていないコメントは、見直しのしようがない。
要件定義と機能設計？
プロトタイプは動く物を見せるから、最低でもコーディングまでは含む。
また要件定義まで戻ると、それはすでに別物だから、見積も計画も想定出来なくなる。
要件定義と機能設計を繰り返し行うのか？
その設計方法は見た事あるが、俺の中ではそれは「デスマーチ序章」と言う。
>>762
紅茶の例が適切でない件については、訂正と説明を行った。
内容に対する意見を避けたコメントや、理由や根拠が記載されていないコメントは、見直しのしようがない。
766 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/15(水) 20:58:17
>>764
バグの原因分析に関しては、大体はどこでもやっているだろう。
たいていはバグ票に混入工程や原因などをチェックする項目がある。
多くの場合、横軸が工程で、縦軸が原因となる。横軸の原因は工程により異なる。
例えば、機能設計の場合は、原因は「機能誤り」「機能漏れ」「仕様表現不備」「外部IF不整合」など、
結合試験の場合の原因は、「修正誤り」「修正漏れ」「デグレート」など。
確かに集計作業は面白いが、使い方を根本的に間違えている管理者も多い。
ちなみに、全部のバグを集計して多いバグの傾向を出しても意味が無い。
バグとは作業者に関連する物である。つまり、食事の時間なのでまた今度。
バグの原因分析に関しては、大体はどこでもやっているだろう。
たいていはバグ票に混入工程や原因などをチェックする項目がある。
多くの場合、横軸が工程で、縦軸が原因となる。横軸の原因は工程により異なる。
例えば、機能設計の場合は、原因は「機能誤り」「機能漏れ」「仕様表現不備」「外部IF不整合」など、
結合試験の場合の原因は、「修正誤り」「修正漏れ」「デグレート」など。
確かに集計作業は面白いが、使い方を根本的に間違えている管理者も多い。
ちなみに、全部のバグを集計して多いバグの傾向を出しても意味が無い。
バグとは作業者に関連する物である。つまり、食事の時間なのでまた今度。
あぼーん
長文失礼。
>>765
コイツはプロトタイピングを良く分かってないらしい。
プロトタイピングで作ったプロトタイプは設計が終わった時点で捨てるんだよ。
1から設計にしたがって実装を全部やり直すんだ。
(まぁソースコードの一部をコピペ、ぐらいは発生するかも知れないが)
プロトタイピングではプロトタイプは出来上がるプログラムとは実装上関係ない。
プロトタイプはプログラムの動きを客先とすり合わせるためや
動作上の問題を早めに探し出すために使われる。
GUIとかでよく使う。
CGIのプロトタイプであれば、実際に動作しなくても
HTMLのみでリンクを使ったパラパラ漫画みたいな物でも良い。
gccとgtkで作るプログラムのプロトタイプを、
とりあえずBVのポトペタでGUI部分だけ見せても良い訳だ。(画面レイアウトとか)
コレのどこら辺が実装だ？
プロトタイプを作って、自分で検証するなり客先に見せるなりした後、
そのプログラム自身を機能拡張、変更して行くのはインクリメンタル手法だ。
大体プロトタイピングが実装まで含むと言うなら
プロトタイプ見せた後「ここはこうして欲しいですねぇ」と客先から言われたら
もう一回設計し直すどころか実装までやり直しじゃないか。
「要件定義と機能設計を繰り返し行う」どころか
「機能設計、詳細設計、コーディング、単体試験」を繰り返し行うことになる。
それこそ序章どころか「デスマーチそのもの」だろ。
>>765
コイツはプロトタイピングを良く分かってないらしい。
プロトタイピングで作ったプロトタイプは設計が終わった時点で捨てるんだよ。
1から設計にしたがって実装を全部やり直すんだ。
(まぁソースコードの一部をコピペ、ぐらいは発生するかも知れないが)
プロトタイピングではプロトタイプは出来上がるプログラムとは実装上関係ない。
プロトタイプはプログラムの動きを客先とすり合わせるためや
動作上の問題を早めに探し出すために使われる。
GUIとかでよく使う。
CGIのプロトタイプであれば、実際に動作しなくても
HTMLのみでリンクを使ったパラパラ漫画みたいな物でも良い。
gccとgtkで作るプログラムのプロトタイプを、
とりあえずBVのポトペタでGUI部分だけ見せても良い訳だ。(画面レイアウトとか)
コレのどこら辺が実装だ？
プロトタイプを作って、自分で検証するなり客先に見せるなりした後、
そのプログラム自身を機能拡張、変更して行くのはインクリメンタル手法だ。
大体プロトタイピングが実装まで含むと言うなら
プロトタイプ見せた後「ここはこうして欲しいですねぇ」と客先から言われたら
もう一回設計し直すどころか実装までやり直しじゃないか。
「要件定義と機能設計を繰り返し行う」どころか
「機能設計、詳細設計、コーディング、単体試験」を繰り返し行うことになる。
それこそ序章どころか「デスマーチそのもの」だろ。
結局「俺の中」の話を、誰にも話せないからここで書く。
本人が自分を改修する意図がないから、人生がデグレートする一方だ。
生き方がウォーターフォールなら、多いバグの傾向を出しても意味が無い。
食事なのでまた今度。寂しいからそこにいてね。
本人が自分を改修する意図がないから、人生がデグレートする一方だ。
生き方がウォーターフォールなら、多いバグの傾向を出しても意味が無い。
食事なのでまた今度。寂しいからそこにいてね。
>>766
おまえはまさしく伸びない技術者の典型。
目的を押さえてないから技術そのものに反応する。
技術の「使い方」はある程度学んでいるのだが、
肝心の目的を押さえてないので発展性がゼロで応用力もない。
> 使い方を根本的に間違えている管理者も多い
おまえは使い方「しか」分かってないただのオタク。
プロトタイプについては思い込みだけで悲惨の一言だ。
ついでだが、「訂正」の意味をちゃんと調べてこいや。
>>522に対する>>538の記述をお前は「訂正」と呼ぶのか？
必死に言い訳してるだけだろ。
プライドを持つのは大事だがお前のは劣悪すぎるんだよ。
分からないなら分かりません、間違っていたのなら間違えました、と言えるようになれ。
一生懸命ごまかしの人生を歩むのはお前の勝手だがな。
おまえはまさしく伸びない技術者の典型。
目的を押さえてないから技術そのものに反応する。
技術の「使い方」はある程度学んでいるのだが、
肝心の目的を押さえてないので発展性がゼロで応用力もない。
> 使い方を根本的に間違えている管理者も多い
おまえは使い方「しか」分かってないただのオタク。
プロトタイプについては思い込みだけで悲惨の一言だ。
ついでだが、「訂正」の意味をちゃんと調べてこいや。
>>522に対する>>538の記述をお前は「訂正」と呼ぶのか？
必死に言い訳してるだけだろ。
プライドを持つのは大事だがお前のは劣悪すぎるんだよ。
分からないなら分かりません、間違っていたのなら間違えました、と言えるようになれ。
一生懸命ごまかしの人生を歩むのはお前の勝手だがな。
マジで専ブラのＮＧワード機能を使ってくれと言わざるをえない
オブジェクト指向を理解すればするほど、
現場から孤立していく。
by Peter van der Linden
現場から孤立していく。
by Peter van der Linden
コストが重すぎて、会社全体で一丸となってレベルじゃなきゃ、
やっぱ駄目だと思うんだ。
やっぱ駄目だと思うんだ。
LL塊(ぷ
777 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/16(木) 19:52:48
>>768
まず俺が言い訳するまえに、聞きたい事がある。
768の認識では画面デザイン変更は、要件定義なのか機能設計なのか教えてほしい。
ちなみに俺の認識では、HTML作成やデモソース作成は実装に入る。
>>769
よく分からんが、デグレートとウォーターフォールの使い方が間違っているようだ。
>>770
ではバグ集計の目的と発展性のある意見を聞きたい。
どういう使い方をすると効果的なんだ？
まず俺が言い訳するまえに、聞きたい事がある。
768の認識では画面デザイン変更は、要件定義なのか機能設計なのか教えてほしい。
ちなみに俺の認識では、HTML作成やデモソース作成は実装に入る。
>>769
よく分からんが、デグレートとウォーターフォールの使い方が間違っているようだ。
>>770
ではバグ集計の目的と発展性のある意見を聞きたい。
どういう使い方をすると効果的なんだ？
明らかにエンドユーザｗを相手にしたことがないのが露呈してるね。
よく分からんことまで相手にせんでもよかろうに。
教えてくださいとは言えないんだねぇ。どうしてもｗ
つまらんプライドと揶揄される理由は、
性格の善し悪しじゃなくて能力が足りないんだよ。わかんないのかなぁ。
よく分からんことまで相手にせんでもよかろうに。
教えてくださいとは言えないんだねぇ。どうしてもｗ
つまらんプライドと揶揄される理由は、
性格の善し悪しじゃなくて能力が足りないんだよ。わかんないのかなぁ。
779 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/16(木) 20:21:03
バグ解析の目的と効果的な使用方法が分からないので教えてください。お願いします。
やっぱ、能力がたりないな。
781 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/16(木) 20:35:15
ふ、伊賀者か。たかひろにされたいならそれも良かろう。
でもなぁ、いい加減真面目にわかった方がいいと思うぞ。
自分の言いたいことより先に、相手が何言ってるか聞いてれば
結局相手も自分の話を聞いてくれるってこと。
でもなぁ、いい加減真面目にわかった方がいいと思うぞ。
自分の言いたいことより先に、相手が何言ってるか聞いてれば
結局相手も自分の話を聞いてくれるってこと。
>>777
＞768の認識では画面デザイン変更は、要件定義なのか機能設計なのか教えてほしい。
時と場合と内容による。
うちでは基本的には、客との交渉で決まった内容が要件定義に入る。
何を指して「画面デザイン」と言っているのか今ひとつ分からないけど、
単なるレイアウトとかボタンをリンクにとか機能の実装方法については機能設計に入る。
一覧表示の表示最大個数を16個から32個に変えて欲しい、というような
要件が「客先との交渉の上で」変わる場合は要件定義。
システム全体が自社開発の場合は、どちらも機能設計に含めてしまうことが多い。
＞768の認識では画面デザイン変更は、要件定義なのか機能設計なのか教えてほしい。
時と場合と内容による。
うちでは基本的には、客との交渉で決まった内容が要件定義に入る。
何を指して「画面デザイン」と言っているのか今ひとつ分からないけど、
単なるレイアウトとかボタンをリンクにとか機能の実装方法については機能設計に入る。
一覧表示の表示最大個数を16個から32個に変えて欲しい、というような
要件が「客先との交渉の上で」変わる場合は要件定義。
システム全体が自社開発の場合は、どちらも機能設計に含めてしまうことが多い。
ここってアホコテと絡むスレじゃねーの？
コテからかう以外でほとんどレス付いてないし。
コテからかう以外でほとんどレス付いてないし。
アホコテのアホレスで笑うスレかとばかり
最近は笑えるを通り越して哀れ・・・
最近は笑えるを通り越して哀れ・・・
自作自演のクオリティ劣化の件。
788 ：仕様書無しさん：2007/08/17(金) 11:48:29
また夏休みで伊賀知己でてきてるの?
789 ：仕様書無しさん：2007/08/17(金) 13:30:25
オブジェクト指向って、名前が大袈裟な割りに底が浅くて馬鹿でも理解出来るから
一時的に流行したけどねぇ
ま、別に名前付けて拝むほどのものじゃないわなｗ
一時的に流行したけどねぇ
ま、別に名前付けて拝むほどのものじゃないわなｗ
790 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/17(金) 20:00:11
>>782
聞いているだろう。
聞いていないと感じる原因は、俺が名無しの発言者（誰がどの発言をしたか）を全て把握していると思って
いるからだ。完結していない名無しの発言は、意図を読んだり、分割された質問の答えを返すのが難しい。
>>783
つまりほとんど機能設計だろう。
まれに要求仕様が変更になることはあるが、その場合は見積し直しの仕切り直しなので、プロトタイプ内に
含めていない。それとサンプル作成もコーディングするから実装だという分類ならば、俺の説明で問題ない
だろう。ただ逆に言うと、要求仕様変更もプロトタイプ内として、サンプル作成をコーディングに
含めないなら、783の説明でも問題ないと言う事になる。
まあ、内容は大差ないと言う事だろう。
聞いているだろう。
聞いていないと感じる原因は、俺が名無しの発言者（誰がどの発言をしたか）を全て把握していると思って
いるからだ。完結していない名無しの発言は、意図を読んだり、分割された質問の答えを返すのが難しい。
>>783
つまりほとんど機能設計だろう。
まれに要求仕様が変更になることはあるが、その場合は見積し直しの仕切り直しなので、プロトタイプ内に
含めていない。それとサンプル作成もコーディングするから実装だという分類ならば、俺の説明で問題ない
だろう。ただ逆に言うと、要求仕様変更もプロトタイプ内として、サンプル作成をコーディングに
含めないなら、783の説明でも問題ないと言う事になる。
まあ、内容は大差ないと言う事だろう。
791 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/17(金) 20:11:18
やれやれ、おじゃばお前な、いい歳こいて本気で思ってるだろ。
「言ってることが正しければ聞いてくれる」って。
んなわきゃねーだろ。俺らはヒトクラスのインスタンスｗじゃねーんだ。
単発の発言に説得力を持たせるのは技術だろうが。
2chで継続を求めるのは、普段の生活で継続に自信がない現れだろ？
コテハンで読んでもらうことに甘えんじゃねーよ。
「言ってることが正しければ聞いてくれる」って。
んなわきゃねーだろ。俺らはヒトクラスのインスタンスｗじゃねーんだ。
単発の発言に説得力を持たせるのは技術だろうが。
2chで継続を求めるのは、普段の生活で継続に自信がない現れだろ？
コテハンで読んでもらうことに甘えんじゃねーよ。
それは間違い。
彼の言ってることは教科書レベル以上のことは全然正しくないし、
単に盲目的に自分の言ってることは正しいと思いこんでる、が正解。
彼の言ってることは教科書レベル以上のことは全然正しくないし、
単に盲目的に自分の言ってることは正しいと思いこんでる、が正解。
ここはやはりコテハンをつついて遊ぶ場所だったのか
>>791
770ではないが。
バグ解析の目的も効果的な使用法も
開発プロセスの問題点を探すこと。
自分で書いてるじゃんか。>>766で。
さらに>>766の言葉を若干借りるなら、
作業者がどのようなミスによってバグが混在することが多いのかを分析する。
意思疎通の欠如ならミーティングを増やすとか、
コーディングのケアレスミスが多いならソースコードレビューのやり方を変えるとか。
今流行りだからちょっとCMMとか勉強してみろ。
どの開発プロセスでもやるべきことに「測定すること」って書かれてるから。
何でもいいから「測定すること」はプロセス改善の第一歩。
770ではないが。
バグ解析の目的も効果的な使用法も
開発プロセスの問題点を探すこと。
自分で書いてるじゃんか。>>766で。
さらに>>766の言葉を若干借りるなら、
作業者がどのようなミスによってバグが混在することが多いのかを分析する。
意思疎通の欠如ならミーティングを増やすとか、
コーディングのケアレスミスが多いならソースコードレビューのやり方を変えるとか。
今流行りだからちょっとCMMとか勉強してみろ。
どの開発プロセスでもやるべきことに「測定すること」って書かれてるから。
何でもいいから「測定すること」はプロセス改善の第一歩。
>>795
測定するのはいいが、測定にコストがかかる事を理解していない上層部は死ぬべき。
測定するのはいいが、測定にコストがかかる事を理解していない上層部は死ぬべき。
音を立てておならをすると臭いが軽減されるという俗説があるが、定かではない。
ただ、マナー上の観点から音の出ないおなら（いわゆるすかしっおなら）をする者
の方が多いのは確かである。音のした場合は臭いがすることが予め予測できるが、
すかしっおならの場合何の前兆もなく突然臭いがするため、余計に臭く感じるため
だとも言われる。
ただ、マナー上の観点から音の出ないおなら（いわゆるすかしっおなら）をする者
の方が多いのは確かである。音のした場合は臭いがすることが予め予測できるが、
すかしっおならの場合何の前兆もなく突然臭いがするため、余計に臭く感じるため
だとも言われる。
どっちでももの凄く臭い俺の立場は？
とりあえず、おめぇ〜の頭の中には広大なお花畑が広がっていて、
>>766単発発言を理解しようとする時も、
脳内お花畑に咲いてるバケモノフラワーにマッピングして理解しようとしてくるから、
話がトンチンカンに逝っちゃって、会話が成立しない事、
を特性要因分析できたｗｗｗ
まずは、おめぇ〜の脳内お花畑の話題は忘れておけ。
俺が>>766で言っているのは、
特性要因図を使った問題の原因分析というのは、
若干ではあるが、オブジェクト指向分析との類似点が感じられて、
面白いですね
以上だ。
>>766単発発言を理解しようとする時も、
脳内お花畑に咲いてるバケモノフラワーにマッピングして理解しようとしてくるから、
話がトンチンカンに逝っちゃって、会話が成立しない事、
を特性要因分析できたｗｗｗ
まずは、おめぇ〜の脳内お花畑の話題は忘れておけ。
俺が>>766で言っているのは、
特性要因図を使った問題の原因分析というのは、
若干ではあるが、オブジェクト指向分析との類似点が感じられて、
面白いですね
以上だ。
スレ番間違いちったｗ
802 ：764 (800訂正ｗ)：2007/08/18(土) 11:51:12
とりあえず、おめぇ〜の頭の中には広大なお花畑が広がっていて、
>>764単発発言を理解しようとする時も、
脳内お花畑に咲いてるバケモノフラワーにマッピングして理解しようとしてくるから、
話がトンチンカンに逝っちゃって、会話が成立しない事、
を特性要因分析できたｗｗｗ
まずは、おめぇ〜の脳内お花畑の話題は忘れておけ。
俺が>>764で言っているのは、
特性要因図を使った問題の原因分析というのは、
若干ではあるが、オブジェクト指向分析との類似点が感じられて、
面白いですね
以上だ。
>>764単発発言を理解しようとする時も、
脳内お花畑に咲いてるバケモノフラワーにマッピングして理解しようとしてくるから、
話がトンチンカンに逝っちゃって、会話が成立しない事、
を特性要因分析できたｗｗｗ
まずは、おめぇ〜の脳内お花畑の話題は忘れておけ。
俺が>>764で言っているのは、
特性要因図を使った問題の原因分析というのは、
若干ではあるが、オブジェクト指向分析との類似点が感じられて、
面白いですね
以上だ。
>802
やっぱ間違えてるしｗ
それじゃ誰の頭にお花畑が広がってるんだか･･･わかるからいいんだけどさ。
やっぱ間違えてるしｗ
それじゃ誰の頭にお花畑が広がってるんだか･･･わかるからいいんだけどさ。
知能の低い人間は、自分に理解のできない話は全て相手の間違いだと結論付けるからお気楽なことだよな
スレの主題を勘違いしている人間が
１年３６５日２４時間体制で粘着しているからダメなんだと思う
２ちゃんの技術系スレは
１年３６５日２４時間体制で粘着しているからダメなんだと思う
２ちゃんの技術系スレは
× スレの主題を勘違いしている人間が
◎ 社会性のないデムパが
◎ 社会性のないデムパが
ホラ来たデムパちゃん
略して失禁
たかひろ失禁
失禁を笑えない。
下らないレスに威勢良く食いつくあたりに
知能の劣悪さを感じる
知能の劣悪さを感じる
下らないスレに以下同文
鸚鵡返しか。アフォ丸出しだな
アフォは丸出しにするもの。小出しはいくない。
なんだQC七つ道具みたいな
定番の品質管理の話にも付いて来れねぇのが
粘着してるのか。
定番の品質管理の話にも付いて来れねぇのが
粘着してるのか。
まぁ、業務でオブジェクト指向使ってる奴ばかりじゃないからな。
QC七つ道具は、オブジェクト指向ではなく
製造業一般の品質管理の分析手法だよん
製造業一般の品質管理の分析手法だよん
引き篭もりニートに実務の話をしても通じるわけねぇだろ
新QC七つ道具ってのもあるな。
こっちは問題構造の定性的分析が目的だから、
プロマネ講習会のネタとして目にした事がある人も多い事と思う
(引き篭もりニートの人は除いて)
こっちは問題構造の定性的分析が目的だから、
プロマネ講習会のネタとして目にした事がある人も多い事と思う
(引き篭もりニートの人は除いて)
KJ法（ｗ
７つ道具とか多すぎ。
３つでギリ。
それ以上覚えられん。
新とかで増やすなよ、と。
３つでギリ。
それ以上覚えられん。
新とかで増やすなよ、と。
業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
って意味だったのに得意げに話し始めててテラワロスｗｗｗ
自分が知ってる別分野の話でこのスレの主導権を握った気になっているのは滑稽だぜ。
CMM自体も流行はかなり前からある。
そして、優れたSEの著書では大体CMMは「クソッタレ」と評価されてる。
もっとおまえ勉強しろよ。
って意味だったのに得意げに話し始めててテラワロスｗｗｗ
自分が知ってる別分野の話でこのスレの主導権を握った気になっているのは滑稽だぜ。
CMM自体も流行はかなり前からある。
そして、優れたSEの著書では大体CMMは「クソッタレ」と評価されてる。
もっとおまえ勉強しろよ。
すげぇバカだと思ったのは、
今時CMMIでもどうかと思うのに、
CMMを自慢げに騙ってしまう時代錯誤感。
バカはやっぱりバカ、
QCとオブジェクト指向を結びつけて話題を展開する創造力もねぇんだな
今時CMMIでもどうかと思うのに、
CMMを自慢げに騙ってしまう時代錯誤感。
バカはやっぱりバカ、
QCとオブジェクト指向を結びつけて話題を展開する創造力もねぇんだな
はい、よい子のみなさん、注目注目ぅ〜
コラ、そこでオナってる学生さん、注目だよ
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
ここで、等価演算子＝ の左側と右側が、全然等価ではないのに注目。
このように、数式もどきを使って非論理的な議論展開をする人間を、
低学歴
と言います。
皆さんも勉強を怠ると、こんな恥ずかしい低学歴になってしまいますよ。
気をつけましょうね
コラ、そこでオナってる学生さん、注目だよ
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
ここで、等価演算子＝ の左側と右側が、全然等価ではないのに注目。
このように、数式もどきを使って非論理的な議論展開をする人間を、
低学歴
と言います。
皆さんも勉強を怠ると、こんな恥ずかしい低学歴になってしまいますよ。
気をつけましょうね
はい、よい子のみなさん、注目注目ぅ〜
コラ、そこでオナってる学生さん、注目だよ
> 皆さんも勉強を怠ると、こんな恥ずかしい低学歴になってしまいますよ。
ここで、句点の左側と右側が、全然等価ではないのに注目。
このように、数式もどきを使って非論理的な議論展開をする人間を、
低学歴
と言います。
気をつけましょうね
コラ、そこでオナってる学生さん、注目だよ
> 皆さんも勉強を怠ると、こんな恥ずかしい低学歴になってしまいますよ。
ここで、句点の左側と右側が、全然等価ではないのに注目。
このように、数式もどきを使って非論理的な議論展開をする人間を、
低学歴
と言います。
気をつけましょうね
>>824
脳内乙
脳内乙
はい、よい子のみなさん、注目注目ぅ〜
コラ、そこでオナってる学生さん、注目だよ
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
ここで、等価演算子＝ の左側と右側が、全然等価ではないのに注目。
このように、数式もどきを使って非論理的な議論展開をする人間を、
低学歴
と言います。
皆さんも勉強を怠ると、こんな恥ずかしい低学歴になってしまいますよ。
気をつけましょうね
830 ：仕様書無しさん：2007/08/19(日) 23:16:45
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
等価じゃない２項の間に入っている「＝」は何の記号？
もしかして、文系無職ヒッキーは「＝」を文章区切りの句読点だと思っていたりして（ﾊﾞｸｼｮｳ
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
等価じゃない２項の間に入っている「＝」は何の記号？
もしかして、文系無職ヒッキーは「＝」を文章区切りの句読点だと思っていたりして（ﾊﾞｸｼｮｳ
結論：文系無職ヒッキーの俺様オブジェクト指向では、
通常 等価関係もしくは代入操作を表す「＝」演算子が
順次演算を表す「,」演算子に脳内オーバーロードされているので
要注意です
通常 等価関係もしくは代入操作を表す「＝」演算子が
順次演算を表す「,」演算子に脳内オーバーロードされているので
要注意です
脳内オーバーロードﾜﾛｽ
それってふつー「勘違い」って言わね？
それってふつー「勘違い」って言わね？
はい、よい子のみなさん、注目注目ぅ〜
>>830のように言語障害なのは低学歴の証拠だよ
爆笑の意味は大勢の人が一度にどっと笑うことだよ
大笑いだと勘違いしてる>>830のような韓国人になっちゃだめだよ
>>830
自国へ帰れ
>>830のように言語障害なのは低学歴の証拠だよ
爆笑の意味は大勢の人が一度にどっと笑うことだよ
大笑いだと勘違いしてる>>830のような韓国人になっちゃだめだよ
>>830
自国へ帰れ
無職ヒッキーの頭の中のお味噌がオーバーヒートした様子です。。。
>>832
必死だな
必死だな
毎度毎度感じる事だが、>>836っていつもレスがワンテンポ遅れてねぇ？
携帯電話必死になって打ってたりしてｗ
携帯電話必死になって打ってたりしてｗ
うぜえ=どうでもいい=つまらん=２人とも
むしろ伝書鳩で２ちゃんしてるんじゃないかと
とりあえず韓国人は反日が多いってことでおｋ？
842 ：仕様書無しさん：2007/08/19(日) 23:35:07
なつやすみのえにっき
１ねん１くみ にしむらひろゆき
８がつ１９にち（にちようび）はれ
きょうはかんこくじんのひとがすれにやってきて、
とうかえんざんしとじゅんじえんざんしのちがいをりかいできずに
ふぁヴょーんしていた。はんとうじんひっしだな
１ねん１くみ にしむらひろゆき
８がつ１９にち（にちようび）はれ
きょうはかんこくじんのひとがすれにやってきて、
とうかえんざんしとじゅんじえんざんしのちがいをりかいできずに
ふぁヴょーんしていた。はんとうじんひっしだな
843 ：仕様書無しさん：2007/08/19(日) 23:37:42
まあ、なんだ。
韓国人のカップルの多くが街中で手を繋いでるのは驚いたな。
文化の違いを感じた。
韓国人のカップルの多くが街中で手を繋いでるのは驚いたな。
文化の違いを感じた。
846 ：仕様書無しさん：2007/08/19(日) 23:42:28
等価演算子を正しく使えないゆとり世代(ぷ
またゆとりの仕業か
ゆとり＋無職ヒッキー＋２ちゃんにしか居場所が無い
で役満だな
で役満だな
タイトル：なぜオブジェクト指向は嫌われているのか？3
【糞スレランク：Ｂ】
直接的な誹謗中傷：39/848 (4.60%)
間接的な誹謗中傷：18/848 (2.12%)
卑猥な表現：14/848 (1.65%)
差別的表現：16/848 (1.89%)
無駄な改行：4/848 (0.47%)
巨大なＡＡなど：6/848 (0.71%)
同一文章の反復：4/848 (0.47%)
by 糞スレチェッカー Ver1.06
まだまだ他に比べたらマシでしょうｗｗ
【糞スレランク：Ｂ】
直接的な誹謗中傷：39/848 (4.60%)
間接的な誹謗中傷：18/848 (2.12%)
卑猥な表現：14/848 (1.65%)
差別的表現：16/848 (1.89%)
無駄な改行：4/848 (0.47%)
巨大なＡＡなど：6/848 (0.71%)
同一文章の反復：4/848 (0.47%)
by 糞スレチェッカー Ver1.06
まだまだ他に比べたらマシでしょうｗｗ
高級な話題と低級なじゃれあいという二者択一があると、
話の流れを低級なじゃれあいに持ち込む事しかできないのが
無職低学歴ヒッキーの特徴
話の流れを低級なじゃれあいに持ち込む事しかできないのが
無職低学歴ヒッキーの特徴
月曜日があ・・・
いやだあ・・・
いやだあ・・・
852 ：仕様書無しさん：2007/08/19(日) 23:49:12
稲
>>850
日本語でおｋ
日本語でおｋ
> 業務でオブジェクト指向使ってる奴ばかりじゃない＝オブジェクト指向スレでQCはスレ違い
また現実世界の話と、お花畑のバケモノフラワーの話の区別がつかなくなったのかｗ
また現実世界の話と、お花畑のバケモノフラワーの話の区別がつかなくなったのかｗ
曜日クラスの月曜日インスタンスは嫌われまくりだよな
ブルーマンデー症候群フラグは危険だし
ブルーマンデー症候群フラグは危険だし
>>854
必死だな
必死だな
いつもここに居る人へ
ここは実務的な話をするスレです。
あなたの脳内お花畑の話題はもうこりごりです。
さっさとデムパ板に帰ってください。
ここは実務的な話をするスレです。
あなたの脳内お花畑の話題はもうこりごりです。
さっさとデムパ板に帰ってください。
>>849
卑猥な表現が足りないな
卑猥な表現が足りないな
ヒント： いつもここに居る彼は、
サンドバック役を嬉々としてやり続けるいじめられっ子
サンドバック役を嬉々としてやり続けるいじめられっ子
>857
誤爆乙
誤爆乙
オブジェクト指向は疲労対効果が以下略
>857,859
なんというか、精神の不安定さと未熟さが滲み出しているんだよね、彼。
せっかく対話の場があっても、彼自身の知能と精神が成熟していないから
いつもつまらない会話にしかならない。さっさと消えてくれればいいのにね
なんというか、精神の不安定さと未熟さが滲み出しているんだよね、彼。
せっかく対話の場があっても、彼自身の知能と精神が成熟していないから
いつもつまらない会話にしかならない。さっさと消えてくれればいいのにね
どうでも良いかも知れんが。
業務外の趣味プログラムでしっかり構造化なりオブジェクト指向なりを
意識して作ってるヤツなんてそんなに居るのか？
業務外の趣味プログラムでしっかり構造化なりオブジェクト指向なりを
意識して作ってるヤツなんてそんなに居るのか？
>863
マジレス
業務でも作ってない
マジレス
業務でも作ってない
>>864
お前はオレか？
お前はオレか？
精 神 が 未 熟 で 不 安 定 な 人 間 の
自 作 自 演 行 為 は 、
と て も 判 り や す い
長澤まさみが人のもんになったんでもうどーでもいい
>>863
えっ？普通そうでしょ？
えっ？普通そうでしょ？
無職ヒッキーじゃ、どんな行為であろうと
一切業務でやってるわけねぇじゃん
ばっかじゃねぇのもったいぶって
一切業務でやってるわけねぇじゃん
ばっかじゃねぇのもったいぶって
>866
スペース連打乙
スペース連打乙
>>862
同意。さっさと死ねばいいのに
同意。さっさと死ねばいいのに
＞８６２ 禿同。ついでに一緒に死んでヤレ
妙な荒れ方しててワロス。
最近ウチでも馬鹿派遣雇って仕事してるけど
DIやインターフェイスの利用前提の設計をすると大抵理解できずに糞コード量産しやがる。
挙がってくる最悪なコードを全部添削して修正依頼＆ラチガあかないときには自分で修正してると、
軽くこの業界に対する失望感が漂ってくるよ…。
オブジェクト指向プログラムを業界の標準的なプログラマに期待できないなんて。
うちの会社もCMMIに力入れるのはいいが、技術力強化も忘れんなって感じだ。
最近ウチでも馬鹿派遣雇って仕事してるけど
DIやインターフェイスの利用前提の設計をすると大抵理解できずに糞コード量産しやがる。
挙がってくる最悪なコードを全部添削して修正依頼＆ラチガあかないときには自分で修正してると、
軽くこの業界に対する失望感が漂ってくるよ…。
オブジェクト指向プログラムを業界の標準的なプログラマに期待できないなんて。
うちの会社もCMMIに力入れるのはいいが、技術力強化も忘れんなって感じだ。
>DI
これはともかくとして(いや、できて当たり前のレベルだけど)
>インターフェイスの利用前提の設計
これできないのは、クズだよ
2004年頃、某証券システムの現場に入って、
これ理解できてない元COBOLerの大群が居て絶句した。
つか、自称OO判ってる風のインキュベーションの奴らが
インタフェースの意義理解できていないのには、もうあきれ返ったな。
いまさらインタフェースがどうこう言い出すなんて、10年遅れだよキミ
これはともかくとして(いや、できて当たり前のレベルだけど)
>インターフェイスの利用前提の設計
これできないのは、クズだよ
2004年頃、某証券システムの現場に入って、
これ理解できてない元COBOLerの大群が居て絶句した。
つか、自称OO判ってる風のインキュベーションの奴らが
インタフェースの意義理解できていないのには、もうあきれ返ったな。
いまさらインタフェースがどうこう言い出すなんて、10年遅れだよキミ
末筆だが
> うちの会社もCMMIに力入れるのはいいが、技術力強化も忘れんなって感じだ。
いまどきCMMIに力入れているとは、
本当に世間とズレまくってる会社だな。合掌
> うちの会社もCMMIに力入れるのはいいが、技術力強化も忘れんなって感じだ。
いまどきCMMIに力入れているとは、
本当に世間とズレまくってる会社だな。合掌
なーんて言いつつ、このおいら自身も
学生時代に研究所蹴った某関西系電機大手に
「(CMMIは興味ないけど)CMMI関連の支援ツール全般サポートしますよぉ」
ってにじり寄ってたクチだがｗ
世の中、引き際が肝心だよな。今時CMMIやってる自慢はねぇーだろっつう感じ。
学生時代に研究所蹴った某関西系電機大手に
「(CMMIは興味ないけど)CMMI関連の支援ツール全般サポートしますよぉ」
ってにじり寄ってたクチだがｗ
世の中、引き際が肝心だよな。今時CMMIやってる自慢はねぇーだろっつう感じ。
>>863 普通はするぜ。
趣味グラム ＞
オブジェクト設計と構造化は必ず行う。
多少難解な構造も最適と判断したらためらわずに持ち込む。
俺しか読まないからドキュメントとテストクラスは少なめ。
業務のプログラム ＞
オブジェクト設計と構造化はマネージャとリーダーの力量に合わせて行う。
難解な構造はリーダーに説明して「？」って顔になったら保守能力なしとして
多少汚いけど馬鹿でも何とか読める設計に直す。
ドキュメントとテストクラスは絶対に書く。
書き捨てのスクリプトは手続き型の時も多いが、
2回以上使う機会があったときにはリファクタリングなり構造を整理してから使う。
趣味グラム ＞
オブジェクト設計と構造化は必ず行う。
多少難解な構造も最適と判断したらためらわずに持ち込む。
俺しか読まないからドキュメントとテストクラスは少なめ。
業務のプログラム ＞
オブジェクト設計と構造化はマネージャとリーダーの力量に合わせて行う。
難解な構造はリーダーに説明して「？」って顔になったら保守能力なしとして
多少汚いけど馬鹿でも何とか読める設計に直す。
ドキュメントとテストクラスは絶対に書く。
書き捨てのスクリプトは手続き型の時も多いが、
2回以上使う機会があったときにはリファクタリングなり構造を整理してから使う。
もうさっきからタカヒロフラグ立ちまくりだな。
あんたこんなとこで何やってんの？
酔っ払いakonの日記の方が100倍はタメになる
あんたこんなとこで何やってんの？
酔っ払いakonの日記の方が100倍はタメになる
タカヒロフラグﾜﾛｽ
>>875
CMMIが時流ずれてること自体は理解してるんだが、
うちの会社の奴らは最低限のドキュメントすら残せない奴らばかりだから
多少こーゆーのも取り入れたほうがいいんだ。
CMMIのレベルがXXです。とか得意げに言い始めたら末期だが。
CMMIが時流ずれてること自体は理解してるんだが、
うちの会社の奴らは最低限のドキュメントすら残せない奴らばかりだから
多少こーゆーのも取り入れたほうがいいんだ。
CMMIのレベルがXXです。とか得意げに言い始めたら末期だが。
いやだからさ。
LL塊（ｗのこのご時世に、なんでCMMIの話題振る？
そんだけお前はCMMIに力入れているのか？
それとも遅れてきた自慢をしたいだけか？
皆目意図がつかめないんだよ、お前の話は。
LL塊（ｗのこのご時世に、なんでCMMIの話題振る？
そんだけお前はCMMIに力入れているのか？
それとも遅れてきた自慢をしたいだけか？
皆目意図がつかめないんだよ、お前の話は。
いや、べつにCMMIなんて俺もどうでもいい。
ただ、LL人気のこのご時世でも、ドキュメントは大切だよね。と。
ちなみに、タカヒロフラグで検索してもこんなのしかトップに出てこなかった。
ttp://samukisi.exblog.jp/3809074/
話題にまざれません＞＜
ただ、LL人気のこのご時世でも、ドキュメントは大切だよね。と。
ちなみに、タカヒロフラグで検索してもこんなのしかトップに出てこなかった。
ttp://samukisi.exblog.jp/3809074/
話題にまざれません＞＜
>>880
ああ、最低限のもの書けない奴いるよな。
そのくせ遅くまで仕事して「終電が無い」とか言ってるリーダーとか。
スケジュールも引けねーリーダーとかいらねー。
オブジェクト指向なんか当然理解ゼロ。
インスタンスなんか言った日にゃ、「タンスにゴン」とか駄洒落。
もうね、なんかね、疲れるんだわ。
ああ、最低限のもの書けない奴いるよな。
そのくせ遅くまで仕事して「終電が無い」とか言ってるリーダーとか。
スケジュールも引けねーリーダーとかいらねー。
オブジェクト指向なんか当然理解ゼロ。
インスタンスなんか言った日にゃ、「タンスにゴン」とか駄洒落。
もうね、なんかね、疲れるんだわ。
古くからOO業界に足を突っ込んでいたら誰もが気付いているタカヒロフラグ
航空宇宙関連業界に少しでも足を突っ込んでいたら
「今更そのレベルかよ！」とあきれかえるCMM
「今更そのレベルかよ！」とあきれかえるCMM
JavaでもC++でもいいんだけど、
「OOは知らん。他の言語ならやったころあるから分かる」ってるのに限って
構造化プログラミングどころか日本語もままならん。
「OOは知らん。他の言語ならやったころあるから分かる」ってるのに限って
構造化プログラミングどころか日本語もままならん。
>>886
そういうやつって、「俺はオブジェクトはやらないから…」とか言うよねｗ
そういうやつって、「俺はオブジェクトはやらないから…」とか言うよねｗ
888 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/21(火) 09:41:06
>>792
言っている意味が分からないが、ただ一つ気になる事がある。
それは俺の感情や境遇を予測した書き込みがあるが、俺の事を言われている気がしないことだ。
考えたこともない心理描写や、掛け離れた境遇で断定されても、妄想乙としか言えないな。
>>793
間違いを指摘しないのか？
>>795
ちょっと違う。766では一番大事な事をぼかして書いた。
ネットや参考書には載ってないが、ベテランの技術者なら分かっている事だ。当ててみな。
CMMって、「レベル1、プロセスが確立されていない状態」とかいうやつか？
古いな。「レベル5の次は何ですか？」「レベル1です。」ってやつだろ？
言っている意味が分からないが、ただ一つ気になる事がある。
それは俺の感情や境遇を予測した書き込みがあるが、俺の事を言われている気がしないことだ。
考えたこともない心理描写や、掛け離れた境遇で断定されても、妄想乙としか言えないな。
>>793
間違いを指摘しないのか？
>>795
ちょっと違う。766では一番大事な事をぼかして書いた。
ネットや参考書には載ってないが、ベテランの技術者なら分かっている事だ。当ててみな。
CMMって、「レベル1、プロセスが確立されていない状態」とかいうやつか？
古いな。「レベル5の次は何ですか？」「レベル1です。」ってやつだろ？
何故好きこのんで報酬もなしにこんな糞文の校正をせにゃならんねん
糞コテの分際で調子にのんじゃね
糞コテの分際で調子にのんじゃね
レベル5の次ってどういう意味なのかが全然わかんない
だんだん鬱屈してきましたｗ
892 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/21(火) 19:32:19
何が「当ててみな」だよ、クソが。何様のつもりだ。
おじゃばさまのつもりだろ
自分でさまつけてるような馬鹿相手に言うだけ無駄。
NGワード推奨：アホコテ
先端プログラマ系科学技術SE→コンサル→研究員→現在身分不明？？？ な俺様に言わせて頂くと、
おじゃま某の発言には、以下の問題点がある。
問題点1. >>766は、「ケアレスミスの原因分析」という>>764の話題に対して、
「バグ解析」という話題のすり替えを実行し、度重なる指摘（>>802他)を無視して
すり替えた話題を続行している点。
このように誠意のないコミュニケーション姿勢が、おじゃま某の発言に対する
信頼性を著しく低下させている。
問題点2.>>766はバグ解析の原因をいくつか挙げているが、
それらは所詮、要件確認にまつわるコミュニケーション上の問題に過ぎない。
とかごちゃごちゃ書こうと思ったけど、普段から酔っ払いみたいな支離滅裂な書き込みする
クソコテ相手にマジレスするのも馬鹿馬鹿しいなぁ、と・・・やーめた
結論： おじゃま某のNGワード推奨は、OO業界標準です。
おじゃま某の発言には、以下の問題点がある。
問題点1. >>766は、「ケアレスミスの原因分析」という>>764の話題に対して、
「バグ解析」という話題のすり替えを実行し、度重なる指摘（>>802他)を無視して
すり替えた話題を続行している点。
このように誠意のないコミュニケーション姿勢が、おじゃま某の発言に対する
信頼性を著しく低下させている。
問題点2.>>766はバグ解析の原因をいくつか挙げているが、
それらは所詮、要件確認にまつわるコミュニケーション上の問題に過ぎない。
とかごちゃごちゃ書こうと思ったけど、普段から酔っ払いみたいな支離滅裂な書き込みする
クソコテ相手にマジレスするのも馬鹿馬鹿しいなぁ、と・・・やーめた
結論： おじゃま某のNGワード推奨は、OO業界標準です。
閑話休題
２ちゃんぐるっと見渡して、アクティブなOOスレってここしかない現状、寂しいね。
いつもここでのたくってくキティが絶対探せない場所に、OOのコアな話題のできるスレ作んないと、
どーしよーもねぇなｗ
２ちゃんぐるっと見渡して、アクティブなOOスレってここしかない現状、寂しいね。
いつもここでのたくってくキティが絶対探せない場所に、OOのコアな話題のできるスレ作んないと、
どーしよーもねぇなｗ
>>898
> 話題のすり替えを実行し、度重なる指摘を無視し
これがこのスレの伝統だす。矛盾を突いてもスルスルと逃げ、
IDがでないことも手伝って、話題のすり替えもひどい。
まともな話にするには、住人の誠意が足り無すぎる。
> 話題のすり替えを実行し、度重なる指摘を無視し
これがこのスレの伝統だす。矛盾を突いてもスルスルと逃げ、
IDがでないことも手伝って、話題のすり替えもひどい。
まともな話にするには、住人の誠意が足り無すぎる。
誠意なんて、マ板で求めるもんじゃないだろw
ム板でも情シス板でも逝ってスレ立てればよかろう。
ム板でも情シス板でも逝ってスレ立てればよかろう。
903 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/22(水) 19:55:57
>>898
バグ要因解析がオブジェクト指向解析みたいで面白いと言う意見に対して、面白いかもしれないが
実際には役に立ってないと言う例を示して、オブジェクト指向設計が通常の分野の設計に役に立たないと
言う話に持って行こうとしたが、最初で止まっているだけだ。
勘のいい人なら分かるんじゃないか？
バグ要因解析がオブジェクト指向解析みたいで面白いと言う意見に対して、面白いかもしれないが
実際には役に立ってないと言う例を示して、オブジェクト指向設計が通常の分野の設計に役に立たないと
言う話に持って行こうとしたが、最初で止まっているだけだ。
勘のいい人なら分かるんじゃないか？
話を持って行けないのは技術がないからだろ。
お前の話はいつも「こういうつもりだった」しかないから
説得力がない。言い訳するよりネタを出せ。クソコテ。
お前の話はいつも「こういうつもりだった」しかないから
説得力がない。言い訳するよりネタを出せ。クソコテ。
＞バグ要因解析がオブジェクト指向解析みたいで面白いと言う意見に対して、面白いかもしれないが
＞実際には役に立ってない
と
＞オブジェクト指向設計が通常の分野の設計に(の？)役に立たない
の話の繋がりがさっぱり分からないわけだが、
同じ理屈で考えると(さっぱり分からんが)、つまり
「オブジェクト指向プログラミングは通常の分野のプログラミングの役に立たない」
コレがオブジェクト指向の嫌われる原因か。
つまり「役に立たないから」
そして話は最初に戻る、と。
＞実際には役に立ってない
と
＞オブジェクト指向設計が通常の分野の設計に(の？)役に立たない
の話の繋がりがさっぱり分からないわけだが、
同じ理屈で考えると(さっぱり分からんが)、つまり
「オブジェクト指向プログラミングは通常の分野のプログラミングの役に立たない」
コレがオブジェクト指向の嫌われる原因か。
つまり「役に立たないから」
そして話は最初に戻る、と。
906 ：仕様書無しさん：2007/08/22(水) 20:59:53
OOPL使ってるのにOOが嫌いとか言っちゃってるヤツがいたら、
この業界から早々と立ち去ってくれ。
この業界から早々と立ち去ってくれ。
一般論を装ったトンデモが並べてあったくらいで
例なんてどこにも出てないだろ
例なんてどこにも出てないだろ
908 ：仕様書無しさん：2007/08/22(水) 21:55:47
コボラが年功序列で中間管理職になったためにOOは嫌われる。
909 ：仕様書無しさん：2007/08/22(水) 22:35:35
＞＞９０３
また話のすり替えか。
ホント低学歴のコミュニケーション態度は劣悪だなｗ
また話のすり替えか。
ホント低学歴のコミュニケーション態度は劣悪だなｗ
愚かな低学歴が賢そうな顔して、
意味有りげなほのめかしをするから、
このスレはレベルが低い。
もし低学歴であっても賢い人間であれば
もったいぶらずに意味のある話をいくらでも書けるはずだ。
高学歴で賢い俺が言う話だから間違いはない。
突っ込みは全て却下。
意味有りげなほのめかしをするから、
このスレはレベルが低い。
もし低学歴であっても賢い人間であれば
もったいぶらずに意味のある話をいくらでも書けるはずだ。
高学歴で賢い俺が言う話だから間違いはない。
突っ込みは全て却下。
911 ：仕様書無しさん：2007/08/22(水) 22:56:19
>>910
へー東大出かすごいなー。
へー東大出かすごいなー。
912 ：仕様書無しさん：2007/08/22(水) 23:52:08
>>911
東大出は屁なのか。すごいなーｗ
東大出は屁なのか。すごいなーｗ
お前らのリアルを何とかしてモデル化しようっていう熱意みたいなものは感じるよ
せっかくだから、ここらでお前らのベストな解決法（設計法）をまとめてくれないか？
せっかくだから、ここらでお前らのベストな解決法（設計法）をまとめてくれないか？
914 ：仕様書無しさん：2007/08/23(木) 00:03:41
>>913
はぁ？なにそれ？
オブジェクト指向ってんだからオブジェクトつくりゃいいんだよバーカｗ
なんでそのクラスを作ったのかは後から説明付けて聞き手を説得できたら成功
説得できなかったら失敗。それだけ。
どんな手法を使おうが、どんな有名人のやり方だろうか他の奴にわからんようなモン
こさえたらその時点で死刑
はぁ？なにそれ？
オブジェクト指向ってんだからオブジェクトつくりゃいいんだよバーカｗ
なんでそのクラスを作ったのかは後から説明付けて聞き手を説得できたら成功
説得できなかったら失敗。それだけ。
どんな手法を使おうが、どんな有名人のやり方だろうか他の奴にわからんようなモン
こさえたらその時点で死刑
／ ＿ ＼
`/ (※) ヽ
｜ ￣ ｜
ヽ /＿＿＿＿＿ヽ /
ヽ|0|二二二|0|ノ
|Vヽ＿＿_ﾉV|
(d|･＝ゝ･＝ゝ|b)
Z/ (＿) ヽフ
/ ＠ ＠ヽ
（ー――〜〜―――) 死刑!!
＼＿＿＿＿＿＿／
てヽ_/ |o／／
／( て二／＼
（‖⌒￣￣))Ｏ￣＼
|┐ー( ｜|＼Ｏo｜
| Ln_)┘ ￣
`/ (※) ヽ
｜ ￣ ｜
ヽ /＿＿＿＿＿ヽ /
ヽ|0|二二二|0|ノ
|Vヽ＿＿_ﾉV|
(d|･＝ゝ･＝ゝ|b)
Z/ (＿) ヽフ
/ ＠ ＠ヽ
（ー――〜〜―――) 死刑!!
＼＿＿＿＿＿＿／
てヽ_/ |o／／
／( て二／＼
（‖⌒￣￣))Ｏ￣＼
|┐ー( ｜|＼Ｏo｜
| Ln_)┘ ￣
レス全然読んでないけど馬鹿ばっかりだな
917 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/23(木) 09:50:26
>>904
だから、バグ解析の目的と効果的な使用方法は？
ってネタ出してるだろ。
クソコテとか言う前に、俺を感心させる回答を出してみろ。
>>905
オブジェクト指向プログラミングの話じゃなくて、
オブジェクト指向分析・設計がシミュレーション分野以外で役に立たないって話だよ。
>>907
バグ解析が例だよ。
>>909
本当に理解出来ていて応用力もあるなら、もし話題のすり替えだったとしても適切に対処出来るんじゃね？
>>910
プログラマが学歴自慢しても空しいだけじゃね？
>>913
分野やシステムによってベストは違うから面白い。
だから、バグ解析の目的と効果的な使用方法は？
ってネタ出してるだろ。
クソコテとか言う前に、俺を感心させる回答を出してみろ。
>>905
オブジェクト指向プログラミングの話じゃなくて、
オブジェクト指向分析・設計がシミュレーション分野以外で役に立たないって話だよ。
>>907
バグ解析が例だよ。
>>909
本当に理解出来ていて応用力もあるなら、もし話題のすり替えだったとしても適切に対処出来るんじゃね？
>>910
プログラマが学歴自慢しても空しいだけじゃね？
>>913
分野やシステムによってベストは違うから面白い。
説得力のあるネタを出せ
↓
質問したじゃん
(;´д`)・・・？
今日日小学生でもこんな回答はせんやろ
↓
質問したじゃん
(;´д`)・・・？
今日日小学生でもこんな回答はせんやろ
もうほっとけ。意地になってるだけだ。
920 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/23(木) 19:30:47
何言ってんの？
「お前の」説得力が求められてるのに
なんで「お前が」質問するんだよ
頭おかしいの？
「お前の」説得力が求められてるのに
なんで「お前が」質問するんだよ
頭おかしいの？
>921
いまさら何をｗ頭おかしいんだよこいつは。
いまさら何をｗ頭おかしいんだよこいつは。
誰か釣られてやれよ
924 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/23(木) 20:28:22
まあまあ落ち着けって。こわくないから。
926 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/23(木) 20:39:09
なんだと、チキショー！
やんのか、オラァ！！
やんのか、オラァ！！
おじゃばキレんなよ。
冷静かつ凡庸、お前の持ち味じゃん。
冷静かつ凡庸、お前の持ち味じゃん。
>927
ひでぇw
ひでぇw
んじゃあ、おじゃば擁護派の俺が解答するよ。
バグ解析の目的と使用方法はPDCA知ってりゃ自明だろ。
施策に効果があったか測定するためにやるんだよ。
昔はバグ発生自体が良くないことだとされていたからな。
ただ、今更何の意味もないだろうが。
バグ解析の目的と使用方法はPDCA知ってりゃ自明だろ。
施策に効果があったか測定するためにやるんだよ。
昔はバグ発生自体が良くないことだとされていたからな。
ただ、今更何の意味もないだろうが。
>927
存在価値ゼロじゃんかｗ
存在価値ゼロじゃんかｗ
931 ：仕様書無しさん：2007/08/23(木) 22:27:48
だからさぁ、元ネタはバグ解析じゃねぇっつってのに、
いつまで話題をずらし続けたら気が済むんだよこの自称コンサル野郎が
いつまで話題をずらし続けたら気が済むんだよこの自称コンサル野郎が
流れブチ切りｽﾏｿ。
なんかUMLを書かないという方がおられますが、うちの業務はまるきし逆ですね。
シーケンス図、クラス図、相互作用図、状態遷移図は保守のために１００％作成します。
他のところではもっといろいろ書いてるのでしょうね。
うちの作業手順で、UML＋設計書を書いてないならコーディングしちゃダメ、ってのがあります。
最初は不便だと感じましたが、オンスケで品質が滅茶苦茶高いので驚きました。
あと、プロトタイプは今でもしょっちゅう作ってます。
特に画面系はプロトタイプ専属のグループがいるぐらいです。
IF相手の別会社もうちと同様にC++とJavaで組んでるのですが、
深夜残業の嵐で品質もひどいものです。。
聞くと、設計書はぐだぐだ、UMLに至っては何それ？ってレベルらしく、
ほぼ定時で帰るうちのグループとはかなり違います。
オブジェクト指向が品質を左右するわけじゃなく、
マネージメントの話が大きいとは思いますが、
やっぱりコアな人の技術力と政治力？発言力？は大事なんだなあとつくづく感じる今日この頃。
出来ない人が参画すると吊るし上げを食らって追い出されるのがちょっと怖いですけど（笑）
なんかUMLを書かないという方がおられますが、うちの業務はまるきし逆ですね。
シーケンス図、クラス図、相互作用図、状態遷移図は保守のために１００％作成します。
他のところではもっといろいろ書いてるのでしょうね。
うちの作業手順で、UML＋設計書を書いてないならコーディングしちゃダメ、ってのがあります。
最初は不便だと感じましたが、オンスケで品質が滅茶苦茶高いので驚きました。
あと、プロトタイプは今でもしょっちゅう作ってます。
特に画面系はプロトタイプ専属のグループがいるぐらいです。
IF相手の別会社もうちと同様にC++とJavaで組んでるのですが、
深夜残業の嵐で品質もひどいものです。。
聞くと、設計書はぐだぐだ、UMLに至っては何それ？ってレベルらしく、
ほぼ定時で帰るうちのグループとはかなり違います。
オブジェクト指向が品質を左右するわけじゃなく、
マネージメントの話が大きいとは思いますが、
やっぱりコアな人の技術力と政治力？発言力？は大事なんだなあとつくづく感じる今日この頃。
出来ない人が参画すると吊るし上げを食らって追い出されるのがちょっと怖いですけど（笑）
con・sult・ant [ http://dictionary.goo.ne.jp/voice/c/02020974.wav ]
━━ n. コンサルタント, 顧問; 〔英〕 主任医師; 相談相手
━━ n. コンサルタント, 顧問; 〔英〕 主任医師; 相談相手
知り合いの務めてるベンチャーはUML図からコードの雛形を生成させ
UML図を弄ればコードの対応する場所も連動するようにマクロ組んでやってるらしい
だからリファクタリングとかかなり楽で正直そのマクロだけでも欲しいなぁと思ったり
UML図を弄ればコードの対応する場所も連動するようにマクロ組んでやってるらしい
だからリファクタリングとかかなり楽で正直そのマクロだけでも欲しいなぁと思ったり
顧問っつうよりか、被後見人
主任医師っつうよりか、隔離病棟患者
相談相手っつうよりか、いつもブツブツと独り言言ってる変な人
だろｗ
主任医師っつうよりか、隔離病棟患者
相談相手っつうよりか、いつもブツブツと独り言言ってる変な人
だろｗ
> いつもブツブツと独り言言ってる変な人
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 ﾜﾛｽ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 ﾜﾛｽ
>>934
うちにもリファクタリングツールがあります。
JavaはEclipse使って、C++は内部で作成してます。
他にも、
シーケンス図を紐解いて？jpgとかテキストに出力したりするものや、
クラス図からソースのメソッドをピンポイントで探しだすものとか。
凄い人がいて、「めんどくさいから作った」そうです。
面白いのでは、
「オブジェクト指向体感ゲーム」「UMLはさぼれ」ゲームなるものまであり、
今ではこのゲームで１００点取るのが最初の仕事になってます。マジです（笑）
お金取れるんじゃないか？、と思うぐらいの出来です。
うちにもリファクタリングツールがあります。
JavaはEclipse使って、C++は内部で作成してます。
他にも、
シーケンス図を紐解いて？jpgとかテキストに出力したりするものや、
クラス図からソースのメソッドをピンポイントで探しだすものとか。
凄い人がいて、「めんどくさいから作った」そうです。
面白いのでは、
「オブジェクト指向体感ゲーム」「UMLはさぼれ」ゲームなるものまであり、
今ではこのゲームで１００点取るのが最初の仕事になってます。マジです（笑）
お金取れるんじゃないか？、と思うぐらいの出来です。
>>938
そのまま詳しく書くとバレちゃうので、そこはご了承ください。
作った人がヨットとスノーボードが好きらしく、
それぞれの部品の役割や他の部品との構成や関連性を作っていくゲームです。
ヨットの舵とセール（帆）の関連性で、
舵を動かせばセールも動かさないと風をうまくつかめない仕組みになってて、
単に関連があります、終わり、じゃなくて、
セールの張り具合を調整するためにバングという装置を使ってあげなきゃいけない、など、
考えながらやらないとクリアできないようになっています。
で、間違えた場合（風をちゃんとつかんでない場合とか）は、
シーケンス図っぽい奴とか相互作用図っぽいのが出てきて、
どこが違うのかを考えさせるような感じで、
ゲームにのめりこみつつ、嫌でもUMLを読破しつつ、みたいな感じになります。
ちなみにヨットの方はオブジェクト指向の初心者が敬遠するような言葉がほとんど出てきません。
UMLも同様です。
スノーボードのはもうちょっとゲーム性が高いのですが、
UMLがよりUMLっぽい感じになって、
言葉も専門色が強くなってきます。
で、オブジェクト指向ゲームとUMLゲーム（それぞれ専門色まるだし）をやる、
ってな感じになってます。
そのまま詳しく書くとバレちゃうので、そこはご了承ください。
作った人がヨットとスノーボードが好きらしく、
それぞれの部品の役割や他の部品との構成や関連性を作っていくゲームです。
ヨットの舵とセール（帆）の関連性で、
舵を動かせばセールも動かさないと風をうまくつかめない仕組みになってて、
単に関連があります、終わり、じゃなくて、
セールの張り具合を調整するためにバングという装置を使ってあげなきゃいけない、など、
考えながらやらないとクリアできないようになっています。
で、間違えた場合（風をちゃんとつかんでない場合とか）は、
シーケンス図っぽい奴とか相互作用図っぽいのが出てきて、
どこが違うのかを考えさせるような感じで、
ゲームにのめりこみつつ、嫌でもUMLを読破しつつ、みたいな感じになります。
ちなみにヨットの方はオブジェクト指向の初心者が敬遠するような言葉がほとんど出てきません。
UMLも同様です。
スノーボードのはもうちょっとゲーム性が高いのですが、
UMLがよりUMLっぽい感じになって、
言葉も専門色が強くなってきます。
で、オブジェクト指向ゲームとUMLゲーム（それぞれ専門色まるだし）をやる、
ってな感じになってます。
すげえ、感動した
ヨットのことよくわからないのでゲーム性がうまくイメージできないのが
すごく残念
ヨットのことよくわからないのでゲーム性がうまくイメージできないのが
すごく残念
ゲームがどんなもんかはわからないけど、楽しく学習できる工夫はいいよね。参考になった。
レス付いて気分よくなったから、詳細ちょっと書いちゃおっかな
ジャンルは３Ｄ格ゲー
実はゲームシステムはあまり評判よくない
ハメ技報告有、無限コンボ報告有、アーケードでは筐体から蹴音が響くこともめずらしくない
近年の格ゲーにアリガチな典型的なキャラゲー
各キャラのバランスが異常に悪い
女の子のコスはデフォで水着よりエロイ
声優が無駄に豪華
明らかにアニメ化を狙ってるところもキモさ爆発
男キャラの適当さ加減は一級品＆明らかに素人と思われる声優
ちなみに俺の使用キャラ（男）の弱パｘ３＋超必コンボ時のボイス
オブジェクト！
オブジェクト！
オブジェクト！
はぁぁぁぁぁ！これで終わりだ！
Ｕ！Ｍ！Ｌ！
・・・だっせぇ
ジャンルは３Ｄ格ゲー
実はゲームシステムはあまり評判よくない
ハメ技報告有、無限コンボ報告有、アーケードでは筐体から蹴音が響くこともめずらしくない
近年の格ゲーにアリガチな典型的なキャラゲー
各キャラのバランスが異常に悪い
女の子のコスはデフォで水着よりエロイ
声優が無駄に豪華
明らかにアニメ化を狙ってるところもキモさ爆発
男キャラの適当さ加減は一級品＆明らかに素人と思われる声優
ちなみに俺の使用キャラ（男）の弱パｘ３＋超必コンボ時のボイス
オブジェクト！
オブジェクト！
オブジェクト！
はぁぁぁぁぁ！これで終わりだ！
Ｕ！Ｍ！Ｌ！
・・・だっせぇ
943 ：あるじゃーのん ◆0aR9pKWx3A ：2007/08/24(金) 00:28:12
>>939
それ障害物よけたりコースのあるやつじゃね？
風向きは多分一定なんだろうけど
進路を変更すると帆と風向きが合わなくなるから、帆は基本風向きに対して調整しないといけない。
操作は自動か、舵だけを操作するのか知らないけど、
残りをパーツとかのパラメータから計算式で求める。
ゲームは単純だけどUMLとのリンクはどんな風に出すんだろ・・・
スノボの方がゲーム性が高いってよく分からない・・・
あんまり向いてない気がするけどいろんなテクニックを使うのかな
それ障害物よけたりコースのあるやつじゃね？
風向きは多分一定なんだろうけど
進路を変更すると帆と風向きが合わなくなるから、帆は基本風向きに対して調整しないといけない。
操作は自動か、舵だけを操作するのか知らないけど、
残りをパーツとかのパラメータから計算式で求める。
ゲームは単純だけどUMLとのリンクはどんな風に出すんだろ・・・
スノボの方がゲーム性が高いってよく分からない・・・
あんまり向いてない気がするけどいろんなテクニックを使うのかな
ゲームについては熱心に語っているが、
肝心のOOネタがあまりに貧弱なイメージで
ぞっとした
肝心のOOネタがあまりに貧弱なイメージで
ぞっとした
>>936
禿同
禿同
オブジェクト指向で設計云々言ってるやつはモジュールとどう違うのか説明してみろや。OOはただの文法だろうが。
>>946
OOは文法では無いけど…少なくともOOPLに於いては近いものだけどな。
OOは文法では無いけど…少なくともOOPLに於いては近いものだけどな。
949 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/24(金) 12:13:31
OO=Object Oriented
オブジェクト指向
指向と文法の区別つかない馬鹿ﾊｹｰｿ
オブジェクト指向
指向と文法の区別つかない馬鹿ﾊｹｰｿ
951 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/24(金) 20:16:31
952 ：wolf ◆8VH3XAqjlU ：2007/08/24(金) 20:19:07
>>937
>>ヨットとスノーボードが好きらしく、それぞれの部品の役割や他の部品との構成や
結構プログラミングが早いとお見受けしました
>>917
>>オブジェクト指向分析・設計がシミュレーション分野以外で役に立たないって話だよ
とレスされていますがゲームとか遊び系シミュレーションでオブジェクトを学習するのがやっぱ良さそうです
ただ >>917 は「小規模なシステムでは」が欠落などしているのでこの表現のままでは不適切かも
>>ヨットとスノーボードが好きらしく、それぞれの部品の役割や他の部品との構成や
結構プログラミングが早いとお見受けしました
>>917
>>オブジェクト指向分析・設計がシミュレーション分野以外で役に立たないって話だよ
とレスされていますがゲームとか遊び系シミュレーションでオブジェクトを学習するのがやっぱ良さそうです
ただ >>917 は「小規模なシステムでは」が欠落などしているのでこの表現のままでは不適切かも
953 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/24(金) 21:15:05
ゲームを使用してオブジェクト指向を学習するなら、海外ゲームのMODを試してみるといい。
MODと言うのはゲームを拡張するツールで、有名な海外ゲームではゲームを買うとおまけで付いて来る物がある。
例えば、NeverwinterNightと言うRPGでは、MODを使用してオリジナルのストーリーを作る事が出来る。
これを見ると、ゲームに登場する物全てがオブジェクトとして表現されている。
キャラクターやモンスター、アイテムはもちろん、地形や呪文など。
ツールを使うのにオブジェクト指向の知識は不要だが、最初からRPGのようなゲームを作るには、
今はオブジェクト指向は必須の技術で、ゲームでどのように使われているかよく分かると思う。
MODと言うのはゲームを拡張するツールで、有名な海外ゲームではゲームを買うとおまけで付いて来る物がある。
例えば、NeverwinterNightと言うRPGでは、MODを使用してオリジナルのストーリーを作る事が出来る。
これを見ると、ゲームに登場する物全てがオブジェクトとして表現されている。
キャラクターやモンスター、アイテムはもちろん、地形や呪文など。
ツールを使うのにオブジェクト指向の知識は不要だが、最初からRPGのようなゲームを作るには、
今はオブジェクト指向は必須の技術で、ゲームでどのように使われているかよく分かると思う。
ジャンルにかかわらずえらそうな奴ｗ結局自分がえらい言えれば何でもいいのね。
いかに上っ面かがよくわかるな。
いかに上っ面かがよくわかるな。
ゲームを「プレイしながら」と「作成しながら」を混同してるバカが1匹居るな。
つーか例がMODてアンタ・・・
ヘタな文章とは――
・書き手の言いたいことが明確でなく、主張が伝わってこない
・内容の構成や順序が整理されておらず、わかりにくい
・主張を裏付ける情報がなく、論理的に納得できない
・難しい用語が定義されないまま使われ、意味がわからない
・長い文が続くうえ、冗長な言い回しが多く、読みにくい
・書き手の言いたいことが明確でなく、主張が伝わってこない
・内容の構成や順序が整理されておらず、わかりにくい
・主張を裏付ける情報がなく、論理的に納得できない
・難しい用語が定義されないまま使われ、意味がわからない
・長い文が続くうえ、冗長な言い回しが多く、読みにくい
ムカツク、うぜぇ文章という意味ではうまいよなｗ
こんなことばっか言ってる奴がいたら確実に手が出そうだ。
本人が素でやってそうで、周りに同情するよ…
こんなことばっか言ってる奴がいたら確実に手が出そうだ。
本人が素でやってそうで、周りに同情するよ…
本人はまともなことを言ってると思ってるんだから手に負えない
周囲の人間はマジ哀れ
周囲の人間はマジ哀れ
ビヘイビアって何？
NGワード推奨： ◆
例えばの話し
人工知能のルーチンを作ってだね
これをクラスにして
複数のオブジェクトを作って
これらが会議を行う。
こういうのって、どうやって作るの？
オブジェクト同士が対等の立場でメッセージを交換するって出来なくね？
人工知能のルーチンを作ってだね
これをクラスにして
複数のオブジェクトを作って
これらが会議を行う。
こういうのって、どうやって作るの？
オブジェクト同士が対等の立場でメッセージを交換するって出来なくね？
>>962
GoF本のobserverパターンを読むとわかると思うよ
GoF本のobserverパターンを読むとわかると思うよ
962 名前： 仕様書無しさん [sage] 投稿日： 2007/08/25(土) 16:04:03
オブジェクト同士が対等の立場でメッセージを交換するって出来なくね？
963 名前： 仕様書無しさん [sage] 投稿日： 2007/08/25(土) 16:18:44
>>962
GoF本のobserverパターンを読むとわかると思うよ
またお花畑か
オブジェクト同士が対等の立場でメッセージを交換するって出来なくね？
963 名前： 仕様書無しさん [sage] 投稿日： 2007/08/25(土) 16:18:44
>>962
GoF本のobserverパターンを読むとわかると思うよ
またお花畑か
>>962
対等の立場ってどういう意味？
通常、人間の会議であってもまったくの対等はありえないと思うのだが。
通常会議を開催するのは議題があるときだし、議長がそれをコントロールすべきものと考えるけど。
対等の立場ってどういう意味？
通常、人間の会議であってもまったくの対等はありえないと思うのだが。
通常会議を開催するのは議題があるときだし、議長がそれをコントロールすべきものと考えるけど。
まぁ気持ちの悪いお花畑だこと
>>962
ある人工知能が別の人工知能の状態を変更する関数が作れるんなら、
ＯＯの場合は、その関数を人工知能のメソッドにするだけ。
ＯＯか非ＯＯかで、できることにそう違いはない。
規模が大きい場合は、ＯＯで組んだ方がわかりやすくなるとは思うけど。
ある人工知能が別の人工知能の状態を変更する関数が作れるんなら、
ＯＯの場合は、その関数を人工知能のメソッドにするだけ。
ＯＯか非ＯＯかで、できることにそう違いはない。
規模が大きい場合は、ＯＯで組んだ方がわかりやすくなるとは思うけど。
ネバーエンディングファンクションなんかやめてくれ( T T )
974 ：wolf ◆8VH3XAqjlU ：2007/08/26(日) 12:08:35
>>966
雑談orブレインストーミングに変更する。
ヒント：２ちゃんへの書き込って雑談じゃないかな？
いわゆるシュミレーション分野ではない今風社会のオブジェクト化ですね
これから真っ当なＯＯをやるにはいいテーマかも
なお、研究テーマとしては随分昔に流行りましたが
雑談orブレインストーミングに変更する。
ヒント：２ちゃんへの書き込って雑談じゃないかな？
いわゆるシュミレーション分野ではない今風社会のオブジェクト化ですね
これから真っ当なＯＯをやるにはいいテーマかも
なお、研究テーマとしては随分昔に流行りましたが
975 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/27(月) 21:15:48
>>954
意識して偉そうに言っているつもりはないが、偉そうに聞こえるとしたら954のコンプレックスじゃないか？
>>955
理解した上で言っているとしたら？
>>957
頭のいい人なら、下手な文章でも理解出来るのではないか？
>>958
現代日本で先に手を出したら負けだよ。
>>959
別に珍しい意見でもないだろう？本当のOOのゲームでの使い方を書いただけだ。
意識して偉そうに言っているつもりはないが、偉そうに聞こえるとしたら954のコンプレックスじゃないか？
>>955
理解した上で言っているとしたら？
>>957
頭のいい人なら、下手な文章でも理解出来るのではないか？
>>958
現代日本で先に手を出したら負けだよ。
>>959
別に珍しい意見でもないだろう？本当のOOのゲームでの使い方を書いただけだ。
976 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/27(月) 21:28:08
今更言うほどの事でもないが、人工知能とOOは関係ない。970の言う通りだ。
968の言う通り、発想のAIは難しい。今のAIは結局は判断文の塊でしかない。
しかし、AI機能をシステムに取り入れる、もっと簡単な方法がある。
それは、さて何でしょう。
968の言う通り、発想のAIは難しい。今のAIは結局は判断文の塊でしかない。
しかし、AI機能をシステムに取り入れる、もっと簡単な方法がある。
それは、さて何でしょう。
>>976
安上がりな人間を使うのが一番だろ。
安上がりな人間を使うのが一番だろ。
人工知能は例えの話であって質問の肝はオブジェクト同士が交信する方法だろ？
荒らしはスルーしれ
人工知能ってのは、人間には容易にできるけど、コンピュータには難しい分野のこと。
コンピュータに実現できた時点で人工知能とよばれなくなってしまう。
チェスだって昔は人工知能の分野だった。
コンピュータに実現できた時点で人工知能とよばれなくなってしまう。
チェスだって昔は人工知能の分野だった。
>>981
スレ違いの癖にいい加減なことホザくな
スレ違いの癖にいい加減なことホザくな
対応するメソッドの呼び出しにするかメッセージオブジェクトのやりとりにするか
動的にメッセージの種類を増やすなら後者しかないし
とりあえず受信側のメソッドを送信側が呼び出すって形でいいや
動的にメッセージの種類を増やすなら後者しかないし
とりあえず受信側のメソッドを送信側が呼び出すって形でいいや
>>982
的確な内容ですね。
的確な内容ですね。
ごめん、いつも同じ時間に煽りいれてたけど、今日は飲みに出てた。
かまってやれなくて悪かった、おじゃば。また今夜なｗ
かまってやれなくて悪かった、おじゃば。また今夜なｗ
987 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/28(火) 09:51:01
>>977
直接的に言いたい事は、ヨットゲームはネタだろうと言う事と、
間接的に言いたい事は、技術者にとってはゲームをすることと作る事は近い事だと言いたい訳だ。
>>978
正解。
>>979
議題は「オブジェクト同士が対等の立場でメッセージを交換する」だろう？
プログラミングの分野で言えば983のような事になるが、設計の分野で言えばすでにそういう考えを
取り入れたシステムがある。さて何でしょう。
>>981
俺も981の意見はウソだと思う。
現在のAIは単に用意されたパターンの多い処理を言うし、チェスは今でもAIと言う。
直接的に言いたい事は、ヨットゲームはネタだろうと言う事と、
間接的に言いたい事は、技術者にとってはゲームをすることと作る事は近い事だと言いたい訳だ。
>>978
正解。
>>979
議題は「オブジェクト同士が対等の立場でメッセージを交換する」だろう？
プログラミングの分野で言えば983のような事になるが、設計の分野で言えばすでにそういう考えを
取り入れたシステムがある。さて何でしょう。
>>981
俺も981の意見はウソだと思う。
現在のAIは単に用意されたパターンの多い処理を言うし、チェスは今でもAIと言う。
どうしても問題を出してる側にいたいらしいｗ
もはや会話のできる状態ではないなこりゃ。
もはや会話のできる状態ではないなこりゃ。
989 ：仕様書無しさん：2007/08/28(火) 20:56:25
最近オブジェクト指向を教わりました。
ほとんどの例で自然界の動物等が引き合いにされてますが、
静的なメンバーとか多態とかの説明になってくる時点で違和感が出てきます。
そもそも自然界では物理的に何かを共有することは不可能だと思うのです。
ほとんどの例で自然界の動物等が引き合いにされてますが、
静的なメンバーとか多態とかの説明になってくる時点で違和感が出てきます。
そもそも自然界では物理的に何かを共有することは不可能だと思うのです。
俺は彼女とパンツを共有してるよ
嘘だけどな
嘘だけどな
987 名前：おじゃばさま ◆GxjxF3yEw6 [] 投稿日：2007/08/28(火) 09:51:01
>>977
直接的に言いたい事は、ヨットゲームはネタだろうと言う事と、
間接的に言いたい事は、技術者にとってはゲームをすることと作る事は近い事だと言いたい訳だ。
存在自体がネタな奴がなんか言ってるな。
職場で間違いなく嫌われてネタにされてる奴ほど悲惨なことはないな。
おじゃばが嫌われる理由ははっきりしている。
ウザいんだよ。マジで。
１００％友人ゼロ。どうせ自称友人多数なんだろうが、バレバレすぎてイタイんだよ。
>>977
直接的に言いたい事は、ヨットゲームはネタだろうと言う事と、
間接的に言いたい事は、技術者にとってはゲームをすることと作る事は近い事だと言いたい訳だ。
存在自体がネタな奴がなんか言ってるな。
職場で間違いなく嫌われてネタにされてる奴ほど悲惨なことはないな。
おじゃばが嫌われる理由ははっきりしている。
ウザいんだよ。マジで。
１００％友人ゼロ。どうせ自称友人多数なんだろうが、バレバレすぎてイタイんだよ。
つ ネタ