トップページ⇒tech
1001コメント385KB

オブジェクト指向の概念を教えれ

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさんNGNG
優秀なお前らに質問です。
JavaScriptで document.write("Hello!"); がやっと書けるようになったオイラに、
オブジェクト指向の何たるかを、わかりやすく、華麗に、スマートに教えてください。
これは、主に自然言語において発揮される高い言語能力が、
プログラマの優秀さの必要条件でもあるという想定を検証するためにも、
チャレンジしがいのある課題であるｺﾞﾙｧ
0002手間は省こうNGNG
うっせぇ、ハゲ
0003デフォルトの名無しさんNGNG
オブジェクト指向　Part2
http://pc.2ch.net/test/read.cgi/tech/1002523282/l50

オブジェクト指向は戦場では必要無し　その２
http://pc.2ch.net/test/read.cgi/tech/1013266554/l50

好いた方へどうぞ。

　　　　　　∧∧　　ミ　＿　ドスッ
　　　　　 (　 　,,)┌─┴┴─┐
　　　　　/　　　つ　糸冬　了. |
　　　～′　/´　└─┬┬─┘
　　　　∪ ∪　　　　　││　_ε３
0004デフォルトの名無しさんNGNG
JavaScript知らんのだが
オブジェクト指向って関係あるのか？
0005デフォルトの名無しさんNGNG
>>3覗いてみたけど、なんだかわかりません。抽象的なものなの？
0006デフォルトの名無しさんNGNG
>>4
JavaScript 言語はプロトタイプベースのオブジェクト指向言語として使える
http://www.tokumaru.org/JavaScript/

>>5
オブジェクト指向は概念だからね。
http://www.ogis-ri.co.jp/otc/hiroba/technical/OO_Guide/index.html
http://www.ogis-ri.co.jp/otc/hiroba/technical/concept.html
0007デフォルトの名無しさんNGNG
>>6プログラミングの勉強をすれば、実感を伴って理解できる時期がくるですかね。
0008not 6NGNG
>>7
そうだね、まずはプログラミングのお勉強をしましょうね。
0009デフォルトの名無しさんNGNG
>>1
簡単に説明してやるからよく聞けよ。
6年3組の生徒は、田中くんも鈴木くんも佐藤さんも高橋さんも
みんな"6年3組の生徒"として扱える。
それがオブジェクト指向だ。
0010デフォルトの名無しさんNGNG
わかりやすくなってきたような、
いまいちのみこめないような、
0011デフォルトの名無しさんNGNG
性質を付加して対象を作り上げる。
0012デフォルトの名無しさんNGNG
>>9
つーことは
敵キャラ消して５秒後に出すってやると
スライムもドラキーもいどまじんもそうなるんか？
0013デフォルトの名無しさんNGNG
>>11鋭いことを言われた気がする
0014デフォルトの名無しさんNGNG
　　　　　　　　　　　 /　￣￣￣￣￣￣￣￣￣￣ /
　　　　　　　　　　　/　　　この糞スレは無事に　/
　　　　　　　　　　 /　　終了いたしました　　　 /
　　　　　　　　　　/　ありがとうございました　 /
　　　　　　　　　 /　　　　　　　　　　　　　　　　/
　　　　　　　　　/　　　　モナーより　　　　　 /
　　　　　　　　 /￣￣￣￣￣￣￣￣￣￣￣/
　 ∧＿∧　　/　　　　　　　　　　　　　　　　/∧＿∧
　（　^∀^）　/　　　　　　　　　　　　　　　　/（^∀^　）
　（　　　　）つ　　　　　　　　　　　　　　　⊂（　　　　）
　｜ ｜ ｜　　　　　　　　　　　　　　　　　　 ｜ ｜ ｜
　（_＿）＿）　　　　　　　　　　　　　　　　　　（＿（＿_）
0015デフォルトの名無しさんNGNG
反対する;　不賛成である
0016デフォルトの名無しさんNGNG
>>1

本屋に行くと1冊5000円くらいのテキストがあるから、買って来い！
0017デフォルトの名無しさんNGNG
>>9
これでいいの？

enum { TANAKA, SUZUKI, SATOU, TAKAHASHI } class63;
0018デフォルトの名無しさんNGNG


　　　　　　　　　幼馴染
　　　＞＞１　　　　⇔　　　　ＶＢ

　　　　↓　片思い

オブジェクト指向　　　　　　⇔　　　　　クラス概念
　　　　　　　　　　　　　付き合ってる
　　　　↑　友人　　　　　　　　　　　　　　　↑　友人

　ＶＣ＋＋，ＪＡＶＡ　　　　　　　　　　　　カプセル化
0019デフォルトの名無しさんNGNG
抽象的な例え話なぞ、OOPを理解してる人間がうなずくだけであって
わからん奴にとってはなんの糧にもならない。ますます煙に巻くだけ。
OOPとは追体験的に理解するべき概念だ。
初心者はうだうだ考えずにまずCLASSでも書いてみろ。
0020デフォルトの名無しさんNGNG
実際に書いてみて何故必要になるのかが体験的に理解できれば良し
0021デフォルトの名無しさんNGNG
>>16紹介して
>>18同じく紹介して
>>19-20まったくもってその通りのようなんですけどねー
0022デフォルトの名無しさんNGNG
classギコハニャーン
にメソッド[逝ってよし]を実装すれば、

　　 　　　　∧∧
～′ ￣￣( ﾟДﾟ)＜逝ってよし
　 UU￣￣ U U　


継承↓

ギコの継承クラスであるclassギコフッサールも

　　,,,,,,,,,,,,,,, ∧∧　
～′,,,,,,,,,,ミ,,ﾟДﾟ彡＜逝ってよし
　UU"""" U U

[逝ってよし]メソッドを持つことになる。
0023デフォルトの名無しさんNGNG
面白いが余計わかりづらい
0024メタレスNGNG
OOについて1レスだけで何かを説明しようとしている
レスは全て間違っている。
0025デフォルトの名無しさんNGNG
>>1=21?
つーか、JavaScriptを自由自在に使いこなすのに
オブジェクト志向は全く必要ないので勉強する必要はありません。
ここで良書を教えてもらって買ったとしても本代の無駄です。
（煽りではないよ。マジレス。）
0026デフォルトの名無しさんNGNG
>>19
そりゃそうだ．「はさみってどんなの？」と聞かれたら，実際につかわせる
のが一番はやいですからね．

でも，こういう話は好きなので，私の理解している部分を
＃>>1には絶対理解不能だろうけど……

OOP：
　データ＆関数で取り扱っていた構造化プログラムから発展した概念．
　「～～って何？」「～～してほしい」といった『目的』をベースに
　プログラムすることができるのが特徴．

　構造化プログラム言語は，「関数を使ってデータを加工する」
　手順が一般的で，データの構造や状態を考慮してプログラムする
　必要があるが，OOP言語はそのあたりを容易に（目的ベースの記述に）
　抽象化できる．
　
＃Ｃみたいなオブジェクト指向に対応していないと言われている
＃プログラム言語でも，オブジェクト指向的な記述は可能ですね．
＃よくできたライブラリだとデータの状態を意識することなく
＃プログラム出来ますし，Ｃベースで開発されているスクリプト
＃言語（Rubyとか)とかも，中の記述はオブジェクト指向ですからね．

あと，Objectオブジェクトを『物』と訳している本とかあるけど，正しい？
私は『目的』じゃないかと思うんですけど……
どう考えてもOOPの概念をわかりづらくしている諸悪の根源のような
気がする……
0027デフォルトの名無しさんNGNG
>>26は
犬.鳴く
猫.鳴く
止まりの衒学者。
0028デフォルトの名無しさんNGNG
あほばっか
26とか嘘だから気をつけるように
0029デフォルトの名無しさんNGNG
でもどこいっても>>26みたいな説明だよ
0030デフォルトの名無しさんNGNG
人間が普段行うような
(世界)全体が部分(物、オブジェクト)から構成されていて
それらが影響しあって(すなわちメッセージをやり取りしあって)
物事が進んで行く、という思考様式のこと
そういうモデル化をプログラミングでも行うって言う
ムーブメントだな。それによる利点とかは
上で誰かが書いているようなことだ
0031デフォルトの名無しさんNGNG
>>25
ということは、JavaScriptを使いこなせるようになったあかつきにも、
オブジェクト指向が理解できてないということでしょうか？
00329NGNG
>>17
交換可能性という意味では当たってる(言いたかったのは抽象化だけど)。
それだけでは何の意味も無い OO の構成要素だったね。というわけで >>24 に同意。

>>1
というわけで、 >>19-20 に同意しつつも、それだけじゃあんまりなので
何を勉強すると OO への理解が早まるかというのを記してあげます。
それは GoFのデザインパターンです。
OO をわかってる人が厳選した OO の使い方ですので、これらが(なぜこういう設計か)
理解できると、あなたも OO が理解できちゃいます。
003326NGNG
>>27-28
ありゃ．そうだった？

したいことをするために細部に立ち入らなくていいっつうのがOOPの目的かな
と思ってるんだけど．

ちなみに蛇足だけど，
>>27
犬.鳴かせる
猫.鳴かせる
じゃない？
0034デフォルトの名無しさんNGNG
正直、JavaScriptの仕様は不可解。
0035デフォルトの名無しさんNGNG
マジレスだよ
ネタじゃないよ


C言語をまずやりましょう

その後にC++に移りましょう
複数の関数とデータが合わさったものが「クラス」です
クラスを使ってプログラミングをすることがオブジェクト指向プログラミングです
（と考えてもいいの。これに文句を言う奴は小学生に「自然数とは・・・」と語り出す
数学オタと変わらない）

ここでどのような基準でクラスを切り分けるかの問題があります
この時の切り分け方の思想が「オブジェクト指向的概念」です

ここでやたらおかしな抽象論を振りかざす輩がいるから
ワケワカ状態になるのです
まずは具体的な処理の仕方から入った方がいいでしょう

0036デフォルトの名無しさんNGNG
他のオブジェクトとの関係によって定義され抽出された概念一般に対する呼称がオブジェクト。
オブジェクトの統合された存在としてソフトウェアを構築するのがオブジェクト指向プログラミング。
0037デフォルトの名無しさんNGNG
デザインパターンで検索したら、よけい難しそうな話ばかりだたよ。
003835NGNG
クラスの一番のメリットは「カプセル化」です
これは一定の処理をクラスの中に閉じ込めることです
まずこれのメリットを理解しましょう

「継承」やら「多態性」やらは無視して構いません
0039デフォルトの名無しさんNGNG
>>35そんなにやらないとダメかな
0040デフォルトの名無しさんNGNG
このスレには未経験衒学者と低学歴コーダしかいないんだね(藁
004135NGNG
初心者は
「クラスをどのように利用するのか」と
「クラスをどのように設計するのか（切り分けるのか）」
を区別しましょう

最初の内はクラスの利用だけでいいでしょう
クラスの利用とは既存のライブラリを利用することです

自分で設計するクラスは一つだけでもいいでしょう
一つのクラスの中に全ての処理を入れてもいいです
0042デフォルトの名無しさんNGNG
>>40
アクター理論や型理論でも持ち出したいなら是非ともやってくれ。
004335NGNG
>39
Javaから入ってもいいです
でもJavaの解説書は抽象論が多くてワケワカになる可能性も高いです
抽象論は無視できるのならJavaでもいいです
0044デフォルトの名無しさんNGNG
なんか、みんな、開眼の言葉とか、目ウロコのコードとかありませんか？
コード書かれてもわからないけど
004535NGNG
デザインパターンは初心者には理解不可能です
デザインパターンはサッカーで言えば「戦術」に当たります
ロクにドリブルもパスもできないサッカー初心者に
「ゾーンデフェンスとは・・・」と語るようなものです
まずは基礎技術を磨きましょう
基礎技術を磨かなければ戦術には意味がありません
0046デフォルトの名無しさんNGNG
>43
OOPLの理論(43の言うところの抽象論)を
読んで理解できないとしたら読解力に難ありだよ。

カプセル化、継承、多態を理解しようと努めて
結果的に理解できなかった人で、
非OOPLな言語ではものすごい生産性を誇ってる人なんていないだろ。

>42
お前も相当に読解力が足りないな(藁
0047デフォルトの名無しさんNGNG
>>35
複数の関数とデータが合わさったものは「プログラム（又はライブラリ）」じゃないの？（ｗ
0048デフォルトの名無しさんNGNG
>>46
このスレには未経験衒学者と低学歴コーダしかいないんだね(藁
　　　↓
　　　これの真意が・・・
　　　↓
OOPLの理論(43の言うところの抽象論)を
読んで理解できないとしたら読解力に難ありだよ。

・・・だっつうんか？
004935NGNG
>47
貴方のツッコミはくだらなすぎて相手にできません
早急に接続を切って首を吊って死んでください
0050デフォルトの名無しさんNGNG
>>49
はたから見ても見苦しいな
0051デフォルトの名無しさんNGNG
ケンカだ、ケンカだ、
喧嘩とオブジェクト指向はプログ板の華だね
0052デフォルトの名無しさんNGNG
>44
VBを使ってみて一度挫折したC++(class)を理解できた
「使う側」の視点に立てれば「作る側」も見えてくるかと
0053デフォルトの名無しさん NGNG
>>52
VBではポリモーフィズム理解出来てないとCLASSを理解した(VBレベルでの)
とは言えないよ。ＶＢでインタフェースのインプリメントとか出来る？
0054デフォルトの名無しさんNGNG
具体例を挙げないとわからんだろ。
それから細部を一つずつ理解しようとしてもムリだ。
まさしく「外国語」を覚えていくみたいに学習していかないと身につかないよ。
005535NGNG
ある程度クラスの利用に慣れたら
自分でクラスの設計をしてみましょう

この時に、「どのようにクラスを設計したらいいんだろう？」
と思い悩むでしょう。

具体的な処理面から言えばクラスとは「複数の関数とデータが合わさったもの」です
しかしここでクラスというものを抽象的に考えると
「一定の処理をするモノ」とみなすことができます
その「モノ」をオブジェクトと呼ぶことにしましょう

ここから抽象論が始まります。
「オブジェクトに何をさせたいのか？」
「オブジェクトに何を伝えるのか？」
「オブジェクトは何を知ってるのか？」
このような抽象的問いを実際の具体的なクラスの構造に落とし込む過程こそが
「オブジェクト指向」なのです

オブジェクト指向プログラミングで最も大切なことは
具体的思考と抽象的思考の両面から思考することです
0056デフォルトの名無しさんNGNG
>>55そのクラスってJavaScriptでいうクラスと同じものですか？
0057デフォルトの名無しさんNGNG
>>53
何で、VBでポリモフィズムの理解が居るの?
そう述べれるのなら、interfaceのimplがVBでできることを知ってるんじゃ
もっとも、全てのメソッドをimplしなきゃいけないけど
0058デフォルトの名無しさんNGNG
>>57
>そう述べれるのなら、interfaceのimplがVBでできることを知ってるんじゃ
>もっとも、全てのメソッドをimplしなきゃいけないけど
何が言いたいのかわからん。常識だろ。
0059デフォルトの名無しさんNGNG
って言うか、クソスレですなー
0060デフォルトの名無しさんNGNG
そんな事より１よ、ちょいと聞いてくれよ。スレとあんま関係ないけどさ。
昨日、近所のム板行ったんです。ム板。
そしたらなんか見慣れないスレッドがいっぱいでわけわかんないんです。
で、よく見たらなんか「OOの概念教えれ」とかいうスレが上がってるんです。
もうね、アホかと。馬鹿かと。
お前らな、OO如きで普段来てないム板に来てんじゃねーよ、ボケが。
OOだよ、OO。
なんか親子連れとかもいるし。一家４人でム板か。おめでてーな。
よーしパパデザパタ説明しちゃうぞー、とか言ってるの。もう見てらんない。
お前らな、Squeakやるからそのスレ下げろと。
ム板ってのはな、もっと殺伐としてるべきなんだよ。
OOアンチな奴といつ喧嘩が始まってもおかしくない、
刺すか刺されるか、そんな雰囲気がいいんじゃねーか。女子供は、すっこんでろ。
で、やっと目的のスレ見つけたかと思ったら、隣の奴が、継承、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、継承なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、継承、だ。
お前は本当に継承を使いたいのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、継承って言いたいだけちゃうんかと。
ム板通の俺から言わせてもらえば今、ム板通の間での最新流行はやっぱり、
モジュール化、これだね。
インターフェイスプログラミングモジュール化多態。これが通の頼み方。
モジュール化ってのはコードの影響範囲を局所化する。そん代わりモジュール単位が多め。これ。
で、それにインターフェイスプログラミング多態。これ最強。
しかしこれを頼むと次からスクリプト屋にマークされるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、Cでメモリ配置の勉強でもしてなさいってこった。
0061デフォルトの名無しさんNGNG
hage
0062デフォルトの名無しさんNGNG
OOPをはじめて理解した夜は興奮して寝つけなかった。

そんな俺も最近よく昔のことを思い出す。

小４くらいのとき、マンコが穴だなんて思いもしなかった。

が、年の離れた兄貴のいるＴは
「ヤッターマンコーヒーライター」
などという言葉を知っているいわば勇者的存在であった。

で、穴があることを知った俺たちだが、どうしてもそれが信じられない。
で、むしろ逆にガキであることを利用して調べようと思った。

ターゲットは音楽の教師である。美人だった。今にして思えば２０歳くらいだったのではないだろうか。短大出てすぐだったように思う。

実行はいたって単純。ガキ特有のカンチョーというあれである。
あれを前に突き刺すというのだ。
ガキなら許されるであろうという勝手な発想だが、たしかにマンコすら知らない奴がほとんどだったからナイスな判断だったろう。

で、実行はＴだった。
Ｔはなんの躊躇もなくやった。
思い切り。

思い切ってやっちゃいかんだろ、と思った。なぜにおまえはフルパワーなのだ、と。

音楽教師は泣いた。２０歳前後という年齢を考えればギャグでもきつい。ガキからすれば大人だったのだが、今思うと娘だ。
むしろ、処女だった可能性すらある。すまん先生。

が、Ｔも泣いていた。
両手人差し指骨折だった。第２関節より下で折れていた。
もろに刺さったんだと感心した。やはり勇者だ。
しかも、救急隊員に、マンコに指が刺さって折れましたと泣きながら事情を説明していた。
あの姿も相当かっこよかった。
0063デフォルトの名無しさんNGNG
(´-`).｡ｏＯ(何で毒電波を撒き散らす奴らって、
皆そろいもそろって文末に句点を打たないんだろう？）
0064デフォルトの名無しさんNGNG
>>60
>これが通の頼み方。
何に頼むんだ？
書き直しを命ずる。
0065デフォルトの名無しさんNGNG
>>63
(´-`).｡ｏＯ(お前のことだろ)。
0066　NGNG
程度の低いヲタと馬鹿の集うスレになりましたね。
0067デフォルトの名無しさんNGNG
なんでもいいから納期は守れ！
0068真35NGNG
やっぱこのキャラは無理があるのでやめた

「クラスとインスタンスの区別は？」
説明が面倒だったから省いただけ

「何でカプセル化だけを特別扱いしてるのか？」
教える順番の問題だよ。
これが理解できん奴が本を書くからワケワカになるんだよ
実際問題として、初心者に継承や多態性を教えても意味がないだろ。



0069デフォルトの名無しさんNGNG
なんとなくわかった気になって眠りに就きたいものだが
0070デフォルトの名無しさんNGNG
最近、ビットマップを一個メンバ変数に読み込んだ後、メンバ関数でxビットビットマップに変換するのがあると
便利かなー、と、考えてる。（xは色数を示すあれの代わり。）
ぜんぜん関連性も何も無いけど・・・。
0071デフォルトの名無しさんNGNG
>説明が面倒だったから省いただけ
説明が面倒なら最初から説明すんな。
言葉足らずなOOの説明ほど有害なものはない。
0072デフォルトの名無しさんNGNG
憂鬱読め。それでOOの入口ぐらいに入れる
0073　NGNG
ＯＯがどうのこうの言ってる連中は洗脳されて言ってるだけです。
本当は中身などないので説明できないのです。
思考操作されているのでそれに気付かないだけです。
ＯＯのことは忘れてください。
0074真35NGNG
「クラスの利用と設計って何や？」
これは例えば、「GUI部品を継承して利用」みたいな解説で
利用と設計がごっちゃになるんだよ
経験者には当然の違いだとしても初心者は混乱するんだよ
初心者の気持ちが分からん奴が本を書くなって。


「具体的思考と抽象的思考って何や？」
これはオレのオリジナルな考えなんだけど
こういう風に解説すれば一番分かりやすいんだよ
抽象的な理論を具体的な処理で言い換えれば、てことだよ
これがないから初心者は分からなくなるんだよ
既存の入門書の著者は説明が下手糞すぎる。



初心者がオブジェクト指向が理解できない一番の理由は書籍の説明の下手さにあるんだよ
今日はキャラ作っておれなりの説明を試みたんだが・・・
0075デフォルトの名無しさんNGNG
カプセル化ってOOじゃないライブラリでもできるじゃん、といってみるテスト。
0076デフォルトの名無しさんNGNG
>>35 君は偉い。
いいか、よく聞け。オブジェクト指向で重要なのはずばり

「カプセル化」

だ。
ほかの事はとりあえず忘れてよし。
0077デフォルトの名無しさんNGNG
モロボシダンはOOですか？
0078　NGNG
ファイル分けカプセル化が最高。
0079　NGNG
>>77
ダンはちがうだろ。「ウィンダム」となんだっけ？
0080デフォルトの名無しさんNGNG
ミクラスとアギラだ >>カプセル怪獣
0081デフォルトの名無しさんNGNG
>>76
それは抽象データ型だって。OO は、その先の話。
008232NGNG
>>35
＞（と考えてもいいの。これに文句を言う奴は小学生に
＞「自然数とは・・・」と語り出す数学オタと変わらない）
ごもっともです。
でも問題なのは、この程度の理解で 「俺は OO を理解したが、従来の手法より劣っているな」とか言う人がいるのが問題なので、それがスタートラインについたにすぎない事をはじめから教えてあげなければいけないと思うです。

>> 37, 45
今はいい入門本がありますよん。といってもたしかにドリブルくらいはできないと意味なしですが、GoF本読んで理解しろ！という意味ではないですので。
0083デフォルトの名無しさんNGNG
いいや、カプセル化は抽象データ型だけじゃない。
0084デフォルトの名無しさんNGNG
>>76
カプセル化はこの際「どうでもいい」だろう。

オブジェクト指向は戦場では必要無し　その２
http://pc.2ch.net/test/read.cgi/tech/1013266554/l50

の、Point 論争を読むべし(300番くらい)。たかがPointにgetter, setterを
付けるのを「オブジェクト指向」だと思われたんじゃ迷惑だ。

OOを勉強するなら「インスタンス」を理解することが最優先。
マルチインスタンスがわかってこそ、OOのありがたみがわかる。
0085デフォルトの名無しさんNGNG
またぞろ変なのが現れたな。
最優先もなにも一通りやらないと意味ないだろ。
0086デフォルトの名無しさんNGNG
オブジェクト指向なんてわけわからん名前じゃなくて、
カプセル化指向って名前にしとけばよかったのに。
0087デフォルトの名無しさんNGNG
ゴラァ！貴様ら！

岩波講座ソフトウェア科学17「モデルと表現」
読んでみたらいかがでしょう。オブジェクト指向に関わる基本概念が
非常に良く理解できると思うのですが。
残念なのは、絶版になってしまったこと。（古本屋で見つければ）
0088デフォルトの名無しさんNGNG
また新語か…＜マルチインスタンス
0089デフォルトの名無しさんNGNG
>>84
極端な例を出して煙にまく奴
0090デフォルトの名無しさんNGNG
>>88

へ?

http://www.google.co.jp/search?q=%83%7D%83%8B%83%60%83C%83%93%83X%83%5E%83%93%83X&hl=ja&lr=
http://www.google.co.jp/search?q=multi+instance&hl=ja&lr=
009182NGNG
>>84
その Point 論争で、技術的レベルの差で負けを認めた者だが…。
やっぱりアクセッサメソッドは付けるべきだ！とこのスレでも言って不評を買ってみるテスト。
0092デフォルトの名無しさんNGNG
>>90
で、OOとの関係は？
0093デフォルトの名無しさんNGNG
フォームに「閉じる」ボタンがあるとするだろ？
で、「閉じる」ボタンのイベントプロシージャにいろいろ処理が書いてあるわけだ。

フォームが100個あったら、それぞれに「閉じる」ボタンを張りつけて、
イベントプロシージャにコードを書いて・・・

こんなことやってたら面倒だろ？

それが、フォームを継承してやれば、継承元フォームの「閉じる」ボタンに
処理を書くだけで、継承先では不要になるんだよ。

えらい楽だと思わないか？
0094デフォルトの名無しさんNGNG
まあ>>84は知識にすごい偏りがあるってことに自分で気がついていない
みたいだから、そんなにいじめないであげようよ。
0095デフォルトの名無しさんNGNG
>>44
厨房の頃、全てのゲームを抽象化したゲーム用
アプリケーションフレームワークを
思いついた時とても感動した。

application.init;
repeat
　application.game.init;
　application.game.run;
　application.game.done;
until not application.game.continue;
application.done;
0096デフォルトの名無しさんNGNG
OO嫌いな奴なら、「サブルーチン呼べばいいじゃん」と反論できてしまう。
0097デフォルトの名無しさんNGNG
>>1
悪いこと言わないからRubyをやれ、
Rubyこそ真のOOPLだ！！
0098デフォルトの名無しさんNGNG
９７が召喚呪文を唱えている気がする。
0099Seisei_YamaguchiNGNG
しかしオヤっさん , OO知らねえ奴らに OO用語で説明しても ...
0100召還師NGNG
>>84
そのスレで煽っておきながら、1日ほっといたら
実はすごいのを召喚してしまっていたので
無視した逃げてきた者です。

しかし、なにより鬱なのが、>>98のResを見て
summonsという意味の日本語が召喚で
僕の使ってた召還はrecallの意味だったことです。
真性に間違ってました。

…しかしrecallでも、ある意味、あってるかも。
0101デフォルトの名無しさんNGNG
OOの話をするときに「カプセル化」に重点を置くと、>>78 のように、
「ファイル分けと一緒じゃん」と思い込む勘違い君が出てくる。
確かに、ファイル分けて、Cならstatic指定すれば「カプセル化」らしき
ものは実現できるんだが。

でも、それはOOじゃないでしょ。なぜならどこにも「オブジェクト」が
いないから。


0102デフォルトの名無しさんNGNG
>>101
その違いが、[マルチインスタンス]って奴なの?
0103デフォルトの名無しさんNGNG
>>102
ていうかOOでいうマルチインスタンスって何さ？
0104デフォルトの名無しさんNGNG
インスタンスの説明をしてみてもいいですか？

まず実行ファイルがあります。
メモリ内は空です。
インスタンスを作るというのは、
実行ファイルがメモリ内にメモリビットを構築した
ときの構築物をいうのです。か？






0105デフォルトの名無しさんNGNG
日本語の乱れについては敢えて
言及しないでクサーい
0106デフォルトの名無しさんNGNG
>>104
実装側からみた側面としては間違ってはいない。
「ポインタとはメモリアドレスの事である」という説明と同程度には合っている。
0107デフォルトの名無しさんNGNG
>>106
なんとなくしっくり来る分析だな。
0108デフォルトの名無しさんNGNG
もうどうでもインスタンス
0109void 1;NGNG
スレ立てっぱなしじゃ悪いので、しろうとのオイラ心に響いた言葉を挙げておきます。
もちろん正否や優劣にかかわる評価ではありません。

>>11
>性質を付加して対象を作り上げる。
属性の束がオブジェクトであるって言われればちょっと理解が進んだ気がする。

>>30
>そういうモデル化をプログラミングでも行うって言うムーブメントだな。
文化的ムーブメントはオイラの統計では３～４年で終わるんだよね。
娘｡も終わりかけてるし

>>55
>このような抽象的問いを実際の具体的なクラスの構造に落とし込む過程こそが
>「オブジェクト指向」なのです
何が人間クラスや国家クラスを保証しているか知らなくても、
人間や国家を知っているし、常に利用したり信奉したりしてるからね。
案外ヒトの考え方ってobject-orientedなんですね。
object-basedじゃないとこがミソかな。

>>97
>Rubyこそ真のOOPLだ！！
古典的にして力強いアド。やってみようかって気にいっしゅんなりました。
でもまずJavaScriptを
0110デフォルトの名無しさんNGNG
>>1
前向きで良い！
0111110NGNG
>>1
>でもまずJavaScriptを
どうしても JavaScriptでＯＯしたいなら
http://member.nifty.ne.jp/masarl/article/js-oop.html
0112101NGNG
ええと、これはmultiple instanceか (^^;

http://www.parashift.com/c++-faq-lite/classes-and-objects.html#[7.5]

In C, encapsulation was accomplished by making things static
in a compilation unit or module. This prevented another module
from accessing the static stuff. (By the way, that use is now
deprecated: don't do that in C++.)

Unfortunately this approach doesn't support multiple instances
of the data, since there is no direct support for making multiple
instances of a module's static data. If multiple instances were
needed in C, programmers typically used a struct. But unfortunately
C structs don't support encapsulation. This exacerbates the tradeoff
between safety (information hiding) and usability (multiple instances).

これだと一応カプセル化にも重点を置いてるけど、JavaにしろPythonにしろ、
デフォルトのアクセス制限を緩くしている。

カプセル化が重要じゃないとは言わないが、少なくとも真っ先に説明することじゃ
ないと思うんだけどなあ。
0113デフォルトの名無しさんNGNG
>>109
JavaScriptは関数型の言語だからやめとけ。
Javaとは別物だぞ。
0114デフォルトの名無しさんNGNG
>>113
ﾊｧ?
0115デフォルトの名無しさんNGNG
>>112
つまり、デフォルトでインスタンス変数のアクセス制限を厳しくしているRubyは
逝ってよしということですか？
0116110NGNG
>>26
>あと，Objectオブジェクトを『物』と訳している本とかあるけど，正しい？
>私は『目的』じゃないかと思うんですけど……
>どう考えてもOOPの概念をわかりづらくしている諸悪の根源のような
>気がする……

『目的』よりはマシ。
0117デフォルトの名無しさんNGNG
結論：

Denis.M.Richeは俺のオナペット。
Kernihgnは俺の妹。
sttrustropは俺の愛人。
松本はチンコ。
0118デフォルトの名無しさんNGNG
まつもとで、すとらうすとらっぷをつつくんですか？いいなあ
0119　NGNG
ともだマツモト
0120デフォルトの名無しさんNGNG
>>115
javaは知らんがpythonは手抜きでインスタンス変数がpublic相当になっている
だけだと思われ。
0121デフォルトの名無しさんNGNG
>>112
カプセル化 == 隠蔽ってわけじゃないよね。
別に必要に応じて透明なカプセルだっていい。

カプセル化は中身を外からいじるのを禁止するためのものではなく
中身がどうなっているか外から気にしなくてもよくするためのものでしょう。
0122デフォルトの名無しさんNGNG
>>121
>中身がどうなっているか外から気にしなくてもよくするためのものでしょう。

気にしないためには見えてはいけない。
透明だったり、半透明だったら気になりませんか？
すけすけですよ？
0123　NGNG
わざわざスカートの下から覗くような真似をしない限り見えませんが？
0124　NGNG
privateにうるさい奴は継承馬鹿かアフォ。
0125デフォルトの名無しさんNGNG
作った人の気持ちを考えてみると・・・

新しくプログラム言語（の理念）を作るというということは、
よほど実現したい機能があったと思われます。
それが何かというと、おそらく

ある実行されている（メモリにロードされている）プログラムが、
他のプログラムを起動させたり、協調したりすることだと思います。

だから、オブジェクト指向というのは、言語記述の形態（継承とかカプセル化とか）に関することよりも、
コンパイル後つまりバイナリ化（機械語化）された段階の形態。

つまりメモリ展開とか共有とかの問題じゃないかなと思っています。

どうでしょうか？>>1
0126デフォルトの名無しさんNGNG
class _ore{
　Super_AV ippon;
protected:
　H_hon issatu;
public:
　Syouroppoo fake;
};
0127デフォルトの名無しさんNGNG
>>125視野が拡がるような、迷いも深まったような････
JavaScriptのDateクラスをモデルに考えて、便利だなと納得しかけてたとこなんで。

>つまりメモリ展開とか共有とかの問題
分かりませんが、DLLとか想像すればいいのでしょうか？
0128デフォルトの名無しさんNGNG
>>125
それはコンポーネント指向。オブジェクト指向とは直接の関係がない。
0129デフォルトの名無しさんNGNG
>>123
コード補完時に思いっきり見えますが？
0130110NGNG
>>128
同意。
0131デフォルトの名無しさんNGNG
typedef struct myclass_t{
　int value;

　struct{
　　void *buf;
　} private;
} myclass_t;
0132デフォルトの名無しさんNGNG
age
0133デフォルトの名無しさんNGNG
カプセル化と多態。これ最強。
0134デフォルトの名無しさんNGNG
131はアホ
0135デフォルトの名無しさんNGNG
どうも漏れは従来の関数型のプログラミングスタイルから抜け出すことができない。
最近考えるのだが優秀な指導者（グル）に師事するのがオブジェクト指向プログラミングを理解する早道なのではないかと思う。
メールで添削教室とかやってくれないかな。
0136高校生NGNG
OOが分からんのなら、まず、データ構造（List,Hash,Tree）の
クラスライブラリを書いてみることを勧める。そして、それらを、
プログラムの中で使うことによってカプセル化や再利用性の重要
性を理解することであろう。
0137デフォルトの名無しさんNGNG
>>135
残念ながら OO のグルに心当たりはないけど…。
みんな GURU に師事しなくても OO を理解してるんだから、それ以外の方法もあるはずです。

もう OO についてはいろいろ勉強したのにも関わらず従来のスタイルから抜け出せませんか？
もしそうならばポイントを見落としているだけかも知れません。
そうではないならば、もっと勉強してください。絶対無駄にはなりません。

今まで OO に関してどんな事を勉強しました？
あと、今までの知識も絶対無駄にはならないです。
なかなか今までのやり方を抜け出せないのは、既成の手法をよく理解しているからだと思います。頑張ってください。
0138デフォルトの名無しさんNGNG
おれだったら、誰だかわからないやつに、>>137みたいな事言われたら、ヤレヤレ…って思うな。
ナマイキな厨房だったら、このくらい書けるしな。
0139デフォルトの名無しさんNGNG
激しくガイシュツではあるが
http://www.shoeisha.com/book/Detail.asp?bid=740
を読んでみるのがいいんでないかとオモタ。

俺がいっちゃん最初に読んだＯＯ本がこれだたのは
ひじょーにﾗｷｰと思ってまする。

この他にも、ＯＯ本何冊か読んでみたけど
俺的に「これじゃワカラネーヨ」というものばっかだたネ。

0140真性信者137(ナマイキな厨房)NGNG
>>138
こっちも誰だかわからないやつに教えてあげてるのです。
自分も幸せになれた物だから、人も幸せにしてあげたいのです。
まぁ、小さな親切大きなお世話かも知れませんがね、
変にすれて人の親切を正直に受け止められない人間は悲しいですよね。
0141デフォルトの名無しさんNGNG
>>137は結局、何も知らないけど、エラそうな事ならいくらでも言えるじじいという結論ですね。
0142135NGNG
>>140
135です。おかげで少し気が楽になりました。
なんかオブジェクト指向プログラミングなんか簡単だよ、
出来ないのはお前がアフォのせいだｺﾞﾙｧ！（妄想）
という声があちらこちらから聞こえていたので少しあせっていたのです。

とりあえず、
>>41,55のやり方でがんばってみるよ。
正直、早くワシも幸せになりたぃ

そんでは、さんきゅ
0143デフォルトの名無しさんNGNG
>>138 >>141
同じ事を言っても偉い人が言ったら納得してそうでない人なら納得しなさそうだな。
権力に弱そう。自分の考えをもっていなそう。
誰が言ったかじゃなくてどういうことを言っているかを考えればいいのに。
0144デフォルトの名無しさんNGNG
>>143
具体的な事何も言わないでなぐさめるだけなら、だれでも出来るってこった。
0145デフォルトの名無しさんNGNG
>>137
はやくおしえてくんろ。
0146デフォルトの名無しさんNGNG
継承とか、カプセル化とかの機能面の利点は感じるが、
オブジェクト指向そのものの利点をあんまり感じないんだが、
誰かいい例をあげてくれんか？
0147デフォルトの名無しさんNGNG
継承とか、カプセル化とか　を、　オブジェクト指向そのものの利点
と思ったらどう？
0148デフォルトの名無しさんNGNG
オブジェクト指向そのものは・・・沢山ある手法の一つ程度に考えたらいいんじゃないの？
0149デフォルトの名無しさんNGNG
>>146
デザインパターンとか見ると、何か気がつくところがあるかも。
0150デフォルトの名無しさんNGNG
カプセル化とか「オブジェクトは自分自身について知っている
とよい」的なOOの考え方って、良い設計を行う妨げになってるん
じゃないかと思うときがある。

例えばオブジェクトの比較なんかはC++でもjavaでも、比較方法は
比較対象となるオブジェクトのメソッドとして実装することが
言語仕様で決められてるわけだけど、対象物の比較なんてのは
第三者が行うことだし文脈によって方法も変わってくるから、比較
対象であるところのオブジェクトが定義するべきじゃない。つまり
実現方法が間違ってるんじゃないかと思うのよ。

で、何でこうゆう設計になってしまったのかなーと考えてみると、
冒頭に書いたようなことが原因ではないかと思うわけ。同じような
問題には、オブジェクトの文字列化やメモリ割り当ての方法なんかも
ある。

つーわけで、少なくとも現在のOOには改善の余地があると思うし、
このような問題がOOに解決できないものなら「OOは捨て」てのもアリ
かとも思うようになってきたんだけど、他の人の意見も聞いてみたく
なったんで何か意見くだちい。
0151デフォルトの名無しさんNGNG
モジュールの概念とデータ構造について勉強しましょう。
この二つを学ばずにＯＯに手を出すと、まず終わります。
0152デフォルトの名無しさんNGNG
>>150
比較を第3者(オブジェクトの外部)から行うとカプセル
化を壊すと思うのだけど。壊さないためにはオブジェクト
定義と一緒のモジュールの中に入れたい。それで言語概念
を少なく保つにはメソッドにするのが簡単。文脈によって
違うとすれば、その文脈を自動判別させるより、メソッド名
なりで区別する方が言語概念を少なく保てる。代替案として
どのような文脈判別メカニズムを提案されますか？
0153デフォルトの名無しさんNGNG
>>150
もうちょっと問題を絞ったほうが議論しやすいのでは。

主張:
オブジェクトの比較は、比較対象であるところのオブジェクトで定義すべきでない。
なぜならば、比較を行うのは第三者だし、文脈によって方法が変わってくるから。
0154デフォルトの名無しさんNGNG
>>150
問題が解決できないものを捨てたら、何も残りません。
代替案が無い以上最善の方法を使うしかないと思うが。
0155デフォルトの名無しさんNGNG
この人に言わせると「私の知る限りでは日本でオブジェクト指向を
理解している人には3人くらいしかいない」そうだ。

http://village.infoweb.ne.jp/~fwgf2942/
0156150NGNG
>>152
javaでもC++(STL)でもComparatorつうのがあってカスタムな比較を
したいときには一応指定できるようになってる。オレが思うに、
どちらの言語でもこのComparatorを唯一の標準にするべきだった。

で、おっしゃるとおり、比較対象となるオブジェクトに外部から
アクセスすることはOOの急所の一つであるカプセル化を壊すことに
なってしまう。オレは第三者が比較を行うのが自然な設計であると
考えてるから、現在のOOは良い設計を行う妨げになってるのでは
ないかと思うわけ。

代替案としては、明示的に宣言した場合にはオブジェクトのprivate
な部分にアクセスすることを許可するような仕組みが考えられる。
こうゆう仕組みをサポートする言語があるのかどうかは知らんけど。
0157　NGNG
どういうときにprivateな部分にアクセスしたいわけ？
0158150NGNG
>>153
まあ、その通りなんだけど、設計自体を問題視してるのではなくて、
そのような設計をさせてしまうOOという手法のあり方を問題にしてる
のよ。

オブジェクトの比較云々はその具体例だと思ってちょ
0159WILLNGNG
あんま関係ないかもしれないけど･･･。

>> 146さんと150さん

オブジェクト指向自体のってーのが良くわからないんだが、
オグジェクト指向の利点てのは
オブジェクト指向設計が徹底されると、複数のプログラムからできてるシステムでも

　「どのプログラムもある種類のデータには同じアクセスをしている」

ちゅ-ことを保証できることにあるとおもうんだわ。

例えば、

「 期間の開始日と終了日には常に 開始日 ≦ 終了日 の関係が成り立たなければならない」

っちゅ-事の管理を構造体と関数でやろうとすると、
ファイルとかデータ-ベースとか引数から期間のデータをもらう度に、
開始日と終了日のチェックをする関数を呼び出す羽目になると思うんだわ。

でも、期間をオブジェクトにしてそのオブジェクトの
開始日と終了日に値をセットするメソッドでチェックするようにして置けば
一々、期間読み込み → チェック関数呼び出し をしなくても良くなるわけさ。




0160デフォルトの名無しさんNGNG
>>155
そりゃ大変だ。外国に勝てないぜ。

つーか彼が知っている日本人は何人なのか気になる。
0161WILLNGNG
>>158

あ～、なるほど･･･。
もしかして、下手な設計者がオブジェクト指向もどきをしようとすると
公開されなきゃならないはずのデータまで隠蔽されてしまって、
痒いところに手が届かないクラス乃至オブジェクトができるといってます?

そーれはそのとおりかもしれない。
0162デフォルトの名無しさんNGNG
>公開されなきゃならないはずのデータまで隠蔽

これはまだいい方。
「隠蔽しなきゃならないはずのデータまで公開」されちまった日にゃぁ...
0163デフォルトの名無しさんNGNG
少なくともWILL君は「３人」の中には入ってないみたいだねぇ。
0164150NGNG
説明が下手でスマン。javaとオブジェクトの比較の例で捕捉してみる。

- 本来オブジェクトの比較は第三者(Comparatorのような)が行うべきだ。
　理由は、前に書いたので分かって貰えると思う。

- ところがjava言語では、Objectクラスに比較メソッド equals(Object)
　が定義されていて、任意のオブジェクトの比較にこのメソッドを使う
　のが標準的、ということになってる。これはおかしい。

- じゃ、なんでこうしてるのか？と考えてみると、OOの考え方が悪い方向
　に影響を与えてるのではないかと推測できる。つまり、

1 オブジェクトの内部データに確実にアクセスできるのはそのオブジェクト
　自身だけである、というカプセル化の考え方があるから。したがって、
　第三者であるところのComparatorは潜在的に、オブジェクトを比較する
　のに十分なデータにアクセスできるとは限らない。

2 「オブジェクトは自分自身について知っているとよい」という考え方が
　あるから。

こんな感じ。
0165WILLNGNG
>>163

うむ。
おいらはリンク先のやつの知人でもないし、
そんなに有名でもないからね。（ｗ
0166デフォルトの名無しさんNGNG
oriented であって one とか only じゃないんだから

そんな必死になるようなもんじゃないと思う。
　逆にOOP言語を効率的に使いこなす技術程度でいいんじゃないかと
0167150NGNG
>>166
どうも。確かに固執してるかもしれない。かれこれ1ヶ月も気になってる(w

ただ、この問題に気づいたのは過去にjavaでコレクションやってて躓いた
ときだったし、今日もC++でplacement newやってて同じ問題にぶち当たった。
なんつうか、不必要に遠回りさせられてるような気がして、もっと柔軟な
言語なりパラダイムなりが必要なのではないかと思うのよ。
0168WILLNGNG
>>164
うーん･･･。
つーか、equals()メソッドと150氏のおっしゃってる
Comparatorではどうも役割が違う気がするんだが･･･。

A.equals(B)

は、主体Aが渡されたオブジェクト"Bと自分自身とが等しいか?"
を判断しているのに対して、

C.compare(A , B)

では、主体Cが"AとBが等しいか?"を判断している
という差があるはず。
で、この二つの答えは必ずしも一致する必要がないし、
どちらが標準ってことも言えないとおいらは考える。

ただ、後者型の比較の仕方はとりあえず
ライブラリの実装としてはあまり適切じゃないんじゃないかな?

150氏がOOの考えが悪い方向に影響を与えていると感じているのは、
何でもかんでもカプセル化しなきゃならないっちゅーような考え方
なんじゃないかなぁ。

もし、>>163の1にあるように第3者であるComparatorが潜在的に
比較するのに必要な情報にアクセスできないのであるとすれば、
それは比較対照となるオブジェクトとComparatorのどちらかの
設計ミスである可能性が高いと考えられる。
可能性としては次の二つ。

1．比較対照となるオブジェクトさんが人に見せなきゃならないデータを見せてない。
(夏休みの宿題とか)
2．こんぺれーたさんはもうちょっと比較対照となるオブジェクトと
仲良くならなければならない。
「(赤の他人のてめぇがおいらの口座の暗証番号を盗み見るなよ。
(おいらの嫁さんなら教えるかも知らんがな～)」

と、言った感じ?

まぁ、どちらにしろ"わかりやすい設計"をするためのオブジェクト指向
なんであって、"正しいオブジェクト指向"するための設計をしていたんじゃ
本末転倒も良い所だと思う今日この頃。

･･･答えになってるかどうかはわからんけど。
0169デフォルトの名無しさんNGNG
>>150
まず、比較は第三者がすべきだという根拠を説明するところからはじめてみては?
0170デフォルトの名無しさんNGNG
>>169
ダブルディスパッチがしにくいとか？
0171デフォルトの名無しさんNGNG
150氏ではないし、理屈よりも感覚なんだが、

オブジェクトを中心に考えると、比較の実装は
"そのオブジェクトが別のオブジェクトと等しいかどうか調べる"
となるんだろうけど、二つが等しいかどうかどっちがどうとか考えず、
単純に比較できたほうがやりやすい、って思ってしまう。

けど、これはデータ中心で考えてるんだろうなぁ。
0172150NGNG
>>169
オブジェクトが提供する機能と、そのオブジェクトを比較する
機能は異なるもので、また異なると見なした方が便利だから、
って感じかな。

例えば文字列オブジェクトを例にとると、文字列の比較方法は
大文字・小文字を区別しないとか最初の何文字だけを比較するとか
千差万別に存在するわけだけど、どの方法で比較したいのかを
知っているのは文字列オブジェクトの使用者だけで、文字列
オブジェクト自身ではないでしょ。だから比較方法は文字列とは
切り離して第三者が行うべきだと思う。
0173169NGNG
たとえば150さんも>>172で
「文字列の比較方法は」
と言っている通り、
比較という概念には比較対象となる各オブジェクトに帰結するものが多い
と思うんだけど。

これを無理にComparatorという第三者に持っていってもいいけど、
そのComparatorは何でも知ってる神様的存在でなければいけない。
文字列比較、文字と数値の比較、整数と分数の比較、…
例えば整数と分数の比較はどうやって行うのか？
結局「分母と分子」という分数の構造と「通分」という分数の知識を
要求されるよね。
するとこのComparatorは分数の中身を知ってる超越的存在でなければならない。
0174デフォルトの名無しさんNGNG
>>172
オブジェクトが公開してないデータを用いて比較する場合は
どうすればいい？
結局は第三者がカプセル化を破る手段(friendとか)
が必要になる？うーん
って言ってる事が>>168と同じになってきた
0175150NGNG
>>168
A.equals(B)とC.compare(A, B)の意味的な違いは同意なんだけど、
どちらが標準として扱われているかと言えば、明らかに前者でしょ。
オレは後者を標準にするべき(つまるところ、AがBをどう思っていよう
が知ったことではない)だと考えているから、

> ライブラリの実装としてはあまり適切じゃないんじゃないかな?

には同意できん。もうちょっと詳しく教えて。

で、後半部分で指摘されてるような設計ミスは、Comparatorを使うと
往々にして起こり得そうなんだけど、>>156で提案してるのが、これを
カバーするための案なのよ。動的分類をサポートするならともかく、
そうでないOO言語では「私もあなたのお嫁さんになりたいのよ」も柔軟に
対応できたらいいなと。
0176　NGNG
単に設計の問題じゃねーのか？
0177150NGNG
>>173
別にComparatorが全てを知っている必要はないでしょ。
Comparatorは、比較するべきオブジェクトの種類を判別
できて、使用者が望む方法で比較できればそれでいい。
そしてこれはあらかじめ定義されてる必要性は全くなくて、
必要なときに使用者が定義してやればそれで済む。
0178デフォルトの名無しさんNGNG
オブジェクト指向ってワカッテル人が、ワカッテナイ人が使えるものをつくるためのもの？
0179169NGNG
>>177
つまり分数と整数の比較をしたい人はそれぞれ自分で
比較するための処理を書かないといけないわけ？
その手の「車輪の再発明」はバグの温床になりそうな…

それよりも例えばSmalltalkみたく全ての比較をメソッドで定義して
使用者がどの比較基準を使うか選んだほうがよくない？
0180150NGNG
>>179
まだ起きてたのか、オレもだけど(w
うーっとComparatorの使い方を説明すれば解って貰える思う。

ComparatorはSet(Smalltalkにもあったよね)のコンストラクタの引数に
与えたりして使う。使用者が意図するオブジェクトの比較方法をSetは
知らないので、知ってるComparatorをこちらで定義して与えてやる。
すると、Setは要素となるオブジェクトの比較方法を知らなくても、
boolを返すComparatorのcompare(Object, Object)メソッドという共通
インターフェイスを呼び出すだけでオブジェクトを比較できる、と
いうような具合。

文字列の比較で、通常は大文字・小文字を区別して比較が行われる
のを区別しないようにしたい場合には、使用者が定義するComparator
の比較メソッドは文字列クラスのEqualsIgnoreCase(String)を呼び出
すだけで終わる。
もちろん、EqualsIgnoreCaseに相当するメソッドがなかったら、自前の
奴を実装するわけだけど。

どのインターフェイスに統一するかの話。
0181169NGNG
ああ、何となくわかってきた。

例えばSmalltalkでソートする時には
SortedCollection withAll: aCollection sortBlock: [:less :more | less < more]
とかするけど、この[:less :more | less < more] は引数を2つ取る無名関数みたいなもの。
これを無名関数という汎用なものではなくて比較に特化したクラスにしたい
って話ね。

各種比較の実装は各クラスの責任で行なうけど、
もう1つ高い抽象化をしたい、って事ね。
それって別にオブジェクト指向が邪魔になってるわけでも
オブジェクト指向に反してるわけでもないような気がするけど。
0182150NGNG
そ。Smalltalkは静的な型チェックが入らなかったと思うんで、
無名関数のままでもいっこうに構わない。いろいろな比較メソッド
を要素となるクラスの側で定義するのも全然構わない。

問題なのは、そのような比較メソッドがなくてもう一段レベルの低い
ところまで行って自前のものを実装しようというときに、カプセル化
(アクセス制御)が邪魔して思うようにできない可能性があって、それが
javaやC++でComparatorを大々的に使用することの歯止めになってるん
じゃないか？てこと。>>164
0183デフォルトの名無しさんNGNG
結局、150がオブジェクト指向の表面しか理解していないだけなんじゃないの？
カプセル化を隠蔽と捉えているようじゃ駄目だよ。
0184デフォルトの名無しさんNGNG
150に限ったことではないが、いろんなＯＯＰＬで、同じ問題がどういうふうに
解決されてるか、もうすこし調べれ、って感じな。

それから、文字列比較の問題は、ビットパターンが同じかどうか比較
するのと、「同じ」っていうのを、あるクラスがどう定義してるかっていう
のがごっちゃになってるみたいだし、同じクラスのインスタンス同士の
比較と、違うクラスのインスタンスの比較も分けてないみたいだ。

「大文字と小文字を区別しない比較」なんて、文字列クラス以外のどこ
で定義しろというんだ？
どうしても「第３者が比較」したいならクラスメソッドでええやん。

それから、、、つっこみドコロ多いから以下略
0185150NGNG
>>183
それは、「カプセル化の恩恵は隠蔽の不利益を補って余りある
ものだから、目を瞑るべきだ」ってこと？

---
オブジェクトの比較について整理してみる。
比較は第三者が行うべきだというオレの意見は、これは統一的な
インターフェイスとしてA.equals(B)ではなくC.compare(A, B)を
採用するべきだ、ということを言ってるのよ。

前者の問題点は、比較方法を変えるためにAに手を入れなければ
ならないこと(それ以外にも手が無いわけじゃないけど、後者の
解決法に較べたらスマートじゃない。>>184氏の言うように、オレ
の知らない言語ではもっといい方法があるかもしれないけど)。
後者の場合は、使用者が意図する比較方法をその度に定義してやれば
いいのでこの問題を解決できる。オブジェクト比較のStrategy
パターンと言ってもいいかもしれない。
0186デフォルトの名無しさんNGNG
＞比較方法を変えるためにAに手を入れなければ
使用者の都合で「別の比較方法を追加」したい時にC.compare(A, B)っていう
選択もあるだろうが、A.equals(B)や A sameAs:B を否定する理由にはならん
だろう…
0187John ◆0z.4Is5E NGNG
>>150
>後者の解決法に較べたらスマートじゃない。
これおかしいと思うよ。
簡単に書ける＝スマートではない事は明らかだよね。
Comparatorなんて物を作ったときのデメリットは
オブジェクトが自分の挙動を知らない事になる。
これが意味するところは、クラス単位での管理が困難になる。
つまり、コードの保守という点でリスクを背負う事になる。

念のため聞いておくと、外部から見てリードオンリーなメンバを作る事って
何か問題があるかな？
問題なければ、あらゆる比較は可能だけどね。
0188デフォルトの名無しさんNGNG
>>164
>オブジェクトの内部データに確実にアクセスできるのはそのオブジェクト
>自身だけである、というカプセル化の考え方があるから。したがって、
>第三者であるところのComparatorは潜在的に、オブジェクトを比較する
>のに十分なデータにアクセスできるとは限らない。

オブジェクトを比較するのに十分なデータを読み出せないというのは
クラスの設計がおかしい。

クラスを利用する方が間違ってる場合もあるけど。
0189デフォルトの名無しさんNGNG
Johnがふつーな事書いてる…
0190デフォルトの名無しさんNGNG
>>189
はあ？>>187はツッコミ所満載だが、何か？
0191デフォルトの名無しさんNGNG
150の一知半解ぶりといい、粘着気質といい、見れば見るほど

■翻訳者が仕事するように駄目な奴をさらす■
http://pc.2ch.net/test/read.cgi/tech/1008165139/-100

の58にそっくりだな。
もしかして同一人物か？
0192150NGNG
>>187
Comparatorという別のクラスを作るのは、管理面でちょっとは
不利かもしれないけど、他の方法で同じことを実現するのは
難しいと思う。おかしいと言うのなら、これ以外の方法で実現
できる統一的なインターフェイスを提案してほしい。

後半部分に関しては、OO的な観点から言えば、公開する必要のない
内部情報をアクセス可能にするのは危険だ、ということになる。
個人的には、アクセスする側・公開する側の両者が、自分が何を
しているのかを理解しているなら構わないと思うけど。
0193150NGNG
>>191
違う。そのスレに書き込んだことはないよ。

あなたみたいな、きちんと理解した人がオレの間違いを
指摘してくれると嬉しい。ちょっくら遊んでかない？
0194189NGNG
>>190
ごめん、「Johnにしては」くらいで、大目に見てくれ。
0195John ◆0z.4Is5E NGNG
>これ以外の方法で実現,できる統一的なインターフェイスを提案してほしい。
equalとか
equalIn***とか(equal_in_***)

>内部情報をアクセス可能にするのは危険だ
だから、リードオンリーって書いたんだけど。
それともリードオンリーのメンバが存在するケースのデメリットがあるんですか？

>自分が何をしているのかを理解している
具体的に書いてくれないと、ちょっとよくわからないんだけど。
0196デフォルトの名無しさんNGNG
>>150は>>184を見て何も感じないんだろうか…
0197デフォルトの名無しさんNGNG
>>196=>>184
150呼んでるぞー
0198デフォルトの名無しさんNGNG
190 vs John
が見たいのは俺だけ？

190が登場したら、190とJohn以外の書き込みは禁止の方向で
0199150NGNG
>>195
>equalとかequalIn***とか(equal_in_***)
「統一」と言ってるんだから一つにしてくれよ。
例えば、あなたがハッシュテーブルをコーディングしていて、
出所のわからない二つのオブジェクトをハッシュテーブルの
使用者のために比較しなければならないときに、いったい
どうやってこの二つを比較するんだ？

>それともリードオンリーのメンバが存在するケースのデメリットがあるんですか？
>具体的に書いてくれないと、ちょっとよくわからないんだけど。
アクセスされる側のクラスをAと呼ぶことにすると、Aの公開インターフェイス
は将来に渡ってある程度互換性が保証されるんだろうけど、Aのリードオンリー
のメンバを含む内部実装は、保証されない。だから、Aがバージョンアップしたり、
Aを他の実装に切り替えたりしたときに、アクセスしてる側のオブジェクトが
動作しなくなるかもしれない。アクセスする側はそのリスクを承知した上で
アクセスしなくちゃいけない、ってこと。
0200184=196NGNG
放置されて、ちょっとくやしい。
0201デフォルトの名無しさんNGNG
150は神！
0202150NGNG
>>196 >>197
>>184氏の発言は、何というか、ビットパターンとか
クラスメソッドとか言ってて微妙にはずしてるような
気がするのよ。「もしかして何か重要なヒントが隠さ
れてるのか？」とも考えてみたんだけど、今のところ
理解できないのでレスできない(w
0203John ◆0z.4Is5E NGNG
>「統一」と言ってるんだから一つにしてくれよ。
そんなのどうやったって無理だけど。

>どうやってこの二つを比較するんだ？
HashObject#equalInHashValue()
みたいな感じかな。

>将来に渡ってある程度互換性が保証されるんだろうけど
そんなんだったら、Javaのライブラリーは将来使い物にならなくなるって
事なんだよね（ｗ
まあ、オブジェクト指向理解度８８％に認定かな。
0204デフォルトの名無しさんNGNG
（　ﾟдﾟ）ﾎﾟｶｰﾝ
0205デフォルトの名無しさんNGNG
なんだなんだ？マルチメソッドの話題か？
0206John ◆0z.4Is5E NGNG
ヒントって言うか、直球だと思うけど、
さらに分かりやすく書くと

>出所のわからない二つのオブジェクトをハッシュテーブルの
>使用者のために比較しなければならない
さらに、オブジェクトへのポインタの値が同じかどうか調べる必要もでてきました。
さあ、どうする？みたいな・・・・・
0207デフォルトの名無しさんNGNG
>205
いや、たまに出てくる俺的感覚の押し売り。
Johnが絡んでるんだから、おして知るべし。
0208デフォルトの名無しさんNGNG
(゜д゜)＜ついに馬脚をあらわたしったら
0209150NGNG
>>205
お、なんか面白そうね。勉強してみるよ、ありがと。
そういえば昨日「マルチディスパッチ」って言った人が
いたと思うけど、知らなかったんで無視した。スマン。
0210John ◆0z.4Is5E NGNG
無視？
それとも言ってる意味がわからなかったのかな。

前半は、第三者が比較しても比較の方法分だけメソッド名が必要。

後半は
継承がわかってないか、あるいは継承の使い方をわかっていないのどちらか。

>アクセスしてる側のオブジェクトが動作しなくなるかもしれない。
こんなケースはありえないと言うか、
「リードオンリー」って書くのは４回目くらいなんだけどね。
0211デフォルトの名無しさんNGNG
電波は無視、気違いは放置
0212John ◆0z.4Is5E NGNG
まあ、これでわかんないなら
説得は不可能って言うか、
分からない事に目をつぶるスタイルじゃ
何を言っても無駄な気がしてきたので、もうやめた。

ちなみにレイトバインディングくらいはわかってるんだよな？
0213デフォルトの名無しさんNGNG
#211.equal(150)?
#Yes!!
0214169NGNG
>>209
いや、マルチメソッドは共通した名前と意味を持つメソッドの実装を
引数の型に応じて複数用意する仕組み。あんまり直接的な関係はないと思う。
ただ、マルチメソッドの実装として、型を指定した引数の情報隠蔽を破る仕組みも
用意している場合があるという点では参考になるかもしれん。

俺的には、この議論はどっちかというとデザインパターン的な所にいくんじゃないか
と思うのだが、どうよ？
0215デフォルトの名無しさんNGNG
オブジェクトとオブジェクトの実装コードは別のもの、とか書いてみるテスト。
0216デフォルトの名無しさんNGNG
John君、煽るのも結構だが、
せめてvisibilityとstatic(dynamic) typingぐらい理解してからにしとけよ。
こっちが恥ずかしくなる。
0217John ◆0z.4Is5E NGNG
可視性ってアクセス修飾子とかの話？

typingって型の事言ってるのか？
静的型付言語とかの事？

だとしたら、ちょっとかわいそう。
がんばって勉強してくれ。
0218John ◆0z.4Is5E NGNG
216=150だったらかわいそうなので
アクセサメソッドを使えばリードオンリーなメンバは作れる。
って書くほど大げさじゃないけど。

equal(A , A)
equal(A , B)
B extends Aのケースを考えれば。

じゃ、おやすみ
0219デフォルトの名無しさんNGNG
さすがの>>150も、Johnを相手にするのは、意味が無い事を悟ったらしい。
0220デフォルトの名無しさんNGNG
a.equal(b)でもClassObj.equal(a,b)のどっちでもいいじゃん。
使い分ければ？
どっちかが絶対的に優れているわけではないし。
時と場合によるのでは？
0221デフォルトの名無しさんNGNG
>>220
>>150はClassObj.equal(a,b)が、
＞クラスメソッドとか言ってて微妙にはずしてるような気がするのよ。
だと>>202で言ってるんだよ。
0222150NGNG
マルチメソッドちょっと勉強した。引数で多態するような
感じであってるよね？ Visitorパターンと関連が深そう。

で、>>169氏の言う通り、直接関係があるわけではなさそう。
0223デフォルトの名無しさんNGNG
>>222

>>181や>>182で言ってることは Eiffel ならできると思う。
はっきりしたことは分からないれど。
0224訂正 223NGNG
>>181や>>182で言ってることは Eiffel ならできるかもしれない。
はっきりしたことは分からないけど。
0225デフォルトの名無しさんNGNG
>>224
Javaなら俺もprivate/protected変数に
public getXXX()をつけるけど
これで解決じゃない？
0226224NGNG
>>225
150はちがうことを言ってるような気がする。
0227デフォルトの名無しさんNGNG
ココ初めてきたが、お前等キモイなマジで。
気に障ったらすまん・・・が、しんで
0228デフォルトの名無しさんNGNG
なんか比較と等値の話が混ざっているような……

（等値の話だとすると）オブジェクトは自分自身について詳しいので，
自分と相手が等しいかどうかを判定するのはオブジェクトに任せちまって
いいんじゃない？わざわざ第３者を連れてくるのは，独立していない
オブジェクトをこしらえることになるのでスマートじゃない．

せいぜい>>202の言うとおりクラスメソッドでやるべきだねぇ．
0229228NGNG
ごめん．>>202じゃなくて>>184……
逝ってきます
0230228NGNG
ちょっと自己レス

これが等値じゃなくて比較の話になると150の逝っていることに意味が出てくる
オブジェクト同士を比較する方法は「オブジェクトのどの特性に注目するか」
によって複数存在するからねぇ．

「ドラッグカーとラリーカー，どっちが速い？」
そんなもん条件によって全然違う．

「Ｆ１と野球，どっちがすごい？」
……何を比較すりゃいいんだ？

こういうときは，150の言うとおり，プログラマが審判となるオブジェクト
をでっち上げて判定させる C.compare(A, B)の形式のほうが柔軟性が高い．

でも，いちいち作るのは面倒だから，オブジェクトA, Bの性質から比較される
「だろう」基準をあらかじめ用意して，自分自身で判断させるA.compare(B)の
方法もあっていいとおもう．

結論としては結局ケースバイケースでやれやっつうことに……
何回も出てきてるじゃん，この結論．




0231150NGNG
>>228
とりあえず、同値性判断や順序判断の操作を総称して「比較」
と呼んでる感じ。その辺はなんとなくで解ってちょ。

オブジェクトは自分自身について詳しいけど、bool equals(Object)
という単一のインターフェイスで判断できるのは、オブジェクトが
主観的に最も適切だと思っている方法でだけででしょ。
で、それがオブジェクトの使用者が意図している方法と一致するとは
限らない。だから、客観的な判断が出来て、使用者の意図を知っている
第三者を連れてこなきゃいけない場合がある。
そして、この第三者を連れてくる方法が今のところ最も汎用性の高い
やり方なんじゃないかと思うのよ。

で、まあこのように考えた場合、それはOO的観点からは、

>独立していない オブジェクトをこしらえることになるのでスマートじゃない

ことになってしまうので、OOに問題があるんじゃないか？
と言ってるのよ。>>164の2
0232仕様書無しさんNGNG
クラス開発者と利用者が別れている場合を想定してるわけだ。
0233デフォルトの名無しさんNGNG
>>231
話をわかりやすくすると、
例えばある人間が「同じ」と判断する基準があって、

　　if (ある人間.equal(a, b))

のequalの判定基準はa,bそれ自身では特定できないってこと？
0234224NGNG
>>231
Eiffelには Javaの Objectに相当するクラスに
オーバーライドできない
standard_equal (shallow_equal) と
deep_equal と
オーバーライドできる equal というメソッドがあるんだけどどう思う？
0235150NGNG
>>233
そうです。

>>234
standard_equalとdeep_equalは全てのオブジェクトに共通する比較
方法を定義してるんだよね。equalの方は、これが汎用インターフェイス
であるのなら、前述の理由で設計が悪いと思う。
0236デフォルトの名無しさんNGNG
そういうクラス横断的な考えは AOP を参照するといいと思う。
0237224NGNG
>>235
比較にはクロージャを使うべきだということですか？
0238デフォルトの名無しさんNGNG
>>237
それは>>181-182で既出です。
0239デフォルトの名無しさんNGNG
sort = a.sort{|a,b| a.hoge <=> b.hoge }
@sort = sort { $a.hoge <=> $b.hoge } @hogehoge;
sort := SortedCollection sortBlock: [:a :b| a >= b].

適切な getter があれば良いということか
0240150NGNG
>>236
うん、個人的にはアスペクト指向を拡大解釈してOOに組み込みたい感じ。
アスペクト指向はまだ勉強すら始めてないんでビクビクもんなんだけど、
副作用的な部分だけでなく本筋の部分もアスペクト指向的に織り込めたら
いいね(確証なし)。

>>237
重要なのはインターフェイスなので、実装方法はどうでもいいのでは？
0241169NGNG
>>239
150が欲っしてるのは比較方法を適宜選択できるようなインターフェイスでしょう。
あるCollectionではequal、別のCollectionではdeep_equal、
また別のCollectionではidentity_equal、さらに別のCollectionでは名前の比較とか。
SmalltalkではこれをBlockClosureでやりくりするけど、
これを静的型でやるにはどうする？って話で,、Comparatorが一番近いだろう、と。

その時に比較対象となるオブジェクトが十分なインターフェースを提供していない場合には
情報隠蔽が邪魔だというのが150の主張だと思うんだけど、
俺的には、それはその比較対象となるオブジェクトの設計の問題だろうと思う。
比較に限らず、常にその問題はあるわけで、そこで必要十分なインターフェースを
洗い出すのが設計ってもんだろうと思うのだが。
0242224NGNG
>>241
>その時に比較対象となるオブジェクトが十分なインターフェースを提供していない場合には
>情報隠蔽が邪魔だというのが150の主張だと思うんだけど、
>俺的には、それはその比較対象となるオブジェクトの設計の問題だろうと思う。

同意。
0243224NGNG
>>241
>これを静的型でやるにはどうする？って話で,、Comparatorが一番近いだろう、と。

Eiffel では比較用のメソッドを定義して
メソッドを引数として渡すと思う。
0244召還師NGNG
うまく説明しにくいが…
比較について、例えば
型A,B,C3で、比較方法も3つだと…

(1)比較方法を全部、被比較オブジェクトのメソッドとして持たせる場合
　　a.hikaku1(b)　<-　比較法１
　　a.hikaku2(c)　<-　比較法２
　　a.hikaku3(b)　<-　比較法３

(2)第三者の審判オブジェクトを作る場合
　　judge1.hikaku(a, b)　<-　比較法１
　　judge2.hikaku(b, c)　<-　比較法２
　　judge3.hikaku(a, c)　<-　比較法３

型が増える可能性が高い場合、(1)有利。
比較法が増える可能性が高い場合、(2)有利。

一般的に(という言い方をすると突っ込まれるがｗ)、
比較法の方が増える可能性が少ないので、
(1)の方がよく用いられる。

…ってだけじゃないの？ここでの議論って。
なんか、もっと根深いことを議論してるの？良く分からないが。
0245150NGNG
>>241
そこまで同意。設計に問題があるから云々っていうのは別にOOに固有
の問題でもないとも思う(ただ、情報隠蔽を前面に出してるので相対的
に問題になりやすいはず)。

で、問題が発生したときに、比較対象となるオブジェクトのソース
コードを変更できる立場にあるのであれば、修正すればそれで済む。

でも、そうでなくて修正することができない場合に、Comparator
を使う戦術は使えなくなってしまう。だから、Comparatorは戦術と
しては申し分ないのに、オプションという不当な扱いを受けてるの
ではないかと考えたわけ。
0246228NGNG
>>231
ふむふむ，「等値」じゃなくて「ある特徴が同じ」ぐらいの意味かな？
＃等価ってやつ？

確かにそれだったらオブジェクト自身にやらせるよりは判定オブジェクトを
でっち上げてそいつにやらせたほうがいいかも．
まあ，特徴ごとにA.equalSize(B)とかA.equalData(B)とかメソッドを作って
やってもいいような気もするけど，それはそれで（使う側も作る側も）
めんどくさそう．

>>241
同意．
隠蔽しているということは，その部分が変更される可能性があるということ
なので，その部分に依存するのはリスク高いね．ちゃんと契約された内容を
使うようにする必要があると思う．

0247169NGNG
>>243
なるほど。つまり、Eiffelでは
「比較が問題になるようなCollectionを＊利用する＊クラスでは
その比較自体がそのクラスである程度の重要度を持っているわけだから
その比較をメソッドとして提供するよう契約するだけの価値がある。」
という考え方なんでしょうか？
俺的にはEiffelのそういうマジメな所に好感を持っています。

Ｓｍａｌｌｔａｌｋでは「比較基準を作りたい？じゃ作ればぁ～」って感じかな(藁
ループなども全てBlockClosureで実装するから、
「ある処理」をBlockClosureとしてオブジェクト化する事には
何の抵抗もないんだよね。
0248デフォルトの名無しさんNGNG
>>150　の主張は
１、A.equal(B) では解決できない場合 C.compare(A,B) が必要だ。
２、だったら「比較」はすべて、 C.compare(A,B)　で統一すべきで、A.equal(B)無いほうがよい。

というふうにずっと見てるんだが。
この　２　が、場合によって適切なシンタックスを選べばいい、っていう意見と対立してるんだろ？

で、 C.compare(A,B) で統一できないのは、ＯＯＰＬの欠点だとまで言ってるようだ。
0249228NGNG
>>244
確かに比較についてはそれでおしまいだね．
そういやSTLの連想コンテナは両方の方法をやってるや．
＃デフォルトはOperator<を使って，ユーザー定義の関数（オブジェクト）が
＃指定された場合はそちらを利用して「等値」を判定
＃この辺の話は"Effective STL"が詳しくてよかったなぁ

実はこの先にもう一つ話があって，
　>>164
　あるオブジェクトが他のオブジェクトの詳細を必要に応じて知ることが
　できないのはOOの悪い癖じゃないの？
というのが150の意見．
0250150NGNG
本題に入ったところで止まってしまってはもったいないので、
今までの話をまとめてOOの弱点を挙げてみる。こんな感じだろうか

- 機能そのものよりも、その機能プラスその機能を自己完結させる
　ために必要なものまでを含めてモジュールとする傾向が強い。

- カプセル化を前面に押し出しておきながら、それを柔軟に扱うの
　に必要な機能を提供していない(これは言語依存かも)。
0251デフォルトの名無しさんNGNG
具体例をあげてほしいプリーズ
0252169NGNG
>>250
> - 機能そのものよりも、その機能プラスその機能を自己完結させる
> 　ために必要なものまでを含めてモジュールとする傾向が強い。

で、何が困るんでしょ？

> - カプセル化を前面に押し出しておきながら、それを柔軟に扱うの
> 　に必要な機能を提供していない(これは言語依存かも)。

カプセル化がオブジェクト単位でしかできないという事？
それでも大抵のオブジェクト指向言語は
オブジェクトとして扱う粒度をユーザー(プログラマ)の判断に委ねているし、
そうして生み出されたオブジェクトを使ってより粒度の粗いオブジェクトを
合成するための仕組みを提供していると思いますが。

オブジェクトの粒度に言語(環境)によって強い制約が課せられているOOといえば
COMがとりあえず思い当たる例なんだけど、そういう話をしてるんじゃないよね？
0253169NGNG
粒度の粗いオブジェクトを合成するだけでなく、
リファクタリングでオブジェクトの粒度を細かくすることもできる。

っつーか、この辺の柔軟性がオブジェクト指向の利点の1つだと思ってたのだが。
0254150NGNG
>>252
二番目の方なんだけど、用語が間違ってたかもしれんので
訂正します、スマン。

- 情報隠蔽を前面に押し出しておきながら、それを柔軟に扱うの
　に必要な機能を提供していない(これは言語依存かも)。

これはさっきの、Comparatorがいまいち好まれない理由はなぜかを
考えたときの(推測から出た)結論を直接うけてる。
0255召還師NGNG
>>249
「癖」のことを言ってるのか…。
「癖」って言われると、難しいものがあるなｗ。
でも、詳細を知ることが出来ないのは、
単にインターフェースが足りてないだけだと思うんだけど…。

そもそも情報隠蔽が嫌いな人って、"生データ"好きな人が多いけど、
往々にして"生データ"そのものより、加工されたデータの方が情報が多い場合がある。

例(適当なのが思いつかないが…)：気体の状態方程式でPV=nRT(Rは定数)を考えると、
生データはP, V, Tの3つでgetP(), getV()...で得られるデータはP, V, n, Tの4つ
みたいにメソッド経由の方が情報が増えたりすることが多々ある。
生データを直接触って4つ目の情報を導き出す時には方程式を使わなければいけないが、
方程式を変化させる必要がある場合、メソッド経由ならメソッド内だけ変えればｲｲのに対して、
生データ直接お触りの場合は、触ってるの全てを直さなければいけない。

っていうか、オブジェクトの"生データ"なんて、たいがい見ても意味ないものばかり。
ただの委譲先オブジェクトだったり、加工しないと意味のないデータだったり…。

＃つまりは、情報隠蔽の是非の議論だよね？勘違いしてるかな？
＃論点が良く分からないのよ。
0256デフォルトの名無しさんNGNG
>>250
＞- 機能そのものよりも、その機能プラスその機能を自己完結させる
＞　ために必要なものまでを含めてモジュールとする傾向が強い。
なぜ弱点なのだろう？
そうしておくと、モジュール間の結合が疎になる利点があるし、
オブジェクトの内部が矛盾した状態にならないことを保証出来る
利点もある。
それに、>>150がこだわる「統一されたインターフェイス」を提供
するのには、必要なことだとおもうが。

> - カプセル化を前面に押し出しておきながら、それを柔軟に扱うの
> 　に必要な機能を提供していない(これは言語依存かも)。
カプセル化しているからこそ、あるモジュールが外部に提供する
サービスが保証できるんであって、中を自由にいじれるように
してしまったら、そのモジュールが動作を保証できなくなる。
「柔軟」というのは、危険なコードが自由に書ける事ではないだろう。

>>150は、インターフェイスの統一にこだわるあまり、モジュールの
提供する、そして動作の保証をするインターフェイスの重要性を
理解できていないようだ。


0257256NGNG
カプセル化を情報隠蔽に変えても、同じだな。
カプセル化して、さらに、外部に晒したくないものは隠蔽する事で
モジュールが公開しているインターフェイス以外の方法でその
オブジェクトにアクセスする事を拒否できるんだしな。
する
0258150NGNG
>>252
>で、何が困るんでしょ？
不必要なものは無い方がよい。そして、その不必要なものが
インターフェイスとして公開されてたりすると、知らない
所でそれをあてにされてたりして、思わぬ所で躓いたりする。

いい具体例が思いつかない‥
0259256NGNG
>>258
それは、不必要なインターフェイスを公開するほうが悪い。
しかし、公開していない内部にアクセス出来る方がいいと
主張してるひとの言う事とは思えないんだが…
0260256NGNG
なんか、戦場スレもそうだったが、設計の悪いモジュールを
ＯＯ（またはＯＯＰＬ）のせいにしてるやつって、以外と多いのな。

あと、危険なコードははじめから書くな、っていう主張と、
危険であることが解かっていれば書いて良いっていう主張は、
永遠に平行線なんだよね。

おれは、「やむおえない場合なら、危険であることが、シンタックス的、
セマンティックス的にコードと設計書に主張できれば、危険なコードも
書いてもいい」っていう意見だ。
0261150NGNG
>>259
先にこっち。

例えばjavaなんかだとクラスのルートであるところのObjectクラス
で比較メソッドbool equals(Object)が公開されてる。比較すること
のできないクラスを定義したとしても、こいつが洩れなく付いてくる。
それではということで、privateに再定義しようとするとコンパイル
エラーになる。なぜなら、一度公開されたインターフェイスをアクセス
制御を強める方向に再定義することはインターフェイスの意味を破壊
してしまうから。
どうしても比較させたくない場合は例外を送出するように再定義する
くらいしか解決方法がない。

こんな問題をスマートに解決する方法の一つとして、不必要なインター
フェイスは最初から避ける、てのはかなりいい線いってると思うけど
どう？

>公開していない内部にアクセス出来る方がいいと
>主張してるひとの言う事とは思えないんだが…
何でもOKって言ってるわけじゃないよ。リスクを承知の上で、
ってのは>>199とか他の所でも結構触れてる。>>156では
明示的に宣言するなら、とかそうゆうことも書いてる。
0262デフォルトの名無しさんNGNG
150は頑張ってるつもりかもしれないけど、結局のところ

「このクラスライブラリは俺の求めるequalsを提供しない。謝罪と賠償を・・・」

って言ってるだけ。
変な比較メソッドが必要になるような自分の設計を見直すところから始めろよ。
0263デフォルトの名無しさんNGNG
【1:35】【抱き枕】すじ丸出し抱き枕ってどうよ？
http://mentai.2ch.net/test/read.cgi/otaku/1016198191/
0264169NGNG
>>260
情報隠蔽はOOのとても基礎の部分だから、
実際に情報隠蔽を破る前に
本当にそれが必要で他にもう方法が無いことが確実であることを
当事者のできるだけ多くが議論して合意している、
という前提で

> おれは、「やむおえない場合なら、危険であることが、シンタックス的、
> セマンティックス的にコードと設計書に主張できれば、危険なコードも
> 書いてもいい」っていう意見だ。

に同意。
OO原理主義的(藁)なSmalltalkでも、
インスタンス変数は皆protectedであって
アクセサを通さなければ外部から更新することはできない。
が、実はinstVarAt:やinstVarAt:put:で外部から直接変数を
参照したり代入したりできる。
これは確実に情報隠蔽を壊しているのだが、
これらinstVarAt:とinstVarAt:put:がないとSmalltalk環境自体が動かない(藁
もちろん、滅多な事では使ってはいけないのは言うまでもない。
0265169NGNG
比較できないオブジェクトって…
少なくともidentityはどんなオブジェクトにも必須でしょ。
そのidentityをデフォルトのequalityにでもしとけばいいんじゃないの？
0266150NGNG
>>256
>そうしておくと、モジュール間の結合が疎になる利点があるし
これは理解できる。オブジェクトが自己完結的であった方が
よい理由になるね、納得。

ただ、インターフェイスの統一に関しては違うと思う。多重継承
なりインターフェイス継承なり、これを補える設備がある。
0267256NGNG
>>266 =>>150
インターフェイスの継承は、「あるインターフェイスを提供している」事を保証
するに過ぎないんだ。
提供しているインターフェイスが適切に実装されていることを保証するには、
やっぱり自己完結させるべきなんだ。
たとえば、インターフェイスFileStreamを継承したとして、open,close,
read,write,seek みたいなメソッドがあることが保証できる。
しかし、これらのメソッドが正しく動作する保証は、そのメソッドを実装する
以外に、矛盾した結果（openしてすぐにwrite,先頭にseekしてreadしたのに
writeしたものが読めないとか）にならない事を保証しないと意味が無い。

インターフェイスとは、あるサービスを提供することを保証するだけでなく、
サービスを保証しない条件を明確にする意味もあるんだよ。
0268　NGNG
オビゼクトなんてランタンよ
ふっ
0269256NGNG
>>264
さんきゅ。
欲を言えば、処理系やリファクタリングブラウザとかで、危険を検出できる
ような予約語とかがあるといいな、とか思うのだな。
0270150NGNG
>>267
それは仰る通り。なんだけど、それが「統一されたインターフェイス」
や、オブジェクトの機能と関係無いインターフェイスを提供することに
価値がある、という話にどうゆうふうに結びつくのかわからん。

論点を明確にしたいので、ちょっと質問。
Streamオブジェクトに文字列化のためのtoStringないしshowメソッド
は必要？　オレはこれが不必要だと思ってて、こうゆうのを自己完結
のためのインターフェイスだと言ってるんだけど。
0271169NGNG
>>267
そこでEiffelのprogram by contractとなる、と。
0272256=267NGNG
>>271
なるほど、さんきゅ。
Eiffelはアスキー出版から本が出たときに、前半だけ読んで、そのままだわ。

>>270
toStringやshowが、機能と関係無い、って言ってる時点で、論点の確認に
ならない気がする。
ま、そういうのも「自己完結」の一部というのはわかる。けど、それについては
それこそ、なぜ弱点なのかの説明が欲しい。

それから、もし、仮に、「統一されたインターフェイスのために、
なぜtoStringやshowが必要か？」っていう質問なら、toStringや
showは、シリアライズは可視化のための統一されたインターフェイスじゃ
ないのかね？って返事になるな。

ま、ちゃんと答えるなら、toStringやshowは自己完結の一部であって、
それが自己完結そのものではない、ってところか。
自己完結は統一されたインターフェイスを保証するために必要だ
といっているのであって、自己完結が統一されたインターフェイス
の全てじゃない。
0273272化粧品NGNG
＞自己完結が統一されたインターフェイスの全てじゃない。
自己完結の全てが統一されたインターフェイスのために必要なわけじゃない。

のまちがい、スマソ。
0274デフォルトの名無しさんNGNG
>>270

どう見てもOOPLそのものへの疑問ではなく、既存のクラスライブラリの設計への不
満をぶちまけてるだけとしか思えない。
嫌なら自分で1から作れ。
そんな俺様ライブラリ誰も使わんと思うが。
0275256NGNG
つか、なんつーか、
>>266
＞>そうしておくと、モジュール間の結合が疎になる利点があるし
＞これは理解できる。オブジェクトが自己完結的であった方が
＞よい理由になるね、納得。
とか、今納得してるようなら、もうすこし勉強と経験積んでからもう一度
かんがえてくれたまい。
って感じな…
0276150NGNG
とりあえず、>>265 >>272は同意にせよ反論にせよ、有意なレスを
するにはもうちょっと時間がかかりそう。天秤がたくさんだ。

>>274
その通り。>>150を見ればわかると思うけど、オレの意見は既存の
クラスライブラリに対して、設計が悪いんじゃないか？という疑問
を持ったことから始まってる。

>>275
そうかもね(w
0277デフォルトの名無しさんNGNG
>どうしても比較させたくない場合は例外を送出するように再定義する
>くらいしか解決方法がない。
こいつ痛すぎる（ｗ
はっきり言うけど、Comparatorなんて作る利点はない。
もちろん指摘の通り情報隠蔽ができなくなるのが一点。
あとは、あえて情報隠蔽を捨てて実装してみろ。
１万行超えたあたりで理解できる。
オブジェクトに比較メソッド持たせるのと何も変わらない。
むしろ､オブジェクトに比較メソッドを持たせる事の利点がわかるはず。

統一的なインターフェースとか言ってるけど、クラス名の指定が必要なわけだから
全然統一じゃない事に気づかないほど頭が悪いのか？
0278228NGNG
おはよう
>>275
クラスを「利用する側」と「提供する側」の永遠のジレンマですな．
利用する側：クラスは「自分の」プログラムに適したものが欲しい
提供する側：クラスは「利用者すべての」プログラムで使える様にしたい
つうことで，利用者は最適性を，提供者は汎用性を追い求める……と
結局，両方とも追い求めているものが違う訳だからねぇ．

通常だと継承とかしてクラスのカスタマイズをするわけだけど，
隠蔽という概念を尊重するのならばあまり無茶はできないし……

利用する側：
　カスタマイズ「したい」部分をカスタマイズすれば最適化を行える
　しかもそのカスタマイズは未来永劫利用できることを保証されている

提供する側：
　ユーザーがどのように利用していようと，ユーザーに影響を与えずに
　クラスのカスタマイズができる．

つうのは理想だなぁ．両者が好き勝手やるとなんにもできないので，
結局契約で縛る必要があるんだけど……

……デザインパターンとかフレームワークとかの話になるのかな？

0279228NGNG
うう……>>275じゃなくて>>274……逝ってきます
0280デフォルトの名無しさんNGNG
>>277
はあ？
Comparatorが情報隠蔽を壊せるわけねえジャン。何言ってんだよ。
比較メソッドとの違いももう何回もループしてるだろ、その議論。
0281デフォルトの名無しさんNGNG
>>280
ﾏｱﾏｱ。
277はただのアホなんで、無視してやってくだせえ
0282　NGNG
もー
クラスが邪魔で邪魔で邪魔で邪魔で　しょーがないんです。
よーし、お父さんstatic使っちゃうぞー。
0283277NGNG
（>´ ー｀<）全員逝け
0284召還師NGNG
今度の論点は、継承の事か。
こちらの方が、深く根深い問題だな。
継承したら、子クラスは親クラスのインタフェースを必ず
すべてサポートしなければいけないのが、嫌なんだろうな。
階層の下に行くにつれて、インタフェースがどんどん大きくなっていって、
ある時点での子クラスは、その子クラス自身が使われる問題領域では
恐らく使わないであろうインタフェースまでサポートしなければいけないのが納得いかない…と。

これは確かに歯がゆいねぇ。
(1)子クラスが親クラスのインタフェースを全て扱えることを保証
(2)あるクラスが必要最小限のインターフェースをサポート
の2つの要求のどちらが優先か、にかかっている。
普通は、1>2の場合継承を使い、1<2の場合委譲を使う。
実装階層とインタフェース階層を別に用意して、
TPOに合わせて(?)インタフェース階層をいくつも作ったりとか…。
ここら辺が気持ち悪い？
0285224NGNG
>>234の訂正。
standard_equal と deep_equal と equal は引数が２つのメソッドだと書くの忘れてた。
それと、オーバライドできるのは equal じゃなくて、引数が１つの is_equal です。
勘違いした。すまん。

Eiffelの例を考えてみました。

class COMPARATOR
feature
　　xxx_equal(a, b: FOO): BOOLEAN is do ... end
　　...
end

class B inherit A COMPARATOR
feature
　　foo1, foo2: FOO
　　hoge is
　　　　do
　　　　　　create foo1
　　　　　　create foo2
　　　　　　if xxx_equal(foo1, foo2) then
　　　　　　　　print("True")
　　　　　　else
　　　　　　　　print("False")
　　　　　　end
　　　　end
end

必要があれば xxx_equal を引数として渡すこともできます。
0286228NGNG
>>284
継承だけの話というよりか，クラス設計者とクラス利用者の間の
契約の話ですかねぇ
その中に継承の話も含まれるんだけどね．

150は，
　クラス利用者がクラスを自分のプログラムに最適化する過程で，
　クラス設計者が想定した状況（クラス利用者に対して提示した契約）
　を越えた範囲でオブジェクトを利用したくなる事態が発生するけど，
　＃例：オブジェクト同士の比較
　＃あと，継承したときの子クラスのインターフェースを制限したいとか
　このときにオブジェクト指向言語だと（隠蔽などの機能により）
　クラス設計者の権限が強いので，利用者はクラス設計者の掌の
　なかでしかプログラミングできないのは不便だ．これはオブジェクトの
　独立性やカプセル化等を前面に押し出したOOPの悪い癖じゃない？
といってるわけで．
当然クラス設計者にとってこのこと（想定した状況しか発生しないと
いうこと）は優れた利点であり，同時にOOPの利点でもあるんだけど，
クラス利用者にとって（他人が想定した状況しか作り出せないということは）
結構大変な制限になるから不自由なことになるんだよね．

言語仕様として，クラス設計者とクラス利用者の間の権限をどのへんで
バランスさせるか……難しいよねぇ

＃まあ，（クラス）設計者は利用者の要望に応えるよう努力している
＃けどね．例で出てきた比較の話だと，STLではデフォルト機能を利用して
＃両対応してるし．でも，それとはちょっと違う話．
0287228NGNG
>>286と書いたけど，よくよく考えると150はそこまで言ってないね……
あくまでオブジェクトの独立性（カプセル化／情報隠蔽）の話だなぁ
ちょっと先走り汁が出すぎたみたい．逝ってきます……
0288274NGNG
>>276
>オレの意見は既存のクラスライブラリに対して、設計が悪いんじゃないか？
>という疑問を持ったことから始まってる。

そんでequalsに矛先を向けるのか？
「標準の比較メソッドが有って困る奴より嬉しい奴の方が圧倒的に多いはずだ」
という設計思想の表明だろ、アレは。
脳みそがねじれててライブラリの文脈に沿った設計が出来ないんなら無理してOOPL
使う必要は無いが、逆恨みでデムパを振り撒くのはやめてくれ。
0289277NGNG
>>280
わかってないのはおまえ。
Comparatorが情報隠蔽と背反だと書いてるのが読めないのか？

>比較メソッドとの違いももう何回もループしてるだろ、その議論
はぁ？
じゃあ､具体的な違いを上げてみろよ。
ここの奴らは､違いが分かってないだけ。
だから､俺は実際に実装してみろと書いたまで。
思考実験できない奴は、実際にやってみるか
人の意見を素直に聞くかしかないだろ。

それから、150は自作自演するな。
見苦しい。

デザインパターンとかフレームワークとか言ってるやつは問題外。
今更継承が論点になってると思ってるのか？
どんな方法を用いても、継承抜きで何が考えられるんだよ。

それから､継承と委譲の違いが分かってない奴
おまえ実行時ポリモーフィズムが使えてない恐れあり。
ハンドルはネタか？
キモイからやめとけ。

>>286
それ全部妄想

こいつら､ほんとにOOでプログラム書いた事があるのかと疑うよ。

どうせ､学生だと思うけど。
最近の大学院生は理論先行の奴ばっかり。
アルゴリズムは知ってるけど､コーディングができないってどんなバカだよ。
0290デフォルトの名無しさんNGNG
はー。すっきりした
0291デフォルトの名無しさんNGNG
これでアフォの大量発生は終わったと思われ
0292デフォルトの名無しさんNGNG
一定規模以上のプロジェクトに参加してないだろう青さが
そこかしこにありありと見えるな。

本をかじった程度で語るな。
0293デフォルトの名無しさんNGNG
一定規模以上になるとOOみたいに本を齧ってりゃ済む知識よりも
プロジェクト管理というこれまたやっかいなファクタのほうが重要になるね。
0294150NGNG
>>278>>285
>>228氏は頭いいね(w どうもその辺にたどり着いたらしい。
こうゆうジレンマってOO以外の手法ではどう捉えられてんだ？
0295デフォルトの名無しさんNGNG
このデムパ野郎は放置の方向でいいでしょうか？
0296デフォルトの名無しさんNGNG
C.compare(A , B) の実装が return(A.compare(B)); という罠
0297デフォルトの名無しさんNGNG
そしてA.compare(B)の実装がreturn(B.compare(this);になっているという罠
0298デフォルトの名無しさんNGNG
結局B.compare(arg) は return(C.compare(arg, this));という…
0299デフォルトの名無しさんNGNG
多重継承を知って始めてオブジェクト指向すごいじゃんと思った。
0300デフォルトの名無しさんNGNG
多重継承ならCOMのがすごいよ
0301228NGNG
>>288～
ありゃりゃ，先走りすぎたか．せっかく面白いネタだったのになぁ．
青臭い理論を軽く受けながすぐらいの貫禄が欲しいもんだけど．
理論で遊ぶのって，実務者にとっては腹立たしいことなのかね？

まあ，一言だけ．
＞こうゆうジレンマってOO以外の手法ではどう捉えられてんだ？
これは実際に自分で体験してみるのが正解かな？
とりあえずはC, Delphi, VBといった環境が対比的で面白いと思う．
＃環境／手法の限界を体験するのはなかなか大変だけどね．

とりあえず150には伝わったみたいなので潜伏しよう……

0302デフォルトの名無しさんNGNG
恥ずかしい277沙羅仕上げ！

つーかよぉ、Comparatorと情報隠蔽が背反なら
オブジェクト指向と情報隠蔽も背反になっちまうわなﾌﾟﾌﾟﾌﾟ
Comparatorが特殊なわけではないことは既に何回か指摘されているよ。
0303デフォルトの名無しさんNGNG
>>302
いまだにあげてるおまえを晒し上げ
0304デフォルトの名無しさんNGNG
>つーかよぉ、Comparatorと情報隠蔽が背反なら
>>156
をどうぞ

>青臭い理論を軽く受けながすぐらいの貫禄が欲しいもんだけど．
ベースがなってないから､そこから展開される理論は幼稚なものになる。
でも、ベースにまで論点を戻さない。
だから厨房って言われるわけ。

>とりあえずはC, Delphi, VBといった環境が対比的で面白いと思う．
何言ってんだか。
Scheme,Lisp当たりを上げないと意味ないだろ。

ついでに､ジレンマって150の勘違いなだけだし。
0305デフォルトの名無しさんNGNG
150から読んでみたよ。
で､気づいた。

>オレは第三者が比較を行うのが自然な設計であると
>考えてるから、現在のOOは良い設計を行う妨げになってるのでは
>ないかと思うわけ。
現在のOOは150が思う自然な設計を行う妨げになっていると
訂正したほうがいいかもな。

>明示的に宣言した場合にはオブジェクトのprivate
>な部分にアクセスすることを許可するような仕組みが考えられる。
Object.equalもプライベートな変数にアクセスしますが何か？

リードオンリーメンバで解決というのに納得した俺は厨房？

何も新しい事を書いてないのでsage
0306召還師NGNG
>>277やべ。リアルなのが出てきた。

実はここまでいろんな意見が出されているが、それらは観点の違いだけ。
僕の場合は、情報隠蔽を厳守するという前提の元で、
あるオブジェクトを柔軟に制御できないのはインタフェースの設計に問題があると考え、
そのインターフェースに深く関連する継承と委譲について軽く触れただけ。
228が最終的に移行した意見は、ライブラリは改変してはならないという前提の元で、
あるライブラリの提供者と利用者の立場の違いを述べている。
150はやや飛躍している感があるが、ここで取り上げられているような問題が
たびたび噴出するということ自体が、パラダイムとしてのOOの欠点ではないかという意見だ。

>>277君だけずれてるんだよね。
まず、Comparatorと情報隠蔽は何も関係ない。
また、>>284での僕の意見の「子クラスは親クラスのインタフェースを必ず
すべてサポートしなければいけない」というのを読み間違えているようだが、
これは概念的強制であって、OOの枠組で作業する以上、あらがえないんだよ。
ちなみに、継承と委譲の違いを指摘するなら、
転送(forwarding)と委譲(delegation)の違いを指摘すべきだね、
>>284の文意を見る限り。(自分で言うのもなんだが)

まあ、>>277は概念と設計と実装がごっちゃになっているんでしょう。
君のような体力系PGは体が資本だから、体に気をつけてな。
0307デフォルトの名無しさんNGNG
オブジェクト指向言語において継承というのは必須な概念ではない。
継承のないオブジェクト指向言語、あるよ。そしてこういうこと言う
のなら実装の継承と界面の継承(サブタイプ)を区別して論じてくれ。
あとEmeraldとか知ってる？

0308デフォルトの名無しさんNGNG
>>306
いや、>>277は概念も設計も実装もわかちゃいないに一票
0309デフォルトの名無しさんNGNG
>>289
実行時ポリモーフィズム？ﾌﾟﾌﾟﾌﾟ
0310召還師NGNG
>>307そういうツッコミを待っていた。
エメラルドってプロトタイプベースのOOPLだっけ？
実際、僕はそういう言語には触れたことがない。
ちょっと調べてみるけど、その言語は、「概念的に」継承が存在しないんだね？
クラスベースの継承に相当するメカニズムそのものが存在しないと。
だとしたら、オモシロイね。

＞実装の継承と界面の継承
書くのが面倒臭いから区別しなかった。確かに、無責任だな。
0311169NGNG
>>310
Selfなんかも継承がないOOPLだね。
コードの再利用は全部委譲を通して行われる。
0312デフォルトの名無しさんNGNG
話の流れがよくわからない。
わかりやすくまとめてくれる識者求む。
結局今は何が論点なんだ～。

継承のないOOPLって動的バインドはどうやってるんですか。
ついでに、実行時ポリモーフィズムって動的バインドの事だよね？
0313デフォルトの名無しさんNGNG
なんで継承が無いとダイナミックバインドが出来ないって事になるんだ？
0314召還師NGNG
エメラルドにも、概念的に継承が存在するんですけど…。
でもまあ、参考になったよ。
継承がcloneされた時のみ発生し、その後は個別にupdateするみたいな…。
(間違っていたら訂正して)

しかし、OOの概念を取り扱うためにはOOPLからなるべく離れなければいけないが、
そういう意味では284でのクラスや委譲という表現は避けたほうがいいのかな？
むしろ、何か特定のOOPLをベースに議論した方が分かりやすいな。

＊僕も、概念と実装が区別できてないな。
0315デフォルトの名無しさんNGNG
ＯＯは概念も実装も発散しているので、問題を絞らないと議論不能。
と言ってみるテスト、つか、実感。
0316169NGNG
>>313
たぶん312はsubtype関係によるinclusion polymorphismと
ごっちゃになってると思われ。
0317312NGNG
>169
詳しく教えて欲しいんですが
私C++しかよくわからんのですが、
動的バインドってのはvirtualと派生クラスポインタでやるものと認識
してい・・・いえ本に書いてありました。

本を読んでみると
関数オーバーロードもポリモーフィズムと呼ぶ事が書いてありますが
こっちがOOと関係あるかと言えば､ないですよね。

動的バインドのほうはオブジェクト指向プログラミングには
なくてはならない機能ですよね。
これを無視してオブジェクト指向とか言ってたら
デザインパターンが成り立ちませんからね。
0318デフォルトの名無しさんNGNG
>>317
それは、statically typed なOOPLの一部に限っての話。
dynamically typedな場合は、継承が無くても（以下略）
0319317NGNG
そういうことですか。
dynamically typedなOOPLで
もっともメジャーなものはなんでしょうか？
0320デフォルトの名無しさんNGNG
>>317
動的バインドには(実装の)継承どころか(界面の)サブタイプすら
なくたって構わない。たとえばinterfaceどうしの継承がなくて、
変数や返値の型にはinterface型しか書けないよう改造したJava言語
考えてみなよ。動的バインドは何ら問題なくできるでしょ？
そういうものもstatically typedな言語の「一部」には違いないよネ。
0321デフォルトの名無しさんNGNG
>>319
そういう質問すると、アレが出てくるぞ、アレが…
0322317NGNG
>>320
ちょっとよくわからないのですが、
界面のサブタイプとは、同名のメソッドという意味でしょうか？

javaよくわからんのですが、
Class implement Interfaceとやる事くらいは
どこかでみた事あるのですが
このimplementは継承ですよね・・・
0323デフォルトの名無しさんNGNG
はっきり言う。
実務で５年以上OO漬けになってるやつ以外は口出すな。
0324デフォルトの名無しさんNGNG
>>323
はいはい。今日はいい天気ですねえ。
0325デフォルトの名無しさんNGNG
はっきり言う。
ＯＯについて、はっきり断定する意見は信用するな。
0326デフォルトの名無しさんNGNG
はっきり言う。
ＯＯについて、あいまいな意見は信用するな。
0327デフォルトの名無しさんNGNG
わかっていない奴が、ＯＯについて断定的に語るのは迷惑。
0328デフォルトの名無しさんNGNG
はっきり言う。
あ、いや、やめとく…
0329デフォルトの名無しさんNGNG
Ruby━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
0330デフォルトの名無しさんNGNG
オブジェクト指向の概念を教えるスレじゃなかったのかここは。
0331デフォルトの名無しさんNGNG
じゃあネタ振りますか。
多態について騙ってくれ。
0332デフォルトの名無しさんNGNG
323はスレの趣旨を理解していないアフォ。
と思ったが、教える側は、ちゃんと教えられるだけの知識と経験を
もっている奴以外、口出すなという意味なら同意。
0333デフォルトの名無しさんNGNG
僕はオブジェクト志向な人間だ。
0334デフォルトの名無しさんNGNG
Ruby━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
0335デフォルトの名無しさんNGNG
クソスレ化確定だな・・・さようなら
0336デフォルトの名無しさんNGNG
多態について

下僕インターフェイスを実装しているオブジェクトは
「逝け！」の命令だけで目的地に向かう。

その昔は下僕に応じた命令をしなくちゃいけなかった
「怪鳥ロプロス空を飛べ！」
「ポセイドンは海を逝け！」
「ロデム変身地をかけろ！」

ご主人様も楽な時代になりました。
0337169NGNG
>>322
implementsも継承の一種と看做せるし、subtype関係も発生させるけど、
interfaceという型仕様に対してclassが実装を与えるという契約の色のほうが濃い。
ちなみにJavaではinterface間の継承関係も存在して、interface型間のsubtype関係を構築できる。

ちなみに動的型OOPLといえばSmalltalkを出さないわけにはいかんでしょ、やっぱ。
0338デフォルトの名無しさんNGNG
　勉強になるスレだ。
ちゃんと答えが返ってきたよ。
0339デフォルトの名無しさんNGNG
>>336
なんかジャイアントロボを思い出したよ。
ロボ～～だけだもんな、命令（藁
0340デフォルトの名無しさんNGNG
「会長ベサトスプログラムを作れ！」
「城乃内はバグを取れ！」
「弦間（以下略）」
0341デフォルトの名無しさんNGNG
(ﾟдﾟ)Rubyｰ
0342デフォルトの名無しさんNGNG
バビル２世 ＝ 構造化
ジャイアントロボ ＝ オブジェクト指向

このスレの結論はこれでいいですか？
0343デフォルトの名無しさんNGNG
>>337
頼むから実装の継承と界面の継承を分離して語ってくれ。まず
implementsが実装の継承なわけないよね？インタフェースには
実装がないんだから。で、継承とは何か定義してみなよ。なおかつ
subtype関係も発生させるっていうのならsubtype関係も定義して
みなよ。
0344デフォルトの名無しさんNGNG
>>343
界面の継承とインターフェイスの継承と仮想クラスの継承、概念の違いはどこにあるですか？
その文脈でいうところのsubtypeとは、どんなもんですか？
0345169NGNG
>>343
で、お前は何を言いたいんだ？
implementsが実装の継承なわけないんだから、
改めて界面の継承と断る必要もないだろ。

これだけじゃ何だから１つ答えておくが、
ClassA implements InterfaceB
の場合、ClassAはInterfaceBのsubtypeだ。
0346317NGNG
>動的バインドには(実装の)継承どころか(界面の)サブタイプすら
>なくたって構わない。
やっぱり､これの意味がよくわからんのですが
界面ってなんですか？
インターフェースを無理やり日本語にしたような感じですが。
そういうふうに解釈させてもらいますと、
オブジェクト同士に共通のインターフェース(界面）を持たせる手段は
C++では継承
JAVAでは継承(extends)とimplement
だとおもうのですが、
動的バインドするには共通のインターフェースが必須です。
そして共通のインターフェースを持ったクラスのIDが必要ですね。

そうなると、動的バインドするには継承のような機構がないとダメだと思うんですね。
で､どこかに委譲というのがありましたが
委譲してしまいますと動的バインドは使えんのですね。
03471NGNG
こんばんわ。
話が難しいのでずっと黙ってましたが、
オライリーのサイ本を読んでると、こうあります。

では、次の二つのコードを比較してみましょう。
rect.setSize(x, y);
setRectSize(rect, x, y);
　どちらのコードも、オブジェクトrectに対して同じ操作をしています。
しかし、操作の対象がオブジェクトであることは、先ほどのメソッド呼び出しの
書式の方が明瞭です
（この説明がピンとこない方はオブジェクト指向プログラミングに慣れて
いないからでしょう。もう少し経験すれば納得できると思います）。

「明瞭」「ピンとくる」とか「慣れ」ってある程度事情を語ってますか？。

上の文章にもたまたま比較が出てくるけど、オイラ的にはあいかわらず、
ヒトの認知や意思がもともとオブジェクト指向だったに一票。
絶対的な視座や、視点の欠如にとっては比較は意味ないようだよ。
神の前の平等とか、不増不減とかね。
素人が口出ししてごめんね、みんな。つまりもっと分かりやすく話してってことです。
0348169NGNG
>>346
あるオブジェクトが答えることができるメッセージの集合を考えてみましょう。
整数オブジェクトAは+, -, *, /, toStringに答えることが出来るとします。
文字列オブジェクトBは++, toUppercase, toStringに答えることが出来るとします。
ここで、変数VにメッセージtoStringを送ったとします。
すると変数Vが指すオブジェクトが自分なりにtoStringに答えます。
ここで動的束縛が発生するわけです。

EiffelやJavaなどの静的型言語では、変数に型を持たせることで
その変数にメッセージを送ってもいいかどうかをコンパイル時に判断します。
この時の基準になるものがsubtype関係で、extendsとimplementsなどから構築されます。

動的型言語では、実行時に判断します。
Smalltalkではクラスの継承関係を遡ってメッセージに対応するメソッドを探索しますが、
あくまでそのオブジェクトがそのメッセージに答えられるかどうかのみが問題であり、
継承関係はメソッドを探索するときに使われるにすぎません。
もちろん共通の基底クラスが必要なわけではありません。
あくまで個々のオブジェクトがメッセージに反応できるかどうかのみが問題になります。

Selfではクラスがありませんが、オブジェクトがメソッドを持っており、
委譲関係を使ってメッセージに対応します。

というわけで、動的束縛にはクラスさえ必要ありません。
0349デフォルトの名無しさんNGNG
途中からしか読んでないけど、動的バインドの意味がそれぞれ違うのでは？

動的バインドに共通の型が必要ないって言ってる人は
RTTI によるメソッド検索とか、ウィンドウズのウィンドウプロシージャみたいな
方法でメッセージ→必要な動作の結びつけの事を動的バインドって言ってると思うし、

共通の型が必要でしょ？って言ってる人は vptr から vtable を探しだす部分
の事を動的バインドって呼んでる気がする。

どっちが正しいんだっけ？


ところで、OO に関して考えたことをひとつ。
OO を学ぶと何かに深く依存する事を嫌うようになる。
結局、実装に依存するのではなくインターフェイスに依存する(抽象度が高くなる)だけで、何かに依存している事にかわりはない。

アンチOOはごく少しの保険料を払うのを拒んでいざという時に泣く人で、
OO信者は常識的にありえない災害を恐れて保険会社のカモになる人。

俺はどっちも嫌だな…ちょっと OO 信者気味だったから、もう少し自分の考えを見直そうと思う。
でもアンチOOほど実装に依存する事に疑いを持たなくなる事はもうできないだろうなと思う。
0350デフォルトの名無しさんNGNG
>>345-346
なるほど、あなたがたは「A implements I」を「AはインタフェースIを継
承している」と呼ぶわけなのね。私はそういう場合には「継承」という言
葉を使わないもので話が食い違っていたようです。だって定められたシ
グニチャのメソッド作るっていうだけなんだから何も「継承」はしてないっ
ていう気がするんだもの。またJava Language Specificationでもその場合
に「inherit」とは言わないよね。

>>347
CLOSではsetRectSize(rect, x, y)でrectの種別に応じてdispatchされます
よね。そういうオブジェクト指向言語もありでしょ。
0351デフォルトの名無しさんNGNG
>>349
「共通の型が必要ない」とは言っていないです。ただ継承は必要
ないと言っただけです。ところが、あるインタフェースを
implementsすることを「継承する」と呼んでいる人と対話していた
ために話がこんがらがったようです。
0352デフォルトの名無しさんNGNG
名無しで話してるからわけわからん
名を名乗れ！
無名は嫌い。
0353デフォルトの名無しさんNGNG
だって2ちゃんねるなんだもーん。
0354317NGNG
やっと、理解できました。
どうも。

>Selfではクラスがありませんが、オブジェクトがメソッドを持っており、
>委譲関係を使ってメッセージに対応します。
こっちは、Selfと言うものを触ってみないと理解できそうもない。

smalltalkの動的束縛はjavaと比べると破格ですな。
で、javaのinterfaceが先進的である理由がようやくわかったと思う。
java信者になりそうだ。
0355デフォルトの名無しさんNGNG
だから界面継承と実装継承を区別しろって。
実装継承しか継承と認めないの↑がいるだろ。
0356355NGNG
おっと、355は>>351ね。
0357デフォルトの名無しさんNGNG
>>355
ていうかそれ読みにくいし本に載ってない単語だから使うのやめない？
0358デフォルトの名無しさんNGNG
>>351
>implementsすることを「継承する」と呼んでいる人と対話

「インターフェイス継承」という用語が通用している現状は無視？
0359デフォルトの名無しさんNGNG
>>357
じゃなんて呼ぶの？インタフェース継承？それで「A implements I」
の場合「AはIからインタフェース継承」していると呼ぶのかなあ。
自分的にはやっぱ「I1 extends I2」のようなものだけをインタフェース
継承と呼びたい気分だ。もちろん実装継承のみに「継承」という言葉を
使ってインタフェース継承は「サブタイピング」と呼ぶ、と言う主義は
ある。それはそれで気持が良い。
0360デフォルトの名無しさんNGNG
>>358
かぶった！それで「A implemens I」と「I1 implemens I2」は区別
しないわけね？
0361169NGNG
>>358
UMLでも一般的だよね、インターフェイス継承。
0362169NGNG
>>359
UMLでは、まさにA implements Iをインターフェイス継承と呼んでると思うけど。
0363デフォルトの名無しさんNGNG
>>362
UML暗いもんですいません。それで「I1 implemens I2」はUMLでは
どう呼ばれているのでしょうか？
0364363NGNG
>>363
間違い! 「I1 extedns I2」つまりあるインタフェースを土台
として新しいインタフェースを定義する場合のことです。スマソ。
0365169NGNG
>>363
うーん、
インターフェイス継承そのものを表現するシンボル(ロリポップ)は
クラスとインターフェイスの間に書くなあ。
インターフェイス同士の場合は普通の継承のシンボル(三角)で書く。
ちなみにクラスとインターフェイスの間の継承も普通の継承のシンボルで
表記することも可。ただしインターフェイスであることをステレオタイプで
明示する。

でもまあ、これはあくまで記法の問題だから、
用語としてインターフェイス間の継承をインターフェイス継承と呼ぶかは
また別問題のような気がする。
ちょっと手元に資料がないんで、はっきりしなくて、すまそ。
0366169NGNG
> インターフェイス継承そのものを表現するシンボル(ロリポップ)は
> クラスとインターフェイスの間に書くなあ。
間に書くっていうか、
インターフェイスは丸で囲んで、実装するクラス(四角)に実線を引く。
0367デフォルトの名無しさんNGNG
>>365-366
ご教示感謝！とりあえず、UMLで「A implemenets I」を
インタフェース継承と呼ぶことは分かった。「I1 extends I2」
は同じ用語か別の用語かまだ分からないんだけど、UMLはさて
おいて、この両者は区別して呼びたいと思いません？

0368デフォルトの名無しさんNGNG
>>367
さておくも何もインターフェイス継承とただの継承でしょ
0369デフォルトの名無しさんNGNG
結局、>>351は何が言いたかったんだ？
0370デフォルトの名無しさんNGNG
>「A implemens I」と「I1 implemens I2」は区別
これを区別する目的は何？
0371デフォルトの名無しさんNGNG
C++の仮想クラスとか、SmalltalkのimprementedBySubclassなメソッド
を含むクラスの継承は、どこへ行っちゃったんだろう？
実装を含まないクラスや、サブクラスがメソッドを再定義する事
を要求するクラスの場合は「継承」って呼ぶだろ？
0372デフォルトの名無しさんNGNG
>>370
インタフェースどうしを拡張しているのと、クラスを
作る時にそのインタフェースに実装を与えるのとでは
やることが全然違うと自分には感じられます。そう感じ
ない人もいるのかも知れませんが。
0373デフォルトの名無しさんNGNG
>>371
それは実装を継承してるから継承なんだとも言えるね。
もっとも全く実装を持たない抽象クラスからの継承も
継承と呼ぶんではあるけど。

0374371NGNG
>>373

Smalltalkはクラスを作る時でさえ、特別な構文を必要としないんだしね。
0375371NGNG
（あ、途中で送っちゃった。）

>>373
そう、それは予想していた答えのうちの１つ。

結局、「インターフェイスを継承する」っていう言い方をすりかしないか、なんて、シンタックスの話で、
インターフェイスをインプリメントするのが、継承の概念から外れてるわけじゃないんだよね。
Smalltalkはクラスを作る時でさえ、特別な構文を必要としないんだから、構文上は実装しているように
見えても、それを「実装の継承だ」っていうのはあまり意味が無い。


0376デフォルトの名無しさんNGNG
>>375
だからさ、ひとつ「継承」という用語の意味を定義してみてよ。
0377375NGNG
（すりかってなんだよ…するかしないか、だよ）

ところで、「ダイナミックバインド」だけど、動的バインドには動的なものと静的なものがある、
ってのは、押さえておいておくれ＞わかってないヤツ

静的なダイナミックバインドは、静的な型付けされた言語で、継承関係にあるクラスの
メソッドうちどのメソッドが起動されるか、っていうのが、実行時に解決されるような場合。

動的なダイナミックバインドは、実行時の変数型によって起動されるメソッドが決定される
というか、変数にバインドされているオブジェクトにメッセージが送信されるような場合。

静的に型付けされた言語で、動的なダイナミックバインドっていうのも、考えられる。
any型やobject型をサポートする言語は、これに入るだろう。

ちゅーことで、いま、論点ってなに？
0378375NGNG
>>376
定義っつってもなぁ…
「あるクラスの性質の一部、または全部を再利用することを宣言する。」
くらいは言ってもいいかな。

「継承」なんて、言語の定義によっていろいろあるからね。
親のもっている性質をすべて受け継ぐのを継承って定義してる言語もあるし、
Selfみたいに、継承を委譲で実現してる言語もある。

そもそも「継承の定義はこー」っていう答えが出てくるのは、わかってない証拠だろう。
0379378NGNG
クラスっていう言葉もつかうべきじゃないな。
0380デフォルトの名無しさんNGNG
概念とは違うけどOOの利点って何？
俺的には多人数で開発するときとかに楽になるかなと思うくらい。
一人っきりで開発するならあまり利点が見つからん。ゼロとはいわないが。
0381デフォルトの名無しさんNGNG
>>380
>俺的には多人数で開発するときとかに楽になるかなと思うくらい。

ウダウダ言う前にやれ。
やらん奴には一生解らん。
0382デフォルトの名無しさんNGNG
で、単に継承といったら、Inferfaceのimplementも含む、という結論で？
0383169NGNG
>>377
動的束縛といったら、
コンパイル時にどのメソッドが起動されるか解決されているようなのは
通常は含まないでしょ。
それを言うのなら、
「動的束縛を伴うメッセージ送信と、動的束縛を伴わないメッセージ送信がある」
というべきでは？
0384377NGNG
>>383
＞コンパイル時にどのメソッドが起動されるか解決されているようなのは
こういうのには触れてませんが、なにか？
0385169NGNG
>>384
すまそ。完璧に誤読。徹夜明けでボ～っとしとった。

前者はvtableなどで実装されるようなもの、つまり
ある変数に束縛されたオブジェクトが受け取ることが出来るメッセージ
の集合が変数の型によってコンパイル時に確定できるもの。
(メソッドをindex可能)

後者はvtableでは実装できないもの、つまり
ある変数に束縛されたオブジェクトが受け取ることが出来るメッセージ
の集合がコンパイル時に確定できないもの。
(メソッドをindex不可)

っていう事で合ってる？
静的型での後者はinterface型の変数へのメッセージ送信がいい例だね。

0386デフォルトの名無しさんNGNG
いまさらなんだけど
>>339
のジャイアントロボって
オブジェクト指向よりはるかに高度だろ
robo()
ってやるだけで適切なことしてくれるんだから
0387384NGNG
>>385
頭がはっきりしてから、もいちど読むといいかも（＾＾；
ダイナミックバインドは、ある変数にどのクラスのインスタンスが束縛されているかが
実行時まで特定できない。これは>>383のとおり。

>>377の前者の例は、C++で仮想函数を呼び出す時、後者の例は、Smalltalkのメッセージ送信だ。
0388384NGNG
補足さしてちょ。
>>385は、静的なダイナミックバインドと動的なダイナミックバインドの実装(?)の話、
ってことでは、はずれてないと思う、けど、充分じゃない。

後者の場合でも、メッセージの集合は確定できるでそ。（極論すれば全部ってこと）
それから、「コンパイル」は持ち出さないほうがいいだろうね。

で、なんで静的なダイナミックバインドと動的なダイナミックバインドを区別するか
っていうと…
はっきりわからん。
静的な型付けの言語と動的な型付けの言語だと、どうしてもこういう違いは出てくる
から、わざわざ分けなくても別れてるって感じ。

ただ、型安全の保障の問題とか、初期化時に変数の型が決定するような場合とか、
静的型付けの言語で、サブクラスへのキャストを許す場合とか、違いを論じるのに
意味のある場面はいろいろ想像できる。

このへん、詳しい人の解説があるとうれしいじょ。
0389169NGNG
>>388
> 後者の場合でも、メッセージの集合は確定できるでそ。（極論すれば全部ってこと）
全部ってことは、わからないのと同じ状態だと思う（藁
少なくともvtableによる実装は非現実的になる。

> で、なんで静的なダイナミックバインドと動的なダイナミックバインドを区別するか
> っていうと…
少なくとも言語設計での重要な判断の１つだとは思うけどね。

型安全の保障の問題については、別問題じゃないの？
例えばinterface型へのメッセージ送信では
動的なダイナミックバインドが発生するけど、
安全性は保障されてるよね。
0390デフォルトの名無しさんNGNG
>>378-382
寝てる間にずいぶん盛り上がっているな…（ｗ
そうね、クラスという言葉も使いたくない。何かが何かを引き継ぐ
ことを継承っていうでしょ。一番広い意味はそれだよね。あ、別に
「どういう言い方をするのが普通」というのは別に人の好みでいいの。
継承を実装の継承と実装の継承じゃないものとに分けることは無意味、
という主張については賛同者は多いのかな？そこが興味あるのね。

>>389
インタフェースだってvtableによる実装をしようと思えばできるよ。
JVMではやってないだけで。(1)各クラスについて、そのクラスが
implementsしてるインタフェースごとに別のvtableを用意する、
(2)インタフェース型の変数についてはオブジェクトの参照と
対でvtableへの参照を保持する。
0391169NGNG
>>390
ああ、そうだった。
やっぱ寝ぼけてる。とりあえず落ちるわ。
0392377=388NGNG
>>389
＞全部ってことは、わからないのと同じ状態だと思う（藁
まぁ、たしかにそうなんだが（ｗ
たとえばSmalltalkは実行時にダイナミックにクラス作ったりメッセージ定義したり出来るから、
実は、わかっているもの全部でも、充分じゃないんだよね。

型安全については、動的型付けの言語の場合、実行時にチェック出来るんだから、
保証されてるのがデフォルトとも言える。
でも、動的な型付けの言語だけど、初期化時にあるオブジェクトに束縛したら、
あとは静的な型制限のある言語の場合、この制限は型安全を指すんじゃないだろうか？
（あ、具体的にどの言語がそうだったか、忘れたけど、俺の妄想だったらごめん）

＞> で、なんで静的なダイナミックバインドと動的なダイナミックバインドを区別するか
＞> っていうと…
＞少なくとも言語設計での重要な判断の１つだとは思うけどね。
ま、言語設計の判断材料の選択肢ではあるだろうね、他を決めたら必然的に決まる場合も
あるし、これを先に決める場合もあるだろうし。

おれもそろそろ仕事する、じゃ、また。
0393377NGNG
>>390
漏れは、実装のみの継承、インターフェイスのみの継承、両方、っていうの、わけるほうがいいと思う。

導出したクラスを使うことを前提に設計されたクラス（多くの場合、インターフェイスの継承を伴なう）と
インスタンスを作って使うためのクラスで、再利用性の性質が全然違うからね。
Javaだとfinalなクラスから継承したら、再利用性もクソもあるか、つーよーな話、戦場スレには
なんども出てきたし（ｗ
0394デフォルトの名無しさんNGNG
>>393
まあ継承をさらに分類することは無意味だと思う人には放置しといて
頂くとして。強い型の言語の場合、継承の「機能」を分類すると
(A)実装の継承
(B)インタフェースの継承
(B1)新しいインタフェース定義に際してインタフェースを継承
(B2)クラスを作る(実装を与える)ためにインタフェースを継承
こう分類できると思うのね。で、自分的には(B1)と(B2)は区別したい
気分なわけ(さらに好みを言わせてもらえば(B2)は継承と呼びたくない…
単なる好みなんでそれ以上突っ込まれても困るけど)。もちろん実際の
言語ではこれらが混ざっている…たとえば純粋な(A)だけで(B)を伴わない
ということはC++やJavaではできないよね。

ところでJavaではfinalなクラスはサブクラス作れないけど、どういう
議論だったわけ？>>戦場スレ。まあ読みに行ってもいいんだけど…


0395393NGNG
>>394
Javaだとfinalなクラス　→　Javaなら当然final指定するようなクラス（を継承を禁止できない言語で）
ということで、表現がへんでした、訂正さしてくらさい。

＞たとえば純粋な(A)だけで(B)を伴わない
＞ということはC++やJavaではできないよね。
C++でもJavaでもいいから、委譲をシンタックスでサポートして欲しいなぁと思ったり、忘れたり…

＞強い型の言語
用語の話でなんですが、reinterpret_castのあるC++は、型安全を破れるので、
「強い型」と言わないっていうのがあるので、静的な型って言いません？
参照↓のp8
http://www.graco.c.u-tokyo.ac.jp/~igarashi/class/fp/chap2.pdf

あ、本題については、もうすこし考えます。
0396デフォルトの名無しさんNGNG
>>395
型安全を破れるかどうかで「強い」と「静的」を使い分ける
というのははじめて聞きました。勉強になります。ただOOPL
の場合動的束縛があるということは型の一部分は実行時に定
まるので「静的」という言葉にちょっと抵抗がありますね。
これも気分の問題。

0397395NGNG
>>396
C++とJavaの型システムを考えた場合、C++：静的で弱い　Java：静的で強い、ってことですけど、伝わってました？

0398デフォルトの名無しさんNGNG
>>381
A: 神なんか本当にいるのか？
B: いることを信じろ。信じなければ一生わからん。

というやり取りと同じように見えた。
0399JavaさんNGNG
public class mona {
　private Object ore, omae;

　mona(Object ore, Object omae) {
　　this.ore = ore;
　　this.omae = omae;
　}

　public String toString() {
　　if (ore.equals(omae)) {
　　　return "omaemona-";
　　} else {
　　　return "omaegana-";
　　}
　}
}
0400デフォルトの名無しさんNGNG
>>397
ああ、なるほどね。ただstrongly typedという用語の
一般的な定義とちょっと違うと思うけど。いや、別にだから
駄目というつもりはないです。strongly typedで検索とか
してみました？
0401381NGNG
>>398

それで？
「OOの存在は証明されていない」とでも言いたいのか？
ageてまで書くことか？
0402397NGNG
>>400
＜検索
statically typedと同じ意味で使ってるのがいっぱい出てくるんですよね（ｗ
ただ、statically typedとstrongly typedの両方を説明してるページは少ない感じです。

両方出てくるオブジェクト指向ＦＡＱでは、strongly typedはMLの説明で出てくるんですけど、
そのほかはstatic typing って表記されていて、はっきりわけてあるみたいです。
0403デフォルトの名無しさんNGNG
>>402
だからオブジェクト指向FAQをやっている人の陰謀(w では？
型安全についてはtype safeという昔からの用語があるのに
わざわざこれまでと別の意味でstrongly typedという用語を
使わせようっていうのはいかがなものか(w でもそういう流派
があることは了解しました。

ところでPascalみたいに右辺値(変数)の型と左辺値(値)の型
が厳密に一致している言語とOOPLみたいにsubtype関係にあれば
自由に入れてよい(その範囲で型が動的に変化し得る)とを区別
したい場合はどう呼び分けるべきなのかな。

0404402NGNG
>>403
静的な束縛と、静的な動的束縛（ｗ
0405デフォルトの名無しさんNGNG
陰謀というなら、関数型言語方面の陰謀かも。
0406169NGNG
>>403
inclusion polymorphismの有無

あと、OOPLでの型安全には
オブジェクトアロケーションの安全性と
メッセージ送信の安全性の２種類があると思う。
0407デフォルトの名無しさんNGNG
>>406
いやまあ、それはいいんだけどその用語ってオブジェクト指向に
偏しているような気もするわけで。Pascalをさしていきなり
「inclusion polymorphismのないstatically typedな言語です」
と紹介しないだろうと思う…

なに、OOPLの型安全性はその2種類に排他的に分類されるって？
それ面白いね、ぜひもっと詳しく聞かせてよ。それ以外にナイ
っていうところがよくわからない。


0408398NGNG
いやあ。
「概念を教えれ」スレなのに、「やらないとわからない」ってのは
無意味な回答だと思ったからさ。
0409召還師NGNG
継承に関する議論、おおいに興味ある。
僕は今まで継承とは血縁関係みたいなもんだと思ってたんだけど、
（「人間関係のうち血縁関係のみDNAから確定される関係で
　他の人間関係はすべて後付けで意味が決まる」という意味で…）
>>307で教えられたEmeraldでの継承のようなクローン人間が出てきて、
その考え方も揺るぎ始めている。
今の僕には継承を定義することなど無理だ。
よって、Emerald検索の際見つけたページを挙げることによって
具体例でもって微力ながら議論に加わらせていただきたい。
http://a414s1.it.nanzan-u.ac.jp/seminar/tobj/tobj3/node1.html
0410169NGNG
>>407
別に俺は排他的に分類されるとも他にはないとも言っていないが。

ちなみにinclusion polymorphismはオブジェクト指向に限ったことではなくて
AdaやModula-2、Modula-3なんかにも取り入れられている概念だが。
例えば[0..2]とIntegerね。
0411デフォルトの名無しさんNGNG
>>410
排他的でないとしても「特徴的な2点」なわけ？その2つの名前を挙げた
だけではよくわかんないな。いやまあ、気が向いたらぜひ語ってください。

なるほど、そうするとPascalの[1..10]と[1..100]なんかもinclusion
polymorphismがあることになるの？だとするともともとの問題に戻って
PascalとJavaの違いは何の違いということで特徴づければよいの？

>>409
どっちかというとプロトタイプベースが目新しかったですかー(w

0412デフォルトの名無しさんNGNG
>>113
想像するとこんな誤解をしていると思われるが

オブジェクト指向言語 : Java, C++ など
関数型言語 : C など

とりあえずScheme,lispあたりでgoogleに突撃してみよう。
0413380NGNG
>>381 >>398
レスありがと
一人仕事が多いから気になってた。確かに実際に体験しないと
有り難みはわからんのかも。OOも神様も。
0414デフォルトの名無しさんNGNG
>>413
一人仕事でも十分役には立ってるけどな。
それ以前では把握しきれなかったような規模のコードを一人で設計して、書いて、メンテできてるし。

もっとも、実装面ではカプセル化というよりはコンポーネント化によってI/Fがすっきりできることと
generic programmingやtemplateによるコードの圧縮の功績が大きいけどね。
0415380NGNG
>414

>もっとも、実装面ではカプセル化というよりはコンポーネント化によってI/Fがすっきりできることと
> generic programmingやtemplateによるコードの圧縮の功績が大きいけどね。

俺もこの恩恵は受けている。ただもし人いっぱいだったらとか考えたら
もう少し有り難みが増すかな？と思ったりする。
そのうち複数人の仕事もやらざるを得ないだろうからそのときまで待ってみます。
0416414NGNG
>>415
スレ違いだけど複数人の仕事の話。

現在は複数人の仕事中心だけど、OO的な設計や仕様を他人には
押しつけないようにしている。
全体の仕様を細かく分断していって、個々の機能間は旧来の設計で
済ましているわけね。

実装面の話しになっちゃうけどJavaをまったく使わないようにしてるんで
そういう分け方をしてても、それぞれのモジュール間の連携がうまくとれてるし、
別にOOわからん人がいたって問題は発生していない。

だから、多人数でのプロジェクトでも、こいつはOOがどのくらい分かってる
のかとかも気にしないし、説明する気もない。

あくまで自分の最良でやる部分を、OOが一番よければOOで、そうでないのは
そうでないので、さくっと作って、統合して、メンテしてる。

ここでね、なんか、システムをね、JavaでOOでEEでBeansで、とかってやってるとね、
結局全員Javaが分かっていないといけなくて、全員がOOをそれなりに分かってないと
いけなくて、なんかちぐはぐなシステムができちゃうことが多いのよ。

だからね、複数人の仕事やるのもいいけどね、OOベースの言語でやろうかな、
なんて、まだ考えない方がいいかもよ。

いや、スレ違いなんだけどね。
0417デフォルトの名無しさんNGNG
少なくとも、モジュール間のインターフェイスくらいは、ＯＯ的な設計して欲しいナリね。
それから、ＯＯＰＬでやらないと、わかってる人がなんか不自由になるからいや。
漏れ的には、ぼちぼち説明しながらプロジェクト進めて、終わったときになんとなく底上げが
出来てるとええなぁ、くらいは思う。

ひねもすのたりのたりかな。
0418デフォルトの名無しさんNGNG
モジュール間インタフェイスはOO的、ってのは同意。
OOをわかってる奴がOOPLを使えない問題は、OOわかってない奴が
OOPL使う問題よりも小さいから、二択ならOOPL使わないほうを選ぶ。
OOPLじゃなくてもOO使う奴は使うんだから。
0419417NGNG
＞OOわかってない奴がOOPL使う問題
これがよくわからんのだ。
たとえばどんな問題？
こういうのって、たいがい、OOPLであるがゆえの問題じゃないんだよね。

ＯＯわかってないやつがOOPL使って問題になるような場合って、
OOPLでなくても同じ様な問題でるだろうし、だいたい、今時、
OOPLでない言語って、選択肢少なくて困らない？
0420デフォルトの名無しさんNGNG
オブジェクトとしての切り分けがおかしいとか。
当然そういう奴がOOPL以外を使った場合も悲惨にはなるんだが、
OOPL使われるよりはマシ、ってのが今までの経験則。
0421417NGNG
「たとえば」って聞いたんだが…
ヤレヤレ、結局戦場スレと同じか…

オブジェクトの切り分けながおかしいとかって、抽象的すぎて話になんないな。
モジュールの中に詰め込まれたコードのローカルな事が、表に影響を与える
ような設計すな。
ちか、クソなモジュールが出来てきたら、わかってるやつなら、自前でラッパー
書くとかするだろ。

OOPLはOOがわかってなくても、OOPLの特徴的な機能、カプセル化とか、
情報隠蔽とかを使うだけでも、意味があるんだが…

元凶は>>420みたいなのが、開発言語の制定をする立場にある、って事に
尽きるようだ。
0422421NGNG
タイプミスが多いな、おれも炒ってよしだな…
0423420NGNG
>>421
貴方はいい人たちと仕事してるんだな、と思うよ。
0424420NGNG
>>423
なんか煽りっぽい口調になっちゃったけど本音ですスマソ
0425421NGNG
＞いい人たちと仕事してるんだな、と思うよ
違う。
おれはドキュソばかりのプロジェクトも動かした。
その経験で言っている。
「OOPLであるがゆえに失敗した」とされるプロジェクトは、
たいては、その言語に不慣れなメンバーばかりで、
失敗の原因が「自分達が不慣れ」なのが原因でなくて、
「OOPLはリスクが高い」ような結論を出してしまう場合や、
OOPLに過大な期待をしたような場合だ。

OOPLを採用するまでも無く、うまくいっているプロジェクト
にOOPLを持ちこむ必要は無いし、OOPLを採用して失敗
したプロジェクトを、もとの環境に戻すことも否定はしない。
当然、経験の少ないものを使うリスクはある。

けど、それは「OOPLであるがゆえ」の失敗では無い。

0426デフォルトの名無しさんNGNG
>>421
「アンチパターン」にいろいろと紹介されているね．
例えば
"The Blob" "Ambiguous Viewpoint" "Functional Decomposition"
なんかそうじゃない？

一応参考
http://www.antipatterns.com/dev_cat.htm
0427３８０NGNG
私の発言からおかしくなったみたいですね。すみません。
すれちがいなんで複数人話はこの辺でおしまいで。
0428デフォルトの名無しさんNGNG
age
0429デフォルトの名無しさんNGNG
もう一度、整理してみたいんだけど
オブジェクト指向の概念って何?

一般的に、必須の概念として、
　「カプセル化(含、情報隠蔽)」「継承」「多態」
とか言われることが多いけど、どうなのかな？

っていうか、何があるとオブジェクト指向といえて、
何がないとオブジェクト指向といえないのですか？
0430デフォルトの名無しさんNGNG
先ず、文章を整理します。>429

>オブジェクト指向の概念って何?
>一般的に、必須の概念として、
>「カプセル化(含、情報隠蔽)」「継承」「多態」
概念を説明するのに、必須概念で説明するのはどうでしょうか。

>っていうか、何があるとオブジェクト指向といえて、何がないとオブジェクト指向といえないのですか？
これは概念じゃなくて、定義じゃないでしょうか。
オブジェクト指向だけで定義というは難しいと思います。
オブジェクト指向分析の定義、OOPの定義、クラスベースOOPの定義、位に狭めないと。
0431デフォルトの名無しさんNGNG
ほんとに知りたいんなら本買って読め。
ここで概念を学ぶにはノイズが大きすぎる。
0432デフォルトの名無しさんNGNG
オブジェクト指向の概念は、君の心の中に…
0433デフォルトの名無しさんNGNG
結局、オブジェクト指向って、範囲が広すぎるから、一言で言うのは無理だしょ。
つか、そもそも概念っつーのは、具定例やたとえ話をしながら、相手の中に形成していくもんだし。
0434デフォルトの名無しさんNGNG
オブジェクト指向とは、「ソフトウェアが扱う対象を
それぞれが固有の性質やふるまいを持った『もの(オブ
ジェクト)』の集まりとして捉える考え方(パラダイム)」。

それ以上でも以下でもない。継承も多態も隠蔽も並行性
もどれ1つとして必須というわけではない(その概念なし
にオブジェクト指向プログラミングすることはあり得る。
0435デフォルトの名無しさんNGNG
OOスレって必ず↑みたいに間違ってはいないが
読み手を混乱させような、まるっきり無価値なレス
付ける奴が出てくるよな。いったいなに考えてんだ？
0436デフォルトの名無しさんNGNG
間違ってないならいいじゃん。分かりやすくて間違っている
方がずっと問題～。
0437デフォルトの名無しさんNGNG
>>434
OOで多態は必須だけど
0438デフォルトの名無しさんNGNG
てことは、434は害あり。
0439デフォルトの名無しさんNGNG
>間違ってないならいいじゃん。
よかないよ。

>継承も多態も隠蔽も並行性もどれ1つとして必須というわけではない
この必須でないケースってのはかなり特殊で
（434がこの環境でまともな開発を行っているとはとても思えない）、
大半の手続き型をベースにしたOOPL（Java, C++など)
を使う開発者にとっては間違いかつ有害。
0440デフォルトの名無しさんNGNG
「オブジェクト指向言語」だったらまあないと役に立たないだろう。
でもオブジェクト指向設計して、あるシステムを作ったら多態は
使われている個所がなかった、なんていうのは別に珍しくもない。
「オブジェクト指向言語」の定義の話ならまた別に考えるでしょ？
0441デフォルトの名無しさんNGNG
定義の話をしているのか？教育の話をしているのか？教育の話
ならおりるよ。

0442デフォルトの名無しさんNGNG
>440-441
>定義の話をしているのか？教育の話をしているのか？
両方だよ。

>あるシステムを作ったら多態は使われている個所がなかった、
結果として使わなかったと必須ではないはまったく別物だろ。
0443デフォルトの名無しさんNGNG
「使わないことがある」なら「必須」じゃないだろ。言葉の定義
ってそういうもんじゃないのか。
0444デフォルトの名無しさんNGNG
>>439
概念はメタ。
個々の言語はそのインスタンス。
分けて考えよう。
0445デフォルトの名無しさんNGNG
かなり間抜けだと思うんだけどネタふり。

OOという基底クラスがあるとしてだね、
どのようなアトリビュートとメソッドが考えられるか、
マターリと、たとえ話でもいいから、語ってクレー。

0446デフォルトの名無しさんNGNG
>>445
「メッセージ送信記法」なんてどお。
単に「オブジェクト.メソッド名(引数…)」っていう順番で書くこと
なんだけど。「メソッド名(オブジェクト, 引数…)」と同じだと言われ
てもこれだけでだいぶ気分が違う。
0447デフォルトの名無しさんNGNG
確かに、構造化言語的な記法だと、主語がCPUで、
目的語に初めてオブジェクトがでてくるね。

なんか、んー、今更って感じだが。
0448デフォルトの名無しさんNGNG
>でもオブジェクト指向設計して、あるシステムを作ったら多態は
>使われている個所がなかった
それはオブジェクト思考設計から不要だったという事では？
0449デフォルトの名無しさんNGNG
設計手法の選択はどうやってやりましょうか・・・
0450デフォルトの名無しさんNGNG
>>448
多態が使われる箇所が存在するか否かでオブジェクト
指向設計の適用の適否が決まると本気で思ってるの？
そういう箇所が1箇所あったとして、そこがシステムの
変更で削除されたら、それだけでオブジェクト指向設計
が不要なシステムに変化するの？興味深い意見だ。

自分は、多態が不要だとか言ってるわけじゃない。逆に
オブジェクト指向やる人が多態を知らないとか使いこな
せないとかじゃ困るし、言語も多態をサポートしてないと
不便だと思うよ。ただ、多態がなかったら絶対にオブジェ
クト指向じゃないとかそういう考えは教条主義的で自分の
好みではないというだけ。絶対にナニナニだなんて言う
固執した考え方に対しては必ずそれがあてはまらない場面
が登場してくると思うのね。マーフィーの法則っていうか。

0451デフォルトの名無しさんNGNG
分岐しそうな個所をインターフェースで置き換える。
これを行わないならOOじゃない。
これを行うなら､多態が必要。
以上。

hello worldにOOは不要だし。
0452デフォルトの名無しさんNGNG
>>451
だからさ、オブジェクト指向設計して実装はOOPLじゃない
場合もあるわけよ。OOPLであるにしても、実際に多態が必要
になるまで決め打ちに選択するかも知れない。性能とかで。

そういうのも認めない、インタフェースが使ってないもの
は他が何であれ断じてオブジェクト指向じゃない、そういう
ご主張なのね。やれやれだな。

そうそう、Boochさんの本だったかな、温室の温度制御とか
の小さい例題。ああいうのもオブジェクト指向な分解と設計
としていいじゃん。色々つけていけばそりゃ多態が欲しくなる
けど、だからといって最初の小さいものがオブジェクト指向じゃ
ないとは言えないと思うのね。hello worldだって仕様によって
はオブジェクト指向で設計したいかもよ。
0453デフォルトの名無しさんNGNG
>452
そうするに高度な柔軟性を維持しつつ何でもありって言いたいんだろ。
お前の言ってること何の役にも立って根蝦夷。
0454デフォルトの名無しさんNGNG
>>452
わかりやすく説明してやると、
javaのクラスライブラリーのクラスが
java.lang.Objectを継承している事のメリットが
わからん奴には、たぶんOO云々いってもわからん。
で、objectを継承してるという事で多態必須。

>インタフェースが使ってないもの
javaのインターフェースじゃないよ。

>Boochさんの本だったかな
何それ？
有名なのか？
一般人にとっては、
そんな不適切な例をあげられても意味ない、なんて事はないよな？

>温室の温度制御とかの小さい例題。
ooで設計するなら、温度計クラスのインターフェースを抜き出して
それを継承（あるいはインプリメント）したクラスを作るな。
という事で、多態は必須。
0455デフォルトの名無しさんNGNG
452のc++のコードにvirtualはない
0456 NGNG
C++でバーチャル使った事無い奴、正直にC++暦を言え。
0457デフォルトの名無しさんNGNG
５年
0458デフォルトの名無しさんNGNG
一生懸命、無駄な事。

import java.io.*;

abstract class ConsoleWriter{
　protected PrintWriter impl;
　public ConsoleWriter(){impl = System.out;}
abstract public void writeObject(Object o);
}
class StringConsoleWriter extends ConsoleWriter{
　public StringConsoleWriter(){super();}
　public void writeObject(Object o){impl.println((o!=null)?o.toString():"null");}
}

public class HelloWorld{
　ConsoleWriter writer;
　public HelloWorld(){writer = new StringConsoleWriter();}
　public void sayHello(){writer.writeObject("Hello World!");}

　public static void main(String args[]){
　　HelloWorld obj = new HelloWorld();
　　obj.sayHello();
　}
}
0459デフォルトの名無しさんNGNG
ねえ、無理矢理使えばどこだって多態使えるんだよ。それで
反論になってると思うなら勝手にやってれば。そこまでして
必須だと思いたいのかねえ。

ちなみに自分がC++を始めて書いた時はvirtualと書かないと
動的にならないことに驚愕して全部virtualをつけまくって
いました。10年くらい前かな。それも問題ありだよねー。
0460デフォルトの名無しさんNGNG
なんだロートルか。
もう潮時だよ。
ゆっくり休めよ。
0461デフォルトの名無しさんNGNG
そだね、じゃ落ちるわ。
0462デフォルトの名無しさんNGNG
Cでオブジェクトライクな処理が行えると聞きますが具体的にはどのようなものでしょうか？
H8マイコンのソフトをオブジェクト指向っぽく書いてみたいのですが。
0463デフォルトの名無しさんNGNG
>>462
たとえば、GTKとか。
0464デフォルトの名無しさんNGNG
>>462
ここをすべて読めば何かが見えてくるだろう。
http://pc.2ch.net/test/read.cgi/tech/1009177280/
0465デフォルトの名無しさんNGNG
>>463
軽く勉強してみました。

window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);

なかなかオブジェクト指向って感じですな。
ありがとうございました。

Ｐ．Ｓ．
軽く調べたらgccのC++が使えるみたいなので使うことにします。
お騒がせしました。
0466デフォルトの名無しさんNGNG
>ねえ、無理矢理使えばどこだって多態使えるんだよ。
アフォ？

458が無駄じゃない事を示すと
writer = new StringConsoleWriter();
ここをファクトリーメソッドにしておけば、
例えばネットワークを超えてコンソールに書き込む処理に
「簡単」に変えることもできる。
この場合の「簡単」がどういう意味かはわかるよね？
if/elseが多態で処理される事によって、保守管理が楽になる。
よって､多態は必須。

ところで
>動的にならないことに驚愕して全部virtualをつけまくって
10年前はsmalltalkでもやってたわけ？
0467デフォルトの名無しさんNGNG
>>459 >>466
なにを問題としているか不明です。
意見の異なる点を洗い出してから話してください。

こんな話では何時までたっても結論は出ません。
２人ともなにやってんだか？
プログラマーとは思えない。
0468デフォルトの名無しさんNGNG
>>467
冷静な第三者的意見は sage で頼む。
0469デフォルトの名無しさんNGNG
459は幼少のころ三匹のvirtualに性的暴行を
受けてそれがトラウマになってんだろ。
0470デフォルトの名無しさんNGNG
>>394
> (B1)新しいインタフェース定義に際してインタフェースを継承
> (B2)クラスを作る(実装を与える)ためにインタフェースを継承
俺は

B1 はインターフェースを拡張
B2 はインターフェースを実装

と言ってるけどな。UML でもインターフェースの実装には、別の記号が用意
されてるよね。
0471貼っとくNGNG
>>72
オブジェクト指向の基礎は、「オブジェクトというものを最も基本的なものとして考える」
ということだろ？
オブジェクト指向プログラミング言語にとってのオブジェクトとは
「データ＋プログラム」だ。どこが難しいんだ？
繰り返し書いているが、基本が簡単だかからといって、そこから派生するもの
実際に利用しているまで、全てが簡単だなんて言うつもりはないし、漏れもそう思う。
基本と応用の間を繋ぐ物 複雑な現実の中から、どうシンプルな本質を
見つけか？という問題に対して答えに近いと思うHPを引用したつもりだ。

72さんの言う意味も判るが、それは応用（実際に役に立っているもの）しか
見ていないように思う。
じゃあ、逆に72さんに聞くがオブジェクト指向のどこが難しいのでしょうか？
消防な漏れに教えてください。

http://pc.2ch.net/test/read.cgi/tech/1016462874/100　より。
0472デフォルトの名無しさんNGNG
「俺が教えてやる」
「分かりやすく説明してやる」
などと勘違いした痛い奴が居るスレがここですか…
0473デフォルトの名無しさんNGNG
はい、ここです。
0474デフォルトの名無しさんNGNG
とりあえず

>>452
> OOPLであるにしても、実際に多態が必要
> になるまで決め打ちに選択するかも知れない。性能とかで。

「仕様変更を考慮しない場合もあるよ」
といっているのに対し

>>466
> 例えばネットワークを超えてコンソールに書き込む処理に
> 「簡単」に変えることもできる。

「仕様変更するかもしれん」といっているのは変だと思うぞ。
0475デフォルトの名無しさんNGNG
>「仕様変更を考慮しない場合もあるよ」
これはOO不要ですね、はい。
0476474NGNG
で、 >>449 に戻ると。
すまん。 >>450 見落としてた。ｲｯﾃｸﾙﾖ
0477デフォルトの名無しさんNGNG
単純な質問ですが、オブジェクト指向データベースを適用する場合、正規化は必要ないのですか？

通常のオラクルなどのテーブルを設計する場合、DOAで分析しデータを正規化するとER図を作りますが、オブジェクト指向のデータベースを適用する場合は、データの正規化は必要ないのでしょうか？

http://home.highway.ne.jp/kogure/jugyo/webtext/oodb/index.html
0478４７７NGNG
あと生産性だけを追求すれば、オラクルなどのRDBとオブジェクト指向言語を組み合わせるよりも、ＯＯＤＢとオブジェクト指向言語を組み合わせした方が、生産性的には向上するのでしょうか？
0479　NGNG
よくわからんがoracle以外を仕事で使うなんて恐ろしいことは出来ません。
0480デフォルトの名無しさんNGNG
>>477
ひとことで言えば、オブジェクトをそのまま格納するのがOODBですから、
正規化の必要はありません。

>>478
RDBとオブジェクト指向で開発すると、RDBに格納したデータをオブジェクトに入れる、
またはオブジェクトをRDBに格納する形に変換する必要があります（インピーダンス
ミスマッチ、でしたっけ？）。

このため、RDB＋OOPLでは、やらなくてはいけないことが増え、生産性は、
OODB＋OOPLより低くなると思います。
0481デフォルトの名無しさんNGNG
>>479
ホスト相手のときはどうするんですか？
0482デフォルトの名無しさんNGNG
>>480 RDB+OOPL でも OO使わなければ　いいんだよ
0483４７７NGNG
>>480　>>482
サンキューです。　ＤＯＡやＲＤＢにこだわらなければ、ＯＯＤＢにしちゃった方が良さそうですね。　まあ新しい事だけに、色々問題は有ると思いますが。　
0484デフォルトの名無しさんNGNG
>>454
SmalltalkのクラスライブラリのIntegerが
Objectを継承している事のメリットが
わからん奴には、たぶんOO云々いってもわからん、
と言ってみるテスト(藁
0485デフォルトの名無しさんNGNG
JavaやC#のようにプリミティブ型と
オブジェクトでラッピングしてもの両方ある
というのが最もよいのかな。どうかな。
誰かに聞いてみよう。
0486デフォルトの名無しさんNGNG
>>485
「全てがオブジェクト」っつーのがシンプルで一番
よいのでわ？　プリミティブ型って処理効率を上げる
ためだけに存在するんじゃないかと思う。
0487デフォルトの名無しさんNGNG
良い悪いを言うときには、評価尺度を明記しないと無意味だぞ。
0488デフォルトの名無しさんNGNG
プリミティブ型がない場合、演算子の再定義の機能がないと、
一貫性が保てないというのはあってる？
0489デフォルトの名無しさんNGNG
>>487
禿同

ついでにいうと、その尺度の妥当性、というか
どういうシチュエーションで意味がある尺度なのか、
という点についても簡単に言及してあるのが望ましい。

物差しの当て方によって、さまざまな結論を導くこと
ができるが、なかには無意味な「当て方」もある。
机上の空論ってのあることだし。
0490デフォルトの名無しさんNGNG
正直にいって「全てがオブジェクト」というのは人間の頭に優しい構
文糖以上の意味はないと思う。
「全てがオブジェクト」にみえる言語でも実際は、インラインで展開して
速度面での効率を追求するような実装をしているものもある。
レイトバインドのコストを理解していればバカ正直に「全部オブジェクト」
にするのは効率的にはムダ以外の何ものでもないことはわかると思う。
JavaやC#がプリミティブを捨てなかった理由もそこにあると思うし、
>>485が言っているようにオブジェクトでラップしたクラスと両方あれば
統一的な取り扱いの面でも問題はないはず。
0491ロボ鉄 ◆MGTy6iYI NGNG
っていうかオブジェクト指向って何ですか
0492デフォルトの名無しさんNGNG
>>490
>JavaやC#がプリミティブを捨てなかった

C#は微妙なところだな。
BoxingはSyntax Sugarという点では「全てオブジェクト」の上を行ってるよ。
0493デフォルトの名無しさんNGNG
よくわかんないんだけど、言語のインプリの話をしてるの？
言語が提供しているプログラミングモデルの話をしてるの？
プログラミングモデルが人間に優しくて実装が高速なら一番
いいわけだけど…
0494デフォルトの名無しさんNGNG
>プログラミングモデルが人間に優しくて実装が高速なら一番いいわけだけど…
プログラミングモデルの話でしょ？
しかし実装もおろそかにしちゃんらん訳で「両方」

C#のBoxing unBoxingはいい感じ
0495デフォルトの名無しさんNGNG
とはいえSmalltalkのSmallIntegerとLargeIntegerのシームレスな互換性に比べると
boxing/unboxingだけでは不十分なのでは？
1 * 10000の結果と1000000 * 100000000000000の結果を全く同じように扱うことができるのは
Integerがオブジェクトであることの恩恵だよね。

primitive typeで同じ事をしようとすると
1. intをIntegerのsubtypeにする。
2. 四則演算などを全てLargeIntegerも扱えるようにoverloadする。
3. overloadはコンパイル時ではなく実行時に解決する。
ってな事が必要になる。
これならintもオブジェクトにしたほうがスッキリする。
0496デフォルトの名無しさんNGNG
>>495

だからSmalltalkは原理主義だって言われるんだよ。
そんなどでかい数値なんかたまにしか使わねーのにパフォーマンス犠牲にしてまで
実装する理由がわからん。YAGNI!
0497デフォルトの名無しさんNGNG
>>495
プログラマがすっきりした気分になったとしても、
実行性能がでなければ捨てられるだけナリヨ。
オブジェクト「しか」選択肢がないより、プログラマ側に選択の
余地があるほうが好ましいなり。
プログラマがすっきりする言語が性能も一番なんだったら、Cのかわりに
Lispが天下をとっておったことじゃろーて。
0498デフォルトの名無しさんNGNG
boxing/unboxing
って何に使うの？
0499デフォルトの名無しさんNGNG
>>496
ではJavaやC#に比べてどれぐらいのパフォーマンスが犠牲になるのか示してみそ。
C#はともかくJavaについてはどのみちバイトコードのオーバーヘッドのほうが大きいよな。

>>497
プププ。
いまだにオブジェクト「しか」選択肢がないと思ってる 化石君ですか？
実行性能を要求される部分はユーザプリミティブにすればいいだけだよ。
例えばSqueakならSmalltalkで書いたコードをCに変換してくれて、
あとはそれをコンパイルすればユーザプリミティブとして利用できるよ。

何でこうSmalltalkへの批判はどれも時代遅れなんだろう (藁
0500デフォルトの名無しさんNGNG
痛い499がいるスレ
0501デフォルトの名無しさんNGNG
内容はともかく書き方が痛いな。舞い上がってる感じ。
0502デフォルトの名無しさんNGNG
>>498
無意味。

>>499
Ｃコンパイラが別途必要だね。
同時性も無くなるし。
0503デフォルトの名無しさんNGNG
>>495
JavaでIntger互換な多倍長整数(LargeInteger)を作ればいいんじゃない？
というか、もうそういうの在るし。

>>498
http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_005/csharp_abc03.html
これぐらいのこと、調べてくれ。

>>502
SmalltalkVMを拡張すること
ユーザ定義のオブジェクトということだ。
でも同時性ってなに？
0504デフォルトの名無しさんNGNG
>>503
そうすると今度はint使ってる部分とInteger使ってる部分とのインターフェースが問題になる。
いちいち変換して渡す?

つーか、オブジェクトとしてのIntegerを否定する人達って
自動ガベージコレクタをどう思ってるんだろうな。
Javaは自動ガベージコレクタ「しか」使えないとか批判するんだろうな。

配列の範囲チェックなんかも
自動範囲チェック「しか」使えないとか批判するんだろうな。
ま、セキュリティホールを量産してなさい、ってこった。
0505デフォルトの名無しさんNGNG
>>498
そんなことも知らないのかよ。
boxingをカタカナで書いてみな。
「ボクシング」
そうだ、それだよ。
四角いリングのなかで男たちが熱く殴り合うアレだよ。

でだな。
英語では単語の前にunが付くと
「逆の～」とか「不～」とか「～の欠如」とか
いった言葉を作ることができるわけだ。
つまりだな、unboxingってのは、
「四角いリングのなかで男たちが熱く殴り合うアレ」が欠如している、
とか、その逆とかいった意味になるんだよ。

わかったか。
0506デフォルトの名無しさんNGNG
C C++ C# と時間をかけて Smalltalk の地平へ近づいているのだなと思うよ。

>>496
多分10年後くらいには、
「そんなどでかい数値なんかたまにしか使わねーが、
パフォーマンスに実質影響ないので」
となる。
0507503NGNG
>>504
変換すればいい。
C#ではプリミティブ型とオブジェクト型の間を簡単に変換する機能
があるから。
それが、さっきから話題になってるボクシング
それにボクシングを使わなくても簡単に出来るでしょ？
普通のプログラムでは、もっと複雑なことやってるし。

Smalltalkerのかたも勉強しようね。
時代は確実に進んでる。たぶん、きっと、けっこうね。
0508504NGNG
>>507
だからさ、いちいちboxing/unboxingするわけ？って聞いてるんだけど。
awtにintを渡すたびに毎回unboxする？
配列の添字にするたびに毎回unboxする？
GUIから渡ってきた整数を毎回boxする？
汎用ライブラリではどっちに揃える？それとも内部でbox/unboxを繰り返す？
パフォーマンスのためのプリミテイブ型が結局box/unboxの手間を頻発させたりはしないか？
0509デフォルトの名無しさんNGNG
ボクシングやアンボクシングを手動で行うぐらいなら、
Smalltalkのようにタグ付きオブジェクトポインタを使って
整数オブジェクトのコストを抑制した上で
インクリメンタルコンパイラの性能向上を図ったほうがいいと思われ。
0510デフォルトの名無しさんNGNG
静的型付けの言語と動的型付けの言語の比較って、やっぱこういう事になるんだな…
0511読まずにカキコNGNG
スタックはガベージコレクションの一種だよね。
generational scavenger一本でやってもいいと思うんだよね。
そうすれば実装上もすべてがオブジェクトでいけると思うんだ。
0512デフォルトの名無しさんNGNG
boxing/unboxingするのにプログラマがなにか書かなきゃいけないの？
0513511NGNG
あ､ちょい違う話か。ｽﾏｿ
0514511NGNG
自動化されたunboxing/boxing機構は、隠蔽されたオブジェクト型計算の最適化と
何が違うんだろうな？
0515デフォルトの名無しさんNGNG
スマートに書けるけど遅いっていうのと、
ちょっと手間がかかるけど速いっていうのと、
どっちを取るかって話みたいね。
boxingはそんな手間じゃないとは思うけど。
0516デフォルトの名無しさんNGNG
>>514
boxing/unboxingは全自動と言うわけではないのでは？
0517デフォルトの名無しさんNGNG
（C#とSmalltalk両方解かってるやつはいないっていう結論だね）
0518デフォルトの名無しさんNGNG
とりあえず、boxingが手間だって言ってる奴らはアフォという結論。
0519デフォルトの名無しさんNGNG
手間ではないには同意だけど、わかってないとはまる落とし穴が沢山ありそう…
0520504NGNG
なんか誤解されてるみたいだけど、
(Integer)とか書くのが手間だと言っているんじゃなくて、
boxingに伴なう変換操作に手間がかかるということ。
1回1回の変換操作は大したことなくても
頻発するとかなりの手間になる。
indexとして使ったり、GUIとのやりとりに使ったりね。

あと、整数がオブジェクトだと遅いといってる人達には
VMの速度に対してどれぐらいのオーバーヘッドになっているのか
示してもらいたいものだ。
0521デフォルトの名無しさんNGNG
やっぱりboxingが解ってない504なのでした。
ばーかばーか
0522デフォルトの名無しさんNGNG
>>あと、整数がオブジェクトだと遅いといってる人達には
ｱﾌｫっすか？どう考えたって遅いだろ？
0523デフォルトの名無しさんNGNG
>>521
http://www.c-sharpcorner.com/Language/BoxNUnBoxGAG.asp
読んでみたが、504の言ってることがどう間違ってるのかサパリワカラーン。
上記URLより
> Boxing a value of a value-type consists of allocating an object instance and copying the value-type value into that instance.
パフォーマンス的にはどう考えても頻発させたくない操作だと思うが。
一方、SmalltalkのSmallIntegerはメモリアロケーションを伴わない分
効率的だと思うが、どうよ？
0524デフォルトの名無しさんNGNG
四則計算あたりについても議論して欲しいなー
0525デフォルトの名無しさんNGNG
>>520
＞VMの速度に対してどれぐらいのオーバーヘッドになっているのか
＞示してもらいたいものだ。
問題の範囲をずいぶん狭くしたもんだ。
0526デフォルトの名無しさんNGNG
C#やJavaではプリミティブ型とオブジェクトの整数が
両方あるから便利でいいじゃない？

普段はオブジェクトでラップされた整数つかって
肝の部分でプリミティブ型の整数をつかえばいヨシ

これだとboxing,unboxingする回数少ないでしょ？
0527デフォルトの名無しさんNGNG
>>526
>普段はオブジェクトでラップされた整数つかって
>肝の部分でプリミティブ型の整数をつかえばいヨシ

むちゃくちゃ言うなあ。

足し算もできないようなのを「普段」使うのか?

肝の部分、って、これじゃいつも肝じゃん。
0528デフォルトの名無しさんNGNG
>>525
JavaがVMを前提にしている以上、
VMも含めた全体の性能にどれだけの影響があるかを問題にするのは
とても自然だと思うのだが、どうよ？
それとも君は車の性能を計るのに
燃料ポンプの性能で最高速度を計算するタイプ？

>>526
両方あると混乱するだけだな。
相互に変換して使おうとしたら、
大きい数はintのサイズに限定されるし
パフォーマンスはボトルネックになっている側が支配的になる。
あんまりいい事ないんだよね。
0529デフォルトの名無しさんNGNG
>>528
boxing, unboxing といってるから、てっきり native code 混在の話をしてると
思ってたんだが、いつのまにか JavaVM 限定の話になってたのか？
0530528NGNG
>>529
boxing/unboxing自体は関数型言語の処理系なんかでも使われてる技術だから
そもそもOOにすら限定されないな。
このスレでは>>499の流れからJava限定で書いている。
0531デフォルトの名無しさんNGNG
>>530
たとえば Java (JIT enabled) な状況で

- Integer を使った MD5 チェックサム計算
- int を使った MD5 チェックサム計算
- JNI を使って C で書いた MD5 チェックサム計算を呼び出す

を書いて、速度を比較してみろいう話？　（面倒だから、俺は嫌だが）
0532デフォルトの名無しさんNGNG
>>527
全部が肝だと思うならそうすりゃいい。
(でも８０：２０の法則って知ってるよね。)

>>529
C#もVMだしね

>>530
というか関数型プログラミング言語が元ネタじゃなかっ竹？
0533528NGNG
>>531
端的に言えばそういうこと。
さらに言うと、MD5計算だけでなくアプリケーション全体のパフォーマンスで
比較しないとね。
例えばPGPを扱えるMTAを実装して、
1. 全部Smalltalkで
2. 全部Javaのintで
3. 全部C#のintとInteger両方を使って
4. PGPは外部ライブラリを使って
実装した場合＊メールの読み書き全体＊に与える影響を比較するとか。

「遅い」というからにはそういう基準で比較しないと意味ないでしょ。

>>532
C#ってネイティブコードへの変換みたいな事もいってなかったっけ？
あと、boxingが関数型由来というのは、俺の知る限りではその通り。
たぶんSimonとかが持ち込んだんじゃないかな。
0534デフォルトの名無しさんNGNG
すっごい教え方をしている人がいたので

「簡単に言うとな、そこだけ取り出して修正ができるっていう便利なものなわけだ」

教えられてるほうは頭に?マークが浮かんでいた。
0535デフォルトの名無しさんNGNG
OOの交換可能性は初心者にとって分かりやすい話かもね。
オブジェクト間の結合を疎にするってのは構造化プログラミングでも
ある程度は出来るけどOOPLのようにエレガントには逝かない。
0536デフォルトの名無しさんNGNG
ああいうひとは、あれだ、片方は３分で終わるもの、もう片方で３時間かかっても、
自分が月に一度しか使わなかったら、「普段の生活の中で、どのくらいの差になるか」
とかいいだしそうだな。
0537デフォルトの名無しさんNGNG
>>536
そのとおりですがなにか？
都民は無駄な物買い込めるほど家が広くないんだよ。
0538デフォルトの名無しさんNGNG
>>533
後から条件を付け加えるのは、都合が良すぎるな。

MD5 ライブラリなんかは、たとえばファイルをサーバ・クライアント間で同期
をとるときに使ったりするから、速度や使用メモリ量がきわめてクリティカル
になる場面もあるんだよ。
0539528NGNG
>>538
だからMD5計算がボトルネックになっているのなら、
その部分は速度重視な言語で書けばいいんじゃない？
>>499にもあるように、Smalltalkも今は他言語を積極的に使える時代なんだから。
俺もSqueakで3次元ポリゴン描画ルーチンをSmalltalkで書いて、
肝の部分だけCに自動変換してユーザプリミティブ化したことあるよ。

しかし、ボトルネックも特定せずに「***は遅いから使えん」などと言うのはアフォ。
80:20の法則で言えば、20のために80の部分まで危険に晒す必要はないでしょ。
20の部分は20の部分に適した言語で書けばいいだけ。
で、残りの80の部分で整数がオブジェクトである不利益がどれだけありますか？ってこと。
0540デフォルトの名無しさんNGNG
もはや、何を主張しているのかもよく分からんな。良いけど。
0541528NGNG
>>536
その月に一度の用事がどれだけ時間にシビアかによるし、
かつ、その前後のスケジュールがどれだけタイトかにもよるわな。

もし、特に問題もなく30分前に出発できるのに
無理して3分で済まそうとして交通事故にあうリスクを増加させているんなら
俺なら30分かけるほうを選択するぞ。
0542デフォルトの名無しさんNGNG
おやおや？
今度は、「自分から見て一番アホそうな書きこみが相手」に、条件後付けですか？

条件後付けは、失笑を買うだけですよ。
おもちゃにされてるの、気がつきませんか？

あと、ageんな。
0543デフォルトの名無しさんNGNG
あ～あ、今度はパフォーマンスの良いほうに無理矢理リスクがあるって事にしてるよ。

ま、良いけど。
0544デフォルトの名無しさんNGNG
>>542-543
まともな反論ができないもんだから仮定条件のアフォな誤読をご開陳ですか。
茶々入れるんならせめて>>484以降の文脈を理解してからにしたらどうですか？
ま、良いけど。
0545デフォルトの名無しさんNGNG
>>528にどう反論しろと…（失笑
0546デフォルトの名無しさんNGNG
つか、あきらかに528==544な。
0547デフォルトの名無しさんNGNG
>>544
特に >>487 と >>489 な。
0548デフォルトの名無しさんNGNG
>>542-546
折には528はごく当然な事を言っているようにしか見えないのですが。
hot spotの特定や言語の適材適所という工学的にごく常識的な事を「後付け」などと言いだすようでは
失笑を買うのはあなたのほうではないかと思いますよ。
0549デフォルトの名無しさんNGNG
>>548
たとえば、>>533と>>539を読み比べてみれ。

「hot spotの特定や言語の適材適所という工学的にごく常識的な事について論じている」っていう条件を後付けしてる、ってゆーの、わかる？
0550デフォルトの名無しさんNGNG
つーかさ、>>528は整数がオブジェクトだと遅いのは認めてるじゃん。
>>539の
＞だからMD5計算がボトルネックになっているのなら、
＞その部分は速度重視な言語で書けばいいんじゃない？
とかさ。
でも、それより整数がオブジェクトであるメリットについてなにも言ってないんだよね。

あとさ、条件を言わないで、遅いのは問題じゃないって言っておいて、
そこ突っ込まれてから、「こういう条件では問題ない」って後付けしてるから、
失笑ってことになるんだろ。
0551デフォルトの名無しさんNGNG
>>549
はあ、>>533で比較条件を例示して>>539で対処例を出しているように読めますが。
で、548が何の後付けなんでしょうか？
それを言うのなら、>>549こそ
「工学的な常識を前提にするな」という条件を後付けしているように思えるのですが。
0552デフォルトの名無しさんNGNG
>>550
528は「遅いのは問題じゃない」なんて言っていないと思いますが。
折が読んだかぎりでは、「遅い」云々は言語だけで決まるものではなく、
使用条件に依存している、という主張で一貫していると思います。

それに、どちらかというと>>538のほうが条件の後付けに見えます。
MD5チェックサムとだけ言っておいて、あとでこんな使い方もある、と
条件を付け足しています。
0553528NGNG
>>550
> つーかさ、>>528は整数がオブジェクトだと遅いのは認めてるじゃん。

どんな言語のどんな実装でも十分に速いことも遅すぎることもありますが、何か？
0554デフォルトの名無しさんNGNG
漏れは、たとえば80っていうリテラルを変数にバインドしたとき、
timesRepeat: aBlock メッセージも factorial メッセージも受け取れて、
場合によってLargeIntegerを返したりするのは、メリットだと思う。
そこから導出したクラスで、番号なのか数なのか順序なのかはっきり
させるプログラミングのしかたも、結構好き。
でも、メリットを活かせない場面も、沢山ある。

たとえば、ＭＤ５の計算がクリティカルなのがあらかじめ予想できるなら、
おれははじめから速度が活かせる言語を選ぶし、３Ｄのポリゴンの描画
なら、はじめからSmalltalkでなんか書かない。
やってみて、数値演算がボトルネックになるから、そこだけ別の言語で
書きなおす、とかするくらいなら、はじめからC++とかで書くよ。

ボトルネックの特定は、たしかに重要なんだが、実行速度の最適化は
アルゴリズムでするのが定跡だろ。
細かい反論重ねるくらいなら、相対的に遅い事をさっさと認めて、
IntegerがObjectのサブクラスであるメリットについて、話しないか？
0555538NGNG
>>552
> それに、どちらかというと>>538のほうが条件の後付けに見えます。
もちろん、あれは後付だよ。

553 が特定の条件下で問題ないでしょと発言したから、それなら逆の条件を
仮定すれば問題アリという結論も導けるから、そんな主張には意味がないと
返しただけ。

何でも良いけど、まずは前提条件をはっきりさせてくれ。
0556550=554NGNG
>>551
>>533は「遅くない」ことを主張したいがための後付けの条件なの、ミエミエじゃん。

＞「工学的な常識を前提にするな」という条件を後付けしているように思えるのですが。
そう読めますか？
>>528が工学的な常識を前提にしているように読めない、っていう意味なんですが。
「工学的な常識を前提にするな」などという主張はしてませんよ。

>>553
同じ計算をした場合、プリミティブな整数型にくらべ、Objectのサブクラス
の整数クラスのインスタンスとでは、相対的に遅いのは明らか。

でさ、あなたの考えるメリットってなに？
0557528NGNG
>>554
> たとえば、ＭＤ５の計算がクリティカルなのがあらかじめ予想できるなら、
> おれははじめから速度が活かせる言語を選ぶし、
あらかじめ予想できたら、その通りだな。俺もそうする。

> ３Ｄのポリゴンの描画
> なら、はじめからSmalltalkでなんか書かない。
それも1つのやりかただと思う。
俺の場合、穴空きポリゴンの三角形分割なんかも必要だったんで、
どこまでプリミティブ化するか決めかねていた面もある。
一度プリミティブにしちゃうと後戻りしにくくなるんで。
それで、どのみち後でCに自動変換できることもわかっていたんで、
まずは全部Smalltalkで書いてみて、実行速度を実測してみて
どの部分をプリミティブ化するか決めることにした。
この場合はSmalltalkのIntegerとCのintとの間にインピーダンスミスマッチみたいなものがあって、
ある意味整数がオブジェクトであるためのデメリットといえる。
なんて書くと、また後付けとか言われそうだが。(苦笑

0558528NGNG
>>554
整数がオブジェクトであるメリットは、俺にとっては
anInteger timesRepeat: aBlock や
anInteger factorial や
anInteger + anotherInteger が
SmallIntegerであってもLarge(Positive/Negative)Integerであっても同様な動作が期待できること。
その結果、整数を引数とするメソッドを書いた時に、そのメソッドの汎用性を高めることができる。

そのメソッドへの整数引数が毎回SmallIntegerならば、
SmallIntegerはタグ付きオブジェクトポインタとして実装されているから
整数オブジェクトのためのメモリアロケーションは発生しないし
動的束縛などの実行時のオーバーヘッドはインクリメンタルコンパイラによって軽減させることができる。

そのメソッドへの整数引数がSmallIntegerだったりLarge(Positive|Negative)Integerだったりするなら
そのメソッドの汎用性が高まるし、実行時のオーバヘッドは可変長整数とほぼ同様になる。
0559538NGNG
>>556
> でさ、あなたの考えるメリットってなに？
要はここだよね。

メリット・デメリットがはっきりすれば、あとは用途に応じて秤にかけて
適切な方を選択すればいい。
0560デフォルトの名無しさんNGNG
>>556
> >>533は「遅くない」ことを主張したいがための後付けの条件なの、ミエミエじゃん。
そうですか？まあそういう読み方もあるかもしれませんね。
どっちかというと折的には「そんなこといったら言語比較とか不可能じゃん」と思ったのですが。
0561デフォルトの名無しさんNGNG
>>559
> メリット・デメリットがはっきりすれば、あとは用途に応じて秤にかけて
> 適切な方を選択すればいい。
同意です。
0562デフォルトの名無しさんNGNG
>>558
> 整数がオブジェクトであるメリットは、
これは、最近の言語だと Generics で対応するのが流行りかも。

Generics と OO って相性良いよ。
0563554NGNG
>>557
＞＞たとえば、ＭＤ５の計算がクリティカルなのがあらかじめ予想できるなら、
プログラムの目的によって、どこがクリティカルなのか解かる場合もあるしね。

＞どこまでプリミティブ化するか決めかねていた面もある。
思考錯誤のしやすさ、というなら、かなり同意。

で、俺は思考錯誤をする時のやりやすさも含めて、プロトタイピングの効率
が優先する場面なら、１桁くらいの整数演算の効率はどーでもいいと思う。
仮に、CのintとSmalltalkのSmallIntegerの効率の差が１０倍違っても、同じ
アルゴリズムなら、いつでもほぼ１０倍なわけだしね。


そうそう、後付けといえば、「プログラムの実行性能より、プロセス起動の
性能の方がクリティカルだったら？」とかいう豪快なのもあるかも（ｗ
0564528NGNG
> メリット・デメリットがはっきりすれば、あとは用途に応じて秤にかけて
> 適切な方を選択すればいい。
そうだね。その通りだと思う。
ただし、メリット・デメリットは言語や処理系のみで決まるものじゃない、ってのは
クドすぎるかな。
0565554NGNG
>>562
＞>>558
＞> 整数がオブジェクトであるメリットは、
＞これは、最近の言語だと Generics で対応するのが流行りかも。
実行時にSmallIntegerが返って来たりLargePositiveIntegerが返って来たりするの、Generics で対応ですか？
ちょっと興味あり。
0566デフォルトの名無しさんNGNG
>>565
> 実行時にSmallIntegerが返って来たりLargePositiveIntegerが返って来たりするの、
> Generics で対応ですか？
コンパイル時に型が確定できる場合には、Generics で行ける。

>>558 で例としてあげられていた
> anInteger factorial や
> anInteger + anotherInteger
なんてのは、そうだよね。
0567528NGNG
>>562
> これは、最近の言語だと Generics で対応するのが流行りかも。
> Generics と OO って相性良いよ。
なるほど。
MLのFunctorは昔ある程度使い込んだことがあるんだけど、
正直、STLなどは不勉強であまり使ったことなかった。

例えばどんなメリットがあるのかなぁ？
関数のoverloadがほとんど必要なくなるとか？
0568デフォルトの名無しさんNGNG
>>564
> ただし、メリット・デメリットは言語や処理系のみで決まるものじゃない、
具体例を挙げるとポイント高いです。
0569554=565NGNG
＞>>566
＞>>558 で例としてあげられていた
＞> anInteger factorial や
＞> anInteger + anotherInteger
＞なんてのは、そうだよね。
これは、コンパイル時に戻り値の型、確定できないとおもうです…
0570528NGNG
>>566
えっと、>>558で書いた
anInteger + anotherIntegerは
anIntegerもanotherIntegerも
SmallIntegerだったりLarge(Positive|Negative)Integerだったり
実行時に決定するんですが、その場合はどうなんでしょう？
0571デフォルトの名無しさんNGNG
>>564
だから、それを言い出すと言語比較とかできなくなると思うのですが…
まあ、言語比較が無意味だというのならそれはそれで1つの見識ですが、
あまり広く受け入れられないと思いますよ。
0572デフォルトの名無しさんNGNG
>>567
最近の流行りは Modern C++ Design という書籍。
0573528NGNG
>>571
ん、そうだね。
言語特有のメリット・デメリットもあるけど、そうでない部分も多いと思うよ。

>>568
んー、ちょっと具体性に欠けるかもしれないけど、>>558で例で言えば

引数として固定長整数が来るのか可変長整数が来るのかコンパイル時に確定できれば
静的型付でかつ整数がvalue typeなほうが演算の速度はいいし、型情報を最適化のために利用することもできる。

実行時にしかわからない場合には、整数がオブジェクトのほうが動的束縛の処理を集中できるメリットがある。
するとVMのコードを集中させることができ、最適化やキャッシュに有利。
整数がvalue typeだと、動的束縛のための処理をオブジェクトのための動的束縛とは別に用意することになり、
その結果、動的束縛のための処理が分散されてしまう。
さらに、value typeの動的束縛を言語や環境が提供していない場合には
ユーザプログラマが動的束縛のコードを書くことになり、
コード量が増えることでデバッグやメンテナンスにも影響する。

似たような事はガベージコレクタにも配列の範囲チェックにも同様な事が言える。
特にポインタ型の扱い(許される演算など)は状況によってメリット・デメリットが錯綜すると思うが、どうよ？
0574528NGNG
>>573に補足すると、
例えばガベージコレクタを使わないほうが実行速度を稼げる可能性がある。
しかし、プログラマは常に最高のコードを書けるわけではないから、
ガベージコレクタを使うことでより上質なコードを書ける場合もあり、
結果的に実行速度を稼げる可能性も大いにある。

そしてガベージコレクタの実装はポインタ型に許される演算などに大きく影響され、
Cのように自由なポインタ型でガベージコレクタ無しで実行速度を稼げる可能性があるが、
Modula-2やModula-3のように非常に限定されたポインタ型と高質なガベージコレクタのほうが
結果的に速いコードが書ける場合もある。

また、通信路などの環境によってボトルネックが決まっている場合にはプログラムの処理速度自体が無意味な場合もある。
極端に言えば、アセンブリとSmalltalkでも実行速度は結果的に同じになる場合すらある。
0575528NGNG
>>574
OOから離れてしまうが、もうちょっと補足すると、
ポインタ型に許される演算やポインタを取り出す処理を限定することで可能な最適化処理もある。
例えばある変数のアドレスがポインタとして取得された可能性を調べることで
より多くのloop invariantの特定やstatementの順序変えが可能になる。

これも言語要素が「実行速度」という同一指標に関してメリットともデメリットともなる例だと思う。
0576528NGNG
>>572
サンクス。見つけたら読んでみるよ。
0577デフォルトの名無しさんNGNG
>>574
> 極端に言えば、アセンブリとSmalltalkでも実行速度は結果的に同じになる
> 場合すらある。
なんで極論を持ち出して、わざわざ Smalltalk のアプローチを全て肯定
しようとするかなぁ、この人は。

利点は利点、欠点は欠点としてフェアな視点で把握して、その後に得失を
考え、あるいは欠点を克服する方法を出してくれば良いだけなのに。
0578デフォルトの名無しさんNGNG
>>573-575
長文ごくろうさんですが、
それも何か、細かく分解すれば言語のメリット・デメリットになるような気がします。
まあ一般に言語や処理系の設計は常にメリット・デメリットが隣り合わせで、
状況によってメリットが出たりデメリットが出たり、という意味では同意です。
0579デフォルトの名無しさんNGNG
>>577
え、本当にあれを読んで528がSmalltalkを全肯定してると思うのですか？
Smalltalkという単語が出てきているのはその1文だけですが、
折にはその前後からSmalltalkにあてはまるメリットもデメリットも読み拾うことができましたが。

というか、Smalltalk使っている人が一方の例にSmalltalkを出すのはすごく自然なことだと思いますよ。
折も別スレで別の言語でもいい文脈で何となくsmlを持ち出したりしたし。
あの1文をもってSmalltalk全肯定と断定するのは、あなたのほうに色眼鏡があって
前後の記述を無視して重箱の隅を突ついているように折には思えます。
0580デフォルトの名無しさんNGNG
>>573
厨房なんで勘違いしてるかもしれないけど、value typeの存在する言語は
value type操作用のプリミティブが存在してるはずだから、あなたのいう
ような「value typeの動的束縛」は存在しなくて、プログラマが静的に決め
打ちしたコードが走ってるだけだと思うんだけど。
VMで走る言語であっても、バイトコードへのコンパイル時に、型が静的に
決定できればいいわけだし。実際Javaは静的に引数の型を決定できたんじゃ
なかったけ？
あとコード量は増えないと言うのがBoxing/Unboxingなんじゃないの？
0581デフォルトの名無しさんNGNG
http://www.objectlink.co.jp/PradaSmalltalk/PradaSmalltalk-JPN_1.html
http://www.objectlink.co.jp/PradaSmalltalk/PradaSmalltalk-JPN_4.html#SEC8
0582デフォルトの名無しさんNGNG
Smalltalkは型付けが弱い(型が無い？)言語なので、自動的にジェネリック
ジェネリックが何に対してジェネリックかといえば型だからねー。
（って、こんなことみんな知ってるか。）

JavaScriptによる ジェネリックプログラミング
ttp://www.mamezou.com/tec/Tips/jsgl/index.html
0583デフォルトの名無しさんNGNG
言語であれこれ言っても仕方ない。成果物だろやっぱり。
0584デフォルトの名無しさんNGNG
朝っぱらから寝ぼけたコメントありが㌧
0585ageNGNG
age
0586デフォルトの名無しさんNGNG
>583
激しく同意。
第一線で活躍している開発者は方法論ごときで
試行錯誤して時間を潰すわけにはいかないのだよ。
0587デフォルトの名無しさんNGNG
>>586
確かに、現場の人間は、実りの少ない議論でつぶす暇がないからなあ…
方法論なんか胴でもいいから、使えるものを出せ!がお客の要求だし。

万が一完成したとても有益な方法論があったとしたら、導入する意思は
ある？もしもあるとしたら、なにを持って有益と判断する？
0588デフォルトの名無しさんNGNG
>>587
＞もしもあるとしたら、なにを持って有益と判断する？
まぁ！納期まで２週間も余ったわ！
0589デフォルトの名無しさんNGNG
>万が一完成したとても有益な方法論があったとしたら、導入する意思は
>ある？もしもあるとしたら、なにを持って有益と判断する？
んなもん必要ない。Cには完成された方法論が既にあるし、
OO関連はCと相容れないので有益とはとてもいえない。

C++だのJavaだのOOなんてものは
Cという激戦区から弾き出された厨房用だろ。

俺は最後までこの分野で勝ち残って引退するよ。
0590デフォルトの名無しさんNGNG
なんや熱く暑苦しく語ってる方がいらっしゃいますが、
スレタイ嫁や、スレ違いだよ。
今隣にあるスレにでも逝け。
0591デフォルトの名無しさんNGNG
このスレは「ＯＯやる奴は死滅寸前スレ」に変わりました。
0592デフォルトの名無しさんNGNG
このスレはさらに「ＯＯわからない奴熱く語れスレ」に変わりました。
0593デフォルトの名無しさんNGNG
OOわからんやつらは、そのうち今で言うところの
コボラーみたいになるわけだな。
0594デフォルトの名無しさんNGNG
コボラーに失礼だろ。
OO分からんやつはJAVA厨房になるんだよ。
0595デフォルトの名無しさんNGNG
職業プログラマとそうでない人で意見は違うだろうな
0596デフォルトの名無しさんNGNG
仕事になると、OOかどうかというのは問題の一つでしかないからなあ。
0597デフォルトの名無しさんNGNG
方法論は所詮理論、現場ではつかえん派と、方法論の現場への導入に挑戦派とあるだろうけど。
そして、戦場では必要無しスレへ相互再帰。
0598デフォルトの名無しさんNGNG
概念を知ってて、実際にやってみたらどうなるか、を知ってる奴と知らない奴では
すんごい差があるね。
だけど、実際に使うかどうかは別だなあ。
0599デフォルトの名無しさんNGNG
>>598
同意、使う使わないはともかく知ってるってことは重要だ。
0600デフォルトの名無しさんNGNG
６００！
0601デフォルトの名無しさんNGNG
>>599
使ってみないと判らない事もあるよ。
たぶん。
0602デフォルトの名無しさんNGNG
>>601
禿同。
スキルっていうのは往々にしてそういうもんだ。

極論だが、素振りの仕方は知っているだけではダメで、実際に練習しないと
ボールを打てるようにならない、というのと似たような一面があると思う。
全てについてそうだとはいうつもりはないが。

で、人によって「ちょっとの練習」でばっちり打てるようになる要領の良い奴もいれば、
「どんなにたくさん練習」してもそこそこにしか打てるようにならない奴もいる。
だから自分がどのていど「要領が良い」のかを客観的かつ的確に把握して
おく必要がある。

問題なのは、野球と違って、なにを以って打てたことになるのか、がはっきり
していないことだな。だから勘違い野郎がばっこすることになる。

ちなみに俺は要領のあまりよくない、ちょっと勘違いしたやつ、というところだろう。
自戒を込めつつ…。
0603デフォルトの名無しさんNGNG
ところが、>>601は>>599を誤読しているという罠
0604601NGNG
そかな？
背景(理論・概念)を知るというのは、それが適用できる
方向性、可能性を知ることだと思う。
オブジェクト指向のような技術的なものは使ってみないと
判らないこと、それが適用できる限界が判らないと思う。

ただし、この理論は凡人の理論だ。
天才もしくはウィザードな人は、勝手に一人で先に行ってください。
できれば、おこぼれをくれると凡人な私はうれしいな。
0605デフォルトの名無しさんNGNG
オブジェクト指向の概念ですか。
個人的にはオブジェクト指向と呼ぶ言葉は良く解らないのですが、
C++やJavaの概念は物の状態や操作を整理する事を言語が
直接サポートしている事だと思います。
0606デフォルトの名無しさんNGNG
>>605 のつづき
まあ整理する事をサポートするだけなので
C++やJavaがプログラムの生産性、保守性を
上げるわけでは無いと思います。
0607デフォルトの名無しさんNGNG
>>606 のつづき
しかしながら物事の整理に対してセンスが良い
SE/PGにとっては力強い武器に成ると思います。
0608デフォルトの名無しさんNGNG
>>605
で、何が言いたいの？
0609デフォルトの名無しさんNGNG
>>604
599と601で「使う」の意味が違ってるね．
まあ，大した話じゃないけど，擬似問題に填まらんよう気をつけんとねぇ
0610デフォルトの名無しさんNGNG
>>609
「使う」？同じ意味で使ってるように見えるけど？
「知る」という意味が601と599では違うなら判るけど。

でも599さんってコンサルタントな人じゃないんかな？
なんとなくそう思う。
0611デフォルトの名無しさんNGNG
>>597-599　続けて読むと、>>599は
実際にプロジェクトで使うかどうかはともかく、使ってみたらどうなるかを知ってることは重要だ。
ってことだろ？
だから>>601は明らかに誤読だと言っている。

もしかしたら、>>599が誤読という罠かもしれないけど（ｗ
0612610NGNG
>>598
>概念を知ってて、実際にやってみたらどうなるか、を知ってる奴と知らない奴では
>すんごい差があるね。
以下略

>>599
>>>598
>同意、使う使わないはともかく知ってるってことは重要だ。

その手段(手法)を使う使わない以前に、手段があると知っていることは重要だ
と私は読めます。
手段を複数持っておくこと、第二案を用意しておくことが重要だ
ということじゃない？違うかな？
0613デフォルトの名無しさんNGNG
>>612
だとしたら、>>599は>>598の何に「同意」なんだろう？？
0614デフォルトの名無しさんNGNG
お前らOO以前に人並みのコミュニケーション能力身に付けろ。
0615612NGNG
修行の旅に出てきます。
ゴミスレにしてごめんなさい。
0616なぜ、オブジェクト指向技術が優れていると言われるのか？NGNG
現在のソフトウェア開発では、大半がネットワークを利用した高度な機能を要求されている。
また、従来のコンピュータだけではなく携帯電話やカーナビゲーションといった
携帯端末でも動作でき、さらにそれを短期間で開発しなければならない。
このような状況を克服するためには、以下のような技術を融合させる必要があり、
それがすなわちオブジェクト指向なのである。

①どの環境でも動作するソフトウェア開発言語

②どの環境でも動作するソフトウェア部品（再利用コンポーネント）

③ソフトウェア開発において人間が理解しやすい分析・設計手法

①は、Javaである程度実現している。C#についてはJava陣営と戦略は異なるものの、
C#をどこでも動作できるような.NET環境の普及を目指している。

②は、ソフトウェアを部品として扱うための枠組みである。
①を実現していることが前提となるが、「オブジェクト（もの）」という単位は、
ソフトウェア部品として理解しやすい。

③は、今日のようにシステムが複雑になるにつれて重要になってきた要求である。
従来のソフトウェア開発言語（Ｃ言語など関数型言語）で使われていた構造化手法では、
人が理解しやすい分析や設計手法を表現するには限界があった。
オブジェクト指向なら、人が実世界を理解する単位を「オブジェクト」として表現するため、
理解しやすくまたシステムの複雑化にも対応できる。
0617デフォルトの名無しさんNGNG
>>616
どこから突っ込め、と？
(ボロボロだな、ぉぃ)
0618デフォルトの名無しさんNGNG
>>616
１行目まではまともだったんだがなぁ・・・。
理論以前に勉強すべきすることがあると思いますよ。
機種依存文字とか。
0619616NGNG
某雑誌の某特集の巻頭特集記事の一部抜粋っすわ。
あんまりにも酷いんで引用してカキコしてみた。
ちなみに書いたのは某社のCTOだそうな。泣けるね。
0620616NGNG
ちなみにその雑誌、「SEを極めるためのスキルアップマガジン」と銘打っております。合掌。
0621デフォルトの名無しさんNGNG
>>619
ああ、お偉いさんならいいよ。
上は理想を追うくらいの方がいい。
現状でそうなってると思ってる奴はダメダメだが。
0622デフォルトの名無しさんNGNG
ttp://www.nextengineer.com/media/
これか？

さすが症泳社。
0623デフォルトの名無しさんNGNG
ttp://www.nextengineer.com/browsing/pdf/NEXTENGINEER.pdf
4ページ目の欄外だ。
藁減る
0624デフォルトの名無しさんNGNG
ttp://www.nextengineer.com/media/
SEって、こんな仕事なの？
まあSEっていう職業自体あいまいなものだが。

結局このHPに書いている、Level4以上に
行けるか逝いけないかというのが問題だろうなー。
でも行ける人は、こんな本読まなくても行ける。
0625デフォルトの名無しさんNGNG
うまく表現できないけど、なんつか、ＳＥって、「ビジネスマン」みたいなアヤシさを感じる。
0626デフォルトの名無しさんNGNG
プログラミングしたり営業したりコンサルタントしたり
大変な職業なんだねー
0627デフォルトの名無しさんNGNG
SEって，「セールスエンジニア」なんて言われちゃうこともある
なかなか辛いねぇ
0628デフォルトの名無しさんNGNG
>>616
おんなじ特集なら，「Interface」の方が100倍ぐらいイイ……かな？
「人間はバカだから，道具をシンプルにしとかないと使いこなせないンよ」
というのには激しく同意．

0629デフォルトの名無しさんNGNG
ライタの層が厚くなると良いねー
0630デフォルトの名無しさんNGNG
俺はLevel1でいいや。
0631デフォルトの名無しさんNGNG
Java 対 .NET とかナメ腐った特集やってる時点でどうかと思うが。
別に開発者なんて誰でも同じだと思うけどね。そんなに難しい仕事じゃないよ。開発なんて。
レベルもクソもあるかよ。

（それより今一番、大変なのは、消費者から直接金を取る立場の人とかでしょう。）
0632リンクNGNG
デザ　インパ ﾀｰﾝ!! ﾊｧﾊｧ・・・
0633デフォルトの名無しさんNGNG
>>631
こういうところの製品はあまり買いたくないなぁ
0634デフォルトの名無しさんNGNG
>>633
つーか、少なくとも勘定系の開発を委託したくはないな、いろんな意味で (W
0635デフォルトの名無しさんNGNG
もっと教えれ
0636デフォルトの名無しさんNGNG
>>616に書いてあるようなことを真に受けて、アンチＯＯが量産される。
0637デフォルトの名無しさんNGNG
オブジェクト指向は良い考え方だと思うけど
今あるオブジェクト指向型言語が良いものだとは思えないなー。
0638デフォルトの名無しさんNGNG
いいねえ、どういうオブジェクト指向言語がいいと思うのか
ぜひ語ってくれ。
0639デフォルトの名無しさんNGNG
Rubyとか懲りずに言ってみる・・・
0640637NGNG
>>638
良い言語が無いから困ってるんだ。
C++の総称(&総称の特殊化)が、次のトレンドへの突破口
だと思ってるんだけどねー。

しいて言えばLuxorかなー？
ttp://www.ff.iij4u.or.jp/~takusi/
0641デフォルトの名無しさんNGNG
>>640
そこ壊れてます。
0642デフォルトの名無しさんNGNG
>>639
いや、いいよ。でもどういう所がイイか書いてくれないと。
>>640
GenericityってC++が起源じゃないよね。AdaとかCLUとかEiffel
とか。ま、ともかく次のイイ言語にはGenericityはあって欲しい。
でもC++がイイ言語というわけには行かないよね、やっぱし。

あとC++になくて欲しいもの。delegationかな。それとinterface
とimplementationの完全分離。サブクラス作るとsubtypeに勝手に
なるのはもうヤメた方がいい。以上私の勝手な好みでした。

0643デフォルトの名無しさんNGNG
意味の検証をシグネチャでしか行わないC#のdelegateは嫌いだなあ。
0644デフォルトの名無しさんNGNG
>C++の総称(&総称の特殊化)が、次のトレンドへの突破口

総称の特殊化って Constraned Genericity のこと？

>GenericityってC++が起源じゃないよね。AdaとかCLUとかEiffelとか。

Genericity の起源はたぶん Algol68

>意味の検証をシグネチャでしか行わないC#のdelegateは嫌いだなあ。

C#のdelegateはレシーバが固定されているのが嫌い。
Smalltalkのselector とか EiffelのAgent みたいにしてほしい。
0645デフォルトの名無しさんNGNG
data = Object.create(int,0);

data.add(Object.create(int,8).num);

data.add(Function.call("hogehoge"));

全部オブジェクト指向は面倒くさい。
0646デフォルトの名無しさんNGNG
>>645
その3つのうちどれがオブジェクト指向？
どれも全然オブジェクト指向っぽくないんだけど。

と、ネタに反応してみるテスト
0647デフォルトの名無しさんNGNG
あげ
0648麗恵香NGNG
魔法のｉらんどでつくったHP不正に改ざんされてパスワード変えられた！！
｡誰か不正アクセスの仕方とか教えてください｡
お願いします｡
0649デフォルトの名無しさんNGNG
>>240
あんたはアメリカ人の乳輪がどうして大きいのか、
原稿用紙200毎分レポート書いてこい
0650デフォルトの名無しさんNGNG
「オブジェクト指向では、
データは自分が何をされるかをあらかじめ知っている」

入門書でいきなりこの抽象的な説明に会い、厨房だった自分は挫折した。
教える側のエキスパートが少ないのがオブジェクト指向の最大の欠点だと思う。
0651デフォルトの名無しさんNGNG
抽象的に書かないと詐欺れないだろ！
0652デフォルトの名無しさんNGNG
>>650
言語仕様が分かってきた頃にやっと意味が理解できるのが入門書。
0653narucy56 ◆wMOjCT4s NGNG
>>651

オブジェクト指向はムズカシくてわけわかんないけど、
使えるとなんかカッコイイみたいな、複雑なことが美徳
という風潮にマッチしちゃってるよな。けど、最近はさ
すがに分かりやすい本がいくつが出てきて、誰でもすぐ
に使いこなせる技術になってきていると思う。
0654デフォルトの名無しさんNGNG
オブジェクト指向は、"has a" "is a" "is implemented using"関係の３つが
理解できれば、まずまず使いこなせる。
0655デフォルトの名無しさんNGNG
>>654 煽りだとしたら３０点（ﾜﾗ
0656デフォルトの名無しさんNGNG
>>654
噛み砕いて、というか日本語で。
to implement は実装するでよろしかったか？
0657デフォルトの名無しさんNGNG
>>656
"has a"は、持っているであり、包含
"is a"は、部分集合であり、public派生
"is implemented using"は、～によって実装されるであり、包含または
privete/protected派生

この３つの違いが理解できるまでは、むやみにクラスを派生させては
いけない。
0658デフォルトの名無しさんNGNG
>>657
どうしようも無いくらいショボイ突込みでゴメソ

"has a"関係の場合、継承でなく関連で。
というのは、もう定説だと思うけど・・・
0659658NGNG
って657さん、ちゃんと書いてるねー。
逝ってきます。
0660デフォルトの名無しさんNGNG
>>657
C++なら総称を使おう。(藁
継承と違って、独立性が高いから良いぜ。
あっ。ごめん、ここオブジェクト指向スレだったね。(藁
0661デフォルトの名無しさんNGNG
is a っていうんだ
おれは is a kind of って習った
で、is implemented using って何？
おれはprivete/protected派生は触れないライブラリから派生した
クラスを基底クラスのメンバーへアクセスされるとうざいとき使うが
0662デフォルトの名無しさんNGNG
"is implemented using"ってインターフェイスは一致しないが
実装は一体化したいという場合だと思われ

でも、これって継承使うか？
0663デフォルトの名無しさんNGNG
>>662
継承を使わず、できるだけ包含を使うように推奨されています。
ただし、継承元の限定公開メンバにアクセスしたい時のみ、継承を
用います。>>661さんが言っておられることです。

例えばStackクラスを作ろうとしたとして、実装は配列でもリストでも構いませ
んよね。この場合Stackクラスの中に配列やリストのクラスを「はめ込みます」。
もしStackクラスから配列やリストにアクセスする必要が生じたときのみ、
protected継承を使います。しかしこれはあまりよい継承スタイルとは言えません。

あと、is aとis a kind of、is implemented usingとis implemented in term of、
いろんな言い方がありますが、同じことです。
0664661NGNG
おれが派生を使うのはオーバーライドが必要な時。
じゃだめかな？
0665デフォルトの名無しさんNGNG
明らかに設計上の上位構造で再利用性あるなら継承つかうけど、
それ以外は使わない。
0666デフォルトの名無しさんNGNG
>>664
オーバーライドって仮想関数のことだよね。そしたらpublic継承だから、is a kind of
の関係にある場合ならどんどん使っていいんじゃない？
0667デフォルトの名無しさんNGNG
で基底クラスのメンバーへアクセスされるとうざいとき
privete/protected派生をつかってる
0668デフォルトの名無しさんNGNG
C++で仮想関数をhas-a,つまりコンポジションから
再定義ってできないよね？
こういうので困ったこと無い？
俺はコンポジションするオブジェクトの仮想関数もオーバライド
できるべきだと思うんだけど。
0669デフォルトの名無しさんNGNG
継承じたいがオーバーライドのためにあると思っていたので特には。
なにか具体例がありますか？
0670デフォルトの名無しさんNGNG
>>668
具体的な例がなにかないでしょうか？イメージがわかないんですけど・・・・
例えば、包含しているクラスが複数あり、そのクラスが同一の型であるとし
たら、それを内包するクラスに仮想関数があったら、メンバをどうやって区別
するのでしょうか？
0671668NGNG
例えば仮想関数でコールバックするクラスをコンポジションするときとか。
コールバックメソッドを再定義して、コンポジションするクラスのメンバに
アクセスしたいけど、できないから。
こんな場合は、インナークラスでも使うのかな、でもはじめからあると
便利じゃないかなと思うんですけどね…。
0672671=668NGNG
インスタンスの名前で区別するとか
名前は必ず identical? ですから >> 670
インナークラスで対処できそうですけど、タイプ量と複雑さが
増すから、言語でサポートしてくれるとあっさりしてていいんじゃないかと。
でも、私の認識が甘いのかもしれません。
0673デフォルトの名無しさんNGNG
ただ単にbridgeパターン使えばいいだけって気が。
一個なら一個だけbridge
複数集約してるなら、そのどれかを選べるbridge

オーバライドでは実現できないね。
0674デフォルトの名無しさんNGNG
>>673
それは正しいが、めんどくさい。
これが真実。
0675デフォルトの名無しさんNGNG
>>671の例だと、基底クラスのインスタンスと、仮想化されたメンバ関数への
ポインタも持ってりゃいいだけだ。
面倒でもなんでもない。
0676デフォルトの名無しさんNGNG
間違えた。
基底クラスへのポインタと、仮想化されたメンバ関数へのポインタを...に読み替えてくれ。

だがどちらにしろ、ここで話す内容じゃないな。
0677デフォルトの名無しさんNGNG
>>675
ソース例キボン
0678デフォルトの名無しさんNGNG
>>668
forwording,delegateのこと？
http://javalab.cs.uni-bonn.de/research/darwin/delegation_eng.html
そういうことが出来ることは、いいことなのか？わるいことなのか？
判らん。

設計の問題なのかも？どうかな？
0679デフォルトの名無しさんNGNG
全部出すと長いので一部。

class Lengthen {
int width_;
public:
typedef ostream &(Lengthen::*method_t)(ostream &os);
Lengthen(int width) : width_(width) {}
ostream &SetWidth(ostream *pos) { return *pos << fixed << setw(width_); }
virtual ostream &puttitle(ostream *pos) = 0;
virtual ostream &putdata(ostream *pos) = 0;
~Lengthen() {};
};
0680デフォルトの名無しさんNGNG
void main()
{
vector<Lengthen *> show_order;
// 好きな順に登録
show_order.push_back(new Name("(´д`;;)"));
show_order.push_back(new Age(14));
show_order.push_back(new Gendor(Gendor::Male));
show_order.push_back(new End);
// ヘッダ
for_each(show_order.begin(), show_order.end(), bind2nd(mem_fun1(&Lengthen::puttitle), &cout));
// データ
for_each(show_order.begin(), show_order.end(), bind2nd(mem_fun1(&Lengthen::putdata), &cout));
}

残りは推測しる
0681デフォルトの名無しさんNGNG
http://www.kame-net.com/jplop/PatternRepository/CurrentPatternsList.htm
なんか、忘れそうなのでメモメモ
0682デフォルトの名無しさんNGNG
JPopですか >>681
最近、活動してないね。
やっぱり(以下 検閲削除)
0683デフォルトの名無しさんNGNG
age
0684デフォルトの名無しさんNGNG
JPLoPってあのトンデモ系団体か。
主旨は立派なんだが、出てくるものは何だかなあ。
0685デフォルトの名無しさんNGNG
有効利用age
0686dddNGNG
オブジェクト指向って
でかいプログラムや，多人数で開発するにはいいが
そうでなければオーバーヘッドがでかいだけなんじゃないかと
最近思ったりする
0687デフォルトの名無しさんNGNG
各地で激しく外出
0688デフォルトの名無しさんNGNG
>>686
すべてをオブジェクト指向というのは非効率。
けど、クラスライブラリは非常に有益。
0689dddNGNG
クラスライブラリつかっていて
わけのわからん挙動で結局
なかまで調べてたいへん
ということもある。
あと便利なのもあるけどたこなのもあると思うんだが
0690デフォルトの名無しさんNGNG
>>689
フレームワーク系のクラスライブラリかな？
だとしたら同意。
ドキュメントが分散しすぎてて「俺の書いた別売り解説本絶賛発売中嫁」みたいな
0691デフォルトの名無しさんNGNG
ge
0692デフォルトの名無しさんNGNG
またいまさら…。
0693デフォルトの名無しさんNGNG
オブジェクト指向の時代は終わりました。
これからは構造化の時代です。

皆さん今までありがとう御座いました。
0694デフォルトの名無しさんNGNG
ええ、今までありがとうございました
さようなら693さま！（・∀・）ﾆﾔﾆﾔ
0695デフォルトの名無しさんNGNG
OOは、実際のところはUMLなどの図形もどきをもとに設計を行う手法らしいです。
ですが、いい大人が図形作画ソフトの前で、
「うがあああああああわかんねえええええええなにぱたあああんなんだああああ！」
と言っているのを見てると、なんだかなあ…と思います。
0696デフォルトの名無しさんNGNG
さようならOO
なんか原一男みたい（わかんないか）
0697デフォルトの名無しさんNGNG
C#いじってみた。なんか、GUI部品も含めプログラムの「オブジェクト」
が本当に自然に書けるようになっているんだね。メソッドまでオブジェ
クトにラップするとは....。

Cベースのウインドウプログラミングではイベントやウインドウの扱い
で泥沼にはまったけど、C#でOOなプログラムを書いていけばこの辺りの
非本質的な部分で悩むことはだいぶ減りそう。プログラム環境としては、
JavaやDelphi以上かも。
やはりネットワークやウインドウプログラムでは、OOって必須だね。
0698デフォルトの名無しさんNGNG
>>697
それはOOの一つの側面。
ライブラリーを作る側から見たOOの特徴を理解しましょう。
0699DQNNGNG
http://www.miraihakusho.jp/reo/
0700デフォルトの名無しさんNGNG
オブジェクト指向ってのはだなぁ。
たい焼き機と、たい焼きと、あんこの関係だよ。
たい焼き機がclassで、たい焼きがobject、あんこがmemberだな。
プログラムをそういう考え方で統一して作ろうってのが、
オブジェクト指向ってわけだ。
ようするに、メリットもあればデメリットもある。
どうでもいい考え方の一つってことだ。な。わかった？
0701デフォルトの名無しさんNGNG
>>700
勉強し直し。
0702デフォルトの名無しさんNGNG
>>700
質の悪い教育ビデオでも見た？
0703デフォルトの名無しさんNGNG
>>702

元ネタは日経の某VB厨雑誌と思われ。
0704デフォルトの名無しさんNGNG
タコ焼き機ならわかるけど。
0705デフォルトの名無しさんNGNG
>>679-680
delete は？
0706デフォルトの名無しさんNGNG
>>705
ガーベジコレクション
0707デフォルトの名無しさんNGNG
このスレを見て OO に目覚めた人はいるのか？
いまどき OO 否定派なんてやっぱりネタなのか？
0708デフォルトの名無しさんNGNG
ＯＯ言語以外は糞
0709デフォルトの名無しさんNGNG
使い尽くしてくれたまへ
0710デフォルトの名無しさんNGNG
OOよりはパターン。
0711デフォルトの名無しさんNGNG
パターンを可搬性を持ちやすいように意識しながら分析していくと、
OOよりになるね。
0712デフォルトの名無しさんNGNG
実際がどうだか知らないが、オブジェクト指向の進化の歴史を
想像してみたら、なんとなくオブジェクト指向のメリットを
説明できていることに気がついた。

※構造体（オブジェクト指向の始祖）
　　構造体を使う方じゃなく、使われる構造体自身が機能を持っていると、
　　コードがすっきりしていいんじゃないか？
　　　　↓
＊最初のクラス（継承は出来ない）
　　コードに手を加えずに、機能の拡張が出来たら便利じゃないか？
　　　　↓
＊継承が使えるクラス
　　継承したクラスを親クラスとして扱うと統一した型で扱えて便利だ。
　　でも、それなら型を定義するためだけにクラスを作るのは汚い。
　　　　↓
＊インターフェイスの発生（型のみの定義が可能に）
　　みんなで型を活用したコーディングを色々試しているうちに、
　　定石が固まってきたのでまとめてみた。
　　　　↓
＊デザインパターンの発生

そんなにキャリア長くないんで実際がどうだか知らないけれど、
こんなもんじゃないかなと思う。
実際どう？
0713デフォルトの名無しさんNGNG
デザパタは「発生」より「発見」の方が、しっくり来ると思う。
0714ななちNGNG
C++とかJavaとかやってると、そうゆうふうに思うんだろうね。
「進化の歴史」は、言いすぎだと思う。
0715デフォルトの名無しさんNGNG
抽象データ型はSimula67の時点で既にあったし、
Smalltalkも今から見れば出てきたのが滅茶苦茶早いからね。
初代は1972年にはもうあったんだっけ？
Cの登場とSmalltalkの登場はほぼ同時期だったと思う。
そしてSmalltakには継承が1976年に導入されて1980年にはMVCができた。
CがC++になったり、Javaがでてきたりするのは更に後だね。
デザパタは元々はSmalltalkのコミュニティから出てきたって
聞いたことがあるけどこれは本当？
0716デフォルトの名無しさんNGNG
オブジェクト指向大賛成。
しかし全てをそれで表現しようとするのは間違い、なはず。
0717デフォルトの名無しさんNGNG
話をループさせるべく蒸し返してみるテスト。

オブジェクト指向とは何かと言えば、継承・多態・カプセル化。
この三つをネジ釘としてオブジェクトという単位を構成し、
それらの結合体としてソフトウェアを構成していくのが狭義のオブジェクト指向。
広義にはそれを思想化して設計法や発想法にまで拡張するけど、
狭義かつ具体的な手法としてはあくまでも、

継承＋多態＋カプセル化＝オブジェクト
Σオブジェクト＝ソフトというオブジェクト

このほーてー式が基本。下手に適用範囲を拡大して
何でもOOで片づけようとすると却って苦しいこともあるので、
OOPに慣れたプログラマほど、OOをシンプルで小さなものとして捉えた方がいい。
0718716NGNG
まあ表現できないところっては少ない気がするけど。
0719デフォルトの名無しさんNGNG
>>714
ご明察。
Javaメインでやってて、その前がC++をほんのちょっと、
その前はBASICまでブランクがあいてます。

>>715
そんな昔からあるのか・・・
でも、BASICやってた頃はオブジェクト指向なんて
かけらも見かけたこと無かったなあ。
0720デフォルトの名無しさんNGNG
>>718
表現できるかどうかじゃなくて、表現しやすいかどうかが重要。
表現できるからといってやたら適用・援用・強要すると幸せになれない。
0721716NGNG
>>720
それはあるね。
0722逝って良しの１NGNG
継承、多態、カプセル化は継承、多態、カプセル化であって
オブジェクト指向ではない。

モノとして扱える/振舞うプログラムモジュールを用いた構造こそがオブジェクト指向
である。
結果としてカプセル化になる傾向はあるが、オブジェクト指向の集合の端っこで
重なっている別の集合と考えた方が良い。

継承・多態はオブジェクト指向とは全然別の記述上の構造に過ぎない。
0723逝って良しの１NGNG
setVideoModeなんてクラスは継承・多態・カプセル化を使っていても
オブジェクト指向ではない。
0724デフォルトの名無しさんNGNG
＞setVideoModeなんてクラス
こりゃまた、ずいぶんヘタレた例をあげたもんだ…
0725デフォルトの名無しさんNGNG
>>722
一見すると正しいようで、実はあまりいい考え方とはいえない罠。
実装上の形式的な、継承・多態・カプセル化、が
ソフトをいきなりオブジェクト指向化するわけではないのは確かだが、
それは単に悪例だというだけであって、
継承・多態・カプセル化はただの実現手段なんだ、
という考え方は危険性を孕んでいる。

継承・多態・カプセル化が本当に「ただの」実現手段ならば、
それ以外の「広く適用可能で」「実際に利用されている」
実現手段でもって実現されたオブジェクト指向の作例も常に頭になくちゃならない。
でないと、有効な実現手段が他にないということなのだから、
結局はオブジェクト指向と継承・多態・カプセル化が表裏一体だと認めてる。
つーわけで実際にそこそこ広く使われている実装手段で
継承・多態・カプセル化の解釈に当てはまらないものを例示してくれ。

思想的なポジションとして継承・多態・カプセル化をオブジェクト指向から
切り離すのは全く正しい考え方ではあるが、
具体的な実装手段を伴わないままに概念が先行してしまうと、
オブジェクト指向以外の実装手段の利用に対する注意が削がれやすい。
ＯＯマンセーになった経験の浅いプログラマがハマりやすいパターンがこれ。
結果的に何でもオブジェクト化しちゃって保守性を逆に下げてしまったりする。
継承・多態・カプセル化では表現しづらいものがあったら、
「だけどこれはオブジェクトとして解釈できる」
というところにあまり拘泥せず、別の考え方もできるようにした方がいい。
オブジェクトじゃない機能の凝集性が低く
スクリプト風のシーケンシャルな処理フローの中に
そこから制御されるオブジェクトを関連づけていくとかね。
プログラマには美的水準以前に、納期や品質というハードルが待ってるんだから。
0726デフォルトの名無しさんNGNG
C++のクラスが表現する一つの形はコンセプトらしいが
異議ないか？
0727デフォルトの名無しさんNGNG
委譲がいまいちわかんねぇな。
使ってる？
0728デフォルトの名無しさんNGNG
委譲なー。漏れもよくわからん。

デリゲードとはちがうんだろ？
0729デフォルトの名無しさんNGNG
クロージャーもよくわからん
0730デフォルトの名無しさんNGNG
ようするに、わかっているやつなんておらんのよ。

オレモナー
0731デフォルトの名無しさんNGNG
じきにアスペクト指向も使わなきゃならん
0732デフォルトの名無しさんNGNG
ムナカータ指向の時代もそのうちくるな
0733デフォルトの名無しさんNGNG
>>728
同じだと思うが。

>>727
これを読めれ。
実装の継承に関する問題
http://www.microsoft.com/japan/developer/library/jptech/TechArt/VTools/vb/vb6/ifacebased.htm
0734指向ってどういう意味？NGNG
Javaの場合
オブジェクト指向、クラス指向、インターフェース指向を
状況によって変えるのが吉。
まあ、同じことを頭の中で見方を変えて考えてるだけだが…。
1つの統一された考え方のみで全てを説明できるほど
頭が整理もされてないってのもあるし。
っていうか、これってJava指向？
駄文でスマン。

＊最近思うが、JavaでもSmalltalkにはない良さもあって良いよね。
0735デフォルトの名無しさんNGNG
ポリもｰフィズムで同じ名前使うと見やすいってだけなの？
0736デフォルトの名無しさんNGNG
>>735
どういう事だ？
0737デフォルトの名無しさんNGNG
>>735
クスクス
0738デフォルトの名無しさんNGNG
クスクスなの？
0739デフォルトの名無しさんNGNG
>>738
何を意図として何を指してそう言ってるのかがさっぱりわからん。
0740738NGNG
同意
0741デフォルトの名無しさんNGNG
>>735
暇なので意訳してやる！

（ポリモーフィズムを使うと、インスタンスの型に応じた
　処理を呼び出せるらしいけど、）←※1
例えば、DrawSquare,DrawCircle,DrawTriangle...ってやらないで、
呼び出しをDrawメソッドに統一するとソースが見やすいってだけなの？

※1 おそらく>>735が全く理解していない部分。
0742デフォルトの名無しさんNGNG
>>741
いや、それくらいの類推は出来るよ。みんな。
その前提でからかってるの。

どっちにしろ通ぶって多様の話振った割には言葉の用法からして間違ってるし。
0743735NGNG
全然通ぶってないと思うんだけども・・・。
とりあえず、意味がわからん
0744735NGNG
意味わからんから揚げ
0745デフォルトの名無しさんNGNG
>>735
だからポリモーフィズムつーのは、
一つにまとめあげようとする技術の総称だ。
これでわからんのなら消えろ。
0746指向ってどういう意味？NGNG
ポリモーフィズムってどういう意味だろうね。
オブジェクト指向的には、
　違うオブジェクトに同じメッセージを出しても違う反応を示すのは当たり前。
　だって、違うオブジェクトなんだもん。…というしかない。
　つまり、十人十色なのがポリモーフィズム。
クラス指向的には、
　下位クラスから上位クラスに対してメッセージシグニチャによる検索をして、
　初めにHITした内容の処理を行う。
　つまり、同シグニチャを名前空間によって、
　分離・分類する構造化的手法がポリモーフィズム。
インターフェース指向的には、
　インターフェース壁により実行者と実装者が分離するのが
　インターフェースの目的の1つなので、
　あるメッセージシグニチャに対して実行したり実装したりする。
　「実装者←→インターフェース←→実行者」のマッピング。
　つまり、実装者の変化が実行者に対するポリモーフィズム。

利点・欠点をはぐらかして書くと、こんな感じかも。
0747デフォルトの名無しさんNGNG
歯垢age
0748デフォルトの名無しさんNGNG
実行者＝実装者
0749デフォルトの名無しさんNGNG
外面は同じだが中身は違うってことで脛。
0750ポリモーフィズムなんてNGNG
低レベル物理演算クラスを3DNowバージョンとSSEバージョンで作りたいとか
そういった外面をまったく同じにするような使い道しか
思い浮かばないな
0751デフォルトの名無しさんNGNG
デバイスドライバとかプラグインの
open
close
send
get
メソッドなんかは思いっきりポリモーフィズムじゃないの？
0752デフォルトの名無しさんNGNG
それはただの共通インタフェース
0753デフォルトの名無しさんNGNG
だから、それがポリモーフィズムだっつーの。
クラスじゃないだけで。
0754デフォルトの名無しさんNGNG
全部ポリモーフィズムっていっとけばいいんだよ。バカダなあ・・・。
0755逝って良しの１NGNG
呼び出しがバラバラで処理が一緒というのはなんて言うの？
0756デフォルトの名無しさんNGNG
コピペ？
0757デフォルトの名無しさんNGNG
＼(ﾟﾛ＼)ｺｺﾊﾄﾞｺ? (／ﾛﾟ)／ｱﾀｼﾊﾀﾞｱﾚ?
0758デフォルトの名無しさんNGNG
ここは2chで
お前は厨。
0759デフォルトの名無しさんNGNG
(;O;)
0760デフォルトの名無しさんNGNG
ポリモーフィズムっていらないよねえ（プ
0761デフォルトの名無しさんNGNG
>>755
リファクタリング対象
0762デフォルトの名無しさんNGNG
>>760
必要になってから泣くなよ（ｗ
0763デフォルトの名無しさんNGNG
>>761
ﾜﾛﾀ
0764デフォルトの名無しさんNGNG

　Ю）＿＿）　
　| ﾟДﾟ.|　ﾊｧ?
　＾＾＾＾＾　 　 　 　
0765デフォルトの名無しさんNGNG
おまえらこれはどうですか？
ttp://www.tcp-ip.or.jp/~ikken/cpp/
0766デフォルトの名無しさんNGNG
>>765
programmerとしては正しいことを書いてる。
software engineerとしてはあまりに乱暴。
0767デフォルトの名無しさんNGNG
>>765
そのページ

>構造化プログラムとは即ち構造体を使うプログラムだ

この言葉が彼のレベルを集約している
0768　NGNG
>>767
ﾜﾛﾀ
0769デフォルトの名無しさんNGNG
>>751
実行時まで、どのデバイスが相手になるのかわからないんなら、ポリモーフィズムかも。
でも、コーディング中にデバイスが特定できてるんなら、手続き抽象、ていどかも。
0770デフォルトの名無しさんNGNG
>>769
まさにC++がそのような言語だね。
0771デフォルトの名無しさんNGNG
すまぬ。sageる。
0772デフォルトの名無しさんNGNG
アプリケーションの設定ってどこで管理するのが普通？
Prefsクラスで集中管理するのか、各クラスがシリアライズするのか。
簡単な物は後者で良いんだけど、設定ダイアログを持つアプリケーションのような
複雑な物になってくると、前者だとPrefsクラス一つで簡潔になると思うけど、
後者だとダイアログクラスが各オブジェクトを知らないとならなくなるから、
大変じゃないですか？
0773デフォルトの名無しさんNGNG
各クラスがプロパティページを吐き出すようにするとか。
駄目か。
0774デフォルトの名無しさんNGNG
漏れはPrefsクラスで集中管理がすき。
設定ダイアログやレジストリとのインターフェイスは、Prefs関連のクラスに集約する。
設定は、各クラスの初期化の時か、パラメータ変更通知メソッドに、パラメータとして渡すようにしてるよ。
0775逝って良しの１NGNG
>>773
おそーい。
俺がとっくに実用化済み。
0776デフォルトの名無しさんNGNG
>>775
ダサい

クラスとリソースが密接に関わり合うと言うのもなんだかなー
0777773NGNG
>>776
そのclassの独立性を高めるって点ではありかも？
自分のことは自分でこなせるみたいな。
0778774NGNG
あるクラスが、自分の必要とするパラメータが、レジストリにどう書かれてるか、とか、
どんなダイアログで変更するのか、なんて、知ってる必要ないじゃん。
だから、そこを分離、抽象化してるんだけど…
0779デフォルトの名無しさんNGNG
>>778
それってPrefsクラスと言うか、単なるローカルレジストリじゃない。
OS等の物理レジストリとの関係を疎遠な物にしているだけでさ。

もう一つ上のレイヤの、オブジェクトとプロパティの関連について知りたいな。
各オブジェクトが、Prefsクラスに問い合わせるようにするの？
それだったら、本質的にはWinで言うGetPrivateProfile～と変わらないしね。

設定ダイアログも、クラスの内部と別に作らないといけないから、
管理に掛かる手間も２倍になってしまう。
0780デフォルトの名無しさんNGNG
まあオブジェクト指向かどうかは知らんが
>>713の方がコーポネント志向ではあるな。
実際ActiveXコントロールなんかは
コントロール自体にプロパティページを内包する形は
採ってないので、それが良い方法なのかはわからないけど。
0781デフォルトの名無しさんNGNG
オブジェクト指向的になら、各クラスにやらせる方が良いだろうが、
わかりやすいプログラムになら、プロパティ管理クラスと、
プロパティ画面表示クラスを、別に用意した方がいいだろうな。
オブジェクトの独立性は低下するが。

納得できない奴もいるかもしれないが、
オブジェクト指向的＝最適な選択じゃないいい例かもな。
俺の能力に問題があって、
オブジェクト指向に出来ないだけだと思うなら、
自分でプログラミングして確かめてみな。
頭の中の妄想じゃなくてな。
0782デフォルトの名無しさんNGNG
オブジェクト指向で、もっとも重要なのは
StatusとActionを決してごちゃまぜにしないこと
0783デフォルトの名無しさんNGNG
>>782
Status→プロパティ
Action→メソッド
これらを含む概念がclassだと思ってたけど違うの？
0784778NGNG
>>779
じゃ、あなたならどーする？
0785デフォルトの名無しさんNGNG
>>784
いや、良い方法が思いつかないから質問しとるんです
0786デフォルトの名無しさんNGNG
>>783
結局、それが全ての間違いの元だったのです・・・

というか、それを過信しすぎると破綻するというか。
0787デフォルトの名無しさんNGNG
オブジェクト指向も所詮道具、目的ではない
オブジェクト指向に出来たら良いわけでもない
0788デフォルトの名無しさんNGNG
別に目的だろうがなんだろうが便利なモノは利用する
違いますか？
0789デフォルトの名無しさんNGNG
お前等レベル低すぎ。
特に>>788。
おまえにはポリシーっつーもんは無いのか。
0790デフォルトの名無しさんNGNG
>>789は趣味グラマです
0791デフォルトの名無しさんNGNG
ポリシーだけはあるが低スキルなんじゃ話にもならない。
0792デフォルトの名無しさんNGNG
agear
0793逝って良しの１NGNG
>>789
他人の考え出したモノをなぞるだけでポリシーもクソもないもんだ。
ポリシーを口に出せるのは俺設計俺構造が出来る人だけ。
0794デフォルトの名無しさんNGNG
>>1
自然言語って何？
0795デフォルトの名無しさんNGNG
>>794
例えば

＞自然言語って何？

とか。
0796デフォルトの名無しさんNGNG
検索したら日本語とか英語のことようだが
0797デフォルトの名無しさんNGNG
>>796
って言うか人が使うファジーな言語のこと。
0798デフォルトの名無しさんNGNG
オブジェクト指向を否定する理由が分からない。
0799デフォルトの名無しさんNGNG
コミニュケーション要言語？
0800デフォルトの名無しさんNGNG
オブジェクト指向プログラミングの問題点、を指摘できる香具師はいるかい？
OOPを理解してるっていうんなら、OOPが完全無欠の開発手法ではない以上、
問題点もちゃんと指摘できるはずだ。
0801デフォルトの名無しさんNGNG
構造化は完璧なのか？
0802デフォルトの名無しさんNGNG
完全無欠の開発手法など存在しない。
0803デフォルトの名無しさんNGNG
ということは利点が多い設計方法が勝ち残るのかな
0804800NGNG
>>801-802
それは俺への当てつけかい？(笑)
OOP以外により優れたものがあると、俺がどこに書いた？

道具は適材適所って意見は多いが、
その具体的な判断基準にまで触れたレスは見かけない。
だから、それを明示できるような奴はいないのか、と話を振ったまで。
OOPが適したところ、適さないところ、の判断もできないようじゃ
OOPについて語る資格があるとも思えない。どうよ？
0805デフォルトの名無しさんNGNG
>>804が良い事言った！
適材適所～としか意見が言えない連中はよく読んどけ。
0806デフォルトの名無しさんNGNG
>>805
で、どこが適してて、どこが適してないんだ？
さっさと教えれ。
0807デフォルトの名無しさんNGNG
知らない
だって勉強中なんだもん♪
0808デフォルトの名無しさんNGNG
>>804
当てつけのつもりはない m(__)m
0809デフォルトの名無しさんNGNG
このスレの住人のレベルでは、総括的なレスは期待できません。
適したところ１つ、もしくは適さないところ１つを、順番に上げていってください。
0810デフォルトの名無しさんNGNG
808
802です。
0811デフォルトの名無しさんNGNG
>> 809
とりあえずお前には適してない
0812デフォルトの名無しさんNGNG
GUI画面描画の為のクラス階層はよさげじゃない？
0813デフォルトの名無しさんNGNG
>>812
実装継承のクラス階層は良くない
メッセージドリブンOSでのGUIは良い
0814デフォルトの名無しさんNGNG
厳密な処理順序が要求される処理には向かないな。
0815デフォルトの名無しさんNGNG
金融派生商品の開発にObjectiveCを使ってる
という事例を以前聞いたことがあるが・・・
0816デフォルトの名無しさんNGNG
一発ものの処理にも普通は向かない。
システムのなが～い初期化処理とか。
0817デフォルトの名無しさんNGNG
向く向かないと、可能不可能は別問題。
世の中には、適不適を無視したシステムも有る。
（しかし、大抵は少数派。）
0818デフォルトの名無しさんNGNG
>>817
向かないのに、何故か携帯でJAVAは
(日本だけは)多数派?
汚い手練手管のドコモの功績か?
0819デフォルトの名無しさんNGNG
イベントドリブンじゃないＯＳ
だとあんまり必要ないかも
0820デフォルトの名無しさんNGNG
オブジェクト指向の有用性について
いつもうんちく垂れてる粘着ﾄﾞｷｭｿは
結局なにも説明できないね
なんか底が知れたって感じ
0821デフォルトの名無しさんNGNG
うーん、オブジェクト指向の有用性かあ。
自分は結構便利だと思ってるけど、なぜ便利かということを振り返ると、
・名前の衝突がかなり回避できる
・VCのエディタがメソッドを補完するために羅列してくれる
・統一的な概念だから整理して考えやすい
・関数やライブラリだけでカプセル化するのに比べて、もっと様々なものを
カプセル化できるようになった

こんな所かな。
0822デフォルトの名無しさんNGNG
オブジェクト指向の無効性について
いつもウンチクすらたらすことの出来ない粘着ドキュソは
結局煽りしか出来ないね
なんか深さすらはじめからないって感じ
0823デフォルトの名無しさんNGNG
ひとまず解らないままにDelphiを３ヶ月程触っていれば概念や有用性が突然天啓
のように理解できると思うんですがどうでしょう。私はそうでした。
Delphiを持ち上げるわけではないですが。
0824名無しさん＠ＥｍａｃｓNGNG
まるごと図解「最新 オブジェクト指向がわかる」
ISBN4-7741-1325-5 C3055 \1580E

あたりから始めるのがよいかと思われ。
読んで分かったような気にならなかったらスッパリあきらめる。
0825デフォルトの名無しさんNGNG
このスレを見て何となくわかった事

オブジェクト指向を盲信する人
－＞適材適所すら言えない
－＞オブジェクト指向が理解できていない
－＞悔しいので何でも他人の理解不足のせいにする
－＞そして自己満足 & 自己陶酔

オブジェクト指向の問題点を指摘できる人の方が
まだ少しはオブジェクト指向を理解できているのかもね
かもだよかも(藁)ﾍﾝﾅｱｵﾘﾊｲﾗﾝﾖ
0826デフォルトの名無しさんNGNG
－＞適材適所すら言えない
OOはどんな状況でも常に最適の解ですが何か
0827デフォルトの名無しさんNGNG
>>826は素人釣氏

0828デフォルトの名無しさんNGNG
>>826
３流のマはすっこんでろ。
0829デフォルトの名無しさんNGNG
大雑把な一般論を言えば。。。
設計の下位レイヤーに近い実装の方がオブジェクト化しやすい。
上位レイヤーに近い実装の方がオブジェクト化しにくい。
コンポーネントはオブジェクトでも接着剤までオブジェクトとは限らない。
0830デフォルトの名無しさんNGNG
常にオブジェクト化するということは、抽象度を下げませんか？
0831デフォルトの名無しさんNGNG
単純に,適所はｵﾌﾞｼﾞｪｸﾄ化しやすい物.
ｵﾌﾞｼﾞｪｸﾄ化しづらい物を,無理にOOするOOﾏﾝｾｰは逝ってﾖｼ.
0832デフォルトの名無しさんNGNG
オブジェクトを使う側はスクリプトで書いて
使われる側のオブジェクトは固めの言語で書くと割に幸せ。
0833デフォルトの名無しさんNGNG
オブジェクト化しやすいっていうのは、どういうケース？
0834デフォルトの名無しさんNGNG
オブジェクト化するのが適所なケース
「適所」がポイント
0835デフォルトの名無しさんNGNG
はぁ？
0836デフォルトの名無しさんNGNG
>>834
要は、きっちり文章化するものではない、ということですか？
0837デフォルトの名無しさんNGNG
>>834
要は、きっちり定義できないので逃げる、ということですか？
0838デフォルトの名無しさんNGNG
オブジェクト指向を勉強しろというのは
自分がわかってなくて適所も言えないための
逃げ口上という結論でいいですか？
0839デフォルトの名無しさんNGNG
いいですよ。
やりたくないんだったらやらなくていい。
決まっていることじゃないから。
0840デフォルトの名無しさんNGNG
だから適所にはオブジェクト化しやすいものを、オブジェクトするのが適所だ
と言えるケースならオブジェクト化しやすいんだよ。要するに適所なんだよ。
0841デフォルトの名無しさんNGNG
オブジェクトする->オブジェクトとする
0842デフォルトの名無しさんNGNG
東は北を向いて右の方向
右は北を向いて東の方向
0843デフォルトの名無しさんNGNG
って言うかここのOO厨、アンチOOバカの話をきっかけにして本を読んで見るのが適当かと。
人に聞くだけで知識つけようなんざプログラマとしてどうなのか？
0844デフォルトの名無しさんNGNG
>>839
おいおい、そんな当たり前の事言ってどうする。俺をがっかりさせるな。
今までの勢いはどうした、弱気になるな。OOやらない奴は馬鹿と言ってくれ。

>>843
もしかして、オブジェクト指向の勉強のために、君に教えを乞う奴が居ると思った？
凄い自信だな、感心したよ。試すつもりはないが、オブジェクト指向の適所をあげてくれ。
もしかして、全ての環境･状況が適所の、完全無欠の絶対手法なのかな？
0845デフォルトの名無しさんNGNG
>>844
＞もしかして、オブジェクト指向の勉強のために、君に教えを乞う奴が居ると思った？
＞凄い自信だな、感心したよ。

俺も文章の意味を簡単に変えてしまうあなたの理解力に感心。
0846デフォルトの名無しさんNGNG
今のオブジェクト指向は純粋なオブジェクト指向ではない。
言うなれば修正オブジェクト指向だ。
0847デフォルトの名無しさんNGNG
>>846
目的はプログラムの開発効率のアップな訳だからそれでも問題はないけどね。
0848デフォルトの名無しさんNGNG
適材適所ってのがよくわからん。
ほとんどの点でオブジェクト指向は最良の選択のはず。
0849デフォルトの名無しさんNGNG
>>848
＞ほとんどの点でオブジェクト指向は最良の選択のはず。

さようならとしか言いようがない。
0850デフォルトの名無しさんNGNG
>>849
どういうときに何がオブジェクト指向より優れているのか
具体的に教えてくれ。
まあさようならでもいいけど。（ｗ
0851デフォルトの名無しさんNGNG
OOできない奴は馬鹿。
0852デフォルトの名無しさんNGNG
職業プログラマでもねぇし、
ソースコード公開してるわけでもねぇし、
馬鹿で良い。ﾁｮｺｯﾄ組めるだけまし
0853デフォルトの名無しさんNGNG
馬鹿でもプログラムを組めるようにしたのがＯＯ
0854デフォルトの名無しさんNGNG
ＯＯできない奴は馬鹿未満
0855デフォルトの名無しさんNGNG
>>850
これがOO厨の正体だな。
馬鹿すぎて、自分がオブジェクト指向を理解できていないことすら、理解する能力がない。
0856デフォルトの名無しさんNGNG
>>855
わかったわかった。まあどうでもいいからさ、
どういうときに何がオブジェクト指向より優れているのか
具体的に教えてくれよ。
0857デフォルトの名無しさんNGNG
>>856
説明してもお前じゃ理解できない。
自分で本読んで勉強しろ。
0858デフォルトの名無しさんNGNG
>>857
つーか、お前は誰にも説明できないだろうが。
そもそもオブジェクト指向以外って何があるか知ってるかい？
構造化だ！とか言うのか？ｗ
0859デフォルトの名無しさんNGNG
おーい、誰か～
どういうときに何がオブジェクト指向より優れているのか
具体的に教えてくれよぉ～。
0860ＯＯ原理主義者 1NGNG
クラスにできないものなどない。
0861OO厨NGNG
　　　　　　　　　　　　　　　　　　　　,,,,,,,,,,,,,,,,,,,,,,,,,,,,
　　　　　　　　　　　　,,--―'''""`ヽ'　　　　　　　　￣`ヽ､
　　　　　　　　　　 ／　　　　　　　　ヾ　　/　　　　　　　　~`ヽ
　　　　　　　　　／　　　　　　　　　　　ヽ;:／""""ヾ　　　ミ　　ヽ
　　　　　　　 ／　　　　　　　　;:;;:::''''""""　　　　　　 ＼　　　　　i
　　　　　　／　　　　　　　　／　　　　　　　　　　　　　　 ヽ　　ヾヽ
　　　　　 /　　　　　/　/　;/　　　　　　　　　　　　　　　　ヾ　　 ヽ
　　　　　/　　　　　　　　;:;:ヽ　　　　　　　　　　　　　,,,,;;::'''''ヽ　　;:|
　　　　　i　　　　　　　　　　/　　,,,,;;:::::::::::::::　　　　　　　＿__ヽ　　ヽ
　　　　　|　　　　　　|　　　|　　"　　　＿＿　::::　　　'"ゞ'-'　ヾ　　ヽ
　　　　　|　　　　　|　　ヾ　|　　　 　 '"-ゞ'-'　::::::.　　:　　　　　|　　;:|
　　　　　|　　　　　　　　　;:|　　　　　　　　　 : :::::::　　: .､　　　 |　　:|
　　　　　 |　　　　　　　　　ヽ　　　　　　　　　(　,--､ ,:"'　　 　 |　/|!
　　　　　　|　　　　　　ヽ　ヾ　　　　　　　　　　　　　　　　　　　|;:/
　　　　　　|　　　　　　　　　|　　　　　　　　　__,-'ﾆニニヽ　　 /|
　　　　　　 ||　　　　　　　`､ヽ　　　　　　　　　ヾニ二ン" 　 /;:|
　　　　　　　 |　　　　　　　ヽ　＼　　　　　　　　　　　　　　 /ﾉ
　　　　　　　　|　　　　　　　　i　　`ｰ-::､_　　　　　　　　,,..-'|ヽ
　　　　　　　　　ヽ;:;:;:;:　　　;:人　　　　　　`ー――'''''"~　/　ヽ
　　　　　　　　　　　 ＼;:;:;:;:/　　`ｰ-､　　　　　　　　　,.-'"　　 ＼ー-､
　　　　　　　　　　　,.-'"　:/　　　　　 ＼　　　　　 ,.-''"　　　　　|
　　　　　　　　　／　　　　!　　　　　　　 ~＞､,.-''"　　　　　　　 |
　　　　,,..-‐'''""　　　　　　ヾ　　　　,.-''"――――-､　　 　 　/

オブジェクト指向がオブジェクト指向であると見抜けない人が
　　　　　　　　　　　　　　　　（プログラミングをする事は）難しい
0862デフォルトの名無しさんNGNG
要するに、何だな。つまりあれだ。
色々難しそうな造語を作って並べてみるのはコの業界によくありがち
なこったが、つまりは同じコードを何度も書きたくねえってこった。
0863デフォルトの名無しさんNGNG
確かに適材適所を考えなくてはならないことは確かであるが、
少し大規模になってくると、OOが適してる場面が非常に多いことも
また事実。
goto文ばかりのプログラムよりも、構造化プログラミングのほうが
より適してる場面が非常に多いのと同じようなもの。
新しい手法が開発されればOOが最適とはいえなくなるだろうけど。
0864デフォルトの名無しさんNGNG
適材適所もなにも、OOしか知らない折れに、他に選択肢なんか無いよ
0865デフォルトの名無しさんNGNG
> OOしか知らない

こういう人が現場を不幸にする
0866デフォルトの名無しさんNGNG
適材適所だの、選択肢が無いだのそのレベルの議論かよ。くだらねぇなぁ。
なんでいつまでたってもそういう大雑把な話しかでてこないんだよ。
OO嫌いな奴もOOのここがこういう風に駄目だとか具体的なこと言えよ。
0867デフォルトの名無しさんNGNG
>>866
じゃあまずお前からだな。
0868デフォルトの名無しさんNGNG
OO嫌いな人＝OO理解できない自分の馬鹿さ加減をOOのせいだと
　　　　　　　　　責任転嫁しようとして必死の人たち。OOは良くないから
　　　　　　　　　わからなくても平気、と思い込もうとしている。

マジかわいそう。
0869デフォルトの名無しさんNGNG
思いこみの激しい>>868さんでした。

はい、次の方。
0870デフォルトの名無しさんNGNG
はい、では私の番。

今の時代OOできないっていうのは、４０過ぎて童貞のようなものです。
必死になるのはわかりますが、自分を相手にしない女をボロクソに言ったり、
セクース経験がある人に八つ当たりするのはやめてください。
僕らの世界ではそれが普通なので。
0871デフォルトの名無しさんNGNG
はい、では私の番。

今の時代Javaができないっていうのは、４０過ぎてスカトロ未経験のようなものです。
必死になるのはわかりますが、うんちを食う女をボロクソに言ったり、
うんちを食う経験がある人に八つ当たりするのはやめてください。
僕らの世界ではそれが普通なので。
0872デフォルトの名無しさんNGNG
返しになってない返しはむなしいのぉ
0873デフォルトの名無しさんNGNG
アホスレ。
0874デフォルトの名無しさんNGNG
なぜこれほどまでにアンチオブジェクト指向が立つのか理解すべきだ。
オブジェクト指向ﾏﾝｾｰスレが立たないのはなぜか。
あなたがたはよく考えねばならない。
0875デフォルトの名無しさんNGNG
マンセーというか、すでに生活の一部だから。
アンチスレが立つのは、理解できないフェードアウト組の必死の抵抗。
0876デフォルトの名無しさんNGNG
オブジェクト指向が生活の一部？ﾌﾟ
0877　NGNG
つーか、皆こだわり過ぎ。
構造化だろうが、OOだろうが、アスペクトだろうが、
客が望むものを作ったやつの勝ち。

0878デフォルトの名無しさんNGNG
>>877
いいこと言った。

早くて高くてうまい。これが理想。
0879デフォルトの名無しさんNGNG
おまえら継承って知ってるか？継承。
2つ継承して派生クラス作るのが通のやり方。
やっぱり効率がいいのだよ。
人間だって父と母から継承するだろ？
プログラムだって同じ。
おまえらアンチOOは可哀想だな（ｗ
0880デフォルトの名無しさんNGNG
>>879
＞2つ継承して
多重継承とその謎の継承方法は違うよな？
0881デフォルトの名無しさんNGNG
そうだけどどこが謎？
マイナーなデザパタだけどな。使ってみろ。
0882ＯＯ原理主義者 1NGNG
アンチOOよりアンチOO原理主義の方がウザイ。
0883デフォルトの名無しさんNGNG
一番ウザイのはOO過激派(通称かまって君)
暇なら書籍でも読め
0884デフォルトの名無しさんNGNG
OO過激派ってどんな人ですか？
0885デフォルトの名無しさんNGNG
>>884
>>881
0886デフォルトの名無しさんNGNG
>>883
わかったわかった。
構ってやるよ。暇なんか？暇なら書籍でも読め。
あー悪かった。遊んでやるからネタ振りしろ。
0887　NGNG
で、単体てすとどうしてる？
0888デフォルトの名無しさんNGNG
おーおーかげきは【OO過激派】
　　実際にシステム開発はせず、VB厨･C#厨･Delphi厨を攻撃することで、
　　日々のストレスを解消する一派。
　　ヒッキーが多く、実務経験がないため、机上の空論から抜けられない。
　　かまってもらいたくて、朝から晩までくだらないレスをする。

建久社新語辞典より
0889デフォルトの名無しさんNGNG
さすがは構造化爺さん。。。
お見逸れ致します。
0890デフォルトの名無しさんNGNG
このスレって本気なの？ネタ？
0891デフォルトの名無しさんNGNG
OO過激派の一人はVB厨叩くのはライフワークって言ってたから本気なんじゃねーの
0892デフォルトの名無しさんNGNG
＊＊厨っていうのは、＊＊を使う人のことなの？
0893デフォルトの名無しさんNGNG
>>892
使わない（えない）奴が妬んで暴れている。
0894デフォルトの名無しさんNGNG
オブジェクト指向がわからないヤツは、こんなところで
つまらんことわめいてないで、転職雑誌買いに行った
ほうがいいよ。お先真っ暗だよ、マジで。
0895デフォルトの名無しさんNGNG
>>892
定義など存在しない
0896デフォルトの名無しさんNGNG
優秀なSingletonがいれば、みんな幸せ。
0897デフォルトの名無しさんNGNG
>>848
>適材適所ってのがよくわからん。
>ほとんどの点でオブジェクト指向は最良の選択のはず。

同意。
0898デフォルトの名無しさんNGNG
おまえらのオブジェクト指向はデザパタを無理やり適用
してるだけだろ？
0899デフォルトの名無しさんNGNG
オブジェクト指向の概念を教えれ
0900デフォルトの名無しさんNGNG
オブジェクト指向について来れないのは旧式
0901デフォルトの名無しさんNGNG
そう旧式。サイコミュも搭載してないようなオンボロ。
0902デフォルトの名無しさんNGNG
>>901
１００年使えるはずだったのになぁ・・・。
0903デフォルトの名無しさんNGNG
>>1
継承とオブジェクト・コンポジション。
これだけは覚えなさい。
すべての基本です。
0904デフォルトの名無しさんNGNG
オブジェ食うと歯垢
0905デフォルトの名無しさんNGNG
結局具体的なことを書く奴がほとんどいないな。
まあ、抽象的な部分が大きいから、
はっきり書くのがためらわれるのは分からんでもない。
何書いたって叩かれそうだからな(藁

が、書かないでいたって話になんねぇから書く。
煮るなり焼くなり好きにしろや。が、ツッコミは具体的にな。
0906905NGNG
オブジェクト指向プログラミングとは、
ソフトを、オブジェクトと呼ばれる単位の塊と見て
設計・実装を行うソフトウェア開発手法である。

オブジェクトとは、広義には、
強い関連を持つ幾つもの処理を一つの区分にカテゴライズして
それを一つの統一された概念の単位と見たものであり、
狭義には、継承・多態・カプセル化によってそれらの単位を実装したものである。

カプセル化とは、データとそのデータに付随する処理を一体化し、
処理関数(＝メソッド)を通じてのみデータを変更できるようにする手法である。
規定外のデータ操作によるバグを減らすという、安全面での効果があるとされる。
また、カプセル化のみによるオブジェクトの実装は、抽象データ型とも呼ばれる。

継承とは、カプセル化によって実装されたオブジェクトの、
大部分は同じだが一部が異なるバリエーションを、
元となるオブジェクトに対して差分を実装する形で実装する手法である。
無駄のない差分実装により、実装効率面での効果があるとされる。
また、継承は、通例、多態の基礎となる。
0907905NGNG
多態とは、実体が異なる複数のオブジェクトを、
共通のインターフェースでアクセスする手法である。
処理の実装実体と、その処理を外部から参照する利用側実装との間の依存性を弱め、
ソフトウェアの設計の抽象化や、保守性の向上に効果があるとされる。
現在幅広く使われているオブジェクト指向プログラミング言語では、
継承に基づいた多態を実現している。
継承は原則としてオブジェクト同士の木構造の関係を作り出すが、
その関係で根にあたるオブジェクトの性質を、
葉に近い下位のオブジェクトも備えているので、
上位のオブジェクトの一種として下位のオブジェクトをアクセスできる。
下位のオブジェクトの実装が変化しても、
上位オブジェクトの一種、という位置づけを崩さなければ、
これを利用する側のコードを変更する必要はない。

Java/C#/C++/ObjectPascal などの言語では、
クラスとインスタンスという概念に基づいてオブジェクトを実装する。
これは、型と変数の関係に対応するものであり、
オブジェクトの実体の内容を定義する雛形がクラス、
その雛形に基づいてメモリ上に実体化されたものがインスタンス、と呼ばれる。
クラスとインスタンスという区別を設けない言語もある。
0908905NGNG
一般的なオブジェクト指向プログラミングの要素技術である、
継承・多態・カプセル化、そして、クラス・インスタンス、は、
いずれもオーソドックスな開発テクニックに同類のものを見ることができる。
しかし、それらを連携させたオブジェクトという単位で考えることで、
個々のテクニックの利点をより容易に活かせるところに意義がある。
逆に言えば、個々のテクニックに執着するあまり、
それらの連携をよく意識することができなければ、
オブジェクト指向プログラミングとは言えない。

オブジェクト指向プログラミングでは
ソフトを構成するであろう個々の機能の全体の中に、
それらの機能の間の関連性を見いだし、分類・整理し、
オブジェクトという単位に仕切り分けてゆかねばならない。
このような事柄を前提とする性質上、
仕切り分けを必要としないほどに規模が小さい場合や、
個々の機能の間に関連性があまりない場合や、
逆にあらゆる部位の間に深い関連性があり分割できない場合、
などには適用が難しい。
一般には、ソフトの規模が大きい方が適用しやすいと言える。
無理な適用は実装を肥大化させ、また硬直させもするので、
要不適を常に意識し、杓子定規にオブジェクト化しないことも重要である。

以上。
0909デフォルトの名無しさんNGNG
いまさら何をいってんだコイツ。
0910905NGNG
>>909
お前らが散発的にこそ言えど決してひとまとめにしては言わなかったこと。
0911ＯＯ原理主義者NGNG
>>910
アンチOO原理主義の典型的な症状がでています。

治療が必要です。
もう、手遅れかもしれません(藁
0912905NGNG
>>911
ツッコミは具体的にな：Ｐ
0913ＯＯ原理主義者NGNG
そう言われてもたくさん書いてあるので
どこからツッコメばいいか…
0914905NGNG
>>913
どこからでも。好きなだけ。
必ずしも応じるとは限らんけどな。
それと、俺個人のOOP観を語ってるわけじゃないから
そこんとこ勘違いしないように。
新人向けの概説テキスト書けと言われたら、って感じの内容。
0915デフォルトの名無しさんNGNG
予防線を張る。
逃げ道を確保する。
0916905NGNG
>>915
言われると思ったヽ(´ー｀)ノ
そういうわけで俺様のOOP観を語っておいてやろう。

　　オブジェクト＝複製可能な状態付き関数

究極にはこれ。これの塊でコードが書けるならOOPだと言っていいね。
問題は、それらのオブジェクトが美的感覚に見合うかどうか。
世間のPGが抱いているOOPへのイメージは結局はそこに機軸がある。
自分のオブジェクト間つうかコードの世界観があって、
それに適合するものを自分のOOPとして主張する。
そんなもん当然千差万別だから、人によって意見が食い違う。
歩み寄りの意思がなきゃOOPの話なんてできやしないよ。違うか？
0917ＯＯ原理主義者NGNG
>>914
オブジェクトの定義が不完全です。
0918デフォルトの名無しさんNGNG
抽象思考が足りんな。
0919905NGNG
>>917
じゃ補うなり置き換えるなりして代案を出してくれ。

>>918
やりすぎても害が大きいと考えるようになったんだ。
一例だが、例えばデザパタに出てくるパターンは、
オブジェクトと見るよりもtemplate関数と見た方が面白い。
そう気付くと、あれをオブジェクトとして見る必然性が薄れる。
0920デフォルトの名無しさんNGNG
>>919
GoFに出てきてるようなデザパタは
オブジェクトとして見ないのなら意味のないものが多いですが、何か？

オブジェクトの定義については、
オブジェクトは内部状態を持つ必要はないし (関数型言語ベースのOOPLもある)
継承を持つ必要もない (継承のないOOPLもある)

メッセージを送ると何か応える実体。これで十分。
0921(;´Д`)ﾊｧﾊｧNGNG
abstruct class >>918 {}
class >>918 {virtual void pure() = 0;};
0922デフォルトの名無しさんNGNG
>>916
それってclosureじゃん
0923デフォルトの名無しさんNGNG
>>922
まあ、
closureはよりピュアなobjectとも言えるし、
objectは豪華装備なclosureとも言える。
0924デフォルトの名無しさんNGNG
ものはいいよう
0925デフォルトの名無しさんNGNG
closureは処理（関数）主体なのに対して、
オブジェクトはデータ主体だと言う違いじゃないの？
0926デフォルトの名無しさんNGNG
>>920
>メッセージを送ると何か応える実体。

それでは（用語が違っているだけで）実質上、
関数との違いでさえ全く表現されていないと思われ。
0927デフォルトの名無しさんNGNG
代替案を出せない奴は無視。
0928デフォルトの名無しさんNGNG
じゃあ>>927の意見も評価に値しないと。
0929デフォルトの名無しさんNGNG
>>925-929
無視
0930デフォルトの名無しさんNGNG
元気があるのはいいことじゃ。
0931デフォルトの名無しさんNGNG
アンチOO原理主義って、
アンチ・OO原理主義ですか？それとも
アンチOO・原理主義ですか？
0932デフォルトの名無しさんNGNG
>>931
アンチOO原理・主義です。
0933デフォルトの名無しさんNGNG
朝鮮　民主主義　人民共和国
朝鮮民　主(体)主義　人民共和国
0934デフォルトの名無しさんNGNG
おまいら、Objective-Cをはやらせてくれ！
0935デフォルトの名無しさんNGNG
ObjCのObjectはRubyもJavaも真っ青な重いオブジェクトだから、
俺の中では屑言語。
0936デフォルトの名無しさんNGNG
おまいら、Cを改造した言語をつくるより、
lispを改造した言語を作った方がいいとおもいませんか？

まぁ、漏れはSchemeで十分だが。
誰か高速なコード生成するコンパイラを作ってたもう。。。
0937デフォルトの名無しさんNGNG
コンパイラを作るのはいいんだけど、
マクロが扱いが死ぬほど難しくないか？
フローを追っていって、厳密に解決出来ないなら、
結局内部にインタプリタを用意する必要があるだろ。
0938デフォルトの名無しさんNGNG
>>936
まぁ、ちょっと興味あるな。
C以外の言語からなんかいいのが派生したら万々歳。
0939デフォルトの名無しさんNGNG
>>937
だからプリプロセッサでやるんじゃないの？
0940デフォルトの名無しさんNGNG
>>936
Flavorはどうよ？
0941デフォルトの名無しさんNGNG
>>939
プリプロセッサって何スか？
Lispのマクロは動的展開されるからこそ意味があると思うんですが。
0942デフォルトの名無しさんNGNG
あ、>>937は936へのレスか。失礼失礼。
0943よNGNG
>>905
なんつか、「オブジェクト指向プログラミングとは」ではじまった
文章にしては、内容が静的な動的型付けの言語の特徴の説明になってるんだよね。
だから、突っ込み方が多くて、逆につっこみづらい。
細かく区切ると、それぞれは、間違ってはいないんだけど…
0944デフォルトの名無しさんNGNG
>>943
言わんとすることは分かるつもりだが。。。
それを説明しちゃうとOOP分かってる人にしか分からない説明になりそうな罠。
0945デフォルトの名無しさんNGNG
>>943
すまん、「静的な動的型付けの言語」ってのが何を言いたいのかよくわからんのだが…
動的型付けはいいけどさ、静的なって何が静的な？
0946デフォルトの名無しさんNGNG
>>945
Javaのような、言語としての性質は静的な物だって事じゃないの？
0947デフォルトの名無しさんNGNG
>>946
言語としての性質は静的って、何の性質について？
Javaは静的型付けだけど、「静的な動的型付け」って言ってるからなあ。

ヨクワカラン君でスマソ。
0948よNGNG
動的型付けってのは、変数の型が実行時に決まるってこと。
で、それが静的っていうのは、変数の取りうる型が、宣言した型か、
その派生経路に出てくる型に限定されてること。
C++やJavaは、これ。
対してSmalltalkやPythonは変数があらゆる型を取れるから、動的。
>>906　の、継承が多態の基礎っていうのは、静的な動的型付け言語の特徴ね。
selfみたいに動的な動的型付けの言語で、継承がなくても多態のある言語もある。
0949よNGNG
>>944
ふつう、相手の知らない概念を、相手の中に形成するときって、
たとえ話をしながら、相手の知ってる概念との差分で理解してもらう
って多いけど、OOPの説明って、たとえ話の作り方のたとえ話みたいに
なっちゃうから、つか、OOが「メタたとえ話」みたいな感じだから、
説明むつかしいんだと思う。

だから、短くすると、わかってる人にしかわからない説明になるのは、
しょうがないって気がする。
でも、正しく説明されてれば、理解の目標には、なると思う。
0950デフォルトの名無しさんNGNG
> 正しく説明されてれば、理解の目標には、なると思う。
結局のところ、「理解できた奴／理解できない奴」には断絶がある
いくら正しく説明してもある種の悟りが無いと理解できないと思う。

例えば自転車
自転車に乗れない奴が乗れるようになるにはある種のコツが必要で、
乗れるようになってしまうと、何故自分が自転車に乗れなかったのかを
思い出せなくなる。
0951ＯＯ原理主義者NGNG
>>919

object
　物，物体
　対象
　目的（のもの）

某英和辞典より。

>>931

アンチ・OO原理主義です。

OOを理解していると思い込み
アンチOOとOO原理主義と対立するOO厨のこと。

OO厨で十分か(w
0952ＯＯ原理主義者NGNG
>>948
ふつう次のように分類する。

静的型付け 動的束縛 : C++ Java
動的型付け 動的束縛 : Smalltalk Python Self
0953デフォルトの名無しさんNGNG
>>950
それは言える。
0954デフォルトの名無しさんNGNG
動的型付けって結局Javaですべての変数の型をObject型にした状態と一緒？
いやintとかはObject型じゃないから、VBでVariant型しか使わない状態と一緒？
0955デフォルトの名無しさんNGNG
新スレまだぁ？
0956デフォルトの名無しさんNGNG
教えれスレなのに、教えてくれる人がいないからもう次はなし
0957ＯＯ原理主義者NGNG
>>954
ちがう。

Javaだとすべての変数の型をObject型にすると
サブクラスのオブジェクトのメンバを呼び出せなくなる。
0958よNGNG
>>952
なにを「ふつう」と呼ぶかにもよるけど、「動的束縛」っていうのは、
lexical scopingと同意の静的束縛の反対語の意味があるのを踏まえた
うえで言ってる？
0959デフォルトの名無しさんNGNG
で結局、「静的な動的型付け」ってのは何なんだよ～！
0960デフォルトの名無しさんNGNG
俺は「静的な静的型付け」や「動的な静的型付け」の
オブジェクト指向言語があるのかが気になる。
0961よNGNG
＞「静的な静的型付け」や「動的な静的型付け」のオブジェクト指向言語
たぶん、無い（ｗ
0962デフォルトの名無しさんNGNG
>>961
え？
動的束縛な静的型付けオブジェクト指向言語は多数実在しますが。JavaとかEiffelとか。
それに静的束縛な静的型付けオブジェクト指向言語は、C++でvirtual宣言をしなければ、
静的束縛かつ静的型付けになると思いますが。

逆に、静的束縛な動的型付け言語ってのが存在しないじゃないのか？
0963よNGNG
「動的束縛」をどういう意味で使ってるか、わかってるんだけど、
それは、旧来のOOPLの狭義の動的束縛なのね。
もっと一般的には、たとえばPythonで
a=1
def foo(b):
　return b*a
def zoo(c):
　a=5
　return foo(c)
だけ示した場合、zoo(3)　が3を返すのは「静的束縛」なのさ。

それから、静的型付けっていうのも、より一般的には、変数の型
（というか、式の型）が変わらない事を言うんだ。
だから、静的型付けの言語は、たいていの場合、型安全を保障する
いわゆる「強い型付け」の言語なんだよ。
0964よNGNG
だから>>961と>>962は、じぇんきぇんかみ合ってないの。
0965デフォルトの名無しさんNGNG
vtableとかの処理系の実装ってどうやって勉強すんの？
0966デフォルトの名無しさんNGNG
>>965 既存のコンパイラにアセンブラソース吐かせるか、逆アセして
0967デフォルトの名無しさんNGNG
963がよくわからん
OOでただ束縛といったら、メッセージとそれによって起動されるプログラムを対応付けることだと思うんだけど、
もしかして、OOという文脈がなければ（＝一般的）こんな使われ方もしますよー、とか言ってる？
0968よNGNG
OOの文脈が前提になるのがいやだから>>943のような書き方したんだよ～
とか、いってます。
（とくに、関数型言語とかがOOPをサポートしてる現状では）
0969デフォルトの名無しさんNGNG
>>968
OOの文脈だろうが何だろうが、scope rules on implicit variable declarationをdynamic bindingと呼ぶなんて聞いたこともない。
ソースきぼんぬ。

>>965
StroustrupのC++関係の論文でも読み漁るといい。
0970よNGNG
http://sky.zero.ad.jp/~zaa54437/programming/concepts/index3.htm#d1
http://www.ito.ecei.tohoku.ac.jp/~izumi/TISL/doc/ISLISP/j_scope.html
http://www.sun-inet.or.jp/~yaneurao/intensive/spt1.html
http://www.hpcs.is.tsukuba.ac.jp/~msato/lecture-note/comp2001/comp3/lecture3.html
など。
0971デフォルトの名無しさんNGNG
>>970
乙curry!
0972967NGNG
まあ分かったけど、「静的な動的型付けの言語」とか言ったら
OOの文脈ですら通じなくなるので、
とりあえずOOの文脈で通じる言葉でしゃべっとけ。

>>948
>動的型付けってのは、変数の型が実行時に決まるってこと。
>で、それが静的っていうのは、変数の取りうる型が、宣言した型か、
>その派生経路に出てくる型に限定されてること。
>C++やJavaは、これ。
C++やJavaは、変数の指すオブジェクトのクラスが静的に決まるような
厳しい静的型付けの言語ではないけど、
OOではポリモーフィズムをサポートする関係上
そういう静的型付けするということはありえないので、
OOの文脈で静的型付けといったら、Javaみたいな言語のことを言う。

本当は、
C++やJava＝半動的半静的型付け
Smalltalk＝完全動的型付け
とか呼んだらいいのかも。
0973デフォルトの名無しさんNGNG
>>972
＞OOの文脈ですら通じなくなるので、
ＯＯ以外の文脈しらないやつがエラそうに（ﾌﾟﾌﾟ
0974デフォルトの名無しさんNGNG
>>973
OOのスレでOOでは誤解される事がほぼ確実な用語を補足説明なしに使うよりは
随分とマシなのでは？
0975デフォルトの名無しさんNGNG
必死だな…
0976デフォルトの名無しさんNGNG
>>975
遊ばれてるという事にやっと気付いたようだね。ぷ。
0977デフォルトの名無しさんNGNG
あ～あ…
ageちゃお。
0978デフォルトの名無しさんNGNG
>>977
こっちがあ～あ･･･だ。ageんなや
0979デフォルトの名無しさんNGNG
記念ﾊﾟﾋﾟｺ(_A_)
0980デフォルトの名無しさんNGNG
で次スレ早く立てろ。
0981デフォルトの名無しさんNGNG
次スレなどいらん。類似スレが多数あるのでそこを再利用しろ
OOは再利用が得意なんだろ？
0982デフォルトの名無しさんNGNG
決まったとか思ってんの？それ
0983デフォルトの名無しさんNGNG
>>981
じゃあ新スレでこのスレを継承します。
0984デフォルトの名無しさんNGNG
ちゃんと継承するってことを明示しろよ。
0985デフォルトの名無しさんNGNG
>>984
オブジェクト指向の概念を教えれ 2重継承目

って感じ？
0986デフォルトの名無しさんNGNG
>>985
:
0987デフォルトの名無しさんNGNG
>>986
extendsを一押ししておく。
0988デフォルトの名無しさんNGNG
やだやだ。Inheritsがｲｲ
0989デフォルトの名無しさんNGNG
こんな些細なことからOO厨同士の確執は始まった・・・
0990デフォルトの名無しさんNGNG
記念ﾊﾟﾋﾟｺ<-_->
0991どすの？NGNG
うん
0992デフォルトの名無しさんNGNG
992
0993デフォルトの名無しさんNGNG
>>988
VBかよ！
0994デフォルトの名無しさんNGNG
>>993
Delに謝れ。
0995デフォルトの名無しさんNGNG
995
0996デフォルトの名無しさんNGNG
996?
0997デフォルトの名無しさんNGNG
オブジェクト指向　＝　プログラム方法論の一種
0998デフォルトの名無しさんNGNG
なんでもいいから次スレ早く立てろ
0999デフォルトの名無しさんNGNG
次スレなどいらない。>>998もいらない。
1000デフォルトの名無しさんNGNG

　＿＿＿ヽヽ 　　　ヽ丶　 　　　　　 （´ (´　　　{-―-/　(´⌒ } 　　 /./　 l　　　　　(´⌒(´
　　　　／　　┼─┼　 　===＝＝　 .(´　　　　 l／l ﾉ} （　　　}-‐''´ﾚ'　　/　 (´⌒´
　　 , く　　　　　　 /　{＼,　_,,..::--――――- ''´　 ｀､l　　　　 ヾ_ツ　 　/　(´
　／　 ヽ　　　　／　　}　 ｀´　 o　.,-‐―┐ o　　 　 .丶　　　　　　ヽ 　　｀、　
　　　　　　　　　　　　 l　　　　　 ./　　　　l 　　　　　　ヽ　　　　　　　ヽ 　　ヽ　　　　　　　　　　　(´⌒(´ (´⌒(´
　　　　　　　　　　　　 {　　　　　ム-―‐-┴　　 　　　　`、.　(´⌒´ 　.〉―‐-〉　　　　　(´⌒(´ (´⌒(´
　　　　　　　　　　　　/　　　　　　 ._,,=-::.,,_　 　 　 ∧ ∧　　　 　　　ノ　　 ./　　　　(´⌒(´
　　　　　　　　　　　　{,,__,,....::-‐''"´/l　　:::::｀`ヽ.　（ﾟДﾟ,,）｀/ヾ／､／￣｀ヽ/　　　(´⌒´
　　ああん　　　　　　i　'　　　....:::::/ l:::......　,､　 :::⊂　⊂ ヽ　/　l l i,／｀`i./　 ≡(´　　　　　　　　(´⌒(´ (´⌒(´
　　こすれる.　　　　 l..::{::::/i::::ﾊ::/　 i::∧:::ハ:::::::/　　 /～:丶_　｀ﾑ-=ｯ　l　　　　　　　　　　(´⌒(´
　　　　　　　　　　　　{/{::/l'ヾﾉ V　　 ﾘ　V　 ヽ,:∪　∪::::::::::::ヽ-‐ 　　l |　L_　　　　　　　(´⌒(´
　　∧∧　 　 ）　　_＿__l/.i　　.;:=　　　　　 =ｭ　{　　 .{::::::::,､::::lヾ　＿　 ヾ.､　7　　　≡(⌒⌒(⌒⌒
⊂（ﾟДﾟ⊂⌒｀つ￣　ノ　l. {　,.,.　　　 　 　　 ,.,. .{　/　ﾄ､::::{ ＼l　　　 ￣　//〈　≡≡(⌒⌒
　　｀''ーヾ､,,__,,ﾑ,,＿_＿,,{ﾑヽ、　　ヾ､￣）　　　 .〉　｀　　ヽ|　_ﾉ=＝=::::;;;ﾑ＿〉≡(´⌒
　　　　　　　　　　　　　　　 　 ｀　　_ 　 　＿,,....-ヽ、　　　ノ~
　　　　　1000ゲトー
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。