05/04/28 23:10:28
集合論ではsetと同じような意味でclassという単語が使われる
ことがあるけど、オブジェクト指向のクラスも元々はそこからとった
言葉じゃないのかなと俺は思う。
176:デフォルトの名無しさん
05/04/28 23:30:05
>>175
正しいかもしれないがたとえ集合論と関連させたものだったとしても似た用語を援用しただけであろう
なぜならば集合論におけるクラスは他のクラスの要素にならないからだ
Smalltalkのクラスはメタクラスのインスタンスでありその点が大いに異なる
また集合論では許されない無限降下列も存在している
MetaClassのメタクラスはMetaClassのインスタンスである
177:デフォルトの名無しさん
05/04/29 05:11:02
>>174-176
２０分おきに連投ご苦労。で、結論出た？
セットとクラスの違い、
数学基礎論でいうクラスと、OO言語のクラスの違い
タイプ理論、
まで説明が終わったら、起こしてくれ。それまで一休みｗ
178:デフォルトの名無しさん
05/04/29 07:45:21
>>177
結論とは何かね？
179:デフォルトの名無しさん
05/04/29 08:09:08
>>157
忘れていた
あまりよい理解ではないが
インスタンス＝クラスのオブジェクト
で理解しても構わない
ここで言うオブジェクトももちろんオブジェクト指向言語におけるオブジェクト
すべてはオブジェクトでありクラスに従属していることを強調する場合はインスタンスという用語を使う
selfに入っているものはオブジェクトでありそれは何らかのクラスのインスタンス
180:デフォルトの名無しさん
05/04/29 08:21:05
蛇足ながら
集合論ではすべては集合（無定義概念）
何らかの集合に所属している場合は要素と呼ぶ
さらに蛇足ながら
クラス概念のある集合論の場合
すべてはクラス（無定義概念）
何らかのクラスの要素である場合は集合
181:131
05/04/29 11:13:10
>>179
慣用的に、"すべてはオブジェクト”という理解があることは承知しています。
ですが、157で述べたとおり、クラスを導出する“オブジェクト”という言葉と、
クラスから導出される“オブジェクト”という言葉は、その導出の順序性と
目的において異なる意味を持っています。
"すべてはオブジェクトである”とい論理は、じつは、ふたつの“オブジェクト”
という言葉が、それぞれ異なる意味を持った言葉でありながら、言葉の
形式的音韻的な同一性に拠ってのみ成立している論理だと思うのです。
そして、このような“オブジェクト”という技術用語の本来の意味をあいまいな
方向に誘導する学術系の論理は、オブジェクト志向プログラミングへの理解
を初手から阻害している重要な原因の一つだと考えているのです。
182:デフォルトの名無しさん
05/04/29 11:15:25
クラスとセットのちがい
クラスの定義を説明する例として、「国連」が例示されることが多い。
すなわち、
o 国連のメンバーは国々であり、
o 国のメンバーは、例えば、日本国なら日本人だが、
x 日本人は国連のメンバーではない、
という説明がされる。
しかし、セットの観点からすれば
x 日本人の集合は、いくら日本人を加わえても、
日本人の集合であって、日本国にはならない。
つまり、「男」と「女」を使った例で言えば、「男」と「女」の集合を起点にして、
「個人 」あるいは「法人」というクラスを形成するためには、
タイプ（Ｎ－１）とタイプＮ の間には、「概念の飛躍（抽象化）」が起こっているのである。
概念の一般化は論理和ではない。
183:デフォルトの名無しさん
05/04/29 11:24:35
>>181
そこに書かれた「二つのオブジェクト」とは
君の言うプログラム設計手法としての「クラスを導出するオブジェクト」と
書かれたプログラム・実際に動く際の「クラスに導出されるオブジェクト」という意味か？
そのような違いを念頭に書いたことはないし実際気にする必要があるとも思えない
184:デフォルトの名無しさん
05/04/29 11:43:24
タイプ理論
20世紀初頭、集合論を使って数学の基礎を再構築する試みが開始された。
数学基礎論の源流には、以下の３つの流派があった。
（１）論理主義 （ラッセルに代表される考え方）
（２）形式主義 （ヒルベルトに代表される考え方）
（３）直観主義 （ブラウワーに代表される考え方）
ラッセルの提示したや り方が「タイプ（type）理論」（the theory of types）である
（ラッセルの提示したタイプ理論は「分岐タイプ理論」と云うが、
ラムゼー（Ramsey F.P.）は、それを簡素化して、単純タイプ理論にした）。
ラッセルの導入したタイプ理論を要約すれば、以下の２点が主張 である。
（１）モノは、（以下に記述するように）いくつもの階層（＝型）から構成されている
（これを、 「高階」の構成という）。
タイプ０：個体｛ａ, ｂ, ｃ,...｝
タイプ１：個体の性質 ｆ(x) [つまり、「関数」]
タイプ２：個体の性質の性質 ｇ(ｆ(x))[ つまり、「関数の関数」のこと ]
：
タイプ（Ｎ－１）
タイプＮ
（２）代入規則：タイプＮの 関数は、タイプ（Ｎ－１）の対象を代入項とする。
したがって、「Ｗ∈Ｗ」（同じレベルの代入）は無意味となる（「タイプ理論」ではＷ∈｛Ｗ｝が正しい扱いとなる）。
ちなみに、Ｗ＝｛Ｗ｝が成立することもある。これを「不動点」という。
数学者たちが、モノを「高次に（高階に）構成された構築物」と観る原点が、ここにある。
モノは「無定義語」であって、「関係 （関数）」のなかで扱われるパラメータ（項）に過ぎない。
185:デフォルトの名無しさん
05/04/29 12:23:27
素朴な集合論は様々な矛盾を誘発し現在は公理化されている
そこでは通常はＷ∈ＷおよびＷ＝{Ｗ}なるものは拒否されている
揚げ足取りのつもりないが気になったので指摘させて頂くが
関数の関数を書く場合はg(f)(x)とした方がよいだろう
もっと正確には(g(f))(x)であろうか
g(f(x))は通常は関数の合成の意味を持たせているからだ
186:デフォルトの名無しさん
05/04/29 12:25:41
いつの間にか蛆虫が沸いている。
187:デフォルトの名無しさん
05/04/29 12:26:50
誤解されぬよう書いておくが>>185は蛇足である
188:デフォルトの名無しさん
05/04/29 12:45:31
枝葉の指摘ご苦労。
じゃ素朴な集合論の話はここまでにして、
次は ZF公理に基づくプログラミングを騙ってくれ。
よろしく
189:デフォルトの名無しさん
05/04/29 13:10:50
>>188
それはHaskellのことか？
190:デフォルトの名無しさん
05/04/29 13:20:08
いや、きっと>>185は、
公理的集合論、例えばZF公理系に基づいて
オブジェクト指向を説明してくれる事と思う。
191:デフォルトの名無しさん
05/04/29 13:29:04
>>190
ご期待には添いかねる
192:デフォルトの名無しさん
05/04/29 13:32:57
あ、そ。
なんだ、自分の頭で考える事ができる人かと思ったら、
受け売りをくどくど書いてるだけの人か。
つまんね
193:デフォルトの名無しさん
05/04/29 13:38:04
>>192
無駄なことはしない
>>185を書いたのは>>184に紹介さえていることが現代的ではなかったことと記法が気になったことだ
特にそれ以上の意図はない
194:デフォルトの名無しさん
05/04/29 13:39:52
うんだから、
その現代的でない理論でオブジェクト指向が成り立っているのか、
あるいは、もっと現代的な説明が可能なのか？
＞無駄なことはしない。
そのあたりをちゃんと説明しろってこと。
195:デフォルトの名無しさん
05/04/29 13:41:37
オブジェクト指向は集合論に基づいているわけではない
以前から似ているが違うと書いているのだが？
196:デフォルトの名無しさん
05/04/29 13:44:41
ラッセルの型理論つのは、型付プログラミング言語に関する
一番最初の説明として、有効だと考える。
で、おまいさんが現代的ではないとおっしゃるのだから、
じゃそれを現代的にして下さい、って事。
197:デフォルトの名無しさん
05/04/29 13:46:54
>>196
ご期待には添いかねる
198:デフォルトの名無しさん
05/04/29 13:47:50
現代的な型理論としては、
MartinLofの型理論 なんつうのもあるな
199:デフォルトの名無しさん
05/04/29 14:00:11
揚足鶏だらけのインターネッツですねｗ
200:デフォルトの名無しさん
05/04/29 14:02:44
初心者相手のゆるい説明に、
いちいちピラニアみたいに食いついてくるのが、
ちゃねらーですから。
201:デフォルトの名無しさん
05/04/29 14:04:30
んなのばっかだと初心者はどん引きして、
近寄ってこないと思うよｗ
202:デフォルトの名無しさん
05/04/29 14:08:30
その方が初心者にとっても身のためだったりしてｗ
203:デフォルトの名無しさん
05/04/29 14:12:44
荒しが活躍し過ぎると、一般人はどん引きして、
２ちゃねらー離れが加速するだけだと思うよｗ
204:デフォルトの名無しさん
05/04/29 14:18:06
今度から俺も、間違えて荒しちまった後で
「他意はない」って言い訳しよ。
それでも突っ込まれて、ほとほと己の無力さ加減に絶望したら、
「期待には添いかねる」
とレスを返す事にしよう。
205:デフォルトの名無しさん
05/04/29 14:20:57
>>204
ご期侍には添いかねる
206:デフォルトの名無しさん
05/04/29 14:33:39
>>205
他意はない
207:デフォルトの名無しさん
05/04/29 14:35:20
>>206
無駄なことはしない。
208:デフォルトの名無しさん
05/04/29 14:37:10
>>207
似ているが違う
209:デフォルトの名無しさん
05/04/29 14:38:53
ゆるい説明をくどくどする奴に限って、
ゆるゆる議論のほころびの一つに突っ込むと、
猛反発をしてくるの法則
210:デフォルトの名無しさん
05/04/29 14:41:05
>>209
ちゃねらーですから。
211:デフォルトの名無しさん
05/04/29 17:24:52
Animal
<-Dog
<-Cat
こんな継承することは現実のプログラミングの現場ではありえない
実装してみて、インターフェースが共通化できそうなら継承木をつくるのであって
概念としてひとくくりにできるから継承やってると泥沼にはまる
だいたいそれでうまくいくんならデザインパターンなんていらないわけで
オブジェクト指向は手段、言語や実装無しに概念としての価値はあまりない
212:デフォルトの名無しさん
05/04/29 17:39:37
>>211
>>123
213:211
05/04/29 17:43:08
> Animal
> <-Dog
> <-Cat
>
> こんな継承することは現実のプログラミングの現場ではありえない
補足します
ゲームやシミュレーションの世界ではこういう書き方もするが、
言語自体の記述力の限界もあって、
概念をそのまま記述することにとらわれると足かせになりがち
煮え切らない文章すまそ
214:211
05/04/29 17:50:49
>>212
オブジェクト指向という言葉しかつかっていませんが、
オブジェクトを型、インスタンスのどちらでとらえるかで
意味が変わりますかね
215:デフォルトの名無しさん
05/04/29 18:14:57
オブジェクト指向言語を実現する方法として、C++型とsmalltalk型と二つの方法があるってことか？
どっかで似たような話を聞いたな。
このスレでも>>157がそういうようなことを言っているけど。
216:131
05/04/29 18:19:04
>>211
> Animal
> <-Dog
> <-Cat
これはPROTOTYPEパターンだね
217:131
05/04/29 18:28:36
>>215
C++は静的なオブジェクト指向プログラミングを実現する仕組みで
コンパイラでできること仕組みの多くを実現している一方の究極。
動的なオブジェクト指向プログラミングを実現する仕組みの究極は、
Perlだと思う。型変換も実行時に簡単にできるし、同一ベースクラスの
サブクラスの多重継承を（現状がいいかは別問題として）矛盾なく
サポートできる。どちらも、静的なコンパイラ言語であるC++では困難
Smalltalkは理解不能ゆえ、私には論評できません。
218:デフォルトの名無しさん
05/04/29 18:32:16
>>214
詳しく
219:デフォルトの名無しさん
05/04/29 18:33:03
>>216
> Animal
> <-Dog
> <-Cat
これ見て
>これはPROTOTYPEパターンだね
とは、あんたエスパーかｗ
まず "<-"演算子の意味を定義しろってｗ
220:デフォルトの名無しさん
05/04/29 18:33:40
>>182, >>184
T型ERからの引用だな。
221:デフォルトの名無しさん
05/04/29 18:35:19
>>219
俺も最初、
Class Animal {}
Class Dog extends Animal {}
Class Cat extends Animal {}
て話かと思った。
Cat extends Dog {}
なんてｱﾌｫな話題を誰が持ち込んだんだｗ
222:デフォルトの名無しさん
05/04/29 18:35:50
型がオブジェクトと言われることって・・・・？
223:デフォルトの名無しさん
05/04/29 18:36:38
>>220
佐藤さんだけじゃなくて、
外国の超大物も書いてるみたいだよ、このスレ。
224:デフォルトの名無しさん
05/04/29 18:38:32
ああ、ブリキの人ね。
彼も日本語が上手くなったなぁ
225:デフォルトの名無しさん
05/04/29 18:40:32
>>220
で、現代的な型理論と
公理的集合論の話の続きは？
226:デフォルトの名無しさん
05/04/29 18:47:45
ProjectBuilderってOOとしてどう？
227:デフォルトの名無しさん
05/04/29 19:42:32
いや佐藤さん本人ではないだろう。
無断借用じゃないの。
228:デフォルトの名無しさん
05/04/29 21:13:25
>>221
にゃんって鳴く犬が猫なんだよｗ
229:デフォルトの名無しさん
05/04/29 21:30:01
>>211
デザインパターンなんていらないんじゃないの？
230:デフォルトの名無しさん
05/04/29 22:04:49
>>229
再利用とかメンテとかがいらなければ、いらないねっ。
231:デフォルトの名無しさん
05/04/29 22:06:31
【オブジェクト指向】言語学習が先？概念学習が先？
1 名前： デフォルトの名無しさん 投稿日： 04/01/10 14:56
VisualBasicやCといった手続き型言語をずっとやってきた人が、
C#やJavaといったオブジェクト指向言語をマスターする場合
オブジェクト指向の概念・概論を学ぶのが先がいいのか、
それとも、C#やJavaの言語を学ぶのが先がいいのか、
どっちがいいと思われますか。
232:デフォルトの名無しさん
05/04/29 22:10:01
>>231
C#やJavaでオブジェクト指向プログラミングしなくても
ぜんぜんに構わない
オブジェクト指向プログラミングにC#やJavaを使わなくても
ぜんぜん構わない
233:デフォルトの名無しさん
05/04/30 00:00:14
C#やJavaでOOしないのはかえって大変
非OO言語でOOするのはストレスたまりまくりんぐ
234:デフォルトの名無しさん
05/04/30 00:07:05
>>120
>ストラ先生は、オブジェクト＝クラスという意味で使っているみたい
って誤読だろ？明らかに
235:デフォルトの名無しさん
05/04/30 00:48:24
>>234
完全に誤読だよな。
236:デフォルトの名無しさん
05/04/30 01:00:16
オブジェクト＝物 って説明すると
初心者は日本語で言うところの「物」を創造してしまい
「動作・ふるまい」を物とは考えることが出来なくなる
物ありきで、その物に対して「動作・ふるまい」をメソッドとして実装することしか頭に浮かばなくなる
237:デフォルトの名無しさん
05/04/30 01:16:12
クラスライブラリの体系をおぼえるのが
ものすごく、めんどくさい。
238:デフォルトの名無しさん
05/04/30 01:18:15
オブジェクトはキャラクターです
パラディンクラスはナイトクラスを継承します
新たに技を追加できます
オーバーライドすることで既存の技を強化することも可能です
239:デフォルトの名無しさん
05/04/30 02:12:37
>>238
>オブジェクトはキャラクターです
この時点で>>236の言っていることそのままじゃん
240:デフォルトの名無しさん
05/04/30 02:17:25
オブジェクトは職業・技能です
とか？
241:デフォルトの名無しさん
05/04/30 02:29:04
クラスは役割、役です
はどう？
242:デフォルトの名無しさん
05/04/30 02:44:27
くらすが個別にインスタンシエーションがつまりmalloc()の
コンストラクタがごごごと動いて
どうも、オブジェクトです、
クラスのインスタンスです、ご用件をどうぞ
free(); または、もしもし五味屋さんはやくきてよ
のような、認識。
今年中によむ、本(予定)。
* 結城本
* エッケルのThinking in Java
* GOF本
243:デフォルトの名無しさん
05/04/30 02:57:57
>>237
マトモに設計されたライブラリなら一部を覚えればあとは類推で何とかなると思うが。
244:デフォルトの名無しさん
05/04/30 04:27:33
オブジェクトを汎化したものがクラスです。
245:デフォルトの名無しさん
05/04/30 04:32:08
>>123
> 分析レベルだと、あんまりインスタンスという言葉は使われない。
おいおい、ユースケースのをインスタンス、とか言うだろ？
使われないのはオブジェクトという意味の「クラスインスタンス」だろ？
246:デフォルトの名無しさん
05/04/30 11:29:38
インヘリタンス
247:デフォルトの名無しさん
05/04/30 12:41:43
混濁箪笥
248:デフォルトの名無しさん
05/04/30 13:23:24
オブジェクト指向ってつまるところ
「そういう仕様」だと思うよ、
現実を表現しやすく、管理しやすい仕様ではあるが
現実に無理して当てはめてわかった気になっても
習熟していくと騙されたと気づくんじゃないかな？
249:デフォルトの名無しさん
05/04/30 13:32:57
騙されたって気にはならないなあ
用意周到なクラスライブラリを理解していくに連れて
なるほどという気持ちになる
あでもそういう汎用クラスライブラリを作る側は大変だろうな
習熟して騙された気になるってそういうレベル？
250:デフォルトの名無しさん
05/04/30 13:47:11
アルゴリズムと一緒で
あーこういう組み方するのか～うまいね～ってな感じ
しかし、それほどデザインパーﾀﾝに執着は無い
クラスの関係図を書くと何階層にもなってしまうので
新規作成時はいいんだけど、後から入ってきた人が
もしそれほど知識無いとしたら修正お願いしてもわかりませんので
251:デフォルトの名無しさん
05/04/30 15:43:55
「現実に無理して当てはめた説明」に騙されたって言ってるんだけど
デザインパターンは現実の構造を示してるんじゃなくて、
工学的な定石に名前をつけたもんでしょ
現実ってリアルワールドね
252:デフォルトの名無しさん
05/04/30 15:46:52
習熟してくるとその辺の神話のうそがわかってくるって
いいたいんですよ
253:さかな ◆xT/ZtgSAnQ
05/04/30 15:55:55
その「神話」とやらを教えてる方の人間も、
理解を助けるための方便として言ってる場合だけじゃなく
自分も本気で信じてる場合もあるから
たちが悪い。
254:デフォルトの名無しさん
05/04/30 16:05:05
結局プライドの戦いと言うわけになるのだな
255:デフォルトの名無しさん
05/04/30 17:22:36
アプリケーション、ツール、フレームワーク、クラスライブラリ、クラス設計に関して、
自分で実際にそれらを作ってみると、設計の妥当性/妥協点がわかる、という事実がある。
もちろん、自分でそーゆーのを作れない泡沫エンジニアへのセールスポイントや使いやすさ
も提供するわけだがｗ
大枠や細かな所は、「現実的な作りやすさ」で決まってくるもんなんだよね。
だから、ｵｰﾌﾟﾝソースで自分で中見て改善する練習をする事が重要なんだ。。。
Smalltalkしかり、Linuxしかり
256:デフォルトの名無しさん
05/04/30 18:00:34
制御系でOOPってどれぐらい浸透している？
ナビ開発をやっているんだけど、現行の手続きOnlyなやり方だと分り難くないかな。
257:デフォルトの名無しさん
05/04/30 18:10:45
>>256
new封印で使ってる
258:デフォルトの名無しさん
05/04/30 18:52:27
騙される方が悪いのか騙す方が悪いのか信じる者は掬われる？
259:池沼くんのレス
05/04/30 18:55:05
88 名前： 番組の途中ですが名無しです 投稿日： 2005/04/29(金) 14:21:36 ID:HlHAQf7m0
まぁ、オブジェクト指向隆盛の現在、
Viewを客受けの良いものにchangeしたのは正しい決断だな。
260:デフォルトの名無しさん
05/05/01 07:24:28
C++の設計者はなんで
shout << なわけねーだろ！
にしなかったんだろ…
261:デフォルトの名無しさん
05/05/01 21:17:22
orz << "入れてよし"
262:デフォルトの名無しさん
05/05/01 21:38:53
プリプロセッサで文法変更すりゃ終了。
263:デフォルトの名無しさん
05/05/06 20:50:37
>>261
orz┤
264:デフォルトの名無しさん
05/05/07 02:13:09
じゃあ、言語学習と概念学習は同時にやっていくってことで終了でいいですか
265:デフォルトの名無しさん
05/05/08 12:32:01
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝来了＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
266:デフォルトの名無しさん
05/05/11 00:24:46
いがぴょんが痛すぎるんだけど、マゾかなんかですか？
267:デフォルトの名無しさん
05/05/11 00:27:54
逝け沼さん、こんにちは
268:デフォルトの名無しさん
05/05/11 02:36:01
>>263
orz=3=3=3=3 ﾌﾞﾌﾞｯﾌﾞﾘﾌﾞﾘﾋﾞﾁﾋﾞﾁﾌﾞﾌﾞﾌﾞ
269:デフォルトの名無しさん
05/05/15 11:01:52
いつの間にかクダスレになっとるわい
270:デフォルトの名無しさん
05/05/15 11:26:23
>>196
型付きの手続き型言語の理論としては、
型付λ計算が広く受け入れられている。
ただし、オブジェクト指向言語では
「オブジェクト指向」の本質といったものを明確にするのは難しいので、
広く受け入れられた理論というのは、まだない。
271:デフォルトの名無しさん
05/05/15 15:14:43
どういった単位でクラスを作っていけばいいんですか？
趣味程度で自分しか使わないコードを書く人間としては、
ついというか癖でだらだらと関数を山ほどForm1のなかに書いてしまうのですが…
272:デフォルトの名無しさん
05/05/15 17:59:10
本当にﾌｶｷｮﾝ似だね
273:デフォルトの名無しさん
05/05/15 19:43:17
>>271
いくら使い捨てコードといっても、一発で動いて後は永遠にメンテ不要なんてケースはまずないわけで。
自分で書いたコード読んでイライラしない？
274:デフォルトの名無しさん
05/05/15 20:41:36
>>271
>どういった単位でクラスを作っていけばいいんですか？
殴り書きでいいのだが、
見つけたオブジェクトを見つける
見つけたオブジェクトの単位でクラス図を書く
クラス図にメンバ変数を追加する
クラス間のメンバ関数を時系列にそってシーケンス図として書く
メンバ関数をクラス図に追加する
これらの手順を納得できるまで繰り返す
収まりがついたらコーデングする
動作としてはこうなんだが、
それぞれの段階で知識や経験が入り込む
275:デフォルトの名無しさん
05/05/15 20:42:51
>>274
×見つけたオブジェクトを見つける
○オブジェクトを見つける
276:デフォルトの名無しさん
05/05/15 20:44:40
C の struct をベースに、データ構造を基準にすると分かりやすい
どれだけの物を１つにまとめ、どれとどれを分けるかの判断は経験則
277:デフォルトの名無しさん
05/05/15 20:45:43
>>274
コーダー乙。
分析レベルのOOを認識できてないあたりが、
机上の勉強だけの糞コーダ臭いな
278:デフォルトの名無しさん
05/05/15 20:52:39
どうでも良いが、わざわざ 『分析レベル』 と 『実装レベル』 を分けて考える必要性が分からん
279:デフォルトの名無しさん
05/05/15 20:53:24
第一の山は、
概念レベルのオブジェクトをいかに抽出し、
現実世界のモデルを作るか？
第二の山は、
ユーザ要求なり機能要求を、
分析レベルでいかに取り込んでいくか
第三の山は、
１で作った概念モデルと
２で作った機能要求モデルを
いかに整合させていくか
第四の山は、
１、２、３で作ったモデルの実装方法の検討。
ここらへんがアーキテクトの仕事。
このあたりまでやって、ようやく開発レベルのOOになる
もちろん、対象分野の開発に慣れていて、
なおかつ新しい設計をしないならば、
1～4は楽勝だけどな。実際はそれをOOに不慣れな人間がやる事が多いから、
下流の人は大変みたいだ。
機能分割とDB設計から割り出したクラス図を受け取って、あとはウォータフォールとかｗ
280:デフォルトの名無しさん
05/05/15 21:05:52
最初の質問に戻って
＞どういった単位でクラスを作っていけばいいんですか？
趣味のプログラミングということで、基準がわからないのだが、仮に
1.開発技術のスキルアップ
2.設計～コーディングにおける作りやすさ
3.拡張のし易さ
あたりを基準に考えていこう。
1.に関しては、薄っぺらいOO開発プロセスの本を追っかけてみると、
UMLやオブジェクト指向分析設計の概観が得られて、勉強になると思う。
とりあえずの推薦図書は、
・ユースケース入門―ユーザマニュアルからプログラムを作る
URLﾘﾝｸ(www.amazon.co.jp)
・ワークブック形式で学ぶ UMLオブジェクトモデリング
URLﾘﾝｸ(www.amazon.co.jp)
281:デフォルトの名無しさん
05/05/15 22:08:24
>>278
> わざわざ 『分析レベル』 と 『実装レベル』 を分けて考える
もし設計/実装レベルのみに着目してソフトウェア開発を行うと、
開発者の関心と努力は、実装可能な事/実装が難しい事に集中してしまい、
結果として下記のような問題が発生します。
(1) 本来の要求(やりたかった事)の実現が、
おざなりになったり、歪んだ形になってしまう事。
（結果として、ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ技術は素晴らしいが、
使う人にとっては判りにくい、使いにくいものになってしまいがちです）
(2) 拡張や機能追加に耐えないクラス設計になってしまう事。
（拡張や機能追加に耐えるしっかりした構造を持たせるには、
普遍的な概念モデルや、プログラム対象分野の知識体系に基づく、
抽象的なレイヤーが必要です。
この抽象的なレイヤーは、汎化クラス抽出の方法でもある程度得られますが、
ボトムアップに実装から抽出する方法では、充分な汎用性をえられません。）
(3) プラットフォームや実装技術と、コアなアルゴリズムの切り分けが不充分になる。
もし、実装技術やプラットフォームに基づいて、アプリケーションの設計を行ったら、
それは将来のOS/環境のバージョンアップ時に、大きな変更作業が必要になるでしょう。
OS/環境依存部、プログラム対象分野の知識体系、アプリケーション、を分けるには、
レイヤー・パターンが有効ですが、そのレイヤーを切り分けるためにも、
OO分析の作業が重要なのです。
他にも書くべき事があるのですが、とりあえずここで筆を置きます。
282:278
05/05/15 22:20:01
>>281
＞もし設計/実装レベルのみに着目してソフトウェア開発を行うと、
いやいや、最終的に両方ともやらなければいけないのは分かっているんだけど、
ある程度のフィードバックが、実装レベルから分析レベルに伝播するから、
わざわざ分けずに一言で纏めちゃっても良いんじゃないかって言う勝手な話
283:デフォルトの名無しさん
05/05/15 22:31:16
分析レベルで抽出されるオブジェクトと、
設計レベルで抽出され、実装に反映されるオブジェクトは、
かなり距離感がある
これが、二つのプロセスを分離している理由です。
もちろん、シェアウェアとか個人でプログラムを作成されている方の中には、
実装技術ベッタリで素晴らしいアプリを作成されている方も多いようですし、
貴方の信じる道を行けば良い、と思います。
284:278
05/05/15 22:50:32
ああ、なんとなく雰囲気が掴めました
目的から作成するオブジェクトと、実装技術から発生させるオブジェクト……
……これらを最終的に一致させるように、今まで考えていたのですが、これじゃダメなんでしょうか
(ひとつになった最終形を眺めて、278 を考えていたです)
っていうか経験不足です
企業に入ってそこそこのプロジェクトに参加するようになったら、改めて考えてみますです
285:デフォルトの名無しさん
05/05/15 22:51:30
なんだろ。目的と実装を一致させるのではなく、実装を目的でラップするとか、そういう意味合いで
286:デフォルトの名無しさん
05/05/16 04:30:20
・・・・・・。
287:デフォルトの名無しさん
05/05/16 20:38:55
うむ。わざわざ別の用語にするほどのこととは思えないな。
>>284のような「設計方針」「心構え」で申し分ない。
288:デフォルトの名無しさん
05/05/16 20:41:57
いや、だから個人で勝手にやる分には全然構わないけど、
内容的には大きな差があるんだって。
＞＞分析モデルと設計モデルの間の深い溝。
俺はこの分野に入ってすぐ、気付いたけどなぁ～
289:デフォルトの名無しさん
05/05/17 08:50:54
具体的に
290:デフォルトの名無しさん
05/05/17 08:58:47
いや、そーゆーのは仕事で覚えるものだから、
素人グラマーに意見するつもりはない。
291:デフォルトの名無しさん
05/05/17 09:00:14
だいたい趣味がプログラムの >>289は、
朝っぱらからこんな所でなにやってんの？
292:デフォルトの名無しさん
05/05/17 09:14:29
結局具体例もないわけね
293:デフォルトの名無しさん
05/05/17 09:16:13
餓鬼と判定。以降スルー
294:デフォルトの名無しさん
05/05/17 09:24:49
自演臭い
295:デフォルトの名無しさん
05/05/17 09:26:12
俺の思いを分かるのは俺だけ！ﾌﾟ
296:デフォルトの名無しさん
05/05/17 09:27:07
VIP板に（・∀・）ｶｴﾚ
297:デフォルトの名無しさん
05/05/17 20:38:12
ジサクジエンイクナイ
298:デフォルトの名無しさん
05/05/18 22:13:32
>>282
そういう思考が肥満児クラスを産む、
なんてな。
299:デフォルトの名無しさん
05/05/18 23:29:45
良い設計モデルの作り方(前編) URLﾘﾝｸ(www.atmarkit.co.jp)
◇ 目指すべき分析モデルの形
分析モデルの作成方法については、多くの設計者や方法論者がさまざまな方法を主張しています。
ここでは詳細には述べませんが、例えば、
・ワード・カニンガム（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つのアーキタイプ、瞬間―時間間隔、役割、パーティ／場所／物、説明に分類し、色分けして、パターンに当てはめて分析していく方法。
特に分析モデルに限ったものではありませんが、最初のモデルを作成する場合の強力な手法となっています。
300:デフォルトの名無しさん
05/05/18 23:30:12
◇ 設計モデルの理想
設計モデルの段階における理想的なモデルとはどんなモデルでしょうか。設計段階のモデルに従って実装が行われ、
その結果システムが出来上がるわけなので、生産性が高く、保守性や拡張性が考慮されていなければなりません。
そのうえで、実装担当者にとって理解しやすいモデルが「良い設計モデル」ということになります。
最近のアジャイル系開発プロセスでは、モデリングを分析段階と設計段階に分けず、
モデリング＝設計（Design）と考えたり、XPのように、コーディング作業にモデリング作業を含んでしまうプロセスもありますが、
本稿では、分析と設計の考え方の違いを解説するために、あえて分析モデルと設計モデルを分けて表現しています。
301:デフォルトの名無しさん
05/05/18 23:57:53
なんかPascal臭い感じだな（意味分かる？）
302:デフォルトの名無しさん
05/05/19 00:11:29
しらねぇよ屑
303:デフォルトの名無しさん
05/05/19 00:12:39
てめえは御託並べる前に、構造化プログラミングとデータ中心アプローチくらい覚えろよｗ
304:デフォルトの名無しさん
05/05/19 08:27:55
なんか初心者にはスレッショルドの高いスレになっちまったな
305:デフォルトの名無しさん
05/05/19 08:37:57
>>299-300のボーランド@IT記事がいいと思うよ。
匿名掲示板で数文字でノウハウ聞き出そうとするアンタは、ギブアンドテイクつう言葉がわからんヒッキーだろ
306:デフォルトの名無しさん
05/05/19 17:18:03
また電波とばす。受信したい奴だけ受信してくれ。
C# だと、オブジェクトの派生になるが C と同じような構造体が扱える
宣言は 『 struct Struct1 { ～ } 』 でインスタンス生成は 『 new Struct1() 』
それに対し、オブジェクトの宣言は 『 class Class1 { ～ } 』 でインスタンス生成は 『 new Class1() 』 なんだけど、
これ、宣言が 『 object Object1 { ～ } 』 の方が分かりやすくないか？って電波だ。
struct の宣言では、定義してあるのが 『構造体』 で、作成されるのが 『構造体のインスタンス＝構造体』 だからまあ良い。
だけど class の下りは、定義してあるのが 『クラス』 で、作成されるのが 『クラスのインスタンス＝オブジェクト』 だから
定義された物と作成される物が異なっていて気持ち悪いかもしれないと言うこと。
異なっていて気持ち悪いのならば、いっそのこと 『 object Object1 { ～ } 』 にしてしまえば……ってコトです。
もちろん、object の宣言を行っていても 『これはクラス Class1 のインスタンス』 という表現は行える筈。
クラスって言葉は、『部門』 とかの分類を表す意味があるから。レベルとかと同じ意味で。
C# では、構造体のインスタンスもオブジェクトと言っているから、まあ気にし過ぎかもしれないけど、
C から入った俺は、なんとなく 『構造体の定義から生まれたモノ＝構造体』 にしたくて。
……って、なんとなくクラスとインスタンスの区別がついてないっぽいな。すまぬ。
307:デフォルトの名無しさん
05/05/19 19:30:00
＝＝＝＝＝ 電磁シールド ＝＝＝＝＝
シンタックス・シュガー作っても本質は変わらない。
クラスと構造体を同一視するのなら、サルもミジンコも同じ。
クラスとオブジェクトの違いもわからずに、
そんなに細かいところをあれこれ弄る必要ナッシング。
308:デフォルトの名無しさん
05/05/19 21:41:58
structで定義しているのは構造体の構造
実際に作成する時作成されるのは構造体
この違いがクラスとオブジェクトの違い
309:デフォルトの名無しさん
05/05/19 21:44:36
けれどクラスという概念をなくしてしまってもいい
オブジェクトの構造・仕組みという抽象的なもので
コード上は現れないようにしても問題ないだろうよ
310:デフォルトの名無しさん
05/05/19 21:47:54
なんか変なのが居ついてるな
311:デフォルトの名無しさん
05/05/20 06:01:04
>>309
そういう道を進んでいる言語もある。
プロトタイプベースと呼ばれているようだが。
312:デフォルトの名無しさん
05/05/20 09:11:17
今頃プロトタイプ・ベースを語るとは・・・ｸｵﾘﾃｨﾃﾗ高杉
313:デフォルトの名無しさん
05/05/20 09:43:14
プログラムもろくに書けない負け犬は、
古臭い脳内知識で妄想勝利するしかやる事がないんだな
プロトタイプベース言語が提供する
インスタンスに対する属性/メソッドの付加は、
Composit, Decoration, Delegation, Factoryあたりで実現できる。
プロトタイプベース言語は、それらの機能を言語仕様に取り込んでいるだけｗ
314:デフォルトの名無しさん
05/05/20 09:45:58
Composite, Decorator, Prototype パターン ＋ Delegation (委譲による処理) な
315:デフォルトの名無しさん
05/05/20 10:59:30
クラスベース ＝オブジェクト間にメタ関係を設け、
メタ関係上位にあるオブジェクト(クラス)に、オブジェクト生成や継承の仕組みを任せて、
メタ関係下位にあるオブジェクト(インスタンス)の内部実装の簡略化を図ったもの
プロトタイプベース＝全てのオブジェクトに、オブジェクト生成や継承の仕組みを提供するもの。
概念は単純になるが、言語実装技術やﾌﾟﾛｸﾞﾗﾐﾝｸﾞ技術のハードルは高くなる。
(静的型付けやLiskov置換則による安全性を、言語レベルで提供しにくくなる)
概念学習への初期投資を惜しむような人間が、プロトタイプベースを選択するのはナンセンス。
プログラム書かない人が見栄知識でアレコレ言うだけなら、チラシの裏に書いてろ。
316:デフォルトの名無しさん
05/05/20 18:25:30
>>315
いい比較だと思うが、それだとクラスがファーストクラスな存在に読めるかも。
317:デフォルトの名無しさん
05/05/20 18:35:42
またファーストクラス厨房か。
Smalltalkでクラス・ベースのオブジェクト指向が確立した後で、
あらためて Self等でプロトタイプ・ベースのオブジェクト指向言語が研究されたのだから、
クラス-オブジェクト関係 (メタ関係 あるいは インスタンス関係)
の方が広く受け入れられてる概念だと思うよ。
Abadi & Cardellaの本もまずクラスベース言語、次にオブジェクトベース言語という展開だし。
318:デフォルトの名無しさん
05/05/20 18:40:05
あ、もっとレベル低い人か。
Smalltalk等、クラスをファーストクラスなオブジェクトとして扱うのが第一世代、
CLOS等、手続き型の延長線上にクラスレスなOOを定義したのが第二世代、
C++等、クラスをオブジェクトが共有する構造体として扱うのは邪道な第三世代、
Java等、クラスをリフレクション等駆使して、実行時に参照可能なオブジェクトとして扱えるようにしたのが第四世代
だよん。（てきとー
319:いやん
05/05/20 18:40:57
× Cardella → ○ Cardelli
320:デフォルトの名無しさん
05/05/20 18:43:46
Selfとか、プロトタイプ・ベースの言語が研究されるようになったのは、C++とJavaの中間くらいからかな。第3.5世代・・・新しい開拓地
321:デフォルトの名無しさん
05/05/20 19:08:23
>>318
プログラム書かない人が見栄知識でアレコレ言うだけなら、チラシの裏に書いてろ。
322:デフォルトの名無しさん
05/05/20 19:29:24
おまえの事だよ
323:デフォルトの名無しさん
05/05/20 21:19:08
プログラム書かない・・・情報処理言語の研究者なのかも
324:デフォルトの名無しさん
05/05/20 21:22:43
豆な人？
325:306
05/05/21 14:42:19
やっぱり混乱の元になったか……
クラスベースについて疑問を思っているんじゃなくて、ただ単に 『表記法』 について疑問に思っただけだったんだけどな
クラスベースとかインスタンスベースとか、正直どうだって良いんだけど
>>308
＞structで定義しているのは構造体の構造
同様に、class で定義しているのはオブジェクトの構造つまりクラス
それは分かる。struct および class が 『定義そのもの』 を指すのか 『定義した生成物』 を指すのかの違いのような。
気分的には、生成物を指したい
326:デフォルトの名無しさん
05/05/21 14:46:28
いろんな「何を」や「何は」が抜けていて、「何に」ついて言いたいのかさっぱりわからない。
327:デフォルトの名無しさん
05/05/21 14:51:43
頭おかしい人だから、放置しとけ
328:デフォルトの名無しさん
05/05/21 15:03:52
>>325
君が誤解している(もしくは不完全な理解をしている)のは、
クラスやオブジェクト等のＯＯの概念ではなくて、型という概念だ。
Cardelliでも読んで、型とは何か、型を宣言するとはどういうことか、
じっくり考えてみたらいい。
329:306
05/05/21 15:05:19
頭おかしいって言われちまったい ^_^;
んじゃ書き直す
======
C# の表記法について、
class では 『定義そのもの』 を指していることは明確であるが、
struct は 『定義そのもの』 と 『定義によって生み出される生産物』 の、どちらを指すのか分かり難いと俺は思う
言いたい事はこれだけ
======
>>307
C# ではクラスと構造体が同一になっちゃってるから困っているんです
>>308
構造体の構造を定義するのならば、キーワードは 『struct_struct』 であるべきという気もします
『struct』 単体ならば、それは 『定義に代って生み出される生産物』 を指すのでは？
330:デフォルトの名無しさん
05/05/21 15:12:33
国語の問題な気がしてきた。
331:306
05/05/21 15:12:37
>>328
了解……出来るように頑張ります
Pascal の 『レコード型』 とか、C の 『構造体型』 とかと同じように考えると、class では 『クラス型』 を定義している筈。
しかし生成物の方は 『レコード型のレコード』 『構造体型の構造体』 とは異なり 『クラス型のインスタンス』 だから、
前２者に揃える場合、これを 『オブジェクト型のオブジェクト』 にしたほうが簡潔ではないかと思いまして。
332:デフォルトの名無しさん
05/05/21 15:13:00
>>330
正解
333:デフォルトの名無しさん
05/05/21 15:31:29
ドーナツの穴について話す時、
「ドーナツ」という単語が付いていると、あたかも「ドーナツ」が存在しているかのように感じる。
だから、「穴の穴」というのが正しいぃぃぃぃーーーーーーーーーーーーーー
334:デフォルトの名無しさん
05/05/21 15:33:18
「ドーナツの穴」って、まるで穴の部分にドーナツがみっちり詰まってるみたいで、誇大広告だよな（ﾋﾟｰﾋｬﾗ
335:デフォルトの名無しさん
05/05/21 15:35:15
人間という単語と、その実体を考えるとき、
実体は単なる人なのに、
単語に「間」という漢字がついているのが、直感に反する。
これからは、「人間」という単語を使うのはやめよう
336:デフォルトの名無しさん
05/05/21 15:49:42
>>333-334
スレ違い。こっち行け
ドーナッツの穴は空洞か存在か？
ｽﾚﾘﾝｸ(philo板)l50
337:デフォルトの名無しさん
05/05/22 08:11:20
>>306
そのobjectってVBでいうところのモジュールだよな？
classと違うだろ。
338:デフォルトの名無しさん
05/05/24 06:19:22
おれはstructで構造体の構造が定義されてるって自然に感じるけどな
んでその構造を持つ変数を同時に生成することもできると
339:デフォルトの名無しさん
05/05/24 09:52:10
>>331
PascalやCのほうを『レコード型のオブジェクト』、『構造体型のオブジェク
ト』って思ってみては？
オブジェクトとインスタンスは、まぁ、同義ということで。
340:306
05/05/24 17:24:00
色々とすまなかった。整理したら間違いに気付いたよ。
こんな馬鹿をやったのは久しぶりだ。今は後悔している OTL
【正しいこと】
・C# の 《クラス》 には 『クラス』 『インタフェイス』 『構造体』 の３種類が存在する
・『インタフェイス』 と 『構造体』 は、Object クラスを継承している
【俺が間違っていたこと】
・《クラス》 と 『クラス』 を混同し、宣言時のキーワード 「class」 が主に 《クラス》 を指す物と考えてしまった
・『クラス←構造体』 に代表される 「言語系外での継承」 が、一般の継承と完全に同じであると信じて疑わなかった
その結果、俺は 「class」 と 「struct」 が同一レベルの概念ではないと錯覚した
そして、「class」 と 「struct」 のレベルを同じにしようと思い、「class」 を 《クラス》 から 『クラス』 にするために
「《クラス》 には 『オブジェクト』 『インタフェイス』 『構造体』 の３種類が存在する、と言い換えたらどうか」
と提案した (>>306)
(実際は 「class」 は 『クラス』 であり、単なる言葉遊びだった orz)
341:最凶VB厨房
05/05/25 00:25:55
全く意味わからんなｗ
【正しいこと】に書いてある内容が正しくない。
342:デフォルトの名無しさん
05/05/25 00:36:00
だからまず国語を勉強するべきだって。
つまり言語学習を先にするべき。
343:306
05/05/25 13:28:06
>>342
悪い。相変わらず間違えてたみたい。
=====
「C# の 《クラス》 には 『クラス』 『インタフェイス』 『構造体』 の３種類が存在する」 ってのは、
「Java の 《クラス》 には 『クラス』 『インタフェイス』 の２種類が存在する」 っていうどっかの本の台詞のパクリだった
この 《クラス》 は、Smalltalk のメタクラスに該当するんかな。よく分からんけど
それはともかく、構造体はクラス階層の中に含まれているから、よく考えたらこの中に入れちゃいけないのかもしれない
=====
インタフェイスは対応するクラスが無いから、Object から派生しているとは言えないでした
(ただし、インタフェイスを実装したクラスのインスタンスは Object であることは確定なので、Object として扱える)
ここのところは訂正しておきます
344:306
05/05/25 13:38:42
結局、まだ理解できていないことは
実質 「class StructA: System.Struct { ～ }」 なクラスを 「struct StructA { ～ }」 と記述させる C# において、
キーワード 「class」 と 「struct」 を同列に置くことが果たして妥当なのかどうか
つまり
System.Struct からの実際の継承は、神の領域において行われる (ソースとして記述できない) が、
神の領域において、結局はクラスである構造体が、クラスと同じレベルまで昇進しているのかどうか
……自分でも未だ混乱していることがありありと分かりますな
あとで Smalltalk でも勉強しよう……
345:最凶VB厨房
05/05/25 19:09:30
間違った前提知識からは(正しい推論をしたとしても)間違った結論しか得られんぞｗ
実質～の部分が既に間違ってますがなｗ
MSDN読め
346:デフォルトの名無しさん
05/05/25 19:15:01
太陽が西から昇るなら、このレスは346である
347:デフォルトの名無しさん
05/05/25 19:24:49
URLﾘﾝｸ(www.microsoft.com)
解説
struct 型は、Point、Rectangle、Color などの軽量のオブジェクトを表すのに
適しています。点はクラスで表現できますが、一部の事例では構造体の方が
より効果的です。たとえば、1,000 個の Point オブジェクトから成る配列を
宣言する場合は、各オブジェクトの参照用に新たにメモリが割り当てられます。
この場合は、構造体を使用した方がリソースを使用しません。
構造体に対して既定の (パラメータなしの) コンストラクタを宣言するとエラー
になります。構造体メンバを既定値に初期化する既定のコンストラクタが常備
されています。
構造体のインスタンス フィールドを初期化するとエラーになります。
new 演算子を使用して struct オブジェクトを作成すると、オブジェクトが作成
されて適切なコンストラクタが呼び出されます。クラスとは異なり、構造体は
new 演算子を使用せずにインスタンスを作成できます。new を使用しなかった
場合、各フィールドは未割り当てのままになり、すべてのフィールドが初期化
されるまでオブジェクトを使用できません。
クラスには継承がありますが、構造体には継承がありません。構造体は、
他の構造体やクラスから継承できず、基本クラスになれません。
ただし、構造体は、基本クラス Object から継承します。
構造体は、クラスの場合とまったく同じ方法でインターフェイスを実装できます。
C++ とは異なり、キーワード struct を使用してクラスを宣言できません。
C# では、クラスと構造体は、意味が異なります。構造体は値型ですが、
クラスは参照型です。
値型の機能の詳細については、「値型」を参照してください。
348:306
05/05/25 21:23:41
>>347
あ、もしかして struct って System.Struct の継承じゃない……のか？
でもインスタンスを作成しているわけじゃないし……なんなんだろう。
=====
それはともかく、え～っと……アロエリーナに聞いたらヒントを教えてくれました。
＞キーワード 「class」 と 「struct」 を同列に置くことが果たして妥当なのかどうか
「妥当じゃないです」
＞クラスである構造体が、クラスと同じレベルまで昇進しているのかどうか
「そんなわけないです。クラスと構造体は別物」
＞じゃあ、クラスと構造体はどうして同じような構文になっているの？
「それが利便性ってもんです」
……俺、この時点で納得しちゃって良い？
「クラス定義と構造体定義は別物だけど、分かりやすいように同じ構文になっている」 で OTL
349:デフォルトの名無しさん
05/05/25 21:38:25
350:306
05/05/25 21:43:54
…… System.Struct なんて無いじゃん orz 昼間俺が見てたのは幻か～ orz
え～っと……ってことは、struct は実質 System.ValueType の継承……じゃなくて……
「struct で定義した構造体は、オブジェクト指向の世界からは System.ValueType を継承したオブジェクトのように見える」
……で良いんか？
351:デフォルトの名無しさん
05/05/25 21:53:05
構造体はオブジェクト指向の外に属するのん？
352:デフォルトの名無しさん
05/05/26 00:49:27
なにこの素人？
353:デフォルトの名無しさん
05/05/26 08:53:23
ちょっとありえないバカだな。
知識がないだけなら調べることで補えるが、
知識がないことに自覚がない上に無根拠な自信に満ち溢れて混乱した言葉を垂れ流すレベルになると
矯正はかなり困難。
354:デフォルトの名無しさん
05/05/26 08:57:33
構ってクンのつまらんﾈﾀだな
355:デフォルトの名無しさん
05/05/26 08:59:58
考えるな、推測するな、勝手に言葉を定義するな。仕様書を読め。
356:構ってクンうざい
05/05/26 09:21:27
>>355
>>347
357:デフォルトの名無しさん
05/05/26 16:05:10
>>1
まあ、その問題は、エロ本によるオナニーがさきか、それとも
実戦のセックスが先か、みてーなもんだ。どっちにも固有の良さはある。
でも、いつまでもオナニーに留まってるわけにはいかない。
そーゆーもんだ。
358:デフォルトの名無しさん
05/05/26 19:11:11
>>1
> VisualBasicやCといった手続き型言語をずっとやってきた人が、
> C#やJavaといったオブジェクト指向言語をマスターする場合
> オブジェクト指向の概念・概論を学ぶのが先がいいのか、
> それとも、C#やJavaの言語を学ぶのが先がいいのか、
> どっちがいいと思われますか。
1. オブジェクト指向の概念・概論を学ぶ
2. その概念を、ずっとやってきたVisualBasicやCで実現してみる
3. 次にC#やJavaの言語を学び、2でやっていたことが言語のprimitiveとして
存在することの良し悪しを考察する
4. VB5ってある意味オブジェクト指向の塊だよなあと感慨にふける
359:306
05/05/26 20:13:05
>>352-355
おお、なんか世界の裏まで知り尽くしているっぽい発言ですな
恐れ入ります
で、結局 「C# の構造体」 って何者なんでしょね
360:306
05/05/26 20:22:49
>>353 >>355
『使うだけ』 ならば仕様書を読めば事足りる
細部まで理解したいのならば、それだけじゃ全然足りない
……って素直に思った
最低だな俺 OTL
っていうかそれ以前に仕様書をマトモに読めよって OTL
どうする？ＮＧ登録したければコテ付けるけど、それとも 306 のままで良い？
361:デフォルトの名無しさん
05/05/26 20:24:40
306でおっけーです。NG登録しときました。
362:306
05/05/26 20:27:33
去るってのも選択肢の１つか……って、そういやもうネタ無いじゃないか
メモ帳にしちまって正直すまんかった OTL
もうちょっと精進できるよう頑張ってみるよ
363:デフォルトの名無しさん
05/05/26 20:31:57
ＮＧ登録完了
でも、>>360 にはとりあえず同意しておく
「全然足りない」ときに「自己流の解釈をする」ってのは方法として間違っていると思うが
364:306
05/05/26 21:37:10
306じゃないけど
これ入れとけば
誰にも見つからないってわけか
3060でもいいのかな？
365:デフォルトの名無しさん
05/05/26 21:42:56
0306＝198
0x306＝774
366:デフォルトの名無しさん
05/05/27 00:31:07
童貞ですがなにか？
367:デフォルトの名無しさん
05/05/27 00:33:08
おねぇさんのマンコ貸してあげようか？
368:偽306
05/05/27 05:32:30
言語学習する前に概念をさらっと学ぶ必要はあるよな
そしてその実例を言語学習で学ぶと概念が身に付く
車の両輪を右から作るか左から作るか悩むようなもので
あまり意味のある質問とは言えませんよ>>1
369:デフォルトの名無しさん
05/05/27 06:15:25
0b306： Syntax Error
370:デフォルトの名無しさん
05/05/27 12:34:10
▂ ▂ ▄ ▄ ▄ ▄
◢░ ▄▀ ▀▄ ░◣ ▌▐▄▀ ▌▐▄▀
▐░:: ░▍
▐▓░:: ▄ ░▍
▐▓░░::░:: ▀▀▀▀▀▀▀▀ ░▓▍▅ ▅ ▄▄▄▄
▐▓▓░░░::░::: :::░::░▓▍ ▊ ▋
▐▓▓▓░░░::░::░::::: :: :: ::::░::░░░░░░▓▓▍ ▐▄▌
▀█▓▓▓░▓░░::░:::░:::::::░::░░░░░▓░▓▓▓▌ ▄▅▀
371:デフォルトの名無しさん
05/05/27 14:43:02
>>370
おおー ヴィジュアル系！
372:デフォルトの名無しさん
05/06/05 21:47:37
カプセル化と継承ってオブジェクト指向の機能だけど
ポリモーフィズムは機能じゃないよね？
継承を利用したデザインパターンだと思うんだけど
識者の意見をお聞きしたい。
373:デフォルトの名無しさん
05/06/05 21:51:23
>>372
・カプセル化はオブジェクト指向の機能ではない
・継承はオブジェクト指向の機能だが、必須ではない
・ポリモーフィズムには多数の種類がある。
貴方が遅延バインディングについて言いたいのだと推測すると、それはオブジェクト指向の機能
・遅延バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
374:デフォルトの名無しさん
05/06/05 21:52:28
ん？ ２行目と３行目は矛盾している気がするが、とりあえず継承有りのオブジェクト指向を考えてくれ
375:デフォルトの名無しさん
05/06/05 22:05:53
＞遅延バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
まぁ、じっくり騙ってくれ、その概念を
376:デフォルトの名無しさん
05/06/05 22:06:59
>>373
それなんてエロゲ？
377:デフォルトの名無しさん
05/06/05 22:47:09
▂ ▂ ▄ ▄ ▄ ▄
◢░ ▄▀ ▀▄ ░◣ ▌▐▄▀ ▌▐▄▀
▐░:: ░▍
▐▓░:: ▄ ░▍
▐▓░░::░:: ▀▀▀▀▀▀▀▀ ░▓▍▅ ▅ ▄▄▄▄
▐▓▓░░░::░::: :::░::░▓▍ ▊ ▋
▐▓▓▓░░░::░::░::::: :: :: ::::░::░░░░░░▓▓▍ ▐▄▌
▀█▓▓▓░▓░░::░:::░:::::::░::░░░░░▓░▓▓▓▌ ▄▅▀
378:372
05/06/05 22:51:30
>>373
遅延バインディングという概念は分かりませんが、
Javaで例えるとカプセル化の為にprivateという修飾子があり、
継承にはextendsという機能がありますよね？
でもポリモーフィズムには言語の機能としては何もなく
継承を利用したデザインパターン（ストラテジー？）じゃないかと
思うのです。
＞ポリモーフィズムには多数の種類がある。
これは詳しい解説キボンヌです。
379:デフォルトの名無しさん
05/06/05 23:18:50
>>378
> でもポリモーフィズムには言語の機能としては何もなく
>>373はそれがlazy bindingだという話だろ？
380:373じゃないが
05/06/05 23:20:13
>>378
> ＞ポリモーフィズムには多数の種類がある。
> これは詳しい解説キボンヌです。
adhoc polymorphism, inclusion polymorphism, parametric polymorphismの3つは
理解しておいたほうがいい。
381:デフォルトの名無しさん
05/06/05 23:53:07
＞遅延バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
まぁ、じっくり騙ってくれよ
382:デフォルトの名無しさん
05/06/06 02:41:09
プログラムがオブジェクト指向たる条件ってなに？
383:デフォルトの名無しさん
05/06/06 02:48:32
>>382
本質的には、クラスという設計図をもとに、インスタンス（オブジェクト）を生成して使う仕組み。
カプセル化とかポリモーフィズムとかは、どちらかと言うとオマケ的な機能だ罠。
384:デフォルトの名無しさん
05/06/06 02:51:27
・クラスを重視するのは、むしろクラス指向なのでは？
・それだと、モジュール指向や抽象データ型とあまり区別がなくなるのでは？
385:382
05/06/06 02:59:55
思うに、
・対象をデータ構造に抽象化・カプセル化し、カプセル化されたデータの関数であるメソッドを持つ。
→データそのものであり、またデータを操作する主体である。
・抽象されたものの集合の内包⇔外延関係が、派生という方法によって積極的に表現されている。
ということではないかと思うんだけど。どうでしょう？
386:382
05/06/06 03:10:17
カプセル化と書いてしまったけど、>>383が書いている通り、
確かにカプセル化はオブジェクト指向の本質ではないと思うんです。
しかし、ポリモーフィズムに関しては、例えば自然言語というのは、
「抽象されたものの集合の内包⇔外延関係(例：犬⇔コギー）」によって構成・表現されている。
その自然言語の構造を踏襲するならば、この関係を積極的に表現する
派生という方法をOOPが持つのは、極自然に感じます。
387:デフォルトの名無しさん
05/06/06 13:05:02
>>378-379
adhoc: interfaceのimplements
inclusion: class, interfaceのextends
parametric: C++のtemplateか
388:デフォルトの名無しさん
05/06/06 14:12:43
>>387
adhocはC++のfunction overloadingが典型例。
C++のtemplateはparametricとは言い切れない。型的に。
389:デフォルトの名無しさん
05/06/06 19:42:40
…えーと、よく解らないんだけど
「カプセル化されてないオブジェクト」って
有り得るの？想像付かない…
390:デフォルトの名無しさん
05/06/06 19:50:25
struct point { int x, y};
とかじゃないか
391:デフォルトの名無しさん
05/06/06 20:02:25
いつの間にか、話がムチャクチャな素人にかき回されてるな。
ブログラムもロクに書けない素人が平日昼間からシャシャリ出るな、と。
392:デフォルトの名無しさん
05/06/06 22:15:57
>>387
adhoc polymorphismは、overloadingとcoersion (i.e. int < float)
inclusion polymorphismは、例えばinheritanceの事。
parametric polymorphismは・・・C++ templateがお気に召さないなら、OcamlかJava Genericsでどうよ。
上記二つをまとめて universal polymorphismと呼ぶ。
>>373
下記の発言は一体どういう文脈の話なのか、ちゃんと説明しろよ
> ・ポリモーフィズムには多数の種類がある。
> 貴方が遅延バインディングについて言いたいのだと推測すると、それはオブジェクト指向の機能
> ・遅延バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
393:デフォルトの名無しさん
05/06/06 22:17:09
int < float つうと型パラメータみたいだな。
int number < float numberという比較演算子は、coersionとして実装される事が多い、と。
394:デフォルトの名無しさん
05/06/08 12:59:46
>>392
>下記の発言は一体どういう文脈の話なのか、ちゃんと説明しろよ
>> ・ポリモーフィズムには多数の種類がある。
ん？ 「ポリモーフィズムは……」って聞かれたんでランタイムポリモーフィズムを想像したけど、
ランタイムじゃないポリモーフィズムももちろんあるって忠告したかっただけ
テンプレートだとかメソッドのオーバーロードだとか、#if ～ #endif でさえ 『ポリモーフィズム＝多様』 で括れるし
395:デフォルトの名無しさん
05/06/08 13:01:25
って言うか数レス前で既に出た話ですねスマヌ orz
396:デフォルトの名無しさん
05/06/09 00:44:21
なんだ、やっぱ変な人が妄想騙ってただけか
397:デフォルトの名無しさん
05/06/09 20:23:07
>>396
自分が理解できないからって変人扱いすることは筋違いだとか、
そもそも勉強中の人を変人扱いすることは筋違いだとか思った
いや、俺もオーバーロードがポリモーフィズムの一種だと聞いたときには「ﾊｧ?」だったわけだが
398:392
05/06/09 21:14:58
はぁ？
＞遅延バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
これをまともに解釈するのは無理ってもんじゃないか？(hahaha
399:デフォルトの名無しさん
05/06/09 21:17:42
だいたい >>387、>>392の後で、
>>394みたいなタワケタ言い訳してる時点で終わってるよ
400:デフォルトの名無しさん
05/06/09 21:18:34
だいたい >>387-388、>>392-393の後で、
>>394みたいなタワケタ言い訳してる時点で終わってるよ
401:373
05/06/09 21:20:38
悪い。普通に 「遅延」 って言ったが 「動的」 の間違いだった罠 (´･ω･`)
あたま超混乱してます現時点で。
……けど、「それを～」 以降を訂正する気は全く無い。
402:デフォルトの名無しさん
05/06/09 21:26:07
はぁ？
＞動的バインディングは継承を利用しているが、それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
これもまともに解釈するのは無理じゃないか？(pupupu
403:373
05/06/09 21:27:36
間違っているのがどこだか分からん
俺の頭か (^_^;
404:デフォルトの名無しさん
05/06/09 21:30:27
えぇ～と、
勉強中の人が「～と理解しましたが、どうでしょう」と書くのは普通だが、
元々ろくすっぽ勉強する気もない荒らしが、掲示板で聞きかじった断片知識を
>>373のように書いてしまうのは、なかなか痛い行為だと思った。
405:373
05/06/09 21:35:54
いや、断片知識のほとんどが書籍からやわ
406:373
05/06/09 21:56:43
……謙虚に成りたい
407:デフォルトの名無しさん
05/06/09 22:02:27
英語だけどこれがわかりやすい。
On Understanding Types, Data Abstraction, and Polymorphism
URLﾘﾝｸ(citeseer.ist.psu.edu)
408:デフォルトの名無しさん
05/06/09 22:07:45
ここに内容が一部紹介されている。
URLﾘﾝｸ(www.mamezou.com)
409:デフォルトの名無しさん
05/06/09 23:29:59
言語はCさえ理解してれば十分
他の言語の文法は必要になったら覚えろ
オブジェクト指向でも構造化でも、3日後に自分で理解できるコード書いてくれればなんでもいいよ……
410:デフォルトの名無しさん
05/06/09 23:34:08
>>409
程度の低いところにお勤めですな(w
経験上、今時Cだけ知っててC++を知らない人は、実はCを良く理解していない
ことが多い
Cのあの糞ったれな宣言シンタクスを難なく読みこなせる程度でないと、
C++は無理だな
411:デフォルトの名無しさん
05/06/09 23:41:55
>>407-408
基本的に>>392と同じ。リファレンス [Cardelli & Wegner '85]って、もう20年も前の話か。
10年前のOOには、Genericsに代表されるような柔軟な型システムや
関数型言語(HOPE～SML, Haskell)の型推論とか
ほとんど取り入れられていなくて、知恵遅れの村に来た感じがして嫌だった。
普及型のOO言語は、ようやく20年前の水準に追いついたわけね。
412:411
05/06/09 23:48:07
えぇ～とぉ、
>>373 相変わらず概念と単語が混乱しているようだが、あんたが言いたかった前半は、
(>>372が「ポリモーフィズムはオブジェクト指向の機能ではないと言ったが)
Subtype polymorphiscm (継承による多態)は継承によるものである。
といったところか。で、後半部分
＞ それをわざわざもったいぶって「デザインパターン」と呼ぶのもどうかと思う
は相変わらず前半とつながんねぇな。
413:デフォルトの名無しさん
05/06/10 00:00:40
>>412
単なるポリモーフィズムを「これはデザインパターンだ！」と言いたくは無い
って言いたかったんや……
414:デフォルトの名無しさん
05/06/10 00:02:02
だから何それ？意味わかんねぇよ、あんたの文章は
415:デフォルトの名無しさん
05/06/10 00:03:23
一丁前にプログラム言語なんか勉強する前に、先ずは日本語を勉強しとけってことか。
416:デフォルトの名無しさん
05/06/10 00:07:20
「単なるポリモーフィズムを、デザインパターンだ！」と主張するような奴は、普通の所には居ない。
上でさんざんあんたがやってきたように、相変わらず単語や概念が無茶苦茶なまま理解して、
それを匿名掲示板に書き殴ってるだけじゃねぇの？
417:373
05/06/10 00:12:59
>>416
＞「単なるポリモーフィズムを、デザインパターンだ！」と主張するような奴は、普通の所には居ない
俺は 372 がこのことを主張したいように感じ取った。そして↑と同じ考えを書きなぐった。
ただそれだけなんだ…… orz
418:デフォルトの名無しさん
05/06/10 00:30:40
＞相変わらず単語や概念が無茶苦茶なまま理解して
そうか……端から見ればそう見えるのか。っていうか８年も Java の本めくってて何も身についてないですか orz
市にてぇ……
419:デフォルトの名無しさん
05/06/10 00:44:21
文法はCさえ知っていれば3日で覚えらえっる
概念にかんしてはオブジェクト指向の概念というより
もっと一般的なことを認識してほしい
420:デフォルトの名無しさん
05/06/10 09:27:48
>>417
確かに元の質問>>372は得体が知れないな。
Garbage In , Garbage Out の典型だな
421:デフォルトの名無しさん
05/06/11 16:03:50
CとJavaとC#を勉強しているのですが、C++だけやってません。
やはりC++はやったほうがよいでしょうかね？
C#できればいらない？
422:デフォルトの名無しさん
05/06/11 16:07:24
>>421
CとC#とjavaができるならC++の習得も(たぶん)容易だからやっとけば？
templateの強力さに感動せよ。
423:デフォルトの名無しさん
05/06/11 16:22:02
>>421
必要になったときで間に合うと思う
簡単なサンプルコードがC++で書いてあっても
ならJavaとC#ができれば概略はつかめるし
>>422
templateの真髄に突っ込むと火傷するよ…… 感動するのは同意
424:デフォルトの名無しさん
05/06/11 20:34:54
>>421
つうか、templeteのエラーメッセージの難解さに挫折すんなよ
いまや、C++は標準ライブラリでtempleteつかってからな
425:デフォルトの名無しさん
05/06/12 03:09:33
単発質問厨房：無意味な質問をして、レスが伸びるように誘導するだけの厨房。
相手にするだけ時間の無駄。つうか大抵自作自演でスレの話題を断ち切るだけの荒らし。
426:デフォルトの名無しさん
05/12/23 17:47:39
400超えのスレで何言ってんだよ
427:デフォルトの名無しさん
06/01/13 18:55:39
初心者なの
レベル高すぎなの
頭パンパンなの
428:デフォルトの名無しさん
06/01/15 20:46:33
概念学習が先です
C++使ってるくせにC以下のプログラム多すぎ
429:デフォルトの名無しさん
06/01/17 03:19:50
>>428
すまん。ホントスマン。
実は、あんまりCも分かってないんで、勘弁してくれ、
できればお勧めのCとC++の参考書を教えてくれ。
430:デフォルトの名無しさん
06/01/17 04:37:46
両方同時でしょ。
野球選手に体力と技術どっちが先に必要かって言ってるようなもんだ。
431:デフォルトの名無しさん
06/01/17 06:00:40
英語力も大事だね
ちゃんとしたプログラマのコードは英文として読めるけど
英語がダメなやつのコードは分けわかんねえ
432:デフォルトの名無しさん
06/01/17 11:00:09
メリケンの書いた糞コードは無視ですか
433:デフォルトの名無しさん
06/01/17 14:03:31
>>427
自分の理解能力を超えてやっても頭に入らない
これは学習スピードなども含んでいる
少しずつでも良いので理解を進めていけ
仕事で即時性を求められているなら理解しないでも作業を遂行できる能力を身に付けろ
434:デフォルトの名無しさん
06/01/17 14:23:47
まぁ、そういう事を考える前に、勉強なり手を動かすのが先だな。
435:デフォルトの名無しさん
06/01/17 18:58:49
オブジェクト指向の概念は「もの」指向だろ・・・。
その「もの」指向をどのように実現するかを言語を通して学ぶ。
概念が解っていなければ本当の意味で良い物は作れないし、
作るためには言語を理解していなければならない。
どっちが先ってもんでもないと思うが・・・。
これにて終了でどうでしょう。
436:マイク ◆yrBrqfF1Ew
06/01/17 19:16:34
オブジェクト指向なんてプログラミングをする上での考え方に過ぎない
馬鹿万能崇拝者がいるけど、あんなの本末転倒ですよ;)
437:デフォルトの名無しさん
06/01/17 21:23:09
>>436
今そんなこと話してないし
438:デフォルトの名無しさん
06/01/17 21:40:45
オブジェクトにこだわるとC++なんて糞言語使ってられなくなるのが普通
439:デフォルトの名無しさん
06/01/18 03:23:23
>>438
そこまでは言わないにしても、言語を使いながら学習していく場合には
適さないと思います＜C++
もっと素直で筋のよさそうな言語から始めるのがよいかと。
本命はやはりSmalltalkなんですかねぇ、でも今だとOOをサポートした
スクリプト言語を使うのがよさそうな気がします。
スクリプトなら余計なお約束はほとんど考えずにちょっと書いて
ちょっと試すことができるし、静的型が無い場合が多いと思うので
必然的にC++のvirtualみたいな歪んだものを扱わなくてよいし。
440:デフォルトの名無しさん
06/01/18 13:00:31
>>439
オブジェクト指向系のスクリプト言語はちょっとした試行を行う際には良いが
システムの構築と言った要件には使うべきではない
441:デフォルトの名無しさん
06/01/18 15:10:03
>>440
不適とする理由は？
442:439
06/01/18 16:05:31
>>440
あくまで学習目的のつもりで書きました。
そういう用途であれば素直に書ける言語が良いかなぁと。
規模が大きくなった場合にどうなるかはやったことがないので何とも。
「硬さ」が足りない部分を、十分なUnitTestで補えれば化けそうな気もするのですが……
443:デフォルトの名無しさん
06/01/18 19:12:46
スクリプト言語の弱点はスケーラビリティにあるんじゃない？
444:デフォルトの名無しさん
06/01/18 19:40:18
>>443
それこそ設計次第では？
445:デフォルトの名無しさん
06/01/18 20:07:22
言語の仕様による話だが、スクリプト言語によってはスケーラビリティを考慮した
アーキテクチャを取れないものがあると思う。
東証のプログラムとか銀行の基幹系システムをGroovy、Ruby、PHPで作れると思うかい？
446:デフォルトの名無しさん
06/01/18 20:17:20
>>445
メインフレームのバッチ処理という話であれば無理。
しかしながらそれは言語仕様によるものではない。
そもそもと金融システムでここ数年で出しゃばってきた手法を採用することはまずない。
なのでどうも実感がわかない。
もうちょい答えやすい例を挙げてくれるとうれしいです。
もしくはあなたが用意している答えを聞きたいです。
447:デフォルトの名無しさん
06/01/18 20:26:48
googleではpythonが広範囲で使われてるらしいやね
どの程度の規模なんだろうな
448:デフォルトの名無しさん
06/01/18 21:45:50
＞ そもそもと金融システムでここ数年で出しゃばってきた手法を採用することはまずない。
なぜ金融システムは保守的なのか？
その答えの一つにスケーラビリティ重視があるからではないだろうか？
スクリプト言語もチューリングマシンを標榜する以上、JavaやC++と同じ事は実現できる。
しかし、システム構築は言語だけで行われるものではなく、動作環境、フレームワーク、
ライブラリといったものに強く依存する。
言語仕様、環境、ツールといったものが渾然一体となり、文化が形成され、その文化の中で
設計思想というものが生まれるのだ。
つまり、同じシステムを構築しようとしてもスクリプト言語を使う場合とJavaやC++を使う場合で
設計は自ずと異なってくるのだ。
そして設計が異なると、その長所、短所も異なってくる。 結局のところ適用分野の住み分けが
起こってくるのは当たり前のことだと考えている。
449:デフォルトの名無しさん
06/01/18 22:00:48
>>448
保守的・・・私が思いつくのはCOBOLやCでごりごり書いたものを実績があるからと言う理由で後生大事に流用してると言う状況です。
全銀手順で2400bpsみたいな。
能書きはいいからちゃっちゃとまともに動かせや。と言う分野だと認識しています。
＞言語の仕様による話だが、スクリプト言語によってはスケーラビリティを考慮した
>>448さんは言語仕様ではなくソフトウェア資産の差が問題であるという認識なのですね。
PerlにはCPANがありますし、CLIな言語では垣根がなくなって来ていますから、状況は変わってくるかもしれませんね。
450:デフォルトの名無しさん
06/01/19 06:39:26
Perlは論外では？
451:デフォルトの名無しさん
06/01/19 12:03:11
やはり静的な型チェックを行う型づけの強い言語の方が大きいシステムには
向いていると思う。
ソースの意図が見て分かりやすいし、コンパイラが静的にチェックできる
意味は非常にデカい。
スクリプト言語は簡単な仕事を簡単に片付けることを重視して作られている
から、一人で片付けるようなちょっとした仕事には非常に向いているが、
それで大規模なシステムを構築しようという気にはならん。
Perlはなあ。暗黙のグローバル変数の乱用、シンタックスの汚さ、それらによる
コードの読みにくさ。マルチスレッド非対応。
まあ論外だろ。
452:デフォルトの名無しさん
06/01/19 13:29:00
>>451
書き方を気をつければいいという話ですね。
453:デフォルトの名無しさん
06/01/19 16:59:09
>>452
「気をつければいい」でバグがなくなるかボケ
言語仕様として一部のバグの発生をありえなくすることのほうが
よっぽど大事
お前一人が頑張っても無駄。一人で作るわけじゃねーんだぞ
454:句読点書けないバカをサマージャンボする俺 ◆9NQzQ21lx.
06/01/19 18:37:46
>>453
455:デフォルトの名無しさん
06/01/19 19:49:27
大規模開発の場合うるさいくらいの規約が当たり前だけど
納期前だとんなもん軽く吹っ飛ぶからなｗ
あっと言う間にワンライナーの出来上がりだぜ！
456:デフォルトの名無しさん
06/01/19 20:12:17
なんだってさ
さあみんな大規模開発でPerlを使おう！！
457:デフォルトの名無しさん
06/01/19 23:01:54
Perlは論外
458:デフォルトの名無しさん
06/01/19 23:04:27
>>457
おまえは雇わないので何の心配もいりません。
459:デフォルトの名無しさん
06/01/19 23:15:32
>>458
お前ごときが人を雇用することはありえませんので何の心配もいりません。
460:デフォルトの名無しさん
06/01/20 01:44:26
まあ、PHPも作り捨てなら有りってレベルだな
461:デフォルトの名無しさん
06/01/20 08:00:03
うっかりPHPを選択してしまって今大変なことになってます。
462:デフォルトの名無しさん
06/01/20 08:26:28
PHPは言語じゃないからなぁ
463:デフォルトの名無しさん
06/01/20 12:18:21
>>452
いや、一人で閉じてる世界なら「書き方を気をつければいい」で済むんだけどな。
あんた、仕事で大規模開発をやったこと、無いでしょ。
464:デフォルトの名無しさん
06/01/20 17:46:27
大規模開発においては、その種の事を決める人間はコードを書かないｗ
465:デフォルトの名無しさん
06/01/20 23:14:56
>>464
いい加減上流の仕事もできるようになりましょうね。
466:デフォルトの名無しさん
06/01/21 12:04:46
もう遅すぎる
467:デフォルトの名無しさん
06/03/02 19:59:15
いい本を見つけました。
「勝者のシステム 敗者のシステム」坂口英弘著
この本では、オブジェクト指向の考え方や、具体的なシステム設計の
ノウハウが紹介されています。これまでのオブジェクト指向の解説書
には無い実戦的な内容です。ただし、前半はビジネス書っぽい内容です。
特に、アプリケーションの階層化や開発体制とオブジェクト指向の関連
を明確に示している点は新鮮でした。
無能ＰＭの批判など（イラスト見てワロタ）もあり、面白い本なので
オススメです。
468:デフォルトの名無しさん
06/03/03 03:04:27
オブジェクト指向なんて高校生だってマスターできる
469:デフォルトの名無しさん
06/03/03 11:56:58
>>468
ケイの（流れの。Smalltalkとかがサポートする）はそうかもね。
もともと子供向けだし。なんでもメッセージングだし。難しいのは「メタ」という
概念を体得することか。もっとも、ステレオタイプなオトナより子供のほうが得意？
URLﾘﾝｸ(tinyurl.com)
... 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.
URLﾘﾝｸ(www.purl.org)
...OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding...
ストラウストラップの（流れの。C++やEiffel、Javaとかがサポートする）はどうかな…。
データ型とは何かについて理解できていないと難しいと思う。
加えて、抽象データ型はなにかとか、最近ではインターフェイスとか。
URLﾘﾝｸ(public.research.att.com)
... 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...
ということで「概念学習が先」に一票。
470:デフォルトの名無しさん
06/03/03 14:39:03
学生で独学でjava(たまに先生にも教わる)やってるけど、
いきなりオブジェクト指向をたいして勉強しないで言語から
始めたから苦労したかも
ただ、間違えまくっていくうちに、オブジェクト指向についても結構おぼえていった希ガス
471:デフォルトの名無しさん
06/03/03 14:58:43
オブジェクト指向を覚えるなら
デザインパターンを理解することが近道だよ
はっきりいって
472:デフォルトの名無しさん
06/03/03 19:21:16
>>471
オブジェクト指向とデザインパターンに直接の関係性はない
473:デフォルトの名無しさん
06/03/03 20:02:40
>>472
デザインパターンがオブジェクト指向原則を理解する上での例題に
なり得る点を考えると、>>471 の言うこともまんざら間違っていない。
474:デフォルトの名無しさん
06/03/03 22:53:01
覚えるなら実践
理解するならデザパタやリファクタリングなど
475:デフォルトの名無しさん
06/03/03 23:59:55
EclipseのようなIDEや
UMLを覚えてUMLツールを使いこなせれば
オブジェクト指向に対する理解が早まるかもしれないな
476:デフォルトの名無しさん
06/03/04 10:22:51
>473
うん，そう思う
>471は，オブジェクト指向とデザインパターンが関連してると言ってるんじゃないし
>472みたいな脊髄反射をよく見るけど，なんだかなぁって思う
477:デフォルトの名無しさん
06/03/04 23:24:11
>>472は「直接の関係はない」といってるから「間接の関係はある」と認めてるんだよ、多分
Java、Ruby等のいろんな言語の文法を片っ端から覚えて
各言語の機能を比較していくのが早いんじゃないかなと思ってる
デザパタもいいよね
オブジェクト指向必要ないよ？ と思ってる人に、良さを知ってもらうのに役立つ
478:デフォルトの名無しさん
06/03/05 14:08:35
SmallTalk とか、出始めの C++ とかちょっといじったころは、
「便利だけど、クラスとかメソッドとか一杯出来すぎて管理しきれねー」
と思って手出し控えてた時期があった。
Java を平気で使い出したのは、Eclipse を使い出してから。
IDE の存在は結構大きい、というか必須では。
479:デフォルトの名無しさん
06/03/05 14:55:24
>>478
Smalltalk も Browser がないと絶対使い物にならなかったと思います。
そう言う意味で IDE は確かに偉大ですな。
あと Smalltalk の t は小文字で書くのが正しいっす。
ちゃんとした文献ではすべて t が小文字になってます。。
（ただ、開発者の一人であるアラン・ケイはどっちでもいいと言っていたと思いますが。）
480:デフォルトの名無しさん
06/03/06 09:23:48
無料のEclipseがあるのにオブジェクト指向が学べないやつは真性アフォ
481:デフォルトの名無しさん
06/03/08 21:54:45
Eclipseとオブジェクト指向は関係ないだろ。
Eclipse使って、プロセス中心のプログラム書いてるやつもいるよ。
これまで見てきた中で、ツール依存のやつは、例外なくアフォ。
分かってるやつなら、Notepad使ったって立派なオブジェクト指向の
コードを書くよ。
482:デフォルトの名無しさん
06/03/08 22:17:30
書けるやつはC言語でオブジェクト指向らしいものも書ける
483:デフォルトの名無しさん
06/03/08 23:04:07
>>482
またそれか。
484:デフォルトの名無しさん
06/03/08 23:38:26
VB厨でしたが、「フォームにカスタム プロパティを追加する」あたりから
入ってじわじわ分かり出しました。
その後Ｃ♯を始めるまでに、VBで実践出来る範囲のこと（インスタンスとか
インターフェースとか委譲とか）を使っていたので、結構スムーズに
移行できました。
会社の中には、VB6の仕事がなくなるまで「グローバルの関数と構造体」で
シコシコやってきた人たちもいますが、彼らは現在、途方に暮れつつも
public staticなメソッドとインスタンス変数でなんとかやっています。
485:デフォルトの名無しさん
06/03/09 00:41:32
public staticしか作れないなんて最悪だな
C言語厨と同類じゃないか
486:デフォルトの名無しさん
06/03/09 00:51:37
馬鹿に巨大なクラスを書いてOOPした気になってるVB/DEL厨は最悪だ。
巨大クラスのクラスフィールドはグローバル変数と変わらん！
487:デフォルトの名無しさん
06/03/09 03:24:59
C言語で書かれたオブジェクト指向設計のソースは
とてもじゃないが生産性が高いとは思えない
488:デフォルトの名無しさん
06/03/09 10:31:55
>>481
もちろん、直接は関係ないよ。
IDEを使えば自然とオブジェクト指向になるわけでも、
使わなければオブジェクト指向ができないわけでもない。
ただ、管理しなければならない要素（クラス名、フィールド名、継承関係）
が増えるから、IDE のサポートがあったほうが楽、というか、無いとしんどいということ。
逆に言うと、IDE の恩恵を受けやすいともいえる。
変数のクラスから、メソッド名などが（継承されたものも含め）コード補完されるといった機能の恩恵は
例えば C言語などではあまり無い。
（構造体からメンバ名がコード補完されるだけではあんまりうれしくない）。
489:デフォルトの名無しさん
06/03/09 13:06:36
>>482
Motif のサブクラス書いてて厭になった。
是非一度お試し下さい。
490:デフォルトの名無しさん
06/03/09 19:22:15
>>488
＞もちろん、直接は関係ないよ。
＞IDEを使えば自然とオブジェクト指向になるわけでも、
＞使わなければオブジェクト指向ができないわけでもない。
だったら、そう書いてね。
EclipseだのAjaxだの言ってるやつに限って、仕事できないのが
多くて困ってるんだ。趣味でやってるのか、プロジェクトに使え
るのか全く気にしてない。つまり、ヲタな奴が多い。
491:デフォルトの名無しさん
06/03/09 23:51:20
>>490
会社で嫌なことがあったかと言って、
勝手な偏見を持ち出されてもなあ。
Ajaxが今のところオブジェクト指向の勉強に役立つとは
とても思えないが、
Eclipseはかなり役立つ機能が揃っているのは
俺もたしかにそう思う。
設定で警告メッセージ項目を徹底的に増やして
FindBugs, CheckStyleなどを組み合わせて、
リファクタリング機能を使いこなすと
そのことがよくわかる感じだ。
492:デフォルトの名無しさん
06/03/10 12:43:54
>>491
>Ajaxが今のところオブジェクト指向の勉強に役立つとは
>とても思えないが
そもそも、その両者に何かの関係があるとも思えないが。
IDEとOOにしてもそうだが、無関係の何かを
関連付けるのが流行ってるのか？
493:デフォルトの名無しさん
06/03/10 17:34:24
>>492
ヒント：ゆとり教育
494:デフォルトの名無しさん
06/03/10 23:37:58
Eclipseを否定するやつにかぎって仕事ができないのが多いんだ
オブジェクト指向と聞くと逃げ出すようなダメグラマ
495:デフォルトの名無しさん
06/03/11 00:43:41
Eclipseを否定するとかしないとか、そういう議論する余地ってまだあるの？
496:デフォルトの名無しさん
06/03/11 15:41:17
継承はわかったが、結婚ってないのか？
497:デフォルトの名無しさん
06/03/11 18:36:39
Eclipseを苦々しく見ている気持ちは分かるよ。
ＯＯの思想を理解しないで、カタチから入ってしまう人が
多いからね。そういう人が実に多い。
要するに、Eclipseを否定しているのではなく、そういう
ツールとかに興味が行ってしまう開発者の問題なんでしょ？
498:デフォルトの名無しさん
06/03/11 18:50:39
>>496
結婚は近親相姦の問題(共通の親を持つ兄妹は同一の形質を持つ
この兄妹が子供を儲けると遺伝形質に曖昧さが発生する)があるか
ら、Javaでは採用を見送られた。
しかし結婚がないからといって悲観する事はない。
そもそも、嫁萌えより妹萌えだろ？
養子縁組を利用すれば相手を問わず妹萌えできる。
結婚なんてそもそも不要なんだよ。
499:デフォルトの名無しさん
06/03/11 22:02:05
>>497
Eclipseは数多くプラグインがでているから
それを使って楽しみたいと思っている香具師が多く、
結果的にEclipse自体が重たくなって使いにくくなるって
いうことならある。
けど、オブジェクト指向プログラミングの真価を
発揮しやすいIDEであることには変わりないな。
500:デフォルトの名無しさん
06/03/11 22:06:45
こんなのを見つけた。
EclipseでJavaに強くなる - ＠IT
URLﾘﾝｸ(www.atmarkit.co.jp)
501:デフォルトの名無しさん
06/03/12 05:24:31
>>498
なんとなく本質が理解できました。＾＾
502:デフォルトの名無しさん
06/03/12 19:48:28
Javaは子孫を残す対象を厳しく選んでしまうという喩えか。
まあそうかもしれない。ちょっとしたことですぐコンパイルエラー出すし。
厳しすぎるのも無理もない。
だらしない男を許さない女みたいな
503:デフォルトの名無しさん
06/03/13 04:52:30
>>502
そういう意味ではJBuilder3は最強だな
継承関係の途中のclassファイルが無くてもコンパイルが出来る
504:デフォルトの名無しさん
06/03/13 12:46:34
Eclipseが使えるなんて当然だろ。できないやつは逝ってよし！
505:デフォルトの名無しさん
06/03/13 23:25:23
Eclipseばっかだけど、VisualStudio.NET 2005 ってどうよ。
MSは、Eclipseより生産性ずっと高いって言ってたよ。
チーム開発の機能が売りみたいだったな。
506:デフォルトの名無しさん
06/03/14 01:44:05
>>505
Teamなんたらじゃないときついな
家でちょろっと遊ぶ程度ならExpressやStandardでも良いんだけど
507:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 20:46:45
TextSS のWindowsXP(Professional)64bit化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
508:デフォルトの名無しさん
06/03/19 02:45:21
>>505
VS.NET 2005のチーム開発がEclipseよりも
売り？ まさかVisual Source Safeをバンドルしただけで
売りだなんて言わないよな。
VSSはSubversionには非常に劣るし
509:デフォルトの名無しさん
06/03/19 11:33:21
>>508
確かに最近、MSはパッとしないね。
マンネリというか、売る気が無いというか、2000年頃は
期待も高かったんだが．．．今はLinux/Javaにやられっぱなしだ。
もうだめぽ？
510:デフォルトの名無しさん
06/03/19 12:09:04
Eclipseの大人気に
焦ってVS.NET 2005 Expressを無料で配布してるくらいだ。
しかもC#やVB.NETの仕事もろくにないし。
PHPとJavaの仕事ばっかで今ドトネトはかなり窮地に立たされているともいえる。
511:デフォルトの名無しさん
06/03/19 12:43:30
JAVAってあまり使ったことないんだけど、
Eclipseって個人だけじゃなくて、実務でも普通に使われてるものなの？
512:デフォルトの名無しさん
06/03/19 12:52:52
ニート卒業するのが先
513:デフォルトの名無しさん
06/03/19 13:29:16
>>511
普通に使われてるよ。
Linuxと同じで、既存のディストリビューションを購入して使ってるところから
自社で独自にパッケージングして使ってるところまで色々だけど、結局Eclipse
である事に変わりはない。
514:デフォルトの名無しさん
06/03/19 13:35:57
Eclipseを個人で使うほうがびっくりだ。
515:デフォルトの名無しさん
06/03/19 13:48:11
Eclipseなら大学の研究室で使ってるよ
516:デフォルトの名無しさん
06/03/19 14:29:02
>>513
そうなんですかー
使いもしない数十万のパッケージなんて会社では
買ってもらえないので、実務に耐えられるJAVAの勉強
どうやってやろうか困ってたんです(;´Д`)
>>514
でもJAVAの開発関連を検索したらIDEではEclipseぐらいしか
見当たりません
個人ではIDEなんて使わないんですか？(;´Д`)
517:デフォルトの名無しさん
06/03/19 14:31:05
>>516
EclipseかNetbeansでいいじゃん 俺はNetbeansをお勧めするけど
まあこのスレよりもっと適切なスレがあると思うので詳しくはそっちへ
518:デフォルトの名無しさん
06/03/19 14:40:00
>>516
>>個人ではIDEなんて使わないんですか？
そんなこともないけどさ。
なんというか、個人で使うには機能が立派すぎる。
言い方を変えれば「重すぎる」んだよねえ。。。
519:デフォルトの名無しさん
06/03/19 15:28:56
学生なんで個人で使ってるが、あれは一度使うと手放せないな…
520:デフォルトの名無しさん
06/03/19 18:24:43
>>514
Eclipseは個人で使った方が楽しめるぞ。
ゲームだってできるし
株価チェックだってできるし、
そういうプラグインを作る楽しみがある。
プラグインバリバリ入れたい放題ってのがいいねえ
521:デフォルトの名無しさん
06/03/19 22:41:46
２ちゃんも見られる・・・・・・・が、開発には害になるｗ
522:デフォルトの名無しさん
06/03/20 07:19:01
Javaで仕事ったらほとんどサーバーサイドで、MSはサーバーサイドでは押されてるが､
クラサバや単なるクライアントアプリでは、問題なくねぇ？
この先、WebアプリはUIが貧弱で、結局、流れはスマートクライアントとかなるかもしれんし。
523:デフォルトの名無しさん
06/03/20 09:50:34
>>521
monalipseなどでEclipse上で見られるが、
有益になる情報も手に入ったりする。
monalipseは使い勝手が悪いので
Jane Doe Styleを使っているがw
524:デフォルトの名無しさん
06/03/20 09:51:41
>>522
どうだろうねえ。
クライアントサイドでもJavaに押されてる気がする。
NetBeans勢力拡大とSwing APIのめまぐるしい性能機能向上
がC#やVB.NETを圧倒している。
525:デフォルトの名無しさん
06/04/16 14:18:32
object is poormans closer!!!!!!!!!!!!
526:デフォルトの名無しさん
06/04/16 19:55:52
closer ってなんだ？ww
closure って書きたかったのﾎﾞｸ？
527:デフォルトの名無しさん
06/04/16 20:00:08
くろーざーといったらミセリだろ
528:デフォルトの名無しさん
06/04/16 20:59:52
ミセリねぇ、、、よく燃えてたよねぇ。
って懐かｽｨ。。。
529:デフォルトの名無しさん
06/04/20 18:04:19
意味が分からない
530:デフォルトの名無しさん
06/04/21 07:33:08
つ URLﾘﾝｸ(images.google.co.jp)
531:デフォルトの名無しさん
06/06/13 00:59:17
トラックバック:URLﾘﾝｸ(app.blogs.itmedia.co.jp)
脱オブジェクト指向のススメ
URLﾘﾝｸ(blogs.itmedia.co.jp)
このイーキャッシュの代表取締役玉木の発言がおかしいから
このスレからpinする。
オブジェクト指向のことをまったくわかっていません。
というか、かなり勘違いしています。
そのくせにオブジェクト指向を否定しています。
532:デフォルトの名無しさん
06/06/24 05:25:02
なんとなく覚えたのはいいけど
オブジェクトのよさがまだいまいちわからない…
関数とあまりかわらないんじゃないかとか
いまいちよくわかってないので、疑問が出てくる
まあ色々と違うんだろうけどアセンブラだって普通のCだって
普通は部分部分でまとめてやるだろうから
同じなんじゃなかろうかとか
隔離して部品として纏められるのがいいんだろうか
他に影響が出づらいとか安全に纏められて管理がしやすいとかだろうか
533:デフォルトの名無しさん
06/06/24 10:03:49
>532
勿論必ずしも必要じゃないがOOPLの方が書き易い処理もいくつかある
1. 構造体や関数をひと纏めにしてグローバルな名前を減らせる
2. 型不定な引数や型ごった煮リストに対応する処理
3. this/selfの存在は何気に大きいと思う
4. 元々OOの発祥である物と物の関係を表す処理
5. GUIライブラリとの相性
534:デフォルトの名無しさん
06/06/24 17:45:00
>>533
なるほどまだあまりよくわかってないけど
無くても出来ることは出来るけど一纏めに出来てミスも防ぎやすいって
ことなんかな
確かにきっちり別れてるからいいっぽい気はするし
ライブラリによってはってのもなんとなくそんな気がする
どんどん使っていけばわかってくるんだろうか
535:デフォルトの名無しさん
06/06/24 18:17:22
>>534
オブジェクト指向を用いたコードと、それを用いずに書いたコードを
具体的に出して比較してみると利点・欠点がわかるかも
536:デフォルトの名無しさん
06/06/26 10:49:22
>534
> 無くても出来ることは出来るけど一纏めに出来てミスも防ぎやすいって
> ことなんかな
プログラミング言語の進化はそれこそが目的だと思う
537:デフォルトの名無しさん
06/06/27 20:27:24
オブジェクト指向のよさがわからない人は
大規模開発したことないんだろうなー