【オブジェクト指向】言語学習が先？概念学習が先？
レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん
NGNGC#やJavaといったオブジェクト指向言語をマスターする場合
オブジェクト指向の概念・概論を学ぶのが先がいいのか、
それとも、C#やJavaの言語を学ぶのが先がいいのか、
どっちがいいと思われますか。
0002１
NGNG時代の流れもあって、C#を勉強を始めました。
C#の言語を勉強していると、
「オブジェクト指向とはどういうものかを知らないと効率悪いよな」と思い
憂鬱なプログラマのためのオブジェクト指向開発講座って本を読み始めたら
「やっぱ、言語を知らないと効率悪いよな」って思うようになって
鶏が先か、卵が先か状態になってしまいました。
皆さまは、どのようにマスターされました？
0003デフォルトの名無しさん
NGNG概念、言語仕様を学ぼうとするのはどちらが先でも結構だが、
結局一番重要なのは実践であってそれは本では学べない。
よって、さっさとそのC#とやらを使え
0004デフォルトの名無しさん
NGNG>>3
> 結局一番重要なのは実践であってそれは本では学べない。
あと、いい先生に逢うこと。
実践から得られた経験を整理して理解する時間と、
それを助けてくれる先生を得ることが大切。
0005デフォルトの名無しさん
NGNG習うより慣れろ。阿都市ね。
0006デフォルトの名無しさん
NGNG言語だけでも、プログラムにはなる
0007デフォルトの名無しさん
NGNG0008デフォルトの名無しさん
NGNGプログラミングは独学でも学べるぞ
0009デフォルトの名無しさん
NGNG手続き型言語と基本的には同じだと思うんだが。
0010デフォルトの名無しさん
NGNG> 俺には分からない。
分かるように努力していない奴には
一生分からない。
0011デフォルトの名無しさん
NGNG少なくともお前よりは出来るし分かる。
0012デフォルトの名無しさん
NGNGぷぷぷ。出来ない奴の気持ちがお前にはわからないってことだよｗ
0013１
NGNG実践の場ですか？
実業務は、まだVisualBasicを使っているので、
（近いうちにC#に移行という話は出ている。
話が出ているだけで、誰もやろうとはしない・・・）
仕事としてはありませんが、
フリーウェアでソフトを作るなりして
実践の場を、作っていこうと思っています。
先生は当然いません。
周りでC#もJavaもつかっている人がいないから
0014デフォルトの名無しさん
NGNGVB使えるならデータ中心的なプログラムスタイルは分かってるだろう。
後はただの言語仕様のお遊びだ。気負うことはまったくないと思われ。
スレ立てる暇あったらJDKインストールして適当な入門書買ってこいと。
0015デフォルトの名無しさん
NGNG話はそれからだ
0016デフォルトの名無しさん
NGNGOO概念とプログラミング両方書いてある入門書で両方学べ。両方だ。
あと、先生がいないなら、JAVAのよいソースを読め。つか、先生なんてふつういるか？
あと結城のデザパタ盆とか呼んで実践してみるのもOOセンスつくかもな。
そしてOOの考え方やOOでの書き方で疑問がわいたらここでもどっかでもスレに書け。
運がよければよい叩きをしてくれる椰子が現れるだろう。
0017デフォルトの名無しさん
NGNG本厨か・・・
0018デフォルトの名無しさん
NGNG0019影
NGNGうへへ、俺は天才だぁー。
0020デフォルトの名無しさん
NGNGまぁ、ある意味事実だ。
0021つぐみ
NGNG0022デフォルトの名無しさん
NGNG必要になってから身につけたのでは遅いかも。<言語
0023デフォルトの名無しさん
NGNGつかOO手法が必要になる時ってどういうとき？
>>19 は事実だよ？
0024デフォルトの名無しさん
NGNG0025デフォルトの名無しさん
NGNGどっちがいいと思われますか。
smalltalk(VisualWorks or Squak)を勉強すれば、両方習得
できると思うけど。
0026デフォルトの名無しさん
NGNG0027貧乏紙
NGNGすごい名前の本！！！
0028デフォルトの名無しさん
NGNG0029デフォルトの名無しさん
NGNG0030デフォルトの名無しさん
NGNGいや、それめっさ定番の本なんだが...。
興味を持ったあなたは運がいい。ぜひ一読をおすすめします。
...とマジレスしてみる。
0031デフォルトの名無しさん
NGNG実装⇔概念
のスパイラルで。
0032デフォルトの名無しさん
NGNG広まることがあるだろうか。実用を考えればやっぱり後者では？
http://sumim.no-ip.com:8080/wiki/414
マイナーな世界で純粋を遊びたいなら、Smalltalkなぞ汚くてやってられん、という人も多いし。
http://pc2.2ch.net/test/read.cgi/tech/1070886635/
0033デフォルトの名無しさん
NGNG0034デフォルトの名無しさん
NGNG激同。概念だけだと、犬が「ワン」猫が「ニャー」の話で終わる。
そう思って憂鬱本と同じアプローチで社内研修をやってみた。
コードはJava用とVB.NET用と両方用意、VBしか知らない人のためのコードの説明も加えた。
…生粋のCOBOLerから「わからん」と苦情がきますた…
0035デフォルトの名無しさん
NGNGGoFならJavaでも++でも出来んじゃん。って事ではなくて？
0036デフォルトの名無しさん
NGNGプロトタイピングしやすいし、概念やデザインの説明に Smalltalk 使われたりするし。
0037デフォルトの名無しさん
NGNGソースプリーズ。
つか、OOコミュニティって何よ？小咄コミュニティとか言う落ちじゃ？
0038デフォルトの名無しさん
NGNGそれより、C++ と Java を一括りにして、Smalltalk と線引きしている基準が分からん。
>Smalltalk系のOOがC++/Java系のOO以上に
0039デフォルトの名無しさん
NGNG0040デフォルトの名無しさん
NGNGサンプルコードにも結構Smalltalkのが入ってるな。
0041デフォルトの名無しさん
NGNG0042デフォルトの名無しさん
NGNG盛り込んだのはCommon Lisp。
よってLispをしなさい。
0043デフォルトの名無しさん
NGNGANSIって言語機能の標準とか規定してたの？CLRみたいだな。
0044自分で整理できてないが
NGNGC++,Java データ型が思考のベース。
小噺 なにはなくともオブジェクトとメッセージ送信ありき。
前者は、問題対象がオブジェクトの世界。後者は問題記述空間が（も？）オブジェクトの世界。
で、後者が半端だという人達は、http://pc2.2ch.net/test/read.cgi/tech/1070886635/ へ。
0045名無しさん＠Linuxザウルス
NGNG[190]名無しさん＠Linuxザウルス<>
04/02/16 21:49
>>184
妹クラスを作って１２人の妹を派生させて
呼びかけると
お兄い様
お兄いちゃん
お兄いたま
(ry
と応答させて
おお ポリモーフィズム マンセー！！
という感じで理解しろという事かな
0046デフォルトの名無しさん
NGNG俺ならそんなもんが出た瞬間速攻でPC叩っ壊す。
そして氏んでくれ
0048デフォルトの名無しさん
NGNGフサギコはギコ猫のサブクラスだから、
フサギコクラスを作るときに「フサフサだぞ」メソッドを記述すれば、
ギコ猫から継承したメソッド「逝ってよし」「ゴルァ」が存在し、
（さらに）フサギコ特有のメソッド「フサフサだぞ」が存在するクラスになる。
0049デフォルトの名無しさん
NGNG0050最凶VB厨房
NGNG0051デフォルトの名無しさん
NGNGオブジェクト指向ってなんだよわかんねーとか言ってるやつは
明らかに実戦不足なんだよ！
実戦経験が豊富であれば、自然とわかるものなんだよ！！
0052デフォルトの名無しさん
NGNGそうだな。実践で生半可なOOを振り回すと火傷する。
0053デフォルトの名無しさん
NGNGどちらかというと>>52に同意
0054デフォルトの名無しさん
NGNGオブジェクト指向言語て、Cや、Pascal、Fortranのよう
な手続き型に
1.構造体のメンバーに対して、アクセス制御ができる。
2.ダウンキャストができる。
3.（引数が違えが）同じ名前の関数を何個定義できる。
を仕様として加えただけだ。
cで書かれた有名なopen sourceソフトを解析すると、
2.3はトリッキーな事をしない限り無理だか、１は、
自主的に制御している。
0055デフォルトの名無しさん
NGNGオーバーロードとOOって関係あるのか？
0056デフォルトの名無しさん
NGNG0057デフォルトの名無しさん
NGNGわかりいいな。
「独習Java」でもそこそこいけるもんかな。
それから他の本に手を出すという要領で。
C言語経験者ならちょっとだけJavaの基礎をしっておけばすぐにとびつける。
0058デフォルトの名無しさん
NGNG結城浩の「Java言語で学ぶデザインパターン入門」でも
かなりの収穫はあると思うが。
0059830
NGNGりんご 投げると放物線を描いて飛んでいく。がメソッドだよ。
このりんごを派生させんのが、ポリもフィズ無だ簡単だ。
0060デフォルトの名無しさん
NGNGメソッド名に具体的な挙動まで定めちゃったらポリモルのしようがないと思うのだがどうか？
0061デフォルトの名無しさん
NGNG「投げる」メッセージを受信すると「放物線でとんでく」メソッドを起動するんならいいんじゃない
0062デフォルトの名無しさん
NGNGそれなら良いんだが>>59からそれが感じられないんで
0063デフォルトの名無しさん
NGNG0064デフォルトの名無しさん
NGNG0065デフォルトの名無しさん
NGNGよかったな、おまえ向きの連載がはじまったぞｗ
http://pc2.2ch.net/test/read.cgi/tech/1049778124/205-
0066デフォルトの名無しさん
NGNGどっちもそれなりに理解していろいろプログラム組んでる
んだが、他にOOP関連で勉強しておいた方がいいモンて
ある？
0067デフォルトの名無しさん
NGNGポリモーフィズムによる一貫性が、人間にやさしいと思うんだけどね
真の人間の生理学を知らないと分からないと思う
ＯＯプログラミングやると勝手にプログラミング上手くなっていくっていうのは
もともと人間に備わっている能力を引き出すからだと思う
もともと備わってる能力を知るってのは、こりゃ難しい やってみないとわからないんだから
やってみると意外とできてしまうってのは不思議だ
0068デフォルトの名無しさん
NGNG身につけるっていう感覚に近い 数学の解き方覚えるようなもんだ
0069デフォルトの名無しさん
NGNGある程度書いていると「何か違うなぁ」の壁にぶち当たる。
そこでオブジェクト指向の概念本、デザインパターン本を読む。
これが一番近道だと思う。概念から入るのは余りお勧めできない。
「オブジェクト指向のほうが自然で楽だわ」という感覚を体感できないから。
0070デフォルトの名無しさん
NGNG0071デフォルトの名無しさん
NGNGただの回帰に見えるが実は螺旋の構造になっている。
戻ると1つ上のステージになっているでしょう。
0072デフォルトの名無しさん
NGNG未消化丸出し
0073デフォルトの名無しさん
NGNG消化できてる香具師なんているのか
0074デフォルトの名無しさん
NGNG0075デフォルトの名無しさん
NGNG0076デフォルトの名無しさん
NGNGhttp://pc5.2ch.net/test/read.cgi/tech/1041658161/
0077デフォルトの名無しさん
NGNGカプセル化とか、ポリモーフィズムとか言う概念が言語で実装されてるのみたら
すぐに飛びつくと思うんだよね。
なんて言ってもそれで一番苦労するから
というわけで概念に一票
0078デフォルトの名無しさん
NGNG0079デフォルトの名無しさん
NGNG0080デフォルトの名無しさん
NGNGそういう考えは、間違ってはいないが、しかし、それがオブジェクト指向を困難にしていると思う
「オブジェクト指向でなぜ作るのか」を読むと、その敷居をとりさってくれるよ。
0081デフォルトの名無しさん
NGNG概念や哲学は必要ありません。
0082デフォルトの名無しさん
NGNG手続き型のプログラミングではグローバル変数を除去出来ないとかいう
ふざけたことが書いてあったんで俺の中では糞本認定されてます。
0083デフォルトの名無しさん
NGNG0084デフォルトの名無しさん
NGNGグローバルな破壊的代入を制御し隠蔽するためにどれだけの苦労が払われてきたか理解できないのだろうな。
0085デフォルトの名無しさん
NGNGきみ自身が
「手続き型言語をずっとやってきた人が、
C#やJavaといったオブジェクト指向言語をマスターする場合」
なんて事を前提にしているんだから、
オブジェクト指向の概念・概論を学ぶのが先がいいに決まってる。
さもないとこういうマヌケなことになる。
http://pc5.2ch.net/test/read.cgi/tech/1055075469/83-85
0086デフォルトの名無しさん
NGNG0087デフォルトの名無しさん
NGNG0088デフォルトの名無しさん
NGNGどっちかが先とか言う奴は糞ウォーターフォール推奨者。
0089デフォルトの名無しさん
05/02/05 10:31:170090デフォルトの名無しさん
2005/04/10(日) 02:40:23『概念学習』を先にしたほうがいいと思います。
自分C言語はできたのですが、学校でJavaを習っていた時全く理解できませんでした。
よく言われるような『どこが分からないのか分からない』状態でした。
でどうしても分からないままでいたくないのでオブジェクト指向の載っている本を2,3冊買いました。(多分悪書の部類の本)
全く理解できませんでした。
長々と説明されているのですが、全く理解できませんでした。
でも日経系の本でオブジェクト指向のことが書かれている記事を見ていたら『あれ？もしかしたらこういうことかな?』と
うっすらと分かりかけてきたところを何度も見ていたら理解できるようになりました。
急にわかるようになってくると今までやってきたところがすぐ理解できました。
っていうかね
Javaを教える先生が『オブジェクト指向』の概念学習より言語学習を教えることをメインにおいたために、生徒の全員が全く理解できませんでした。
毎回何十個も言語学習をするよりも、半年かかってもいいから概念学習をしっかりさせたほうがいい。
これは多分英語でもいえると思う。
大学に在学していたとき、アメリカ人の先生が
『今学校の方針でこのような学習法(言語学習)をしているけど、正直概念学習のほうがいい。
単語を暗記させるよりも、辞書片手に英語の新聞の翻訳をさせたほうがよっぽどいい勉強になる』
と言った気持ちがオブジェクトをなんとなく分かりかけたときに理解できた。
どこのプログラマーでも困ったら本見るんだからそれでカバーできない概念学習をしっかりしたほうがいいと思う。
0091デフォルトの名無しさん
2005/04/12(火) 23:39:230092デフォルトの名無しさん
2005/04/13(水) 13:22:12009390
2005/04/19(火) 15:05:07しかも重要なところに『上書参考』って・・・・。
0094デフォルトの名無しさん
2005/04/19(火) 19:48:34概念がわかっても、それが一体何の役に立つのかわからなくてイライラしたやつが
暴動起こして終わると思うな。
0095脳内PG
2005/04/19(火) 20:00:19言語をやる内に、オブジェクト指向は理解できると思いますし
0096デフォルトの名無しさん
2005/04/19(火) 20:06:42どうしても概念レベルで、実装が頭をよぎっちまわない？
酷いときは妥協のしどころまで考えてたり。
0097デフォルトの名無しさん
2005/04/19(火) 20:25:330098デフォルトの名無しさん
2005/04/20(水) 01:44:48与えられた本しか読まない馬鹿にはどんな本を与えても無駄。
0099デフォルトの名無しさん
2005/04/23(土) 20:03:38取り敢えず手始めにCでもするかな…
0100デフォルトの名無しさん
2005/04/23(土) 21:09:17糾える縄の如く理解していけばいいし
実際みなそうしている
0101デフォルトの名無しさん
2005/04/25(月) 07:53:16「カプセル化」と「継承」は実戦から入ったほうが手っ取り早い。
｢多態性オブジェクト」とか「仮想関数」は、概念の勉強を先にしたほうがいいかな。
0102デフォルトの名無しさん
2005/04/25(月) 09:18:55継承・仮想関数も全てポリモーフィズムのためにあるわけだから、
どっちが先もクソもないだろ。
0103デフォルトの名無しさん
2005/04/25(月) 11:46:520104デフォルトの名無しさん
2005/04/25(月) 20:03:08略して
ガイガク
0105デフォルトの名無しさん
2005/04/26(火) 08:10:220106デフォルトの名無しさん
2005/04/26(火) 08:56:310107デフォルトの名無しさん
2005/04/26(火) 15:03:01メッセージングまんせーなら Smalltalk
クラスまんせーなら Java か C++
0108デフォルトの名無しさん
2005/04/26(火) 15:04:26オブジェクトまんせーならSelfか。
0109デフォルトの名無しさん
2005/04/26(火) 15:25:29Javaを使うのには、いくつかの理由があります。
・広く知られている
・C を基本とした文法（一般的なスタイルとなりつつあります）
・フリーで高性能な開発環境が利用可能である
・Javaの知識があれば仕事に就ける
こういった理由から、私はJavaの使用をやめさせようとはしませんでした
（C#にもこういった特徴があり、いずれC#が代わりになるだろうと指摘してはいたんですが）。
ただ、Javaだけに任せようとは思っていません。
Java、C#、C++はいずれも、オブジェクト指向プログラミングのある形を提示してくれていますが、
誰かにオブジェクト指向を紹介するならば、選択肢も紹介してあげるといいでしょう。
選択肢とは、RubyとPythonのことです。
両言語とも、動的型言語です。静的型言語と一緒に使えるようになってれば便利だと思います。
どちらも大変便利な言語です。ちょっとしたスクリプトで自動化して解決するような仕事はたくさんあります。
技術者たるもの、１つくらいはスクリプト言語を隠し持っているべきですね。
0110デフォルトの名無しさん
2005/04/26(火) 21:17:070111デフォルトの名無しさん
2005/04/26(火) 21:49:16その気持ちは分かります。
私のようなSmalltalkファンですら、もう何年もSmalltalkの環境（image）を立ち上げていません。
0112デフォルトの名無しさん
2005/04/26(火) 21:50:19広く使われている（かつ利用可能な）のはPythonですし、
Rubyはより純粋なオブジェクト指向ですので（学ぶのには最適です）
私にとってみれば、すがすがしい感じがします。
あと、Rubyにはブロック（コード群を簡単にオブジェクトとして扱う機能）がありますね。
ブロックは強力なプログラミングツールで、コードの構造化についての多くの考え方を
学ぶことができます。
他のやり方だと、なかなかこうはいきません。関数型言語の入門用にも良いですね。
スクリプト言語の強みは、プロのプログラマが日常的に使えることなんです。
0113デフォルトの名無しさん
2005/04/26(火) 22:03:54オブジェクト指向の本読むと、みんなごっちゃでわけわかんなくなるの･･･
0114デフォルトの名無しさん
2005/04/26(火) 22:10:28基本的に、プログラム内では一意に決まり、いつ参照しても同じ結果が得られる静的な情報。
インスタンスというのは、クラスという型情報を元に、メモリ上に生成されるデータの実体。これをオブジェクトともいう。
プログラムの処理とともに内部変数を変化させる動的な存在。必要に応じて複数生成されることも多々ある。
0115デフォルトの名無しさん
2005/04/26(火) 22:20:11教えてくれてありがと
クラス＝型
オブジェクト＝インスタンス＝メモリ上の実データ
という理解でいいの？
オブジェクトのメンバ関数のメモリ上の実コードはどういう言い方するといんだろ？
クラスのメンバ関数って言った方が正しいのかな？
0116デフォルトの名無しさん
2005/04/26(火) 22:22:10おっと、
オブジェクト＝クラスのインスタンス
と書いているみたいですね。
0117デフォルトの名無しさん
2005/04/26(火) 22:26:42たとえば
class Hoge
{
void foo();
static void bar();
};
というC++クラスの場合、fooはインスタンス所属で、barはクラス所属。
クラス所属の関数は、インスタンスを作らなくてもコールできる。
こんなふうに
Hoge::foo();
一般にこれをクラスメソッドとか、クラス関数と呼ぶ。
インスタンス所属の関数は、当然インスタンスを作らないとコールできない。
Hoge *hoge = new Hode();
hoge->bar();
あんまりいわないけど、あえて言うならインスタンスメソッド。
0118デフォルトの名無しさん
2005/04/26(火) 22:29:02オブジェクトのほうがより抽象的で、インスタンスのほうが具体的なニュアンスを持つ。
でも、かなり混同もされる。
0119117
2005/04/26(火) 22:30:38Hoge::bar();
と、
hoge->foo();
だった
0120デフォルトの名無しさん
2005/04/26(火) 22:48:24そう、そのニュアンスの違いが“理屈で”解らない。
ストラゥストラップの「プログラミング言語C++」を読んでると、
ニュアンスの違いがどこにあるのか解らなくなる
ストラ先生は、オブジェクト＝クラスという意味で使っているみたい
そしてインスタンスって用語は出てこない。
で、他の本を読むとオブジェクト≒クラス、オブジェクト≒インスタンス
のような意味で使う。
オブジェクト指向を特集している今売りの雑誌でも、
オブジェクト＝物だといいつつ、
明確に定義しないまま“クラス”と“インスタンス”という用語を使う
書き手によってさまざま。困ってしまいます。
0121デフォルトの名無しさん
2005/04/26(火) 22:53:48オブジェクトはクラスもインスタンスも含む概念で、
言語や状況によって、インスタンス=オブジェクトと見なせる場合があるのだと
強引に理解しているが、根拠はない。
0122デフォルトの名無しさん
2005/04/26(火) 22:58:34static関数と非static関数の違いは理解してるつもり
staticメンバ関数はthisポインタがなく、引数、auto変数/定数を除くと
クラスのstatic変数/定数しか直接参照できない。
非staticメンバ関数は（暗黙の）thisポインタがあり、
上に加えてメンバ変数を参照できる。
Hoge myHoge; //と宣言すると
myHoge.foo(); // static関数と
myHoge.bar(); // 非static関数は同じ呼び出し方になる
0123デフォルトの名無しさん
2005/04/26(火) 23:02:03確かに、オブジェクトというのは微妙な言葉だな。
場合によってはクラスを表現するオブジェクトというものもあらわれる。
たとえば、Javaだと、クラス情報をランタイムに参照できるようにメモリ上にクラス情報を置いてくれる。これはつまり「クラス情報のオブジェクト（インスタンス）」といえる。
このランタイムクラス情報は、あくまでもクラスについての情報を保持する別のオブジェクトであって、クラスそのものではない。
というあたりが自分のもっているイメージ。
あと、
オブジェクト指向は、「分析」と「設計」で分けて語られる。
「分析」は対象領域を抽象的に分類、整理する手段としてのオブジェクト指向で、
「設計」は実際にプログラムに落とすためのオブジェクト指向。
どっちの話をしているのか意識しないとすぐ混乱する。
分析レベルだと、あんまりインスタンスという言葉は使われない。
設計レベルではやたらと増える。
そういう意味でもインスタンスは具体的なニュアンスを与える。
0124デフォルトの名無しさん
2005/04/26(火) 23:04:490125デフォルトの名無しさん
2005/04/26(火) 23:05:23static関数と非static関数が逆転してたす。
0126デフォルトの名無しさん
2005/04/26(火) 23:06:130127デフォルトの名無しさん
2005/04/26(火) 23:11:41＞クラスを表現するオブジェクト
GoF本に、“クラスオブジェクト”という用語がでてきます。
型情報を持ったオブジェクトと理解しています。
具体的には、WindowsのCOMコンポーネントがtypeライブラリ情報をもっているイメージ。
SmallTalkは私のプログラマ・センスでは理解できません。
＞「分析」と「設計」で分けて語られる
オブジェクトはアナリスト用語
クラスとインスタンスはプログラマ用語
と使い分けられるといいのに･･･
0128デフォルトの名無しさん
2005/04/26(火) 23:12:55要素の集まりが集合
しかし集合を要素とする集合も考える
ある集合の要素を作ろうとするなら
要素としての集合に対して操作をする
操作の対象はあくまで要素というわけ
0129デフォルトの名無しさん
2005/04/26(火) 23:14:34確かに
親子関係とは集合の包含関係のこと
集合とその要素との関係も親子関係と言ったのは間違い
0130デフォルトの名無しさん
2005/04/26(火) 23:21:28>metaclassのinstanceがclass
これは、C++のtemplateを理解しようとする時に出てくる概念の壁(^^)
template関連以外ではこういう言い方は成り立たないのでは？
というか、templateのパラメータとしてのクラスと
オブジェクトの型であるクラスを混同してしまい、
最後にはちゃぶ台をひっくり返すケースだと思いますけど
0131デフォルトの名無しさん
2005/04/26(火) 23:26:11instanceとはclassに所属しているobjectであることを強調したもの
0132デフォルトの名無しさん
2005/04/26(火) 23:42:19オブジェクト≡クラスのインスタンス
というのが、おおかたの書籍にでてくる理解で
インスタンス≡クラスのオブジェクト
という理解は、そもそも不要で混乱のもとだと思います
0133デフォルトの名無しさん
2005/04/26(火) 23:49:02なぜかね？
classによって産み出されるobjectのことをそのclassのinstanceと呼ぶのだが
つまりinstanceとはclassという概念に従属していることを強調する用語
0134デフォルトの名無しさん
2005/04/26(火) 23:50:54相撲流遠く (綴り、Smalltalkだっつーの)では
・クラス継承関係
・インスタンス関係
の他に
・メタクラス関係
があるのが興味深いんだ。
C++みたいな静的言語では、おもいっくそネグっちゃってるが、
JavaやC#では、リフレクションとかメタデータって名前で復活してる。
ちなみに相撲流遠くのクラス階層は、およそこんな感じ。
Object
△├－－－－－－－－┬－－－(略)
├｜－－－－－－－┐｜
｜↓instance ｜↓ instance
MetaClass Class
△ superclass △ superclass
｜ ｜
FooMetaClass ←－－ FooClass
metaclass ｜
｜instance
↓
aFooInstance
【Class変数/メソッド担当】【Instance変数/メソッド担当】
0135デフォルトの名無しさん
2005/04/26(火) 23:53:19OO広場 Happy Squeaking！の32ページ目あたり
http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/pdf/Squeak4.pdf
0137デフォルトの名無しさん
2005/04/27(水) 00:22:15MetaClassはFooMetaclassのclass（FooMetaclassはMetaClassのinstance）
FooClassはFooMetaclassのinstance（FooMetaclassはFooClassのclass）
ClassがFooMetaclassのsuperclass（FooClassはClassのinstanceとしての性格を継承）
0138デフォルトの名無しさん
2005/04/27(水) 00:36:12うろ覚えで書いちまった。(記憶力の減退か・・・)
正確な所は、
http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/img/metaHiera9.gif
見てね(はぁーと
相撲流遠くのクラス階層は
・メタ関係にあるオブジェクト(クラス)がインスタンスを生成する
というルールに基づいてる、と。
0139デフォルトの名無しさん
2005/04/27(水) 00:43:43もちろん、目指すゴールによって一概には言えないけど。
クラス使うと便利な面が多々あるし、
しらなきゃその恩恵を受けられないわけだし。
確か、ドラクエのモンスターを題材として
オブジェクト指向を説明しているいい本があったな。あれですぐ飲み込めた。
なんていう本かは忘れた。
0140デフォルトの名無しさん
2005/04/27(水) 00:46:12言語を使わない案というのは、原則について議論するということになるでしょうね。
おそらくはUMLを描くとか、そんな感じでしょうか。
私は、まずは言語を使って、何かできるようになるほうが断然いいと思いますね。
私にとってソフトウェア設計とは、数学みたいなものなんです。
読んだり聞いたりするだけでは、なかなか理解が深まりません。
実際にやってみないと理解なんかできません。
だから、本当にオブジェクト指向を理解したいのなら、実際に何かを作ってみるべきです。
0141デフォルトの名無しさん
2005/04/27(水) 08:44:480142デフォルトの名無しさん
2005/04/27(水) 19:25:420143デフォルトの名無しさん
2005/04/27(水) 19:28:45と
クラスインスタンスオブジェクト
は異なるわけか。
0144デフォルトの名無しさん
2005/04/28(木) 00:04:45（下手に訳すのがいけないのかも。）
0145デフォルトの名無しさん
2005/04/28(木) 00:08:580146デフォルトの名無しさん
2005/04/28(木) 00:32:03意味ワカンネ
0147デフォルトの名無しさん
2005/04/28(木) 08:56:430148デフォルトの名無しさん
2005/04/28(木) 08:58:19その二つはなに？
0149デフォルトの名無しさん
2005/04/28(木) 10:21:03何気にRPGとかだとクラスの有効利用をカンタンに理解できそうなきガス
0150デフォルトの名無しさん
2005/04/28(木) 11:24:27> クラスオブジェクトインスタンス
new Point(1,2)
> クラスインスタンスオブジェクト
Point
かな？
0151デフォルトの名無しさん
2005/04/28(木) 13:56:31それをどうプログラミングしていくかというところで、ぽかーん
という状態です。
0152OO太郎
2005/04/28(木) 15:22:59オブジェクト指向というのは、プログラミングのスタイルだ。JavaやC++は
オブジェクト指向言語だといわれるけど、非オブジェクト指向的な
プログラミングをしようと思ったら出来る。オブジェクトなんて使わなくても
同じように動くプログラムは作れる。
だから、プログラミングスタイルとしてオブジェクト指向をしっかり覚えないと
いつまでたってもオブジェクト指向のプログラミングは出来るようにならない。
俺みたいにBASICで育った者は特にそうだ。
0153OO太郎
2005/04/28(木) 15:40:00いまの、ウインドウズを中心としたいわゆるGUIのプログラミングに
ぴったりな概念だからだ。
オブジェクトはそれほど大騒ぎするほど難しい概念じゃない。巷に溢れる
説明の下手な著者の書いた本がくどくど説明するほど抽象的な概念
でもない。オブジェクト＝物だ。ウインドウズだったら、それぞれの
窓はオブジェクトだ。あるいは、窓の中にあるボタンの一つ一つが
全てオブジェクトだ。
トランプのゲームだったら、トランプの一枚一枚がオブジェクトだ。
クラスというのは、オブジェクトを作る型みたいなもの。トランプには
必ずマークと数字がある。そういう決まりをまとめたものがクラスだ。
トランプクラスからトランプの一枚一枚を作り出すと、それがオブジェクト
になる。例えば
Trampu tramp1 = new Trampu (ハート、A）；
Trampu tramp2 = new Trampu (ハート、２）；
・・・・・・・・・
Trampu tramp52 = new Trampu （クローバー、K）;
という感じにトランプオブジェクトが５２個作れる。それぞれが
トランプクラスのインスタンスになるわけだ。
0154OO太郎
2005/04/28(木) 15:52:20数というようなデータだけじゃなくて、いわゆるサブルーチンのような
機能（これがメソッドだ）も一まとめにしてしまうことが出来るってこと。
例えば、トランプゲームだったら、「持ち札」なんてクラスが定義できる
カも知れない。プレーヤーが4人いたら、それぞれ持ち札があるわけ
だから、持ち札１、持ち札２、持ち札３、持ち札４というような
オブジェクトが作れる。例えば「持ち札１」には、ハートの３、
スペードの４、クローバーのA、ダイヤの７がある。それはみんな
インスタンス変数になる。で、メソッドとして、「カードを引く」
「カードを捨てる」「カードの枚数を得る」「同じマークを捜す」
「同じ数を捜す」などなどいろいろなメソッドが考えられる。
それらを全てクラスで定義しておいて、実際に「持ち札１」にたいして
そういうメソッドを呼ぶことによって、「持ち札１」の内容を変更
したり、内容を見たりすることが出来る。
0155OO太郎
2005/04/28(木) 16:06:15なんて、クラス考えてもいいかもしれない。そこから作られる、
インスタンスとしての「カードの山」オブジェクトはインスタンス変数
として、カードの数、カードの種類などをもっていて。メソッドとして
は、「カードを出す」、「カードを切る」など考えられるかもしれない。
0156OO太郎
2005/04/28(木) 16:21:57ということだ。昔のプログラミングみたいに、一行目から始まって、
順々にコンパイラでもインタープリターでも読んでいって、順次実行
していく、いわゆる手続きがたのプログラミングとは違う。
プログラムは、キーボートや、マウスといった入力装置からの割り込み
あるいはメッセージを待っていて、マウスがクリックされたというと、
それを処理するルーチンがある、マウスがドラッグされた、というと
それを処理するルーチン、というように、そういう各々のイベント
処理を中心にプログラムが構築されていく。
で、そういう処理が、アル程度OSに任されてしまっているので、
プログラマーにはコントロールできない部分がある。例えば、描画
にしても、自分が、「描け」と命令するというよりも、絵を特定の
机の上に置いておくと、システムが定期的に来て、それを持っていって
画面に貼り付けてくれる、というようなイメージだ。絵を変化させ
たいばあいは、別の絵を描いといて、それをまた特定の机の
上に置いておいて、システムが持っていくのを待つ。
こういった思考パターンによるプログラム作りにがつまり、
オブジェクト指向のプログラミングということだろうと、
素人の俺は思うんだが。
0157131
2005/04/28(木) 16:22:19すいません、寝ちまいましたm(_ _)m
オブジェクト指向プラグミングする際に
1. まず、プログラミング対象を分析した結果としてオブジェクトを抽出する
2. 次に、オブジェクトの設計・実装の結果としてメンバ変数とメンバ関数による
オブジェクトの定義であるクラスを導出する
3. 最後に、プログラムの実行の結果としてクラスのインスタンスがメモリ上に
割り振られる
この場合、オブジェクトという用語に必要な概念は、
プログラミング対象を分析した結果としてオブジェクトという用語であって、
それ以外の、
インスタンス≡クラスのオブジェクト
の“オブジェクト”の用語の使い方は、 “一般概念としてのオブジェクト”という用語の適用を
オブジェクト指向プラグミングというコンテキストに持ち込むことになるからです。
つまり、オブジェクト指向プラグミングというコンテキストでの“オブジェクト”の用語の
因果関係、つまり順序性の意味を無視しているということです。
「色即是空・空即是色」という禅問答は、アカデミック（学術）的な思考の中では
成立するのかもしれませんが、エンジニアリング（技術）的な思考の中では、
「色即是空」であるか、さもなければ、「空即是色」のどちらかでなければ、
未知の技術に対する理解は混乱するだけなのです
0158OO太郎
2005/04/28(木) 17:04:55クラスに具体的なデータを与えて作ったインスタンスつまり
「具体例」がオブジェクトなんでしょ？
クラスは基本的に、オブジェクトを作るための枠組みであって、トランプ
でいったら、白紙でマークや数字が印刷される前の状態だと思う。
0159デフォルトの名無しさん
2005/04/28(木) 17:38:160160デフォルトの名無しさん
2005/04/28(木) 19:05:35こういうのってどうやってるんだろ・・・。
継承されまくりでどこにメソッドがあるのかもよくわからないし・・・。
0161デフォルトの名無しさん
2005/04/28(木) 19:40:53とりあえずdoxygen通してみるとか。
0162160
2005/04/28(木) 20:50:27なるほど、よさげですね。
ためしてみます。アドバイスありがとうm(_ _)m
0163デフォルトの名無しさん
2005/04/28(木) 21:09:51素人の説明って結局わからん、ってのはよくわかった、
0164デフォルトの名無しさん
2005/04/28(木) 21:29:38思い出しちまったよ。
OOトランプの役者としては、
・トランプの各カード
・カードの山
の他に、
・ゲーム (トランプがルール知ってる訳じゃなくて、ゲームにルールがある)
・プレイヤー (一人(占い等)または複数)
・ゲームの場 (占いの内容とか、ゲームが何回戦目かとか)
も要るな。
0165デフォルトの名無しさん
2005/04/28(木) 21:34:09そうかね？よく理解していると思ったが
>>158
Integerクラスのインスタンスが1,2,3などの整数
Integerクラスを任意の整数と捉えることも可能だが
任意の整数の全体と捉えることの方をおすすめしておこう
0166デフォルトの名無しさん
2005/04/28(木) 21:36:550167デフォルトの名無しさん
2005/04/28(木) 21:39:15結局 Smalltalkのクラス階層として結晶した概念を、
後付で説明しようともがいているだけだな。
>>165
＞Integerクラスのインスタンスが1,2,3などの整数
＞Integerクラスを任意の整数と捉えることも可能だが
＞任意の整数の全体と捉えることの方をおすすめしておこう
誰もそんな事、話題にしてないしｗ
0168デフォルトの名無しさん
2005/04/28(木) 22:04:12概念→実装ほどかけ離れてるもんはない。
0169デフォルトの名無しさん
2005/04/28(木) 22:06:37つう事。
概念
↓
実装
↓
実装を概念として騙ってる ←このスレ
0170デフォルトの名無しさん
2005/04/28(木) 22:26:45オブジェクト指向の風味がある偽物
偽物の腐った概念であれ>>152-の理解は正しい
0172デフォルトの名無しさん
2005/04/28(木) 22:36:47「整数」を「インスタンス」と置き換えてみよう。
二行目「クラスを任意のインスタンスと捉える」
というような荒唐無稽な話は、(>>165と>>171以外)誰も言っていない。
三行目「クラスはインスタンスの全体と捉える」
これは、クラスを集合と捉える考え方だね。
0173デフォルトの名無しさん
2005/04/28(木) 22:51:41オブジェクト指向の定義は千差万別人それぞれ。
俺はリフレクションさえあれば何でも良し。C++ 逝ってﾖｼ!!
http://www.shiro.dreamhost.com/scheme/trans/reesoo-j.html
0174デフォルトの名無しさん
2005/04/28(木) 22:56:20荒唐無稽と言うほどでもない
クラスの概念は集合と似ているが同じではない
集合を任意要素として表現することもあり
オブジェクトとクラスの関係を理解する一つの方法として
>>158の捉え方もあながち捨てたものではない
なお>>158をよく理解していると褒めてはいない
>>152-の例が例としてよくまとまっていると褒めた
0175チラシの裏
2005/04/28(木) 23:10:28ことがあるけど、オブジェクト指向のクラスも元々はそこからとった
言葉じゃないのかなと俺は思う。
0176デフォルトの名無しさん
2005/04/28(木) 23:30:05正しいかもしれないがたとえ集合論と関連させたものだったとしても似た用語を援用しただけであろう
なぜならば集合論におけるクラスは他のクラスの要素にならないからだ
Smalltalkのクラスはメタクラスのインスタンスでありその点が大いに異なる
また集合論では許されない無限降下列も存在している
MetaClassのメタクラスはMetaClassのインスタンスである
0177デフォルトの名無しさん
2005/04/29(金) 05:11:02２０分おきに連投ご苦労。で、結論出た？
セットとクラスの違い、
数学基礎論でいうクラスと、OO言語のクラスの違い
タイプ理論、
まで説明が終わったら、起こしてくれ。それまで一休みｗ
0178デフォルトの名無しさん
2005/04/29(金) 07:45:21結論とは何かね？
0179デフォルトの名無しさん
2005/04/29(金) 08:09:08忘れていた
あまりよい理解ではないが
インスタンス＝クラスのオブジェクト
で理解しても構わない
ここで言うオブジェクトももちろんオブジェクト指向言語におけるオブジェクト
すべてはオブジェクトでありクラスに従属していることを強調する場合はインスタンスという用語を使う
selfに入っているものはオブジェクトでありそれは何らかのクラスのインスタンス
0180デフォルトの名無しさん
2005/04/29(金) 08:21:05集合論ではすべては集合（無定義概念）
何らかの集合に所属している場合は要素と呼ぶ
さらに蛇足ながら
クラス概念のある集合論の場合
すべてはクラス（無定義概念）
何らかのクラスの要素である場合は集合
0181131
2005/04/29(金) 11:13:10慣用的に、"すべてはオブジェクト”という理解があることは承知しています。
ですが、157で述べたとおり、クラスを導出する“オブジェクト”という言葉と、
クラスから導出される“オブジェクト”という言葉は、その導出の順序性と
目的において異なる意味を持っています。
"すべてはオブジェクトである”とい論理は、じつは、ふたつの“オブジェクト”
という言葉が、それぞれ異なる意味を持った言葉でありながら、言葉の
形式的音韻的な同一性に拠ってのみ成立している論理だと思うのです。
そして、このような“オブジェクト”という技術用語の本来の意味をあいまいな
方向に誘導する学術系の論理は、オブジェクト志向プログラミングへの理解
を初手から阻害している重要な原因の一つだと考えているのです。
0182デフォルトの名無しさん
2005/04/29(金) 11:15:25クラスの定義を説明する例として、「国連」が例示されることが多い。
すなわち、
o 国連のメンバーは国々であり、
o 国のメンバーは、例えば、日本国なら日本人だが、
x 日本人は国連のメンバーではない、
という説明がされる。
しかし、セットの観点からすれば
x 日本人の集合は、いくら日本人を加わえても、
日本人の集合であって、日本国にはならない。
つまり、「男」と「女」を使った例で言えば、「男」と「女」の集合を起点にして、
「個人 」あるいは「法人」というクラスを形成するためには、
タイプ（Ｎ－１）とタイプＮ の間には、「概念の飛躍（抽象化）」が起こっているのである。
概念の一般化は論理和ではない。
0183デフォルトの名無しさん
2005/04/29(金) 11:24:35そこに書かれた「二つのオブジェクト」とは
君の言うプログラム設計手法としての「クラスを導出するオブジェクト」と
書かれたプログラム・実際に動く際の「クラスに導出されるオブジェクト」という意味か？
そのような違いを念頭に書いたことはないし実際気にする必要があるとも思えない
0184デフォルトの名無しさん
2005/04/29(金) 11:43:2420世紀初頭、集合論を使って数学の基礎を再構築する試みが開始された。
数学基礎論の源流には、以下の３つの流派があった。
（１）論理主義 （ラッセルに代表される考え方）
（２）形式主義 （ヒルベルトに代表される考え方）
（３）直観主義 （ブラウワーに代表される考え方）
ラッセルの提示したや り方が「タイプ（type）理論」（the theory of types）である
（ラッセルの提示したタイプ理論は「分岐タイプ理論」と云うが、
ラムゼー（Ramsey F.P.）は、それを簡素化して、単純タイプ理論にした）。
ラッセルの導入したタイプ理論を要約すれば、以下の２点が主張 である。
（１）モノは、（以下に記述するように）いくつもの階層（＝型）から構成されている
（これを、 「高階」の構成という）。
タイプ０：個体｛ａ, ｂ, ｃ,...｝
タイプ１：個体の性質 ｆ(x) [つまり、「関数」]
タイプ２：個体の性質の性質 ｇ(ｆ(x))[ つまり、「関数の関数」のこと ]
：
タイプ（Ｎ－１）
タイプＮ
（２）代入規則：タイプＮの 関数は、タイプ（Ｎ－１）の対象を代入項とする。
したがって、「Ｗ∈Ｗ」（同じレベルの代入）は無意味となる（「タイプ理論」ではＷ∈｛Ｗ｝が正しい扱いとなる）。
ちなみに、Ｗ＝｛Ｗ｝が成立することもある。これを「不動点」という。
数学者たちが、モノを「高次に（高階に）構成された構築物」と観る原点が、ここにある。
モノは「無定義語」であって、「関係 （関数）」のなかで扱われるパラメータ（項）に過ぎない。
0185デフォルトの名無しさん
2005/04/29(金) 12:23:27そこでは通常はＷ∈ＷおよびＷ＝{Ｗ}なるものは拒否されている
揚げ足取りのつもりないが気になったので指摘させて頂くが
関数の関数を書く場合はg(f)(x)とした方がよいだろう
もっと正確には(g(f))(x)であろうか
g(f(x))は通常は関数の合成の意味を持たせているからだ
0186デフォルトの名無しさん
2005/04/29(金) 12:25:410187デフォルトの名無しさん
2005/04/29(金) 12:26:500188デフォルトの名無しさん
2005/04/29(金) 12:45:31じゃ素朴な集合論の話はここまでにして、
次は ZF公理に基づくプログラミングを騙ってくれ。
よろしく
0189デフォルトの名無しさん
2005/04/29(金) 13:10:50それはHaskellのことか？
0190デフォルトの名無しさん
2005/04/29(金) 13:20:08公理的集合論、例えばZF公理系に基づいて
オブジェクト指向を説明してくれる事と思う。
0191デフォルトの名無しさん
2005/04/29(金) 13:29:04ご期待には添いかねる
0192デフォルトの名無しさん
2005/04/29(金) 13:32:57なんだ、自分の頭で考える事ができる人かと思ったら、
受け売りをくどくど書いてるだけの人か。
つまんね
0193デフォルトの名無しさん
2005/04/29(金) 13:38:04無駄なことはしない
>>185を書いたのは>>184に紹介さえていることが現代的ではなかったことと記法が気になったことだ
特にそれ以上の意図はない
0194デフォルトの名無しさん
2005/04/29(金) 13:39:52その現代的でない理論でオブジェクト指向が成り立っているのか、
あるいは、もっと現代的な説明が可能なのか？
＞無駄なことはしない。
そのあたりをちゃんと説明しろってこと。
0195デフォルトの名無しさん
2005/04/29(金) 13:41:37以前から似ているが違うと書いているのだが？
0196デフォルトの名無しさん
2005/04/29(金) 13:44:41一番最初の説明として、有効だと考える。
で、おまいさんが現代的ではないとおっしゃるのだから、
じゃそれを現代的にして下さい、って事。
0197デフォルトの名無しさん
2005/04/29(金) 13:46:54ご期待には添いかねる
0198デフォルトの名無しさん
2005/04/29(金) 13:47:50MartinLofの型理論 なんつうのもあるな
0199デフォルトの名無しさん
2005/04/29(金) 14:00:110200デフォルトの名無しさん
2005/04/29(金) 14:02:44いちいちピラニアみたいに食いついてくるのが、
ちゃねらーですから。
0201デフォルトの名無しさん
2005/04/29(金) 14:04:30近寄ってこないと思うよｗ
0202デフォルトの名無しさん
2005/04/29(金) 14:08:300203デフォルトの名無しさん
2005/04/29(金) 14:12:44２ちゃねらー離れが加速するだけだと思うよｗ
0204デフォルトの名無しさん
2005/04/29(金) 14:18:06「他意はない」って言い訳しよ。
それでも突っ込まれて、ほとほと己の無力さ加減に絶望したら、
「期待には添いかねる」
とレスを返す事にしよう。
0205デフォルトの名無しさん
2005/04/29(金) 14:20:57ご期侍には添いかねる
0206デフォルトの名無しさん
2005/04/29(金) 14:33:39他意はない
0207デフォルトの名無しさん
2005/04/29(金) 14:35:20無駄なことはしない。
0208デフォルトの名無しさん
2005/04/29(金) 14:37:10似ているが違う
0209デフォルトの名無しさん
2005/04/29(金) 14:38:53ゆるゆる議論のほころびの一つに突っ込むと、
猛反発をしてくるの法則
0210デフォルトの名無しさん
2005/04/29(金) 14:41:05ちゃねらーですから。
0211デフォルトの名無しさん
2005/04/29(金) 17:24:52<-Dog
<-Cat
こんな継承することは現実のプログラミングの現場ではありえない
実装してみて、インターフェースが共通化できそうなら継承木をつくるのであって
概念としてひとくくりにできるから継承やってると泥沼にはまる
だいたいそれでうまくいくんならデザインパターンなんていらないわけで
オブジェクト指向は手段、言語や実装無しに概念としての価値はあまりない
0212デフォルトの名無しさん
2005/04/29(金) 17:39:37>>123
0213211
2005/04/29(金) 17:43:08> <-Dog
> <-Cat
>
> こんな継承することは現実のプログラミングの現場ではありえない
補足します
ゲームやシミュレーションの世界ではこういう書き方もするが、
言語自体の記述力の限界もあって、
概念をそのまま記述することにとらわれると足かせになりがち
煮え切らない文章すまそ
0215デフォルトの名無しさん
2005/04/29(金) 18:14:57どっかで似たような話を聞いたな。
このスレでも>>157がそういうようなことを言っているけど。
0217131
2005/04/29(金) 18:28:36C++は静的なオブジェクト指向プログラミングを実現する仕組みで
コンパイラでできること仕組みの多くを実現している一方の究極。
動的なオブジェクト指向プログラミングを実現する仕組みの究極は、
Perlだと思う。型変換も実行時に簡単にできるし、同一ベースクラスの
サブクラスの多重継承を（現状がいいかは別問題として）矛盾なく
サポートできる。どちらも、静的なコンパイラ言語であるC++では困難
Smalltalkは理解不能ゆえ、私には論評できません。
0218デフォルトの名無しさん
2005/04/29(金) 18:32:16詳しく
0219デフォルトの名無しさん
2005/04/29(金) 18:33:03> Animal
> <-Dog
> <-Cat
これ見て
>これはPROTOTYPEパターンだね
とは、あんたエスパーかｗ
まず "<-"演算子の意味を定義しろってｗ
0220デフォルトの名無しさん
2005/04/29(金) 18:33:40T型ERからの引用だな。
0221デフォルトの名無しさん
2005/04/29(金) 18:35:19俺も最初、
Class Animal {}
Class Dog extends Animal {}
Class Cat extends Animal {}
て話かと思った。
Cat extends Dog {}
なんてｱﾌｫな話題を誰が持ち込んだんだｗ
0222デフォルトの名無しさん
2005/04/29(金) 18:35:500223デフォルトの名無しさん
2005/04/29(金) 18:36:38佐藤さんだけじゃなくて、
外国の超大物も書いてるみたいだよ、このスレ。
0224デフォルトの名無しさん
2005/04/29(金) 18:38:32彼も日本語が上手くなったなぁ
0225デフォルトの名無しさん
2005/04/29(金) 18:40:32で、現代的な型理論と
公理的集合論の話の続きは？
0226デフォルトの名無しさん
2005/04/29(金) 18:47:450227デフォルトの名無しさん
2005/04/29(金) 19:42:32無断借用じゃないの。
0228デフォルトの名無しさん
2005/04/29(金) 21:13:25にゃんって鳴く犬が猫なんだよｗ
0229デフォルトの名無しさん
2005/04/29(金) 21:30:01デザインパターンなんていらないんじゃないの？
0230デフォルトの名無しさん
2005/04/29(金) 22:04:49再利用とかメンテとかがいらなければ、いらないねっ。
0231デフォルトの名無しさん
2005/04/29(金) 22:06:311 名前： デフォルトの名無しさん 投稿日： 04/01/10 14:56
VisualBasicやCといった手続き型言語をずっとやってきた人が、
C#やJavaといったオブジェクト指向言語をマスターする場合
オブジェクト指向の概念・概論を学ぶのが先がいいのか、
それとも、C#やJavaの言語を学ぶのが先がいいのか、
どっちがいいと思われますか。
0232デフォルトの名無しさん
2005/04/29(金) 22:10:01C#やJavaでオブジェクト指向プログラミングしなくても
ぜんぜんに構わない
オブジェクト指向プログラミングにC#やJavaを使わなくても
ぜんぜん構わない
0233デフォルトの名無しさん
2005/04/30(土) 00:00:14非OO言語でOOするのはストレスたまりまくりんぐ
0234デフォルトの名無しさん
2005/04/30(土) 00:07:05>ストラ先生は、オブジェクト＝クラスという意味で使っているみたい
って誤読だろ？明らかに
0235デフォルトの名無しさん
2005/04/30(土) 00:48:24完全に誤読だよな。
0236デフォルトの名無しさん
2005/04/30(土) 01:00:16初心者は日本語で言うところの「物」を創造してしまい
「動作・ふるまい」を物とは考えることが出来なくなる
物ありきで、その物に対して「動作・ふるまい」をメソッドとして実装することしか頭に浮かばなくなる
0237デフォルトの名無しさん
2005/04/30(土) 01:16:12ものすごく、めんどくさい。
0238デフォルトの名無しさん
2005/04/30(土) 01:18:15パラディンクラスはナイトクラスを継承します
新たに技を追加できます
オーバーライドすることで既存の技を強化することも可能です
0239デフォルトの名無しさん
2005/04/30(土) 02:12:37>オブジェクトはキャラクターです
この時点で>>236の言っていることそのままじゃん
0240デフォルトの名無しさん
2005/04/30(土) 02:17:25とか？
0241デフォルトの名無しさん
2005/04/30(土) 02:29:04はどう？
0242デフォルトの名無しさん
2005/04/30(土) 02:44:27コンストラクタがごごごと動いて
どうも、オブジェクトです、
クラスのインスタンスです、ご用件をどうぞ
free(); または、もしもし五味屋さんはやくきてよ
のような、認識。
今年中によむ、本(予定)。
* 結城本
* エッケルのThinking in Java
* GOF本
0243デフォルトの名無しさん
2005/04/30(土) 02:57:57マトモに設計されたライブラリなら一部を覚えればあとは類推で何とかなると思うが。
0244デフォルトの名無しさん
2005/04/30(土) 04:27:330245デフォルトの名無しさん
2005/04/30(土) 04:32:08> 分析レベルだと、あんまりインスタンスという言葉は使われない。
おいおい、ユースケースのをインスタンス、とか言うだろ？
使われないのはオブジェクトという意味の「クラスインスタンス」だろ？
0246デフォルトの名無しさん
2005/04/30(土) 11:29:380247デフォルトの名無しさん
2005/04/30(土) 12:41:430248デフォルトの名無しさん
2005/04/30(土) 13:23:24「そういう仕様」だと思うよ、
現実を表現しやすく、管理しやすい仕様ではあるが
現実に無理して当てはめてわかった気になっても
習熟していくと騙されたと気づくんじゃないかな？
0249デフォルトの名無しさん
2005/04/30(土) 13:32:57用意周到なクラスライブラリを理解していくに連れて
なるほどという気持ちになる
あでもそういう汎用クラスライブラリを作る側は大変だろうな
習熟して騙された気になるってそういうレベル？
0250デフォルトの名無しさん
2005/04/30(土) 13:47:11あーこういう組み方するのか～うまいね～ってな感じ
しかし、それほどデザインパーﾀﾝに執着は無い
クラスの関係図を書くと何階層にもなってしまうので
新規作成時はいいんだけど、後から入ってきた人が
もしそれほど知識無いとしたら修正お願いしてもわかりませんので
0251デフォルトの名無しさん
2005/04/30(土) 15:43:55デザインパターンは現実の構造を示してるんじゃなくて、
工学的な定石に名前をつけたもんでしょ
現実ってリアルワールドね
0252デフォルトの名無しさん
2005/04/30(土) 15:46:52いいたいんですよ
0253さかな ◆xT/ZtgSAnQ
2005/04/30(土) 15:55:55理解を助けるための方便として言ってる場合だけじゃなく
自分も本気で信じてる場合もあるから
たちが悪い。
0254デフォルトの名無しさん
2005/04/30(土) 16:05:050255デフォルトの名無しさん
2005/04/30(土) 17:22:36自分で実際にそれらを作ってみると、設計の妥当性/妥協点がわかる、という事実がある。
もちろん、自分でそーゆーのを作れない泡沫エンジニアへのセールスポイントや使いやすさ
も提供するわけだがｗ
大枠や細かな所は、「現実的な作りやすさ」で決まってくるもんなんだよね。
だから、ｵｰﾌﾟﾝソースで自分で中見て改善する練習をする事が重要なんだ。。。
Smalltalkしかり、Linuxしかり
0256デフォルトの名無しさん
2005/04/30(土) 18:00:34ナビ開発をやっているんだけど、現行の手続きOnlyなやり方だと分り難くないかな。
0257デフォルトの名無しさん
2005/04/30(土) 18:10:45new封印で使ってる
0258デフォルトの名無しさん
2005/04/30(土) 18:52:270259池沼くんのレス
2005/04/30(土) 18:55:05まぁ、オブジェクト指向隆盛の現在、
Viewを客受けの良いものにchangeしたのは正しい決断だな。
0260デフォルトの名無しさん
2005/05/01(日) 07:24:28shout << なわけねーだろ！
にしなかったんだろ…
0261デフォルトの名無しさん
2005/05/01(日) 21:17:220262デフォルトの名無しさん
2005/05/01(日) 21:38:530263デフォルトの名無しさん
2005/05/06(金) 20:50:37orz┤
0264デフォルトの名無しさん
2005/05/07(土) 02:13:090265デフォルトの名無しさん
2005/05/08(日) 12:32:010266デフォルトの名無しさん
2005/05/11(水) 00:24:460267デフォルトの名無しさん
2005/05/11(水) 00:27:540268デフォルトの名無しさん
2005/05/11(水) 02:36:01orz=3=3=3=3 ﾌﾞﾌﾞｯﾌﾞﾘﾌﾞﾘﾋﾞﾁﾋﾞﾁﾌﾞﾌﾞﾌﾞ
0269デフォルトの名無しさん
2005/05/15(日) 11:01:520270デフォルトの名無しさん
2005/05/15(日) 11:26:23型付きの手続き型言語の理論としては、
型付λ計算が広く受け入れられている。
ただし、オブジェクト指向言語では
「オブジェクト指向」の本質といったものを明確にするのは難しいので、
広く受け入れられた理論というのは、まだない。
0271デフォルトの名無しさん
2005/05/15(日) 15:14:43趣味程度で自分しか使わないコードを書く人間としては、
ついというか癖でだらだらと関数を山ほどForm1のなかに書いてしまうのですが…
0272デフォルトの名無しさん
2005/05/15(日) 17:59:100273デフォルトの名無しさん
2005/05/15(日) 19:43:17いくら使い捨てコードといっても、一発で動いて後は永遠にメンテ不要なんてケースはまずないわけで。
自分で書いたコード読んでイライラしない？
0274デフォルトの名無しさん
2005/05/15(日) 20:41:36>どういった単位でクラスを作っていけばいいんですか？
殴り書きでいいのだが、
見つけたオブジェクトを見つける
見つけたオブジェクトの単位でクラス図を書く
クラス図にメンバ変数を追加する
クラス間のメンバ関数を時系列にそってシーケンス図として書く
メンバ関数をクラス図に追加する
これらの手順を納得できるまで繰り返す
収まりがついたらコーデングする
動作としてはこうなんだが、
それぞれの段階で知識や経験が入り込む
0275デフォルトの名無しさん
2005/05/15(日) 20:42:51×見つけたオブジェクトを見つける
○オブジェクトを見つける
0276デフォルトの名無しさん
2005/05/15(日) 20:44:40どれだけの物を１つにまとめ、どれとどれを分けるかの判断は経験則
0277デフォルトの名無しさん
2005/05/15(日) 20:45:43コーダー乙。
分析レベルのOOを認識できてないあたりが、
机上の勉強だけの糞コーダ臭いな
0278デフォルトの名無しさん
2005/05/15(日) 20:52:390279デフォルトの名無しさん
2005/05/15(日) 20:53:24概念レベルのオブジェクトをいかに抽出し、
現実世界のモデルを作るか？
第二の山は、
ユーザ要求なり機能要求を、
分析レベルでいかに取り込んでいくか
第三の山は、
１で作った概念モデルと
２で作った機能要求モデルを
いかに整合させていくか
第四の山は、
１、２、３で作ったモデルの実装方法の検討。
ここらへんがアーキテクトの仕事。
このあたりまでやって、ようやく開発レベルのOOになる
もちろん、対象分野の開発に慣れていて、
なおかつ新しい設計をしないならば、
1～4は楽勝だけどな。実際はそれをOOに不慣れな人間がやる事が多いから、
下流の人は大変みたいだ。
機能分割とDB設計から割り出したクラス図を受け取って、あとはウォータフォールとかｗ
0280デフォルトの名無しさん
2005/05/15(日) 21:05:52＞どういった単位でクラスを作っていけばいいんですか？
趣味のプログラミングということで、基準がわからないのだが、仮に
1.開発技術のスキルアップ
2.設計～コーディングにおける作りやすさ
3.拡張のし易さ
あたりを基準に考えていこう。
1.に関しては、薄っぺらいOO開発プロセスの本を追っかけてみると、
UMLやオブジェクト指向分析設計の概観が得られて、勉強になると思う。
とりあえずの推薦図書は、
・ユースケース入門―ユーザマニュアルからプログラムを作る
http://www.amazon.co.jp/exec/obidos/ASIN/4894713772/
・ワークブック形式で学ぶ UMLオブジェクトモデリング
http://www.amazon.co.jp/exec/obidos/ASIN/4797320192/
0281デフォルトの名無しさん
2005/05/15(日) 22:08:24> わざわざ 『分析レベル』 と 『実装レベル』 を分けて考える
もし設計/実装レベルのみに着目してソフトウェア開発を行うと、
開発者の関心と努力は、実装可能な事/実装が難しい事に集中してしまい、
結果として下記のような問題が発生します。
(1) 本来の要求(やりたかった事)の実現が、
おざなりになったり、歪んだ形になってしまう事。
（結果として、ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ技術は素晴らしいが、
使う人にとっては判りにくい、使いにくいものになってしまいがちです）
(2) 拡張や機能追加に耐えないクラス設計になってしまう事。
（拡張や機能追加に耐えるしっかりした構造を持たせるには、
普遍的な概念モデルや、プログラム対象分野の知識体系に基づく、
抽象的なレイヤーが必要です。
この抽象的なレイヤーは、汎化クラス抽出の方法でもある程度得られますが、
ボトムアップに実装から抽出する方法では、充分な汎用性をえられません。）
(3) プラットフォームや実装技術と、コアなアルゴリズムの切り分けが不充分になる。
もし、実装技術やプラットフォームに基づいて、アプリケーションの設計を行ったら、
それは将来のOS/環境のバージョンアップ時に、大きな変更作業が必要になるでしょう。
OS/環境依存部、プログラム対象分野の知識体系、アプリケーション、を分けるには、
レイヤー・パターンが有効ですが、そのレイヤーを切り分けるためにも、
OO分析の作業が重要なのです。
他にも書くべき事があるのですが、とりあえずここで筆を置きます。
0282278
2005/05/15(日) 22:20:01＞もし設計/実装レベルのみに着目してソフトウェア開発を行うと、
いやいや、最終的に両方ともやらなければいけないのは分かっているんだけど、
ある程度のフィードバックが、実装レベルから分析レベルに伝播するから、
わざわざ分けずに一言で纏めちゃっても良いんじゃないかって言う勝手な話
0283デフォルトの名無しさん
2005/05/15(日) 22:31:16設計レベルで抽出され、実装に反映されるオブジェクトは、
かなり距離感がある
これが、二つのプロセスを分離している理由です。
もちろん、シェアウェアとか個人でプログラムを作成されている方の中には、
実装技術ベッタリで素晴らしいアプリを作成されている方も多いようですし、
貴方の信じる道を行けば良い、と思います。
0284278
2005/05/15(日) 22:50:32目的から作成するオブジェクトと、実装技術から発生させるオブジェクト……
……これらを最終的に一致させるように、今まで考えていたのですが、これじゃダメなんでしょうか
(ひとつになった最終形を眺めて、278 を考えていたです)
っていうか経験不足です
企業に入ってそこそこのプロジェクトに参加するようになったら、改めて考えてみますです
0285デフォルトの名無しさん
2005/05/15(日) 22:51:300286デフォルトの名無しさん
2005/05/16(月) 04:30:200287デフォルトの名無しさん
2005/05/16(月) 20:38:55>>284のような「設計方針」「心構え」で申し分ない。
0288デフォルトの名無しさん
2005/05/16(月) 20:41:57内容的には大きな差があるんだって。
＞＞分析モデルと設計モデルの間の深い溝。
俺はこの分野に入ってすぐ、気付いたけどなぁ～
0289デフォルトの名無しさん
2005/05/17(火) 08:50:540290デフォルトの名無しさん
2005/05/17(火) 08:58:47素人グラマーに意見するつもりはない。
0291デフォルトの名無しさん
2005/05/17(火) 09:00:14朝っぱらからこんな所でなにやってんの？
0292デフォルトの名無しさん
2005/05/17(火) 09:14:290293デフォルトの名無しさん
2005/05/17(火) 09:16:130294デフォルトの名無しさん
2005/05/17(火) 09:24:490295デフォルトの名無しさん
2005/05/17(火) 09:26:120296デフォルトの名無しさん
2005/05/17(火) 09:27:070297デフォルトの名無しさん
2005/05/17(火) 20:38:120298デフォルトの名無しさん
2005/05/18(水) 22:13:32そういう思考が肥満児クラスを産む、
なんてな。
0299デフォルトの名無しさん
2005/05/18(水) 23:29:45◇ 目指すべき分析モデルの形
分析モデルの作成方法については、多くの設計者や方法論者がさまざまな方法を主張しています。
ここでは詳細には述べませんが、例えば、
・ワード・カニンガム（Ward Cunningham）による「CRC分析法（ブレーンストーミング）」（注1）や
「名詞・動詞分析法」（注2）、
・ピーター・コード（Peter Coad）により『Java Modeling in Color with UML』（Prentice Hall刊）の中で紹介されている設計手法（注3）
などがあります。
注1: CRC分析法（ブレーンストーミング）
クラス（Class）、債務（Responsibility）、協調（Collaboration）に分けられたCRCカードを用いて分析していく方法です。
詳細は『Object Design: Roles, Responsibilities, and Collaborations』（Rebecca Wirfs-Brock／Alan McKean著、Addison-Wesley刊）
をご参照ください。
注2: 名詞・動詞分析法
ユースケースや用語集から、名詞、名詞句を探し出して、クラスの候補とし、動詞、動詞句を探し出して、メソッドの候補として作成していく方法。
注3: 『Java Modeling in Color with UML』（Prentice Hal刊）の中で紹介されている設計手法
4つのアーキタイプ、瞬間―時間間隔、役割、パーティ／場所／物、説明に分類し、色分けして、パターンに当てはめて分析していく方法。
特に分析モデルに限ったものではありませんが、最初のモデルを作成する場合の強力な手法となっています。
0300デフォルトの名無しさん
2005/05/18(水) 23:30:12設計モデルの段階における理想的なモデルとはどんなモデルでしょうか。設計段階のモデルに従って実装が行われ、
その結果システムが出来上がるわけなので、生産性が高く、保守性や拡張性が考慮されていなければなりません。
そのうえで、実装担当者にとって理解しやすいモデルが「良い設計モデル」ということになります。
最近のアジャイル系開発プロセスでは、モデリングを分析段階と設計段階に分けず、
モデリング＝設計（Design）と考えたり、XPのように、コーディング作業にモデリング作業を含んでしまうプロセスもありますが、
本稿では、分析と設計の考え方の違いを解説するために、あえて分析モデルと設計モデルを分けて表現しています。
0301デフォルトの名無しさん
2005/05/18(水) 23:57:530302デフォルトの名無しさん
2005/05/19(木) 00:11:290303デフォルトの名無しさん
2005/05/19(木) 00:12:390304デフォルトの名無しさん
2005/05/19(木) 08:27:550305デフォルトの名無しさん
2005/05/19(木) 08:37:57匿名掲示板で数文字でノウハウ聞き出そうとするアンタは、ギブアンドテイクつう言葉がわからんヒッキーだろ
0306デフォルトの名無しさん
2005/05/19(木) 17:18:03C# だと、オブジェクトの派生になるが C と同じような構造体が扱える
宣言は 『 struct Struct1 { ～ } 』 でインスタンス生成は 『 new Struct1() 』
それに対し、オブジェクトの宣言は 『 class Class1 { ～ } 』 でインスタンス生成は 『 new Class1() 』 なんだけど、
これ、宣言が 『 object Object1 { ～ } 』 の方が分かりやすくないか？って電波だ。
struct の宣言では、定義してあるのが 『構造体』 で、作成されるのが 『構造体のインスタンス＝構造体』 だからまあ良い。
だけど class の下りは、定義してあるのが 『クラス』 で、作成されるのが 『クラスのインスタンス＝オブジェクト』 だから
定義された物と作成される物が異なっていて気持ち悪いかもしれないと言うこと。
異なっていて気持ち悪いのならば、いっそのこと 『 object Object1 { ～ } 』 にしてしまえば……ってコトです。
もちろん、object の宣言を行っていても 『これはクラス Class1 のインスタンス』 という表現は行える筈。
クラスって言葉は、『部門』 とかの分類を表す意味があるから。レベルとかと同じ意味で。
C# では、構造体のインスタンスもオブジェクトと言っているから、まあ気にし過ぎかもしれないけど、
C から入った俺は、なんとなく 『構造体の定義から生まれたモノ＝構造体』 にしたくて。
……って、なんとなくクラスとインスタンスの区別がついてないっぽいな。すまぬ。
0307デフォルトの名無しさん
2005/05/19(木) 19:30:00シンタックス・シュガー作っても本質は変わらない。
クラスと構造体を同一視するのなら、サルもミジンコも同じ。
クラスとオブジェクトの違いもわからずに、
そんなに細かいところをあれこれ弄る必要ナッシング。
0308デフォルトの名無しさん
2005/05/19(木) 21:41:58実際に作成する時作成されるのは構造体
この違いがクラスとオブジェクトの違い
0309デフォルトの名無しさん
2005/05/19(木) 21:44:36オブジェクトの構造・仕組みという抽象的なもので
コード上は現れないようにしても問題ないだろうよ
0310デフォルトの名無しさん
2005/05/19(木) 21:47:540311デフォルトの名無しさん
2005/05/20(金) 06:01:04そういう道を進んでいる言語もある。
プロトタイプベースと呼ばれているようだが。
0312デフォルトの名無しさん
2005/05/20(金) 09:11:170313デフォルトの名無しさん
2005/05/20(金) 09:43:14古臭い脳内知識で妄想勝利するしかやる事がないんだな
プロトタイプベース言語が提供する
インスタンスに対する属性/メソッドの付加は、
Composit, Decoration, Delegation, Factoryあたりで実現できる。
プロトタイプベース言語は、それらの機能を言語仕様に取り込んでいるだけｗ
0314デフォルトの名無しさん
2005/05/20(金) 09:45:580315デフォルトの名無しさん
2005/05/20(金) 10:59:30メタ関係上位にあるオブジェクト(クラス)に、オブジェクト生成や継承の仕組みを任せて、
メタ関係下位にあるオブジェクト(インスタンス)の内部実装の簡略化を図ったもの
プロトタイプベース＝全てのオブジェクトに、オブジェクト生成や継承の仕組みを提供するもの。
概念は単純になるが、言語実装技術やﾌﾟﾛｸﾞﾗﾐﾝｸﾞ技術のハードルは高くなる。
(静的型付けやLiskov置換則による安全性を、言語レベルで提供しにくくなる)
概念学習への初期投資を惜しむような人間が、プロトタイプベースを選択するのはナンセンス。
プログラム書かない人が見栄知識でアレコレ言うだけなら、チラシの裏に書いてろ。
0316デフォルトの名無しさん
2005/05/20(金) 18:25:30いい比較だと思うが、それだとクラスがファーストクラスな存在に読めるかも。
0317デフォルトの名無しさん
2005/05/20(金) 18:35:42Smalltalkでクラス・ベースのオブジェクト指向が確立した後で、
あらためて Self等でプロトタイプ・ベースのオブジェクト指向言語が研究されたのだから、
クラス-オブジェクト関係 (メタ関係 あるいは インスタンス関係)
の方が広く受け入れられてる概念だと思うよ。
Abadi & Cardellaの本もまずクラスベース言語、次にオブジェクトベース言語という展開だし。
0318デフォルトの名無しさん
2005/05/20(金) 18:40:05Smalltalk等、クラスをファーストクラスなオブジェクトとして扱うのが第一世代、
CLOS等、手続き型の延長線上にクラスレスなOOを定義したのが第二世代、
C++等、クラスをオブジェクトが共有する構造体として扱うのは邪道な第三世代、
Java等、クラスをリフレクション等駆使して、実行時に参照可能なオブジェクトとして扱えるようにしたのが第四世代
だよん。（てきとー
0319いやん
2005/05/20(金) 18:40:570320デフォルトの名無しさん
2005/05/20(金) 18:43:460321デフォルトの名無しさん
2005/05/20(金) 19:08:23プログラム書かない人が見栄知識でアレコレ言うだけなら、チラシの裏に書いてろ。
0322デフォルトの名無しさん
2005/05/20(金) 19:29:240323デフォルトの名無しさん
2005/05/20(金) 21:19:080324デフォルトの名無しさん
2005/05/20(金) 21:22:430325306
2005/05/21(土) 14:42:19クラスベースについて疑問を思っているんじゃなくて、ただ単に 『表記法』 について疑問に思っただけだったんだけどな
クラスベースとかインスタンスベースとか、正直どうだって良いんだけど
>>308
＞structで定義しているのは構造体の構造
同様に、class で定義しているのはオブジェクトの構造つまりクラス
それは分かる。struct および class が 『定義そのもの』 を指すのか 『定義した生成物』 を指すのかの違いのような。
気分的には、生成物を指したい
0326デフォルトの名無しさん
2005/05/21(土) 14:46:280327デフォルトの名無しさん
2005/05/21(土) 14:51:430328デフォルトの名無しさん
2005/05/21(土) 15:03:52君が誤解している(もしくは不完全な理解をしている)のは、
クラスやオブジェクト等のＯＯの概念ではなくて、型という概念だ。
Cardelliでも読んで、型とは何か、型を宣言するとはどういうことか、
じっくり考えてみたらいい。
0329306
2005/05/21(土) 15:05:19んじゃ書き直す
======
C# の表記法について、
class では 『定義そのもの』 を指していることは明確であるが、
struct は 『定義そのもの』 と 『定義によって生み出される生産物』 の、どちらを指すのか分かり難いと俺は思う
言いたい事はこれだけ
======
>>307
C# ではクラスと構造体が同一になっちゃってるから困っているんです
>>308
構造体の構造を定義するのならば、キーワードは 『struct_struct』 であるべきという気もします
『struct』 単体ならば、それは 『定義に代って生み出される生産物』 を指すのでは？
0330デフォルトの名無しさん
2005/05/21(土) 15:12:330331306
2005/05/21(土) 15:12:37了解……出来るように頑張ります
Pascal の 『レコード型』 とか、C の 『構造体型』 とかと同じように考えると、class では 『クラス型』 を定義している筈。
しかし生成物の方は 『レコード型のレコード』 『構造体型の構造体』 とは異なり 『クラス型のインスタンス』 だから、
前２者に揃える場合、これを 『オブジェクト型のオブジェクト』 にしたほうが簡潔ではないかと思いまして。
0332デフォルトの名無しさん
2005/05/21(土) 15:13:00正解
0333デフォルトの名無しさん
2005/05/21(土) 15:31:29「ドーナツ」という単語が付いていると、あたかも「ドーナツ」が存在しているかのように感じる。
だから、「穴の穴」というのが正しいぃぃぃぃーーーーーーーーーーーーーー
0334デフォルトの名無しさん
2005/05/21(土) 15:33:180335デフォルトの名無しさん
2005/05/21(土) 15:35:15実体は単なる人なのに、
単語に「間」という漢字がついているのが、直感に反する。
これからは、「人間」という単語を使うのはやめよう
0336デフォルトの名無しさん
2005/05/21(土) 15:49:42スレ違い。こっち行け
ドーナッツの穴は空洞か存在か？
http://academy3.2ch.net/test/read.cgi/philo/1049436081/l50
0337デフォルトの名無しさん
2005/05/22(日) 08:11:20そのobjectってVBでいうところのモジュールだよな？
classと違うだろ。
0338デフォルトの名無しさん
2005/05/24(火) 06:19:22んでその構造を持つ変数を同時に生成することもできると
0339デフォルトの名無しさん
2005/05/24(火) 09:52:10PascalやCのほうを『レコード型のオブジェクト』、『構造体型のオブジェク
ト』って思ってみては？
オブジェクトとインスタンスは、まぁ、同義ということで。
0340306
2005/05/24(火) 17:24:00こんな馬鹿をやったのは久しぶりだ。今は後悔している OTL
【正しいこと】
・C# の 《クラス》 には 『クラス』 『インタフェイス』 『構造体』 の３種類が存在する
・『インタフェイス』 と 『構造体』 は、Object クラスを継承している
【俺が間違っていたこと】
・《クラス》 と 『クラス』 を混同し、宣言時のキーワード 「class」 が主に 《クラス》 を指す物と考えてしまった
・『クラス←構造体』 に代表される 「言語系外での継承」 が、一般の継承と完全に同じであると信じて疑わなかった
その結果、俺は 「class」 と 「struct」 が同一レベルの概念ではないと錯覚した
そして、「class」 と 「struct」 のレベルを同じにしようと思い、「class」 を 《クラス》 から 『クラス』 にするために
「《クラス》 には 『オブジェクト』 『インタフェイス』 『構造体』 の３種類が存在する、と言い換えたらどうか」
と提案した (>>306)
(実際は 「class」 は 『クラス』 であり、単なる言葉遊びだった orz)
0341最凶VB厨房
2005/05/25(水) 00:25:55【正しいこと】に書いてある内容が正しくない。
0342デフォルトの名無しさん
2005/05/25(水) 00:36:00つまり言語学習を先にするべき。
0343306
2005/05/25(水) 13:28:06悪い。相変わらず間違えてたみたい。
=====
「C# の 《クラス》 には 『クラス』 『インタフェイス』 『構造体』 の３種類が存在する」 ってのは、
「Java の 《クラス》 には 『クラス』 『インタフェイス』 の２種類が存在する」 っていうどっかの本の台詞のパクリだった
この 《クラス》 は、Smalltalk のメタクラスに該当するんかな。よく分からんけど
それはともかく、構造体はクラス階層の中に含まれているから、よく考えたらこの中に入れちゃいけないのかもしれない
=====
インタフェイスは対応するクラスが無いから、Object から派生しているとは言えないでした
(ただし、インタフェイスを実装したクラスのインスタンスは Object であることは確定なので、Object として扱える)
ここのところは訂正しておきます
0344306
2005/05/25(水) 13:38:42実質 「class StructA: System.Struct { ～ }」 なクラスを 「struct StructA { ～ }」 と記述させる C# において、
キーワード 「class」 と 「struct」 を同列に置くことが果たして妥当なのかどうか
つまり
System.Struct からの実際の継承は、神の領域において行われる (ソースとして記述できない) が、
神の領域において、結局はクラスである構造体が、クラスと同じレベルまで昇進しているのかどうか
……自分でも未だ混乱していることがありありと分かりますな
あとで Smalltalk でも勉強しよう……
0345最凶VB厨房
2005/05/25(水) 19:09:30実質～の部分が既に間違ってますがなｗ
MSDN読め
0346デフォルトの名無しさん
2005/05/25(水) 19:15:010347デフォルトの名無しさん
2005/05/25(水) 19:24:49解説
struct 型は、Point、Rectangle、Color などの軽量のオブジェクトを表すのに
適しています。点はクラスで表現できますが、一部の事例では構造体の方が
より効果的です。たとえば、1,000 個の Point オブジェクトから成る配列を
宣言する場合は、各オブジェクトの参照用に新たにメモリが割り当てられます。
この場合は、構造体を使用した方がリソースを使用しません。
構造体に対して既定の (パラメータなしの) コンストラクタを宣言するとエラー
になります。構造体メンバを既定値に初期化する既定のコンストラクタが常備
されています。
構造体のインスタンス フィールドを初期化するとエラーになります。
new 演算子を使用して struct オブジェクトを作成すると、オブジェクトが作成
されて適切なコンストラクタが呼び出されます。クラスとは異なり、構造体は
new 演算子を使用せずにインスタンスを作成できます。new を使用しなかった
場合、各フィールドは未割り当てのままになり、すべてのフィールドが初期化
されるまでオブジェクトを使用できません。
クラスには継承がありますが、構造体には継承がありません。構造体は、
他の構造体やクラスから継承できず、基本クラスになれません。
ただし、構造体は、基本クラス Object から継承します。
構造体は、クラスの場合とまったく同じ方法でインターフェイスを実装できます。
C++ とは異なり、キーワード struct を使用してクラスを宣言できません。
C# では、クラスと構造体は、意味が異なります。構造体は値型ですが、
クラスは参照型です。
値型の機能の詳細については、「値型」を参照してください。
0348306
2005/05/25(水) 21:23:41あ、もしかして struct って System.Struct の継承じゃない……のか？
でもインスタンスを作成しているわけじゃないし……なんなんだろう。
=====
それはともかく、え～っと……アロエリーナに聞いたらヒントを教えてくれました。
＞キーワード 「class」 と 「struct」 を同列に置くことが果たして妥当なのかどうか
「妥当じゃないです」
＞クラスである構造体が、クラスと同じレベルまで昇進しているのかどうか
「そんなわけないです。クラスと構造体は別物」
＞じゃあ、クラスと構造体はどうして同じような構文になっているの？
「それが利便性ってもんです」
……俺、この時点で納得しちゃって良い？
「クラス定義と構造体定義は別物だけど、分かりやすいように同じ構文になっている」 で OTL
0349デフォルトの名無しさん
2005/05/25(水) 21:38:250350306
2005/05/25(水) 21:43:54え～っと……ってことは、struct は実質 System.ValueType の継承……じゃなくて……
「struct で定義した構造体は、オブジェクト指向の世界からは System.ValueType を継承したオブジェクトのように見える」
……で良いんか？
0351デフォルトの名無しさん
2005/05/25(水) 21:53:050352デフォルトの名無しさん
2005/05/26(木) 00:49:270353デフォルトの名無しさん
2005/05/26(木) 08:53:23知識がないだけなら調べることで補えるが、
知識がないことに自覚がない上に無根拠な自信に満ち溢れて混乱した言葉を垂れ流すレベルになると
矯正はかなり困難。
0354デフォルトの名無しさん
2005/05/26(木) 08:57:330355デフォルトの名無しさん
2005/05/26(木) 08:59:580357デフォルトの名無しさん
2005/05/26(木) 16:05:10まあ、その問題は、エロ本によるオナニーがさきか、それとも
実戦のセックスが先か、みてーなもんだ。どっちにも固有の良さはある。
でも、いつまでもオナニーに留まってるわけにはいかない。
そーゆーもんだ。
0358デフォルトの名無しさん
2005/05/26(木) 19:11:11> VisualBasicやCといった手続き型言語をずっとやってきた人が、
> C#やJavaといったオブジェクト指向言語をマスターする場合
> オブジェクト指向の概念・概論を学ぶのが先がいいのか、
> それとも、C#やJavaの言語を学ぶのが先がいいのか、
> どっちがいいと思われますか。
1. オブジェクト指向の概念・概論を学ぶ
2. その概念を、ずっとやってきたVisualBasicやCで実現してみる
3. 次にC#やJavaの言語を学び、2でやっていたことが言語のprimitiveとして
存在することの良し悪しを考察する
4. VB5ってある意味オブジェクト指向の塊だよなあと感慨にふける
0359306
2005/05/26(木) 20:13:05おお、なんか世界の裏まで知り尽くしているっぽい発言ですな
恐れ入ります
で、結局 「C# の構造体」 って何者なんでしょね
0360306
2005/05/26(木) 20:22:49『使うだけ』 ならば仕様書を読めば事足りる
細部まで理解したいのならば、それだけじゃ全然足りない
……って素直に思った
最低だな俺 OTL
っていうかそれ以前に仕様書をマトモに読めよって OTL
どうする？ＮＧ登録したければコテ付けるけど、それとも 306 のままで良い？
0361デフォルトの名無しさん
2005/05/26(木) 20:24:400362306
2005/05/26(木) 20:27:33メモ帳にしちまって正直すまんかった OTL
もうちょっと精進できるよう頑張ってみるよ
0363デフォルトの名無しさん
2005/05/26(木) 20:31:57でも、>>360 にはとりあえず同意しておく
「全然足りない」ときに「自己流の解釈をする」ってのは方法として間違っていると思うが
0364306
2005/05/26(木) 21:37:10これ入れとけば
誰にも見つからないってわけか
3060でもいいのかな？
0365デフォルトの名無しさん
2005/05/26(木) 21:42:560x306＝774
0366デフォルトの名無しさん
2005/05/27(金) 00:31:070367デフォルトの名無しさん
2005/05/27(金) 00:33:080368偽306
2005/05/27(金) 05:32:30そしてその実例を言語学習で学ぶと概念が身に付く
車の両輪を右から作るか左から作るか悩むようなもので
あまり意味のある質問とは言えませんよ>>1
0369デフォルトの名無しさん
2005/05/27(金) 06:15:250370デフォルトの名無しさん
2005/05/27(金) 12:34:10◢░ ▄▀ ▀▄ ░◣ ▌▐▄▀ ▌▐▄▀
▐░:: ░▍
▐▓░:: ▄ ░▍
▐▓░░::░:: ▀▀▀▀▀▀▀▀ ░▓▍▅ ▅ ▄▄▄▄
▐▓▓░░░::░::: :::░::░▓▍ ▊ ▋
▐▓▓▓░░░::░::░::::: :: :: ::::░::░░░░░░▓▓▍ ▐▄▌
▀█▓▓▓░▓░░::░:::░:::::::░::░░░░░▓░▓▓▓▌ ▄▅▀
0371デフォルトの名無しさん
2005/05/27(金) 14:43:02おおー ヴィジュアル系！
0372デフォルトの名無しさん
2005/06/05(日) 21:47:37ポリモーフィズムは機能じゃないよね？
継承を利用したデザインパターンだと思うんだけど
識者の意見をお聞きしたい。
0373デフォルトの名無しさん
2005/06/05(日) 21:51:23・カプセル化はオブジェクト指向の機能ではない
・継承はオブジェクト指向の機能だが、必須ではない
・ポリモーフィズムには多数の種類がある。
貴方が遅延バインディングについて言いたいのだと推測すると、それはオブジェクト指向の機能
・遅延バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
0374デフォルトの名無しさん
2005/06/05(日) 21:52:280375デフォルトの名無しさん
2005/06/05(日) 22:05:53まぁ、じっくり騙ってくれ、その概念を
0376デフォルトの名無しさん
2005/06/05(日) 22:06:59それなんてエロゲ？
0377デフォルトの名無しさん
2005/06/05(日) 22:47:09◢░ ▄▀ ▀▄ ░◣ ▌▐▄▀ ▌▐▄▀
▐░:: ░▍
▐▓░:: ▄ ░▍
▐▓░░::░:: ▀▀▀▀▀▀▀▀ ░▓▍▅ ▅ ▄▄▄▄
▐▓▓░░░::░::: :::░::░▓▍ ▊ ▋
▐▓▓▓░░░::░::░::::: :: :: ::::░::░░░░░░▓▓▍ ▐▄▌
▀█▓▓▓░▓░░::░:::░:::::::░::░░░░░▓░▓▓▓▌ ▄▅▀
0378372
2005/06/05(日) 22:51:30遅延バインディングという概念は分かりませんが、
Javaで例えるとカプセル化の為にprivateという修飾子があり、
継承にはextendsという機能がありますよね？
でもポリモーフィズムには言語の機能としては何もなく
継承を利用したデザインパターン（ストラテジー？）じゃないかと
思うのです。
＞ポリモーフィズムには多数の種類がある。
これは詳しい解説キボンヌです。
0379デフォルトの名無しさん
2005/06/05(日) 23:18:50> でもポリモーフィズムには言語の機能としては何もなく
>>373はそれがlazy bindingだという話だろ？
0380373じゃないが
2005/06/05(日) 23:20:13> ＞ポリモーフィズムには多数の種類がある。
> これは詳しい解説キボンヌです。
adhoc polymorphism, inclusion polymorphism, parametric polymorphismの3つは
理解しておいたほうがいい。
0381デフォルトの名無しさん
2005/06/05(日) 23:53:07まぁ、じっくり騙ってくれよ
0382デフォルトの名無しさん
2005/06/06(月) 02:41:090383デフォルトの名無しさん
2005/06/06(月) 02:48:32本質的には、クラスという設計図をもとに、インスタンス（オブジェクト）を生成して使う仕組み。
カプセル化とかポリモーフィズムとかは、どちらかと言うとオマケ的な機能だ罠。
0384デフォルトの名無しさん
2005/06/06(月) 02:51:27・それだと、モジュール指向や抽象データ型とあまり区別がなくなるのでは？
0385382
2005/06/06(月) 02:59:55・対象をデータ構造に抽象化・カプセル化し、カプセル化されたデータの関数であるメソッドを持つ。
→データそのものであり、またデータを操作する主体である。
・抽象されたものの集合の内包⇔外延関係が、派生という方法によって積極的に表現されている。
ということではないかと思うんだけど。どうでしょう？
0386382
2005/06/06(月) 03:10:17確かにカプセル化はオブジェクト指向の本質ではないと思うんです。
しかし、ポリモーフィズムに関しては、例えば自然言語というのは、
「抽象されたものの集合の内包⇔外延関係(例：犬⇔コギー）」によって構成・表現されている。
その自然言語の構造を踏襲するならば、この関係を積極的に表現する
派生という方法をOOPが持つのは、極自然に感じます。
0387デフォルトの名無しさん
2005/06/06(月) 13:05:02adhoc: interfaceのimplements
inclusion: class, interfaceのextends
parametric: C++のtemplateか
0388デフォルトの名無しさん
2005/06/06(月) 14:12:43adhocはC++のfunction overloadingが典型例。
C++のtemplateはparametricとは言い切れない。型的に。
0389デフォルトの名無しさん
2005/06/06(月) 19:42:40「カプセル化されてないオブジェクト」って
有り得るの？想像付かない…
0390デフォルトの名無しさん
2005/06/06(月) 19:50:25とかじゃないか
0391デフォルトの名無しさん
2005/06/06(月) 20:02:25ブログラムもロクに書けない素人が平日昼間からシャシャリ出るな、と。
0392デフォルトの名無しさん
2005/06/06(月) 22:15:57adhoc polymorphismは、overloadingとcoersion (i.e. int < float)
inclusion polymorphismは、例えばinheritanceの事。
parametric polymorphismは・・・C++ templateがお気に召さないなら、OcamlかJava Genericsでどうよ。
上記二つをまとめて universal polymorphismと呼ぶ。
>>373
下記の発言は一体どういう文脈の話なのか、ちゃんと説明しろよ
> ・ポリモーフィズムには多数の種類がある。
> 貴方が遅延バインディングについて言いたいのだと推測すると、それはオブジェクト指向の機能
> ・遅延バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
0393デフォルトの名無しさん
2005/06/06(月) 22:17:09int number < float numberという比較演算子は、coersionとして実装される事が多い、と。
0394デフォルトの名無しさん
2005/06/08(水) 12:59:46>下記の発言は一体どういう文脈の話なのか、ちゃんと説明しろよ
>> ・ポリモーフィズムには多数の種類がある。
ん？ 「ポリモーフィズムは……」って聞かれたんでランタイムポリモーフィズムを想像したけど、
ランタイムじゃないポリモーフィズムももちろんあるって忠告したかっただけ
テンプレートだとかメソッドのオーバーロードだとか、#if ～ #endif でさえ 『ポリモーフィズム＝多様』 で括れるし
0395デフォルトの名無しさん
2005/06/08(水) 13:01:250396デフォルトの名無しさん
2005/06/09(木) 00:44:210397デフォルトの名無しさん
2005/06/09(木) 20:23:07自分が理解できないからって変人扱いすることは筋違いだとか、
そもそも勉強中の人を変人扱いすることは筋違いだとか思った
いや、俺もオーバーロードがポリモーフィズムの一種だと聞いたときには「ﾊｧ?」だったわけだが
0398392
2005/06/09(木) 21:14:58＞遅延バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
これをまともに解釈するのは無理ってもんじゃないか？(hahaha
0401373
2005/06/09(木) 21:20:38あたま超混乱してます現時点で。
……けど、「それを～」 以降を訂正する気は全く無い。
0402デフォルトの名無しさん
2005/06/09(木) 21:26:07＞動的バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
これもまともに解釈するのは無理じゃないか？(pupupu
0403373
2005/06/09(木) 21:27:36俺の頭か (^_^;
0404デフォルトの名無しさん
2005/06/09(木) 21:30:27勉強中の人が「～と理解しましたが、どうでしょう」と書くのは普通だが、
元々ろくすっぽ勉強する気もない荒らしが、掲示板で聞きかじった断片知識を
>>373のように書いてしまうのは、なかなか痛い行為だと思った。
0405373
2005/06/09(木) 21:35:540406373
2005/06/09(木) 21:56:430407デフォルトの名無しさん
2005/06/09(木) 22:02:27On Understanding Types, Data Abstraction, and Polymorphism
http://citeseer.ist.psu.edu/cardelli85understanding.html
0408デフォルトの名無しさん
2005/06/09(木) 22:07:45http://www.mamezou.com/tec/equip001.htm
0409デフォルトの名無しさん
2005/06/09(木) 23:29:59他の言語の文法は必要になったら覚えろ
オブジェクト指向でも構造化でも、3日後に自分で理解できるコード書いてくれればなんでもいいよ……
0410デフォルトの名無しさん
2005/06/09(木) 23:34:08程度の低いところにお勤めですな(w
経験上、今時Cだけ知っててC++を知らない人は、実はCを良く理解していない
ことが多い
Cのあの糞ったれな宣言シンタクスを難なく読みこなせる程度でないと、
C++は無理だな
0411デフォルトの名無しさん
2005/06/09(木) 23:41:55基本的に>>392と同じ。リファレンス [Cardelli & Wegner '85]って、もう20年も前の話か。
10年前のOOには、Genericsに代表されるような柔軟な型システムや
関数型言語(HOPE～SML, Haskell)の型推論とか
ほとんど取り入れられていなくて、知恵遅れの村に来た感じがして嫌だった。
普及型のOO言語は、ようやく20年前の水準に追いついたわけね。
0412411
2005/06/09(木) 23:48:07>>373 相変わらず概念と単語が混乱しているようだが、あんたが言いたかった前半は、
(>>372が「ポリモーフィズムはオブジェクト指向の機能ではないと言ったが)
Subtype polymorphiscm (継承による多態)は継承によるものである。
といったところか。で、後半部分
＞ それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
は相変わらず前半とつながんねぇな。
0413デフォルトの名無しさん
2005/06/10(金) 00:00:40単なるポリモーフィズムを「これはデザインパターンだ！」と言いたくは無い
って言いたかったんや……
0414デフォルトの名無しさん
2005/06/10(金) 00:02:020415デフォルトの名無しさん
2005/06/10(金) 00:03:230416デフォルトの名無しさん
2005/06/10(金) 00:07:20上でさんざんあんたがやってきたように、相変わらず単語や概念が無茶苦茶なまま理解して、
それを匿名掲示板に書き殴ってるだけじゃねぇの？
0417373
2005/06/10(金) 00:12:59＞「単なるポリモーフィズムを、デザインパターンだ！」と主張するような奴は、普通の所には居ない
俺は 372 がこのことを主張したいように感じ取った。そして↑と同じ考えを書きなぐった。
ただそれだけなんだ…… orz
0418デフォルトの名無しさん
2005/06/10(金) 00:30:40そうか……端から見ればそう見えるのか。っていうか８年も Java の本めくってて何も身についてないですか orz
市にてぇ……
0419デフォルトの名無しさん
2005/06/10(金) 00:44:21概念にかんしてはオブジェクト指向の概念というより
もっと一般的なことを認識してほしい
0420デフォルトの名無しさん
2005/06/10(金) 09:27:48確かに元の質問>>372は得体が知れないな。
Garbage In , Garbage Out の典型だな
0421デフォルトの名無しさん
2005/06/11(土) 16:03:50やはりC++はやったほうがよいでしょうかね？
C#できればいらない？
0422デフォルトの名無しさん
2005/06/11(土) 16:07:24CとC#とjavaができるならC++の習得も(たぶん)容易だからやっとけば？
templateの強力さに感動せよ。
0423デフォルトの名無しさん
2005/06/11(土) 16:22:02必要になったときで間に合うと思う
簡単なサンプルコードがC++で書いてあっても
ならJavaとC#ができれば概略はつかめるし
>>422
templateの真髄に突っ込むと火傷するよ…… 感動するのは同意
0424デフォルトの名無しさん
2005/06/11(土) 20:34:54つうか、templeteのエラーメッセージの難解さに挫折すんなよ
いまや、C++は標準ライブラリでtempleteつかってからな
0425デフォルトの名無しさん
2005/06/12(日) 03:09:33相手にするだけ時間の無駄。つうか大抵自作自演でスレの話題を断ち切るだけの荒らし。
0426デフォルトの名無しさん
2005/12/23(金) 17:47:390427デフォルトの名無しさん
2006/01/13(金) 18:55:39レベル高すぎなの
頭パンパンなの
0428デフォルトの名無しさん
2006/01/15(日) 20:46:33C++使ってるくせにC以下のプログラム多すぎ
0429デフォルトの名無しさん
2006/01/17(火) 03:19:50すまん。ホントスマン。
実は、あんまりCも分かってないんで、勘弁してくれ、
できればお勧めのCとC++の参考書を教えてくれ。
0430デフォルトの名無しさん
2006/01/17(火) 04:37:46野球選手に体力と技術どっちが先に必要かって言ってるようなもんだ。
0431デフォルトの名無しさん
2006/01/17(火) 06:00:40ちゃんとしたプログラマのコードは英文として読めるけど
英語がダメなやつのコードは分けわかんねえ
0432デフォルトの名無しさん
2006/01/17(火) 11:00:090433デフォルトの名無しさん
2006/01/17(火) 14:03:31自分の理解能力を超えてやっても頭に入らない
これは学習スピードなども含んでいる
少しずつでも良いので理解を進めていけ
仕事で即時性を求められているなら理解しないでも作業を遂行できる能力を身に付けろ
0434デフォルトの名無しさん
2006/01/17(火) 14:23:470435デフォルトの名無しさん
2006/01/17(火) 18:58:49その「もの」指向をどのように実現するかを言語を通して学ぶ。
概念が解っていなければ本当の意味で良い物は作れないし、
作るためには言語を理解していなければならない。
どっちが先ってもんでもないと思うが・・・。
これにて終了でどうでしょう。
0436マイク ◆yrBrqfF1Ew
2006/01/17(火) 19:16:34馬鹿万能崇拝者がいるけど、あんなの本末転倒ですよ;)
0437デフォルトの名無しさん
2006/01/17(火) 21:23:09今そんなこと話してないし
0438デフォルトの名無しさん
2006/01/17(火) 21:40:450439デフォルトの名無しさん
2006/01/18(水) 03:23:23そこまでは言わないにしても、言語を使いながら学習していく場合には
適さないと思います＜C++
もっと素直で筋のよさそうな言語から始めるのがよいかと。
本命はやはりSmalltalkなんですかねぇ、でも今だとOOをサポートした
スクリプト言語を使うのがよさそうな気がします。
スクリプトなら余計なお約束はほとんど考えずにちょっと書いて
ちょっと試すことができるし、静的型が無い場合が多いと思うので
必然的にC++のvirtualみたいな歪んだものを扱わなくてよいし。
0440デフォルトの名無しさん
2006/01/18(水) 13:00:31オブジェクト指向系のスクリプト言語はちょっとした試行を行う際には良いが
システムの構築と言った要件には使うべきではない
0441デフォルトの名無しさん
2006/01/18(水) 15:10:03不適とする理由は？
0442439
2006/01/18(水) 16:05:31あくまで学習目的のつもりで書きました。
そういう用途であれば素直に書ける言語が良いかなぁと。
規模が大きくなった場合にどうなるかはやったことがないので何とも。
「硬さ」が足りない部分を、十分なUnitTestで補えれば化けそうな気もするのですが……
0443デフォルトの名無しさん
2006/01/18(水) 19:12:460444デフォルトの名無しさん
2006/01/18(水) 19:40:18それこそ設計次第では？
0445デフォルトの名無しさん
2006/01/18(水) 20:07:22アーキテクチャを取れないものがあると思う。
東証のプログラムとか銀行の基幹系システムをGroovy、Ruby、PHPで作れると思うかい？
0446デフォルトの名無しさん
2006/01/18(水) 20:17:20メインフレームのバッチ処理という話であれば無理。
しかしながらそれは言語仕様によるものではない。
そもそもと金融システムでここ数年で出しゃばってきた手法を採用することはまずない。
なのでどうも実感がわかない。
もうちょい答えやすい例を挙げてくれるとうれしいです。
もしくはあなたが用意している答えを聞きたいです。
0447デフォルトの名無しさん
2006/01/18(水) 20:26:48どの程度の規模なんだろうな
0448デフォルトの名無しさん
2006/01/18(水) 21:45:50なぜ金融システムは保守的なのか？
その答えの一つにスケーラビリティ重視があるからではないだろうか？
スクリプト言語もチューリングマシンを標榜する以上、JavaやC++と同じ事は実現できる。
しかし、システム構築は言語だけで行われるものではなく、動作環境、フレームワーク、
ライブラリといったものに強く依存する。
言語仕様、環境、ツールといったものが渾然一体となり、文化が形成され、その文化の中で
設計思想というものが生まれるのだ。
つまり、同じシステムを構築しようとしてもスクリプト言語を使う場合とJavaやC++を使う場合で
設計は自ずと異なってくるのだ。
そして設計が異なると、その長所、短所も異なってくる。 結局のところ適用分野の住み分けが
起こってくるのは当たり前のことだと考えている。
0449デフォルトの名無しさん
2006/01/18(水) 22:00:48保守的・・・私が思いつくのはCOBOLやCでごりごり書いたものを実績があるからと言う理由で後生大事に流用してると言う状況です。
全銀手順で2400bpsみたいな。
能書きはいいからちゃっちゃとまともに動かせや。と言う分野だと認識しています。
＞言語の仕様による話だが、スクリプト言語によってはスケーラビリティを考慮した
>>448さんは言語仕様ではなくソフトウェア資産の差が問題であるという認識なのですね。
PerlにはCPANがありますし、CLIな言語では垣根がなくなって来ていますから、状況は変わってくるかもしれませんね。
0450デフォルトの名無しさん
2006/01/19(木) 06:39:260451デフォルトの名無しさん
2006/01/19(木) 12:03:11向いていると思う。
ソースの意図が見て分かりやすいし、コンパイラが静的にチェックできる
意味は非常にデカい。
スクリプト言語は簡単な仕事を簡単に片付けることを重視して作られている
から、一人で片付けるようなちょっとした仕事には非常に向いているが、
それで大規模なシステムを構築しようという気にはならん。
Perlはなあ。暗黙のグローバル変数の乱用、シンタックスの汚さ、それらによる
コードの読みにくさ。マルチスレッド非対応。
まあ論外だろ。
0452デフォルトの名無しさん
2006/01/19(木) 13:29:00書き方を気をつければいいという話ですね。
0453デフォルトの名無しさん
2006/01/19(木) 16:59:09「気をつければいい」でバグがなくなるかボケ
言語仕様として一部のバグの発生をありえなくすることのほうが
よっぽど大事
お前一人が頑張っても無駄。一人で作るわけじゃねーんだぞ
0454句読点書けないバカをサマージャンボする俺 ◆9NQzQ21lx.
2006/01/19(木) 18:37:460455デフォルトの名無しさん
2006/01/19(木) 19:49:27納期前だとんなもん軽く吹っ飛ぶからなｗ
あっと言う間にワンライナーの出来上がりだぜ！
0456デフォルトの名無しさん
2006/01/19(木) 20:12:17さあみんな大規模開発でPerlを使おう！！
0457デフォルトの名無しさん
2006/01/19(木) 23:01:540458デフォルトの名無しさん
2006/01/19(木) 23:04:27おまえは雇わないので何の心配もいりません。
0459デフォルトの名無しさん
2006/01/19(木) 23:15:32お前ごときが人を雇用することはありえませんので何の心配もいりません。
0460デフォルトの名無しさん
2006/01/20(金) 01:44:260461デフォルトの名無しさん
2006/01/20(金) 08:00:030462デフォルトの名無しさん
2006/01/20(金) 08:26:280463デフォルトの名無しさん
2006/01/20(金) 12:18:21いや、一人で閉じてる世界なら「書き方を気をつければいい」で済むんだけどな。
あんた、仕事で大規模開発をやったこと、無いでしょ。
0464デフォルトの名無しさん
2006/01/20(金) 17:46:270465デフォルトの名無しさん
2006/01/20(金) 23:14:56いい加減上流の仕事もできるようになりましょうね。
0466デフォルトの名無しさん
2006/01/21(土) 12:04:460467デフォルトの名無しさん
2006/03/02(木) 19:59:15「勝者のシステム 敗者のシステム」坂口英弘著
この本では、オブジェクト指向の考え方や、具体的なシステム設計の
ノウハウが紹介されています。これまでのオブジェクト指向の解説書
には無い実戦的な内容です。ただし、前半はビジネス書っぽい内容です。
特に、アプリケーションの階層化や開発体制とオブジェクト指向の関連
を明確に示している点は新鮮でした。
無能ＰＭの批判など（イラスト見てワロタ）もあり、面白い本なので
オススメです。
0468デフォルトの名無しさん
2006/03/03(金) 03:04:270469デフォルトの名無しさん
2006/03/03(金) 11:56:58ケイの（流れの。Smalltalkとかがサポートする）はそうかもね。
もともと子供向けだし。なんでもメッセージングだし。難しいのは「メタ」という
概念を体得することか。もっとも、ステレオタイプなオトナより子供のほうが得意？
http://tinyurl.com/jpyu5
... The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
is all about (and it's something that was never quite completed in our
Xerox PARC phase). The Japanese have a small word -- ma -- for "that which
is in between" -- perhaps the nearest English equivalent is "interstitial".
The key in making great and growable systems is much more to design how its
modules communicate rather than what their internal properties and
behaviors should be.
http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
...OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding...
ストラウストラップの（流れの。C++やEiffel、Javaとかがサポートする）はどうかな…。
データ型とは何かについて理解できていないと難しいと思う。
加えて、抽象データ型はなにかとか、最近ではインターフェイスとか。
http://public.research.att.com/~bs/whatis.pdf
... Object-oriented programming is programming using inheritance. Data
abstraction is programming using user-defined types. With few exceptions,
object-oriented programming can and ought to be a superset of data
abstraction...
ということで「概念学習が先」に一票。
0470デフォルトの名無しさん
2006/03/03(金) 14:39:03いきなりオブジェクト指向をたいして勉強しないで言語から
始めたから苦労したかも
ただ、間違えまくっていくうちに、オブジェクト指向についても結構おぼえていった希ガス
0471デフォルトの名無しさん
2006/03/03(金) 14:58:43デザインパターンを理解することが近道だよ
はっきりいって
0472デフォルトの名無しさん
2006/03/03(金) 19:21:16オブジェクト指向とデザインパターンに直接の関係性はない
0473デフォルトの名無しさん
2006/03/03(金) 20:02:40デザインパターンがオブジェクト指向原則を理解する上での例題に
なり得る点を考えると、>>471 の言うこともまんざら間違っていない。
0474デフォルトの名無しさん
2006/03/03(金) 22:53:01理解するならデザパタやリファクタリングなど
0475デフォルトの名無しさん
2006/03/03(金) 23:59:55UMLを覚えてUMLツールを使いこなせれば
オブジェクト指向に対する理解が早まるかもしれないな
0476デフォルトの名無しさん
2006/03/04(土) 10:22:51うん，そう思う
>471は，オブジェクト指向とデザインパターンが関連してると言ってるんじゃないし
>472みたいな脊髄反射をよく見るけど，なんだかなぁって思う
0477デフォルトの名無しさん
2006/03/04(土) 23:24:11Java、Ruby等のいろんな言語の文法を片っ端から覚えて
各言語の機能を比較していくのが早いんじゃないかなと思ってる
デザパタもいいよね
オブジェクト指向必要ないよ？ と思ってる人に、良さを知ってもらうのに役立つ
0478デフォルトの名無しさん
2006/03/05(日) 14:08:35「便利だけど、クラスとかメソッドとか一杯出来すぎて管理しきれねー」
と思って手出し控えてた時期があった。
Java を平気で使い出したのは、Eclipse を使い出してから。
IDE の存在は結構大きい、というか必須では。
0479デフォルトの名無しさん
2006/03/05(日) 14:55:24Smalltalk も Browser がないと絶対使い物にならなかったと思います。
そう言う意味で IDE は確かに偉大ですな。
あと Smalltalk の t は小文字で書くのが正しいっす。
ちゃんとした文献ではすべて t が小文字になってます。。
（ただ、開発者の一人であるアラン・ケイはどっちでもいいと言っていたと思いますが。）
0480デフォルトの名無しさん
2006/03/06(月) 09:23:480481デフォルトの名無しさん
2006/03/08(水) 21:54:45Eclipse使って、プロセス中心のプログラム書いてるやつもいるよ。
これまで見てきた中で、ツール依存のやつは、例外なくアフォ。
分かってるやつなら、Notepad使ったって立派なオブジェクト指向の
コードを書くよ。
0482デフォルトの名無しさん
2006/03/08(水) 22:17:300483デフォルトの名無しさん
2006/03/08(水) 23:04:07またそれか。
0484デフォルトの名無しさん
2006/03/08(水) 23:38:26入ってじわじわ分かり出しました。
その後Ｃ♯を始めるまでに、VBで実践出来る範囲のこと（インスタンスとか
インターフェースとか委譲とか）を使っていたので、結構スムーズに
移行できました。
会社の中には、VB6の仕事がなくなるまで「グローバルの関数と構造体」で
シコシコやってきた人たちもいますが、彼らは現在、途方に暮れつつも
public staticなメソッドとインスタンス変数でなんとかやっています。
0485デフォルトの名無しさん
2006/03/09(木) 00:41:32C言語厨と同類じゃないか
0486デフォルトの名無しさん
2006/03/09(木) 00:51:37巨大クラスのクラスフィールドはグローバル変数と変わらん！
0487デフォルトの名無しさん
2006/03/09(木) 03:24:59とてもじゃないが生産性が高いとは思えない
0488デフォルトの名無しさん
2006/03/09(木) 10:31:55もちろん、直接は関係ないよ。
IDEを使えば自然とオブジェクト指向になるわけでも、
使わなければオブジェクト指向ができないわけでもない。
ただ、管理しなければならない要素（クラス名、フィールド名、継承関係）
が増えるから、IDE のサポートがあったほうが楽、というか、無いとしんどいということ。
逆に言うと、IDE の恩恵を受けやすいともいえる。
変数のクラスから、メソッド名などが（継承されたものも含め）コード補完されるといった機能の恩恵は
例えば C言語などではあまり無い。
（構造体からメンバ名がコード補完されるだけではあんまりうれしくない）。
0489デフォルトの名無しさん
2006/03/09(木) 13:06:36Motif のサブクラス書いてて厭になった。
是非一度お試し下さい。
0490デフォルトの名無しさん
2006/03/09(木) 19:22:15＞もちろん、直接は関係ないよ。
＞IDEを使えば自然とオブジェクト指向になるわけでも、
＞使わなければオブジェクト指向ができないわけでもない。
だったら、そう書いてね。
EclipseだのAjaxだの言ってるやつに限って、仕事できないのが
多くて困ってるんだ。趣味でやってるのか、プロジェクトに使え
るのか全く気にしてない。つまり、ヲタな奴が多い。
0491デフォルトの名無しさん
2006/03/09(木) 23:51:20会社で嫌なことがあったかと言って、
勝手な偏見を持ち出されてもなあ。
Ajaxが今のところオブジェクト指向の勉強に役立つとは
とても思えないが、
Eclipseはかなり役立つ機能が揃っているのは
俺もたしかにそう思う。
設定で警告メッセージ項目を徹底的に増やして
FindBugs, CheckStyleなどを組み合わせて、
リファクタリング機能を使いこなすと
そのことがよくわかる感じだ。
0492デフォルトの名無しさん
2006/03/10(金) 12:43:54>Ajaxが今のところオブジェクト指向の勉強に役立つとは
>とても思えないが
そもそも、その両者に何かの関係があるとも思えないが。
IDEとOOにしてもそうだが、無関係の何かを
関連付けるのが流行ってるのか？
0493デフォルトの名無しさん
2006/03/10(金) 17:34:24ヒント：ゆとり教育
0494デフォルトの名無しさん
2006/03/10(金) 23:37:58オブジェクト指向と聞くと逃げ出すようなダメグラマ
0495デフォルトの名無しさん
2006/03/11(土) 00:43:410496デフォルトの名無しさん
2006/03/11(土) 15:41:170497デフォルトの名無しさん
2006/03/11(土) 18:36:39ＯＯの思想を理解しないで、カタチから入ってしまう人が
多いからね。そういう人が実に多い。
要するに、Eclipseを否定しているのではなく、そういう
ツールとかに興味が行ってしまう開発者の問題なんでしょ？
0498デフォルトの名無しさん
2006/03/11(土) 18:50:39結婚は近親相姦の問題(共通の親を持つ兄妹は同一の形質を持つ
この兄妹が子供を儲けると遺伝形質に曖昧さが発生する)があるか
ら、Javaでは採用を見送られた。
しかし結婚がないからといって悲観する事はない。
そもそも、嫁萌えより妹萌えだろ？
養子縁組を利用すれば相手を問わず妹萌えできる。
結婚なんてそもそも不要なんだよ。
0499デフォルトの名無しさん
2006/03/11(土) 22:02:05Eclipseは数多くプラグインがでているから
それを使って楽しみたいと思っている香具師が多く、
結果的にEclipse自体が重たくなって使いにくくなるって
いうことならある。
けど、オブジェクト指向プログラミングの真価を
発揮しやすいIDEであることには変わりないな。
0500デフォルトの名無しさん
2006/03/11(土) 22:06:45EclipseでJavaに強くなる - ＠IT
http://www.atmarkit.co.jp/fjava/rensai3/eclipsejava2_01/eclipse2_01_1.html
0501デフォルトの名無しさん
2006/03/12(日) 05:24:31なんとなく本質が理解できました。＾＾
0502デフォルトの名無しさん
2006/03/12(日) 19:48:28まあそうかもしれない。ちょっとしたことですぐコンパイルエラー出すし。
厳しすぎるのも無理もない。
だらしない男を許さない女みたいな
0503デフォルトの名無しさん
2006/03/13(月) 04:52:30そういう意味ではJBuilder3は最強だな
継承関係の途中のclassファイルが無くてもコンパイルが出来る
0504デフォルトの名無しさん
2006/03/13(月) 12:46:340505デフォルトの名無しさん
2006/03/13(月) 23:25:23MSは、Eclipseより生産性ずっと高いって言ってたよ。
チーム開発の機能が売りみたいだったな。
0506デフォルトの名無しさん
2006/03/14(火) 01:44:05Teamなんたらじゃないときついな
家でちょろっと遊ぶ程度ならExpressやStandardでも良いんだけど
0507http://www.vector.co.jp/soft/win95/util/se072729.html
2006/03/18(土) 20:46:45もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
0508デフォルトの名無しさん
2006/03/19(日) 02:45:21VS.NET 2005のチーム開発がEclipseよりも
売り？ まさかVisual Source Safeをバンドルしただけで
売りだなんて言わないよな。
VSSはSubversionには非常に劣るし
0509デフォルトの名無しさん
2006/03/19(日) 11:33:21確かに最近、MSはパッとしないね。
マンネリというか、売る気が無いというか、2000年頃は
期待も高かったんだが．．．今はLinux/Javaにやられっぱなしだ。
もうだめぽ？
0510デフォルトの名無しさん
2006/03/19(日) 12:09:04焦ってVS.NET 2005 Expressを無料で配布してるくらいだ。
しかもC#やVB.NETの仕事もろくにないし。
PHPとJavaの仕事ばっかで今ドトネトはかなり窮地に立たされているともいえる。
0511デフォルトの名無しさん
2006/03/19(日) 12:43:30Eclipseって個人だけじゃなくて、実務でも普通に使われてるものなの？
0512デフォルトの名無しさん
2006/03/19(日) 12:52:520513デフォルトの名無しさん
2006/03/19(日) 13:29:16普通に使われてるよ。
Linuxと同じで、既存のディストリビューションを購入して使ってるところから
自社で独自にパッケージングして使ってるところまで色々だけど、結局Eclipse
である事に変わりはない。
0514デフォルトの名無しさん
2006/03/19(日) 13:35:570515デフォルトの名無しさん
2006/03/19(日) 13:48:110516デフォルトの名無しさん
2006/03/19(日) 14:29:02そうなんですかー
使いもしない数十万のパッケージなんて会社では
買ってもらえないので、実務に耐えられるJAVAの勉強
どうやってやろうか困ってたんです(;´Д`)
>>514
でもJAVAの開発関連を検索したらIDEではEclipseぐらいしか
見当たりません
個人ではIDEなんて使わないんですか？(;´Д`)
0517デフォルトの名無しさん
2006/03/19(日) 14:31:05EclipseかNetbeansでいいじゃん 俺はNetbeansをお勧めするけど
まあこのスレよりもっと適切なスレがあると思うので詳しくはそっちへ
0518デフォルトの名無しさん
2006/03/19(日) 14:40:00>>個人ではIDEなんて使わないんですか？
そんなこともないけどさ。
なんというか、個人で使うには機能が立派すぎる。
言い方を変えれば「重すぎる」んだよねえ。。。
0519デフォルトの名無しさん
2006/03/19(日) 15:28:560520デフォルトの名無しさん
2006/03/19(日) 18:24:43Eclipseは個人で使った方が楽しめるぞ。
ゲームだってできるし
株価チェックだってできるし、
そういうプラグインを作る楽しみがある。
プラグインバリバリ入れたい放題ってのがいいねえ
0521デフォルトの名無しさん
2006/03/19(日) 22:41:460522デフォルトの名無しさん
2006/03/20(月) 07:19:01クラサバや単なるクライアントアプリでは、問題なくねぇ？
この先、WebアプリはUIが貧弱で、結局、流れはスマートクライアントとかなるかもしれんし。
0523デフォルトの名無しさん
2006/03/20(月) 09:50:34monalipseなどでEclipse上で見られるが、
有益になる情報も手に入ったりする。
monalipseは使い勝手が悪いので
Jane Doe Styleを使っているがw
0524デフォルトの名無しさん
2006/03/20(月) 09:51:41どうだろうねえ。
クライアントサイドでもJavaに押されてる気がする。
NetBeans勢力拡大とSwing APIのめまぐるしい性能機能向上
がC#やVB.NETを圧倒している。
0525デフォルトの名無しさん
2006/04/16(日) 14:18:320526デフォルトの名無しさん
2006/04/16(日) 19:55:52closure って書きたかったのﾎﾞｸ？
0527デフォルトの名無しさん
2006/04/16(日) 20:00:080528デフォルトの名無しさん
2006/04/16(日) 20:59:52って懐かｽｨ。。。
0529デフォルトの名無しさん
2006/04/20(木) 18:04:190530デフォルトの名無しさん
2006/04/21(金) 07:33:080531デフォルトの名無しさん
2006/06/13(火) 00:59:17脱オブジェクト指向のススメ
ttp://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html
このイーキャッシュの代表取締役玉木の発言がおかしいから
このスレからpinする。
オブジェクト指向のことをまったくわかっていません。
というか、かなり勘違いしています。
そのくせにオブジェクト指向を否定しています。
0532デフォルトの名無しさん
2006/06/24(土) 05:25:02オブジェクトのよさがまだいまいちわからない…
関数とあまりかわらないんじゃないかとか
いまいちよくわかってないので、疑問が出てくる
まあ色々と違うんだろうけどアセンブラだって普通のCだって
普通は部分部分でまとめてやるだろうから
同じなんじゃなかろうかとか
隔離して部品として纏められるのがいいんだろうか
他に影響が出づらいとか安全に纏められて管理がしやすいとかだろうか
0533デフォルトの名無しさん
2006/06/24(土) 10:03:49勿論必ずしも必要じゃないがOOPLの方が書き易い処理もいくつかある
1. 構造体や関数をひと纏めにしてグローバルな名前を減らせる
2. 型不定な引数や型ごった煮リストに対応する処理
3. this/selfの存在は何気に大きいと思う
4. 元々OOの発祥である物と物の関係を表す処理
5. GUIライブラリとの相性
0534デフォルトの名無しさん
2006/06/24(土) 17:45:00なるほどまだあまりよくわかってないけど
無くても出来ることは出来るけど一纏めに出来てミスも防ぎやすいって
ことなんかな
確かにきっちり別れてるからいいっぽい気はするし
ライブラリによってはってのもなんとなくそんな気がする
どんどん使っていけばわかってくるんだろうか
0535デフォルトの名無しさん
2006/06/24(土) 18:17:22オブジェクト指向を用いたコードと、それを用いずに書いたコードを
具体的に出して比較してみると利点・欠点がわかるかも
0536デフォルトの名無しさん
2006/06/26(月) 10:49:22> 無くても出来ることは出来るけど一纏めに出来てミスも防ぎやすいって
> ことなんかな
プログラミング言語の進化はそれこそが目的だと思う
0537デフォルトの名無しさん
2006/06/27(火) 20:27:24大規模開発したことないんだろうなー
0538デフォルトの名無しさん
2006/06/27(火) 21:49:15って話があるような気がする。
「オブジェクト指向」「オブジェクト指向」って題目のように唱えて、
「自動車がオブジェクトで、ハンドルやアクセルが操作で・・」
みたいな話を性懲りも無く繰り返してるだけの奴と、
たとえば、Java の文法を熟知して、Abstruct Class や Interface を
適切に追懐こなしてる奴とどっちが「使えるのか」。
後者の奴に、「なぜフィールドをprivate にして、アクセッサでアクセスしてるのか？」と聞けば、
「こうしたほうが、外部からの参照や変更が限定できていろいろと都合がいいからだよ、
だいたい、setter や getter に必ずしも対応するフィールドがあるとは限らないし」
といったことを答えるだろう。そもそも、Cの時代から構造体のメンバにはなるべく直接代入
しないようにしていたことの延長をやってるだけなのだ。
Abstruct や Interface をなぜ使うのかと聞かれれば、「便利だから」
「Cでやりたいと思ってできなかったことができるようになっているから」
といった答えが返ってくるだろう。
手続き型言語で十分な経験を積んだ開発者なら、Java のような言語を与えられれば、
自然とそういうことができるものなのだ。
「題目を唱えること」と、「実際に優れたコードを書くこと」はどちらが大切なのか？
結局、「オブジェクト指向の大切さ」云々を言っている人の大半は、
「題目を唱えること」を「実際に優れたコードを書くこと」よりも優先してるだけのように思えてならない。
0539デフォルトの名無しさん
2006/06/27(火) 22:42:440540デフォルトの名無しさん
2006/06/27(火) 22:44:49http://academy4.2ch.net/test/read.cgi/english/1151414777/l50
0541デフォルトの名無しさん
2006/06/27(火) 22:46:44微妙に異なる話だけど、オブジェクト指向の定義が１つじゃないのは問題のような気がした。
ケイかストラウストラップか、あるいは……みたいな。
0542デフォルトの名無しさん
2006/06/27(火) 22:57:06アラン・ケイもSmalltalk（！）も知らないと思われ。
0543デフォルトの名無しさん
2006/06/27(火) 22:58:58そうですね。
オブジェクト指向を、「それらしく」使える人は、プロセス中心の
プログラム開発でいやと言うほど無駄なコード書いてきた人や、トラブル
を経験してきた人ですね。危険回避のために自然とオブジェクト指向の
考えを導入したくなります。コードの最適化を行おうとすれば、自然とOOP
になりますね。
0544デフォルトの名無しさん
2006/06/27(火) 23:10:22勘違いでなければ、元々OOP向きだったか、OOPでも破綻
しないものだったに過ぎん。
過信論者にはなるなよ>>543
0545デフォルトの名無しさん
2006/06/27(火) 23:18:21（まあ、人にも多少はあるだろうけど。）
C言語で、
struct window w;
window_open( w );
window_setsize( w, 100, 100 );
とかやってた人間は、
Window w = new Windows();
w.setSize( 100, 100 );
ってかけるようになったら「やっとなるべき形になった」としか思わないんじゃないかな。
「window_setsize( w, 100, 100 ); のほうがいい」と思う人は少ないと思う。
0547デフォルトの名無しさん
2006/06/28(水) 13:26:17> オブジェクト指向の定義が１つじゃないのは問題
しかしそれが実際ですからねぇ…。それらを混同して（あるいは勝手に組み合わせた俺定義を
ふりかざして）トラブルになるケースは多いですし。逆に、誰の「オブジェクト指向」かを
明らかにするよう心がければ、議論の入り口でのありがちなループを回避できるのもまた確かなことです。
とにかく、教科書レベルの記述で混乱に拍車をかけるような書き方は避けて欲しいです。
あえて問題があるとすれば、オブジェクトが本質じゃないものに「オブジェクト指向」と名付けたケイか、
すでにケイのオブジェクト指向があるのに、あえて“抽象データ型のスーパーセット”あるいは
“クラス（継承）によるプログラミング”という別の切り口に同じ「オブジェクト指向」と
名付けてしまったストラウストラップが諸悪の根源か…。まあ、どっちもどっちかなと。
0548デフォルトの名無しさん
2006/06/28(水) 18:14:55「オブジェクトを如何にして使用するか」 なケイと、
「オブジェクトを如何にして定義するか」 なストラウストラップの対立のような気が。
0549デフォルトの名無しさん
2006/06/28(水) 18:39:45その例は、あまり魅力的な差に見えないね。
もうちょっと派手で、いかにもOOがよろしげに見える例を出せないの？
0550デフォルトの名無しさん
2006/06/28(水) 19:34:51>その例は、あまり魅力的な差に見えないね。
それは、（君が現場の苦労を知らない）
坊やだからさ。
0551デフォルトの名無しさん
2006/06/28(水) 19:47:36しかし、現場の苦労はどうでもいいから、もうちょっとマシなの
おながいしまつ>>550
0552デフォルトの名無しさん
2006/06/28(水) 19:57:23現場の苦労がどうでもいいなら、そんなのなくてもどうでもいいじゃん？
0553デフォルトの名無しさん
2006/06/28(水) 20:17:46しらないならかかなきゃいいのに。
0554デフォルトの名無しさん
2006/06/28(水) 20:18:15漫才したい訳じゃないんで、もうちょっとマシなの
おながいしまつ>>552
0555デフォルトの名無しさん
2006/06/28(水) 20:28:18そもそも両者は対立なんかしていない。対立以前に名前以外、本質的部分に接点がない。
利用者が勝手な文脈でそれぞれのエッセンスをまぜこぜにして混乱を助長するから
発案者のほう（とくにストラウストラップ）が困惑しているくらいのことはあるだろうけど。
ttp://www.research.att.com/~bs/bs_faq.html#from-Smalltalk
ttp://www.purl.org/stefan_ram/pub/doc_kay_oop_en
0556デフォルトの名無しさん
2006/06/28(水) 20:39:55ストラウストラップのオブジェクト指向の例でいいならば、複素数の計算とかは？
複素数という新しい型を定義せずに、複素数演算を自然に記述するのは難しいと思う。
0557デフォルトの名無しさん
2006/06/28(水) 20:48:06それは >>545 のように対比できる対象例がありますか？
ちなみに>>535 は別の人ですけど。
0558デフォルトの名無しさん
2006/06/28(水) 21:42:20オブジェクト指向言語は設計＞コードの変換の手間が少なくて使いやすいと思う
0559デフォルトの名無しさん
2006/06/28(水) 22:36:200560デフォルトの名無しさん
2006/06/28(水) 22:38:240561デフォルトの名無しさん
2006/06/28(水) 23:23:28Ｃ（non oop）版はアンチが書いてくれ。
class complex {
double re, im;
public:
complex(double r, double i) { re=r; im=i; }
complex(double r) { re=r; im=0; } // float->complex conversion
friend complex operator+(complex, complex);
friend complex operator-(complex, complex); // binary minus
friend complex operator-(complex); // unary minus
friend complex operator*(complex, complex);
friend complex operator/(complex, complex);
// ...
};
complex operator+(complex a1, complex a2)
{
return complex(a1.re+a2.re,a1.im+a2.im);
}
// ...
complex a = 2.3;
complex b = 1/a;
complex c = a+b*complex(1,2.3);
// ...
c = -(a/b)+2;
0562デフォルトの名無しさん
2006/06/29(木) 01:46:10「現場の苦労はどうでもいい」なんて言ってる人間にとって、
「魅力的」なコードなんて、とりあえず俺には何の意味も無い。
プログラミングは座敷芸じゃない。
0563デフォルトの名無しさん
2006/06/29(木) 02:13:41新しい型を自然に記述するのは、新しい型の振る舞いと定義が可能で、
元の言語仕様と同様に、新しい型を取り扱える処理系であれば可能な
事だと思います。
それは処理系依存の問題でoopとは関係ないような気がしますが、それ
とも、新しい型の振る舞いと定義が可能で、元の言語仕様と同様に、新
しい型を取り扱える事こそがoopだと言う事ですか？
0564デフォルトの名無しさん
2006/06/29(木) 02:15:05ここは、マ板じゃなくてム板なんだから、そゆのもありじゃね？
0565デフォルトの名無しさん
2006/06/29(木) 02:22:14ありだろうけど、逆にいうとそれに付き合う義理もないんじゃね？
とりあえず、>>545 は「そういう意味で」「魅力的」と主張してる
わけじゃないから、それは別の話題の話題として話せばいい。
0566デフォルトの名無しさん
2006/06/29(木) 02:39:51[オブジェクト生成]
obj01 = window_new();
obj02 = button_new();
obj03 = checkbox_new();
obj04 = listbox_new();
[表示]
window_show(obj01);
button_show(obj02);
checkbox_show(obj03);
listbox_show(obj04);
とかやってた人間は、
[オブジェクト生成]
obj01 = new window();
obj02 = new button();
obj03 = new checkbox();
obj04 = new listbox();
[表示]
obj01->show();
obj02->show();
obj03->show();
obj04->show();
になる。
0567デフォルトの名無しさん
2006/06/29(木) 08:08:15ストラウスストラップのオブジェクト指向の文脈では、そう。
より正しくは、それに継承を加えたもの。
別の言い方をすると、抽象データ型(ユーザーが新しい型と振る舞いを…)を
Simulaのクラスを使ってやる、というのが彼の(そして´90年代以降主流の、
今でいう、カプセル化・多態性・統承の)オブジェクト指向。
念のため書き添えると、この文脈では「メッセージ」(ケイのオブジェクト指向の
キー・コンセプト)は関係ない。
0568デフォルトの名無しさん
2006/06/29(木) 08:13:51統承× → 継承〇 スマン。手書きなもんで…。
0569デフォルトの名無しさん
2006/06/29(木) 10:08:200570デフォルトの名無しさん
2006/06/29(木) 10:38:420571デフォルトの名無しさん
2006/06/30(金) 00:42:06ありがとう、やっと、自分の理解していた事が、言葉と結びつきました。
0572デフォルトの名無しさん
2006/06/30(金) 07:01:09何かのお役にたてたのでしたら、さいわいです。
0573デフォルトの名無しさん
2006/07/03(月) 21:37:41便利だ」でOK？
0574デフォルトの名無しさん
2006/07/03(月) 21:52:16使いどころによって便利か不便かが決まる。
0575デフォルトの名無しさん
2006/07/03(月) 22:01:33がんじ絡めにOOPしなくても良いんだから不便ってこたぁないだろ
それが自分のせいであれ、会社のせいであれ
OOPLが不便って思う人はOOPLに振り回されてると思う
大きなコードになるとOOPの方が良いが
小さなコードで無理してOOPすると余計に混乱するぞ
0576デフォルトの名無しさん
2006/07/03(月) 22:18:23もっと謙虚に、プログラミングにおける支配的パラダイムだ、でいいと思う。
0577デフォルトの名無しさん
2006/07/03(月) 22:21:210578デフォルトの名無しさん
2006/07/04(火) 13:18:16相対性理論は物理学における支配的パラダイムだった。量子力学の誕生までは。
いや
端的に「支配的パラダイムは歴史と共に変遷する」と表現した方がわかりやすいか？
そして
パラダイムのシフトは旧来のパラダイムを支持する人間が死滅するまで完了しない
という歴史的な事実も書いておこう
0579デフォルトの名無しさん
2006/07/04(火) 20:23:57ニュートン力学も相対性理論も量子力学も、世界の一部分を切り取った姿を提示しているだけだから、
これをプログラミングに直すと 『ひとつの方法』 を提示しているってことになるな。
0580デフォルトの名無しさん
2006/07/04(火) 21:57:56「学びて思わざれば則ちくらし、思うて学ばざれば則ちあやうし」
これにてこのスレ終了。
0581デフォルトの名無しさん
2006/07/14(金) 14:08:320582デフォルトの名無しさん
2006/07/14(金) 16:56:040583デフォルトの名無しさん
2006/07/15(土) 15:32:300584デフォルトの名無しさん
2006/07/15(土) 16:09:41大事なのは振る舞いだ。
0585デフォルトの名無しさん
2006/07/15(土) 16:25:350586デフォルトの名無しさん
2006/07/15(土) 16:51:440587デフォルトの名無しさん
2006/07/15(土) 16:52:52勉強すればするほど馬鹿になってるんじゃないかって。
0588デフォルトの名無しさん
2006/07/15(土) 19:42:420589デフォルトの名無しさん
2006/07/15(土) 21:05:100590デフォルトの名無しさん
2006/07/16(日) 00:49:330591デフォルトの名無しさん
2006/07/16(日) 04:35:580592デフォルトの名無しさん
2006/08/21(月) 11:04:09能書き垂れてる。
やはり、言語学習で慣れるのが先では？
でも言語学習だけで終わると薄っぺらな人生と同じで虚しい。
１の質問に対しては｢両方とも必要｣という穏当かつ中途半端な
回答しかないと思う
0593デフォルトの名無しさん
2006/08/27(日) 18:34:37オブジェクト指向設計技術はここから何度も刷新されている。
今から購入するんなら、
「デザインパターンとともに学ぶオブジェクト指向のこころ」を
お勧めしたい。
0594デフォルトの名無しさん
2006/08/27(日) 21:21:10上から下に処理が実行されることを教えた後ですぐに
継承とかインターフェースとか教えて、
デザインパターンのいくつか、例えばテンプレートメソッドとかを覚えさせて、
その後で、繰り返し文とか配列とか教えたら、
なかなか面白いことになるのではなかろうか。
誰か新人に試してみれ。
0595デフォルトの名無しさん
2006/09/06(水) 17:34:590596デフォルトの名無しさん
2006/09/07(木) 22:20:38確かに横文字で得意がるタイプは居るな
しかし敢えて>>595の言う横文字が
何処までを指すのか知りたい
少なくともここ一週間のこのスレのログには
得意がる程の横文字は見当たらないんだが…
0597デフォルトの名無しさん
2006/09/07(木) 22:55:32そんなの>>595の虫の居所次第じゃね？
0598デフォルトの名無しさん
2006/09/30(土) 17:35:03http://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html
0599デフォルトの名無しさん
2006/09/30(土) 18:26:43それ糞だから
0600デフォルトの名無しさん
2006/09/30(土) 20:28:440601デフォルトの名無しさん
2006/09/30(土) 21:34:09made to teach succession or the interface at once after processing is
taught to be executed on below as a method of teaching to the person who
doesn't know "P" of the programming though it is a hypothesis, and to be
remembered, and if the for statement or the array is taught afterwards,
it not interesting? easily
It is tried by the new figure.
0602デフォルトの名無しさん
2006/10/01(日) 11:17:48オブジェクト指向の概念、ちゅーのは、果たしてありうるんだろうか？
0603デフォルトの名無しさん
2006/10/01(日) 12:56:09“オブジェクト指向的な設計”と“オブジェクト指向言語の使い方”を混同してるだけにしか見えない
設計から実装にいたる間は幾つかの層に分けられるのだから、より抽象的な所では同じでも良いが実装に近づくにつれ分化していくって所
0604デフォルトの名無しさん
2006/10/01(日) 22:38:55C++ と Smalltalk
0605デフォルトの名無しさん
2006/10/01(日) 22:41:28> オブジェクト感覚
> オブジェクト感覚
> オブジェクト感覚
> オブジェクト感覚
> オブジェクト感覚
> オブジェクト感覚
「新たな感覚 ・・・ それはオブジェクト感覚だ！」 の巻～
0606デフォルトの名無しさん
2006/10/02(月) 04:51:36チミが本気でそう思うなら、チミの「オブジェクト指向」は漠然としすぎていて
童話のようなお話だってことだ。
たとえばアランとビアルネのオブジェクト指向は、根本から明らかに違う。
0607デフォルトの名無しさん
2006/10/02(月) 12:18:48チミが本気でそう思うなら、チミの「オブジェクト指向」は漠然としすぎていて
童話のようなお話だってことだ。
以下ループ
0608デフォルトの名無しさん
2006/10/02(月) 14:28:010609デフォルトの名無しさん
2006/10/03(火) 07:46:13統一した概念として説明しようとすると、共通のキーワードを抜き出して、大雑把に
説明するくらいしか出来ないけど、それはオブジェクト指向についての説明にぜんぜんならない。
ネコクラスが哺乳類クラスを継承するような説明は、こういう勘違いから始まるんだろう。
0610デフォルトの名無しさん
2006/10/04(水) 13:24:27オブジェクト指向の簡単な部分だしか
だ・し・か
0611デフォルトの名無しさん
2006/10/04(水) 13:25:270612デフォルトの名無しさん
2006/10/04(水) 16:52:17神経質とも言うか・・・
0613デフォルトの名無しさん
2006/10/04(水) 16:53:100614デフォルトの名無しさん
2006/10/04(水) 16:58:44この神経質はこの板によく出てくるん奴だろう。
どこに行っても友達少ないんだし、ほっとけよ。
リアルでも避けられて、こいつはもう既にうつ病が始まってるんだからさ。
0615デフォルトの名無しさん
2006/10/04(水) 17:02:14ああそうだな。
うつ病の奴って、迷惑だから早く自殺して欲しいよな…
0616デフォルトの名無しさん
2006/10/04(水) 21:50:36他人の小さなミスをネチネチ言う奴いるよね
そんな奴って、だいたい嫌な香具師で、スネ夫みたいな感じの香具師
0617デフォルトの名無しさん
2006/10/05(木) 02:04:56とりあえず一片真で濃い
0618デフォルトの名無しさん
2006/10/05(木) 18:00:36誤字の部分示してコンパイルエラーと書けば良いのに
単なる指摘しか出来ない奴の頭の構造ってどうなってだろな
0619デフォルトの名無しさん
2006/10/05(木) 18:26:10何が書いてあるのか読めないのだが？
もう一度書き直してくれ。
0620デフォルトの名無しさん
2006/10/06(金) 00:10:07問題集の回答には「ヒープ」って書いてあったんですが、
この問題文から読み取れる情報から回答するとすれば「処理系依存」だと思うんですが皆様的にはどうでしょう？
オブジェクト指向プログラミングに関する次の記述中の[a]～[g]に入れる適切な字句を答えよ。
オブジェクト指向プログラミングでは、[a]化の概念を用いて[b]を介してデータを扱う。
これによって、オブジェクト内部の[c]構造に変更があっても、
呼び出し側のプログラムを変更する必要がなく、保守性の向上が期待できる。
スーパークラスで定義した操作をサブクラスで再定義することもできる。これを[d]という。
操作の再定義によって、同じ名前でも違った実装をもつことになる。
実装が異なっても、それを呼び出すプログラムが違いを意識しなくても良いことを[e]という。
プログラムによって生成されるオブジェクトの実体は、[f]領域に確保される。
使用されなくなったオブジェクトの管理をプログラムで行うのは困難なので、
[g]によって領域内の不必要なオブジェクトの整理を行い、領域の再利用を図る言語処理系がある。
0621デフォルトの名無しさん
2006/10/06(金) 00:14:50過去問から出題したのかなぁ
もし[b]がメンバ関数ならすごくC++臭くて鼻つままないと近寄れねーです
0622デフォルトの名無しさん
2006/10/06(金) 03:04:20多態、f、ガベージコレクション、かな？
fはスタックの場合もあるよね。
0623デフォルトの名無しさん
2006/10/06(金) 05:29:270624デフォルトの名無しさん
2006/10/06(金) 06:35:100625デフォルトの名無しさん
2006/10/07(土) 16:38:54それらのスーパークラスであるメモリを答えにすればいいのでは？
0626デフォルトの名無しさん
2006/10/07(土) 17:03:40実装にばかり気をとられてそこまで気がつかきませんでした。
「プログラムによって生成されるオブジェクトの実体は、[メモリ]領域に確保される。 」
なに当たり前のことを言ってるの？的な部分もありますが、
同じ文章が試験に出題されたらこれでいきます。
0627デフォルトの名無しさん
2006/10/07(土) 22:04:11コード領域の対してのデータ領域とかはどう？
0628デフォルトの名無しさん
2006/10/08(日) 02:50:490629デフォルトの名無しさん
2006/10/08(日) 10:08:52foo(){
TestClass class;
TestClass *p_class = new TestClass;
}
前者はスタック、後者はヒープに領域が取られるんじゃなかったっけ？
規格書で動作まで規定されてるかわからんけど。
0630デフォルトの名無しさん
2006/10/08(日) 10:34:400631デフォルトの名無しさん
2006/10/08(日) 13:33:59もう何年にもなるんじゃないか
コテハンを厨厨にすればいいじゃないかな
0632デフォルトの名無しさん
2006/10/08(日) 13:54:560633デフォルトの名無しさん
2006/10/08(日) 13:59:120634デフォルトの名無しさん
2006/10/09(月) 03:57:23ヒープ ⊃ スタック
だと思ってたよ
0635デフォルトの名無しさん
2006/10/13(金) 23:12:060636デフォルトの名無しさん
2006/10/20(金) 12:05:52それ、オレの大学のコンピュータサイエンスⅠのクラスでまさにやってるとこだよ。
ベーシックしか知らなかった友人Ｃは今クラッシュして苦しんでる。
概念学習より言語学習が先だとおもう
0637デフォルトの名無しさん
2006/10/21(土) 20:09:110638デフォルトの名無しさん
2006/10/22(日) 04:05:03言語を習得したらその言語で書かれたサンプルを読みまくり、自分でもコードを書いてみる。
そうすればオブジェクト指向の考え方も自然と身に付く。
オブジェクト指向の概念本はやたら話の内容を大きくしてるだけの糞本が多いので要注意。
0639デフォルトの名無しさん
2006/10/22(日) 05:46:57でかいプロジェクトを自分で設計出来るかどうか、
0640デフォルトの名無しさん
2006/10/22(日) 08:44:38でかいプロジェクトを設計出来る
・OOは心強い武器になる
・近頃はOO分析とか言われてる
→OO使える
> 問題はオブジェクト指向を使えるかどうかよりも
少なくとも、オブジェクト指向は使えなきゃ困る
/*
…てかOOなんて”指向”だから、思想と同じ意味だよ！
そんなに神聖化する必要なんて無いんだよ！
って言いたかっただけです
*/
0641デフォルトの名無しさん
2006/10/22(日) 10:24:48ソースの可読性がよく、とてもこざっぱりしていて。
もともとVBやってたときも、exe開発はせず、ほとんどdll開発。
データ取得クラスを作って、
普通にvb5.0のときから、そのクラスをnewして、プロパティをセットして
get（）メソッドでデータ取得。
みたいなことをしていた。
おそらくそれ作ったのがC上がりの人だったのかもしれないが。
今思うとサーバにｄｌｌを配置して、各画面のｅｘｅをクリックしたと同時に
サーバのdllとクライアントのdllのバージョンを比較し、新しくなっていたら、サーバから取り直す、という
処理も入れていた。
そんなことを３年間やって客先とか出向いたりいろいろしていて、いざ次にVBやりましょう、と他のプロジェクトに入ったとき
非常にわかりづらかった。
その後javaをへてC#に入ったけど、実は今とってもピッタンコと思える言語をみつけてうれしくなってる。
0642デフォルトの名無しさん
2006/10/24(火) 01:53:59そういう奴なら暇が出来たら関数型言語とか弄ってみな
すげえおもしれえよ
0643デフォルトの名無しさん
2006/10/26(木) 13:13:330644デフォルトの名無しさん
2006/10/26(木) 13:23:33あれはもうダメだ。
0645デフォルトの名無しさん
2006/10/26(木) 22:33:19言語仕様事態はとくに面白くもなく、醜いわけでもなく・・・
0646デフォルトの名無しさん
2006/10/26(木) 22:55:000647デフォルトの名無しさん
2006/10/26(木) 23:06:54横レスするけど、Java と違って野良フレームワークがあまり無いから
楽なような気がする。あとMSが勝手にガンガン突っ走るんでJavaより
ダイナミックで面白いよね。2.0 だの 3.0 だの。
0648デフォルトの名無しさん
2006/10/26(木) 23:16:09Javaは携帯やサーバー用途に広がったけど、
C#はいくら面白くてもWindows関係だけでは？
突っ走っていてもMSやC#は一体何がしたいんだろう？
そこが明確じゃないからC#よりJavaに流れるのかもしれない。
0649デフォルトの名無しさん
2006/10/26(木) 23:19:330650デフォルトの名無しさん
2006/10/26(木) 23:22:030651デフォルトの名無しさん
2006/10/26(木) 23:22:22（漏れはPC用のソフト作る会社で働いてるから、かなりバイアスがかかってる）
0652デフォルトの名無しさん
2006/10/26(木) 23:24:11Javaの言語仕様をじっくりみていくとその奇怪さがよくわかるよ
0653デフォルトの名無しさん
2006/10/26(木) 23:28:49ｋｗｓｋ
0654デフォルトの名無しさん
2006/10/26(木) 23:29:030655デフォルトの名無しさん
2006/10/26(木) 23:51:06具体的に言えば、Windowsのさらに.Netのところのみってこと。
いまだに世界は狭いよね。
結果は同じだし、それよりもJavaの方に目が向いてしまうもんじゃないか。
0656デフォルトの名無しさん
2006/10/26(木) 23:57:11なんでどっちかが先に生まれないいかんねん。同時に生んだらええねん
0657デフォルトの名無しさん
2006/10/27(金) 00:00:09>>654
いやね、↓の本をちょっと娯楽で読んでいたらJavaって変だなぁって改めて思わされたから。
http://www.amazon.co.jp/gp/product/4894716895/sr=1-80/qid=1161874695/ref=sr_1_80/250-9245522-9627404?ie=UTF8&s=books
0658デフォルトの名無しさん
2006/10/27(金) 01:10:48プログラミング言語って人が普通に生活する感覚からは大きく外れてるよね
って感じな。
0659デフォルトの名無しさん
2006/10/27(金) 08:08:48もしC++で同じような本があったら10倍くらいの厚さになるだろうなｗ
0660デフォルトの名無しさん
2006/10/27(金) 10:59:39BASICは５～６倍でC言語でも３倍位の厚さになるな。
その位Javaはシンプル
Windowsの特定のバージョンのC言語だけやってると気が付かないと思うけど
良い意味でMSに囲いこまれてるってだけ
0661デフォルトの名無しさん
2006/10/27(金) 11:08:21> BASICは５～６倍でC言語でも３倍位の厚さになるな。
納得できる定義ではない
よって
> その位Javaはシンプル
の帰結は論理的ではない
と言ってみる
0662デフォルトの名無しさん
2006/10/27(金) 11:15:550663デフォルトの名無しさん
2006/10/27(金) 11:19:24古典言語を引き合いにだしたら、そりゃ変なところもあるでしょうよ。
0664デフォルトの名無しさん
2006/10/27(金) 15:35:590665デフォルトの名無しさん
2006/10/27(金) 15:53:470666デフォルトの名無しさん
2006/10/28(土) 14:08:050667デフォルトの名無しさん
2006/10/28(土) 14:16:25彼らはわざわざ検索しにくい言葉を使うのが習性らしい
.Net、Word、.doc....実に迷惑千万だろ
0668デフォルトの名無しさん
2006/10/28(土) 14:42:480669デフォルトの名無しさん
2006/10/28(土) 17:45:270670デフォルトの名無しさん
2006/10/28(土) 18:09:180671デフォルトの名無しさん
2006/10/28(土) 20:13:400672デフォルトの名無しさん
2006/10/28(土) 21:19:370673デフォルトの名無しさん
2006/10/28(土) 21:36:16「COM」を追加。
0674デフォルトの名無しさん
2006/10/28(土) 23:05:58関連リンク
哲学者ならばプログラム言語を勉強したまえ
http://academy4.2ch.net/test/read.cgi/philo/1162007282/
0675デフォルトの名無しさん
2006/10/29(日) 21:30:21Windowsも追加しといてー
0676デフォルトの名無しさん
2006/11/06(月) 11:36:22おまいらSOAPを忘れてる
0677デフォルトの名無しさん
2006/11/06(月) 15:10:560678デフォルトの名無しさん
2006/12/14(木) 03:24:410679デフォルトの名無しさん
2006/12/25(月) 07:17:480680デフォルトの名無しさん
2006/12/26(火) 04:21:520681デフォルトの名無しさん
2006/12/26(火) 05:55:05Javaのどこにさわやかなイメージがあるんだ？
携帯アプリ製作現場しか思い浮かばんぞ？
0682デフォルトの名無しさん
2006/12/26(火) 19:34:450683ココ電球（∩T∀T) ◆tIS/.aX84.
2006/12/26(火) 19:36:210684デフォルトの名無しさん
2006/12/30(土) 02:18:490685ココ電球（∩T∀T) ◆tIS/.aX84.
2006/12/31(日) 11:46:12話は変わるが、会社でオブジェクト指向信者がサーバーに負担かけまくって
しばしばDB飛ばしてたのがいたが、首になったらしい。
0686ココ電球（∩T∀T) ◆tIS/.aX84.
2006/12/31(日) 11:48:53こっちがチューニングで爪に火を灯すようにサーバーの負荷減らしてるのによお。
ドッカーンと、こっちがチューニングで減らした量の１００倍くらいの負荷作っちゃうからな。
示威行為なんだよな。
まったく信者ってやつは。
0687デフォルトの名無しさん
2006/12/31(日) 14:12:500688デフォルトの名無しさん
2007/01/19(金) 23:06:21オブジェクト指向における再利用と、関数による再利用
の違いを教えてくれ。
0689デフォルトの名無しさん
2007/01/19(金) 23:55:500690デフォルトの名無しさん
2007/01/20(土) 00:46:150691デフォルトの名無しさん
2007/01/20(土) 00:52:140692デフォルトの名無しさん
2007/01/20(土) 00:52:450693デフォルトの名無しさん
2007/01/20(土) 00:57:370694デフォルトの名無しさん
2007/01/20(土) 01:18:46検索してみろ
0695デフォルトの名無しさん
2007/01/20(土) 02:25:43FJ のことか？
0696デフォルトの名無しさん
2007/01/20(土) 03:21:36これがオブジェクト指向か？
0697デフォルトの名無しさん
2007/01/20(土) 08:35:09その通り
0698ココ電球（∩T∀T) ◆tIS/.aX84.
2007/01/20(土) 09:42:360699デフォルトの名無しさん
2007/01/20(土) 11:08:260700デフォルトの名無しさん
2007/01/20(土) 11:16:09class 音
0701デフォルトの名無しさん
2007/01/20(土) 11:42:28わんクラス
class 犬 interface 吠えるく{
鳴き声 bark（）{
return new わん（）；
}
}
0702デフォルトの名無しさん
2007/01/20(土) 11:44:17オブジェクト指向で表現できないものは無いｗ
あほちゃうかｗ
0703デフォルトの名無しさん
2007/01/20(土) 12:14:340704ココ電球（∩T∀T) ◆tIS/.aX84.
2007/01/20(土) 12:26:510705デフォルトの名無しさん
2007/01/20(土) 12:35:420706ココ電球（∩T∀T) ◆tIS/.aX84.
2007/01/20(土) 12:51:10ハングルが世界最高の言語だって言ってる連中と同列ですね。
0707ココ電球（∩T∀T) ◆tIS/.aX84.
2007/01/20(土) 12:51:35ハングルが世界最高の言語だって言ってる連中と同列ですね。
0708デフォルトの名無しさん
2007/01/20(土) 13:03:45こなせるようになったら、OOP的なアプローチでロジックを組めば
綺麗に効率よくコーディングできることに気が付くはずだ。
（たとえそれがOOPとして既に広く周知されたものだと知らなくても）
そこでC++などを勉強すれば、綺麗で効率の良いスタイルのコードを
自然に書けて、さらに補強する機能があることは自然と受け入れら
れるはず。
要するに、概念学習なんて自然と思いついて然るべきもので、
わざわざ他人から教えられるようなものではない。
概念学習で苦労しているのは低脳。つーかマ向きの人間じゃない。
0709デフォルトの名無しさん
2007/01/20(土) 13:14:27流石に「表現」するには厳しいモノも無くはないだろう。OOが万能とは思わない。
それまでのプログラミングより表現の幅は大きいと思うけど。
0710デフォルトの名無しさん
2007/01/20(土) 13:23:450711デフォルトの名無しさん
2007/01/20(土) 13:53:50>要するに、概念学習なんて自然と思いついて然るべきもので、
>わざわざ他人から教えられるようなものではない。
どちらが効率的かということだろ。既に他人が知っていることを
わざわざ自分で再発見する必要はないと思うけどね。他人が考え
てくれたものはありがたくさっさと学んだ方がよほど効率的で
いいと思わないか？
0712デフォルトの名無しさん
2007/01/20(土) 15:11:42メリットが見出せなかった。
使えないとか、理解できないとかではなくて
非手続き型で十分じゃね？って感じで
でも.netやらJAVA系のエディタは便利だな
まあ、オブジェクト指向開発は
ツールありきってことかな
0713デフォルトの名無しさん
2007/01/20(土) 15:15:55ソースのインデント萌え～ってことよ。
0714デフォルトの名無しさん
2007/01/20(土) 16:22:42扱えないと思うヤツには扱えない
オブジェクト指向は難しいと思うヤツには難しい
0715デフォルトの名無しさん
2007/01/20(土) 16:25:46データ毎に処理を分けるなよと思ったところで、がちがちの密結合でThe END
0716デフォルトの名無しさん
2007/01/20(土) 16:34:44クラス＝構造化された単位
だったらそうなるがそれじゃただの機能分割だｗ
クラスが共通関数のまとめ役って言う考えはＯＯ的ではない
0717デフォルトの名無しさん
2007/01/20(土) 16:46:01クラス＝関連の強いデータと関数の塊と言うのは十分OO的
OOと言うのは結局、効率的な機能分割法にすぎない。
0718デフォルトの名無しさん
2007/01/20(土) 16:47:57初期のＯＯの考え方に近いか
ただ、クラス＝役割だ
0719デフォルトの名無しさん
2007/01/20(土) 16:50:45クラスが単なる空間定義に終わってしまっているという良い例だなぁｗ
クラスは空間定義ではあるが、ＯＯ的というにはそれだけではたりない。
0720デフォルトの名無しさん
2007/01/20(土) 16:51:36×概念的はなっそう
○概念的なアプローチ
0721デフォルトの名無しさん
2007/01/20(土) 17:00:47それでは、その足りない部分を具体的に述べてくれ。
0722デフォルトの名無しさん
2007/01/20(土) 17:02:19役割、意味論
0723デフォルトの名無しさん
2007/01/20(土) 17:04:02分割時に当然、役割、意味単位で分けるが
それじゃ駄目なん？
0724デフォルトの名無しさん
2007/01/20(土) 17:07:32実社会における役割と等価。
意味論も機能的な意味論ではない。
実社会における意味論と等価。
構造化アプローチで設計していくとソコは必ずしも一致しない。
ただ、構造化＝役割の細分化という意味なら同意できるなぁ。
0725デフォルトの名無しさん
2007/01/20(土) 17:11:420726デフォルトの名無しさん
2007/01/20(土) 17:12:12すまんが、機能的な意味と役割と
実社会における意味と役割とが
解離してる。例をあげてくれないか？
0727デフォルトの名無しさん
2007/01/20(土) 17:29:38実社会という言葉は適切ではなかったｗ
要するに、手続きからクラスを定義するのと
要件からクラスを定義するのでは、クラスの作られ方が違ってくるってこと。
ただそれもレベルの問題で、旨くできる人はそれでもうまくクラスが作れているから
厳密な違いは無いと思うけど、旨くない人が手続きからクラスを導出していくと
クラスのインターフェイスが違ってくる。
例）ある業務のシステムを作っています。
【手続き型の構造化手法】
手続きＡからクラスＢを導出しました。
その場合、クラスＢは多かれ少なかれ手続きＢに特化する。
後から手続きＣでもクラスＢが持つデータを使うことがわかりました。
でも、クラスＢのインターフェイスは手続きＢようなので、手続きＣ用のインターフェイスを
作りました。
【ＯＯ的手法】
業務の役割や意味からクラスＢを導出しました。
クラスＢには、業務を実行するインターフェイスＤがありました。
業務の手続きＡ、ＣはクラスＢのインターフェイスＤを使うように実装する事にしました。
0728デフォルトの名無しさん
2007/01/20(土) 17:40:24ありがとう、なんとなくわかった、しかし
そういう話なら、もっと以前の構造化プログラムの
モジュールでも同じだと思うけど、モジュールBが手続きA、C
どちらでも、そのまま使えるような設計が構造化でも
良い設計のはず。
0729デフォルトの名無しさん
2007/01/20(土) 18:56:56構造化とＯＯの決定的な違いは抽象化
0730デフォルトの名無しさん
2007/01/20(土) 18:57:59構造化がオブジェクト指向特有の手法だと思ってたとかいうオチじゃないよね・・・？
0731デフォルトの名無しさん
2007/01/20(土) 19:07:29だがそれだけでＯＯとはいえない
0732デフォルトの名無しさん
2007/01/20(土) 19:08:56抽象化すれば、問題ないの？
なら、機能分割時に、役割に応じて
共通部分を親抽象クラスなりインターフェイス（Javaなもんで）
なり抽出して作成すればOK？
0733デフォルトの名無しさん
2007/01/20(土) 19:10:500734デフォルトの名無しさん
2007/01/20(土) 19:12:12手っ取り早くはデザインパターンとかを勉強してみるといいんじゃない？
0735デフォルトの名無しさん
2007/01/20(土) 19:20:55デザパタは、実務で使ってるよ。
TemplateMethodとかVisitorとかFactoriyMeyhodとか、
良く使う。
0736デフォルトの名無しさん
2007/01/20(土) 19:39:04実務レベルの話は、それなりにわかるんだが
その上のOO道みたいな、哲学的な部分がさっぱりわからん。
0737デフォルトの名無しさん
2007/01/20(土) 19:45:18変に構えなくても良いんじゃね？
しょせん継承・カプセル化・情報隠蔽が出来てりゃ C++ では OO なんだし。
0738デフォルトの名無しさん
2007/01/20(土) 19:52:20やっぱり、構えなくて良いんかね。
でも、OO的で無いとか観念的なアプローチをしろとか
言われたんで気になってね。
0739デフォルトの名無しさん
2007/01/20(土) 19:55:02File Input Parse Queue Timer Output
言葉と実装とでE-Rが変わらないようにすると管理しやすいんだよね。
OOに慣れると疎結合を意識しだす嬉しい恩恵も得られる。
C言語使ってるときでもOOは意識するもんだけどね。
0740デフォルトの名無しさん
2007/01/20(土) 20:13:30図に描いてみたけど上の構造化手法の例の問題点がよく分からん
http://www.borujoa.org/upload/source/upload9881.gif
0741デフォルトの名無しさん
2007/01/20(土) 20:15:43何でデータが手続きを参照してるの？ｗ
0742デフォルトの名無しさん
2007/01/20(土) 20:22:17構造化手法からオブジェクトを導出するならこんな感じになるのかなってのを
想像して図にしてみただけだよ。
その矢印はデータの流れを表してると考えてくれ。
0743デフォルトの名無しさん
2007/01/20(土) 20:52:55>>727の問題点は、本来１つですむインターフェイスが手続きごとに複数実装しなければならんて事。
共通的に使われるものが、個別の要件に応じてインターフェイスを変更するのはおかしいんでは？
0744デフォルトの名無しさん
2007/01/20(土) 21:05:28普通の設計だと思うけど、>>727の説明は何が言いたいのか理解しづらい。
0745デフォルトの名無しさん
2007/01/20(土) 21:13:12＞データが同じなら１つのクラスでメソッドで処理を分けるのがオブジェクト指向的にも・・・
データとは？
この時点でＯＯではない
そういうのがわからないから概念から学ぶべきだといっている
ただ、判らないからといって実務で直接的に問題になるか？っと言われれば、状況による。
どんなに生産性が悪くても、それで成り立ってれば問題はないのでは？
0746デフォルトの名無しさん
2007/01/20(土) 21:15:16両方同時に
がいいのでは？
0747デフォルトの名無しさん
2007/01/20(土) 21:25:14IntegerやStringから、List、HttpRequest、Bitmap、Window、、、、。
世の中にはデータみたいなオブジェクトが腐るほど溢れてるけど、これらはOOじゃないのか？
0748デフォルトの名無しさん
2007/01/20(土) 21:29:410749デフォルトの名無しさん
2007/01/20(土) 21:30:51分からないから説明してよ。あなた自身の言葉で。
0750デフォルトの名無しさん
2007/01/20(土) 21:32:03intもオブジェクト、言語仕様に振り回されるな。
0751デフォルトの名無しさん
2007/01/20(土) 21:36:150752デフォルトの名無しさん
2007/01/20(土) 21:41:430753デフォルトの名無しさん
2007/01/20(土) 21:43:08オブジェクトではないと定義すれば int はオブジェクトではない
0754デフォルトの名無しさん
2007/01/20(土) 21:43:450755デフォルトの名無しさん
2007/01/20(土) 21:43:460756デフォルトの名無しさん
2007/01/20(土) 21:44:410757デフォルトの名無しさん
2007/01/20(土) 21:48:110758デフォルトの名無しさん
2007/01/20(土) 21:52:26オブジェクト指向の学習としては概念中心に行うべきか？
0759デフォルトの名無しさん
2007/01/20(土) 21:58:16ここの、やりとりを見れば自明かと。
大体明確な解すらないのだから、
学者が研究でやれば良いレベル初心者には、まったく必要ない
0760デフォルトの名無しさん
2007/01/20(土) 21:58:45Javaですらint.classが存在する。ちなみにInteger.classとは別物。
0761デフォルトの名無しさん
2007/01/20(土) 22:11:04そうそう
で、そういう奴らは指示されたようにコーディングだけしてれば良いのだｗ
0762デフォルトの名無しさん
2007/01/20(土) 22:15:45OOは文系のための言語という考えがあるが、あながち間違っていない。
0763デフォルトの名無しさん
2007/01/20(土) 22:33:45プログラムが書けない奴は日本語もダメ。
もちろん、日本人の話なw
0764740
2007/01/20(土) 22:48:38こうやって見るとオブジェクト指向っぽく見えない？
http://www.borujoa.org/upload/source/upload9885.gif
0765デフォルトの名無しさん
2007/01/20(土) 22:58:15Ｃ＋＋やＪａｖａの開発を一緒にやったりする経験が多くあるが、オブジェクト
指向に背を向けている人は最後まで理解する事はできなかったね
結局その人たちは元の古巣へもどって逝ったよ。
0766デフォルトの名無しさん
2007/01/20(土) 23:04:49それは、やる気や適正の問題で観念学習をしてないからじゃ
無いでしょう？俺の経験では言語学習だけで、使いものになる人は
いても、観念学習だけでまともな設計ができる様になった人は
見たことないな。
0767デフォルトの名無しさん
2007/01/20(土) 23:12:17ちがう
言語は覚えようとしていた
だが概念を覚えようとはしなかった
だから結局何がなんだかわからなくて挫折した
概念がわからない状態でＯＯＰＬ使って作ったプログラムは
ただの手続き型プログラムだろ
Ｊａｖａを使ってＣ言語や、ＣＯＢＯＬを書こうとしているだけ
0768デフォルトの名無しさん
2007/01/20(土) 23:14:41期限付きで結果を出さなきゃならないような状況では、
形はともかく動くものが出来ればいいからな
ただそれはオブジェクト指向技術を使って開発したプログラムではない
0769デフォルトの名無しさん
2007/01/20(土) 23:18:41継承も、カプセル化・隠蔽もきちんと使ってたぜ
どのあたりがOOじゃ無いのか、さっぱりわからないんだが
OOの条件を書いてもらえないか？
0770デフォルトの名無しさん
2007/01/20(土) 23:20:18＞継承も、カプセル化・隠蔽もきちんと使ってたぜ
っていうかその人は概念を持っているんじゃないの？
0771デフォルトの名無しさん
2007/01/20(土) 23:21:23っていうか、オレが見た人をおまいが知ってるんかよｗ
0772デフォルトの名無しさん
2007/01/20(土) 23:24:55概念を特別に勉強しなくたって自然と習得できる人もいるだろうし、
そうでない人もいるだろうねぇ
特定の人間が出来るからって万人が出来るとは限らん。
0773デフォルトの名無しさん
2007/01/20(土) 23:27:21コードを書く上での観念だけだよ。
OOの哲学なんてのは、まったく教えてない。
不必要な情報は出さない。同じ役割の物は、
抽象クラスを作ってインターフェイスを同じにする。
書き方が違うだけで、構造化でも同じだと言ってたよ。
0774デフォルトの名無しさん
2007/01/20(土) 23:28:23同じくC言語に熟練した同僚と違いOOPにも戸惑わなかった。
何に違いがあるのか考えてみると、
俺は普段からそういう思考で過ごしているからだという結論に落ち着いた。
言語適正＝生活習慣。これだね。
0775デフォルトの名無しさん
2007/01/20(土) 23:32:57オレもＣとかＣＯＢＯＬしかやったことの無い人にはそう教えるよ
0776デフォルトの名無しさん
2007/01/20(土) 23:35:09言語学習と言うか実際にコード書かせて学習させるのが
一番だと思う。良いコードを見せてこうやったほうが安全とか
便利とか、実例で学ばせてゆく、英語とかでも文法いくらやっても
話せる様にはならないじゃん
0777デフォルトの名無しさん
2007/01/20(土) 23:35:54そんなの見たこと無いけどな。
0778デフォルトの名無しさん
2007/01/20(土) 23:38:08なぜソコでクラスを分ける必要があるのか？とか
そういう素朴な疑問にはどうやって答えるの？
概念の説明無しで
0779デフォルトの名無しさん
2007/01/20(土) 23:40:22最初はこれくらいで教えておくのが楽。
0780デフォルトの名無しさん
2007/01/20(土) 23:43:46Cやってた人は、早い場合は異様に早いよ
３日もしない内に、実務で使ってみたいから、
適当な仕事無い？とか聞いてくる
まぁ、それで頼んだ結果をみると、
Cのヘッダみたいな定数クラスがあったり
ツッコミ何処それなりにあったりするけど。
動くことはキチンと動く
0781デフォルトの名無しさん
2007/01/20(土) 23:46:030782デフォルトの名無しさん
2007/01/20(土) 23:46:04プログラムが書けるようになるだけなのでは？
0783デフォルトの名無しさん
2007/01/20(土) 23:47:39プログラムが書けるようになることがゴールじゃないだろｗ
スレ違いもいいところｗ
0784デフォルトの名無しさん
2007/01/20(土) 23:48:19オブジェクト指向が理解できてると言える条件を
教えてもらわないと、なんとも言えない。
0785デフォルトの名無しさん
2007/01/20(土) 23:50:49>>784自信はオブジェクト指向が理解できてて、
それはプログラムが書けさえすれば達成できるものだ、
という理解でいいの？
0786デフォルトの名無しさん
2007/01/20(土) 23:56:59微妙に違う、オブジェクト指向の理解できてるかどうか
なんかは誰にもわからない。ので実質、
保守性の生産性が高い設計、及び、プログラムが書ける事のみが
重要と言いたい
0787デフォルトの名無しさん
2007/01/20(土) 23:58:10基準といえるか判らんが、
デザインパターンの知識が無くて設計しても、デザインパターンにマッチした設計が出来るようなら
割とオブジェクト指向を理解しているといえるのでは？
0788デフォルトの名無しさん
2007/01/20(土) 23:59:39だがそれはスレの趣旨とあってないだろ？
0789デフォルトの名無しさん
2007/01/21(日) 00:03:270790デフォルトの名無しさん
2007/01/21(日) 00:04:440791デフォルトの名無しさん
2007/01/21(日) 00:09:49デザパタ＝OOなのか？
それこそ実装よりの技術でOOの概念とは違う気がするが
それはともかく教えれば、適切に使う様になる
場合が多いけど、教えずに使ってるのは、無いかも
TemplateとかVisitorとかは、継承の説明で教えちゃうしなぁ
これは、実装の話だから、設計だとどうだろうな、
実装おしえてから設計教えるからわからん。
0792デフォルトの名無しさん
2007/01/21(日) 00:11:15１クラスはpublicメソッド数が１０個以内
１メソッドのコード行数が１００行以内
１クラスの行数が２００行以内
この条件でプログラムを作れるかどうか？
0793デフォルトの名無しさん
2007/01/21(日) 00:17:06デザインパターンは役割の関係の雛形
これに近い適切な役割の関係が導出できるかどうかが問題
それには役割自体が適切に割り当てられているか？っという事も含まれてる
0794デフォルトの名無しさん
2007/01/21(日) 00:18:29本当にそんな実装よりの評価で良いのか。
しかも、その条件で、たぶんOO的で無い
クラスを幾らでも作れるし、設計できるよ。
0795デフォルトの名無しさん
2007/01/21(日) 00:22:36デザパタが自然に使えてるかと言えば使えてるな。
だいたいデザパタって機能レベルの関係でもつかえるから
このスレ的には、OOとあまり関係ないんじゃないか？
0796デフォルトの名無しさん
2007/01/21(日) 00:22:36ある側面からの機械的な評価でしかない。
でも、ＯＯ的な考えを持ってない人はこの基準に収まる、”意味のあるプログラム”はかけないと思うね。
0797デフォルトの名無しさん
2007/01/21(日) 00:26:14そんな事はないぞ、メソッドの長さは、Cでも短い方が良いし
モジュールもそうだから、極論すればCのモジュールを
そのままクラスにしたような物でもとおるよ。
0798デフォルトの名無しさん
2007/01/21(日) 00:30:220799デフォルトの名無しさん
2007/01/21(日) 00:31:56メトリクスをクリアするため、ってのは問題外ｗ
0800デフォルトの名無しさん
2007/01/21(日) 00:35:09はっきりしたんじゃないｗ
0801デフォルトの名無しさん
2007/01/21(日) 00:35:09こんなもんJDKのクラスライブラリだけ見ても該当しないコードだらけやん
0802デフォルトの名無しさん
2007/01/21(日) 00:37:07モジュールをそのままクラスにしたのだから
機械的にモジュール分割を行わなっていなければ
当然、例えば、ネットアクセスモジュールとか
意味はあるだろう。
>>799
たとえば、上の例だと
ネットアクセスする関数郡って意味はあるよね。
0803デフォルトの名無しさん
2007/01/21(日) 00:39:44class NetAccessMethods1
class NetAccessMethods2
class NetAccessMethods3
とか作ってそれぞれメソッド１０個ずつ？ｗ
0804デフォルトの名無しさん
2007/01/21(日) 00:47:21それは、機械的な訳かただから違う
NetAccessToA_Machine
NeTAccessToB_Machine
NetAccessCommon
Aマシンへの、アクセス用
Bマシンへの、アクセス用
上記の共通部分
って感じのモジュール
0805デフォルトの名無しさん
2007/01/21(日) 00:48:49ｗ
class Connection
class Protocol
class Message
見たいなクラスくらい作って欲しいもんだ
0806デフォルトの名無しさん
2007/01/21(日) 00:50:390807デフォルトの名無しさん
2007/01/21(日) 00:52:00このクラス設計を見て、オブジェクト指向を理解しているとはお世辞にもいえんなｗ
申し訳ないけどｗ
0808デフォルトの名無しさん
2007/01/21(日) 00:52:31理解しているとはいっていなかったね
0809デフォルトの名無しさん
2007/01/21(日) 00:53:08おやすみー
0810デフォルトの名無しさん
2007/01/21(日) 00:57:21だから>>804みたいな明らかに駄目なクラス分けでも
メトリックス通ってしまうよって例だから
0811デフォルトの名無しさん
2007/01/21(日) 00:59:53日本語ができない人だったのか。
気付かなかったよ。
0812デフォルトの名無しさん
2007/01/21(日) 01:06:29あそっかｗ
ゴメンよｗ
ホイじゃホントにおやすみー
0813デフォルトの名無しさん
2007/01/21(日) 01:09:30こちらこそ、眠いとこ煽って悪った
おやすみ
0814デフォルトの名無しさん
2007/01/21(日) 08:46:07http://ja.wikipedia.org/wiki/%E8%A3%B8%E3%81%AE%E7%8E%8B%E6%A7%98
0815デフォルトの名無しさん
2007/01/21(日) 10:58:180816デフォルトの名無しさん
2007/01/22(月) 01:13:23そしてそこから、集合に属するオブジェクト、インスタンスという考え方で
実体を形成してそれらを「扱う」体系を言語化した。
それらに、継承や抽象化などの性質を浮き彫りにして強調することで
「オブジェクト指向」という概念を改めて定義した、ということではない
でしょうか。
0817デフォルトの名無しさん
2007/01/22(月) 01:18:25Globalメンバー（変数、関数）の方が特異な存在になっていると思う。
それらは型、集合に属するというものの、インスタンスではないから
スーパーな存在、実物存在に対する、神、あるいは法則、あるいは
イデア的な存在となっているため、
「オブジェクト指向」のなかでも「オブジェクト的でない」存在が結局
このStaticでsharedな存在ではないかと。
0818デフォルトの名無しさん
2007/01/22(月) 01:24:260819デフォルトの名無しさん
2007/01/22(月) 02:16:17staticなものをいちいちインスタンスにするのがバカバカしいからだお
バカは概念にこだわる
かしこいやつは目的を失わず、「言語」を学習する
0820デフォルトの名無しさん
2007/01/22(月) 02:22:56バカは2chの煽りにこだわる
かしこいやつは目的を失わず、「成果」を持ち帰る
0821デフォルトの名無しさん
2007/01/22(月) 11:51:54どのようにクラスを定義しますか？
「カード」クラスにはどんなメソッドを定義しますか？
カードを置く時、それはその場所に置けるのか否かの判定を
どのクラスのどのメソッドで行いますか？
表示するカード絵はどのクラスが保持しますか？
0822デフォルトの名無しさん
2007/01/22(月) 12:00:350823デフォルトの名無しさん
2007/01/22(月) 12:07:08カードクラスをインターフェースにするところから始めるよ。
0824デフォルトの名無しさん
2007/01/22(月) 12:24:43自分のもっている本を見ると、Cardクラスは
int getNumber();
int getSuit();
String toString();
の3つ。
ルールクラスがあって、
Card[] findCandidate(Hand hand, Table table);
で置ける場所の候補（トランプのスートとナンバー）を探すようになっている。
0825デフォルトの名無しさん
2007/01/22(月) 12:26:030826デフォルトの名無しさん
2007/01/22(月) 13:11:43カードクラスを純粋クラスとしてカードの操作メソッドを定義。
カード絵クラスでカードの絵柄1枚と縦横サイズ等を保持。絵柄の読み込みもこのクラスにさせる。
トランプカードクラスはカードクラスを継承しコピーコンストラクタで裏のカード絵と表のカード絵の2個のカード絵オブジェクトをスートとナンバーと一緒に入力してそれが何のカードかを決める。
トランプカードクラスは入力されたカード絵オブジェクトを実体ではなく参照で保持する（つまりポインタで保持する）。
トランプカード集合クラスでトランプカードの裏の絵と５４枚の表の絵計５５個のカード絵オブジェクトを生成した後５４個のトランプカードオブジェクトを生成する。
七並べゲームクラスはトランプカード集合オブジェクトを保持する。
ってどうよ？
0827デフォルトの名無しさん
2007/01/22(月) 14:18:41トランプゲーム詰め合わせへの路線変更や
絵柄切替機能付けろって仕様追加はありそうだな
0828デフォルトの名無しさん
2007/01/22(月) 15:03:100829デフォルトの名無しさん
2007/01/22(月) 15:47:02D言語は知らない。
オブジェクト指向を習いたいならJavaからした方がいいと思う。
オブジェクト指向系の書籍は、Javaで例を挙げているのが多いから。
自分もRubyを習おうと思って始めたけど、結局Javaの方を先に習得していたし。
0830デフォルトの名無しさん
2007/01/22(月) 18:01:34なぜかそのトランプゲーム詰め合わせ仕様書にはトランプタワーが入っていたり
さあ物理エンジンを作ろうｗ
0831デフォルトの名無しさん
2007/01/22(月) 19:45:05やぱ分け分かんなくなってる奴が多いのか？
0832デフォルトの名無しさん
2007/01/22(月) 20:36:43七並べ用トランプカードクラスも作る
0833デフォルトの名無しさん
2007/01/22(月) 20:50:46標準クラスにも
使い道の分からないのはあるぞ？
0834デフォルトの名無しさん
2007/01/22(月) 21:27:540835デフォルトの名無しさん
2007/01/22(月) 23:46:24ちゃんとモデリングセーや
0836デフォルトの名無しさん
2007/01/23(火) 00:07:37そう思うならモデリング例を上げれや。
批判だけなら猿でもできる。
0837デフォルトの名無しさん
2007/01/23(火) 17:38:20より YAGNI 感を醸すために、トランプと花札を同じコンテナに格納できないように template にするべきだと思う
0838デフォルトの名無しさん
2007/01/23(火) 23:32:43>神とかイデアとかじゃなくって便利だからだお
>staticなものをいちいちインスタンスにするのがバカバカしいからだお
便利といって何でもご都合主義で入れていけばいいならそもそも
オブジェクト指向でなくてもいいということにもなるが
オブジェクト指向であるのにオブジェクト的ならぬ存在に支えてもらわないと、
実際に本当には便利にならない、、
という現実があるのだ、という風にとらえないと、物事の限界や長所と短所
という考え方の意味がなくなる
イデアや普遍法則があっていつでも自由に適用できるようになってないと
不便な現物世界になる、つまり現物は機能的に不全だといえるかもしれない
0839デフォルトの名無しさん
2007/01/24(水) 21:44:560840デフォルトの名無しさん
2007/01/25(木) 21:07:550841デフォルトの名無しさん
2007/01/25(木) 21:21:12それがクラスなら、お前がクラスと呼ぶものは全てクラスだよ。
0842デフォルトの名無しさん
2007/01/25(木) 21:22:02継承どうするんですか？まクラス使いたいのなら、すなおにC#に汁
ところで、住人様方
VBやVC#でさくさくプログラミングしようかなーと思ってるんですが
オブジェクト指向理解してないと、やっぱりプログラミングむりぽですか？
0843デフォルトの名無しさん
2007/01/25(木) 21:23:00やれんことは無いらしい。
http://www.sage-p.com/process/cool.htm
0844デフォルトの名無しさん
2007/01/25(木) 22:38:11.> それがクラスなら、お前がクラスと呼ぶものは全てクラスだよ。
それがクラスなら、プログラムと呼ばれるもの全てクラスだよ。
こっちの方がいいよ。
0845デフォルトの名無しさん
2007/01/25(木) 23:04:070846デフォルトの名無しさん
2007/01/25(木) 23:05:380847デフォルトの名無しさん
2007/01/25(木) 23:31:24オブジェクト指向言語はC言語で開発できる
C言語 is King of プログラム言語ｓ だ！
0848デフォルトの名無しさん
2007/01/25(木) 23:37:430849デフォルトの名無しさん
2007/01/26(金) 01:36:17その理論だとアセンブラ最強な件
0850デフォルトの名無しさん
2007/01/26(金) 01:40:04機械語最強です
0851デフォルトの名無しさん
2007/01/26(金) 01:40:360852デフォルトの名無しさん
2007/01/26(金) 01:43:12ttp://hp.vector.co.jp/authors/VA015412/
0853デフォルトの名無しさん
2007/01/26(金) 01:45:24反応すんなほんたま
0854デフォルトの名無しさん
2007/01/26(金) 02:32:480855デフォルトの名無しさん
2007/01/26(金) 02:36:480856デフォルトの名無しさん
2007/01/26(金) 08:08:500857デフォルトの名無しさん
2007/01/26(金) 08:40:22いや、>840 は一応 vtable くらいは用意するつもりなんだろうから。
0858デフォルトの名無しさん
2007/01/26(金) 12:23:190859デフォルトの名無しさん
2007/01/26(金) 16:48:26参考書によってはそうでもないけど。
0860デフォルトの名無しさん
2007/01/26(金) 21:45:360861デフォルトの名無しさん
2007/01/26(金) 22:36:244000行あるようなクラス書いてないか？
やたらif分がネストしてないか？
0862デフォルトの名無しさん
2007/01/26(金) 22:43:210863デフォルトの名無しさん
2007/01/26(金) 22:56:24プログラムは内部が糞であっても、要求を満たしてれば合格
逆に内部がどんなに素晴らしくても、要求を満たしていなければ不合格
よって、
4000行あるようなクラスで、且つ、やたらif分がネストしてたとしても
要求を満足していればOK
0864デフォルトの名無しさん
2007/01/26(金) 22:57:380865デフォルトの名無しさん
2007/01/26(金) 22:59:03こういうセリフはよく職業プログラマが使うが
職業プログラマほど使ってはいけない言葉
0866デフォルトの名無しさん
2007/01/26(金) 23:00:44そして保守・運用作業が困難な事が目に見えているため、転職。
0867デフォルトの名無しさん
2007/01/26(金) 23:07:07ついでに、要求を満たしてない物に金は払えない、とも言われた
0868デフォルトの名無しさん
2007/01/26(金) 23:08:20そんなの当たり前だハゲ
0869デフォルトの名無しさん
2007/01/26(金) 23:09:540870デフォルトの名無しさん
2007/01/26(金) 23:11:13クラス名がDF000001とか（ｗ
0871デフォルトの名無しさん
2007/01/26(金) 23:19:16>>863, >>867を言われたってわけよ、納期も大事な要求事項だからな
0872デフォルトの名無しさん
2007/01/26(金) 23:21:36それは単にお前がオブジェクト指向に慣れていないのが原因なだけでは
0873デフォルトの名無しさん
2007/01/26(金) 23:22:460874デフォルトの名無しさん
2007/01/26(金) 23:34:54移植作業なんてものはそういうものだ。
読みやすくするのはリファクタリング作業。
0875デフォルトの名無しさん
2007/01/26(金) 23:48:25構造化設計のままリファクタリングなどできない。
0876デフォルトの名無しさん
2007/01/26(金) 23:51:400877デフォルトの名無しさん
2007/01/26(金) 23:56:390878デフォルトの名無しさん
2007/01/26(金) 23:58:340879デフォルトの名無しさん
2007/01/27(土) 00:00:22リストラクチャリングはリファクタリングの部分集合。
0880デフォルトの名無しさん
2007/01/27(土) 00:02:35http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
0881デフォルトの名無しさん
2007/01/27(土) 00:02:53あまり聞かないねぇ。こういう事はリファクタリングというんだよ。おぼえとけ
0882デフォルトの名無しさん
2007/01/27(土) 00:10:26要するに、Martin Fowlerは、リファクタリングの粒度の事で言い方を変えたいだけじゃないの？
そんな短絡的な趣味に付き合いたくもない。
0883デフォルトの名無しさん
2007/01/27(土) 00:17:47あほなの？
0884デフォルトの名無しさん
2007/01/27(土) 00:22:35まあ、この手の連中は用語作って商売するからな
0885デフォルトの名無しさん
2007/01/27(土) 10:57:24ある意味SUNの陰謀だｗ
0886デフォルトの名無しさん
2007/01/27(土) 11:07:390887デフォルトの名無しさん
2007/01/27(土) 11:13:51１．条件分岐と反復文のみを用い、基本的に上から下へと制御が進む
２．類似した処理は関数としてまとめる
だよね？
0888デフォルトの名無しさん
2007/01/27(土) 11:24:540889デフォルトの名無しさん
2007/01/27(土) 11:27:53実は、構造化指向は参考書の中で聞いたことがあるだけで実際には
あんまり知らない。ただ構造化指向が染み付いた人はオブジェクト指向に脳みそ
切り替えるのは厳しいかな。と
0890デフォルトの名無しさん
2007/01/27(土) 11:42:39「構造化志向」って何？
いや、
そんな細かな書き間違いの話なんかよりも、
むしろ >>889 の言う「志向」が、
何を指すのかを聞きたいな。
・・・いやいや、
そんな細かな書き間違いの話なんかよりも、
むしろ >>889 の言おうとしたであろう「指向」が、
何を指すのかを聞きたいな。
例えば、「オブジェクト指向」でいう「指向」とは何なのか？
とかさ。
0891デフォルトの名無しさん
2007/01/27(土) 11:49:26「デザインパターン」の一種だと思う。
0892デフォルトの名無しさん
2007/01/27(土) 12:06:12デザインパターンはオブジェクト指向のサブセットだろ
0893887
2007/01/27(土) 12:12:48の記述は、（１．制御の流れ）に相当するよね？
オブジェクト指向は主に全体を見通しての設計技法であり、構造化は実際の制御文を書く
ときの技術って感じで、別に相反するものでもないと思うんだけど。
で、構造化しか知らない人は、全体の設計も構造化（制御中心）でしてしまうと。
0894デフォルトの名無しさん
2007/01/27(土) 12:14:14いや、逆だと思う。
要するに「デサインパターン has-a オブジェクト指向」。
GoF に「オブジェクト・パターン」なんてのが載っていても
全然おかしくないような気がする。
0895デフォルトの名無しさん
2007/01/27(土) 12:19:05ばかですか？
0896デフォルトの名無しさん
2007/01/27(土) 12:33:17勘違いしないでほしいが、俺は別に「デサインパターン」が凄い！
なんて思っていない。
あれはプログラミング上で頻出する、枯れたイディオムを羅列したものだ
（ただし形式上、「OOP による」という条件付、だがね）。
OOP も所詮は「プログラミング上のイディオム」だよ。
0897デフォルトの名無しさん
2007/01/27(土) 12:42:02>>895は誰のカキコも読まないただの荒らしだからレスを返さなくてもいいよ
0898デフォルトの名無しさん
2007/01/27(土) 12:44:080899デフォルトの名無しさん
2007/01/27(土) 12:45:400900デフォルトの名無しさん
2007/01/27(土) 13:48:39よくいるんだが、構造化定理と構造化技法がごっちゃになってる。
構造化技法ってのは、特定のパラダイムというよりは、いろんな宣教師が各人勝手なことを吠えてただけに近い（これはオブジェクト指向○○も一緒だけど）。
シンプルな設計をするためのイディオム集みたいなかんじ。
データフローグラムなんてのもあったりして、データ中心の分析設計も構造化時代からあった。
データ + アルゴリズム = プログラム なんてのも構造化時代からのものだし。
モジュール化の話題では、pimpl に似た技法を使っての実装隠蔽の話などもあった。
OOが設計で構造化がコーディングと断絶したものではない。
OOは方針の違う構造化のスーパーセットみたいなもんだ。
0901デフォルトの名無しさん
2007/01/27(土) 13:52:100902デフォルトの名無しさん
2007/01/27(土) 13:55:30ああ、そうだな。
それと、現代において
まともなソフトウエア工学なんてものがあると
思っているのもお前だけだよ。
0903デフォルトの名無しさん
2007/01/27(土) 14:02:300904デフォルトの名無しさん
2007/01/27(土) 14:10:56答えを言ってやろう
電子工学の基礎→ディジタル回路→チューリングマシン→コンピュータの仕組み→機械語→アセンブラ→C言語→構造化設計→Pascal→C++→オブジェクト指向設計技法→Java→Lispと平行してラムダ計算を勉強→MLと平行してコンパイラを設計→Haskell
0905デフォルトの名無しさん
2007/01/27(土) 14:22:36つきつめれば最も実践的な宗教かな。
一つの世界観を創造してしかもそれを実装しているんだから。
0906デフォルトの名無しさん
2007/01/27(土) 17:42:14オブジェクト指向＝構造化にしたいってことを言いたいスレに変ったって事か
0907デフォルトの名無しさん
2007/01/27(土) 18:00:15算数→数学→物理→量子→電気→電子工学の基礎→ …
0908デフォルトの名無しさん
2007/01/27(土) 18:19:340909デフォルトの名無しさん
2007/01/27(土) 18:29:50構造主義って哲学が大流行した時代があって、哲学以外の分野でも新しい概念や
手法の頭に「構造化～」って言葉をとりあえず付けるのが流行ってたってだけで、
お前さんのいうダイクストラの構造化プログラミングとはまったく関係ないよ。
0910デフォルトの名無しさん
2007/01/28(日) 15:23:38「類似した処理は関数としてまとめる 」
なんてことは言っていない。
あえて換言すれば
「全論理を構造化する」
かと
0911デフォルトの名無しさん
2007/01/28(日) 17:03:47へっけんろぴゅろぴゅ～
あわ～
へっけんあわ～
0912デフォルトの名無しさん
2007/01/28(日) 22:33:570913デフォルトの名無しさん
2007/01/30(火) 01:05:35「オブジェクト指向の概念の発明者は誰ですか？」
ttp://d.hatena.ne.jp/sumim/20040525/p1
3番目のクックのオブジェクト指向に興味があるんだが、
いまいち理解できずorz
0914デフォルトの名無しさん
2007/01/30(火) 09:35:35おまえのせいじゃないから
原文を当たった方がいいよ
引用者が日本語を扱うのが下手だとしか思えん
↓
抽象データ型が「型」による抽象化なのに対して、
オブジェクト指向は「手続き」によりそれを行なう対極の手法
（つまり“2”のオブジェクト指向の言うところとは違い、
両者はサブセット／スーパーセットの関係にはない）と位置づけていて興味深いです。
この文脈においては、もし“オブジェクト指向”したいと思うならば、
けっして this（や、self）の型を見て条件分岐をするような仮想関数
（や、メソッド）を書いてはいけない…ということが、よりはっきりと認識できるはずです。
0915デフォルトの名無しさん
2007/01/30(火) 13:02:58>>914 の言うように論文を当たるのがベストだけれど、端的には…
データの「型」を見て、相応しい「手続き」をするよう条件分岐みたいな処理をする
関数を書かないといけないのが、「型」による抽象化（クックの言う抽象データ型）。
「型」ごとに同名の関数を定義できて、それぞれその「型」に相応しい「手続き」を
記述するだけでいいのが、「手続き」による抽象化（クックの言うオブジェクト指向）。
前者だと、既存の「型」にかかわる「手続き」を新たに追加するときに、新しい
関数をひとつ定義すればよく、既存の関数にはいっさい手を加える必要がないので有利。
この場合、後者では、各「型」に追加した「手続き」に対応する関数を追加しないといけない。
逆に、既存の「型」と同じインターフェイスを備えた新しい「型」を追加したいとき、
後者が有利。前者では、すべての既存の関数に新しい「型」に対してどのような
「手続き」をするのかの判断を追加しないといけないから。
説明しようとすると、けっこう難しいな。ｗ
0916デフォルトの名無しさん
2007/01/31(水) 01:25:12オブジェクト指向の”オブジェクト”＝状態って言うのは、いまひとつ手狭な感じがして仕方が無い
0917デフォルトの名無しさん
2007/01/31(水) 01:28:08それだけではない、という意味
0918デフォルトの名無しさん
2007/01/31(水) 01:45:170919デフォルトの名無しさん
2007/03/20(火) 01:23:420920デフォルトの名無しさん
2007/03/28(水) 01:37:450921デフォルトの名無しさん
2007/04/17(火) 23:49:250922デフォルトの名無しさん
2007/04/19(木) 23:32:18そうだな。たしかにいい感じに熟してきた頃合。
でも、これは材料としてであって、まだまだ料理の工夫が必要だろうけど。
0923デフォルトの名無しさん
2007/04/20(金) 15:15:140924デフォルトの名無しさん
2007/04/21(土) 14:37:23開拓者は開拓者の道を歩んでもらわなきゃ困るけど
0925デフォルトの名無しさん
2007/04/21(土) 14:47:460926デフォルトの名無しさん
2007/04/21(土) 15:12:020927デフォルトの名無しさん
2007/04/21(土) 15:26:580928デフォルトの名無しさん
2007/04/21(土) 21:25:120929デフォルトの名無しさん
2007/04/23(月) 03:14:460930デフォルトの名無しさん
2007/04/25(水) 06:08:560931デフォルトの名無しさん
2007/04/25(水) 07:39:11URL：http://pc11.2ch.net/test/read.cgi/tech/1073714172/
【糞スレランク：ＳＳ】
直接的な誹謗中傷：29/930 (3.12%)
間接的な誹謗中傷：650/930 (69.89%)
卑猥な表現：8/930 (0.86%)
差別的表現：7/930 (0.75%)
無駄な改行：1/930 (0.11%)
巨大なＡＡ：8/930 (0.86%)
by 糞スレチェッカー Ver0.72 http://kabu.tm.land.to/kuso/kuso.cgi
0932デフォルトの名無しさん
2007/04/25(水) 11:04:58最近ではマルチエージェント指向なんて呼ばれているらしいけど。
0933デフォルトの名無しさん
2007/06/23(土) 07:31:270934デフォルトの名無しさん
2007/07/08(日) 08:46:32構造化プログラミング以前に、
入力-->処理-->出力
という古典的プログラムの概念すら無いから困る。
0935デフォルトの名無しさん
2007/07/08(日) 09:06:39軽薄で内容の無いバブル的なスローガンだったな。
0936デフォルトの名無しさん
2007/07/08(日) 09:07:060937デフォルトの名無しさん
2007/07/08(日) 09:11:49このスレには初めて書き込むんだがな。
低脳なオブジェクト指向信者が監視してるのか、ご苦労さんｗ
0938デフォルトの名無しさん
2007/07/08(日) 09:47:19「カプセル化による隠蔽、スレッドとの親和性によって、結果的に逐次的プログラミングのパラダイムを駆逐したんだよね」
「関数型言語の理想を部分的にであれ実用化したという点は評価に値するね」
「そうそう。安易に構造化プログラミングと対比するのは、情報処理の変化の本質を見ていないよ」
「まさに木を見て森を見ず！」
「コードの見た目だけに拘って議論するのは、悪しき唯物史観というべきだね」
「とはいえ、人間の貧弱なインターフェイスでは、階層的名前空間による隠蔽や静的型チェックの強化がもたらした即物的な影響も甚大なのでは？」
「タイプ数の減少はプログラマの限られた思考能力をより抽象的なレベルに振り向けるからね」
「じゃあ次はエージェント指向だ！」
「どうかな？ スレッドさえ満足に扱えない人間に、協調的プログラミングのパラダイムが理解できるんだろうか」
「しばらくはオブジェクト指向のレベルにとどまるのかもしれないなぁ」
0939デフォルトの名無しさん
2007/07/08(日) 10:03:110940デフォルトの名無しさん
2007/07/08(日) 10:44:180941デフォルトの名無しさん
2007/07/15(日) 16:19:09そうそう。そうなんだ。
基礎がなくても、開発環境のお陰で、なんとなくプログラムが動くもんだから
それで満足してるみたい。
不具合は原因が突き止められないので、フラグ増やしてフタして終わり。
もう勘弁してほしい。
0942デフォルトの名無しさん
2007/07/15(日) 19:46:06コピペ＋マジックナンバー書き換えしまくり
っつーソースを見た時はびっくりした
0943デフォルトの名無しさん
2007/07/15(日) 19:48:190944デフォルトの名無しさん
2007/09/23(日) 18:43:16通りすがりデスが、3クックの～はC/C++の関数のポインタの様な事の気がする。
0945デフォルトの名無しさん
2007/09/23(日) 21:47:30そのblogで紹介されているPDFを適当に読むに、
関数ポインタではなく、Lisp(CLOS)の方が適切みたいだが。
0946デフォルトの名無しさん
2007/09/24(月) 10:44:04ま、どっちも言いたいことは分かるしたぶん間違っていないとも思う。
レス数が900を超えています。1000を超えると表示できなくなるよ。