ｵﾌﾞｼﾞｪｸﾄ指向開発は構造化開発と何が違うの？★7

過去スレ

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★4
http://pc11.2ch.net/test/read.cgi/prog/1173529414/

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★5
http://pc11.2ch.net/test/read.cgi/prog/1174746731/

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★6
http://pc11.2ch.net/test/read.cgi/prog/1175099288/

スルー推奨ワード（相手をした場合は荒らしとみなされます場合があります）
電球（日本語が通じません）、
たかひろ（本人はおそらく存在しないがアンチが荒らし化）、
おじゃばさま（レスは簡潔に）

>>1情報
http://megalodon.jp/?url=http://pc11.2ch.net/test/read.cgi/tech/1172431242/626&date=20070410182152

>>2 乙

ウェブ石碑：今週の人気の名言

　　　　http://sekihi.net/

Suisui解任動議 今現在
解任賛成 : 27 (42.2%)
解任反対 : 37 (57.8%)
票差 : 10
合計: 64


賛成票が増えて42%になりました。
もし反対票がなければ、あと11票（8%超）の賛成票が集まればsuisuiは解任になります。

投票期限まで
あと 4 日
投票期日 : 2007年5月2日 (水) 00:02 (UTC) まで
（注意！ : 日本時間では2007年5月2日 (水) 09:02 までが投票期日となります！）


彼を解任させたいかさせたくないかを考えるまであと4日あります。
議論まとめページを良く読んでじっくり考えましょう。

なお、この解任は、彼をメタウィキのスチュワードという
役職から解任させるものではありません。
日本ウィキペディアでの管理者という役職を解任させる是非を問うものです。
2chでのデマに惑わされないよう要注意して下さい。

なんだお前Wikipedia荒しもやっているのか。
アカウント500個以上使って荒してるバカも居るそうだが、
お前の事だろ

どうした？

おっぱい大好き星人が来たら呼んでくれ。
それまではスルーしとくわ

タモリ？
岡村？

すず●たかひ●

Win32APIのライブラリ作るんですけど、
言語はC++がいいんでしょうか

●●き●●●ろ

・・・もうなんか
す●●た●●ろ
って記号化してない？
本人が書いてる／書いていないに係わらず
本人の振りをして書いている人が何人もいるような気がするんだけど

すずきたか○○は ♂bject ♀riented 技術の似非コンサルタントですが、何か？

「本人はおそらく存在しない」って本人が言っても説得力に欠ける

・オブジェクト指向による開発とは、クラスとポリモフィズムを駆使して
本人も含めて誰にも解読できない、また改修不可能なバグを持ったプロ
グラムが作れる。
・構造化による開発は、巨大関数群の集まりでプログラムを作りあげるが、
時間を掛ければ解読は可能であり、バグの改修もできる。

また、本来デザパタは設計レベルで用いるものであるが、
デザパタ＝クラス設計レベルのノウハウ　という勘違い
のもと、クラス間の関連をパズル化しプログラムを解読
できないようにするのがオブジェクト指向による開発の
特徴である。

嗚呼勘違い

デザパタはアーキテクチャであり概念です。

>>18
何が？

壮絶な勘違いをしてるな

基本用語の定義が世間一般の定義とずれているだけだろう

>>21
>>22
勉強しなおしたほうがいいよ。がんばれ。

>>23
早く頭の病院に行った方がいいよ。かわいそうにね

>>24
開発は趣味に留めといてね。お願い。

>>1の頭はどんどんバカになってきたな。

次スレタイトル決定だな
・構造化開発と非構造化開発は何が違うの？
・高級言語開発とアセンブラ開発は何が違うの？
・電卓とソロバンは何が違うの？

>>25
大丈夫だよ。
キミがいつも出没している底辺現場には顔を出さないから。
そのかわり元請の指示にはちゃんと従うんだぞ。

デザパタはアーキテクチャであり概念です。
が理解できない香具師の多さが、オブジェクト指向の難しさを物語っているね。

>>27
ゲゲ！プロですか？ヲワタｗ

念のため、オブジェクト指向も概念です。

NGワード推奨：「デザパタはアーキテクチャであり概念です。」

　　　　　　　　　　↑
　　　　　　　　　　この人、下請け派遣スレでいつも必死になってる池沼です

■Suisui解任動議 今現在
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui_20070421#.E8.A7.A3.E4.BB.BB.E3.81.AB.E8.B3.9B.E6.88.90_.28Demand_the_resignation_of_the_sysop.29
解任賛成 : 28 (41.8%)
解任反対 : 39 (58.2%)
票差 : 11　/ 　合計: 67


賛成票が1増え反対票が2増えて41%になりました。
もし反対票がなければ、あと12票（9%超）の賛成票が集まればSuisuiは解任になります。

■投票期限まで　あと 3 日
投票期日 : 2007年5月2日 (水) 00:02 (UTC) まで
（注意！ : 日本時間では2007年5月2日 (水) 09:02 までが投票期日となります！）

彼を解任させたいかさせたくないかを考えるまであと4日あります。
議論まとめページを良く読んでじっくり考えましょう。

■以下の条件を満たさなければ投票することはできませんので注意して下さい。
* 初めて編集した時から動議提出時までに1ヶ月以上を経過していること。
* その間、標準名前空間を50回以上編集し、
* 動議提出時から遡って直近1ヶ月の標準名前空間編集回数が5回以上あること。
■なお、この解任は、彼をメタウィキのスチュワードという
役職から解任させるものではありません。
日本ウィキペディアでの管理者という役職を解任させる是非を問うものです。
2chでのデマに惑わされないよう要注意して下さい。
■関連スレ 【百科事典】ウィキペディア第385刷【Wikipedia】
http://hobby9.2ch.net/test/read.cgi/hobby/1177767325/

がんばれ。まだ時間はある。もっと勉強しろ。

閑話休題

GoF本すみからすみまで読んでも
クラス設計レベル、実装レベルの話が中心なんだよね。
アーキテクチャの事ならアークテクチャパターン本（POSA)やPoEAA
分析レベルのパターンの事ならアナパタ等を読むっつのが
初心者への適切なガイドだろう。

ここの池沼はまたどこで大きな勘違いをしてしまったのやら。
池沼の主張って同じ文章をコピペするだけで
根拠無しだから、勘違いの原因を推察するのも難しい

デザパタ狂信者といえばJPLoPの鈴木高弘が有名。

■Suisui解任動議 今現在
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui_20070421#.E8.A7.A3.E4.BB.BB.E3.81.AB.E8.B3.9B.E6.88.90_.28Demand_the_resignation_of_the_sysop.29
解任賛成 : 28 (41.8%)
解任反対 : 39 (58.2%)
票差 : 11　/ 　合計: 67


賛成票が1増え反対票が2増えて41%になりました。
もし反対票がなければ、あと12票（9%超）の賛成票が集まればSuisuiは解任になります。

■投票期限まで　あと 3 日
投票期日 : 2007年5月2日 (水) 00:02 (UTC) まで
（注意！ : 日本時間では2007年5月2日 (水) 09:02 までが投票期日となります！）

彼を解任させたいかさせたくないかを考えるまであと4日あります。
議論まとめページを良く読んでじっくり考えましょう。

■以下の条件を満たさなければ投票することはできませんので注意して下さい。
* 初めて編集した時から動議提出時までに1ヶ月以上を経過していること。
* その間、標準名前空間を50回以上編集し、
* 動議提出時から遡って直近1ヶ月の標準名前空間編集回数が5回以上あること。
■なお、この解任は、彼をメタウィキのスチュワードという
役職から解任させるものではありません。
日本ウィキペディアでの管理者という役職を解任させる是非を問うものです。
2chでのデマに惑わされないよう要注意して下さい。
■関連スレ 【百科事典】ウィキペディア第385刷【Wikipedia】
http://hobby9.2ch.net/test/read.cgi/hobby/1177767325/

>>33
同意。
「デザパタが概念だ」などと戯言を繰り返している人間は、
ちゃんとGoF本の原書を読み直したほうがいい。

おまいら本当にデザパタキチガイをからかうのが好きだな

>>2
この人一体だれ？聞いた事ねぇなあ。
有名人になりたかったけど有名じゃない人が
２ちゃんで売名行為をしているの？

この人が条件に一致します。
http://www.tisia.or.jp/uml/005.doc
>鈴木　高弘様　プロフィール概要
> 1. 1962年生まれ、宇都宮大学工学部電子工学科卒

>>34
>>37
デザパタは概念なので、例として、クラス設計レベル、実装レベル
を述べて解説しているのだよ。GoF本の原書をちゃんと読んだほうが
いいよ。

デザパタはオブジェクト指向設計パターンである。
つまり概念なのです。

池沼にマジレスしておくと。
GoF本は何度も言うように、
アーキテクチャ設計の詳細〜クラス設計〜実装レベルの話だよ。
つまり、キミが言うように設計レベル全般に関わる話とは違うよ。
主張を途中で変更して議論を続けるキミは、議論に負けたわけだ。
負け犬くんバイバイ

>>37
池沼の脳内では「概念」という単語の意味が
一般的に受け入れられているのとは違う意味に結びついているので、
一般人と話が通じないだけ。

>>43
中途半端なバイリンガルによくあるパターンだな。
オブジェクト指向の"Object"と、
実世界の操作対象"object"の区別がつかなくて、
なんかトンでもない脳内宗教を主張しちゃう奴。
オブジェクト指向が国内に輸入された当初にはあちこちに居たなｗ

なんだかとっても懐かしい気分

>>42
なんども言わせるなよ。
デザパタは概念なので、例として、クラス設計レベル、実装レベル
を述べて解説しているのだよ。

池沼の言う「概念」の原語は、一体どれなんだろうね。

がいねん 概念
・a general idea;
・a notion;
・【哲】a concept.
・〜上の　conceptual.

>>42
どうもオブジェクト指向には向いてないようだね。

中途半端なバイリンガル相手にする時は、
OEDから定義を拾ってきて選択を迫るのがデフォだろう。
あとは、彼がその宗教概念を構築する原因となったリファレンスを開示させるとか。

■Suisui（今泉 誠）解任動議 今現在
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui_20070421#.E8.A7.A3.E4.BB.BB.E3.81.AB.E8.B3.9B.E6.88.90_.28Demand_the_resignation_of_the_sysop.29
解任賛成 : 28 (41.8%)
解任反対 : 39 (58.2%)
票差 : 11　/ 　合計: 67

賛成票が1増え反対票が2増えて41%になりました。
もし反対票がなければ、あと12票（9%超）の賛成票が集まればSuisuiは解任になります。
■投票期限まで　あと 3 日
投票期日 : 2007年5月2日 (水) 00:02 (UTC) まで
（注意！ : 日本時間では2007年5月2日 (水) 09:02 までが投票期日となります！）

広域ブロック、対話拒否で批判されている彼を解任させたいかさせたくないかを考えるまであと3日あります。
議論まとめページを良く読んでじっくり考えましょう。
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui/%E8%AD%B0%E8%AB%96%E3%82%92%E3%81%BE%E3%81%A8%E3%82%81%E3%81%9F%E3%83%9A%E3%83%BC%E3%82%B8

■以下の条件を満たさなければ投票することはできませんので注意して下さい。
* 初めて編集した時から動議提出時までに1ヶ月以上を経過していること。
* その間、標準名前空間を50回以上編集し、
* 動議提出時から遡って直近1ヶ月の標準名前空間編集回数が5回以上あること。
■なお、この解任は、彼をメタウィキのスチュワードという
役職から解任させるものではありません。
日本ウィキペディアでの管理者という役職を解任させる是非を問うものです。
2chでのデマに惑わされないよう要注意して下さい。
■関連スレ 【百科事典】ウィキペディア第385刷【Wikipedia】
http://hobby9.2ch.net/test/read.cgi/hobby/1177767325/

池沼の相手飽きた。
バカはムリにハッタリかまそうとせず
バカに見合った底辺労働にいそしんでなさいってこった

>>39
聞いた事もねぇ大学だな

>>50
まだGoF本は早すぎたようだね。困ったね。

>>46
Design pattern is one of object oriented designe pattern.
Therefore, design pattern is *.
（*: a general idea, a notation, a concept)

くだらねぇ文章だな
Thereforeで導かれる文章の根拠が、その前の文章に全然示されていない。

>>52
キチガイ乙。

>>54
構造化設計の方が理解しやすだろうから、あっちで頑張れ。

GoF本の翻訳には、俺の元同僚(英国留学帰り)も誘われてたんだけど、
なんか自信が無かったのか暇が無かった知らんが、結局参加しなかったんだよな。
GoF本読みなおしてみると、ずいぶんひどい訳、意味を理解していないと思われる訳が
ところどころ見受けられる。

もし未だにGoFデザパタ本をありがたがる人が居るのなら、
さっさと再翻訳なり改訂版出すなりすればいいのにね。
SICP本みたく。

>>56
あのバカが関わっていたら、もっとしっちゃかめっちゃかな翻訳になっていたのは確実だｗ

本位田先生は、もうあの本は放置なんだろうか。
まあ今更再翻訳するまでもなく、気になる所は原書を見れば充分だけど。

デザインパターンについては多くの書籍があるよね。
その本の多くにはデザパタは概念であると説明して
あるね。

池沼はバカだから、何でも煽ればいいと思っているのだろうけど。
相手をよく見て煽れってこった。

池沼： GoFは神。GoFデザパタは聖典。
　　　　でもバカなのでゾッキ本しか読まずに
　　　　デザパタを理解したつもりになっているだけ。
上級技術者： GoF本の翻訳グループの知り合い。
　　　　翻訳に多少読みにくい点があって、
　　　　それが原因でゾッキ本が氾濫している事には気付いているが、
　　　　原書を読めば解決できるので無問題。
　　　　なぜ池沼がデザパタにこだわり続けるのか、理解に苦しむ。

>>53
池沼のマヌケ三段論法がやっと読めた。

1. GoFデザインパターンは、オブジェクト指向のデザインパターンである。
　(注：あたりまえ)
2. オブジェクト指向(OO)は概念である。
　(注：意味不明)
3. 従って、GoFデザインパターンとは、概念(のデザインパターン)である。
　 GoFデザインパターン⊂オブジェクト指向デザインパターン＝概念(のデザインパターン)
　(注：なぜ括弧内を省略可能なのか不明)

バカかお前は

ここに居る高弘よりも更に頭が劣悪な池沼って、
普段なにやってんの？
そんなにバカじゃ、まともな仕事に就けないだろ。

>>62
おもしろいな。おまいは。

>>63
それは秘密ね。

Fランク大学出身者にとっては、
翻訳本が聖典なんだろうな。
同情するよ

>>63
COBOLしかできない担当者の下請け

>>63
一年に一回か二回、大規模イベントで講演もどきをするが、
内容が幼いので全然話題にならない。

>>63
趣味は酒とゴルフ
好きなものはおっぱいとなかだし
最近ゴルフに誘ってくれる友人が少なくなって
暇をもてあましがち

>>67-69
誰かのプロフィールそっくりだな
もしかして本人？

お酒とおまんこのしすぎで脳細胞が破壊されているご様子です。

版画＝童貞

また脳内友達の話題か

>>69-71
あれはきっと戸田ちゃんのイタズラだと思う

>>74
そうなのか？
俺はまた本人の書き込みかと思ってたよｗ

版画ちゃん、ひとりで何ぶつぶついってんの？
はやく死んだらいいのにねｗ

さっさと死ね

　　　　　　　　　　　　　　　,．-- ､_
　　　　　　　　　　　　j「Y'´　　　　 ｀`ー-y'´￣`!
　　　　　　　　　　 [ﾆゝｲ　　　　　　　　　 ヽ.　 ｀`!
　　　　　　　　　　　　＞jﾕー-‐､_ ,r-､ /^ゝ!ｰ-､/
　　　　　　　　　　　　ﾌ厂「ﾄ､厂ｽ-､ _」| （ｲ-y ,ｲ
　　　　　　　　　　　 / /ﾘ‐j-」1ﾘ十l/´ゝソY^ﾆ7
　　　　　　 　 　 　　|/l 」Tｳﾞー'Tｳﾘ〃　l/　 「　　　
　　　　　　　　　 　 　　| ﾄ､' ' _　' ' '/ 　 j!　　|
　　　　　　　　　　 　 　{ ヾ｀ ｰrrｭ<7 　/|1 　 ヽ
　　　　　　　　　　　　 ∧ ,ﾚ'´ﾘ爪/ 　/⌒,　　　〉
　　　　　　　　　　　　/rイ　　l/ﾚ'　　|　　 l　　/
　　　　　　　　 　 　 /　ｶ〉_/,ｲ/　　 /　　 ﾄ､ _f二]
　　　　　　 　 　 　 /　/^Y / /　,ィ´　　　 ヽ1 「ヽ」
　 　 　 　 　 　 　 /[ﾆ>､ j/ソ ,ｨﾌ´二ﾄ､仄「ｽ　`ヽ
　　 　 　 　 　 　 〈　 ﾉ　//／ﾚ'ﾆ二」´￣「´ ｀,　　|
　　　　　　　　　　 ,ソ ,ｲ　　　|/　 ,　　 　 |　　i　　j
　　　　　　　　　／　/^ﾚ　　,ｲ 　 ,'　　　　ヽ　 l　,/
　　　　　　 _, イ　　/　f　 ,/　}　 i　　　　　 ﾄ､/ /
　　　　／／￣ゝ-､{　 l　/ _ノ __」ﾄ､　 　　 ヽf　j
　　 　,l／　　　　　　　,ヽj´ ,ｲ「｀T　i　　　　 lﾘ /ー-､ ＿
　　　 1　　　　　 　 ／　 　 j1|　 |　|　　　　 ﾚL_　　　　　｀7
　　　　＼　　　　／　　　　 |1| __」　L　､　, /　,ｲ　ー- ､ ,/
　　　　　 ＼　／　　　　　　|1二三三ﾄ､　 ryイj　　　 _／
　　　　　　　ヽ　　　　　　　　　＿,　-‐ゝ-f_ﾉノ　　　_/
　　　　　　　　 ＼　ー--‐ ' ´　　　　　＿ ＿,　-‐'´
　　　　　　　　　　＼ ＿__,．-‐ '"´￣

しかし、びっくりだね。
天動説な香具師が地動説に出会ったような騒ぎかただね。
まぁ、これまでアーキテクチャーの設計などには無縁なようだね。
デザパタはね。概念なの。
素直になって、それを念頭にもういちどGoF本を読んでみたら。
今まで見えなかったことが見えてくるよ。

釣れますか？

今日の漁獲はキチガイ一匹
不漁だね

まだ理解できないようですね。とても残念ですが無理ありません。
まぁオブジェクト指向は難しいので仕方ないですね。
オブジェクト指向を理解するうえで、デザパタという概念を理解することは重要なことです。
カルチャーショックを受けてかなり動揺されているようですが、
パラダイムシフトから落ちこぼれないように素直になって勉強してください。

ま
ま
オ
カ
パ

何の暗号だ？

あれぇ？デザインパターンが概念でないとしたら、いったい何なのでしょうか？

OO厨はほんとに言葉遊びが好きだなw

OOについての見解は前スレのおじゃば氏の話が大体の結論。
デザパタ厨が定期的に沸くので、誤解を恐れずに断言すると
デザパタはいわゆるプログラムテクニック集のようなもの。

平たく言うなら、ソートの種類をたくさん知っているとかそういう類。
もっと言うと、別にOOとは関係ない。

つまり、デザインパターンとはOOとは別のもので
熟練のプログラマーがよく使っていた
(プログラムの)デザイン(の)パターン(の一部)って事。

>>85
ありがとうございます。本当にびっくりしました。
特に『デザインパターンとはOOとは別のもの』っていうところが気に入りました。
ここまでの勘違と出会ったのは今日が初めです。凄すぎる。

『デザパタはいわゆるプログラムテクニック集』ってか。
オブジェクト指向モデリングが出来ないわけだ。
なんか今日は収穫が多いわ。
今後の講義のネタに使わせてもらいます。

『平たく言うなら、ソートの種類をたくさん知っているとかそういう類。
もっと言うと、別にOOとは関係ない。』ってところもなかなか素晴らしい。
マジ、しんじられな〜い。って感じ。

だから、デザパタは初心者が知っても有効な使い道が
わからない場合が多いし、知っていても
最適な実装方法という答えという話ではない。

>>89
わかるよ。実演ありがとう。

日々どうやってオブジェクト指向を伝承しようかと悩んでいます。
そこで初心者が陥りやすい勘違いを洗い出しています。
ご協力に感謝します。

文章を訂正

だから、デザパタは初心者が知っても有効な使い道が
わからない場合が多いし、知っていても
最適な実装方法という答えという話ではない。

単純に、自分ならこうするという方法に名前をつけただけなので
その方法が間違っていれば、当然デザパタを知っていても
知らなくても結果は同じになる。
又、実装方法や言語等で品質にもバラつきがあるため
実際には会話上の用語としての存在と思うと話が早い

>>92
つまり概念ということでしょうか？

オブジェクト指向とは関係ないけど、
ウィンドウ＝スレッド っていう勘違いもしてない？

>>88
別にそんなに違ったことは言ってないけどw
別にOOじゃなきゃデザインパターンの実装が出来ない訳じゃないし。
OOだとやりやすいよって話なだけだろ。

設計にしたって具体的な実装方法を知らなければ
最適なパターンは適応出来ない訳だし
デザパタで全ての設計が出来る訳でもないし。

デザパタ知っててもアホな適応すれば意味ないし。
お前みたいな教科書どおりの猿が一番駄目と思うけどw

あと初心者の勘違いで多いのは以下ですね。
・インスタンス＝オブジェクト
・クラス＋ポリモフィズム＝オブジェクト指向

文章を訂正

>>88
別にそんなに違ったことは言ってないけどw
別にOOPじゃなきゃデザインパターンの実装が出来ない訳じゃないし。
OOPだとやりやすいよって話なだけだろ。

設計にしたって具体的な実装方法を知らなければ
最適なパターンは適応出来ない訳だし
デザパタで全ての設計が出来る訳でもないし。

デザパタ知っててもアホな適応すれば意味ないし。
お前みたいな教科書どおりの猿が一番駄目と思うけどw

『別にOOPじゃなきゃデザインパターンの実装が出来ない訳じゃないし』っというフレーズ
も初心者の言葉に多いですね。現実的には無理でしょうね。初心者には無理。
熟練者でもOOP以外では、問題解決の本質に集中できなくなるので、かなりの苦痛を伴うと思いますよ。
デザインパターンはOOPから生まれた概念ですからね。

キチガイの自演をマターリヲチしませう

>>92
プログラムは全て概念だからね。
そしてここからここまでがこうです
という区切りも実はないし、意味がない事なんだよね。
それを力説しているのがOO厨には多くて辟易するね。

昔から厳密なOOの定義は多態、継承、隠蔽。
誤訳とかなんだとかいう話は、大抵はただの主観だからw
あからさまな翻訳な訳がないのは普通の人なら
ちょっと考えればわかるはずw

>>85
オブジェクト指向設計は概念で行うのよ。プログラムは実装だから概念ではないよ。

>>100
お持ちの概念が浅いし狭すぎるのでは。勉強不足ではないですか？
オブジェクト指向は難しいですよ。

>>98
だから誤解を恐れずにというフレーズを最初に入れたんだけどw
初心者には無理とか関係ないし。
正確にはデザインパターンというものは全部ではないにしても
以前から熟練者にはなじみのあるものだろーが。

それに名前がついたのが仮にOOP使用者だったからといって
OOPから生まれた概念って事になっちゃうのかね、君の場合？
そもそもOOって寄せ集めのような側面があるし。

ついこの間までInterpreterパターンも理解できてなかったバカが
ずいぶん威勢が良いな。
どうせ23パターン中にまだまだ多くの誤解や疑問を抱えたまま、
デザパタデザパタわめいてるんだろう。哀れな人生だ

>>103
>>104
ちょっと刺激が強すぎたですか。
カルチャーショックを乗り越えて勉強に励んでください。
私も最初は初心者でしたから。
私の場合、師に恵まれていたので遠回りをしなかったことが幸運でした。
みなさんも無駄に遠回りしないように、素直になって頑張ってください。

ＧＷなんですけど、家庭の事情で家にいるため、ここで遊んでいます。
伝え方が気にさわるようでしたらお許しください。
内容はすべてマジで書いています。

>>104
理解してないのはおまえだろっｗ
コードも書けないくせにえっらそうにｗバーカｗ
ゴールデンウィークもこんな過疎板に張りつきっぱなしでよお、
ヒキコモリのなかでも最低ランクな、おまえｗ
おまえより哀れな人生なんてねえよｗ常識的に考えてｗｗ

>>107
あなた誰？相手をお間違えでは？

　　　　　　　｡ﾟ･，ｗ.;:'ｗ;:,,.
　　　　　　ｗ 　（ﾚ'）ｗ;;'ｗ::`;.
　んもー_, ._　 /7;ｗ:｡;:；:ｗ;:'　　　　　　　　
　　 （　･ω･）//　 ﾞli;l'" ,.｡ｗ;:';.:'.ｗ、　
　　 /´＿l]つ'.;；:'ｗ;':;.. ,;":'；ｗ;'::;'w::`;
　　{{]}⌒)＾) ;':ｗ'；::ｗｗ;,.ﾞ':;｡;､;；ｗ:": '
.　　/,し' |:|　ﾞ'"''ヾヽ''" ;:'／
　 //===|:|.　ii　　ヾ|!li ,;､;ｗ；'｡;:,.
. //====|:|　ｗ　　 .|il!;':;,:；ｗ;`;:.;'
//=====|:|　,.｡;；ｗ:;｡,l!ﾞ//''ﾞ"`"
/======|:|,:､ｗ；`:ｗ:ﾞ;:.'/

>>102
オブジェクト指向が簡単とは言ってないですよ。
それにオブジェクト指向が問題解決の全てとも思っていません。

コストや規模、階層等に分けて使い分けるのが肝要と考えます。
オブジェクト指向を極めるのは有意義な事と考えますが
あくまでひとつの分野であってそれ以上でも以下でもないと考えています。
技術の種類は多いですから、効果の高い事を適時実行する
という形が理想です。それも実際には難しいでしょうがw

>>104
俺に言ってるの？
キチガイ？

オブジェクト指向で議論できるスレはないですか？
ここは初心者ばかりのようですし。

むしろ、お前こそ誰よ？ってカンジ

>>112
私は「デザパタ＝概念」男ですが。

鳥でも付けろ
IDすら出ない板なんだから

新参の方ですか？

>>110
いえいえ。オブジェクト指向は難しいので、しっかり勉強してくださいという意味です。

>>115
そうです。

キチガイのﾌｧﾋﾞｮｰﾝをﾏﾀｰﾘとｦﾁしませう
ここでｗの数がﾌｧﾋﾞｮｰﾝの度合いに比例しているのがﾎﾟｲﾝﾄですね。

>>116
日々励んでいますよw
それよりも、あなたはマスターwしていらっしゃるのですか？
そうであるなら、マスターwからの視点で
自説や有効な手段を展開されてはいかがでしょうか？

Interpreterパターンの例示せ示せってPy厨相手に暴れてるお前、
とっても笑えたよ。まさか再帰下降パーサも知らなかったとは、
ずいぶん情けない技術者だな。
学生時代からこれまで一体何してきたの？

オブジェクト指向への近道は、
『デザパタ＝概念』
でGoF本を熟読ってことで理解できましたね。

>>120
まんこばっかりしてきました

一応キチガイにマジレスしとくと

デザパタ＝概念
Design Pattern is a notion.

これ意味が通ってないよ。
日本語にまだ慣れていないんだろうけど、
デザインパターンのパターンがどういう意味の概念と対応するとか、
デザインパターンの本質はどういった概念で示されるとか、
欠けている言葉を追加しないと、日本人には通じないよ。
頑張って、日本語の勉強をして下さい。

なぜデザパタの話になったのか思い出しました。
以下が起点でした。

872 名前： 仕様書無しさん [sage] 投稿日： 2007/04/28(土) 15:07:47
初心者はデザパタ勉強したほうが近道なんでしょうか？

>>120
Javaのクラスがオブジェクトかどうかも知らなかった癖にえっらそうにｗ
このゴミｗ童貞のまま死ねｗ

>>118
お前みたいなのが増えて糞スレ化してたな。以前もw
お前は消えたほうがこのスレとしては有意義になるんじゃないの？

初心者の疑問から信念を抽出するﾌｧﾋﾞｮｰﾝ厨

それはともかく。
>>123にはしっかり答えた方がいいんじゃないかな。
>>123にすら答えられないのは、単なる低脳の荒しだろ。

>>123
了解です。

あともう一つ、キチガイにマジレスしとくと、
Javaのクラスは元々はオブジェクトじゃないね。
Reflection API導入で、Class.classという形で
Javaのクラス概念を操作するためのオブジェクトが導入された
というのが正解。

>>130
ギブ宣言乙ｗ

>>131
なんだギブアップか。
情けないハッタリだったな。

>>119
それは身内でのみします。
デザパタ＝概念の考え方は、このスレにとって地動説なみの特別サービスな提供になります。

あなた日本語下手あるね。
わたし日本語のネイティブあるよ。
あなたの日本語ブロークンすぎて
サパーリ理解できませんスミダ

>>124
デザパタを知ってもそれだけでは意味を成さないんですけどねw
OO厨の人が大きな声で有効性をアピールすると
道を誤る初心者も続出するでしょうねwww

>>132
なにがJavaのクラスはオブジェクトじゃない！だよｗ
わらわせんなっつのｗハゲｗ

ちなみに、現状Javaではクラスはreflection APIを通じてしか操作できないわけだが、

もしクラスがファースト・クラスのオブジェクトであれば、
クラス自体にも継承元となる上位クラス(例えばClassClass)が存在し、
またクラスの振る舞いをクラスメソッドに記述してカスタマイズする事もできる。

しかし実際のJavaのクラスでは、
クラスメソッドとはインスタンスの存在なしに動作できるメソッド
という程度の意味しか与えられていない。

キチガイ相手に大サービスしちまったな。
これもGWのお陰だ。感謝しとけよ毎日が祝日のキチガイさん

こんな低レベルなキチガイは高弘あたりに相手にさせとくのに限るな

今現在、マ板での最大の釣堀だと聞いて来たのですが。
すばらしい釣りを見ることが出来てとても嬉しいです。

>>135
それはその通りです。デザパタを知ってもそれだけでは意味を成しません。
デザパタを学んで気づかなければならない重要な点は、デザパタ＝概念 であるということです。
身に付けるべき点は、デザパタのセンスですね。これを概念レベルで正確に理解することです。
これが出来ないとオブジェクト設計は出来ません。

>>137
バカかおめｗ
Javaのクラスはインスタンスを持つっつのｗクラスローダごとになｗ
無知が偉そうにしやがって、キチガイとっとと死ねよｗ
このキモブタがよｗ

今日の漁獲はいつものキチガイ一匹だけだよ。
文末にｗつけまくってるのがキチガイの印。
GW中は不漁だね

よい子への注意：
クラスローダ毎に独自のクラス空間が存在し、
同じクラス定義を別々のクラスローダでロードする事ができるのは事実だが、
それはクラスがファーストクラスのオブジェクトである事の証明にはならない。

キチガイがいくら空理空論を振り回しても、
Java言語の実装に変化が生じるわけではない。

>クラス自体にも継承元となる上位クラス(例えばClassClass)が存在し、
なんだこれ？ｗ
Class.classが全てのクラスのメタクラスなんだがｗ
おまえほんとに存在自体が恥だなｗ

>>133
いえ、貴方が考える程
そんなたいした話ではありませんよ。
どうみても、本屋で数千円レベルの話です。
デザパタ=概念でも一向に構いません。
それ自体はただの言葉遊びですから。
それに実際に大事なのは、有効に使う為のノウハウですからね。

>>145
おいおいキチガイ
Smalltalkのメタクラスと
JavaのClass.classを混同するな

金魚鉢のボーフラなみに低脳だな

ゴタクは判ったから、さっさとその地動説の説明とやらやれよ。
はやく>>123に回答してね〜キチガイさ〜んｗｗｗｗｗｗｗ

趣味
おまんこ
好きな物
おっぱい
なかだし
ごるふ

>>147
おいおい版画ｗ
ぶっちゃけ失敗したと思ってんだろｗ

また脳内友達にヘルプを求めているのか
脳内にしか友達が居ないとは哀れな中年人生だな

キチガイ似非コンサル氏へ伝言

結局ここでいつも戯けた事わめいてる基地外って、
なんでこんなに暇人なの？就業しているように見えないんだけど。

>>143
だからお前のレスは糞だからいらないよw
記憶媒体の容量の無駄だから消えてね。
これからは地球に易しい人間を目指しなさいwww

>>85
『言葉遊び』ですかぁ。残念です。
本当にオブジェクト指向は勉強されましたか？
実践経験はありますか？

>>152
キチガイ似非コンサル＝ここで暴れているキチガイ

>>1-155まで一切コードもUMLも出ていないヘタレさ加減にﾜﾛﾀ
やっぱキチガイにはプログラムなんてかけないもんな

似非コンサルの知能が日に日に劣化していくのをマターリとヲチするスレ

1. スレッドの速さ

レス数 日付時刻
　　　1 2007-04-28 23:09:57
　 101 2007-04-29 18:35:13
　 157 2007-04-29 19:51:48

緊張型 別名「粘着型」
スレッドの進む速さが周期的に乱高下します。これは、ひとりの人間の寝起きに呼応しているためと考えられます。スレッドがいわゆる「粘着質な人」に侵されているのかもしれません。健常化するには当該者の隔離が必要でしょう。

2. 時間解析

不定期型 別名「俺スレ型」
一部の時間帯だけが突出します。一握りの人たちで回しているスレなのかもしれません。スレを落さないために1さんだけが必死なのかも。

>>85
『実際に大事なのは、有効に使う為のノウハウ』ですか。
ノウハウは大切ですが、実際に大事なのは概念レベルの理解です。
一般的にノウハウは、流れさるものが多いですからね。

あなたが概念を強調したいのは判ったが、
あなたの言う概念が、具体的に何を示しているのか説明が足りない。
例えば一つのパターンを例にとって説明してみそ。

釣れませんねぇ
脳が萎縮しつつあるから、具体的な話はムリかな。

アルコールとアドレナリンの海に浮かぶ
ちっちゃな味噌塊が、思考の焦点を合わせようともがいています…

>>160
いやです。ここで、遊んでいるだけですから。
技術の流出になるじゃないですか。私は無料ではありません。

そうだよね。厚生労働省のポリテクで日給貰わないと、飢えて死んじゃうもんね。
少ない知識と交換で日々のパンを漁る、貧乏人生万歳

>>160
オブジェクト指向について、世間の理解度を、計りに来ただけなんです。
このスレが妥当かどうかはかなり疑問ですがね。

千葉ポリテクかよ！
失業者〜浮浪者と同レベルじゃん
ずいぶん堕ちたものだな高弘

オブジェクト指向をこれから学ぼうと思っているのですが、
どのような順序で学んだらよいのでしょうか？
実際の業務で覚えるのが一番だと思うのですが、
今は違う業務のため独学になります。
ちなみにJavaの言語仕様は理解しています。

これぐらいしか思いつかないのですが、どれから手をつければよいでしょうか？
・デザインパターン
・UML
・お勧めの本

「いちばんやさしいオブジェクト指向の本」
「オブジェクト指向でなぜつくるのか？」
「実践UML」（途中で挫折・・）
は読みました。

失業者対策事業で日々の飢えをしのぐ似非コンサル万歳

2人しかいないスレで自演するのって、なんてストラテジ？

いや、少なくともほとんど読み飛ばしてる俺も居るぞ！

似非コンサルの人は、口先だけ動かして金を稼ごうとするのではなく、
他の有名コンサル同様、実践に裏付けられたコードや方法論、著作で金を稼ぐべき。
口先だけならなんとでも言える。
まして匿名掲示板で延々と自作自演するだけなら、
そこらのガキにだってできる。

>>169
T.Suzuki パターン

人気の名言

いや別に本気で聞いてもらいたい訳じゃないんだよな。
別に俺が得する訳でもないし。
ちょっとしたネタふりだよ。科学的根拠のない
適当なことを思うがままに書いてみただけなんだから、
突っ込みがあるかと思ったのだが、
あまりにサイコすぎたかな。

　　　　　　　　　　　　　　　　おじゃばさま (業務コンサルタント)

日本には著作で稼げるコンサルタントなんていないと思うけど。
・・・いや言い直す。
自分は日本人コンサルタントの書いた有名な著作を何冊か読んだが、
読む価値のある本は全く無かった。

>>173
まあ版画というリアルサイコを前にして、この発言はないなｗ
おじゃばのセンスのなさはガチｗ

要するに、キミには読解力も著作力もないから、
著作では勝負にならないって話だろ。
教育のテキストくらい、他人にまかせっきりにせず
自分で書いたらどうなんだろうね。

これから人気上昇する予定の名言


マルチスレッドロジックにマルチスレッドロジックが重なるアミダのトグロw
マルチスレッド・プログラミングは超絶難しい
　　　　　　　　　　　　　　　　　　　　　　　　　　　(業務コンサルタント)


データベースがリレーショナルモデルで排他制御するからなー。
ORマッピングで破綻しちゃうー。
　　　　　　　　　　　　　　　　　　　　　　　　　　　(業務コンサルタント)


俺は、会計とか金融とかのシステムを作りたいということが目的で、
それ以外のことに時間を割いてる余裕なんてないんだ。

内部の調査は、それに興味のある人間がするべきだ。
こちらが必要としている のは、正しく動くコードだということ。
　　　　　　　　　　　　　　　　　　　　　　　　　　　(業務コンサルタント)

>>154
私も広義の意味でのオブジェクト指向は日々勉強中です。
デザパタに関しては頻出度の高いものに関しては
効果的に使うノウハウをつかんだと感じています。
もちろん、業務に関係する部分でのノウハウ限定ですが。

OOの有効性を否定するつもりはありませんが
OOが全ての様な論調の厨が定期的に沸くのは
気にいらないですね。
実際に稚拙なシングルトンを実装しているOO厨を
現場で目撃した事もありますが、
OO厨は勘違い傾向が他の厨より圧倒的に高い傾向にあります。
声も大きい傾向があるのでなんとかしたいものですが…

そんなことより版画はまず就職しろｗ
おまえに人を批判する資格などないｗ

またSingletonか。
SingletonとFactoryとTemplateMethod, Chain of Responsibilityくらいしか
てめぇの口から聞いた覚えがねぇな。

世の中みんな休日をエンジョイしようというGWのど真ん中で
脳内友達の名前連呼とは悲しい中年人生だな
おまえ、生き方を変えた方がいいんじゃない？
例えば１年間２ちゃんから離れてみるとか

>>180
匿名掲示板の特定レスを、手前勝手に特定人格とバインドするのは何てパターン？

OO厨って高弘の事だろ。
デザパタとかオブジェクト指向とか、
高弘以上に声高に主張しまくる厨房見たことない

>>183
彼にとって、オブジェクト指向は宗教であり、
デザパタは世界の23不思議なのです。
アルコール漬脳味噌の思考などというものは、
所詮その程度のアクティビティしかないのです。

なんかおまぃら、
必死だなｗｗｗｗ

名言続出で、石碑を作るのが間に合わないYO!
もっとゆっくり名言を出してくれ！

つまんね

>>165
お前は自分に調子よく批判だけをしに来ているのはよく理解したので
もう俺にはレスしてくんなよ。
言い逃げするのがわかりきってるからなw

ウェブ石碑ってけっこうSEO頑張ってるんだな。
あそこに登録すると、すぐGoogleで引っかかるようになる。

>>180
うるさいよ。キチガイ。
妄想相手と勘違いして話をしてんじゃねーよ。
お前の電波具合にObserverパターンを適応したら
それこそフリーズもんだよw
病院逝けw

誰が誰に対して悪態ついてるの？
悪態ついているって事は、実はかなり的確な指摘だったんじゃないか。

新参vs版画
この板ではおなじみの光景

２人しか居ないスレで
また脳内友達と別人格が喧嘩してるのか。
大変な妄想だな

高弘がちょくちょく来るスレって、大体いつもこんな感じ。

>>176
教育テキストまで他人に書かせてるのか。
終わってるな

>>193-194＝版画
じゃあなんで来るのｗ

>>85
経験的に言えることですが、素直に受け入れる人は伸びますね。
素直な人は、学ぶ術をしっている。

>>197
それは言えてますね。
否定的に物を考える人間は、
うまくいかない理由と、その解決方法ばかり考えてしまって、
どうやったらうまくいくのかという思考がおろそかになる傾向がある。

>>196
キミの脳内友達は一体どこに居るの？
キミの脳の中にしか存在しないんじゃないか？

ウェブ石碑みたら俺が鈴木高弘になってるよw
ここの住人はキチガイなの？

なんか全体的にキモイしw
このスレ自体がやばいんじゃないの？

きっと監督・監修って意味だろ

>>85
『OO厨は勘違い傾向が他の厨より圧倒的に高い傾向にあります』には同意します。
OOというのは難しい技術なんですよ。高度な概念を学ぶには、確かな経験が必要
なのです。書籍だけでは無理があります。師に学ぶことですね。

このおじいちゃん
同じ事ばかり言ってらぁ

数年前に別の板に居たコテハンかぁ

>>203
キミは騙されやすいタイプですね

>>200
あんたほんとに新参なんだなｗ
いつものことだから気にすんなｗ

＞ここの住人はキチガイなの？
いまごろ気づくなよｗどんだけ鈍いんだおまえはｗ

文末のwがキチガイの印だよ

>>85
ただ、師に巡り会うのは難しいですね。はっきり言って運しだいかなぁ。

しっかしホントに内容ねぇスレだなぁ
今日はキチガイ一匹の自作自演状態だな

今日の漁獲：キチガイ一匹 (いつもの外道)

>>197
私が素直ではないと言いたいのですかね。
私の主観では「素直=学ぶ術を知っている」にはならないのですがw
癖のある技術者のほうがむしろ多いのでは？

>>198
私が否定的に物を考えていると言いたいのですかね。
私の主観では「ソフトウェアはうまくいく方法よりも
うまくいかない問題を解決する事で進化している」と考えていますがw
うまくいくだけで良いなら、OOはそもそもいらないのでは？


それにしても、このスレはなんか粘着質なかんじだなw
なんか気持ち悪いYO!!w

>>208-209＝版画＝リアルキティｗ
じゃあなんで毎日来るの？ｗ

変質者が戯言書いたりまともな振りしたり大変なスレだな。

>>210
> 私が否定的に物を考えていると言いたいのですかね。

その発言を見るに、キミは素直に人の発言を受け取る能力が欠落している。
つまり、キミは正しい。

> 変質者が戯言書いたりまともな振りしたり大変なスレだな。

それが T.Suzuki クオリティ

>>205
何か得たいの知れないキチガイが存在する様なので
そろそろ消えようかなw

>>202
>>207
たしかに師は重要なのかもしれないですね。
良いコードからは得るものがたくさんありますし。
もちろん悪いコードからも得るものはあるのですがwww

>>210
癖はありますが、良いところを伸ばすのが私の努めです。
そう、技術は進化していきますが、あなたはついて行けてないのかも。

>>214
消えたりせずに続けましょうよ。
OOについては、師を見つけるのは結構困難ですね。
下手すると、1000人に一人ぐらいじゃないですか？

> 変質者が戯言書いたりまともな振りしたり大変なスレだな。

結局おまえはこの発想から一歩も抜け出せないのなｗ
おまえにとっては発言自体の内容・本質より、誰がした発言かってことの方が重要で、
おまえ自身の本当の価値より、他者がおまえをどう見るかってことの方が重要なんだよなｗ
なっさけねえｗ
ま、ゴミは一生ひきこもってろってこったｗ

>>212
>>213
キチガイって怖いねw
ちょっと妄想しすぎなんじゃないの？
俺は何回も言ってるよ。病院逝けってw
絶対にお前達のためだって、正常じゃないってwww
2ちゃんだから相手してるけど、本来なら普通は相手しないよwww

狂信者って怖いね。
意味不明な会話だらけでマジ引くわ
頭悪いんだから、ムリして掲示板に出てこなければいいのにｗ

>>219＝版画
じゃあなんで毎日くるの？ｗそれも平日昼間っからｗ

要するに、こんな感じでいつも暴れているのが鈴木高弘だ
という事実が周知のことになればそれでおｋ

>>221
こんな過疎板でひとりづつに周知してるんだ？ｗ
さては馬鹿なんでしょｗ知ってるけどｗ

鈴木にはあと数年間は苦渋を舐め続けてもらって
奴がこれまでやってきた荒し行為のツケを払ってもらわないとな

>>167
師を見つけなさい。実際の業務で覚えるなら、師が必要です。
でないとデスマーチが待ってます。保守もできなくなります。

>>223
もっとひとが多いところいってやればぁ？ｗ
ν速行ってやれよｗこの根性無しｗ

>>215
貴方は教育者の方ですか？
それともキチガイですか？

>>216
人数比で話すのも違う気がしますが…
企業ごとの技術レベルにも大きな開きがありますしね。

あと、糞スレ化に一役買ってしまったみたいでwww
このスレには書き込まないほうが良かったみたいですね。
迷ったんですけど、ついwww

大丈夫でしょ。これだけageとけば後は検索エンジンが引っ掛けてくれる

私は教育者と言われる程の人間ではない。
単に失業者や浮浪者の手に職を付けさせる補助をしているに過ぎない。

しかし、現場のレベルは低いですね。
OOはやめた方がいいと思う。
構造化言語で、オブジェクトベースで設計するのがお勧めですね。
オブジェクトベースなら、ポリモフィズムは無いですから。
初心者のポリモフィズムは、オブジェクティブスパゲッティ化するから非常に危険です。

>>226
概念男の方です。

× しかし、現場のレベルは低いですね。
○ 似非コンサルが紛れ込む事のできる
　　似非大規模開発現場のレベルは低いですね。

本日のｼﾞｻｯｶｰｽﾚ

>>231
似非コンサルは、おもしろいから大好きです。

似非コンサル本人は面白可笑しいのでしょうけど、
荒唐無稽な駄法螺に付き合わされる周りの人達は大変な目に会うそうですよ。

>>234
大変なことになるのが目に見えるドキドキさがたまらない。
俺って変態？

そりゃ周りの仕事の邪魔するだけの本人は
ドキドキして楽しいんだろうな。

第三者から見れば、単なる穀潰しだけど。

熟練者がフレームワークをつくって、
初心者には葉っぱだけを担当させるのが常套手段です。
でも、その熟練者がいな〜い。

このままOOは廃れるのでしょうか？

似非コンサル

それはライバル会社がライバルを叩き潰すために送り込む
やっすい生物兵器

コンサルコンサルって、コンサルなんてどうだっていいっつのｗ
コンサルなんて使ったことねえし、そんなもんいらねえしｗ
だいたいおめえはムショクだろうがｗ
無為な人生を後悔しながら死ねボケナスｗ

OOで生産性は落ちたのではないですか？

半島からの破壊工作員も混じってたりする

OOで保守性も落ちたのではないですか？

OOで原因不明のバグが増えたのではありませんか？

無色のキチガイの切れ具合が絶妙だな。文末ｗくん

OOでソースコードが読めなくなったのではありませんか？

それなのに何故OOなのでしょうか？

文末ｗってそもそも就業経験あるのか

就業経験ｗｗｗ

ヒキコモリのおまえが、なんとかして優位に立ちたいってあがきか？ｗｗ
うっけるわｗゴミクズｗ

キチガイ大繁殖だな

携帯から煽れば済むレベルの糞スレ

就業経験を聞かれ
なぜか逆ギレしだす
毎日常駐の文末ｗ

さっさと首くくれや

文末ｗの話題はおっそろしく単調でつまらない

>毎日常駐の文末ｗ

もう何年間も常駐してるよな
昼に端末から見ても、帰りに携帯で見ても、
いつもどこかのスレで暴れてる

そいつが元祖キチガイ

毎日常駐くんが暴れると
全部S氏に嫌疑がかかる面白スレ

デザパタはアーキテクチャであり概念です。

話題が貧困
飽きた

今日のまとめ

文末ｗ氏は、生まれてこの方就業経験が無い。

女性経験もな

閉講

可哀想な文末ｗ氏

プロジェクトの最初の頃は、
「オブジェクト指向で作る！！」
って、気合入れてUMLの設計書が沢山出来たけど、
結局、プロジェクトの最後の方になると、
そんなオブジェクト指向っぽい設計書なんて誰も見なくなって、
結局、従来どおりの設計書しか見なくなる・・・

そんなのばっかり

で？

オブジェクト指向などクソの役にも立ちません！

流行ってる技術＝役に立つ技術 というわけではない！

なんだまだ恥ずかし毛もなく粘着してるのか童貞

オブジェクト指向など時間無駄、お金の無駄だ！

キチガイ降臨中(昨晩からずーっと)

>>268
なぜそんなに長い時間、こんな過疎板に張り付いているかって？
キチガイだからさ！！

オブジェクト指向は廃れる！

高弘乙

なんかどうしようも無い奴がいるようだな
GWだってのにお疲れ様なこった

大体、指向などというあやふやなもの使えるか！

オブジェクト指向って戦術を示さない経営者みたいだな。

基地の妄想は果てしない

オブジェクト指向って２０年先には笑いのネタになってるかもよ。

構造化言語で十分なんだよ。知ったか！

眠いスレだな。
高飛車くんが来たら呼んでくれ

概念や設計より実装技術が大事なんだよ。
実装技術があればどうにでもなる。

ソフトウェア＝プログラム＝実装技術

どうよ！反論できまいが。

スルー。
おっぱい星人が来たら起こしてくれ

バグは現場で起きるんだよ。実装技術がすべてなんだよ。

設計とか概念とかのたまう香具師は実装技術がない証。

実際、生産性、安定性、保守性のどれをとっても
構造化実装＞＞＞＞＞越えられない壁＞＞＞＞＞オブジェクト指向
だろうが。

きちきちばんばん

勝ったぜ。勝利！

流行りなど、文字通り流れて逝くだけ。

統合失調症

>>8=282が必死な件について

遠吠えが微かに聞こえるなぁ。ふふ。

本物のキチガイが暴れている

>>290
あまりに図星な欠点の指摘に動揺しているようだな。

なにこのキチガイ

>>292
遠吠えかぁ？

たかひろ が こわれた

リアルキチガイ観察スレ

不甲斐ないスレだ。オブジェクト指向も同じことよ。
俺様の完全勝利だな。遠吠えくん。

誰かおらぬなか！出会え出会え！

構造化実装こそ最適解である。ずばり。
以上

出張くん発狂スレ

>299
ここは出会い系じゃないぜ。

インスタンスとオブジェクトは同じですよね？

インスタンスはオブジェクトの１つ

//*******************************
// 荒らしは華麗にスルーしましょう
//*******************************

インスタンスがオブジェクトの１つだとすると
２つ目は何がありますか？

ん〜、マジレスすると、
クラスもオブジェクト。
大雑把に言えば、なんもかんもオブジェクト。

オブジェクト指向は、なんもかんもオブジェクトと考えれば良いのですね。

クラスだって状態と振る舞いを持つからな。

なんもかんもオブジェクト症候群になるまえに、
一回本を手に取った方がいいんじゃまいかな〜

クラスは、状態と振る舞いを定義する型ですよね。

型じゃなくて、クラス。

言語は何をやってるの？それで説明したほうがわかりやすい

脳内言語

Ｃ＃だす。

>>311
ヒント：static

逆に、状態と振る舞いを持つものを、
オブジェクトと定義することを今思いついた。
この定義だとクロージャもオブジェクトになるな。

クラスは型の一つですよね。クラス型っていうぐらいだし。

すまんが何を知りたいのかはっきりしてくれまいか
オブジェクト→クラス→型、と初心者問答が続くのだろうか？
初心者本を読んだ方がここで聞くより効率的だと思っちゃったりしちゃったりしてるんだが

インスタンスとオブジェクトの違いが理解できないのです。

インスタンスってのは、とりあえずはこう覚えておけばよし
「クラス型の変数宣言をしたときの変数のこと」

CString strData;

この場合のCStringがクラス型、strDataがインスタンス、
そしてCStringもstrDataもオブジェクト。
というか、コーディング中は「オブジェクト」という概念は捨ててよし（最初は）

>>318
あなたレベル高いんですね

C#であってもリフレクションAPIを使えば、
型情報経由でメソッドやフィールドへのアクセス
型の動的な作成、既存のオブジェクトへの動的な型のバインディング
等が可能。

これらの手法を使えば、当然 Smalltalkと同様なメタクラスシステムを構築し、
クラスをファーストクラスのオブジェクトとして扱う事が可能なはずだが、
実際のC#ではそのような言語デザインはなされていない。

どうもありがとうございました。

>>322
重いんだろ？

実行時型情報を使うとなると、その部分はやっぱり最適化が難しくなるからな。

高弘ちゃん、bizmoはいつ潰すの？

アクションゲームのプログラムにオブジェクト指向は
やめといたほうがいいことが最近わかった

>>327
そうなの？
見た目は部品分かりやすそうなんだけど

いまどきメタクラス・システム(クラスをファーストクラスのオブジェクトとして扱うシステム)
が流行らない理由：

1. メタクラスを多用したプログラミングは、多重の解釈処理が必要となるため、
　 プログラマーにとって判りにくく、また実行も重くなりがちである。

2. しかし実際のプログラムでは、メタクラスを必要とする部分はそれほど多くなく、
　 大抵の処理は通常のフラットなクラスシステム(クラスとオブジェクト)で記述できる。

3. フラットなクラスシステムでは記述しにくい処理(例えば動的なクラス操作、クラス生成)も、
　 リフレクション技術やバイトコード編集技術を使えば、ほぼ同等の事が可能になる。

4. その他の理由：
　 全てのクラスが、メタクラスを継承するような単純なメタクラスシステム(Smalltalk等)は、
　 言語設計者やコアライブラリ設計者にしかメリットをもたらさない。
　 もし、一般のライブラリ作成者がおのおの勝手なメタクラス定義に基づくクラスライブラリ
　 を公開したら、ライブラリ間でクラスの基本動作が異なるため相互運用
　 (ライブラリを組み合わせた処理)が極めて難しくなる。

言語設計者やコアライブラリ設計者しか変更できないような
中央集権的なメタクラス・システムを導入するよりも、
フラットなクラスシステムでほぼ同等の事を可能にする方が、
一般のライブラリ作成者に多くのメリットをもたらす。
だからメタクラス・システムは今は流行っていない。

>>329
長いな・・
smalltalkで開発してるところが無い＝メタクラスの概念が無いだけだろ

言語設計上のトレードオフだろ。

ついでに言うとだな、
全行にカタカナが入ってるようなとっつきにくい用語の羅列は
残念ながら敬遠される

英単語並べるよりはいくぶんマシだと思うがｗ
カタカナですら通じないんだったら、
それはそもそも背景知識が足りねぇんだろ

概念や単語を知らなければ、話も通じない。
単純明快

それもそうなんだが、
敬遠される事実をほったらかしにしてると、
「ぉいぉい、またあいつ突っ走ってるよ・・・」
「いいよ、ほっとこーぜ」
ってなことになっちゃわね？

概念や単語を知らずに、一体何を語りたいの？

逆に聞くけど、
smalltalkが流行らないことを語りたいの？

>>319
・インスタンスはクラス型の変数のこと。いわゆる実体と呼ばれます。
ちなみにクラスはメタクラスのインスタンスになります。

・オブジェクトは、オブジェクト指向のオブジェクトのことです。
物理的な物や概念な物をオブジェクトと呼びます。
よってインスタンスは、オブジェクトのひとつになります。

「Smalltalkのようなやり方でclassをobjectとして扱う」※のを
最近の言語が避けている理由

1. そのようなやり方(※)は、人間にとって動作を理解しにくく、
　　また実行時の動作も重くなりがち。

2. 大抵の処理は、それ(※)がなくても大体うまくいく。

3. うまくいかない例外的な処理であっても、
　　reflection APIや byte code編集技術を使えば大体うまくいく。

4. そのようなやり方(※)を苦労して実現しても、
　　それの利点を享受できるのは言語作成者周辺の人々だけである。
　　不特定多数の開発者がそれ(※)をいじりだすと、
　　相互運用性が低下する危険性がある。
　　不特定多数の開発者に触らせるインタフェースは
　　項目2, 項目3 のやり方が望ましい。

>>339
> クラスはメタクラスのインスタンス

それなんて言語

smalltalk、CLOS

smalltalkは、その開発環境自体もオブジェクトとみなすぐらいだからなあ

つか、スレタイと激しく違うネタだな

>>342
>>340

メタクラスってどう使うの？

メタクラスはメタメタクラスのインスタンスなのでしょうか？

なんかマックのハンドルみたいな。

クラスの挙動に使う。
たとえば初期化とか実行時の管理とか。
あまりにコアなんでJavaとかC#なんかの主要OO言語では
とっぱらわれてるのよ〜ん

メタクラスってビッグバンみたいなもの？

>>348
なんとなく分かってきました。

あ、ちょっと嘘言った。
Javaだとjava.java.classとかがメタクラスだけど
コーディングでは意識しないってことね。
いちいち考えないでしょ、こんなの。

XMLのDOMのように、それを使わなくても処理できるし、
それをあえて使うと処理が重くなるけれど、
あった方が操作対象が明確になる、という存在。

>>351
java.java.classでもクラスの挙動に使えるのですか。

ぶ、さらに嘘書いてる（笑）
java.lang.classね
すまそ〜ん

なんだぁウィキペディアからの抜粋じゃんｗ

何の話？

考え方はクラスと一緒
クラスに挙動を定義するとインスタンスの振る舞いを書ける
それがメタクラスとクラスになっただけ

何の話？

ついでに言えば、
メタクラスの挙動を示すのがテラクラス
テラクラスの挙動を示すのがテラワロス
テラワロスの挙動を示すのがイッテヨシ

>>357
簡単簡単

なんだ脳内妄想の人か

脳内妄想こそがオブジェクト指向の秘訣とみた！

java.lang.Classは、クラスのクラス＝メタクラスというよりは
クラスの型情報(Object.class等) に関する上位クラスに過ぎない。
メタクラス階層と、上位クラス階層は異なるものである事に注意。

どーにもこーにも盛り上がりに欠けると思ったら、
やっぱ脳内妄想の人がしこっているだけか

>>363
なるほど。隠し撮りみたいな感じですね。

正確にはクラスの型情報のクラス

糖質が来てるな

>>366
用途はなんですか？

こういう、Object指向のコア部分ってのは基本的には学者向けと言うかオナニーというか。
あんまり役に立たないけど語りたがる人多いよね。

一般の開発者にとって分かりやすいオブジェクト指向って言う点で考えたら
JavaとRuby辺りがいい線行ってるかなって感じだな。

ただ、RubyはRailsの台頭でむしろRubyの言語特性をあまり知らないまま使う
馬鹿が増えた気がしないでもないが。

JavaはJavaで極端なフレームワーク主義が台頭しているので、どうにもこうにも。

キミは一体何様ですか？
劣等感を感じるたびに、相手を卑下するようでは成長しませんよ。

最近LLパーサを覚えたばかりの初心者にとっては、
全てが為にする議論にしか見えないのだろう。
放っておけ

Webや本で読んだ内容をメモっとくためのスレがあると聞いて飛んできますた。

糖質粘着

塩分控えめ

オブジェクト指向の弊害は、オブジェクト指向の利便性に慣れきったしまったが故に
非オブジェクト指向のコードやレガシーシステムの保守時に、今まではこういうものだ
とあきらめ強引に保守していたものに対して、異常に拒絶反応が出てしまい、却って
そういうシステムの保守がままならなくなってしまうことだな。

糖質粘着は何年間も
同じ質問、同じ話題を繰り返す癖がある

>>346
そうです。ちなみにメタメタクラス（メタクラスのクラス）は Metaclass という名のクラスで、
これは自身のクラス（メタクラス）のクラスでもあるため、ここでループして終わっています。

メタクラスはあってもそれがオブジェクトではない Objective-C みたいな言語もあります。

糖質の質疑応答は、Web検索システムで取得できる範囲の情報に限定されている。

糖質は生の人間と会話ができない

俺はこの板で、相手を褒めたり、研磨しあうようなカキコを見たことが無い。
何を書こうが大抵は稚拙な叩き、貶し、煽りの類なんだが、日本には相手を
リスペクトしたり、コンプリメントする文化があまり育っていないんだなと
つくづく思う。基本的には足のひっぱりあい。出る杭は叩くのが基本姿勢。
一旦社会的に認められた奴は大いに持ち上げるが、そうでない奴の意見や足
を踏み外した奴は右へ倣えで徹底的に叩いてみせるのが、この島国の伝統的
な体質であり常識的な分別らしい。

スレタイと違って、構造化云々の話がでないけど、ここの人は
構造化分析/設計をマスターしている人はいないの？

>>380
プログラム板はそうひどくもないよ。

>380
お前は何もわかってない
表層だけチラ見して評価を下す無能だと自己紹介しただけだな

↑稚拙な煽りのいい例。

問題
コンピューターを使わないシステムを三つ挙げよ。 （使わなくても成立するもの）

答えられなかったらあなたは今後システムという言葉を使ってはなりません。

船舶、航空機、製造業と答えた人は間違いですX

あなたが間違っています

>>384
なにその稚拙なレスｗ
流石に噴いた

>>385
脇システム、山本システム、藤井システム

>385
おやぢ四段積みシステム

煽り専門のぬしが居座っているな。GWぐらいどっか遊びにいけよ。

コンピュータ自体を構成する要素はそれほど多くない。基本構成はCPU、メモリ、時計
ビデオカード、入力装置、出力装置だ。コンピュータの世界を表現するものは0と1だけ
だから、この単純な構成で、我々は実に様々な世界を創り上げ表現しなければならない
のだ。

必然的に我々は、実世界の概念をコンピュータに持ち込むためにメタファを使用する
ことになる。例えば言葉ではスタックと呼んでいても、実際にLIFO構造をもった物理的
な入れ物がPCの中に存在しているわけではなくて、ある電子的な入力に対して規則に
従った結果を返す仕組みをCPUとメモリを使って実現したものをそう呼んでいるだけだ。
CPUは、メモリと電子をやり取りし、レジスタの状態を変えているだけなのに、我々は
それを、物理的なスタック状の入れ物に値を出し入れするかのような場面を思い描く。
クラスにしても、オブジェクトにしてもそう。商品クラスとか、自動車クラスとか呼んでい
てもそれらはあくまでもデジタル信号であって、我々が理解し易いようにそんな*もの*が
コンピュータの中に実在するかのように勝手に脳内でイメージしているだけだ。

構造化もオブジェクト指向も、概念に対する捕らえ方や表現方法が異なるだけで、物事
を抽象的に捕らえるという意味においては本質的に同じなのだ。対極的に論じるよりも、
抽象化の視点をどこに置くべきかを論じるべきだと思う。抽象化は必要ないという人は
マシン語を使えばよいのだから。

と、いう理解で宜しいですか？

抽象化は必要ない→マシン語
これは短絡すぎないか？

■Suisui（今泉 誠）解任動議 今現在
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui_20070421#.E8.A7.A3.E4.BB.BB.E3.81.AB.E8.B3.9B.E6.88.90_.28Demand_the_resignation_of_the_sysop.29
解任賛成 : 32 (42.1%)
解任反対 : 44 (57.9%)
票差 : 12　/ 　合計: 76

今後、13票以上の解任賛成票が投じられない限り、Suisuiの留任は保証されます。

■投票期限まであと50時間を切りました。
投票期日 : 2007年5月2日 (水) 00:02 (協定世界時) まで
（注意！ : 日本時間では2007年5月2日 (水) 09:02 までが投票期日となります！）

広域ブロック、対話拒否で批判されている彼を留任させるべきか、そうでないかを考えるまであとおよそ50時間近くあります。議論まとめページを良く読んでじっくり考えましょう。
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui/%E8%AD%B0%E8%AB%96%E3%82%92%E3%81%BE%E3%81%A8%E3%82%81%E3%81%9F%E3%83%9A%E3%83%BC%E3%82%B8

■以下の条件を満たさなければ無効票になりますので注意して下さい。
* 初めて編集した時から動議提出時までに1ヶ月以上を経過していること。
* その間、標準名前空間を50回以上編集し、
* 動議提出時から遡って直近1ヶ月の標準名前空間編集回数が5回以上あること。
■なお、この解任は、彼をメタウィキのスチュワードという
役職から解任させるものではありません。
日本ウィキペディアでの管理者という役職を解任させる是非を問うものです。
2chでのデマに惑わされないよう要注意して下さい。
■関連スレ 【百科事典】ウィキペディア第i386刷【Wikipedia】
http://hobby9.2ch.net/test/read.cgi/hobby/1177830010/

そんなにsmalltalkがいいなら、objectiveC でいいじゃん

>>393
コピペ君って馬鹿だな、まで読んだ。

方法論などいらぬ。実装技術がすべてなのだ。

プログラミングがお粗末な香具師に限って、方法論だの、指向などと騒いでる。

話に聞くところ、オブジェクト指向は、達人のプログラミングセンスを分析して
導いたようですな。どのみち凡人には無縁ということですな。

>>391
抽象化というより仮想化でしょ。
自分で「〜かのように」って書いてるじゃん。
そうその発想が仮想化の発想だよ。

仮想機械の組み合わせとしてプログラム全体を設計する、とういう発想がOOPだとすれば
これは確かにOOP言語が出現するずっと前からやってきた手法ではあるね。
どんな仮想機械を想定しているかを明示的に表現できる度合いにおいて、
OOP言語はそうでない言語には違いはあるが。

それどころか工学全体で見れば、おそらく100年以上前からある発想だね。
例えばブロック図なんて仮想化の発想そのものだし、電気の等価回路という発想だって
ある意味そうなわけで。

人がブロック図をわかりやすいと感じる理由と、OOPをわかりやすいと感じる理由は
おそらく同じでしょう。

>>398
それデザパタのことじゃないの？w

>>399
オブジェクト＝デザパタ　だろうが！

釣りうざい

>>399 国語辞典かそうか？

メタクラスをオブジェクトとして扱わないのが最近の言語？違うだろ。
メタクラスはスクリプト言語とは相性が良いが
C#やJavaみたいなコンパイラとは相性が悪いってだけだろ。

でも、オブジェクト指向出来てるかどうかの判断って
デザパタのパターンがあるかどうかで決めてないかぁ？

デザパタには３つの扉があっとたい

>>399
抽象化と仮想化は違うぞ。設計や言語で扱うのは抽象化のテクニックだ。
対象とするものが問題領域で関わる性質や要素を抜き出して整理している
わけだ。ものそのものをまるごと再現しているわけではないからな。
ソフトウェアの世界での仮想化という言葉は、メモリやディスクといったコン
ピュータそのものが扱っているもの、或いは、シミューレータやエミュレータ
といった領域での話だ。

抽象化しすぎてキャストしてる設計をよく見るｗ

汎化と汎用が分かってない香具師が多い。

あと、派生クラスが１０００個ってのもあったなぁ。

>>406
なんか抽象っていう言葉の本来の意味を誤解してないか？
仮想化って言葉にも。
仮想化っていうのは本来字面があらわすとおり、もっとずっと広い意味で使われる
言葉だと思うけど。。


それ以前に話がかみ合ってないよ。
俺はオブジェクト指向とは仮想化の発想そのものだ、と言ってるんですが。。
設計って何の話だよ。

ああそうか、継承を意識したクラス設計の話をしてるのかな？
だから抽象とか訳のわからないことをいうのか。

>>410
オセロで石をクラスにしたり、ポットで水をクラスにしたりするタイプの方ですか？

>>403
まあな。動的言語じゃないと実装しにくいから、でおｋだと思う。
ちなみにSmalltalkはバイトコードをVM上で動かすコンパイラ言語だったりする。
Squeakの場合はVM自体がSqueakで書かれていて、それをCにトランスレートしてネイティブバイナリを作っていたり・・・

>>411
オセロで石をオブジェクトにしたのは、
全ての物をオブジェクトにしたら設計はどうなるか？
というゲームの下での話だったと思う。

更に付け加えると、石をオブジェクトにすべきか否かというディベート(模擬議論)では、
石をオブジェクトにするデメリットとしては、クラス数が増えて設計が大変になる、
といった消極的デメリットしか上がらなかったね。

オセロの石をオブジェクトにすべきか否かの結論は、
設計者の判断任せである。

・もし仮にオセロの設計が(思考部分等含めて)とても複雑になるのだったら、
クラス化対象の取捨選択も重要かもしれない。

・逆に非常に簡単なトイプログラムを練習で作るのだったら、
分析上現れる操作対象や事象を全てオブジェクトとしてみて、
その結果、設計や実装に不都合が現れないかどうか確認してみると良いだろう。

なーに、実際のJavaプログラムの中では、オセロの石どころか
「リクエスト内容(Event)」「処理結果の値(DTO)」「定数テーブル(ValueObject」
が飛び回っているのが現実ですから・・・

糞遅そーなオセロだな

>>413
石をオブジェクトにするとクラス数が増えて設計が大変になりますか？
ならないでしょう。

>>411
違うよ。
っていうか、意味がわからない。

仮想化っていのは、ある機能を果たす仮想機械を作ることであって
問題領域に出てくる名詞をとにかくクラスのすることのわけがないだろう。

一種のValueObjectだから、速度への影響はほとんどナッシング。
もし微妙な速度低下も気になるなら、Flyweightパターン適用でおｋ

ってそんな微妙な話はキミには通じないよね

>>414
設計者の判断任せではなく、石に責務があるかどうかが論点ですね。

今ここで行われている議論は、要するに

「コンピュータ〜ソフトウェアの本質＝仮想機械を作る事」と仮定すると、
オブジェクト指向のモデリング能力は、まさしくその機能を提供するのに適している

という話でよろしいか？

>>420
そのように聞こえるねｗ

>>420
そういうの「言語明瞭意味不明」って言うんだよ。

オブジェクト指向のモデリングの能力って何だよw
モデリング能力という属性は人間に付くんだろうよw

そうじゃなくて、君が使っている言葉をつかって別のフレーズを作るとすれば、
モブジェクト指向とはモデリングの一種であり、それは全体を（小さな）仮想機械による
分割統治して設計するものである、という感じだな。

>>391
>構造化もオブジェクト指向も、概念に対する捕らえ方や表現方法が異なるだけで、物事
>を抽象的に捕らえるという意味においては本質的に同じなのだ

捕らえ方や表現方法が異なったら、本質的に同じわけないだろ。
本質的には別物だよ。

>>423
そらお前さんがわかってないだけ。
その点では>>391は間違ってない。

>>419
私は責務マンセー主義ではないので、あなたには同意できません。
オセロの石のオブジェクト化には、次のメリットがあるので、
私はオブジェクト化するのが適切であると考えています。理由は以下の通り

1. 視覚要素を提供する責務がある
2. プレイヤーの持ち駒数に制限がある（システム内で限られた数の資源の管理）

>>422
まぁなんでもいいや。
こっちの話は、
オブジェクト指向のモデリングは、
現実のシミュレーションを行うには表現力が弱い、
だからアスペクトを導入しろっていう話だから。

>>425
実際にはプログラム書いたことがない人かな？w

１はともかく、２は普通は「石のコレクションクラス」とか
「石たちのマネージャクラス」に仮想化するでしょ。

>>425
・視覚要素を提供するのは局面クラスの責務です。
・プレイヤーの持ち駒数に制限は必要ありません。

分割統治という観点で見た場合、
　package → class (→ innerclass) → method, variable
という階層構造は、
例えばコンポーネントとかフィーチャーとかサービスと呼ばれる中粒度の分割や、
複数のクラスが相互作用して小さな機能を実現するひとまとまりのクラスのような中〜小粒度の分割
が弱い。

それは単に粒度の問題だけではなく、
クラス実装と機能提供が必ずしも一致しない、
というマッピングの問題である。

>>427
おいおい。
キミがまた罵倒文句を出してくるなら、
キミが大規模開発でやった画面とモデルが分離できていないクソ設計の件を蒸し返してもいいんだぞ。

>>425
良かったね。新境地が開けて。主義でないとか言って、型にはまるのはまだ早いよ。

>>428
> ・視覚要素を提供するのは局面クラスの責務です。

まぁ、そこは設計者が好ずきなら、キミの好きにすればいいさ。
実際問題、まともな思考アルゴリズムは、オブジェクト指向でなど設計しないから。

> ・プレイヤーの持ち駒数に制限は必要ありません。

それは、練習問題設定上のアヤさんですね。
私は「アプリケーションのルールを分離記述可能にする」
という練習問題を皆に解いて欲しかったので、
現実に存在するオセロ系ゲームのルールのバリエーションを調べ、
ある種のルールでは「駒数制限がある」という事実に基づいて
分析例を出しただけです。あなたがそれに同意できないなら、
勝手にすれば良いでしょう。いつものペテンコンサルティングのように

>>432
ルールを分離記述するというテーマは興味深いな

>>432
>「アプリケーションのルールを分離記述可能にする」
それなら石をクラスにする必要性がまったくありませんね。
模範解答を持たずに、練習問題を皆に解いて欲しいなどと
ごねてはいけませんね。

鈴木流オブジェクト指向だと分析クラスと設計クラスが一対一に対応しちゃうんだろうな。

分析モデルはビジネス分析と同様、現実の事象や概念を扱い、
設計モデルで分析モデルの実装方法を検討する
というのが、現実の仕事に即しているわけだがｗ

>>435
なるほど。
だからこいつは「石オブジェクトなど絶対要らない」などと
どうでもいい主張に固執しているわけか。

分析モデルと設計モデルは別物です。
分析モデルの段階で、実装方法を考えると、
現実の問題を適切に分析できません。
ちゃんと勉強してこい

>>432
もしかして石の数を管理するのに、石の数だけインスタンス作るのですか？
これが仮想化指向の神髄とみた。

ビジネス分析の途中で、「これはFactoryで実装すればいいね」とか言い出して
アナリストに怪訝な顔をされている予感

>>435
は、>>425のことを指してるのではないですか？

>>437
Flyweightパターンを勉強して来い
新しいIntegerクラス設計では、
-128〜128の整数をSingletonでプールして、
Flyweightで関連付けるとかいう話があったな。

>>439
やっぱキミは理解度が低すぎて、
会話にならないや

バイバイ

>>441
ありゃりゃ。恥ずしいことじゃないよ。また戻ってこいよ。

>>439
オセロの石は、最初っから分析モデルの話。
で、分析モデルで現れたオブジェクトを
削除する理由が特段無かった(>>413)から、
それを設計モデルで素直採用したら>>425のようになる
というお話。

>>427みたいな意見は、J2EEもがきで頭が固まっちゃってる人の実装方法でしょ。

でさぁ。鈴木はいつになったらアスペクト指向の話ができる程度に進化するんだ？
お前はいつまでたっても幼稚な話ばかりで全然脱皮しないな

>>443
ひょっとしてそれ本当に真面目に言ってるの?

統合失調症が出てきたな

統合失調はおっぱいをまさぐりはじめた

>>445
で？

統合失調の話は下らない話ばかりで退屈

現場主義のﾄﾞｶﾀは分析工程へのオブジェクト指向の適用経験が希薄なので、
分析モデルと設計モデルの区別がついていないようです

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

という、理解で宜しいですか？

そりゃそうだろ
分析工程をﾄﾞｶﾀに任せたら、とんでもない結果が出てくるからな

ﾄﾞｶﾀが理解している分析モデルは、要件定義が完了し、実装方法を検討する前段階で作る
一種の設計モデルに過ぎない。
ﾄﾞｶﾀには、分析モデルと設計モデルの間にある大きな飛躍を理解できない。

分析モデルと設計モデルって、そんなに大きな差があるものなの？

システムの提供する機能範囲や、実装方法を考慮したものが、設計モデル。

じゃあ分析モデルはなんなのさ？

>>451
という理解で宜しいか、もなにも
言ってる本人が自分がどういう意味で「抽象化」という言葉を使っているのか
よくわかってないでしょ。

分析モデルは、問題領域のモデル化だろ。
どこまでシステム化するか、どうやって実装するか、はある程度は考慮するが、
実装のクラス設計をどうするなんて瑣末な事とは全然無関係。

>>451
よろしいと思いますよ。よく勉強されてるしオブジェクト指向の本質を
理解されていますね。

パッケージやミドルウェア開発していれば、
オブジェクト指向で分析モデルを作る機会に恵まれるが、
国内でOOで大規模開発やるぞー！とかハッタリこいている連中は、
オブジェクト指向でビジネス分析などさせてもらえないのが実情。

ほら、前スレのタイトルも、OOD/P ってなってて、OOAは範囲外になってただろ？
それが大規模開発系ﾄﾞｶﾀの現実

>>460
なーんだ。オブジェクト指向で大規模開発なんて威勢のいい事言ってると思ったら、
実際は設計〜実装しかやってないのか。だらしねぇ〜

>>451
なに意味不明な駄文を書いて自作自演でオナニーしてるんだよｗ

>>451
これを理解できるかどうかであなたのレベルが分かりますよ。

技術レベルの低い人間の戯言はスルー

>>462
それは才能に対するひがみです。

レベルの低い人間でもプライドだけはしっかりある
という事実に辟易する今日この頃

大規模OO開発の連中は、分析モデルなど作った経験がないから、
分析に実装レベルの話を持ち込む荒唐無稽さを理解できない

これが事実

マジですが、>>451 さんの考え方を理解できるように勉強しなさい。
このスレにはもったいない方です。

まだ自作自演を続けるか・・・

>>469
ちがいます。私は>>451さんとは別人。

>>469
理解できないのね。がんばれ！

>>469
なら、>>451への疑問点を挙げてみて。

>>451は統合失調症患者の落書きです。
スルーして下さい。

というか、分析モデルと設計モデルって、
何が違うの？
というか、モデルって何？
ってなところの知識を要求されるからOOって敬遠しちゃうんだよな〜
抽象とか仮想とか分け分からんし
ん？学習不足は自覚しとるよ

>>473
いやいや。目覚めるチャンスだぞ。もったいない。

よりによってコタツの仮想化、扇風機の抽象化とは
どれだけ頭が爆発しているんだ・・・

コタツや扇風機は、手段であって、
真の目的は「人間生活や社会活動に適した環境の提供」
にあるのだろう。

もし、コタツや扇風機の制御ソフトウェアの開発が目的であったとしても、
「人間生活や社会活動に適した環境の提供」という真の目的を見落としてしまったら、
適切な成果は期待できない。

>>476
レベルに会わせて分かりやすいように例えてるのが理解できないのですか。
なぜ煽るのか不思議です。

ええぇーっとさ、駄文書いてもいいんだけど、
誰も読めないよ、あの文章。

前から何度も言っている事だが、キミは作文能力が極めて劣悪だ。
キミの頭の中のコアダンプを他の人に渡して理解しろというのは無茶苦茶だ。

目的、問題定義、問題の解決方法(もしくは解決の方向)に分けて、
文章を書き直してごらん

なんかさ〜、もうちょっと分かりやすい話はないの？
わざわざ難しく言ってるようにしか見えないし。

スレタイで言えば、構造化と何が違うかってのは、
OOは言葉の洪水で意思疎通が難しそうで嫌になる、って感じになっちゃう

>>451
いいから、
目的、問題定義、問題解決の方法(もしくは解決の方向性)
をきちんと整理して書いてごらん。

>>480
　>>451は未整理の思いつきを書いただけだろう。
　文書内容を整理したら何も残らない、に100おっぱい

　　　　　　　　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　|　ちょ、ちょーとまって!!!今>>479が良いこと言った!
　　　　 , ,-;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:,.　　ヽ─ｙ──────────────　　 ,-v-、
　　　　/;:;:;:;:;:;:ミミ;:;:;:;:;:;:;:;:;:;`､　　　　　　　　　　　　　　　　　　　　　　　　　　/ _ﾉ_ﾉ:^)
　　　 /;:;:;:;:彡―ー-､_;:;:;:;:;:;:;:;|　　　　　　　　　　　　　　　　　　　　 　 　 　 / _ﾉ_ﾉ_ノ ／）
　　　 |;:;:;:ノ、　　　　　`､;;:;:;:;:;:i　　　　　　　　　　　　　　　　　　　　　　　　/　ﾉ ﾉノ／／
　　　 |;:/＿ヽ　,,,,,,,,,,　　|;:;:;:;:;:;!　　　　　　　　　　　　　　　　　　　　　 ____/　 ______　ノ
　　　　| ' ﾟ ''/ ┌｡-､　　|;:;:;:;:/　　　　　　　　　　　　　　 　 　 　 _.. r（" 　`ｰ"　、 ﾉ
　　　　|` ノ(　 ヽ 　ソ　 |ノ|/　　　　　　　　　　　　　　 _. -‐ '"´　　l　l-､　 　　ﾞ ノ
＿,-ー| /＿` ”'　　＼　 ノ　　 __　　　　　　 .　-‐ ' "´　　　　　　　 l　ヽ`ー''"ｰ'"
　|　:　 | ）ヾ三ﾆヽ　　 /ヽ ' "´／｀ﾞ ｰｧ' "´　　‐'"´　　　　　　　　　ヽ､`ｰ ／ノ
　ヽ　　`､＿＿＿,.-ー'　|　　 /　　　/　　　　　　　　　　　　　　　 __.. -'-'"
　　|　　　 |　＼　　　/　|　　 l　　　/　　　　　　　　　　　 .　-‐ '"´
　　＼　　 |＿__＞＜　/　ヽ

>>478
>>480
素直になれよ。今のままじゃ駄目だと思うよ。

>>483
>>451
いいから、
目的、問題定義、問題解決の方法(もしくは解決の方向性)
をきちんと整理して書いてごらん。

キミの現状は、他人の会話を無視して
ウンコを垂れ流して、それを他人に食えと言っている
赤ん坊と同じだ。
相手に理解を求めるなら、まずは言葉を変えて例を変えて、
説得を試みろ。

それができないなら、言葉をしゃべれない赤ん坊の叫び声と同じで、
第三者の理解など得る事はできない。これが現実というものだ

>>451＝ウンコたれ確定かな？

>>484
レベルが高すぎてすまんが、オブジェクト指向を理解するということは
こういうことなんだ。それが無理なら、やめておけ。

451ってそんなにヘンなこと書いてるか？
最終形態は決まってたとしても
途中経過がはっきりしてないとまずい、って書いてるだけじゃないの？

>>485
確定でしょ。
こいつが何か訳のわかんない事書き込んで、
それを他人に理解させようと努力してる姿など見たことない。

統合失調のキチガイだからしょうがないよ。放置。

>>451の名前はウンコ垂れに決定しました。

よくわからんが、>>484は何を必死になってんだ？

ウンコ垂れはスルーという事で。

お次の議題は
分析モデルに実装方法をねじ込もうとする
頭のおかしな似非コンサルの再教育だな

おまぃらもちつけ
ちょっと茶でも飲もうや

>>488
>>489
>>491
これがオブジェクト指向が普及しない実体だな。だめぽ。

>お次の議題は
>分析モデルに実装方法をねじ込もうとする
>頭のおかしな似非コンサルの再教育だな

レスで示すとどれかいな？

スレタイそのままだけど、
OO開発やってるところは構造化開発の場合と何が違うん？

1. 「オセロの石」が分析モデル上に存在するのは、全然支障がない。

2. 分析モデルに現れたオブジェクトは、必ずしも設計モデルに反映されるとは限らない。
　　設計モデルは実装方法を考慮するので、
　　実装方法の選択によって分析モデル上のオブジェクトが他のオブジェクト(ボード等)
　　に吸収される可能性がある。

3. 他方、オブジェクト指向の設計モデルは、
　　設計〜実装を行う人間にとっては扱いやすいモデルであるが、
　　計算機上の処理に適切な形をとるとは限らない。
　　従って、速度やメモリ効率を重視する思考ルーチンでは、
　　オブジェクト指向設計が採用されていない。

4. 結論
　　オセロの石を設計〜実装レベルのオブジェクトにしようが、ボード上の状態として扱おうが、
　　オセロゲームの価値(遊びやすさ、見栄え、思考ルーチンの強さ)には全然影響がない。
　　したがって、オセロの石をオブジェクトにしてもしなくても良い。
　　

これが >>496 頭のおかしな似非コンサルでしょうか？

4' 結論＋α
　　本来、分析モデルと設計モデルは全く異なるものだが、
　　もし可能なら、設計モデルを分析モデルと対応させておけば、
　　要求-分析-設計-実装-テストの見通しやトレーサビリティが向上する。

　　従って、分析モデルに現れた「オセロの石」を設計モデルにも採用するという選択は
　　極めて素直な選択と言える。

　　補足： 現実の開発では、設計モデルを分析モデルに合わせるだけではなく、
　　分析モデル自体を、実現可能な設計モデルに合わせてしまう事もよく行われる。
　　ただしこの立場をとった場合、分析モデルが現実の事象や要求とマッチしなくなる。

>>497＝ウンコ垂れの統合失調症患者

>>495
・オブジェクト指向による開発とは、クラスとポリモフィズムを駆使して
本人も含めて誰にも解読できない、また改修不可能なバグを持ったプロ
グラムが作れる。

・構造化による開発は、巨大関数群の集まりでプログラムを作りあげるが、
時間を掛ければ解読は可能であり、バグの改修もできる。

・また、本来デザパタは設計レベルで用いるものであるが、
デザパタ＝クラス設計レベルのノウハウ　という勘違い
のもと、クラス間の関連をパズル化しプログラムを解読
できないようにするのがオブジェクト指向による開発の
特徴である。

なかだし大好きなおっぱい星人が来たら起こしてくれ。
キチガイの相手はしない主義なんで

あのさー、
OOでの開発っていっつもこんなにモメルわけ？
で、モデル化するのにこんなに説明が必要なの？
こんなのに時間かけるわけ？
やっとれん・・・

>>502
モメてないねぇ。
なんか一人だけコタツだ扇風機だ言い出す変人が議論をかき回してただけでしょ。

>>501
中田氏おっぱい星人は
メッタ切りにされて戦意喪失している模様

>>496,498
ようやく納得できた

うゎ、ちょっと大変なことになってた。擁護してくれた人ありがとう。ちょっとじーんときた。
叩いてた人。確かに思いつきで書いたところもあることは否定しないが、一番言いたかったのは
前半の「抽象化と仮想化は違う」という部分なんだけど、勢いであまり纏めずに後半まで書いて
しまったのがまずかったかもと反省。冗長だった。そんだけ。

似非コンサルの物分りの悪さは異常

>>502
OOはさ、技術レベルの高低差が激しくてね。おちこぼれ（>>503）がすねるのよ。
それで時間が掛かるの。

>>506
ゴタクは判ったから、
ちゃんと文章を書き直してごらん。

目的、問題定義、問題解決に分けて

ゴタク言いは、自分でも何を言っているのかよく判っていないので、
文章の整理など絶対しないのは自明

ウンコの中にもトウモロコシや白滝が入っているよ
ウンコまみれだから食用には適さないけどｗ

ウンコ垂れにとっては、ウンコの中の未消化物も大切な栄養源なんだよ。

>>508
なに一人でブツブツ言ってんだよ池沼
自分のウンコを自分で食って、美味しいか？

OOの技術レベルに差があるのは、
単にOO開発が少ないので技術者が育ってないだけじゃないの？
実際活用されてるなんて話も聞いたことないし、
それ以上に、「OO開発経験者募集」って話聞いたことないし

なんだかどうしようもないGW厨房がいるな

>>514
おい糖質どうした？

GW中も家に篭りきりでキチガイが進行したようだな

もうﾄﾞｶﾀの話はこりごりだな

そろそろまともな人、こねぇかな

>>517
ここは議論スレではなく、糖質ヲチ＆糖質弄りスレだから、
まともな人はもう来ない。

今日一日このスレに張り付いてた奴が混じってるなw

しようがないなあ。
今日の迷言拾い集めて石碑でも作りますか

>>514
OOはさ、ソフトウェア工学の技術体系全体を理解する必要がある程難しい技術なんですよ。
センスがないと書籍だけでは習得は難しいでしょうね。ほとんどの香具師には無理かもしれません。
このスレなら、理解されているのは、>>451 さんだけのようです。
OO開発は多いですよ。仕上がりはダメダメですけどね。

石碑登録完了

>>519
ずばりキミだね
携帯でずっとヲチしてたけど、キミがずぅーっと一行こっきりの独り言を書いてたｗ

>>522
これはさすがにS氏の発言という事にはできないな。
あまりに支離滅裂でレベルが低すぎる。。。S氏のレベルの低さを考慮しても

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

>>525
理解が深い故、端的すぎて、一般には受け入れがたいのでしょうね。
みんな頑張って勉強しよう。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

>>521
ソフトウエア工学以前の話に思える
明らかに専門用語・単語のせいで意思疎通が困難になってるところがある
しかも人によって解釈が違ったりしてて
「OOとは？」という面での統一感がまるで無い

大雑把に言えばオブジェクト間でメッセージのやりとりするだけの話なのに
えらくややこしい学者さんの会話ばかりで辟易するって人がいても不思議じゃないなあ

>>527
エッセンスが濃すぎて、香具師が消化不良を起こしていますよ。
罪な人だ。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

>>415って、分析モデルの話？それとも設計モデルの話？
それとも脳内完結の妄想の話？

>>530
ゆっくり、噛んでごらん。消化できるかもしれないよ。
すぐに理解できなくても心配しないで。何度でも読み返せばいい。
まだ先は長いよ。チャンスはある。素直になって頑張れ。

>>531
イタイタしい奴だな
友達いなくて寂しいならこんなとこじゃなくて出会い系でも行ってくれや

OOの目的って何よ。俺はソフトウェア開発にとって重要なことは単純さと判り易さだと思うぜ。
難しい概念も凝ったテクニックも、結果的に生産性や保守性を上げないんだったら意味ないだろ。
それこそ、オナニーと一緒だ。ビットからテラの単位まで、12も桁が違う単位の世界を同じレベルで扱わ
なければならないんだ。まるでビー玉と地球を同じレベルで扱っているようなもんだ。こんな複雑なものを
扱うんだから、せめて、開発手法だけは単純にしてくれよ。
そのための手法がOOだというなら、多少の苦労はしてでも身につけるべきものだと思う。OOではダメだ
と言うなら、その代案を教えてくれ。

とにかく自作自演で「素晴らしい」などと空しい発言を繰り返すのはやめて、
素直に文章を書き直すのが一番だ。
キミの話は荒唐無稽で、現実との対応がついていない。

例えば仮想化という単語はどこからひねり出してきたのか？
そのレベルから説明をはじめてみなさい。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

>>536
暇なら勉強したら。時間がもったいないよ。

>>539
刺激が強すぎたようだ。壊れてる。ごめん。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

>>539の主治医です。
この度、このようなレスを539が立てるに至ったことは、
主治医として、大変残念な事であり、また、治療の効果が
まだまだ現れていないことを証明しているため、そろそろ
最終的な決断を下す必要があるようです。
みなさんお聞きになったことがあるかもしれませんが、
必ずしも心の病は、特殊な病気ではなく、誰もがそうなる
可能性があります。しかし、だからといって、これ以上、
>>539を放置することは、例えば何の関係もない人を傷つけたり、
逆に>>539自身の将来にとり、名から図示も良いことではありません。
そこで、私は、>>539の両親、臨床心理士などとも相談して、
>>539をしばらくの間、ネットの出来る環境から離して、
濃密な人間関係の中で治療をすることにしました。
>>539にとっては、納得がいかないことかもしれませんが、私も、
医師免許をかけて、>>539を徹底して直すことに致しました。
どうかみなさん！>>539が戻ってきましたら、このような人を悲しませる
スレではなく、みんなに感動を届ける以上の人間になっていると
思いますので、暖かく見守ってやってください。

>>415
判ったから同じ文章を何度もコピペせず、
言いたい事を要約しろ

俺はお前のクソレベルの質問にいちいち丁寧に答えてやっただろ？
お前は自分の発言を自画自賛する前に
きちんと内容を説明する義務がある。

それができないなら
お前は議論に寄与できない人間という事になる。
さっさとこの世から消えろ

ＧＷなのに一緒に外出する相手もいないとこんなんなっちゃうのか？
せいぜい2chで発散して、外で危害を加えるようなまねはやめとけよ。

>>544
こいつにはムリだろう。
毎回毎回同じことの繰り返しだ。
クソを自画自賛するだけのクズ野郎だって知ってるだろ

誰かｴﾛい人教えてくれ
このコピペ＋451に必死な奴は一体何を訴えてんだ？

>>543
GW中ずっと一人で寂しかったんだね？
よしよし

なんか、こういう連投な奴が銃乱射とかするんだろうな
本当にイタタマレナイよ

>>546
こいつハッタリじゃんｗ
ハッタリ相手に藻舞何やってんの

すず○たか○ろくんが銃乱射を予告したようです。
早速ですが通報しておきます。

>>549
ﾀｲｰﾎ

>>549
通報しますた

＞５４９
半島に帰れチョン

やれやれ
○ずき○かひろのスレはいつも荒れるな

逮捕祭り会場はこちらですか？

拳銃を持ったﾁｮｿが立てこもっているのはこのスレですね？

自演があからさますぎて痛いよ。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

で、スレタイの話はどこに行ったんかな？

ﾌｧﾋﾞｮｰﾝｷﾀ━━━━('A`) ━━━━ｱﾆｮﾊｾﾖ

オブジェクト指向とか知らない俺には、ここは最高の隔離スレ。

どうしようもない559が一人で頑張ってるみたいだが、
あんまり人に迷惑かけない生き方しないと駄目だぞ。

>>560
抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

>>564
わかったわかった

ちょっとほっといてあげた方がいいかも。そのうち寝るでしょ。

>>563
仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
マシン、仮想キーボードといったものだ。
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

>>566
仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。

では、まともな方々は一時おやすみなさい、ということで。

>>569
おやすみ。
人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易いｗｗｗ

>>570
おやすみなさい。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ(w

>人がイメージしたものは、その生成から、破棄に至る
>まで、非常に不安定な状態になり易い

オブジェクト指向の留意点を端的に表してるね。わかるかな。

ハッタリの野郎、とうとう最後まで自分の悪文を直さなかったな。
ハッタリが周囲に嫌われているのは、
ハッタリが難しいことを言うからではなく、
ハッタリの日本語がおかしいからだって早く気付けよ

>コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
>ことはできないのだ

香具師にも理解できるよね。でもちょっと難しいかな。

>>572
人間の思考(イメージ)は、オブジェクトとは異なり
単純な生成や単純な破棄などなされません。
キミの頭は狂っています。

糖質は今晩は何時に寝るの？

いつもみたく朝の４時５時まで張り付いてたら、
無職童貞がバレバレになるよ？

> コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
> ことはできないのだ

糖質の思考は醜いなぁ
扇風機やコタツを抽象化？
寝言は寝て言え

>>575
コンテキストから理解しなきゃだめよ。

>>577
やばいよ。理解できないんだ。この先どうするの？

>>577
何が目的で、このすれに来てるの？
不思議ちゃん。

無職童貞ちゃん徹夜乙

はやく就業経験くらい作っとけよ
あと女性経験もｗ

>>581
ＧＷだし大丈夫だよ。お気遣いありがと。

だから自分自身で意味を咀嚼できてもない言葉を
無闇に使おうとするから451みたいになるんだよね。

オブジェクト指向と抽象化になんの関係があるのかサッパリわからん。

なんとなく、構造化プログラミングで「手続き抽象」とかいうときの意味で
抽象化といっているような気はするんだが。。

そういう意味で抽象化と言っているのなら、確かにオブジェクト指向は
抽象化の一種ではある。

もっとも、あの構造化プログラミングでブラックボックス化のことを
「手続き抽象」とよぶ用語法って個人的にはあまり適切でない気がするけどね。

仮想化って概念はどっから引っ張ってきたんでしょうね？

>>583
ありゃりゃ。釣り？
マジなら地動説と初遭遇かな。

>>584
オブジェクト指向における熟練者の指向方法のひとつです。

１は国語がはっきりいってまともにできないタイプ。
文系でも理系でも１のような痛いタイプと同じ空気を吸いたくないわなｗｗｗｗｗｗ
専門版は基地外の集まりだなｗｗｗｗｗｗｗｗｗｗｗｗｗ仲良くしなよ＞＜

なにこのクソスレ

この道は厳しい。みんな逃げずに頑張れ。一番を目指すんだ！

上流アーキテクトの考えかたを理解するのは、容易なことではない。
それはどの世界でも同じこと。
ふてくされたり、いじけたりしたらそこで終わりだ。
素直になって、話を聴くこと。わかるか。

ウンコ垂れは、自分の話を聞いてくれる人を探すのに必死。
まずは他人の話に耳を傾けようね。

>>590
あら？鈴木高弘発言によると
「２１世紀に入ってアーキテクチャの進歩は終わったから
アーキテクトは業務システムをやる必要がある」
だったはずなんだけどなあ。
鈴木高弘はアーキテクト・コンプレックスだったのか。
バッカみてぇ

そいつがバカなのは豆蔵社内でも有名。
口先でグダグダ言うだけで実行力がない。
経営上の意思決定の足かせになったから
豆蔵を追い出されたのは公知の事実。

>>591
>>592
楽しい香具師だな。学生さん？ならいいけど。
お勤めならご愁傷さま。

アドレナリンの血圧が上昇した模様
もう一押しで脳味噌プッツンかなｗｗｗ

ここって、いつきても煽りや叩きやってる人（１人かな）がいるのな。
ま、煽るのは気持ちいいんだろうけどさ、煽らずにはいられないって性格は
どうにかした方がいいと思うよ。もうちょっと我慢して大人になろうよ。
掲示板だけでやってる分には、それほど迷惑かけない（充分迷惑なんだけど）
からいいけど、実社会と区別つかなくなって失敗してから後悔しても遅いよ。
本当に。外にも楽しいこといっぱいあるんだからさ。外出ようぜ。

http://ascii24.com/news/i/mrkt/article/2001/10/12/630366-000.html
2001年10月11日、役員人事の一新を発表した。(中略)
前社長は取締役会において「一技術者に戻りたい」として退任を表明(中略)。
役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

オブジェクト指向というのは、Ｈｏｗではなく、Ｗｈａｔなのです。
人に教えられるものではなく、自分で考えて見つけるものなのです。
だから難しい。オブジェクト指向。

1. 「オセロの石」が分析モデル上に存在するのは、全然支障がない。

2. 分析モデルに現れたオブジェクトは、必ずしも設計モデルに反映されるとは限らない。
　　設計モデルは実装方法を考慮するので、
　　実装方法の選択によって分析モデル上のオブジェクトが他のオブジェクト(ボード等)
　　に吸収される可能性がある。

3. 他方、オブジェクト指向の設計モデルは、
　　設計〜実装を行う人間にとっては扱いやすいモデルであるが、
　　計算機上の処理に適切な形をとるとは限らない。
　　従って、速度やメモリ効率を重視する思考ルーチンでは、
　　オブジェクト指向設計が採用されていない。

4. 結論
　　オセロの石を設計〜実装レベルのオブジェクトにしようが、ボード上の状態として扱おうが、
　　オセロゲームの価値(遊びやすさ、見栄え、思考ルーチンの強さ)には全然影響がない。
　　したがって、オセロの石をオブジェクトにしてもしなくても良い。
　　
4' 結論＋α
　　本来、分析モデルと設計モデルは全く異なるものだが、
　　もし可能なら、設計モデルを分析モデルと対応させておけば、
　　要求-分析-設計-実装-テストの見通しやトレーサビリティが向上する。

　　従って、分析モデルに現れた「オセロの石」を設計モデルにも採用するという選択は
　　極めて素直な選択と言える。

　　補足： 現実の開発では、設計モデルを分析モデルに合わせるだけではなく、
　　分析モデル自体を、実現可能な設計モデルに合わせてしまう事もよく行われる。
　　ただしこの立場をとった場合、分析モデルが現実の事象や要求とマッチしなくなる。

オブジェクト指向というのは、アンプのようなものです。
入力信号となる設計センスを増幅して出力します。
優劣の差が目に見えて分かるわけです。

実際問題として、世の中の大多数のシミュレーション、思考ルーチン等は
オブジェクト指向などという中途半端なモデリング手法は用いず、
より厳密なモデル＝数学的モデルを直接実装している。

オブジェクト指向などというものは、
厳密な数学的モデルの成り立たない領域のモデル化や実装で
間に合わせとして役に立てばいい、その程度のものなのである。

>>601
グローバル変数＋巨大関数群＝プログラムな方ですか？

いや、「その程度のもの」であるにも係わらず、
まともなモデリングそのものが実施不可能
であるという
現状認識を踏まえて話をするべきではないのか。

それでは、厳密な数学的モデルが成り立たない領域とは、どのような領域か。

例えば、企業活動、コミュニケーション、等々。
これらの領域は、詳しくデータをとれば何らかの統計的性質を発見でき、
その統計的偏りに基づいて、何らかのビジネスを起こせるかもしれない。
しかし、企業活動やコミュニケーションの本質、基本モデルは
決して数学的モデルで記述しつくす事はできない。
従ってこれらの領域では、数学的には曖昧な事象をモデリングする手段が必要となる。

あるいは、システム工学の対象となるような、非常に多数の構成要素を持つ製品
-- 例えば電子機器、化学プラント、自動車/船舶/航空機 等々。
これらの場合個々の構成要素は、理学的/工学的な裏づけを持ち、
近似的な数値モデルを使って製造する事ができる。
しかし最終的な製品は、複数の構成要素が深い階層構造を持って組み合わさって構成されており、
その複雑な組み合わせ全体に関する数学的モデル、というものを求めるのは非常に難しい。

そもそも構成要素が非常に多いので、
取り得る組み合わせの数自体天文学的な数である。
取り得る全ての組み合わせの中から
最適な組み合わせを探す事すら難しい。
こういった分野で使える数学的道具は、せいぜい統計くらいである。
そして、そのような場面で必要なのが、
膨大な組み合わせの中から、最適解に近い解を見出す「センス」である。

オブジェクト指向など関係ない。センスが重要なのである。

>>604
わけわかりません

スレタイ「ｵﾌﾞｼﾞｪｸﾄ指向開発は構造化開発と何が違うの？」

何が違うか、といえば、
再生産性があると信じられながら
多くの場合は裏切られてる現実が増えた、ってことかな？

> いや、「その程度のもの」であるにも係わらず、
> まともなモデリングそのものが実施不可能

それは貴方に業務分析や生産技術のスキルや実績がないため
そのレベルの話に参加させてもらえないとか、
あるいは貴方の分野でモデリングの重要性が認められていない、
というレベルの話ではありませんか。

ある分野でモデリングを実施不可能なら、
　　・モデリングをあきらめるか、
　　・その分野から立ち去るか、
　　・モデリングを実施可能な状態にするか、
どうぞお好きになさって下さい。

いったいなにを作ろうとしてんだか。コンピュータで宇宙でも作る気か？
んなもん誰が必要とすんだよ。賢い人の考えることはよくわからん。

難しく言わずに、
OOはプログラミングとは直接的には関係がない、
って書けば済む話じゃないの？

> 再生産性があると信じられながら

> 再生産性があると信じられながら

> 再生産性があると信じられながら

> 再生産性があると信じられながら

> 再生産性があると信じられながら

> 再生産性があると信じられながら

> 再生産性があると信じられながら

> 再生産性があると信じられながら

> 再生産性があると信じられながら

いみふめ
レベルの低い釣り人と見なしてよろしいですね。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

役員を3人に絞ったのは、迅速な経営判断を行なうためだという。

>>611
今は役員が８人も居るよ。

あ〜あ、
また昨日の悲惨な奴がきちゃったよ

昼夜逆転の社会落伍者なんだよ。
かわいそうな奴なんだ。
ほっといてやれ。

↑社会的落伍者 (就業経験０、女性経験０)

>>612
４人目がNGって事でわ・・・（ｗ

「まだその域に達していない、」ってこと

４人目は(能力的に)まだその域に達していなかった
にも関わらず役員となったが、
その職務に必須な迅速な経営判断を下せず
居たたまれなくなって逃げ出した。

なるほど。

>>604
そうです。そのセンスを増幅させるアンプがオブジェクト指向なのです。

その後４人目はあちこちを転々としたが、
結局のところ、居場所を見つけることはできなかった。
４人目の心はすっかり荒み、顔は髭だらけになり、
目は狂った光を帯びるようになった。
連日連夜匿名掲示板に出没してはスレを荒し
日ごろの鬱憤を晴らすだけの生活になっていた。

そうして６年目の春を迎えようとする矢先、
４人目の罵詈雑言に耐えかねた善良な住人がついに立ち上がった。

「お前は狂っている。出て行け。人間としてNGだ」

４人目は涙ながらにこう答えた。
　　「(お、おれは) まだその域(NG)には達していない、・・・」

>>620
それも違うよ。

ニュートンは物理現象を数学という道具をつかって説明しようとした。（数学指向、だな）
数学指向を選択することが、問題解決に必要とされる数学的知見（の組み合わせ）を
見極める能力をブーストするだろうか？
んなわきゃあない。

プログラマは仮想機械による分割統治でアプリケーションを設計しようとする。
（仮想機械 = オブジェクト、つまりオブジェクト指向）
オブジェクト指向を選択することが、アプリケーションに必要とされる仮想機械（の組み合わせ）
を見極める能力をブーストするだろうか？

>>620
だから電子工学の世界ではブロック図を使うっていってるだろw
電子工学の世界のブロック図のアイデアをプログラミングの世界に輸入すると
OOPになるの。わかる？

UMLになるのでは？

エレクトリックお花畑

>>622
オブジェクト指向につて勘違いされているようですね。

仮想機械（笑）

>>622
やっぱり、グローバル変数＋巨大関数群＝プログラムな方ですね。
あなたさまには構造化設計を強くお勧めします。

俺様定義で話をでっちあげて、
自作自演で一行レスつけまくるから
お前はいつまでたっても童貞なんだ

ガキ臭いオナニーして気持ちいいか

ウンコ垂れカプサイシンくんの自作自演が
鼻が曲がりそうなほど臭いので放置

>>622
仮にあなたのいう仮想機械 = オブジェクトだとして、その仮想機械をあなたは
どのようにして抽出されるのですか？

カプサイシンの自問自答はいつまでたっても話が進まない

ｱﾄﾞﾚﾅﾘﾝがｵﾊﾟｲﾊﾟﾌﾞを奢ってくれるそうだ

仮想機械なんて俺には抽出できないよ。

カプセル化ってどっちが正しいんだろう？
１．「外に見せる必要の無いものを隠蔽する」
２．「外に見せないといけないものだけを外に見せる」

仮想機械をググってもバーチャルマシンの説明しか出てこないんですが・・・
VM=オブジェクトってこと？

>>635
そうです。プログラムは、仮想機械の組合せなのです。

>>634
２．ですね。

>>635
プログラムを一つの仮想機械だけで構成すれば、仮想機械の抽出は不要です。
この技法を「センス」と呼びます。

仮想メカニズム
という表現なら少しは理解できる人が増えるかな？
どっちにしろこの種の比喩はもう単語が使い尽くされているから
適切な言葉を捜すのは難しいね

仮想メカニズムは、関数から構成されます。関数も仮想メカニズムの一つです。
構造化設計により、仮想メカニズムの抽出は比較的簡単に行えます。

この混乱させようとしてる空気は何なの？
>>639
自分のブログにでも書いたらどう？
オレ様用語なんか見たくもないし

この内容>>604って、ソフトウェア設計が難しいことを、滅茶苦茶遠回しにしたうえ、
俺様解釈を加えて複雑にして述べてるだけじゃないの。
全く無意味な内容だな。

>「荒らし」ってなに？ △　▽　　▲　▼
>
>スレッドを乱立させたり、長文や意味を持たない文字列やアスキーアートなどをコピー＆ペーストしたり、削除対象になるものを書き込んだり、掲示板の使い勝手を悪くしてしまう行為一般の総称です。
>個人の誹謗中傷、度の過ぎた差別発言、むやみに不必要なスレッドを上げること、執拗な煽りや叩き、なども荒らしとみなされる場合があります。
>平たく言えば、他人に迷惑が掛かる書きこみはアウトってことです。。。
>
>荒らし行為に遭遇した場合は、諌めたり挑発したりなど、むやみに対抗しないようにお願いします。特に荒らしを煽るのは逆効果です。
>荒らしに反応したらあなたも荒らしかも。。。

なんか今日は特別レベルが低かったね。寝ようかな。

おかしな算数屋さんだけだったね。ＧＷだからかな。

>>642
お前はまともな会話が通じない
低レベルな知能の持ち主である事を再確認した。
　　　　　　　　　　　　　　　　　　　　　　　以上終了

>>646
ごめん。直球すぎた？
分かりやすくてごめんね。

結論
数学モデルや論理モデルの厳密さと比較して、
オブジェクト指向モデルはとても曖昧でいい加減なものだ。
もし数学や論理で記述できる対象ならば、
数学や論理を使うのがベストである。

しかし、全ての対象を数学や論理で記述できるとは限らない。
あるいは記述自体は可能であっても、その厳密さ故に
記述に莫大なコストがかかる場合もありえる。
そのような場合には、しょうがないから安っちくてボロっちいい
オブジェクト指向モデルを採用してあげてもいいかもね。
まあ信頼性はグッと下がるけど

はい。わかりました。

>>648
もうなんでもいいよ
プログラマーが結局やるんだし

やっぱり機能に着目する、構造化設計が一番ってことかぁ？
数学モデルや論理モデルにも相性いいだろう。

この子、小学生か中学生くらいかな。
反応がとても幼いので、レスを付けるのがダルい

まるっきり知識のない空っぽな人を相手にしているような気分だ。
これ、もしかして統合失調症クオリティじゃねぇ？

>>653
たぶん当たり

>>648
だから自分で咀嚼できてもいない言葉無理して使うなって。
恥ずかしい奴だな

オブジェクト指向モデルっていったいなんだよw

○○という道具を用いて何かを説明する方法を○○モデルという。
（例. 数学モデル、OSI参照モデル）

その「オブジェクト指向モデル」とやらは、オブジェクト指向つかって何を説明するんだよw

ネタで書くならもっと人を笑わせるか、そうでなければ人を唸らせるような
ウィットに富んだこと書けよ。

お前さんのそれは面白くもなければ、何の理知も感じないよ。

>>653
キミの読みは当たったようだ。
こいつは何も知らずに議論の真似事をしているだけのキチガイだ

>>655
さっさと薬のんで寝れ

>>657
算数屋だけど、ソフトウェアは難しかったですか？

OOの検定とかあれば
何が正しいのかはっきりするし
レベル差もわかるのになあ
少なくともJavaやってれるのでOO分かってます、みたいな奴は減る

統合失調だかなんだか知らないが、
プログラマの視点なら、コード面から、
コンチャンの視点なら、会計処理の業務自体の忠実な再現、
それでeじゃねーか
どこぞで原点の話をした覚えあるが、システムてのは、業務のｺﾝﾋﾟｭｰﾀ処理化、業務をｺﾝﾋﾟｭｰﾀに移植したところから始まったんだろう。
往々にしてカタカナ言葉というのは曖昧、いや誤魔化すための手段か。
仕事で使うなら、背伸びしないでできる方法でさ。
まずは、一つ一つATOMICを意識して業務の順序どおりに忠実に再現するとこから始めりゃ。
そこからオブジェクトがでてくればいいわけで。
いきなり難しい本読んでも全くワケワカメで身につかず、７〜８割方ある程度分かっている本を読んでいくのが深く身につくという同じように、
いきなりオブジェクトどーだこーだ言っても始まらんだろう。

コンチャンってなんですか？
ATOMICってなんですか？
何を言いたいんですか？

オロナミンCのホーロー看板の人

目的がわからんが、とにかくこの板で自分探しの旅をするのはやめてくれ。
世間にでてがんばれば、人も自然と自分のこと認めてくれるからさ、な。

　　　　　　　　注意：　現在このスレには統合失調症患者が出没しています。

　　　　　　　　　　　　　統合失調症とは、自己と他人との境界を正常に認識できなくなる病気です。

　　　　　　　　　　　　　統合失調症患者との議論は、あなたの精神の平衡を崩す可能性があります。




　　　　　　　　　　　　　

　　　　　　　　　　　　　

　　　　　　　　　　　　　

　　　　　　　　　　　　　
　　　　　　　　　　　　　

　　　　　　　　　　　　　

　　　　　　　　　　　　　
　　　　　　　　　　　　　
　　　　　　　　　　　　　

　

>>664
わるいけど君も件の彼と同じ程度には病気だと思うぞ
いや、それどころかもっと悪い。

件の彼は君ほど幼稚じゃあないからな

　　　　　　　　注意：　現在このスレには統合失調症患者が出没しています。

　　　　　　　　　　　　　統合失調症とは、自己と他人との境界を正常に認識できなくなる病気です。

　　　　　　　　　　　　　統合失調症患者との議論は、あなたの精神の平衡を崩す可能性があります。

人に話す前に何事も自分で文章にしてみるというのは大事とよくいうが、かく言う自分はまとめるのは苦手なほうだがこれはおいておいて、自分の文章に書き直すと、↓です。
ACID属性
A Atomicity (原子性)
すべてが完全に実行されるか、処理が完結しない場合には元の状態に戻る
＞やってみてわかること第一段階、デッドロック＞タイムアウトを待って鯖を固まらせるな、waitforgraph(待ち合わせ表)を用いて或いはjoinしてデッドロック能動的or事前に制御。
しかし、運用時SQL直利用等で決して崩されてはならない。
C Consistency (一貫性)
処理の順番に関わらず結果が同じになる
＞やってみて分かること第一段階、最初から処理の順番決めておく。
I Isolation (独立性)
他のトランザクションの影響を受けない
＞やってみて分かること第一段階、むやみにマルチスレッドを作って毛玉を作って、デッドロックさせるな、最初はシングル、キュー・メッセージ(直列化シリアライズ化)処理で。
D Durability (耐久性)
いったんトランザクションが完結したら障害が発生してもデータの状態が変化しない
＞やってみて分かること第一段階、２フェーズコミットよりむしろ、オブジェクトを自分のタモトに持ってくるRPCで。

　　　　【注意と警告】現在このスレには統合失調症患者が出没しています。

　　　　　　　　　　　統合失調症とは、自己と他者との境界を正常に認識できなくなる病気です。

　　　　　　　　　　　統合失調症患者は、自己の発言と他者の発言を混同したり、

　　　　　　　　　　　自分自身と同様な病状を他者も抱えているに違いないという妄想をもって、

　　　　　　　　　　　あなたの精神の平衡を崩す可能性があります。ご注意下さい。

学会レベルの議論と実務のギャップに耐えられなくなって、人格崩壊を起こしかけてるな。
統合失調症の好発年齢は30±3歳に集中してるから、ピッタリはまっちゃったんだろう。
メジャートランキライザーを服用すればブッ飛んだ論理展開はしなくなると思うが、元職に
戻るのはかなり困難と思われ。
とりあえずリアルでも扱いようがなくなるので、周囲の人間に対応してもらうまでスルーする
しかなさそうだ。

カプセル化ってさ、別にOOだけの話じゃないよね
DLLとかでも外部に公開しなければ同じだし

結局構造化とOOの違いがよーわからん

なんだ糖質のおっさん３０±３歳なのか
幼いと思ったらやっぱり雛っ子か





　　　　【注意と警告】現在このスレには統合失調症患者が出没しています。

　　　　　　　　　　　統合失調症とは、自己と他者の境界を正常に認識できなくなる病気です。

　　　　　　　　　　　統合失調症患者の典型的な病状は以下の通りです。

　　　　　　　　　　　1. 他者の発言と自己の発言の区別がつかなくなる

　　　　　　　　　　　2. 自己の考えを、言葉にしなくても、相手は理解できるものと思い込む

　　　　　　　　　　　3. 他者も、自分と同じ病気にかかっていると思い込む

　　　　　　　　　　　統合失調症患者との議論は、あなたの精神の平衡を崩す危険性があります。
　　　　　　　　　　　ご注意下さい。

>>670
それはOOよりもむしろ「構造化」っていう言葉が何を指しているのか、
実体が曖昧だからかもしれないね。

宗教社会学的には、空疎であいまいなものほど人はありがたがるらしいが
（キリスト教の最後の審判の後の神の国みたいに）、構造化という言葉も
この類かもしれんな。

>>667の書き込みオモロ過ぎ。

石碑化して永久保存＆ワールドワイド公開決定！
(プロジェクト名もほぼ確定！)

ただし発言者がいかにも雑魚っぽい。
弱い者いじめは可哀想だし、
しばらくペンディングしとくか

>>672
バカタレ

構造化ってサブ関数にばらしていくだけを定義してるんだっけ？
なんか、構造化ってのはプログラミングの手法で、
OOってのはプログラミングは関係ないように思えるんだけど

>>672
ググって最初に出てくる構造化プログラミングのページ。
構造化の語源がどこにあるのか、自分で確認しろ。
このページには５種類の「構造」が示されている。

>>672
ＵＲＬ書き忘れ orz

構造化プログラミング
ttp://www2.cc.niigata-u.ac.jp/~takeuchi/tbasic/Intro2Basic/Structure.html

>>673
最近は軽薄短小がはやりなようだが、
逆に、J2EEも準本格的データベースも誰でも試せる時代でもあって。
何が言いたいかというと、第一段階と書いたように、
本だけで分かったつもりにならずに、やってみれば誰でも最初にぶち当たることだろう。
ACID属性？トランザクション考えるとそうだね、ウンウンで済ますとこだが、実際自分も済ましたが、
データベースやサーバサイドの機能におんぶに抱っこしないとすると、言い換えると、少しでもカスタマイズしようとするとかなり厳しい部分だと実感したけどな。
やってみりゃあたりまえで、あたりまえのことしか書かずに済まんが、
あたりまえのこともやらずに分かったつもりの危うさが軽薄短小時代

発言者特定完了
石碑化決定

>>676
そんな大学の教養のテキストに出てくるような大元の定義は知ってるってw
「構造化」っていう言葉の現実の使われ方のことを言ってるんだよ。
ものすごく曖昧に使われてるでしょ。

たとえば>>670が書いているみたいにカプセル化とか、本来構造化と関係ないことまで
構造化の概念みたいな扱いになってることが多いし。

かつ、あたかも画期的発想であるかのような大業な扱いを受けていることが多い。
本当は構造化なんて中身空っぽなのに。

過去の人気名言

マルチスレッドロジックにマルチスレッドロジックが重なるアミダのトグロw
マルチスレッド・プログラミングは超絶難しい
　　　　　　　　　　　　　　　　　　　　　　　　　　　(業務コンサルタント)


データベースがリレーショナルモデルで排他制御するからなー。
ORマッピングで破綻しちゃうー。
　　　　　　　　　　　　　　　　　　　　　　　　　　　(業務コンサルタント)


俺は、会計とか金融とかのシステムを作りたいということが目的で、
それ以外のことに時間を割いてる余裕なんてないんだ。

内部の調査は、それに興味のある人間がするべきだ。
こちらが必要としている のは、正しく動くコードだということ。
　　　　　　　　　　　　　　　　　　　　　　　　　　　(業務コンサルタント)

>>680
バカタレ
60年代はそれがソフトウェア工学上の重要な概念だったんだよ
お前は本当に底の浅い人間だな

> カプセル化

それは構造化プログラミング・ページの５番目の構造だろバーカ

迷言連発で石碑を彫るのが追いつかないぞ

あのさ、個人名書いてるけど訴えられたらどうすんの？
マジで。

あのさ、匿名で何年間も業界関係者の実名出して叩きやってるバカが居るんだけど、
そいつはどうよ？

人がやってるから自分もやっていいってことにはならんだろ

どうって、普通に訴えられるだろ。意味不明。

匿名掲示板上とはいえ、業界関係者何人実名挙げて叩いてたっけ？
・元居た会社はほとんど全部叩いてるだろ、
・元居た会社で火消しやった連中を、繰り返し戦犯のように叩いてるだろ、
・プログラム関係の翻訳者や著作者は、親の敵にでも会ったような勢いで罵倒しまくりだろ。
ぜんぶばれてるんだよキミ

>>682
なんか人の言葉には聞く耳もたないタイプの人間に見えるが一応書く。

構造化の功績っていうのは命名的・編纂的な功績であって発明・発見的な
功績ではないんだよ。
デザインパターンと一緒さ。

暗黙的に広く知られている知識に名前を与えて整理した功績に過ぎない。
それも誰でも思いつくようなことを、だ。

実際中身ないでしょ？
だから必要以上にありがたがられて、その意味する範囲があいまいに拡大していく。

違う、っていうなら「構造化」という言葉がさしているコンセプトを
簡潔に表現できる？

大元の定義じゃなくて、構造化という言葉の現実の使われ方についてだよ。

関数型言語コミュニティの一件は傑作だったな。
誰かが警告文を流したら、
別の誰かが個人特定情報持ってきて、身元バレバレ。

お陰で俺もここ何年か悩まされていた荒しの正体がやっと判ったよ。

>>680
> >>676
> そんな大学の教養のテキストに出てくるような大元の定義は知ってるってw
> 「構造化」っていう言葉の現実の使われ方のことを言ってるんだよ。
> ものすごく曖昧に使われてるでしょ。
>
> たとえば>>670が書いているみたいにカプセル化とか、本来構造化と関係ないことまで
> 構造化の概念みたいな扱いになってることが多いし。
>
> かつ、あたかも画期的発想であるかのような大業な扱いを受けていることが多い。
> 本当は構造化なんて中身空っぽなのに。

> カプセル化

それは構造化プログラミング・ページの５番目の構造だろバーカ
日本語の文章もちゃんと読めないのかバーカ

>>689
なんかおまぃ激しい奴だな
その個人が誰だか知らんが、おまぃは関係者か？
会社がどうだとか、このスレに関係ないだろ
茶でも飲んでちょっともちつけ

>>690

てめぇのために赤ちゃん言葉で構造化プログラミング説明するほど
物好きじゃねぇんだよバーカ

↓のＵＲＬ読んで、自分で考えろバーカ
構造化プログラミング
ttp://www2.cc.niigata-u.ac.jp/~takeuchi/tbasic/Intro2Basic/Structure.html

どうしてこう、このスレは喧嘩腰な奴が多いんだ？
知識レベルの差ぐらいお互い認めりゃー済む話じゃねーの？
なんでバカバカ言い合ってんだよ・・・

【注意と警告】現在このスレには統合失調症患者が出没しています。

　　　　　　　　統合失調症とは、自己と他者の境界を正常に認識できなくなる病気です。

　　　　　　　　統合失調症患者の典型的な症状は以下の通りです。

　　　　　　　　　　1. 他者の発言と自己の発言の区別がつかなくなる

　　　　　　　　　　2. 自己の考えを言葉にして相手に伝えなくても、相手は理解できるものと思い込む

　　　　　　　　　　3. 他者も自分と同じ病気にかかっていると信じ込む

　　　　　　　　統合失調症患者との議論は、あなたの精神の平衡を崩す危険性があります。

　　　　　　　　ご注意下さい。

まだやってんのかよｗ
版画ちゃん、いったいなにがそんなに面白いのか
おれにも教えてよｗ

電圧の高低でオン・オフを表現しようとした発想も、ビットの並びをニーモニックに割り当てたアイデアも、
データとプログラムを同一視した着眼点も、その処理を集積化した技術も、プログラム言語を人間の言語
に近い表現に発展させた知識も、全て先人達が試行錯誤しながら成し得、現在へと築き上げてきたものだ。
我々は、記録として残された現実味の伴わない手がかりを頼りに僅かばかりの実践を経た若造の分際で、
ロープウェイに乗せられていきなり山頂へ連れてこられたものだから、眼下に聳える名も知らぬ山々と、足
元に転がる朽ち果てた躯を眺めながら、まるで摩利支天に抱かれたかのごとき恍惚の表情で呆けている
愚か者であることを、せめて頭の隅にでも留めておかなければならない。我々が偉そうに立つこの場所は
常に最先端だが、その様子は氷山の一角で戯れるペンギンにも似ている。海中へ潜ってみて初めて知る
世界があることを知るべきだ。

普通に努力を積み重ねてきた人間は、
いい歳こいてそんな戯言は言わない。

過去の巨人と己の能力の相違を自覚しつつ、
過去の巨人の歩んだ後をまがりなりにもなぞり、
そして過去の巨人の肩の上で、
自分にできる精一杯の仕事をしようとする。

判らない事があれば、
まずは巨人の歩みを確認し、自分の理解に飛躍がないか確認し、
その上で、ああ、ここは巨人が来ていない道なのかもしれない
と時には思う。そして自分で道を開いて進んでいくと、
その先には先人の足跡が残っている。

技術者の人生とはそんなものだ。

>>698=699
スレタイと無関係

>>700
構造化とＯＯの間に存在する
・技術的連続性　と
・プログラミング・パラダイムの変化
に関する話だ。
判らないなら黙ってろ。

構造化みたいなの（OOPだってそうだが）を「技術」と呼ぶのは
むしろ工学の他分野の技術に対する冒涜だと俺は思うぞ。

そんなこといってるから情報工学ってのは三流工学扱いだったんだよな。

レベルの低い住人がよりレベルの低い対象を見つけて叩こうとするスレ

>>698-699

同意。
巨人の肩の上で作業している人は
自分が巨人よりも優れた存在だと勘違いしがちだ

>>740
またそういう、半端な奴が訳知り顔で得意げにいいそうなセリフを。
よくそういうこと恥ずかしげもなくいえるよまったくw

違う違うお前さんや>>699は真に偉大な発見発明とチープなものを
見分ける能力がないだけだって。

【注意と警告】現在このスレには統合失調症患者が出没しています。 （ｒｙ

>>740
しつこい

そんなに書いたら>>740には怖くて誰も書き込めなくなるじゃないか。

>>740はあれだな、真に偉大な発見発明とチープなものを
見分けられないんだな。もちっと勉強しろw

ぜひ>740はおじゃばに取ってもらいたいなｗ

やはり全般としてこのスレには技術的な視点や合理的な判断が欠落している．
方向性は間違ってないにせよ，やはり素人がない知恵を必死に絞って，
適当な話をでっち上げてるようにしか見えないな．
旧態依然の老人どもに都合の良い部分だけを切り出して，
わざと誤解を与えるように構成している．
そういう意味ではかなり悪質なスレと思える．

オブジェクト指向論なんてそんな難しいもんじゃないんだよ。
言葉や習慣と同じで、長年やってれば自然と身につくもの。
ただ人によって手法や流儀が少し異なる場合があるから、誤解
が生じ易いが、肝心なことは１点だけだ。シンプルなものは
シンプルに、複雑なことはなるべくシンプルにするように心
がければいいのさ。自分にとって分かり易いことは、少なく
とも自分にとって分かり難いことよりも受け入れられるはず
だから。それさえ心がけていれば、テクニカルなノウハウは
自然と身についてくるさ。

>>711
自分の批判を自分自身に向けられないのかな？w
一文の価値もない愚痴はいいから、君自身のOOPに関する見解を述べたら？

それが無理なら（まあ無理なんでしょうがw）せめて他人が書いてることに
具体的に反論しろよ。

>>712
OOが難しくないのはその通りだと思うが、しかしロクに理解してもない君が
それを言うのはどうなの？
複雑なことはなるべくシンプルにするように心がければいいのさ、って何だよw

何も言ってないの同じじゃんそんなの。

逆説的だが「志を語る奴に，本当に志のある奴はいない」と言って良いと思う．

もし本気で志を持っていれば，それを人に語るよりも先に，努力し行動する．「技術力が欲しい」と思えば，大学に進んだり，専門書を自腹切って買ったり，人のソースコードを読んだり，セミナーや勉強会に参加したりする．
「英語をものにしたい」と思えば，単語を覚えたり，ペーパーバックを読みあさったり，podcastを聞いてみたり，留学したりする．技術力や英語力は志の結果だ．

逆に，行動の伴わない口先だけの「志」とは本物の志と呼べるだろうか．また結果の伴わない「志」に，一体どれほどの価値があるだろうか．努力もせずに「志」を語るだけなら誰にだってできるのだ．

意味不明なこと書いてスカしたつもりになっても、
最終的には自己イメージが傷つくだけだと思うけど。

いくら目を背けているつもりでいても、
まともなことが書けないからおふざけに「逃げてる」頭の悪い自分、という
自己評価はついて回るからな。

まあ最初から傷つくような自己イメージなんて持ってないかもしれないがなw

そもそも科学的な観点から考えても、人生の責任を「意識」に求めるなど迷信のような発想だとされる。
自分の「思考」を過大評価し、かなりの部分まで現実に影響を及ぼすことができると考えるのは、
幼児特有の発想で「魔術的思考」と呼ばれるものだ。
幼児にとっては現実と妄想の区別がそれほど明確ではないので、
何でも頭の中の思考によって可能だと考えてしまうのである。

思考可能な「意識」に重きを置くのもその延長で、
すべての現実がその頭の中の認識なり意志なりで可能だと考えてしまうのである。
その結果、現実が不愉快なものならば、自分なり他者なりにとことん「恨み」を蓄積し、
現実が愉快なものなら自意識を肥大させることになる。

いわゆる成熟した精神の持ち主が、どちらかというと運命愛的な態度をもっているのに対し、
未熟な人間というのは常に現実や将来起きることに怯えている。
というのも、自己と外界の境界があいまいなために、
不愉快な現実によって自意識が破壊されると錯覚しているからである。

その結果、ユーモア、柔軟さ、寛大さに欠ける硬い性格になるという。
また、そのようなタイプの人は、成熟した人がなぜ大らかで柔軟で自信に満ちているかを理解できず、
社会的地位や金や名誉によって守られているからそうなっていると勘違いしていることが多い。

>>716
なかなかおもろいｗ

句読点を改行の目安にする奴。
「、」「。」の代わりに「,」「．」を使う奴。
末尾にwをつける奴。

こいつらが同一人物だとしたらこのスレはまさしく一人芝居だな。

オブジェクト指向とは、意識を対象に向けること。
意識を、How（機能）ではなく、What（対象）に向けるだけ。
ただ、それだけのこと。

意識を、How（機能）ではなく、What（対象）に向けるパターンを
示したのが、デザインパターン。

なんてことは、本にいくらでも書いてある。
本を何冊読もうが、さほど腕は上がらない。
大切なのは、美しく仕上げるとういう意識をもって、設計の経験を重ねるしかない。
それしかないのだ。

自問自答を繰り返せ。既成概念にとらわれるな。それがオブジェクト指向だ。

これこそオブジェクト至高

オセロの主要クラス。

思考クラス：打石の決定
局面クラス：局面のコンテキスト（配石、打石、変化を記録する）
記録クラス：ゲームのコンテキスト（局面の流れを記録する）
規則クラス：オセロのルール
進行クラス：ゲーム進行

┌──────┐ ┌──────┐ ┌──────┐
│ 思考クラス ├─◇ 進行クラス ◇─┤ 規則クラス │
└──────┘ └─◇──◇─┘ └──────┘
│ │
┌─┘ └─┐
┌───┴──┐┌──┴───┐
│ 局面クラス ││ 記録クラス │
└──────┘└──────┘

┌──────┐　┌──────┐　┌──────┐
│ 思考クラス ├─◇ 進行クラス ◇─┤ 規則クラス │
└──────┘　└─◇──◇─┘　└──────┘
　　　　　　　　　　　│　　│
　　　　　　　　　┌─┘　　└─┐
　　　　　┌───┴──┐┌──┴───┐
　　　　　│ 局面クラス ││ 記録クラス │
　　　　　└──────┘└──────┘

┌──────┐　┌──────┐　┌──────┐
│ 思考クラス ├─◇ 進行クラス ◇─┤ 規則クラス │
└──────┘　└─◇──◇─┘　└──────┘
　　　　　　　　　　　│　　│
　　　　　　　　　┌─┘　　└──┐
　　　　　┌───┴──┐　┌──┴───┐
　　　　　│ 局面クラス ├─◇ 記録クラス │
　　　　　└──────┘　└──────┘

オブジェクト指向と構造化は相反する考え方ではない。
オブジェクト指向により、What（対象）を見つけたあと、
How（機能）の設計は構造化で行うことになる。

ようやく分析モデルと設計モデルの相違を理解しはじめたようだな。
次は設計モデルを詳細化しろ。

>局面クラス：局面のコンテキスト（配石、打石、変化を記録する）
>記録クラス：ゲームのコンテキスト（局面の流れを記録する）
はひとつでいいいんじゃね？

>規則クラス：オセロのルール
>進行クラス：ゲーム進行
もひとつでいいんじゃね？

>>730
>>局面クラス：局面のコンテキスト（配石、打石、変化を記録する）
>>記録クラス：ゲームのコンテキスト（局面の流れを記録する）
>はひとつでいいいんじゃね？

例えば、写真とアルバムがひとつでいいわけない。

>>規則クラス：オセロのルール
>>進行クラス：ゲーム進行
>もひとつでいいんじゃね？

レールと電車がひとつでいいわけない。

>>729
私の設計モデルは、地動説ほどのインパクトがありますよ。
そのカルチャーなビッグバンに耐える覚悟があるなら見せましょう。

[プレーヤ]─◇[ゲーム]◇─[ルール]
　　　　　　　　◇
　　　　　　　　│
　　　　　[ボード]◇─[棋譜]

なんだ
これは前出た分析モデルの劣化版に過ぎないな

まだやってるのか。
だからいいとか悪いとか、そういう問題じゃないんだよ。

どういう役割分担が人にとってより直観（直感ではない）的か、
それが重要なんだろ。

個人的にはルールクラスなんてありえない実装だと思う。
そんなのは盤面の状態クラスの一メソッドで実装した方がずっとわかりやすいじゃないか。

現在の盤面の状態から可能な手を列挙して返すんだよ。

ルールを実装から分離するという練習問題だからな。

>例えば、写真とアルバムがひとつでいいわけない。
アルバムw
写真を持つ写真で...っていってもわかんないかw


>レールと電車がひとつでいいわけない。
レール=乗り物でいいやん

分析/設計の話って幼稚だなｗ
実装レベルの話しようぜｗ

プレーヤはプラガブルな存在だから、
ゲームの審判ルールと
プレーヤの思考ルーチンは分離しておくのが妥当。

思考ルーチンの効率は盤面データの構造に強く依存する。
思考ルーチンはゲームのルールに強く依存する。

プレーヤはプラガブルな存在だから
ゲームのボード状態と
プレーヤの思考ルーチンが使うボードは分離しておくのが妥当。
特に先読みは、ゲーム本体のボードと違うインスタンスを使う必要かある。

>740に失望

ユーザ不在で設計を進める典型的なパターンだな。
UIも機能も自由にしていいんだったら、後は人の好みの問題でしょ。
見栄えに重きを置くひと、拡張性(オセロの拡張性ってなんだ？)に重きを置くひと、
思考ルーチンの強さや早さに重きを置くひと、etc..
決まっているのはオセロのルールだけなんだから、他の要求仕様をおざなりにしてちゃ
目的のものができあがるわけがない。
あと、スピード重視の場合、オセロみたいに再帰を駆使するロジックはマイクロ秒単位
の節約が要求されるから、OO的なノウハウより、純粋にマシン語レベルの命令数を
少なくする技巧を重視した設計の方がいいな。時間の制限さえなければ、オセロなんて
誰が作っても最強のものが作れるんだから。ここはいかに無駄を排除できるかが問わ
れるところ。

>>742
なんか恥ずかしい自己陶酔ｸﾝだなあw
何の話をしてるんだよw
ここは何を話題にするスレですか？

単なる練習問題に過ぎないので
発注者も要求仕様も無い
とマジレス

・・・あのさ。オセロの設計は、
オセロをOOで設計することによって（構造化開発との対比が出来て）
スレタイの問いに応えようというのが目的じゃなかったっけ。
オセロゲームの実装論議をすることが目的ではなかったと思うけど。

で？

要求仕様が無いんじゃ、できあがったものの評価もできんわなぁ。
ＯＯとの比較のために、他の手法の利点、欠点を語ってもいいと思うけど。
勝手に、境界引いちゃうのもなぁ。了見が狭いというか。ま、いいけどね。
じゃ、どうぞ続けてください。

>>736
デザパタ覚え立ての典型的発想だな。
局面と棋譜の間に同一視の概念は適切ではない。
補習の必要があるな。

(・∀・) < A と B のｱｲｰﾀﾞに ﾄﾞｰｲﾂｼのｶﾞｲｰﾈﾝ

>>736
いわゆる、打ち出の小槌だね。
打ち出の小槌（Golden Hammer）パターンとは、自分が使い慣れている技術や方法を
何にでも（必要のないところにでも）適用してしまう 。

(・∀・) < ｱｲｰﾀﾞは ﾄﾞｲﾂ人の外人

アイーダはジュゼッペ・ヴェルディが作曲、1871年に初演された全4幕から成るオペラである。
ちなみに、志村けんがやってたのは、アイーンだ。

いかんいかん、無意識にオブジェクト指向のオーラが出てしまう。
私の存在が技術の流出なのです。

(・∀・) < ﾀﾜｹﾀ存在が愚術を露出

>>736
>写真を持つ写真で...っていってもわかんないかw
デザパタを実装レベルのテクニックとして理解してしまうと
このような発想になる。
デザパタの考え方を概念として理解すれば、このように適用を間違える
ことはない。

(・∀・) < ｴﾛ写真の中にｴﾛ写真...っていってもわかんないかｗ
　　　　　　ｴﾛを実行ﾚﾍﾞﾙのﾃｸﾆｰｸとして理解してしまうと
　　　　　　このような発想になる。
　　　　　　ｴﾛを概念として理解すれば、ｾｸｰｽなしで逝ける。

>局面クラス：局面のコンテキスト（配石、打石、変化を記録する）
>記録クラス：ゲームのコンテキスト（局面の流れを記録する）
はひとつでいいいんじゃね？

>規則クラス：オセロのルール
>進行クラス：ゲーム進行
もひとつでいいんじゃね？

インサートメソッドは、ちんこクラスとまんこクラスのどっちにもたせたらいいんだろう。

tinko

>>757
坊や、まだ、自分のスタイルを持つのは早すぎるよ。
今は、美しさを追求しなさい。
Single Responsibility Principle

>>758 hint
・「リストに要素を追加する」
・「まんこにちんこを挿入する」

>>761
前者はリストを更新するのが目的だけど
後者はその後のちんこの動作の準備操作に過ぎない
でしょ。類似性があるようには思えないんだけど。

>>757
記録クラスは、局面クラスを利用して、棋譜の記録と再生を行うことが責務なのです。
棋譜の記録と再生が不要なら、記録クラスも不要です。
このようなオプション的なクラスを、本質的に必要である局面クラスと一つにすべきではありません。

ゲーム進行クラスは、棋譜の再生、逆再生など、オセロのルールとは関係ないことも
責務としています。純粋なオセロのルールとは切り離すべきなのです。

今は、シンプルな美しさを最優先しようじゃないですか。

>本質的に必要である局面クラス
kwsk
何が"本質"なんだろ?

>純粋なオセロのルールとは切り離すべき
なぜ？

ってゆーか
>記録クラスは、棋譜の記録と再生を行う
>ゲーム進行クラスは、棋譜の再生、逆再生
こんな話は今知ったw
知った今となってはこっちが分かれてる理由が不明

>>764
いやです。ここで、遊んでいるだけですから。
技術の流出になるじゃないですか。私は無料ではありません。

>>764
ttp://jibun.atmarkit.co.jp/ljibun01/rensai/sinji01/sinji01.html

　　　　　[リバーシ系ボードゲーム]
　　　　　　△　　　　　　　　　　　　　◇
　　　　　　 ：　　　　　　　　　　　　　│
　　　　[ 試合 ]　　　　　　　　　 [ルール]
　　　　　　◇　　　　　　　　　　　　　↑従う
　　　　　　↓　　　　　　　　　　　　　│
{ プレーヤ, 記録, 進行係, }　 [審判, 進行係, プレーヤ, ゲーム盤, 石, ]

　┏━━━━━━┓　　　　　　　　　　　　　　　　　 ┏━━━━━━┓
　┃進行係　 　 　 ┃　　　　　　　　　　　　　　　　　 ┃審判　　　　　...┃
　┣============┫　　　　　　　　　　　　　　　　　 ┣============┫
　┃先攻後攻決め┃　　　　　　　　　　　　　　　　　 ┃　　　　　　　　 .┃
　┃開始指示　 　 ┃　　　　　　　　　　　　　　　　　 ┃　　　　　　　　 .┃
　┃打ち順指示......┠───────────→┨お手付き判定.┃
　┃　　　　　　　　 .┠←───────────┨パス判定.　 　 ┃
　┃終了指示　 　 ┠←───────────┨終了判定　 　 ┃
　┗━┯┯━━━┛開始/終了/手戻/譜の再現 .┗━━━┯━━┛　　　　　　　　　　　　
　　..次↓└────────────────→┐　　 .↑ﾁｪｯｸ
　┏━┷━━━━┓　　　　　　盤面を見る　　　　..┏┷━━┷━━┓　記録 ┏━━━┓
　┃プレーヤ　　　.┠…･┌────────→　┃ゲーム盤　　....┠──→┨記録　 ┃
　┠──────┨　　│　　　　　　打つ　　　 　 .┠──────┨　 　 　 ┗━┯━┛
　┃石　　　　　　　.┠───────────→┃石の配置　 　 ┠←────┘
　┠──────┨　　│　 　 　 　.：　関連　　　 .┠──────┨　手戻/譜の再現
　┃手を考える　　┃　　│　　 ┏━┷━┓　　　　.┃初期配置　 　 ┃
　┗━━━△━━┛　　│　　 ┃打ち手.┃　　 　 .┃ﾘﾊﾞｰｽ　　　 　 ┃
　 　 ┌──┴──┐　..↑　　 ┠───┨　　　　.┃得点集計　 　 ┃
┏━┷━━┓┏━┷━┷┓....┃石　 　 ┃　　　　.┗━━━━━━┛
┃人　　　　.┃┃ｺﾝﾋﾟｭｰﾀ .┃....┃位置　 ┃　　　　
┣========┫┗━━┯━┛....┗◇━◇┛　　　　
┃手入力　 ┃.考える↓　　　　 ┌┘　 └─┐
┗━━━━┛┏━━┷━┓┏┷━━┓┏┷━━┓
　　　　　　　　 .┃戦略　 　 ┃┃石　 　 ┃┃位置　 ┃
　　　　　　　　 .┗━━━━┛┠───┨┗━━━┛
　　　　　　　　　　　　　　　　　 ┃色　 　 ┃
　　　　　　　　　　　　　　　　　 ┠───┨
　　　　　　　　　　　　　　　　　 ┃ﾘﾊﾞｰｽ..┃
　　　　　　　　　　　　　　　　　 ┗━━━┛

濡れてからでないと入れてはまずい＞本質的な局面
今日は何回やって体位はどう変えたか＞記録クラス

生成()
→[ゲーム]　　new Player(黒)
　　　│|　|────→ [プレーヤA]　　new Player(白)
　　　│|　|─────────────→ [プレーヤB]　　new Board()
　　　│|　|───────────────────────→ [ゲーム盤]
　　　││.─┐初期化()　　　：　　　　　　　　　　　　 ：　　　　　　　　　　　　：
　　　│|　|←┘　　　　　　　　 ：　　　　　　　　　　　　 ：　　　初期配置().　　：
　　　│|　|────────────────────────→││
　　　││─┐ゲーム進行() .：　　　　　　　　　　　　 ：　　　　　　　　　　　　：
　　　│|　|←┘　次を打て()　.：　 思考処理()　　　　 ：　　　　　　　　　　　　：
　　　│|　|──────→││.─┐　　　　　　　　 ：　　　　　　　　　　　　：
　　　│|　|　　　　　　　　　　.│|　|←┘　　　　　　　　 ：　　　　　 　 打つ()　.：　石を置けるか()
　　　│|　|　　　　　　　　　　.││───────────────→││.─┐
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　│|　|←┘
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││　リバース()
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││.─┐
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　│|　|←┘
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││　パス/終了判定()
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　　　　　　　　　　　││.─┐
　　　│|　|　　　　　　　　　　　 ：　　　　　　　　　　　　 ：　(パス/終了なし).│|　|←┘
　　　│|　|.←────────────────────────││
　　　│|　|　　　次を打て()　　：　　　　　　　　　　　　 ：　思考処理()　　　　 ：
　　　│|　|───────────────→││.─┐　　　　　　　.││
　　　│|　|　　　　　　　　　　.　：　　　　　　　　　　　.│|　|←┘..盤面参照()││

図がずれて見える人のためのイメージ表示

>>767 http://aas.u.la/c.cgi/-/prog/1177769397/767?480
>>768 http://aas.u.la/c.cgi/-/prog/1177769397/768?480
>>770 http://aas.u.la/c.cgi/-/prog/1177769397/770?480

図がずれて見える人のためのイメージ表示

>>767 http://aas.u.la/image.cgi/AAS=480/pc11.2ch.net/prog/1177769397/767
>>768 http://aas.u.la/image.cgi/AAS=480/pc11.2ch.net/prog/1177769397/768
>>770 http://aas.u.la/image.cgi/AAS=480/pc11.2ch.net/prog/1177769397/770

>濡れてからでないと入れてはまずい＞本質的な局面

んーその理由だったらルールとか進行の方ぢゃね？

どうしたら濡れるかはその時々なので、少なくともルールではないような。

オセロって、持ち時間とか無いんだっけ？

>>775
あるんじゃない。時間は大切だからね。

確か競技としてのルールは持ち時間を使い切ると負け、だったような

(５) 試合進行
(カ) 相手が時間切れとなった場合、貴方の勝ちが確定し、32.5：31.5での勝ちか、自分に有利なところまで、自分の持ち時間の範囲内で相手の手まで含めて打つ（勝手打ち）かのどちらかを選択できます。
　なお、勝手打ちの途中で貴方も時間切れとなった場合は32.5：31.5になります。

試合ルールには当然あると思うが、AAが巨大化したからねぐった。
ゲーム開始時にプレーヤに持ち時間与えて、
進行係の次打て指示から
プレーヤが打つまでの時間を(順次)差し引いていって
持ち時間が０になったら即負け
とかそんな感じでしょ。

時間の測定、持ち時間残りのアナウンスは、進行係かな審判かな？

黒、白のプレーヤーがそれぞれチームを組んで複数名いるなどを想定すると、
持ち時間は、プレーヤの属性ではなく、進行係の管理物かな？

時間の測定、持ち時間残りのアナウンスは、進行係だと考える。

プレーヤーとチームは同一視可能だね。

>781
だが勝敗判定は審判？

>>783
審判がオセロの打石ルールだからね。

判定アナウンスは、進行係だろ。

進行と審判が分かれてる理由は？

>>786
進行は、進行と棋譜の再生、逆再生などの係りさん。
審判は、オセロのルールを知っている。
Single Responsibility Principle の原則から分けている。
一つにしてもプログラム上は問題なし。
オブジェクト指向から見ると、分けたほうが美しい。

>進行は、進行と棋譜の再生、逆再生などの係りさん。

これ、ゲーム盤と記録にやらせりゃええやん

進行係っつうのは、ぶっちゃけゲームのmain()関数。
ゲーム進行＝ゲームの時間軸の管理をする。

だから、ユーザが「ちょっと待った今の無し」つう
ルール無視の行動したい時は、進行係に無理をお願いするｗ

あと、昔の棋譜出して練習する時も、進行係にお願いするｗ

>>788
実際はゲーム盤と記録が一生懸命働くけど、進行係がその音頭を取るわけだ。

どこまで真面目に言ってるのかしらないが馬鹿が多いなここも。

仮想機械に分割統治することの目的の一つはナニがどの責任を負っているのか
明確にすることだったはずなのに、審判だの進行だのといった、現実世界に存在する
名詞に引きずられた、期待される機能が曖昧なクラスを乱造してチマチマ分割したら
かえって責任の所在がどこにあるのかわからなくなるじゃないかよ。

審判クラスなんてイラネ。
だから可能な手の列挙とか、勝敗の判定なんてものは盤面クラスの一メソッドの方が
より直観的だろ。

もちろん現実世界にそんな知能をもった盤面なんてありえないが、
いいんだよ仮想機械を作ってるんだから。

>>790
おっしゃる通りですね〜
mediator なのかな〜


持ち時間はプレーヤ、
打ち時間測定は審判がやるべき仕事のような気もする。
ついでに、初期配置や得点集計も審判の仕事のような・・・

>>791
おい、また始まったのか罵詈雑言のクズ

>>791
オセロは疎結合の練習問題だからなｗ
練習問題の主旨を貫徹せずに、
気分で議論を左右したいなら、お前は出て行け

で、ここまで話してなんか結論出たの〜？

>>791
肥満児 (The Blob)
責任の多くがひとつのクラスに集中している状況のこと。
ひとつのクラスが処理を独占してしまい、他のクラスはデータのカプセル化しか行っていない。
オブジェクト指向風に見えても本質的には手続き型である。
アーキテクチャ不在が最大の原因だが、プロトタイプをそのまま製品コードとしたような場合にも発生しやすい。
結果的にカプセル化などが不十分のため、複雑で再利用もできない。
この場合のリファクタリングは機能単位での分割ということになる。

進行係が音頭をとる必要があるのか？

「ちょっと待った今の無し」も「昔の棋譜出して練習」もゲーム盤と記録にやらせりゃええ
仲介人いらね

ん〜？チンポとマンコのどちらにinsertメソッドを付けるかって問題か？
両方に付けとけばいいんじゃない？
チンポがのしかかる時はpush
マンコがのしかかる時はpull
でしょ？

チンポにinsertメソッドは痛いだろw

push/popはいいアイディアだが

>>796
なるほど、審判だの進行だのといったわけのわからないクラスを作っておけば、
それらは再利用が可能になるわけね。
で、何に再利用するの？w

本当に馬鹿だな。

単純なのが好きな人はこれでやってくれ。
設計段階で詳細化したくないだけでしょ

+---------------+ 手を打つ　+---------------+ きろく
| プレーヤ　　　　　 |────→| ゲーム盤　　　　 ├ →[きろく]
+---------------+2　　　　　 1+---------------+ 　　　 ↓
| 石の色※1　　　　 |　　　　　　　 | 石配置　　　　　　 ├──┘
+---------------+ (パス)　　　+---------------+ 手戻/棋譜の再現
| 次の手を考える　|────→.| 初期配置　　　　　|
|　　　　　　　　　　　 |2　　　　　　1| はさまれた石を　 |
|　　　　　　　　　　　 |　　　　　　　 | 　ひっくり返す　　 |
|　　　　　　　　　　　 |　　　　　　　 | 終了判定　　　　　|
|　　　　　　　　　　　 |　　　　　　　 | 得点集計　　　　　|
+---------------+　　　　　　　+---------------+

>>800
出てけよ罵詈雑言
さっさと死ね

>>797
それでは分かりやすい例を挙げてみようか。
これはビデオデッキとビデオテープの関係だな。
まぁ機能だけでみると、ビデオデッキとビデオテープが一体になっていても一見問題ない。
でも他のビデオテープが見れないよね。
進行係とゲーム盤と記録が分かれているのは、仕様変更に備えてるんだな。これが。
仕様変更の必要がなければ、問題なしとしてもいいよ。俺はいやだけどね。

>800
ちと違う。
分けとくことによって仕様変更が及ぶ範囲を局所化したい。
開放/閉鎖原則を守りたい。
再利用したいわけではない。

...もっとも今のところ審判だの進行だのがうまく分かれているとは思えないけどw

GNU boardだっけ？
ボードゲーム用汎用フレームワーク作ろうとしてた試みって。
あれ、チェス以外の実装見た事がないような気もするが・・・

まあここのオセロは「ルール分離」の練習問題に過ぎないから、
ボードとプレーヤはできるだけ抽象化しといて、
ルール(審判、進行係、ボードデザイン、石を含む)と
思考ルーチン を切換可能なフレームワークにしましょ
って話でいいと思うけどｗ

>他のビデオテープが見れない
んー今は他のテープなんていらないやんw

>仕様変更に備えてる
どんな？
ゲーム盤や記録に手を入れずに進行だけですむ仕様変更って何？

public sex() {
while(chimpo->hasEnegry()) {
chimpo->push();
mamco->pull();
chimpo->pull();
mamco->push();
}
}

更にいうと審判と進行係部分も
汎用フレームワークの一部にしといて、
ルール流し込めばそのルールに従って動く、
っつう方向。

思考ルーチンはヒューリスティックが重要だから、
ここは毎回カスタマイズ。

自分は構造化厨化も知れないけど。
オセロみたいな単純なゲームを設計するのにこんなに紛糾するなら
OOなんか要らない
という素の感想があるな

貴様ら、設計中毒という言葉を知っていますか？

>>806
ボードゲームのフレームワーク化としては、
それなりに再利用ができるでしょ
見た目が似てる将棋やチェスや囲碁とかね

while(isMakelove()){
while(chimpo->hasEnegry()) {
chimpo->push();
chimpo->pull();
}
while(mamco->hasEnegry()) {
mamco->pull();
mamco->push();
}
}

GNU goはネットニュースに流れてたような気がする。
囲碁の思考ルーチンは鬼だから、ほとんど新規コードだったと思うけどｗ

>>806
では、ビデオをＤＶＤに替えて読み直して理解して。

>それなりに再利用

いらね

>>815
君の意見は聞いてないから安心してね。

>814
なおさらビデオデッキの再利用は無理やんw

>>817
ＤＶＤに替えて読むとＤＶＤデッキになるわけだ。がんばれ。

やはりオブジェクト指向は、センスを増幅するアンプだね。
レスを見ると優劣がハッキリしてる。

>>810
貴様はmankoが変わる度にchinkoを再実装してろ
死ね

>>810
藻前は、設計力無だな。

>818
あえて言おう、
んー今は他のDVDなんていらない、と
(釣られたのか？)

ＯＯは銀の弾丸どころか
銀の耳掻きにもならん。

OOは金の核爆弾だからな。

>>823
申し訳ございません。ＯＯは熟練者向けの道具なので、ご遠慮願えますか？

>>824
ＯＯは、魔法の杖ではありません。藻前には無用の長物ですな。

いや、だから使い方を誤ると全てぶち壊しと、

>>827
ごめんなさい。理解不足でした。

構造化はプログラムを部品単位に明確にするやり方。
オブジェクト指向は、プログラムを擬人化するやりかた。

こんなんでいい？

>>829
だめです。

>>829
目的は同じ。着目対象が違うだけ。How（機能）とWhat（対象）。

オブジェクト指向分析が提唱される以前には、システム分析のレベルにおいては、データ構造を中心としたシステムの分析技法である構造化技法が存在した。
また、プログラミングのレベル (プログラミングパラダイム) では、プログラムの実行の流れを決められた制御構造の組み合わせとして書き下す構造化
プログラミングや、カプセル化を促すモジュールプログラミング、多態に対応するデータ指向プログラミングという技法が存在していた。
これらに対し、オブジェクト指向手法はそれらを一般化しさらに推し進めたものであるという考え方がある。
オブジェクト指向分析や設計に基づいてシステムを実際に開発する際には、オブジェクト指向言語を用いる必要は必ずしもない。
ただし、オブジェクト指向によるシステム分析結果を実装するには、プログラム構造とのセマンティクスギャップが少ないオブジェクト指向言語を用いるのが普通である。
オブジェクト指向は、当初プログラムの構造をオブジェクト群の相互作用とおよびその雛形であるクラス群の関係として捉え、
プログラムコードを書き表すオブジェクト指向プログラミングから始まっているが、その後、システム開発における要求分析フェイズにおいて、
開発しようとする対象領域の構成要素をオブジェクトとして発見・定義していくオブジェクト指向分析、
システムの動作や構造をオブジェクトとクラスとして記述するオブジェクト指向設計技術としても広く発展・普及することとなった。
wikipedia

>>791
イラネ

mamkoだけに、基本は先入れ中出し法かな。

クラス、オブジェクト、インスタンス、メソッド、とかは日本語、漢字表記にして欲しい。
そもそもオブジェクト指向という言葉が長くて何を言いたいのかわかりにくい表記なんだよね。
オブジェクト指向開発の中には構造化開発も含まれているのに、それぞれが全く違うかのような
考えで対立をあおるとかもう秋田。

ＯＯＰで作ったものがアセンブラ表記になったとき、構造化プログラミングとの違いは、
似ている関数の使い回しをしているだけなんだよね。
アセンブラでの実装と考えれば、昔からあるジャンプテーブルを使った方法でしかない。
ソースレベルでは、高度な概念、実行時は効率化した構造化と大差無い。

OOPと構造化プログラミングが対立するなんて言ってる奴みたことないけど。
すくなくとも本を書く程度の知識がある人間の中での話しだが。

モジュール分けの分類方法のひとつって程度にだけ思ってる。

オブジェクトにはオブジェクト・クラスとオブジェクト・インスタンスがある。
「インスタンス」は『アリストテレス』のような個々の存在物を表す
「クラス」がその上位分類である『人』を表す
オブジェクト，クラス，インスタンスは全部オブジェクト

ソースはITPro

ジェラルド・ワインバーグの｢エゴレスプログラミングの十戒｣
http://www.codinghorror.com/blog/archives/000584.html

1. 自分が誤りを犯すということを理解し、受け入れること 。
2. 自分と自分のコードは別物である。
3. どんなに｢空手｣を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。
4. 相談せずにコードの書き直 しをしない。
5. 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。
6. 世界で唯一変わらないのは変わるということだけ。
7. 唯一本当の権威は、地位ではなく知識より生ずる。
8, 自分で正しいと思うことのために戦うこと。しかし負けは潔く認めること。
9. ｢部屋に籠りきりのやつ｣にはなるな（ｗ
10.人ではなくコードを批判すること??コーダーには優しく、コードには厳しく。

コピペ君って馬鹿だな、まで読んだ。

コピペ君って馬鹿だな、まで読んだ。 、まで読んだ。

コピペ君って馬鹿だな、まで読んだ。 、まで読んだ。、まで読んだ。

盤面全体のリバースルール（全駒の白黒を反転）があると
普通のオセロとは違う駆け引きができそう
盤面リバースの発生条件が必要だけど

俺たちの力で日本を一位にしようぜ！！
http://wwwww.2ch.net/test/read.cgi/news4vip/1178519584/

1. チリ 116,221,567
2. ポーランド 110,624,561
3. イスラエル 77,638,668
4. スロベニア 54,199,248
5. フィンランド 38,015,461
6. デンマーク 31,365,051
7. ブルガリア 30,442,276
8. 日本 19,478,937

石を投げる戦争から人は進化・進歩を遂げ、剣や槍などの武器をもって戦うようになった
人間はさらに発展し兵器を使う戦争を始めた
そして今、指先一つを武器とした電脳戦争が勃発したのであった・・・
皇国を勝利へと導くには貴様らの参戦が不可欠である
・戦場
http://www.clickclickclick.com/default.asp
・まとめサイト
http://www33.atwiki.jp/clickvip/
・mixi
http://mixi.jp/view_community.pl?id=2141035

コピペ君って馬鹿だな、まで読んだ。

コピペ君にならケツのヴァージン捧げてもいい、まで読んだ。

コピペじゃないと煽られる・・とでも思ったか
煽るのは馬鹿だから気にしなくて良いのに

GW中にすごく伸びたな。読むのが大変だった。
前スレで俺に質問が出ていたので、今更だが回答しておこうと思う。

>OOだと変更が入れば入るほど、洗練されていく、とありますけど、
>なぜそうなるんですか？

これは使われるパターンが多くなると、適切でないクラスに配置した変数やメソッドが使いにくく
なるため、適切なクラスに配置し直す事になる。
それにより汎用化が進み、抽象化が進むみ、洗練されていく
これはOOの考え方によるもので、言語仕様とは直接関係ない。
コーディング量が増えても悪化しない（丈夫）なのがOOの特徴だ。


>C言語だとDBが変わると修正が大きくJavaだと小さい、とありますが、
>各DB＋言語で使用するライブラリを、DBの違いを吸収した関数を用意しておけば、
>関数の呼び先の処理が変わるだけで言語の違いは無いと思うんです。

その通り。
この非OOでのIF共通化は、OOの抽象化と同じような効果がある。
しかし、これが問題で適切に変更を見越して設計するのは業務に詳しくないと難しい。
例えば前例のDB共通化の関数を手間かけて作ったが、DBを変えなかったので意味がなかったなんて
話しは良く聞く。これはセンスと言うより業務経験に因る所が大きく、構造化の基本方針は
「最初に適切な設計をして修正はあまり行わない」と言う物である。

OOの場合は基本的な概念が「抽象化」なので、変更に強い。
そのため拡張性を考えずに必要な部分だけ作っておいて、後から修正や追加を行っても修正は少ない。
これもOOの特徴だ。つまりこれらの違いは、センスの問題というより基本方針の違いとなる。

このスレで抽象化と仮想化の説明があって、だれか要約してくれとあったのでやってみる。
ちなみに原文でも、長いが難しい事は言っていないので、よく読めば分かると思うが。

仮想化とは存在しない装置を、あるように見せることだ。例（仮想キーボード、仮想メモリ）
抽象化とは物をクラスで表現することだ。
抽象化の表現は人によって違うので、経験が必要だ。

って事かな。

どう見ても宗教です。本当にありがとうございました。

結局主観でしか喋れんならblogでやってろ屑コテ

■ おすすめ２ちゃんねる 開発中。。。 by FOX ★
このスレを見ている人はこんなスレも見ています。(ver 0.20)
【モバ・au】同人系 自作イラスト総合【25万円】 [オークション]
フリーのファイル暗号化ツール 2MB [ソフトウェア]
【曲は】ボーカル募集【できたけど】 ８ [DTM]
萌え・電波ソングを作るスレ５ [DTM]
★Word/Excel (MS-OFFICE) 初心者スレッド Part30★ [PC初心者]

>>849
君は文系の方が向いてるんじゃないの？w

そういう愚劣な言葉遊びがお好きなら政治学とか社会学に進むべきだったね。
うまくいきゃ大好きな言葉遊びで飯が食えたのに。

このスレを伸ばしていたのは、おじゃばとそれ以外の粘着芋だったということが、
このＧＷ中にはっきりしたな。

>850、851
宗教でも主観でもないと思うが。
「抽象化すれば変更が簡単になる」ってのは分かるだろう？
ここからもう納得出来ないのか？それとも抽象化はの意味が分からないのか？

>853
原文を書いたのは俺じゃないぞ。俺は要約しただけ。
要約が難しいと言っているのか？

>854
「おじゃばと」？
GW中は参加していないが。
GW中参加していたのは学生かな？もう来ないのかな？

http://wwwww.2ch.net/test/read.cgi/news4vip/1178681376/
【一番クリックした国が優勝】
大英帝国主催の世界クリック選手権開催中！
俺たちのクリックで日本を一位にしようぜ！！
“30年は日本に手は出せないな”という勝ち方をしたい。
詳しくはまとめサイトで
1. チリ 151,573,423
2. ポーランド 149,469,832
3. ★日本 112,270,351★ （5/9 11:00現在）
・戦場
http://www.clickclickclick.com/default.asp
・まとめサイト
http://www33.atwiki.jp/clickvip/

コピペ君って馬鹿だな、まで読んだ。

奇遇だな、俺もコピペ君って馬鹿だな、まで読んだ。
しかし、そんなこと、わざわざ報告するほどのことか？

このスレのオセロの設計についても根本的に無意味な所が多い。
前述のようにOOでは構造化のような「最初から拡張性を考えた設計」は必要ない。
つまりとりあえず必要最小限の機能だけ、抽象化して実装しておけばいい。

最初から汎用ボードゲームを設計するなんてのは、「優秀な非OO技術者の後遺症」だ。
ルール分離なども、ルールが追加されてから考えればいい。

ぼんやりてきとうに思い付きをこーでぃんぐすればいいんだな？と抽象化した。

ぼんやり適当にではない。
前にも書いたが、慣れないうちは「実在する物」を「クラスで表現する」ように書くといい。
クラス名を「実在する物」（例：Board）、メソッド名を「動作」（例：put）にすると分かりやすい。
分類不能な物はとりあえず適当に作っておけばいい。

オブジェクト指向と構造化は何が違うかの質問にも答えておこう。
「物をクラスで表現する」のがオブジェクト指向で、「処理抽出し組み合わせる」のが構造化である。

じゃあ、存在してないおまいにかんして
１）　実存のクラス定義とインスタンスを示せ
２）　実存の構造を示せ

あいかわらずここのバカは分析と設計の違いも区別ついてないんだなｗ

おじゃばはもう少し議論のあり方を考えた方がいい
自分の主張があるのは分かったが具体性に欠けてるため
糞コテだとかバカだとか言われる面があるのだろう

あと、これが大きな問題なんだが
「自分が教えてやってるんだ、言うことを聞け」
という雰囲気が相手に伝わってる時点で、
いくら正しいことを言っていたとしても
おじゃばという人間性に疑いをもたれ議論する前の段階で終わってる

理屈っぽい奴はいくらでもいるが、社交性の低いヒューマンスキルの無い奴とは仕事はしたくないな

それ以前の問題かと

彼が言いたいことはなんとなくわかる
しかし根拠が全て主観だから全てが無意味
挙げ句論点を理解してないから
単なる独り言止まりってだけ

プログラムとして実現すると、同じものの本質が変わるのか？

■ おすすめ２ちゃんねる 開発中。。。 by FOX ★
このスレを見ている人はこんなスレも見ています。(ver 0.20)
なぜAMDはインテルに勝てないのか？ [自作PC]
【不安定】Gigabyte被害者の会 Part2【粗悪品】 [自作PC]
【ハルヒに】動画再生用PCを考えるスレ【負けた】 [自作PC]
Celeron 総合 Part7 [自作PC]
ASUSTeK　P4PE/GE-V友の会　Rev.6 [自作PC]

>863
OOのクラス定義
class Ojava{
　　public void setMessage(String msg);
　　public String getMessage();
}

構造化の場合
void OOvsNonOO(){
　　int user = 0;
　　for(int cnt=0; ; cnt++){
　　　　visit(&user); <-- ここで取れるうちの一人
　　　　if(wantsRead(user)){
　　　　　　read(user);
　　　　}
　　　　if(wantsWrite(user)){
　　　　　　write(user);
　　　　}
　　}
}

>863
だから、話通じないからやめとけってばｗ

あかんなこのコテ
ここまでアホだとは思わんかった

つまり、おじゃばは自分のことを、メッセージをもらうか渡すだけの奴と抽象化したわけだ。
まるで、言葉を一つしか覚えられない物忘れの激しいオウムみたいな奴だなw。

いやそーじゃなく

まったく同じ実存を表現してみろっていっただけ。
奴の解釈はそれだけだったらしいけどな。

>873
OOの定義
class Ojava{
　　public void setMessage(String msg);
　　public String getMessage();
}

構造化の定義
struct OJAVA{
　　char name[32];
　　int age;
　　int property[1024];
　　　:
　　　:
};

うわっつらのプログラム言語で、じゃない。

概念を自然言語で説明してくれ。

>875
物をクラスで表現するのがOO
処理の道を作ってデータを流すのが構造化
でどうよ？

ちなみにソースコードは876の意図で書いた。
ソースコードから876を読み取れた人は、センスがあるから自慢していいぞ。

いや、センスはないだろプログラマとしては。
カウンセラとか、ベビーシッタとかそっち方向には適性あるかも。

>876
なぜ「構造化」という歴史があったか調べてから言え。浅いぞ。

おじゃばはセンスがないとよく言われませんか？
皆さんおじゃばプログラム開発のセンスあると思う？
構造化の定義
struct OJAVA{
　　char name[32];
　　int age;
　　int property[1024];
　　setMessage;
　　getMessage;
　　　:
　　　:
};

new()は知っててもmallocは知らない、
javaにはないｗからポインタも解らない、から仕方ないかも。

関数ポインタもな

構造化でもgetmessage作ってDLL化して
それだけをexportすりゃあ同じだろ
OOの利点はこれ、という点が何もねーじゃん

「実存」なんて単語を使い始めたのは誰だ？

役者の演技による映画やドラマ作り＝オブジェクト指向開発
セルやクレイによるアニメ作り＝構造化開発

つかさあ、何かができるとかできないとかそういうことは本質じゃないだろ。
むしろ、設計技法にしろ言語にしろ高級になればなるほどできないことが多くなる。

いや、あの糞こてにみえるレスはただのノイズなんだよ。

>880,881
Javaはむしろ全部ポインタ。
クラスとインタフェース使えば、関数のポインタと同じ事が出来る。

>882
DLL化ってOOのクラスと同じ単位で全部DLL化するのか？

するのか？ じゃないでしょ、するのですか？　でしょ。まったくこの子は何度言ってもできないんだから。

構造化分析の弱点は分析モデルと設計モデルの間に大きなギャップが存在することだ。
このギャップがあるために、場当たり的な設計や、時間の経過に伴い逸れてしまうような
システムを構築しまうリスクが大きい。OOでは、システムのほぼ独立したビューの全てを
一つのセマンティックでリンクできる点で、大きなアドバンテージとなる。

2ch粘着癖を直せ

>>889
何が言いたいか全然わからない。特に最後の文は意味不明。

そんなこと言うと余計調子に乗ると思うぞこの馬鹿は。
基本的にメンタリティが小学生みたいだからな。

すまん、俺もいまいちピンとこなかったんだが、偉い人の本に書いてあったもんで、
2chに書きこんだら覚えるかなと思ってメモってみただけ。気にすんな。

>>887
そういう時は

つ[Null pointer Exception]

て反論するんだ。
アンチJavaの常識だ。

Javaっていい？

マニュアルに書いてないバグ
使いこなすのにマニュアル外の経験が必要なVC++より
Javaのほうが癖が無く素直。

>888
はぁ？

>891
そんなに難しい事を言ってないと思う。もう少し簡単に訳してみる。
----------------------------------------------------------------------------------
構造化では、分析（要求仕様からデータの流れと処理を考える）と、
設計（抽出した処理を階層的に並び替える）に、大きな開きがある。
そのため場当たり的な設計や、変更のしすぎで破綻するシステムを作る可能性が高い。
OOでは独立した構造（クラス）を、「クラス」と言う1つの文法で記述出来て、
組み立てられるのが、構造化に対する優位性である。
----------------------------------------------------------------------------------
と言う事だろう。
「OOでは独立した構造（クラス）を、「クラス」と言う1つの文法で記述出来て〜」
と言うのは、俺の「DLL化ってOOのクラスと同じ単位で全部DLL化するのか？」から
俺の言いたい事を読み取って代弁してくれたんじゃないのか？
知らないふりはよせよ>893

>894
なるほど、参考になった。

>896
確かにその通りだ。
つーか電球、あんなにOO嫌いだったのに、Javaの素晴らしさに目覚めたのか？

>>897
難しいとは言っていない。意味不明だといっている。
まず、「ギャップ」とか「大きな開き」とか書いているところだ。
なんだこれは。なんなのだ。貴方はわかるのか？
分析モデルと設計モデルの間のギャップとは何なのだ？
文学や読書感想文じゃないんだから、いきなり感性とか感想に基づいた
未定義用語を書かれても意味不明としか返答できないだろう。

そしてそのギャップとやらが
「場当たり的な設計や、時間の経過に伴い逸れてしまうようなシステムを構築しまう」とか
「場当たり的な設計や、変更のしすぎで破綻するシステム」
の原因（の一つ）になると言っている。
これにはなぜそうなるのかの説明が一言も無い。
「ギャップ」とか「大きな開き」とかの定義も説明もせずにそれに起因する事象のことを書かれてもわからんだろ。

893とおじゃばは文系なのか？

ギャップってのは、分析の時は人間や業務の視点からとらえ、
設計の時はコンピュータシステムの視点から行うことを指してる。
つまり、分析モデルから設計モデルに移る時に、
一度モデルをばらして再構築する必要がある。
OOの場合、分析モデルのオブジェクトを設計モデルに持ち込める度合いが大きいというだけの話。
しかし、RDBがある限り、そんなに話は甘くない。

>>899
お前、「ギャップ」や「大きな開き」の意味がわからないのか？
本当にわからないのか？
「難しい」や「意味不明」や「感性」などを定義もなく使ってるようだが。
これらはわかるのに、「ギャップ」や「大きな開き」がわからんのか？