オブジェクト指向スレ
レス数が1000を超えています。これ以上書き込みはできません。
0001憂鬱な名無しさん
NGNG・オブジェクト指向についての疑問、応答
・OOP言語、UML、分散オブジェクト、デザインパターン等
などなど、オブジェクト指向についてのスレッド。
0002関数型信者
NGNG0003デフォルトの名無しさん
NGNGになるらしい。ｳｿ
0004憂鬱な名無しさん
NGNG・プログラムの再利用がしやすい。
・変更が局所化されるので、仕様の拡張や変更に対応しやすい。
・プログラムの構造が把握しやすい。
・状態の管理に優れている。
とくに状態の管理という視点は関数型言語に対するアドバンテージだ
と思います。逆に関数型言語のOOに対するアドバンテージってなん
ですか？
0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNGうむ、確かにベクトルが違うと比較は難しいな。
正反対の方向で進化したベクトルの双璧という感じがする。
しかし、どうしても比べたくなって来るのもまた事実。
0007
NGNG＞・プログラムの再利用がしやすい。
再利用できた事の方が少ないが・・。
0008デフォルトの名無しさん
NGNG設計が上手くないと、てんで使い物にならないんだろ？
それって実はオブジェクト指向自体に欠陥があるからじゃないか？
仕様変更に対応しやすいってのも疑問だな。設計を変える
と根本から作り直しだろ。設計のやり方もわかりにくい。
ただ騒がれてるから信者が増えただけのような気がするんだよな。
0009デフォルトの名無しさん
NGNG0010デフォルトの名無しさん
NGNGOOPだと、ポリモーフィズムができるけど、関数型でもできるの?
それともまったく違った方法論なの?
0011デフォルトの名無しさん
NGNGLispはそもそも変数に型が無いから、ポインタと言わず
変数に何でも代入できる。
Haskellは型がある関数型言語だけど、型クラスの
仕組みがポリモーフィズムに対応すると思う。
0012デフォルトの名無しさん
NGNG＞設計を変えると根本から作り直しだろ。
OOがあってもなくても同じ。
0013デフォルトの名無しさん
NGNGうーん、その類の意見よく聞くけど
設計テキトーにやって何とかなる考え方ってプログラミングに限らずあるかなぁ・・・？
設計していく上で、うまくいく設計の指針みたいな物はやっぱり必要だと思うし。
OO詳しくないから結構テキトーに言ってるんだが、そんな気がする。
0014デフォルトの名無しさん
NGNGあっというまに広まったけど、オブジェクト指向は、なかなか
そうはならない。
オブジェクト指向って、一般ピープルにはむずかしすぎるんだよ。
オブジェクト指向、破綻説に一票。
0015デフォルトの名無しさん
NGNGC++がグローバル変数とグローバル関数とパブリックなデータメンバを
使用できない言語仕様にしたらあっという間に広まっただろう。
0016デフォルトの名無しさん
NGNGやりやすい言語とやりにくい言語の違いはもちろんあるが、
かしこいプログラマであれば、ダイクストラが構造化を唱える以前から
無意識のうちに構造化していただろう。
でも、オブジェクト志向だとそうはいかない。
オブジェクト志向のほうが明らかにむずい。
0017デフォルトの名無しさん
NGNG>構造化が広まったのはC言語の仕様のせい。
それは違うだろ。
当時は、COBOLやFortranような言語でも、構造化の構文が
取り入れられたら、しっかり現場でも使われていた。
オブジェクト指向は、COBOLやFortranに取り入れられても
現場では広まらなかった。
本質的に難しいんだよ。オブジェクト指向は。
0018defaultの名無しさん
NGNGメソッドを整えても、俺しか使わない。
俺のクラスから派生などしない。
良く知りもしないクラスの関数を上書きするたび、
そのうち何かあるなと思う。
0019defaultの名無しさん
NGNG構造化しないと、設計は無理。
オブジェクト指向だと、設計が面倒。
0020関数型信者
NGNG下の三つはわかるのですが、
OO だと再利用しやすくなるってのはなんででしょ？
あと2番目に挙げられていることは、要はカプセル化だと思うのですが、
それに関しては OOP言語でなくとも容易に出来ますよね。
> 逆に関数型言語のOOに対するアドバンテージってなんですか？
なんでしょうねぇ？
>>11
型クラスが無い ML でもポリモーフィズムと呼ばれるものはあるよね。
まあ、Haskell のほうが柔軟な気もするけど。
>>14-17
構造化は思考の平淡化って感じだしね。
その点、OO は問題を分析して何かを抽出し、そこから基礎を築き
その上にプログラムを築くみたいな感じ(ちょっと謎)だもんなぁ。
0021デフォルトの名無しさん
NGNGなんでしょうねぇ？で、関数型の信者務まるのかよ。
0022
NGNG真っ平らに並べたプログラム書いて、（意味判らない人は該当）
クラスは単なるサブルーチンに使ってるだけ。
でもってＯＯを理解したつもりになってるＯＯオタって多そう。
0023defaultの名無しさん
NGNGクラスライブラリ作るならまだしも、普通のアプリだとねぇ。
0025デフォルトの名無しさん
NGNGＯＯにのっとって設計したら 使う分にはもう極楽だよ
再利用性もとても良い 自分で設計して極楽鳥～
だけど設計と実装が地獄だyo
0026
NGNGつうかメモリにバラバラにデーター配置してたら何がなんだか
判らなくなる。
0027意味は無い
NGNG0028defaultの名無しさん
NGNG（構造化の階層を、クラスの派生で補えるわけもない。）
両者を対峙するものとして比較したのではなく、必然性で比較したのです。
002925
NGNG>むしろ不慣れな分だけ生産性が落ちるというのが現実です
クラス資産命だもの＞ＯＯ
言葉だけＯＯにしても無意味だyo
0030
NGNGあるのは
１）データ操作や入出力の基本関係
２）同じ様な物を作ってる場合
だけ。
プログラムの内、アプリケーションの仕様依存部分が
特定のアプリケーション固有のものなら一般性はないから
再利用できない道理。
0031
NGNGというのはＯＯの再利用性とは違う。
0032デフォルトの名無しさん
NGNG良かれと思って新技術を導入したらかえって以前よりも生産性が落ちることは珍しくない。
難し過ぎて使いこなせる人が少なければ、
理屈の上では理想的な技術であったとしても邪魔なだけ。
0033
NGNG理屈自体が宣伝する為に作られただけだから。
0034デフォルトの名無しさん
NGNGまだプログラムについてよくわかってないのですが……
どんなものに使われているのかもわかりません
できるかぎり詳しく教えて欲しいです。
0035デフォルトの名無しさん
NGNGでも、見てもわからんと思うよ。
http://yougo.ascii24.com/gh/07/000738.html
0036デフォルトの名無しさん
NGNG動作部分は軽く作ってあとから定義しろってことです。
0037デフォルトの名無しさん
NGNG0038デフォルトの名無しさん
NGNG説明してやれ。
0039デフォルトの名無しさん
NGNGオブジェクト指向的アプローチからは手の出しようが無くなる
よね。
どんな設計がタコでもちゃんと動いてる部品があれば、そいつ
に手を加えず継承して後から再利用出来るようなOO言語というか
手法って確立出来ないかな
windowsでいうサブクラス（メッセージフック）みたいにさ
0040デフォルトの名無しさん
NGNGオプジェクト指向は、プログラムする時の考え方・方法論のひとつ。
構造化プログラミングでは、「どのように行うか」が中心だが、オブジェクト
指向では、「誰が行うか」を中心に考える。
ある機能を実現するプログラムを考えるとき、その機能を分担する「もの」
=オブジェクトを考えて、そのオブジェクトに仕事をさせるということ。
例えば、ボタンを押すとメッセージを表示するダイアログを作ろうとする
と、機能中心で考えれば、一連の流れとして、「ボタンが押されるのを
見張っている」「ボタン押されたら、メッセージを表示する」「また、
ボタンを見張る」といった流れだと思うけど、
オブジェクト指向では、「メッセージを表示するのはボタン」「ボタンを
押すのはユーザー」と考えて、ボタンオブジェクトにメッセージ表示の
責任を持たせる、といった考え方をする。
換言すれば、機能中心で考えれば、ボタンはユーザーの入力を受け取るため
の仕掛けに過ぎず、入力の受け取り、受け取った後の処理は、そのボタンを
見張っているコードが責任を持つけれど、
オブジェクト中心で考えれば、「押されたら何らかの行動をするボタン」を
作って、後はほっとく、という感じかな。
だから、ウインドウシステムのような、イベント駆動型のプログラムには適
している、というのはわかりやすいんじゃない。
もちろん、それだけじゃなくて、プログラム全般に有効なんだけど、その説明
は本でよんでね。
0041デフォルトの名無しさん
NGNGベースにしたソフトが死ぬ程出回ってるわけで
再利用性が高いことが証明されまくっていると思う。
0042デフォルトの名無しさん
NGNGオブジェクト指向なんて無視して、僕が言うとおり
何かするオブジェクトを作ったら動作部分は軽く作っておいてあとから継承したオブジェクトで定義すればいいんです。それが有効に使える技です。
あとは秘密です。
0043デフォルトの名無しさん
NGNGクラスライブラリ＝オブジェクト指向 じゃないかもしれないな という線で
0044デフォルトの名無しさん
NGNGどうやって実装しているかそのクラスを使う人に見えてはいけません。
あくまでも、開発者の視点ではなく、ユーザーの視点でクラスのメソッド等を決めなくてはいけないです。
0045
NGNG＞どうやって実装しているかそのクラスを使う人に見えてはいけません。
Javaはそれやってるから糞言語なんだよねー。
見えてるというか「さあ見ろ！見ないと使えないぞ！」って構造。
ユーザーが使うクラスは Ａだけなのに、使いたければ
継承元のクラスと、その継承元のクラスと、継承元のクラスと、継承元のクラスの
メソッド（メンバ関数）を参照してね。とかやってる。
ＳＵＮの設計者は単なるクラスヲタであってＯＯＰの設計をしていないと思う。
0046デフォルトの名無しさん
NGNG0047デフォルトの名無しさん
NGNG0048デフォルトの名無しさん
NGNG0049
NGNGマシ、というのであれば、ＭＦＣの方がマシ。
0050初期不良
NGNGBeOS の標準 IDE のクラスライブラリは使いやすかったなぁ
0051
NGNG激しく同意。
別に全てのクラスが一つの基本クラスから派生してなきゃいけない理由
なんか無い。
0052デフォルトの名無しさん
NGNGそれはあなたが MFC に慣れているというだけじゃ？
Java はけっこうコダワリ OOP という気がする。
OOP という話なら、MFC は糞。
0053デフォルトの名無しさん
NGNGそこかしこにこっそりデザインパターンもちりばめられている。
BeOS のそれとも似ているかも。
0054デフォルトの名無しさん
NGNG>なんか無い。
んなこたない。
言語仕様として基本クラスのないOOPLなんてC++くらいだよ。
0055デフォルトの名無しさん
NGNG0056デフォルトの名無しさん
NGNGC++ 自体は君が思っているほど OOP べったりな言語ではない。
それに静的な言語と動的な言語をごっちゃにするのもどうかと思ふ。
0057デフォルトの名無しさん
NGNG>C++ 自体は君が思っているほど OOP べったりな言語ではない。
そんなことは百も承知だがここはOOPスレだろ(藁
それに今時の言語は動的・静的の区別は
かなりあいまいになってきてるから
ごっちゃにしないのもどうかと思ふ。
0058
NGNGＭＦＣのSerializeとＪａｖａのSerializableの説明の比較をしてみよ。
ＭＦＣの方はそれ読んだだけで組めるけど、（ＭＳＤＮ）
Javaの方はあの説明だけでは（ＡＰＩドキュメント）
「結局自分で実装するのか？」（説明文が糞）
「どうやって実装するのか」（他のクラスの事だから？触れていない）
さっぱり判らんぞ。
0060
NGNGクラス原理主義者発見！
Ｏｂｊｅｃｔ基本クラスなぞＯＯとは関係無いぞ！
0061
NGNGじゃあStringの基本クラスにCharクラス持ってきて使ってね 藁
0062デフォルトの名無しさん
NGNGそれじゃ設計じゃなくてドキュメントの問題じゃん。
0064デフォルトの名無しさん
NGNG0065デフォルトの名無しさん
NGNG>>オブジェクト指向という思想
について解説お願い。無視するかどうか、知ってから考えたいので。
0066デフォルトの名無しさん
NGNG0067デフォルトの名無しさん
NGNG作られた電気に区別はなく、利用者には区別のしようもないという事では？
006866
NGNG0069横レス
NGNGオブジェクトからオブジェクトにデーター渡すだけで必要な
プログラム動作が得られるような構造。
例：テキストエディタが作りたければ
KeyBoardObject →データ→ DisplaｙObject
でエディタが完成する様に両方のオブジェクトをつくればいい。
DisplaｙObjectは他の入力（ムービーファイルやマウスドロップ）
にも対応す汎用性を持っていなくてはいけない。
0070
NGNGにも対応する汎用性を持っていたほうがいい。 ○
0071デフォルトの名無しさん
NGNGOOP的にはそうだがOO的には「オブジェクトにメッセージを送ることで」
この概念のレベルと実装のレベルがごっちゃにされやすい。
0072デフォルトの名無しさん
NGNG...
007366
NGNGいや。
0074
NGNG出ましたか。
出ましたね。
信者登場ですね。
0075
NGNG「メッセージ」と呼ぶ奴いたら病気。
0076デフォルトの名無しさん
NGNG007765
NGNG「原子力発電」=オブジェクト指向テクニック、「議論」=思想、という
ことですか。
思想はいらないから、テクニックはどんどん使えということ。つまり、
OOPしろということですね。了解。
>>69
レスありがとうです。
今いち理解が及びませんが、勉強してみます。
0078
NGNGメッセージしか書いていないんじゃない？
0079デフォルトの名無しさん
NGNGOO信者だけど何か？
分析・設計段階ではメッセージでいいじゃん。
でもまあ、データ中心なプログラムとは相性が良くないね。
そういうのにはDFDでも使うべし。
0080デフォルトの名無しさん
NGNG理解できなかったら上手く使えるわけも無い。
そういうやつがOO使えるやつを批判して、OO使うなという。
なんのことはない、OO使えるやつの足を引っ張ってるんだよ。
OO否定するやつは世間に迷惑かけてる害虫なんだよ。
0081java厨房
NGNGメッセージは、オブジェクトのメソッドの呼び出しでしょ。
データ自体がメッセージなの?
0082デフォルトの名無しさん
NGNGデータを包んだオブジェクトの参照がメッセージに乗って運ばれる。
0083
NGNGＯＯのクラス図はＤＦＤだよ？
0084デフォルトの名無しさん
NGNG0085デフォルトの名無しさん
NGNGUMLの分析段階でのクラス図をDFD代わりに使うってのなら分かるが。
0086デフォルトの名無しさん
NGNGクラス間の継承関係と委譲関係を図にしたものじゃない？
OOPプログラムの仕様書に、それが無いと困ると思うが。
0087
NGNG0088デフォルトの名無しさん
NGNG図というとUMLしか思い浮かばなかった。見聞が狭くてすまん。
0089デフォルトの名無しさん
NGNG0090
NGNGＯＯはオブジェクト指向概念。
ＯＯＰはＯＯを元に作られた、という体裁を取っているけど、
本当はＯＯはＯＯＰの後から適当に作られたインチキ概念。
物理学でいうところの原理に相当するものが欲しかったんだろうね。
0091デフォルトの名無しさん
NGNG構造体が便利だから操作する関数も一緒に構造体にぶち込んだら
クラスができました！(･∀･)って感じですか？
違うでしょうね(^_^; すいません。
0092デフォルトの名無しさん
NGNG0093
NGNG関数ポインタね。
0094デフォルトの名無しさん
NGNGC++なら不要であれば自動削除される
0095デフォルトの名無しさん
NGNGOO はオブジェクト指向
OOP はオブジェクト指向プログラミング
OOPL がオブジェクト指向言語
じゃないの？
0096デフォルトの名無しさん
NGNGSimulaしらんの？
0097defaultの名無しさん
NGNG継承重視で設計すれば、メンテナンスが楽？
仕様変更があったら、ソース変更した方が早いでしょ。
そもそも、オーバーライドだけじゃ対応できないし。
プログラムがわかりにくくなるだけ。
オブジェクト単位なら、汎用性がある？
共通サブでもないアプリに、汎用性は必要ない。
インターフェイス増やして、工数がかさむだけ。
クラスライブラリの場合、派生させて使用するのが前提だし、
汎用性が必要なのも当然。
しかしアプリの場合、そんな必要は元々無い。
0098デフォルトの名無しさん
NGNG仕様変更のときに普通にソース変更なんかやっていては、あちこちに
変更の影響が波及してバグが発生しやすくなるし、大変だよ。
オーバーライドで対応できないのはもともと分析が悪いか、根本的に大
きすぎる仕様変更があった場合だけで、別にオブジェクト指向が悪い
わけじゃない。
それに、オブジェクト指向分析は何も難しいことじゃなく、現実を
そっくりそのままシミュレーションするように考えればいいだけ。
逆にオブジェクト指向を使わないほうが、指針が無いだけにかえって
安心感が無いな。
アプリに汎用性が必要ないってのもおかしな議論で、万が一に備えて
万全を期すのがいいに決まってる。
0099デフォルトの名無しさん
NGNGその他人もオブジェクト指向の教養が無いと駄目なこと。
その意味で汎用性が無くなる。
0100
NGNGゆえにＯＯは机上の空論。
汎用性のあるアプリなんか作ってるのは安易な仕事やってるだけ。
0101デフォルトの名無しさん
NGNGああ、まったく、どいつもこいつもお手軽症候群だ。
0102101
NGNG0103
NGNG再利用できるクラスを挙げてくれ。ｗ
0104デフォルトの名無しさん
NGNG意味がわからん。その当たり前の仕様変更に対応しやすいのが
オブジェクト指向。
そのために汎用性のあるコードを書くのは当然。
0105デフォルトの名無しさん
NGNG企業クラス、社員クラスetc.
0106１０３
NGNG無理無理。空論空論。
0107デフォルトの名無しさん
NGNGでも汎用性たっぷりのMFCとかのクラスライブラリを
ベースに(つまり再利用しまくって)作っとるでしょ？みんな。
0108デフォルトの名無しさん
NGNG根拠が抜け落ちてます。もうちょっと詳しく説明してくれないかな？
0109
NGNG自社の給与計算に決まってるのに、請負いで他社の給与計算するの？
社員クラスと株価関係ないじゃん。
0110defaultの名無しさん
NGNG（継承と再利用に関わる部分。）
ＯＯＰ独自の考え方が必要だと感じる。
0111
NGNGしょーもなー。
0112デフォルトの名無しさん
NGNGだから、ここでアプリに汎用性があるという言われ方してるのは
アプリに使われてるコードに汎用性があるってことだろ？
この板的にユーザーの視点じゃないだろうし。
0113
NGNG0114デフォルトの名無しさん
NGNGそんでもって、いつも使う社内用なり個人用なりの
クラスライブラリみたいなの持ってるでしょ？
再利用できとるやん。
0115デフォルトの名無しさん
NGNG株価チャートと給与計算は独立した二つのアプリじゃないのか？
何が言いたいのかわからん。
まさか、全く違う用途の二つのアプリで共通に使うクラスを
作れってことか？
それが作れないからって汎用性が無い等と言い出すのは
無理矢理な議論だな。
0116デフォルトの名無しさん
NGNG＞オブジェクト指向の分析は、現実の世界に即していない。
あたりまえ。
現実のレベルよりもっと抽象的なレベルで考えるだろ？
0117
NGNG一般に使いまわしできないもん。
Ｃのファイル分けだと出来たけどね。
0118デフォルトの名無しさん
NGNG先人の知恵が労せず使える。
0119デフォルトの名無しさん
NGNGそらあんたに才能ないだけだわ。
0120
NGNG(ﾟДﾟ)ﾊｧ!?
0121デフォルトの名無しさん
NGNGその社員オブジェクトが所属する地位を変えるだけで簡単に
対応できる。
汎用性あるじゃん。
0122
NGNG激しく勘違い。
これがＯＯ厨の正体か？
0123デフォルトの名無しさん
NGNG0124defaultの名無しさん
NGNGカプセル化記述の美化と、派生と上書きによる
クラスライブラリのカスタマイズである。
クラスライブラリを作るような気持ちでアプリを作ると、
とんでもないことになる。
0125
NGNG書けなかった人だろうね。
クラス導入で言語の助けを得て初めて再利用できるようになって
感激しているというところか。
0126デフォルトの名無しさん
NGNGクラスライブラリを作るつもりでアプリ作るのがＯＯＰなのか？
0127
NGNG0128デフォルトの名無しさん
NGNGで、オブジェクト指向の欠点とは何でしょう？
0129デフォルトの名無しさん
NGNGじゃあ、あんたは普段再利用性の高いコードを書くために
どういった手法を使っている？
0130
NGNG再利用性の高い仕事を貰う。ｗ
0131
NGNG>>128
行きすぎると生産性を落とす。
0132デフォルトの名無しさん
NGNGなるほど、よくわかった。
0133デフォルトの名無しさん
NGNG行き過ぎなければいいんだね？
0134デフォルトの名無しさん
NGNGそして、デザインパターンを知らない他人がソースを
保守できなくなる。
0135defaultの名無しさん
NGNGＯＯＰの概念の多くを、アプリに持ち込まない方がいいのではという意味。
クラスライブラリから派生させて使ってる程度が、ちょうどいい。
0136デフォルトの名無しさん
NGNGそれは、Cを知らない他人がCのソースを
保守できないのと同じことではないんですか？
01371
NGNGhttp://members.tripod.co.jp/bingo852/
0138デフォルトの名無しさん
NGNGCとデザインパターンでは、使えるまでに必要な知識量が全然違う。
0139デフォルトの名無しさん
NGNGようはあれか？
少年野球チームに突然西武の松坂が助っ人に現れて全力投球したのはいいが、
キャッチャーがボールをとれなくて負けてしまったって状況と同じ状況か？
0140デフォルトの名無しさん
NGNG何？ブラクラ？グロ画像？
0141デフォルトの名無しさん
NGNGたとえ C で OOP の概念をつかわずに書いてあったとしても、
そのシステム特有の概念(というかアーキテクチャ)を
理解しなければ保守できないんじゃないの？
で、デザインパターンなんかは、そういったアーキテクチャを
体系づけて再利用しようとするものでしょ？
0142デフォルトの名無しさん
NGNG0143デフォルトの名無しさん
NGNG俺の認識なんだけど、違うと思う。一過性のアプリならＯＯじゃなくても
なんでもいい（らしい）。ただいろいろ作ってきて、構造が見えてきて
かつ、使いまわす時点になったら、ＯＯで構造を抽出して再利用を考えて
組むと後の生産性が上がる。
構造を見誤ればぐちゃぐちゃになる。ＯＯは難しいよ。
でも使わないわけにはいかない。
0144デフォルトの名無しさん
NGNGでもデザインパターンまでにたどり着くには、
C(もしくはJavaなど)やそのアーキテクチャは
必須でしょ。
その後、さらにC++やOOの知識などが必要になる
から、やっぱり保守要員は確保しづらくなる。
0145デフォルトの名無しさん
NGNGじゃなくって、作ったり保守する対象のシステムね
0146デフォ
NGNG状態の管理…俗っぽく言うと、変数の値の変化の管理
状態の変化をすべて監視･制御できるなら、すべてグローバル変数でよろしい
しかし、大規模になれば、または多人数で作るなら
さすがにその取り扱いは厳しくなってくる
そこで生まれたのが、OOの考え方
しかし、不完全である
…こういう意見が、一般的なのはわかるけど
じゃあ、何が不完全かっていうのが分からない
おそらく、理想系が想像できないから、比べられないためであろう
答えを教えてちょうだい＞OOな方々
0147デフォルトの名無しさん
NGNG0148結論
NGNG個人の趣味に使え。
0149デフォルトの名無しさん
NGNG安らかに眠れるNE！
0150デフォルトの名無しさん
NGNGOOAとOODはどうした？こちらにOOの優位性があるのではないのか？
0151ゆかり
NGNGおやすみなさい☆
0152デフォルトの名無しさん
NGNG元から間違ってるぞ
0153103
NGNG激しく同意。
0154103
NGNG状態はオマケ。
データーフローが入ってない。
0155OO信者
NGNGソフトウェアの開発にオブジェクトというメタファーを導入するのがオブジェクト指向。
オブジェクトにメッセージを送ると何らかの仕事をしてくれる、
このオブジェクト間のメッセージ通信でソフトウェアを構成するというモデル。
オブジェクトという単位を持ち出したことで、
処理の責務をソフトウェアの対象ドメインに由来させることができるわけ。
業務の概念とプログラムの概念を近づけることで、開発をしやすくしようというのが狙い。
例えば売上伝票のデータを整形するモジュールを作るとして、
伝票オブジェクトがあってプロパティを設定するのと、
denpyou_format関数にパラメータを渡すのとでは、
前者の方が分かりやすいはず。
（例がおかしいけどつっこまないで…）
クラスレベルでの再利用が難しいのは JavaBeans の何たらプロジェクトの失敗で明らか。
業務は業務によって激しくロジックが異なるので再利用を見越して作るのは至難。
今さかんなのは設計レベルでの概念の再利用/共有化。
つまりアーキテクチャパターンやデザインパターンなどのパターン技術というわけ。
0156デフォルトの名無しさん
NGNGオブジェクト指向は、再利用しやすい、設計がいい、仕様変更に耐えるものではないのです。
再利用しやすい、設計がいい、仕様変更に耐えるもに、「あなたが努力する」道を提供する技術なのです。
0157デフォルトの名無しさん
NGNGまだ言ってるよ。
0158デフォルトの名無しさん
NGNG-----------------------------------------------------
39 名前：デフォルトの名無しさん 投稿日：01/09/24 11:33
設計がタコだとどうしようもないというか
オブジェクト指向的アプローチからは手の出しようが無くなる
よね。
どんな設計がタコでもちゃんと動いてる部品があれば、そいつ
に手を加えず継承して後から再利用出来るようなOO言語というか
手法って確立出来ないかな
windowsでいうサブクラス（メッセージフック）みたいにさ
-----------------------------------------------------
たしかに、親クラスに手を加えだしたらオブジェクト指向的とは言えないような感じがするよね
でもMFCやVCLだってクラスライブラリがバージョンアップしてるし
0159デフォルトの名無しさん
NGNGデータはオブジェクトの属性でしかないと思うのだがどうよ。
データの流れを軽視しているという意味じゃなくて、
データが重要だからこそ、オブジェクトに責任を持って管理してもらうのだよ。
だからオブジェクトの振る舞いが主役になる。
0160デフォルトの名無しさん
NGNG来館者が自ら記録するようにし、記入漏れがないように来館者を教育するのが構造化。
誰がどういうときに記録するのか、データフローなどで管理する。
来館者は楽だけど、時々貸し出し記録が狂って本が無くなるので、
常により厳密な管理が求められる。
貸し出し窓口を設けて、窓口に問い合わせて書籍を借りるのがオブジェクト指向。
書籍の貸し出し記録へのアクセスは窓口の担当者のみがアクセスできる。
貸し出し記録は万全だけど、来館者は書籍へのアクセスを面倒だと感じる。
0161
NGNGせめて二個ないと・・。
0162デフォルトの名無しさん
NGNG>>160
どちらの例もOOを有利に見せかけるためにでっち上げられたような気がする。
あと手続き（関数の中身というかアルゴリズム）をどうでもいいことのように
扱ってるOO本が多いような気がする。分析の際に言語考えるななんて無理。
0163デフォルトの名無しさん
NGNG利用者が図書館のどこに目的の本があるか知らなくても
館員に持ってこさせれば済む、ってことじゃないのか。
0164OO信者
NGNGOOを使うと有利な場合には大いに使いましょうというだけ。
メソッドの中身をどう実装するかはそれほど重要でないのは確かだね。
設計したインターフェイス道理になっているかが重要。
リファクタリング本を読むと目から鱗かも。
0165デフォルトの名無しさん
NGNGって、悪いって言われても言うけど（ぉ
過去の自分を振り返ってみて、VisualBasicって
かなり隠蔽がうまくいってるケースだと思うな。
自分でクラス（？）を変更できないのがイタイけど。
っていうか、もう使ってねーし＞VB
0166java厨房
NGNG言語は何を主に使用されていますか。
小生、java厨房なので、ＯＯしないと非効率的なのですが。
0167VBエキスパート
NGNGOOなんて下水道みたいなもので、必要ではあるけど
普通の人はわざわざ関わらないものなのです。
汚水の処理は汚水に適した人間がやればよいのです。
0168デフォルトの名無しさん
NGNGwarata
0169デフォルトの名無しさん
NGNGOO＝オアシス
0170デフォルトの名無しさん
NGNGプログラムかけないやつがOO分析ってありなの？
0171デフォルトの名無しさん
NGNGただの構造体に関数が引っ付いたようなものの癖に
メソッドとかメッセージやり取りとかインターフェイスとか
偉そうなカタカナを使うのがむかつくのは俺だけか。
0172デフォルトの名無しさん
NGNGそういうことしてる奴を見かけたら
可及的すみやかに殺して刻んで海に捨てましょう。
0173非OO (!= 反OO)
NGNGお前だけだろ。
0174デフォルトの名無しさん
NGNGだったらプログラム書けなくてもいいのでは？
0175デフォルトの名無しさん
NGNGわけ無いだろ。プログラムできないやつが分析しようと思うことなんて
ないだろ。
原理的には可能かもしれないが、分析が上手く行ったかどうか自分で
体験できないから著しく不利。
0176デフォルトの名無しさん
NGNGプロパティとメソッドで全て、の時代は終わってるんじゃないか？
もちろんOOの概念は汎用プログラミングのベースとして重要なんだけどさ。
0177java
NGNG汎用プログラミングって何ですか?
教えてください。
0178defaultの名無しさん
NGNG理論的にはその通り。しかし現実的ではない。
0179デフォ@146
NGNG以下の考え方に間違いがあったら指摘してちょうだい＞OOに詳しい人
オブジェクト
任意の責任のもとにまとめられた状態と振る舞いの集まり
振る舞いは状態の変化とともに行動が変わる
オブジェクト間に許された行為は、ただ通信のみ
クラス
オブジェクトの記述方法の1つで、オブジェクトの静的側面を示す
クラスを用いなくても、オブジェクトの構築方法はある
主に、振る舞いの制御に威力を発揮
で、オブジェクトの「責任」「状態」「振る舞い」の
3つのどれを中心に考えるかで、分析･設計方法が変わる
と思ってみたけど、あんま自身ないな…
しかし、「ただ通信のみ」ってところで、自分で書いててなんだが
カイジの8巻を思い出したｗ
0180デフォルトの名無しさん
NGNGかなり自信無いんで、外してたらすまぬ。
全然違うオブジェクトにも、同じ操作が部分的に適用できることは多い。
ってことで、汎用性のある操作はオブジェクトから独立させて、複数の操作を効果的に組み合わせることも意識するような感じだろうか。
操作そのものをオブジェクトにしちゃった関数オブジェクトの概念もかなり重要。
ベースはOOだから、汎用性の無い操作はメソッドとして隠蔽するけど、その枠に無い操作も多い。例えば比較とかソートとか。
純粋OOにこだわったら、例えば高速なソートを自前で起こしても、それを文字列中の文字のソートとかに使うにはクラス定義の変更が伴う訳で。
C++で例を挙げると、
MySort ( coll.begin(), coll.end(), less<string>() );
みたいなコードが、collが配列でもリンクリストでもファイルでもとにかく呼べる、と。
OOの枠からは外れるけど、実際に楽だし、素直に納得の行くパラダイムだと思う。
で、
MySort ( coll.begin(), coll.end(), greater<string>() );
とすれば逆順になり、
MySort ( coll.begin(), coll.end(), less_ignore_case<string>() );
とかだと大文字小文字無視になる、という感じで。
さらに、数値の入ってるコンテナなら
MySort ( coll.begin(), coll.end(), less<int>() );
とか。
あと、上記の例くらいなら、Cでごりごり書くのと速度もメモリ消費も同じにできるのもポイント。
まだ自分でもこなれてない手法なんで、いろいろ甘いのは勘弁。
0181180
NGNG0182デフォルトの名無しさん
NGNGhttp://mentai.2ch.net/test/read.cgi?bbs=prog&key=995110531
0183デフォルトの名無しさん
NGNGアホ？
0184デフォルトの名無しさん
NGNG「共通プログラミング」なんて訳してる本もありますよね。
ちなみに、構造化～、オブジェクト指向～、ジェネリック～は
どれが上、どれが下というもんでもないし、
それぞれ相反するものではないと思いますよ。
0185defaultの名無しさん
NGNG新たにプログラムＢを開発するときは、ａｅを流用し、
ｂを継承してｂ’を作り、ａｂ’ｅｆｇとなり、
新規開発はｆｇだけで済みました。
更にプログラムＣを開発するときは、ａｃ’ｆとなり、
プログラムを良く知らない新入社員でも、
開発できてしまいました。
プログラム資産を蓄積すれば、大抵のアプリケーションは、
既存のオブジェクトの組み合わせと、
継承によるカスタマイズだけで、出来てしまいます。
すばらしい！
0186デフォルトの名無しさん
NGNGLISPにとっては何をいまさらという感じだが。
0187デフォルトの名無しさん
NGNGモジュール化、実装隠蔽、差分実装、の３つの組み合わせでできることだよね。
これは必ずしもＯＯに特有の話じゃない。
・・・などと書いてみるテスト。
0188defaultの名無しさん
NGNGつまり、ＣＯＢＯＬやＰＬ／Ｉのプログラミングのことです。（嘘）
汎用プログラミングがジェネリックプログラミングなら、
Ｃ＋＋でいえばテンプレートですね。
0189デフォ@146
NGNGLispのような関数型言語（実際には、Lispはそうでもない）の方が強力だと思われる
>>146で述べた状態の管理の代表的なもう1つの解が関数型言語
自身では状態を持たないので振る舞いの変化もない
じゃあ、状態の変化をどう管理するかというと
ある「もの」の状態の変化の変遷を
例えば、すべてリスト状に書き下すことによって、管理したりする
100から25,20,30の引き算とかは、100 - (25, 20, 30) => 25
しかし、こういう管理方法も不完全である
なぜかは、やっぱり、よく分からないので答えてください＞関数型言語の方々
オブジェクト指向、関数型、どちらも興味はあるのだが、
どちらも相容れないパラダイムなのかな…
0190デフォルトの名無しさん
NGNGんだけど、言語全体から見たら、なんだかなあ・・って感じ。
0191デフォ@146
NGNGあれって、明示的な型宣言のないRubyやLispやSmalltalkでは
明白で簡潔に書けるのに、C++では明示的な型宣言が存在するために
あえてああいう書き方でしか表せないパラダイムの1つ
…のような気がするんだけど
「どんな型でもいいよ～」っていう以外に効用ってあるの?
あと、>>189は、激しくスレ違いの予感…
0193デフォルトの名無しさん
NGNGモジュールレベルの方が今のOO言語の窮屈なクラスレベルより設計も実装も
再利用も楽だった気がするのは年寄りだからかな
0194デフォルトの名無しさん
NGNGそもそもメソッド、メッセージ、インターフェイスという単語は、
英語的には普通の単語過ぎてダサい感覚です。
シニカルに見えて鼻につくと思うのは日本人だけ。
（だから日本で流行らないんだろうなぁ）
メソッド→手順
メッセージ→伝言
インターフェイス→境界
オブジェクト→物体
クラス→種別
インスタンス→実体
なんてどうでしょうか。
0195デフォルトの名無しさん
NGNG>>185みたいなのは「差分プログラミング」っていうんじゃないの。
「ソフトウェアIC」なんていう私語もあったね。:-P
0196デフォルトの名無しさん
NGNG３目並べゲームをオブジェクト指向で表現してみてよ
簡単すぎるならテトリスでもいいよ
0197デフォルトの名無しさん
NGNG自分でやれ。
手番からなにからすべてクラスで定義した厳密バージョンと、
コード・設計が最もシンプルになるような最適バージョンの両方作ってみな。
もちろんプレイヤーは人間・CPU・ネットワーク越しすべてを透過的に扱えるように設計しろよ。
その程度なら厨房でも何とかこなせるし、良い勉強になるよ。
0198デフォルトの名無しさん
NGNG差分プログラミングなんて用語は始めて聞いたぞ。
ソースをコピペして一部を改造するという腐ったやり方のことか？
0200199
NGNG199=195
0201196
NGNG0202デフォルトの名無しさん
NGNG0204デフォルトの名無しさん
NGNGすでにシンプルな物をよりシンプルにするのは苦手というか、効果が薄い。
そういうところはアルゴリズムにまかせたほうがいい。
有用な技術だけど、すべてにおいて効果を発揮する万能薬じゃないのだよ。
会社組織にたとえれば、２～３人の小さな組織で備品購買担当を決める意味があるのか。
こんな小さな組織で下手に担当を決めるとかえって窮屈になる。
だから３目並べやテトリスくらいでは、デメリットばかりが目立っていい例はあげられない。
しかし大きな組織になったら担当が必要になる。
１００人の社員が好き勝手に備品を買ってきたらえらいことになるし、
管理するのは大変だから担当を決めて、決済や稟議というメッセージを仲介し、
購入という操作や、予算という属性を隠蔽する必要が出てくる。
組織を知ればオブジェクト指向は見えてくる。
0205196
NGNG0206196
NGNG普段、MFC/VCLを【使う】事はやってましたが、
いまひとつオブジェクト指向ってのが理解出来ないというか
クラスライブラリっってGUI用で（TCのテキスト窓用のも類似として）
これはオブジェクト指向そのものとはちょっと違うんじゃないかと思ってました。
COMを作るのにオブジェクト指向なんて概念は必要なくてインターフェースさえ
決めればいいので、インターフェースを決めるのにオブジェクトやクラス（つまり
現実世界の物を抽象化）なんて考えてませんでしたから
つまりはオブジェクト指向のいうオブジェクトは業務系の用語だという事なら
理解出来ます
0207デフォルトの名無しさん
NGNGいいかげんその手の半端で不正確で
読み手をあらぬ方向へ誘導する説明を得意げにするのはやめろ。
何の役にもたたん。
0208デフォルトの名無しさん
NGNG>そもそもプログラムかけないやつが、分析できるだけの知識を持ってる
わけ無いだろ。プログラムできないやつが分析しようと思うことなんて
ないだろ。
ファウラーによると、「最高の分析者はそのドメインのスペシャリスト」だ
そうですけどね。でも確かに現実の顧客にモデリングを教えてやってもらう、
ってのは想像できません。
その前に自分がモデリングできなきゃいけない…あ、ファウラーみたいな
コンサルタントがついてるからできるのか。
>原理的には可能かもしれないが、分析が上手く行ったかどうか自分で
体験できないから著しく不利。
モデリングできたら、そのモデルを「実装」してみればいいのでは？
分析モデルでも動くモノはできるよね。
0209デフォルトの名無しさん
NGNG業務系や事務系の用語となぜ決めつけたのか知らないけど、
オブジェクト指向はゲーム開発だろうがなんだろうが使えるよ。
なんか堅苦しく考えすぎているような……。
TRadioButtonはラジオボタンを担当している。
ラジオボタンがラジオボタンである責任をTRadioButtonが負っている。
もしラジオボタンの表示が崩れたり、表示とチェックの状態が異なっていたりしたら、
それはTRadioButtonに問題があるからであり、TRadioButtonの責任だけを問えばいい。
当たり前のことだよね……。
フォームに６個のラジオボタンと、６個のチェックボックスがあるとする。
非オブジェクト指向なら、フォームを再描画するとき、
コンポーネントのテーブルを調べて、各ボックスの状態を調べて、
コンポーネントの種類に応じた描画関数を呼び出していくだろうか？
オブジェクト指向の場合、そのコンポーネントの正体は知らないまま、
フォームに張り付いているコンポーネントに対して再描画のメッセージを
送っていくだけで事足りる。コンポーネントの種類が増えても、
フォームの処理を返る必要はない。
これは各コンポーネントが、それぞれの役割りに責任を持っていることが保証されて
はじめて成り立つんだよ。
0210defaultの名無しさん@職場
NGNG185 のすばらしいは、本当にそんなことが出来たら
すばらしいって意味ですよ。
0211
NGNGところで、ゲーム業界ではパックマンのころから、表示物体の事を
「オブジェクト」って呼んでたの知ってる？
0212デフォルトの名無しさん
NGNGオブジェクト指向アレルギーの典型的症状が現れています。
理解できないから理解しようとしない、
理解しようとしないから理解できないという悪循環に陥っていませんか。
0213潜伏中
NGNG> ところで、ゲーム業界ではパックマンのころから、表示物体の事を 「オブジェクト」って呼んでたの知ってる？
だって物体（実体）を表わすための汎用名詞じゃん :-)
コンピュータ言語で言うところの "object" とは別の意味だ。
0214潜伏中
NGNG> オブジェクト指向はＧＵＩパーツでは成功しやすいよね
それは単にユーザインターフェイスを構築する際はユーザの
取りうるアクションそれぞれに対して振る舞い(reaction)を
定義しなければならないから複雑化しやすく、複雑化した
モデルに対してはオブジェクト指向がよりよい手法であるから
ユーザインターフェイスに対してオブジェクト指向は成功しや
すい、ということでしょ。
0215196
NGNGOOPがゲームだろうがなんだろうが便利に使えるという事なら同意するけど
オブジェクト指向ってのは
＞「オブジェクトとは，日常生活に見られる物体を、ソフトウェア・プログラミング上でモデル化して表現したものです」
っていう所からよく入るだろ？
プログラミングの立場から見ればモデル化というか抽象化は当然やる。
というよりプログラミング＝抽象化だと思う
プログラムするのだから抽象化するのは当たり前なんだから、後半に意味はない。
なら「日常生活に見られる物体を、」ってあたりがオブジェクト指向なんだろうか？
そういう目で見れば、TRadioButton とか まったく日常に見られる物体とはかけ離れた
動作、仕様で実装されている。
それはWindowsコントロールのラッパーだからしょうがないというなら、じゃいったいオブジェクト指向って何？
結局、
継承や、データ＋メソッド構造の事じゃないのか？と思うけど、そうじゃないんだと多くの
入門書やサイトは言ってる。 じゃ何なんだ？ って疑問があったんだけど
業務系や事務系の【金を取る為の】 用語なんだと理解すれば 色んな疑問が全部納得出来るんだ。
組込み系でいえばニューロとかファジイとか1/fの用語と一緒だね
0216デフォルトの名無しさん
NGNG結局、
>業務系や事務系の【金を取る為の】 用語
としての「オブジェクト指向」はいやだ、というのはわかるけど、
>OOPがゲームだろうがなんだろうが便利に使えるという事
>継承や、データ＋メソッド構造の事
を196はなんて呼ぶの?
それがオブジェクト指向なんじゃないのかな。
0217デフォルトの名無しさん
NGNG>なら「日常生活に見られる物体を、」ってあたりがオブジェクト指向なんだろうか？
>そういう目で見れば、TRadioButton とか まったく日常に見られる物体とはかけ離れた
>動作、仕様で実装されている。
>それはWindowsコントロールのラッパーだからしょうがないというなら、じゃいったいオブジェクト指向って何？
現実に喩えるということと、現実に合わせるということは違うんだよ。
オブジェクト指向は、現実世界にある「責任分担」などの仕組みを真似ましょうと言っているに過ぎず、
ソフトウェアを現実世界と同じ形に置き換えましょうと言っているわけじゃない。
オブジェクトが担う責任についてもっとよく考えてみよう。
誰かに責任を負わせるということは、それ以外の誰かが負う責任が減るということ。
ラジオボタンの責任をTRadioButtonに一任しているからこそ、
TFormはラジオボタンに関する責任を負わないで済む。
こういう責任分担のしくみは、会社組織の中にあるそれと全く変わりがない思うけど。
別にVCLのコンポーネントに部長や課長や西地区担当という名前を付けることを求めたりはしない。
データ＋メソッド構造をオブジェクトと呼んでもいいけど、それには但し書きが必要。
そのメソッドにはオブジェクトの一部としてデータを維持管理する責任があり、
その責任が負えないようならオブジェクトの構成要素とは呼べない。
ちなみに俺は組み込み系とゲーム系しか知らないから、
業務系、事務系、勘定系のことは知らん。
0218デフォルトの名無しさん
NGNG本当に理解したいなら、2ch で書いててもどうせ適切な説明は返ってこない（ここは
匿名で短いコメントを次々とつけていく形式だから、包括的な説明するには向かんメ
ディアだ）から「憂鬱なプログラマのための…」でも買ってきて読むことを勧めるが。
たんに煽りたいだけなら、止めないけど。
> 業務系や事務系の【金を取る為の】 用語なんだと理解すれば 色んな疑問が全部納得出来るんだ。
ＯＯはすでに「現場で」使われている技術だよ。看板だけ会って中身がない単なる用
語とは違う。
あとＯＯの真髄は、プログラミング言語よりもむしろ分析／設計段階にある。ＯＯで分
析／設計した結果を素直にコーディングするために必要な機能を取り入れた言語を
ＯＯＰＬ（オブジェクト指向プログラミング言語）と呼ぶわけだが、その言語の機能を
見てＯＯの全体像を知ろうとするのは、木を見て森を想像するのと同じぐらい難しい。
というわけで、まずはＯＯの分析／設計について調べるのがいいと思うぞ。
0219デフォルトの名無しさん
NGNG悩みますねぇ～。
実装方法も継承主体でいくのかオブジェクトコンポジションを
使ったほーがいいのかとか。
ＯＯの分析／設計の勉強をきちんとやったほうがいいんでしょうね。
0220サブジェクト志向言語
NGNG/*表題を書けやｺﾞﾗｧ*/
/******************/
void hoge(void){
printf("表題が必要です");
}
0221
NGNG「オブジェクト指向を理解しているのは俺だけ」
「本当は難しくて抽象的でお前らなんかに理解できないんだよ」
みたいな厨房を大量に生んでしまった事のようだな。
0222デフォルトの名無しさん
NGNGできてるんじゃないかと思うけど、パーサ系(状態遷移とかのある)がどーもうまく
設計できなくて、変数いっぱい・関数長い・インデント深いと三拍子揃ったソースを
書いちゃってて今鬱…
誰かやり方知ってたらヒントでも教えてください。。
0223Delギコ
NGNG( ﾟ∀ﾟ) ＜ >>221 藁夕
| つ[|lllll］).＼＿＿＿＿＿＿＿＿＿
～| |
∪∪
ｵﾌﾞｼﾞｪｸﾄ志向のメインは単に構造体がメソッドをもてることだと思フ
0224
NGNGとにかく、出来あがったら別ファイルにするなり（カプセル化）
して目に触れないようにすれば（隠蔽）ＯＫダ。
0225デフォルトの名無しさん
NGNGそんな極度に抽象的な処理をオブジェクト指向にする必要も無いと思うが。
0226222
NGNGんー。それはやってます。
ただカプセル化した中とはいえ、ネストの深いifとかはなんとかしたくて。
うーむ。
>>225
確かに、具体的にイメージできるもの(オブジェクト)があったほうが設計しやすいですよね。
0227デフォルトの名無しさん
NGNG0228デフォルトの名無しさん
NGNGwhile (!state.isFinal()) {
state = state.parseNext(context);
}
0229デフォルトの名無しさん
NGNGModula-2をつくったNiklaus Wirthはオブジェクト指向言語Oberonをつくった。
>>196
オブジェクト指向を理解してない。
>>211
関係ないけど、表示物体をクラスにするのは典型的なオブジェクト指向だと思う。
0230デフォルトの名無しさん
NGNGラベルを状態にみたてて goto で回す。
それかテーブル駆動。
汚いと言われようが何しようが、
カプセル化してしまえば内部は好きかって。
0231デフォルトの名無しさん
NGNGVBでもOOできるよーん。
0232デフォルトの名無しさん
NGNGVBの継承ができないという仕様はある意味潔い。
0233230
NGNG細部は好き勝ってという手法が好きです。
あんまりオブジェクティブを徹底しすぎてもちょっとアレ。
0234
NGNG同感。
Stringをオブジェクトにした奴は死んで欲しい。
0235
NGNG信者にふさわしい死に方をきぼんぬ。
0236デフォルトの名無しさん
NGNGネタですか？
0237デフォルトの名無しさん
NGNG0239デフォルトの名無しさん
NGNG0240
NGNG従ってちゃんと継承して作りなおして、信者にふさわしい死を・・・。
0241230,233
NGNG0242デフォルトの名無しさん
NGNG1 to: 100 do: [: i | Transcript show: i ; cr.]
0243
NGNG何語ですか？
0244デフォルトの名無しさん
NGNGSmalltalk だよ～。
1 というオブジェクトに to: do: というメッセージを送ってる。
こいつを受け取ると、1 は 100 まで数え上げて、
do: に与えられたクロージャをその都度呼び出す。
で、その際の現在の値が i に与えられる。
0245デフォルトの名無しさん
NGNG0246デフォルトの名無しさん
NGNGDesign Pattern の Interpreter と State の組み合わせで
いけないかな。とはいえ、もう試しているけどうまくいかないから
書いているんだろうから、余計なお世話だな。
0247defaultの名無しさん
NGNG（つまりはカプセル化）ＯＯＰ以前からやってること。
つまり、ＯＯレベルでは構造化に対してアドバンテージが低い。
ＯＯＰの構造化に対するアドバンテージは、継承にある。
ＯＯＰの継承で設計すると、抽象化による共通部分の
ベースクラスへの切り出しが必要だが、これが問題だ。
システム化というのは、現実の世界の処理を具体化し、
機能別に再構築する物だと思う。
にもかかわらず、派生によるメンテナンス性向上のために、
無理に抽象化することに意味があるのか？
（それ以前に、派生でメンテナンス性が向上するとは思えないが。）
また、今までカプセル化は、設計上の必要性で行ってきたのだが、
ＯＯＰだからと何でも細かくオブジェクト化し、
インターフェイスやメソッドを増加させるのはどうかと思う。
0248デフォルトの名無しさん
NGNG機能単位のプログラム分割とカプセル化は全然別物だと思うよ。
0249defaultの名無しさん
NGNG違う場合もありますが、全然別物ではありません。
共通サブルーチンや共通モジュールを、想像してください。
印刷サブルーチンは、各種パラメータにより、
内部の印刷モジュール（メソッド）を実行します。
コール元からすれば、直接メソッドを呼ぶのか、
パラメータを指定するのかの違いだけです。
0250デフォルトの名無しさん
NGNG同じ場合もありますが、別物なのが普通です。
例えば、クラスとインスタンスを例にあげて言えば、
インスタンスは複数あるのが普通だし、持ち運びもできる。
非ＯＯなモジュールの場合にはそういうことは考えない。
「もの」として持ち運んだり複製したりできることが重要。
0251デフォルトの名無しさん
NGNG0252defaultの名無しさん
NGNGＯＯレベルではの話です。
ＯＯＰレベルだと、その利点はありますね。
0253デフォルトの名無しさん
NGNGＯＯ、ＯＯＰ、ＯＯＡ、ＯＯＤ、の使い分けがよく分かりませんです。
どういう基準で使い分けてますか？
0254defaultの名無しさん
NGNGＯＯレベル、設計レベル（ＯＯＡ＋ＯＯＤ）。
ＯＯＰレベル、実装レベル。
設計レベルでは、データフローに対する
処理単位（クラス）で考え、同じデータフローを
個別データ単位（インスタンス）では考えない。
0255デフォルトの名無しさん
NGNGＯＯ＝オブジェクト指向パラダイム
ＯＯＰ＝オブジェクト指向プログラム
ＯＯＡ＝オブジェクト指向分析
ＯＯＤ＝オブジェクト指向設計
で、カプセル化はＯＯとして（問題をオブジェクトとして見るために）
必要不可欠なキーワードで
構造化なんちゃらのモジュールとは一線を画していると思われますが。
0256デフォルトの名無しさん
NGNG>>247
オブジェクト（役割単位での分割）とモジュール（機能単位での分割）は区別して考えないと。
モジュールは管理している属性が不明瞭だし、操作する対象も不明瞭のままです。
そこを明らかにすることに価値を見出すのがオブジェクト指向かと。
継承がＯＯの最大のメリットだというのはそのとおりだけど、
ＯＯ初心者にこれを説明しようとするから難しくなるのではないかと思います。
ポリモーフィズムとか、ある程度のデザパタが理解できるようにならないと
継承の本当の美味しさというのは掴めないし。
（>>223みたいなことを言っている奴もいるし）
だからまず、オブジェクト否定派には、オブジェクトとは何なのかという
至極当然のところから噛み砕いて説明したほうがいいと思いますよ。
0257デフォルトの名無しさん
NGNGそれはすでにＯＯではなくフローモデルあたりだと思う。
0258デフォルトの名無しさん
NGNG> ＯＯＰの構造化に対するアドバンテージは、継承にある。
設計／実装段階の要は、むしろ「インスタンス間の相互作用」だと思うが。
継承も相互作用の一形態ではあるけど、むしろ特殊な例。
0259デフォルトの名無しさん
NGNGあまり一般的な分類だとは思えないなぁ。255 さんとかぶるけど、
ＯＯ＝オブジェクト指向：思想。ポリシー。対象を特に選ばない。
ＯＯＡ＝オブジェクト指向分析：ＯＯに基づいた問題領域の分析工程。
ＯＯＤ＝オブジェクト指向設計：ＯＯに基づいた(ソフトウェアの)設計工程。
ＯＯＰ＝オブジェクト指向プログラミング：ＯＯに基づいた実装工程。
クラスとかインスタンスという概念はＯＯでよく見られる一つのパターンであって
ＯＯＡやＯＯＤだからクラスでＯＯＰだったらインスタンスというのは変だよ。
プロトタイプベースの言語だったらクラスないし。
クラス間ならぬインスタンス間の関係を設計段階では扱わないかと言えばんなことないし。
0260defaultの名無しさん
NGNG混乱を招いてしまいました。
ＯＯのモジュール分割と、構造化の機能分割を
同じだとは言いいません。
ＯＯＡやＯＯＤでもたらされる恩恵は、既存の構造化で、
ある程度満たされていると言いたかったのです。
デザインパターンについても、企業内レベルでは
以前から標準化する努力がされています。
ではＯＯのアドバンテージは？
今まで存在しなかった、継承やポリモーフィズムに、
真のアドバンテージはあるでしょうか？
>>257
ＯＯＤ
0261デフォルトの名無しさん
NGNG何でもいいが、もう少しＯＯについて勉強してから意見を開陳した方が良い
と思われ。単語レベルで解釈が食い違っているようだと、さすがに議論にな
らないですよ。
0262defaultの名無しさん
NGNGごもっともです。
0263デフォルトの名無しさん
NGNGまず、銀の弾丸的なものを期待する対象じゃないと思う。＜ＯＯ
んで、既存の手法に対する全く新規なアドバンテージもないと思う。
なら、何がいいのかというとトータルでは扱いやすいってこと。
むしろ既存の手法にあった色々な考え方を
カプセル化や継承なんていう基本語彙で表現しやすくしたのがでかい。
そもそもSimulaやSmalltalk-72にさかのぼればＯＯは古典の部類。
既存の手法とオーバーラップしてるのは自然なことじゃない？
大体プログラムなんて最後は全部機械語に落ちるわけで
どんな手法も目標機械語列へのリーチを短くする話でしかない。
その意味では十分なアドバンテージがあると思うよ。
0264defaultの名無しさん
NGNG私もそう思います。それがわかって必要な部分だけ
使用すればいいのですが、過度に使用しようとすると、
問題があると感じます。
0265defaultの名無しさん
NGNG実際に設計・開発した人で、継承やポリモーフィズムの
アドバンテージを、実感した人はいますか？
0266デフォルトの名無しさん
NGNG「クラスライブラリのようには汎用的でない」の間違いだよね？
重箱隅な突っ込みは置いといて、状況設定が不適切だと思う。
継承や多態が有効に機能するように、
限定的な範囲内であっても汎用性を意識して設計することが
ＯＯＰの有効性の重要なポイントになっているはず。
極端な話、「汎用性をもたせてはならない」という条件をつけたら
どの辺りでＯＯＰが役に立つのか想像がつかない。
0267defaultの名無しさん
NGNG> 「クラスライブラリのようには汎用的でない」の間違いだよね？
はい。
汎用性を前提としたクラスライブラリで、
継承が役にたつのはわかっています。
アプリケーションの設計・開発で、継承やポリモーフィズムが
プログラムの何かに貢献した例についてです。
汎用性をもたせてはならないなどとは、状況設定していません。
アプリケーションの汎用化に貢献したでも、
メンテナンス性の向上でも、システム構造の明確化でもかまいません。
0268デフォルトの名無しさん
NGNGアプリケーションの、というのならもちろん役に立っている。
個人的な経験を挙げれば次の通り。
複数フォーマットのファイルに対応したい場合に
共通インターフェースを Document クラスにまとめて
個別のフォーマットに対応するものを派生クラスで特化する。
Factory パターンと組み合わせれば
特化された Document を追加するだけで
他のコードは一切書き換えずに機能を拡張できる。
同様のことが Command パターンの時にも成り立つ。
構造の明確化、メンテナンス性の向上、どちらのメリットもある。
0269defaultの名無しさん
NGNG私の場合、クラスライブラリのドキュメントクラスから
個別のフォーマットのクラスを派生させて、
そこ個別のクラスから、更に派生する構造はとりません。
共通部分は別クラスにし、クラスのメンバにします。
理由は、この方がわかりやすく、扱いやすいと感じるからです。
0270デフォルトの名無しさん
NGNGいたるところで役立ってますよ
窓なんてひょろっと必要なところをオーバーライドしたら
アプリが出来あがる。これくらいならモジュールのみでも
無理やりやればできるけど
多態とかインスタンス間の関係まで、デザインパターンに
踏み込めばモジュールでは役に立たない。
0271デフォルトの名無しさん
NGNGクラスのメンバにするというのは委譲のことを言ってる？
これを継承＆多態じゃなくて委譲にするのはかなり非常識だよ。
もちろん継承のない言語(VBとか)だったら仕方ないけれど。
継承を使わない＝多態を使わない＝インターフェースが共通化できない
ということになるから敢えてそうするだけのメリットがないと。
委譲ですらないんだったら根本的に何かを間違えていると思う。
0272デフォルトの名無しさん
NGNG自己レス。
ダイナミックバインディングが前提の言語だったら
継承使わなくても多態は使えるね。VBもその点はそうか。
実装はコピらなくちゃいけないし
ディスパッチャとしてのメソッド実装が必要になるから非効率だけどね。
とりあえずこれで寝。
0273defaultの名無しさん
NGNGインターフェイスの共通化はクラスライブラリレベルで、
クラスメンバにしているのは実装部分です。
0274デフォルトの名無しさん
NGNGクラスライブラリで提供しているインターフェース以外は、自作のクラスの外に出さない、
ということですか？ なんか勘違いしてるような気がしますが（私が）
0275defaultの名無しさん
NGNG故意に共通のメソッドを作らなかったわけではなく、
（過去において）ほとんど必要性がなかったのです。
追加するメソッドに、クラスライブラリ以外のメソッドで、
汎用性な部分がなかった。
共通する処理部分や、共通するデータ部分はありましたが、
これらは別クラスにしました。
継承させた方がＯＯＰらしいのですが、
（少なくとも私は）必要性を感じませんでした。
まれには、共通するメソッドがあって、
継承を使用したこともありますが。
0276デフォルトの名無しさん
NGNG……。
黙ってこれを読め。
http://www2s.biglobe.ne.jp/~gkimoto/j/oop/part2/ch14_polymorphism.html
君はだいぶ勘違いしているようだから、さらっと流し読みしてはいけない。
間違った固定観念は全て捨てて、よく熟読すること。
0277defaultの名無しさん
NGNG私がいいたかったのは、何が何でもＯＯの概念にそって、
継承やポリモーフィズムを使うことが、
わかりやすくもないし、メンテナンスし安くもないということ。
人間クラスと犬クラスを、どうしても継承させたがるのは
どうかと思う。
たとえＯＯの概念から外れても、別のクラスの方がわかりやすく、
メンテナンスしやすいこともある。
0278デフォルトの名無しさん
NGNGそれじゃあさ、compositeパターンの活用例を挙げて、
そのメリットとデメリットを説明してみな。
説明する課程で理解が深まると思うから。
0279デフォルトの名無しさん
NGNGOOを一生懸命勉強してきたのはわかるけどさ
本を真に受けてOO最高じゃ話が進まないよ
まともなシステム開発したことある?
0280デフォルトの名無しさん
NGNGOOがまともなシステム開発に使われていないとでも？
0281デフォルトの名無しさん
NGNGGoFパターンにケンカを売ろうという根性だけは認めるけど、
もっと勉強した方がいいね。
0282デフォルトの名無しさん
NGNG酷い事言うなー。今まで必死でやって来た事が、現実じゃ役に立たないなんて言われたら、儂なら泣いちゃうよ。
0283デフォルトの名無しさん
NGNG何でも継承にしようとするＯＯ信者は困りもんだが。
適度に使えばＯＯは有効だよ！
0284デフォルトの名無しさん
NGNG最前線で破綻してるのは周知の事実
書籍を鵜呑みにする偽知識者以外は、みんな知っている
だからといって、OOPを否定しようという勘違い者は論外
0285デフォルトの名無しさん
NGNGvoid foo(A& bar) {
}
関数fooに渡されるbarは型Aのオブジェクトということだけわかっていれば、
barがどのクラス(実装)のインスタンスかを知らなくてもかまわない。
GoFのパターンも、型と実装の分離を前提にしているものがほとんど。
0286チーズはどこへ消えた？
NGNGへぇ、システムやアプリの開発経験があるんだ。
満足の設計ができた？
もっとうまい方法があるかもしれないと疑問に思わなかった？
ん？ そうか、現状に満足しているんだね。
君はすばらしいよ。それならもう僕からは何も言うことがないよ。
0287日曜プログラマ
NGNG>>285
つまり継承って事では？
0288OO信者
NGNG適切な役割を持たせたオブジェクト同士の協調作業にあると分かる。
言語の機能に思考を縛られていてはいけないと思うな。
>>277
＞人間クラスと犬クラスを、どうしても継承させたがるのはどうかと思う。
例の粗を探すのではなく、例から概念を理解してほしい。
おそらくあなたは、「コードの把握しやすさ」は理解できても
「ソフトウェア構造の把握しやすさ」という概念は理解できていないのでは？
共通部分を括り出すだけでは自分用関数ライブラリと変わらない。
デザインパターンは、ソフトウェアを開発していると良く出くわす
*設計上*の問題とその解決法に名前を付けたもの。
名前があるおかげで、
「これはfactoryパターンでやるといいんでない？」「あ、なるほど」
というやりとりができる。
まあ、みんながパターンを知ってないと共通語彙として使えないから
まだまだ浸透するには時間がかかるだろうけどねえ。
0290デフォルトの名無しさん
NGNG継承と書くときには、「インターフェースの継承」なのか「実装の継承」なのか
明記したほうが良い。混乱の元だから。
0291285
NGNG>つまり継承って事では？
言語によっては、継承によって実現せざるをえない場合があるが、Javaのように
interfaceとclassによって実現できる場合もある。重要なのは「型」と「実装」
の区別を意識すること。
0292真のプログラマー
NGNG全てを具体的に扱うことができれば抽象化など全く不要だからだ。
0293真のプログラマー
NGNG見ず知らずの他人になど頼らずとも常に最良の設計を創造できるのだ。
0294デフォルトの名無しさん
NGNG過去のコードは全て脳にインプットされ、
いつでも常にフルスクラッチで書き起こせる。
0295真のプログラマー
NGNGこれまで設計ミスなどという愚考を犯したことが無いからだ。
0296デフォルトの名無しさん
NGNG0297デフォルトの名無しさん
NGNG0298真のプログラマー
NGNG犯さないったら犯さない。
名前の記入を忘れたり、
ましてや愚行を愚考と書いたりなどするわけがない。
0299デフォルトの名無しさん
NGNG0300デフォルトの名無しさん
NGNG0301デフォルトの名無しさん
NGNGマジレスされると嫌味効果が薄れるからやめてくれ。
0302デフォルトの名無しさん
NGNG技術の進歩についていかれないだけだろ？
0303デフォルトの名無しさん
NGNG元ネタは、これか？
本物のプログラマ
http://www.genpaku.org/realprogrammerj.html
なんにしろスレ違いだから、このへんでやめとけ＞真のプログラマー
0304デフォルトの名無しさん
NGNG>>303
あ～あ、やっちゃったよ。
0305デフォルトの名無しさん
NGNG0306デフォルトの名無しさん
NGNG今ごろ気づいたけれど、別クラスのほうがわかりやすいって何？
継承したって、人間と犬と猫は別クラスであることにはかわりないじゃん。
共通部分は動物クラスにまとめられるから、同じ処理が犬や猫クラスに重複しないし。
メンテナンスしやすさ、わかりやすさ、どこをとっても継承したほうが上では？
継承を使わないで何がよいのかさっぱり解らないよ。
単に継承が理解できないから使わないと言っているようにしか聞こえない。
0307デフォルトの名無しさん
NGNG0308デフォルトの名無しさん
NGNG継承っていうのも、あまり俺は好きじゃない
継承するとメンテナンスしずらい気もする
もちろん､ポリモーフィズムのためなら関係ないが
0309デフォルトの名無しさん
NGNGだが、抽象動物クラスには「前足」があるのかそれとも「手」があるのか？なんてことを
考え出すと、手だか足だかは別クラスにして接続したほうがよさそうだ、と判るんではないかと。
俺もOOマンセーなんだけど、引継ぎで
俺「ここの状態遷移はStateパターンそのままで･･･」
相手「ﾊｧ？すていとぱたーん？」
俺「個々の状態を、AbstractStateクラスのサブクラスで定義して･･･」
相手「ﾊｧ？クラス？構造化プログラミングの言葉でいうと何？」
てなことがしょっちゅうなんだけど。
思うにOOの弱点は
・OOへの理解が浅い人間が設計するとどこまでもひどくなりうる。
・もともとの設計がまともでも、OOへの理解の浅い人間がソースを引き継ぐと
理解できない、またはどこまでもひどくなりうる
・上記2点にもかかわらず理解を深めるのが難しい。（このスレの混乱振りを見れば明らか）
つまり、フールプルーフがなってない。
よって、設計・実装・保守を行う者と、利用者が明確に区別できる場合
（たとえば自分用クラスライブラリや、商用クラスライブラリや、長期に渡って
同一人物やチームが保守することができる場合など）のみしか有効でないと
思うんだがどうよ？
#OOへの理解が浅いのはオレモナー
0311デフォ@どうなんすか？
NGNG継承は、規格化（通信規約）が第一目的
これにより、交換可能を実現できる
…と思う
しかし、オブジェクト指向が再利用性と交換性を目指してるのは分かるけど
デザパタとか見てると、交換性はうまくできてるけど
再利用性はいまいち実現できていないように感じるけど、いかがか？＞OOの人
0312デフォルトの名無しさん
NGNGアーキテクチャの再利用を目指していると思われ。
おいら自身もコードそれ自体の再利用性に
あんまりこだわるのもどうかと思う。
もちろん意識することは吉だろうが。
0313デフォ@どうなんすか？
NGNG交換性を有するという事は、その部分以外での構造を再利用をしているのと等価かなとは思ってたけど…
じゃあ、オブジェクト指向って抽象クラスとかでコード内で規格（制約）を設けることで
構造を再利用させることが目的なの？＞OOの人
そうであれば、扱う問題ごとに制約が存在することによる理解のし辛さ（デメリット）は
仕方なくついてまわる問題なのかもしれないですね
開発環境なんかでこのデメリットはやわらげられるのか、どうか…
0314デフォルトの名無しさん
NGNG真のオブジェクト指向言語は何ですか？
0315312
NGNGおいらは OO はそれなりに好きだけど、原理主義ではないので
そのスジの人の意見は違うのかもしれんけど。
0316デフォルトの名無しさん
NGNGSelf
0317デフォルトの名無しさん
NGNGEiffel
0318デフォルトの名無しさん
NGNG「構造の再利用」はOOの目的ではなくデザインパターンの目的である、
と>>312は主張していると思われ。
しかしながらデザインパターンでもアダプタやデコレータの用に
既存のソースコードそのものを修正することなく再利用することを
目的とするものもある。
とはいえ、ほんとにまったく修正しないで再利用するのは現実には
結構難しいのは同意。
0319デフォルトの名無しさん
NGNGOOはコードの利用方法に適切に制約を設けることで可読性/保守性を高めます。
ってこれはOOの特徴と言うと語弊があるけど、デザインパターンってのは触らせる
部分と触らない部分をきっちり分けているわけでさーよ。
OOPLであれば、触らせないことを保証する為の仕組みが備わっているものが多い、とさ。
0320デフォ@どうなんすか？
NGNGデザインパターンは別にOOに含まれるというものではないのですか？
0321デフォルトの名無しさん
NGNGそれはあくまで「OOにおける再利用のための」という部分を省略してそう呼んでいると考えれば?
広義にはOOじゃないデザインパターンというのも考えられるでしょ。
ま、前者の意味が浸透してるから「デザインパターン」->OOという図式を崩せはしないだろうけど。
0322defaultの名無しさん
NGNG必要ない場合には、クラスライブラリからの派生で止めておけば、
わかりやすく、メンテナンスしやすいという意味です。
４階層継承したアプリケーションの場合、
ＯＯのいうように最下層のオーバーライドで
メンテナンスが用意かというと、そうではない。
実際には、最上位クラスまでさかのぼって、ソースを見るんです。
クラスライブラリからの派生のみなら、メンテナンスは比較的容易です。
クラスライブラリからの派生だけでも、クラスライブラリレベルでは、
インターフェイスは統一されていますし、ポリモーフィズムも使えます。
それでもなおアプリケーション内で継承するのは、
あくまで追加する共通のメソッドがあり、ポリモーフィズムを、
追加したメソッドで使用する必要がある場合だと思います。
（業務で扱うオブジェクトを、対象を意識せずに使うことは、
あまりありません。）
ＯＯは絶対に良いものだから、ＯＯの概念に沿わせるために、
抽象化するのでは、ＯＯのためのＯＯになってしまいます。
0323デフォルトの名無しさん
NGNGクラスライブラリから派生せず、独自の階層を持つクラスは作らない、という
主張ですか？
たとえばドロー系のツールなら、そこで扱う「形状」を表現するために
class Shape {};
class Circle : public Shape {};
class Rect : public Shape {};
...
みたいなクラス階層を考えるのが普通だと思うんですが、どうしてるんでしょう？
0324322じゃないけど
NGNG＞わかりやすく、メンテナンスしやすいという意味です。
に対して
＞クラスライブラリから派生せず、独自の階層を持つクラスは作らない、という
＞主張ですか？
なの？
0325デフォルトの名無しさん
NGNGhttp://www.microsoft.com/JAPAN/developer/library/jptech/TechArt/VTools/vb/vb6/ifacebased.htm
なんか良いことが書いてありそうなんだけど、
めんどくさくってインターフェースの利用に踏み切れない。
実体験としてインターフェースは重要ですか?
0326
NGNGプログラムＡ －＞ コネクタ －＞プログラムＢ
でいいじゃんか。
03271
NGNGhttp://www.f2.dion.ne.jp/~impact14/
0328ななしヘタぐらま
NGNGすごいー，このサイト，かなりわかりやすく説明が書いてありますね．
難しい事柄をこうやって易しく説明できる人って尊敬しちゃうな．
全てのプログラマー，必読！
いいページ教えてくれてありがとう＞ >>276さん
0329デフォルトの名無しさん
NGNG確かに。>>277は、全然読まなかったみたいだが、愚かな行為だったな。
0330デフォルトの名無しさん
NGNGOOを賞賛しない人を
馬鹿扱いすることでしか
反論できないのね
優越感に浸りたいのは
わかるけど
SEとしての決定的な資質に
かけてると思う
0331デフォルトの名無しさん
NGNG煽り厨房、逝って良し。
0332デフォルトの名無しさん
NGNG事実、ＯＯを否定するのは、おまえみたいなバカ。
自分が理解できないのを、ＯＯの欠陥のようにいう。
0333デフォルトの名無しさん
NGNG激しく同意。結局、OOの唯一の欠点は、アホには理解できない事。理解できないアホに、何をいっても無駄。
0335デフォルトの名無しさん
NGNGOOを理解した上でOOを批判するのであれば素直に読むけど、
OO批判のほとんどはOOを理解してないことが明らかだからね。
否定派を馬鹿扱いしているのではなく、
理解できない物を無闇に批判する人たちを馬鹿扱いしているだけだよ。
0336デフォルトの名無しさん
NGNGＯＯの概念を使わない人を、ＯＯを理解できない人と決めつけるのは、どうか
と思うよ。デメリットから、あえて使ってない人も多いと思うし。反対意見に
も謙虚に耳を傾ければ、得られる物もあるんじゃないかな？
よけいなお世話だったかな？
0337デフォルトの名無しさん
NGNGなんか的外れというかなんというか…
ちゃんと読めよ
0338デフォルトの名無しさん
NGNGそもそも 335 は「ＯＯの概念を使わない人を、ＯＯを理解できない人と決めつけ」て
いないと思われ。
0339デフォルトの名無しさん
NGNGここで叩かれてるのは明らかに理解してない
人ばかりだろ。
誰も決め付けてないよ。
0340デフォルトの名無しさん
NGNG日本では信仰の自由が保障されているのだよ。
オブジェクト指向原理主義者にとって、
その思想は正義なのだ。絶対なのだ。
疑問を抱くことも許されぬ、絶対不可侵の物なのだ。
その思想に沿わない設計をする奴は、
オブジェクト指向を理解できない馬鹿以外の
何者でもない。
ましてオブジェクト指向を批判する奴など、
悪その物に他ならない。
正義の制裁を加えるべき対象なのだ。
考えてもみよ。ユダヤ教を信じている人間に、
思想の矛盾を言ってなんになる。
信じている根拠を聞いてなんになる。
彼らにとって、教えに従わない人間は、
愚かな異教徒以外の何者でもない。
0341デフォルトの名無しさん
NGNG0342デフォルトの名無しさん
NGNG0343デフォルトの名無しさん
NGNG0344デフォルトの名無しさん
NGNG当然だ。ＯＯとか以前に、人として間違って
いる。
0345クズは氏ね
NGNGんだよ。ＯＯは、俺達選ばれた民だけ使いこなせるのさ。
0346デフォルトの名無しさん
NGNG－－－－－－－終了－－－－－－－
0347デフォルトの名無しさん
NGNGOOを使っている人が少数派だと思っている？
0348デフォルトの名無しさん
NGNGラスに動物クラスがあって当然だってことがＯＯは正しいってとこからス
タートしているとおもう。だからそれ以外の考えはＯＯを理解してないってこ
とになるとおもう。デモそれってＯＯ的な考えをしない人＝ＯＯを理解してな
い人ってことでしょ。これだとＯＯのにそってない人がみんなＯＯを理解
してない人になるとおもう。ＯＯを理解している人はＯＯな人たちだけになっ
ちゃうとおもう。これっておかしいとおもう。
0350クズは氏ね
NGNG猿程度の知能があればＯＯは理解できる。しかしクズは別。ここにはクズが多すぎ
る。
0351デフォルトの名無しさん
NGNGお前もくずの一員だと言うことを認識せよ
0352デフォルトの名無しさん
NGNG非OOP派も猿程度の知能はあると思うよ。たぶん(^^;
0353クズは氏ね
NGNGオマエモナー
0354デフォルトの名無しさん
NGNG今までの流れを
１ OO否定派
２ OO肯定・継承否定派
３ OO肯定・継承肯定派
と勝手に分類してみる
オレは今の所は２だが・・・
３は２まで罵ってしまうのが痛い
オブジェクト指向原理主義過激派（３）は穏健派（２）まで敵にしてしまい、
それを見た１は２と３の両方を嫌ってしまう
OOはとりあえずはカプセル化だけでいいのでは？
カプセル化のメリットは誰にでもすぐ分かるだろうし
オレ自身はカプセル化が最大のメリットだと思っている
継承や多態性はそのメリットが分かりにくいし、考えずにやると破綻しやすい
継承しなきゃOOじゃないというのはおかしいだろう
0355デフォルトの名無しさん
NGNGそれらはＯＯのある特定のパターンの実現手段に過ぎない。
0356デフォルトの名無しさん
NGNGアンチャン、わかりやすいじゃねーか。おりゃこれでいくと、基本的には３だな。
趣味で作ってるプログラムは、バリバリ３だしな。仕事の大規模システムが４・５
階層だと、さすがにきついがな。
0357デフォルトの名無しさん
NGNGﾅﾝﾃﾞ言語の進化を否定すんだ？そうすると殆どのクラスライブラリはなくなるし、
クラスを派生させて振る舞いの差分をコーディングするって当たり前の事が出来なくなるＹＯ！
継承には明確なメリットがあって、通常のOO言語仕様にあるのに。
0358デフォルトの名無しさん
NGNGつか、
主人「猫は「ニャー」と鳴け、犬は「ワン」と鳴け」
猫「ニャー」
犬「ワン」
猿「…」
ってのは OO じゃないだろ。
主人「鳴け」
猫「ニャー」
犬「ワン」
猿「キィキィ」
じゃないとダメ。
メッセージに対してオブジェクトが自分で振る舞いを決めるてこそ OO だろ。
「多態無しですが、自分は OO やってます」なんて意味無いし。
0359デフォルトの名無しさん
NGNG勘違いＯＯ派発見。
0360デフォルトの名無しさん
NGNG多重継承についてどう思いますか？
0361354
NGNG継承が許されるのはクラスライブラリだけ、という考えもある
クラスライブラリはユーザー共有の知識なのでどこに実装があるのか皆知ってるが、
自作のクラスで継承を多用すると実装がどこにあるのか探すのが大変だろう
デバッグする時はなおさらだ。
そりゃクラスライブラリにもバグがあるけどさ・・・
0362デフォルトの名無しさん
NGNG与えられた道具は、必要なときに必要なだけ使えばよい。
常に使わなければならない訳ではない。と言いつつも、俺は3だ。
しかし、2については気持ちは分かる。1はどうかと思うが･･･
＃番号書くと立場が明確になって、良いんではないか?
0363デフォルトの名無しさん
NGNG機能を説明するためのサンプルに、十分なメリットがないと難癖つけていたのでは、
いつまでも機能を理解することはできないよ。
１０件のクイックソートの例を見て、ヒープソートの方が速いと言っているようなものだ。
その例が現実にはどのようなことに役立つのか、そこを自分でよく考えて欲しい。
もちろん適材適所で使うべきなのは言うまでもないことだよ。
継承否定派の人たちは、ポリモーフィズムを口にはしていても理解しているようには見えない。
オブジェクト指向でポリモーフィズムしないなんてナンセンスもいいとこ。
きちんと説明する必要があると思うんだけどね。
0364デフォルトの名無しさん
NGNGせーんだよな。
実際の仕事で、こんな概念的に整理できる単純ケースなんて、殆
ど無いからな。ましてや巨大プロジェクト全体を眺めたら、概念で
派生ツリー作ろうなんてのが、無理だとわかる。結局のところ、処
理を分析して、地道に共通部分を洗い出して行くしかない。
どうもＯＯ原理主義派？？ってのは、机上の空論っぽいんだよな。
趣味でプログラム作ってる、只のオタクじゃないのか？
0365Delギコ
NGNG＞オブジェクト指向でポリモーフィズムしないなんてナンセンスもいいとこ。
ｵﾚﾊ 2ﾐﾀｲ
∧∧ ／￣ >>363
＠＿(,,ﾟДﾟ) ＜ 全部が全部理解してなくちゃ
⊂,,＿_つつ. ＼＿ 開発しちゃいけないって事にならない？
クラスライブラリ開発者とクラスライブラリユーザーとを使い分けて
考えたらどうかなあ。クラスライブラリユーザーはポリモを理解してなくて
使いこなしていないだろうけど
OOの恩恵を受けてるわけだからそれでいいでしょ。
＞ 犬と猫の上位に動物があれば便利ってのが、そもそもインチキく
＞せーんだよな。
クラスライブラリを作成するときには考慮する事は必須だけど
現実にｿﾌﾄ作っていく際に必要あれば上位の動物をつくるけど
犬、ﾈｺ、別にしても問題ない時は別々のままにしたりするよねー。
究極的な事言い始めたら
全部のクラスを原子クラスから分子クラス、固体/液体/気体クラス
と作らなきゃっいけないなんていうのはおかしいことなんだし。
0366364
NGNG> 機能を説明するためのサンプルに、十分なメリットがないと難癖つけていたのでは、
いつまでも機能を理解することはできないよ
そういう高飛車な態度が反発されてんだよ。いい加減、自分だけ
分かってるような態度やめろよな。
サンプルなんてものは、全く逆の結論をさもまことしやかに見せ
ることが出来ることぐらい、おまえでも分かるだろ？
0367通りすがり
NGNGOO原理主義者ってのは言い得て妙かも
(この言葉を広めましょう)
この人達って再利用とかわかりやすさとか
ほんとはどうでも良くって
OOの考え方に則ってプログラム作るのが
1番大事なんじゃない？
つまりはOOの原理が1番大事な人達
0368デフォルトの名無しさん
NGNGあんまりOOP派の株を下げるなよな。
0369357
NGNG考え方はあっても良い。だが、クラスライブラリを利用する人はそのクラスの派生による
差分コーディングで作ってるんだ。
>犬と猫の上位に動物があれば便利ってのが、そもそもインチキくせーんだよな。
クラスライブラリのクラスを継承後、振る舞いを差し替えるいう例。犬、猫、動物関係無し。
0370357
NGNG>概念で派生ツリー作ろうなんてのが、無理だとわかる。
クラスライブラリには派生ツリーがあるのを知らない？
クラスライブラリを使ったことあるなら、そのメリットわかるよＮＥ？
0371357
NGNG自分は多重継承使ってないので、使っている人に聞いて下さい。
現在主流のOOPの限界は、単一継承か多重継承かにあるんでなく、
実行時の継承が有るか無いかだと思うけどね。（主流じゃない言語にあるらしい）
0372デフォルトの名無しさん
NGNGオブジェクト指向でポリモーフィズムしないなんてナンセンスもいいとこ。
うーん。
難しいところだね。
鳴けといえば、相手が何か解らなくても鳴く。
考えると良さそうだけど、現実の業務で犬か猫か解らない物に、
鳴けというケースは滅多にないからね。
上位クラスで扱う必要性があれば、便利だと思うけど。
犬と猫のインターフェイスがあまりに違うなら、継承による依存関係がない方が良いときもあるし。
時と場合によるね。
ポリモーフィズムを使わなくても、犬に鳴けといえばワンと鳴くし、猫に鳴けといえばニャーと鳴くしね。
当たり前だけど。
0373357
NGNG0375小泉
NGNG0376デフォルトの名無しさん
NGNGクラスライブラリもどきのツリーだったら怖い(^^;)
0377デフォルトの名無しさん
NGNG0378357
NGNG継承による差分コーディングにより、何百万ステップが激減するんじゃない。
ステップ減らせることを否定しちゃイカン。開発もメンテもステップが多いものは×。
0379357
NGNGクラスライブラリを派生することにより、何百万ステップが激減のが分かりやすい。
自分が記述するコードを大型なクラスツリーにしなきゃならん、という思い込みが間違いだよね。
0380デフォルトの名無しさん
NGNG動物クラスを作って継承させたらいい。
0381デフォルトの名無しさん
NGNG0382354
NGNGクラスライブラリから派生するのはむしろ穏健派の考えでは？
それに関してはあまり否定はしない
問題なのは自分で抽象クラスを作って継承する場合
何度も言うがクラスライブラリを利用するのとそれ以外は全く別物
クラスライブラリのような継承ツリーがアプリの中にあったら困るでしょ
クラスライブラリは
・変更されることがなく
・ユーザーに共有の知識であり
・ソースを読む必要がなく
・デバッグする必要が無い
という点でアプリそのものとは全く異なる（もちろん、完全ではないが）
0383デフォルトの名無しさん
NGNG人間クラスは
クロマニョンクラスとか
イクチオステガクラスとか
アミノ酸クラスとかから
派生させるべきって事？
結論は何なの？
0384357
NGNG>・変更されることがなく
勝手に内部が変更されるから便利なの。
コンパイラのバージョンが上がったら、ドッキングプロパティが増えてたとか。
>・ユーザーに共有の知識であり
提供された時点では共通の振る舞いだが、派生で振る舞いを変えれるのが良いの。
>・ソースを読む必要がなく
派生して振る舞いを変えるには、該当メソッドを知らなければならないので読まなければならない
>・デバッグする必要が無い
？
0385デフォルトの名無しさん
NGNG0386デフォルトの名無しさん
NGNG0387sage
NGNG0388357
NGNGそうでもないＹＯ！
ボトムアップで作っていく場合にも、関数よりクラスのが楽。
専門分野特化業務アプリって大型コードになるが、
クラスとメソッドの枠だけ作ってって、後から中身を作る方が、塗り絵みたいで、精神的に楽。
0389357
NGNG「クラスライブラリがアプリそのものとは全く異なる」という結論です。
アプリを一から書くのでなく、クラスライブラリからクラスとってきて、
動作の違う部分だけオーバーライドするって開発になるんです。
だから、出来上がったものは、継承ツリーがあってその上位層はクラスライブラリになってた、
って感じで等価になるんです。
そう出来上がってない場合は、
クラスをnewして外からプロパティセットしてメソッド呼んでと、、、
これでは、関数と変わりません。
0390357
NGNGそういう開発方法とるのは、ブビ坊がCOMやActiveXを使い場合です。
COMは派生出来ないので仕方有りません。
0391デフォルトの名無しさん
NGNG0392デフォルトの名無しさん
NGNGはたしてＯＯＰは？
0393357
NGNG残るのは、汗で書かれた汎用機OSとLinuxカーネル位か。
X-WindowもC言語かなぁ。
0394素朴な疑問
NGNG継承否定派も含めめ、
これだけＯＯ信者が多いのは何故？
0395デフォルトの名無しさん
NGNG「汗で書かれた」＝「アセンブリ言語で書かれた」
「汗で書かれた」＝「血と汗と涙で書かれた」
0396デフォルトの名無しさん
NGNG悪い宗教とはそういうものです。
0397デフォルトの名無しさん
NGNG構造化設計のほうがこけている割合は圧倒的に多いと思うけどね。
クソ設計の泥沼に陥っている奴は誰だ？
0398素朴な疑問
NGNGなるほど。
日本の宗教人口は実人口の２倍っていいいますもんね。
教祖の金儲けのために踊らされてると知りつつも、
信じてしまうのが日本人なのか？
0399素朴な疑問
NGNG構造化については話を聞きませんが
、やはり悪い酒興のようですね
0400素朴な疑問
NGNGです
0401357
NGNGあ、そうなの？初耳。言語は何よ。
>構造化については話を聞きませんが
構造化では出来上がるシステムが知れてる。
>、やはり悪い酒興のようですね
こういう人は汎用機に留まって、WinやLinux系に移行しない方が良いと思います。
別にそれを止めはしません。
0402357
NGNG↓
汎用機COBOLに留まって、の方が分かりやすいですね。
0403素朴な疑問
NGNGすいません、構造化のことは
、まだ勉強していないのです。勉強不足ですいません。
0404デフォルトの名無しさん
NGNGhttp://www3.nikkeibp.co.jp/WAT2/971212/971212trein01.html
OO がいけないわけじゃないじゃん…
0405デフォルトの名無しさん
NGNG…（閉口）
0406デフォルトの名無しさん
NGNG＞IBMイコールOOT（オブジェクト指向技術）と考えてもらって構わない
ｶ､ｶｺｲｲﾉｶﾅ？
0407357
NGNGOOPから失敗というのは間違い。
第三世代言語にクラスが追加されたのがOO言語。
例えば、C++使いながら、実はC関数っていう開発もあるし、
汎用機でJava使いながら、関数単位で、Javaのクラスをnewして、
コボラー人海戦術方式したり出来るし。
なんかOOP否定するのに必死みたいだが、OOP言語にも旧言語仕様は入ってるので。
0408404
NGNG否定しようとなんてしてないじゃん…
> OO がいけないわけじゃないじゃん…
って言ってるだけやん…
つか
> > いくつものシステムがこけてるのに、
> って、OO のせいじゃないやん
って言ってみたかっただけやん…
0409357
NGNGそれから407に色々書いたけど、やっぱり関数セットを一杯書くより、
何でもクラスにしといてメソッドにしといた方が絶対楽。一回やれば分かるＹＯ！
0410OO信者
NGNG・継承できそうなら継承しなければならない→嘘
・現実世界の階層構造を必ず模倣しなければならない→嘘
開発するソフトウェアにとってのみ必要なクラス階層構造にする。
そのための指針が、
アナリシスパターンやアーキテクチャパターンやデザインパターン
などのパターン技術。（+プロセス技法)
継承はあくまで差分プログラミングと多態性を実現するための手段であって目的ではない。
0411357
NGNG>継承はあくまで差分プログラミングと多態性を実現するための手段であって目的ではない。
一旦、差分プログラミングと多態性になれると、
それが出来ない言語は鬱陶しくて、やってられなくなることを付け加えますです。
0412デフォルトの名無しさん
NGNG同意
> 開発するソフトウェアにとってのみ必要なクラス階層構造にする。
入門書だと、これが抜けてる場合が多い気がします。まずは犬と猫で、上位に動物クラスと
いうのは現実に則していて分かりやすいけど、実用的じゃない。
あくまで問題（ソフトウェア）の性質に合わせてクラスは抽出しないと。
0413デフォルトの名無しさん
NGNG意見には同意だけどＯＯの話じゃなくて開発技法一般の話だと思う。
要は教条主義に陥る奴は誰であれバカだよ、と。
0414デフォルトの名無しさん
NGNGＯＯ信者にしては、だいぶ現実的な思想だな。
しかし、まだ詰めが甘い。
差分プログラミングや多態性は、最終目的ではない。
最終目的とは何かを考えてみよ。
対象のシステムにおいて、差分プログラミングと多態性が、最終目的に対して与えるメリットとデメリットを比較せよ。
それが即ち設計だ。
0415デフォルトの名無しさん
NGNGやっとまともな意見が出てきたって気がするよ
0416デフォルトの名無しさん
NGNG357はもっとOO原理主義的に
・継承できそうなら継承しなければならない→真
・現実世界の階層構造を必ず模倣しなければならない→真
となってくれないと。
パターンという単語が出てきて逃げ腰か？>>357
0417354
NGNGOO穏健派的には
・継承できそうだけど、継承したくない→真
・現実世界の階層構造を模倣できそうだけど、模倣したくない→真
ですね（藁
0418デフォルトの名無しさん
NGNGケースバイケースでしょ。
0419ＯＯ道師範
NGNGそれが俺様のＯＯ道美学じゃ。文句あるか！
0420デフォルトの名無しさん
NGNG0421デフォルトの名無しさん
NGNGはたから見てる分には、カッコいいかも？
でも、一緒に仕事するのはイヤ。
0422デフォルトの名無しさん
NGNG0423デフォルトの名無しさん
NGNGαでどうだ。構造化はβ。手続きがγ。
0424デフォルトの名無しさん
NGNG最優先の選択肢は「独立したオブジェクト」。
次が「委譲」。
その次にやっと「インタフェイス継承」。
最後に「実装継承」。
ほんとに必要なの？「多重実装継承」。
0425デフォルトの名無しさん
NGNGmix-in的に使えば極楽。
0426荒らしではなくてテストです
NGNGい
う
え
お
か
き
く
け
こ
さ
し
す
せ
そ
た
ち
つ
て
と
あ
い
う
え
お
か
き
く
け
こ
さ
し
す
せ
そ
た
ち
つ
て
と
0427426
NGNGありがとうございました。
0428デフォルトの名無しさん
NGNG言語によっても変わる気がする。
C++なら間違いなく後者だが
0429357
NGNG>・継承できそうなら継承しなければならない→真
>・現実世界の階層構造を必ず模倣しなければならない→真
これは単なる馬鹿な意見ですね。
現実世界の階層構造は一意に決まっているものではありません。
現在主流のOO言語では不可能。不可能を目指してはいけません。
0430357
NGNG継承賛成派・・・継承でステップを激減
継承反対派・・・現実世界の階層構造を必ず模倣しなければならない
なぜ反対派が、極論を言うか。継承が何か分かってないからです。
構造化の初期は同じことが言われたでしょう
構造化賛成派・・・関数でステップ激減
構造化反対派・・・「goto行番号」ならソース１つで良いのに．．．
手続き分割出来るって、出来るものは全て分割しろよ！
0431357
NGNG反対派はそのメリットにそったクラスを一個でも作って検討してＹＯ！
0432デフォルトの名無しさん
NGNG業界の弱さですね。西洋人はオブジェクト指向が出始めた頃から
ばりばりとＯＯプログラミングして、InterViewというフレームワークを作っていたの
だけど日本人はそれを真似するぐらいでしたね。日本人には向かない
のかもしれませんね。
0433
NGNGＯＯ出る前からやってたよ。
F6-PageDown-F8->別ファイル-F9
0434デフォルトの名無しさん
NGNG> 日本のビジネスソフト業界
2チャンねらーの間違いでしょ
0435デフォルトの名無しさん
NGNG>>430
なるほど……と一瞬思ったけど、ちょっと違うと思う。
継承賛成派は、使うところと使わないところを見極めた上で、
使うべきところではしっかり使うべきだと言っている。
継承反対派は、全てのケースで無理に使うとよくないと言っている。
つまり、どちらも全てのケースで継承を使うのは良くないと知っていて、
この点では実は同じことを言っている。
それではどこが違うのか。
賛成派は、使いどころの見極めについて具体的な方法論を持っていると思う。
そしてどうすると失敗するのかを明確にわかっている。
だから使うべきところなら迷わず使う。
しかし反対派は、どこで見極めるのか掴めてなくて、
失敗しないために、慎重になるという方法を選んでいる。
だから確固たる信念を持って使うべきという人がいると、
その人には慎重さが足りないと思ってしまう。
0436
NGNGＯＯはクラスなど無くても成立します。
0437
NGNG0438435
NGNG失敗する可能性を恐れて継承の良さを半端に教えるのはよくない。
まず成功する場合のメリットをしっかり認識させた上で、
さらに失敗する可能性について教えるべきだと思う。
そうしないと、継承を恐れすぎて、身につかなくなってしまう。
さて、どうすればうまく継承できるのか。
何度か失敗してみるのがいちばん手っ取り早いけど、
学生が勉強しているならともかく、実務で作業しながら学ばないとしたら、
これはリスクが高すぎる（俺は実務で失敗して学んだけどね）。
やはりUMLなどのモデリング手法を学んだ上で、
十分な要求定義と分析を重ねるしかなさそう。
あとできる限りデザインパターンから設計を選ぶようにしないといけない。
でもこれをうまくやるにも、経験がものをいうんだよなぁ。
構造化設計の経験がある人にオブジェクト指向を教えるのは案外たやすい。
状態遷移とかERとかDFDとか、かなり似ているからね（つーかほとんどそのまんま）。
でも、構造化言語を使っただけで構造化設計をできた「つもり」になっている人に、
オブジェクト指向を教えるのは非常に難しい。
そういう意味で、構造化設計の経験者なら、オブジェクト指向でも
すぐにそれなりの設計ができると思うのだけど。
0439435
NGNGクラスや継承が無くてもOOが成立するというのは、間違っては無いですけど、
それは基礎的な話ですよね。
OOをベースにした膨大な技術の蓄積を享受するには、継承は避けられない。
0440357
NGNG>ＯＯはクラスなど無くても成立します。
確かに現実世界には確固としたクラス階層というものは無いんだよね。
オブジェクトといえるものはあるが。
そういう意味で言うと、
>OO穏健派的には
>・現実世界の階層構造を模倣できそうだけど、模倣したくない→真
この人はまだ良く分かってない。
0441357
NGNGオブジェクトベースのoopでは、クラスが無くて、実行時に継承するそうです。
0443357
NGNG哺乳類の固体に、有る時期ウィルスがDNAを転写、又は紫外線があたって、
犬に分化したもの、猫に分化したものが出来たという方が現実味あるよね。
そうだと、実行時の継承の方が現実に近い。
だから、実は、動物、犬猫猿が変だって言ってた意見も分かるよね。
0444357
NGNGシミュレーションする場合もオブジェクトベースのが記述しやすいかも。
ではお休みなさい。
0445435
NGNGいや、そこはわからない。
現実の世の中を完全に模倣することに、あまり意味は無い。
結局さ、所詮はソフトウェアに過ぎないわけよ。
ソフトウェアから見てオブジェクトが十分に抽象的なら、
必要以上に抽象化する必要は無いでしょ。
あるソフトでは動物クラスという抽象クラスが必要かもしれないし、
別のソフトでは不必要かもしれない。
そこは設計の都合次第。
0446名無しさん＠ＸＥｍａｃｓ
NGNG0447デフォルトの名無しさん
NGNG禿同
抽象とか模倣とか、一部の人たちがやけに
難しいことを得意げに言ってるが、
それって実際役に立ってますか？
少なくとも自分の周りでは役に立ちそうにないね。
＞その蘊蓄。
純粋に設計し、純粋に組む。それが正道でしょ？
0448
NGNG0449デフォルトの名無しさん
NGNG0450デフォルトの名無しさん
NGNG>オブジェクトベースのoopでは、クラスが無くて、実行時に継承するそうです。
うーん。それはちょっと違う。
動的な言語、たとえばSmalltalkやruby、ならクラス自体を実行時に処理するんで…。
Objectベースとか「prototype型」と呼ばれる言語は、クラスじゃなく
インスタンス「に」メソッドやフィールドをつける。
Objectを産む方法は、既に有る「望んだものに一番似てるObject」を「コピー」し、
それに好きなメソッドやフィールドをを追加/削除することで得る。
0451デフォルトの名無しさん
NGNGhttp://www.microsoft.com/japan/developer/scripting/default.htm?/japan/developer/scripting/jscript/doc/jsconcreatingownobjects.htm
WebComponentsってのがこれを使ってましたっけ?
0452
NGNGJavaのAPIはクラス設計の抽象化に失敗していて、やたらにクラス増やしてますが
何か？
0453デフォルトの名無しさん
NGNGhttp://www.microsoft.com/JAPAN/developer/library/jptech/TechArt/VTools/vb/vb6/ifacebased.htm
MSDNだよ。ブラクラじゃないから。
0454デフォルトの名無しさん
NGNG0455デフォルトの名無しさん
NGNGMetal～クラス
ストリーミングクラス
↑このへん。
0456デフォルトの名無しさん
NGNGJ～については結構クラス数爆発の印象はありますね。でも、抽象化に失敗かと言うと逆で、
抽象化し過ぎたせいで、強力な柔軟性と引き換えに使いやすさ/分かりやすさを犠牲にした感はあります。
ま、それも抽象化に失敗といえるか(藁
0457デフォルトの名無しさん
NGNGだと勘違いしてるのでは。
0458デフォルトの名無しさん
NGNGうわべだけで理解したつもりになって
語る厨房は無視したらいい
ＯＯを無価値と思わせるのもそれはそれでいいではないか
0459デフォルトの名無しさん
NGNG>>458
君たちみたいな勘違い君がいると、我々ＯＯ派の見識が疑われ、不毛な議論に逆戻りだよ。
反ＯＯ派の為ではなく、まともなＯＯ派のために消えてくれ。
0460357
NGNGこういう意見てどうしようも無いよね。説明してないヤツだし。
オブジェクト指向を否定する人達にクラスベースとオブジェクトベースと
同時に分からせることは出来るわけない。順をおって、クラスベースから説明しないと。
説明ということがどういうことか分からない学生君なら、ちょっかいかけなきゃ良いのに。
0461sage
NGNG二度目読み直し中。
0462デフォルトの名無しさん
NGNGオマエモナー
ＯＯを語りたがるやつほどＯＯを知らないことがほとんどだよ
ネット上のＤＱＮＯＯページのどれほど多いことか
0463デフォルトの名無しさん
NGNGだからＭＦＣは分かりづらい。
0464デフォルトの名無しさん
NGNGそういうのは、DQNではないOOページを作ってから言おうな。
せめてDQNじゃないページを紹介してみろよ。
読んでやるから。
どうでもいいが抽象論で満足してないで
現実にどういう場合にどういう継承を使ったとか言えばいいのにのお。
継承でクラス階層増やしまくって他人には使いにくい
意味不明なライブラリを自作して喜んでる奴が多そうだな
0465デフォルトの名無しさん
NGNG混同してる方が説明を要すると思うぞ。
クラスと００は全くの別物。
0466デフォルトの名無しさん
NGNGドキュメント・ビュー・アーキティクチャなぞ常識。
だから別オブジェクトにしただけの話。
特にビューの方はパーツ化して使いまわしがしやすい。
十数年前、プログラム組み初めて（アセンブラ）直ぐに気付いて
取り入れたよ。
0467357
NGNG>クラスと００は全くの別物。
小学校一年では、地球から観測した太陽（天動説）を教えてから、
中学生で地動説になるんだろうが。
同じように、構造化プログラミングを教えるときは、
関数を作れって教えるが、それはoopでは間違いになる。
説明の途中でクラス説明したら駄目なのか？
氏ねや厨房。
0468
NGNG0469デフォルトの名無しさん
NGNG中身の無い議論に誘導するのはもう止めよう。
0470
NGNG0471デフォルトの名無しさん
NGNG眺めてあれこれ言ってるより、さっさと食べて仕事しろってことだな。
0472357
NGNG>てんぷらと中華料理ぐらい違う
どっちも食べ物で共通項あるじゃないか。
クラスベースのoopではoo=クラス
オブジェクトベースのoopではoo=オブジェクト
だろ。「」は人に説明ということがデキンみたいだな。
学生というか中身の無いヤツというか。サヨナラ。
0473357
NGNG「」は自分は全て知ってると悦に入ってるんだろうが、
しかし、オブジェクトベースでさえも通過点なんだ。技術とはそういうもの。
順を追って説明出来ないなら、会話に入らない方がみんなのため。
0474デフォルトの名無しさん
NGNGＧＵＩ周りは 出来合いのクラスライブラリ使うからＯＯ設計の出番無しさ
アプリケーションだとすぐに相互に依存しあってＯＯ設計だと
再利用が逆に難しくなった経験しかないな。
OCXはそのまま利用出来るならいいけどそうじゃなきゃ後になって
どこを弄っていいか判らなくなる事多いし
今迄手軽に再利用出来たのはDelphiコンポーネントだけだな
しいてクラスが再利用出来た経験は、クラスライブラリをラップする
関数用意しておいた時だな・・・・はは・・・・
スクリプトを継承出来るような構造で書いてさ、結局文字列渡して
実行する関数として使うだけなんてさ・・・ははは・・・・
0475憂鬱な名無しさん
NGNG私は実はオブジェクト指向でプログラム組んだことは無いんですが、
最近「憂鬱なプログラマのためのオブジェクト指向開発講座」や
メイヤーさんの「オブジェクト指向入門」等を読んで、オブジェクト
指向に感動したものです。
オブジェクト指向の分析設計のやり方が良くわからない、または、オブジェクト
指向の分析設計でうまく行くとは思えない人は前者の本を読んでみては
どうでしょうか？
誤解も解けて自信が湧いてくると思います。
私の名前もその本から取りました。
このスレにも「憂鬱な・・・」を読んでいると思われる人の発言がいくつか
ありました。
って、ちょっとスレの流れとはあまり関係ない話ですみません。
0476
NGNG0477デフォルトの名無しさん
NGNG0478デフォルトの名無しさん
NGNG0479デフォルトの名無しさん
NGNGそんなあなたにこのＨＰ
http://www2s.biglobe.ne.jp/~Beyond/amue/byan/guest/tetu/katsu01.html
0480デフォルトの名無しさん
NGNG差分プログラミングの柔軟性や、多態の便利さは、無条件で得られる物ではない。
実装の継承は依存を発生させ、オブジェクトの独立性を損なう。
インターフェイスの継承でさえ、現実には依存なしの設計は不可能に近い。
クラスの多段階層は実装の位置を不明確にし、メンテナンスやデバッグに弊害をもたらす。
これら支払わなければならない代償について、どうも理解できていないようだ。
0481デフォルトの名無しさん
NGNG委譲しまくりのクラス思想もどうかと思うけど。群生の初期段階っぽい。
どうでもいいことだがＭＳの書くものはＯＯとは認めたくない。
あんなのはＯＯではあるまいに。病んだＯＯというか。
0482デフォルトの名無しさん
NGNGＯＯ本には、そんな事書いてないからね。実際プログラミングした奴じゃないと、
わかららんよ。本に洗脳されて、わかったつもりの奴が多いから。
0483デフォルトの名無しさん
NGNG0484デフォルトの名無しさん
NGNGＯＯＰのクラスライブラリって、どれもわかりづらくて、
使いにくいですよね？ たぶん、最も優秀な、最もＯＯに
精通した人達が、作ったと思うんですが？
そこで私が思うのは、作りが悪いのではなく、ＯＯで作る
と、ＯＯでの開発が向いていると思える汎用クラスライブ
ラリでさえ、ああなっちゃうのかなと。何かＯＯの限界が
見えたような気がしてしまうのです。
0485480
NGNG俺はそうは思わん。
このスレにも住み着いている、ＯＯオタクみたいのが作るから、継承オバケみたいになる。
多態の必要性等を十分吟味して作れば、もっとましな物が作れる。
0486デフォルトの名無しさん
NGNG0487デフォルトの名無しさん
NGNG機能にムダがありすぎ
仕様がいいかげんすぎ
相互関係がしょぼすぎ
だからです
0488デフォルトの名無しさん
NGNGVCのクラスブラウザとかがあれば結構マシになる。
0489デフォルトの名無しさん
NGNG階層が深くて、何度もオーバーライドされてて、
オーバーライド中では上位クラスの実装もよんでて。
やっぱ探すの大変だよ。
0490デフォルトの名無しさん
NGNG上位クラスに、ツリー形式ですぐ飛べるようになってるから
随分マシだよ。
0491デフォルトの名無しさん
NGNGＯＯＰで生産性上がるならＯＯＰ採用してる会社は利益率上がって
採用してない会社を駆逐してるはずだよ？
現実はなんかＯＯＰ採用してるとこの不振が目立つ・・・。
これが世の中の動きという奴。
0492デフォルトの名無しさん
NGNG更に、使いこなせないものに引きずられるのは
自分の使うべき道具を見切れていないその企業自身の問題でしかない。
ＯＯに限らず、ソフトウェア開発プロセスが流行った時代にも同じようなことはあった。
もちろん、だからと言って、ＯＯが有益である、と結論できるものでもない。
0493デフォルトの名無しさん
NGNG上がってないのなら企業の問題ではありません。
ＯＯは使いこなすのが難しいっつう事でビジネスとしてのＯＯの評価は
終わってしまいます。
0494デフォルトの名無しさん
NGNG非ＯＯの場合の同様のデータと比較しなければ意味がない。
そういう具体的な話が持ち出せない限りは煽りと変わらない。
言っておくが、ＯＯを擁護したいわけではない。
0495こんなのは？
NGNGhttp://www.hotwired.co.jp/news/news/business/story/20010420103.html
0496デフォルトの名無しさん
NGNGその記事ではOOのことには触れられてなくて、実行速度が悪かった
としか書いてないし。
0497デフォルトの名無しさん
NGNG何百人いても無能が揃ってるとどうしようもないだろう
逆に十数名でもＯＯを武器に生産性を上げている企業も多い
ＡＩは専門家がいなければアホなものしか作れないしな
結局アホの集まりだったということだろう
0498デフォルトの名無しさん
NGNG４９５の話は、ＯＯとの因果関係が非常に不明瞭だけど、
失敗の原因を究明するときに、何でもアホだからとか馬鹿だからとか、
短絡思考過ぎると思うけど。
失敗原因の分析能力に欠ける上、何の発展性も改善も得られないよ。
0499デフォルトの名無しさん
NGNG同意
プロジェクトは、優秀な人材集めりゃ成功するわけ
じゃない
逆に一部の優秀な人材と、多数の凡人でも、十分成
功できる
むしろそれが出来ない方法論なら、方法論に問題が
あると認めざるおえない
0500デフォルトの名無しさん
NGNGそれでは非オブジェクト指向言語がオブジェクト指向を
サポートしようとしている現状にはどう思われますか？
0501デフォルトの名無しさん
NGNG0502デフォルトの名無しさん
NGNG>むしろそれが出来ない方法論なら、方法論に問題が
>あると認めざるおえない
それは問題分析者がアホなんだよ
ＯＯにせよなんにせよ、プランを立ててから実行資源、条件を
綿密に計画しなきゃ意味がない。ＯＯはそれが特に顕著。
ふさわしい言語、解析は問題によりけり。それがわからないアホなら
どうしようもない救いもない。
なんでも方法論のせいにする前に、問題解析さえできていない
アホのほうがはるかに問題だろ。
0503デフォルトの名無しさん
NGNG皆逃げ出してるって。
0504デフォルトの名無しさん
NGNGＷＩＮ用の店で売ってるようなソフトで成功してるところなんか無いんじゃない？
0505デフォルトの名無しさん
NGNGアマですか？
0506デフォルトの名無しさん
NGNGただ最善を模索するのみ。
0507デフォルトの名無しさん
NGNG0508デフォルトの名無しさん
NGNG構造化の利点は関数を定義できること。
クラスを定義できなくてもいいと言うのは
関数を定義できなくてもいいと言うのと同じ。
関数を定義できるようになったことが進歩であるように
クラスを定義できるようになったことはさらなる進歩だ。
0509デフォルトの名無しさん
NGNGクラスのないオブジェクト指向言語もある。
それは利点のない言語か？
0510デフォルトの名無しさん
NGNGMFCってOO実践してると言っても良いんだろうか・・・？
要は運用次第って事でしょ。
共産主義という考え方があっても運用次第では旧ソの様になってしまう。
運用しずらい概念であるということなのかも。
0511あ
NGNG0512デフォルトの名無しさん
NGNG0513512
NGNG0514デフォルトの名無しさん
NGNGオブジェクト指向は計画経済、共産主義みたいなもんだ。
0515デフォルトの名無しさん
NGNG予測に失敗すれば経済は破綻する。
0516デフォルトの名無しさん
NGNGつうことで>>510さんきゅー
0517デフォルトの名無しさん
NGNG営業用の「オブジェクト指向」があって、これはお仕事を貰う為の格好付けみたいなもんでしょ
0518357
NGNG>ＯＯＰで生産性上がるならＯＯＰ採用してる会社は利益率上がって
>採用してない会社を駆逐してるはずだよ？
>現実はなんかＯＯＰ採用してるとこの不振が目立つ・・・。
>これが世の中の動きという奴。
これは一体どこの話なんだろう。OOPを取り入れない会社とOOP取り入れた会社の２種類に分かれる？
今、OOでない言語って、VBとCOBOL類（OO-COBOLは余り聞かない）しか無いよね。
どこの会社でも、VC++、DelphiVCL、Javaと取り入れている。
10年前のUNIX/プリプロセッサC++は取り入れてるところはあまり無かったようだが。
システム開発失敗事例というものは年に山ほどあって、その解決策としてクラスライブラリというのが一般的。
0519357
NGNG■期待を裏切ったJava
純粋に技術的に見ても，Java不振の原因には2つあると思います．
まず，グラフィックスの描画速度が不自然に遅いという事実．これは，互換性を向上させたSwingに至ってさらに悪化．
もうひとつは，実は本当に矛盾しているのですが，互換性の欠如．それも，異なるJavaのバージョン間での互換性も含めての話です．
まともにJavaを使おうと思えば思うほど，Javaの環境設定に注意を払わねばなりません．Java開発環境，実行環境を何種類も載せて，注意深く切り替えて使うなんて状況も，決して珍しくありません．
とにかく，Javaは遅くて面倒なのです．
■Javaを蹴落としたLinux
私には，LinuxはWindows市場ではなく既存のUNIX市場を食い荒らしたとしか思えません．Linuxこそ，Microsoftの最大の陰謀ではないかとも思いたくなります．
0520
NGNG0522オフトピ
NGNG0523354
NGNG自民党と共産党の間にいる民主党みたいだな（藁
誰が敵なのか分からん
0524357
NGNG自分が断言出来ることは断言して、会話の進行を加速したいだけ。
もし、自分の断言が間違ってたことが分かったら、それはそれで収穫だよ。
0525357
NGNGそれをﾏﾀｰｸ理解しないスレが続いて、このスレ終焉した感じ。
0526デフォルトの名無しさん
NGNG本屋で一度も見掛けたこと無いのかを教えてくれ。
「憂鬱なプログラマのためのオブジェクト指向なんちゃら」
え？絶版？
0527デフォルトの名無しさん
NGNG0529508
NGNGプロトタイプベースのオブジェクト指向言語のことですね。
オブジェクト指向言語万歳
0530デフォルトの名無しさん
NGNG多重継承は言語がちゃんと設計されていれば有効です。
Javaふうに説明すると
class B extends A, A, A {} が
class B extends A {}
と同じになる必要があります。
例をあげると
class A { ... } extends Object
class B { ... } extends Object
class C extends A, B {}
AとBを通じて継承された2つのObjectは1つになる必要があります。
他にも名前の衝突とかオーバーライドとかあるけど省略。
0531デフォルトの名無しさん
NGNGCでは特にオーバーライドしない時、
C.equals()の動作をどのように規定するのでしょうか？
オーバーライドされていなければコンパイルエラーとかに
すればいいのかな？
0532デフォルトの名無しさん
NGNGC++の場合、これはコンパイルエラーになります。
（呼び出し先が曖昧と言われる）
operator=をclass Cでも使いたければ、
class Cがきちんとoperator=を用意しないといけません。
ところでJavaの場合でインターフェイスのメソッド名が重複したとき（参照）はどうする？
class CFile {
public:
bool Open(string &filename);
};
class CWindow {
public:
bool Open(HWnd handle);
};
class CFileWindow : public CFile, CWindow {
private:
bool Open(string &filename); //使用禁止
bool Open(HWnd handle); //使用禁止
public:
bool Open(HWnd handle, string &filename) {
CFile::Open(filename);
CWindow::Open(handle);
}
};
0533532
NGNG0534デフォルトの名無しさん
NGNGjavaでは、メソッド名だけではなく、パラメータまで含めてシグナチャなので
例のコードではインターフェイスのメソッド名の衝突にはならない。
また、同じシグナチャのメソッドを持つ複数のインターフェイスを実装しても、
メソッドはひとつでいい、というかひとつしか作れない。それで問題も起きない。
例
interface A{
void say(String mes);
}
interface B{
void say(String hello);
}
class C implements A, B{
public void say(String hoge){
System.out.println(hoge);
}
}
0536530
NGNGclass A extends Object { ... }
class B extends Object { ... }
class C extends A, B {}
AとBを通じて継承された2つのObjectは1つになる必要があります。
0537526
NGNG広島。たまに大阪に出るから良い店教えてちょんまげ。
梅田のジュンク堂、紀伊国屋、旭屋やらまわったが見つけられなかった。
探し方ヘタなのかな・・・？
0538デフォルトの名無しさん
NGNG俺は技術書のために本屋をはしごするのに疲れた。
http://www.amazon.co.jp
2Chで評判の良い本はバシバシ買う。
0539526
NGNGesBooksに頼んだのが運の尽きかしらんけど、
発注して5日後に本社にしか在庫ねぇってメール来て、
入荷したら又メールするって来たんだわ。
で、それからさらに5日経過してるが、未だにとどかん。
計10日も待たされる・・・。
esBooks
amazone
クロネコブックサービス
紀伊国屋
どこが一番在庫量豊富なんだろう
0540530
NGNGEiffelふうに書くと
class A {
public x() { ... }
}
class B extends A {
public x() { ... }
}
class C extends A {
public x() { ... }
}
class D extends B rename x as x1
select x1
end
C rename x as x2
end
{}
D d = new D() ;
A a = d ; a. x() ; // x1がよばれる
B b = d ; b. x() ; // x1がよばれる
C c = d ; c. x() ; // x2がよばれる
0541デフォルトの名無しさん
NGNGＪａｖａにはそれが出来ない宿命があるから改良する度にクラスがごっそり増える。藁
0542デフォルトの名無しさん
NGNG意味不明
0543デフォ
NGNGいろいろボタンはついてるけど、説明書読まなきゃ何の事か分からない多機能リモコン
みたいなもんに感じる
0544354
NGNGそれは言語仕様について？ それともライブラリについて？
後者ならば確かに情報が多いが故に探すのが大変という、ネット社会にも
通じる議論になるが、過去の言語なら自作する必要のあったモノを利用できるのは
便利なはず。ただ、よく使うクラスをヘルプで特記してくれりゃ、とは思うが。
0545デフォルトの名無しさん
NGNGという分岐点があるように思うな。
0546デフォルトの名無しさん
NGNG技術書ならcbook24が速い。即日発送だし。在庫もすぐ確認できる。
bk1も関東なら(?)today便で翌日には届くが、予約も併用しないと送料がかかる。
amazonは配送は上記に比べて遅いが注文後のキャンセルがwebだけでできるので安心。
憂鬱な～はかなりあちこちの本屋で売ってるな。
「憂鬱なプログラマのための」は小さく脇にあるだけで
オブジェクト指向～がでかいタイトル。
0547357
NGNG>いろいろボタンはついてるけど、説明書読まなきゃ何の事か分からない多機能リモコン
これは、全くの勘違いですね。
関数ライブラリというものが、呼び出し手順仕様書を読まなきゃ何の事か分からない多機能リモコン。
例えば、一万近くあるWin32API。殆どがサンプルコードを読まなければ使えない。
oopではWin32APIのコールセットがメソッドに纏めてあるので、呼び出し手順を意識しない。
0548デフォルトの名無しさん
NGNGWin32APIはボタンが1万個ある単純なリモコンだと思うぞ。
OOライブラリはボタンの数を減らそうとして結果的に「多機能リモコン」
になってしまう。
関数は呼び出して返り値を使うことしか考えなくていいけど、クラスはいろいろと
考えなくてはならないことが多い。
#ちなみにだからOOはだめといってるわけじゃない
0549357
NGNG>Win32APIはボタンが1万個ある単純なリモコンだと思うぞ。
リモコンのボタン押す順番間違えたらエラーになるよ。
>関数は呼び出して返り値を使うことしか考えなくていいけど、クラスはいろいろと
意味不明。メソッド名で処理が分かるじゃない。
関数は一個じゃなくて複数あるものを、正しい順番で呼びださないと。
0550マジアドバイス
NGNG0552デフォルトの名無しさん
NGNGあなたは病気です。
病名はNIHシンドローム。
http://www2u.biglobe.ne.jp/~kikucyt/e/ABC_Data/nihsyn.html
0553デフォルトの名無しさん
NGNG>リモコンのボタン押す順番間違えたらエラーになるよ。
でも押すだけだから「単純」だろ？使いやすいといった覚えはないぞ
>>関数は呼び出して返り値を使うことしか考えなくていいけど、クラスはいろいろと
>意味不明。メソッド名で処理が分かるじゃない。
>関数は一個じゃなくて複数あるものを、正しい順番で呼びださないと
よくわからん。正しい順番で呼ぶ関数を新たに作ればいいんじゃない？
それともコンストラクタとデストラクタが自動的に呼ばれるということ
いってるのか？
それが有効なのは同意するが、ゆえに高機能で使いこなすのが大変な
(そしてもちろん使いこなせれば役に立つ)高機能リモコンなのでは？
0554デフォルトの名無しさん
NGNG0555デフォルトの名無しさん
NGNG単純 ＝ 簡単、 高機能 ＝ 使いこなすのが大変
という図式は、逆だよね。
同じことをするのに、
単純 ＝ 手間がかかる、 高機能 ＝ 簡単
が普通だよね。
0556デフォルトの名無しさん
NGNG人によると思うよ
高機能なものは俺に取っては簡単ではない
俺は記憶力が他人に比べて異常に悪い（一つプロジェクトが終ると
前の事聞かれても全く覚えてないほどだ）だから
単純で機能がはっきりわかるものを組み合わせられる仕掛けならいいけどさ
BASICのように MID/LEFT/RIGHTと高機能な関数があるよりは
while(*d++=*s++); と基本タームを組み合わせる方が楽だ
0557デフォルトの名無しさん
NGNG関数によるアプローチが招く複雑さについてはメイヤーさんの本でも議論されとるぞい。
0558デフォルトの名無しさん
NGNGあんたはもうプログラマを辞めたほうが良いよ。
時代の変化についていけない哀れなC使いにしかみえん。
0559デフォルトの名無しさん
NGNGオブジェクトはボタンがたくさんついているリモコンじゃないからな。
そもそも関数郡が単純なリモコンというたとえに無理がある。
オブジェクト＝高機能でもない。
関数ライブラリこそ高機能なひとつの機械。
クラスライブラリは単機能な機械の集合。
関数ライブラリを使いこなすにはかなりの習熟が必要。
クラスライブラリもある程度の習熟が必要だけど、
関数の数よりクラスの数のほうが少ないから、
探し出しやすい。
またクラスを見つけた後は、機能がシンプルだから
操作方法が推定しやすい。
もちろん高機能なクラスが混じっていたら使いづらくなる
ということは言うまでも無いが、
関数ライブラリは、個々の関数は単機能でも、
全体としてかなり高機能になってしまう。
だいたいクラスライブラリでも関数という単位はあるしね。
0560559
NGNGオブジェクト指向に都合がいいことを言っていると思うかい？
いやいや、オブジェクト指向とは突然湧き出てきたものじゃない。
「よいプログラム設計を分析して得られた結果」がオブジェクト指向なんだよ。
むやみやたらに作ってもなかなか上手い設計にはならないし、
全てのプログラマーが経験で学ぶというのも限界がある。
だから過去の成功例や失敗例を分析して、
誰でも成功できるように導いてやるほうがいい。
オブジェクト指向が完全な答えかどうかはわからないけれど、
一つだけ確実に言えることは、オブジェクト指向を学んで損することは何もないということ。
だからよけいなアレルギーは捨てて欲しいなぁ。
0561559
NGNG難しい概念だから、良くない概念だと思ってしまいがちだし、
それを振り回している奴らは鼻持ちならないように見えるかもしれない。
しかしオブジェクト指向はプログラミングの方法論ではなく、
プログラム設計の方法論なのよ。（※OOPはOOの実現方法でしかない）
プログラミングができるようになっても、
うまく設計することがいかに難しいかは、
業務でプログラムしている人なら知っているでしょう。
それなら方法論がある程度難解になるのは
仕方がないということを悟るべき。
幸い、オブジェクト指向は、これまで生まれてきた
設計手法に比べて単純明快。
オブジェクトに仕事を委託しよう、
オブジェクトが作業する手段として関数と変数を所有させよう、
オブジェクトは契約を守ろう、というだけのもの。
（正確な表現じゃないけど、解りやすいでしょ？）
0562デフォルトの名無しさん
NGNGそして数百ページに及ぶ契約書を読まないと使えないのね。ｗ
0563デフォルトの名無しさん
NGNG＞関数の数よりクラスの数のほうが少ないから、
なにｺﾚ?
0564デフォルトの名無しさん
NGNG反ＯＯ派の人も、カプセル化の意義について、疑問を感じる人は少ないと思うけど。
焦点はやはり、上書と多態を得るための代償（継承）についてでしょ。
ＯＯ派の人も、そろそろ理解できたと思うけど。
0565564
NGNG例が悪いよ。
0566デフォルトの名無しさん
NGNG0567デフォルトの名無しさん
NGNGあなたが正解！！
オブジェクト指向の生産性は最悪なわけよ。
だから小さなクラスライブラリと強力な関数なの
0568564
NGNG0569デフォルトの名無しさん
NGNGさっさと理解しておかないと職をなくすよ。
0570デフォルトの名無しさん
NGNG0571357
NGNGwinapiを使ってたころは、リファレンスヘルプを印刷しまくってコーディングし、
エラーや動作しない場合は、サンプルコードを沢山探し印刷して理解した。
クラスライブラリでは、該当クラス宣言した後は、メソッド、プロパティ一覧されるから、
適当な呼び出しで動作する。その動作でどんなapiが呼び出されたのか知りたい場合、
そのプログラムをデバッガで中に入るだけでapiコールが全て見えるため数分で作業が終る。
つまり クラスライブラリ ＞ リファレンス＋サンプルコード
0572357
NGNG0573デフォルトの名無しさん
NGNGJavaの事を言ったつもりだった。
MFC＞＞＞＞＞＞JAVA
0574357
NGNG>なにｺﾚ?
win32apiは一万を超えているが、クラスはその１００分の１じゃないかな。
>焦点はやはり、上書と多態を得るための代償（継承）についてでしょ。
>ＯＯ派の人も、そろそろ理解できたと思うけど。
？
0575デフォルトの名無しさん
NGNG訳判らんメソッドが大量に画面埋め尽くすだけだと思われ。
0576デフォルトの名無しさん
NGNG0577デフォルトの名無しさん
NGNGapiをクラスでラップされると、環境毎（処理系､言語毎）
に異なるクラスライブラリを把握しないといけない。
素直にDLLにアクセスでき、関数が見えていてくれた方が
良い場合が多い。もしくはCOMの様なインタフェース。
(COMの実装が良いとは言わない)
apiからは離れとけ>357
0578デフォルトの名無しさん
NGNG厨房OOPerの氾濫が深刻な問題なのである。
0579デフォルトの名無しさん
NGNGOOへの理解度のギャップを埋め合わせるためのうまいやり方ないかなあ。
0580デフォルトの名無しさん
NGNGＣ＋＋で全部クラスにする奴は逝って良し。
全部クラスにしないと使えないＯＯＰな死ね！
｜｜｜｜｜ ＿＿＿＿＿＿＿＿＿＿＿＿＿_
｜｜｜｜｜ ／＿＿＿＿＿＿＿＿＿＿＿＿＿／|
｜｜｜｜｜ ＿＿＿＿＿＿＿＿＿＿＿ ｜ ｜
｜｜｜｜｜ | ｜ ｜
｜｜ (* ﾟДﾟ)さん 投稿日：‐‐‐ | | ｜
Λ Λ | |氏ね！！ | | |
/ ＿＿/ ｜｜クソ言語 が！！ | ｜ ｜
/uｕ ||||||||||||＼ ｜｜クソスレ立てんな！ | | ｜
｜∪u U | ｜｜逝ってよし！！カス！！ ｜｜ ｜
＼＿ｕ＿＿_ ／ ｜｜＿＿＿＿＿＿＿＿＿＿＿| |／|
／ ＼ ｜＿＿＿＿＿＿＿＿＿＿＿＿_／ ｜
/ ＼｜ Ａ：＝＝＝ ｜ ／|＿_＿
｜ ＼＿＿＿＿＿Ｂ：＝＝＝ ＿＿ |／ ｜ ／）
｜ |＼ ＼①②③④⑤⑥⑦⑧⑨ー ／ ／ ／／
｜ ｜ ＼ｕＵ ））□□□□□□□ ／ ／ ／／
| ＼ ）））＿＿＿＿＿＿＿＿／／ ／／
| ＼ ――――――――― ／／
――――――――――――
0581564
NGNGＯＯ派の人も、ＯＯの欠点を指摘されると、相手の理解不足にすり替えるのはやめたら？
0582デフォルトの名無しさん
NGNG同意。
0583デフォルトの名無しさん
NGNG0584デフォルトの名無しさん
NGNGまあ、それでもいいけど
0585デフォルトの名無しさん
NGNG0586564
NGNG全否定というのは無理だと思う。
反ＯＯ派の人は、まずこれを認識すべきでは？
ＯＯは方法論の最終形態ではないのだから、
欠点を全て否定するのは無理だと思う。
ＯＯ派の人は、まずこれを認識すべきでは？
0587デフォルトの名無しさん
NGNGＯＯ派／反ＯＯ派って何？
きみ一人で言ってない？
0588デフォルトの名無しさん
NGNGクなった気になれるでしょ。そういう人間には、何いってもムダ。
0589564
NGNG～～派というのは、正誤に関わらず、自分の気に入った結論へ、
話を持って行こうとする人のことです。
そういう人が、かなりいると感じたので。
0590デフォルトの名無しさん
NGNGつまり、あんたの事だな（ｗ
0591564
NGNGあなたの望みは、くだらない煽り合戦のようですね。
0592564
NGNG0593デフォルトの名無しさん
NGNG両陣営とも、聞く耳なんて持ってないよ
今までのスレみれば、判りそうなもんだが
0594デフォルトの名無しさん
NGNG高水準言語の常識、いまじゃあピンからキリまで使っている。
いまだにＯＯうんぬん言ってたら時代遅れになっちゃうぞ。
0595デフォルトの名無しさん
NGNGこのスレ自体がナンセンスという事かな♪
0596デフォルトの名無しさん
NGNG殆どはOOPでクラス使って手続き型組んでるのね。w
0597デフォルトの名無しさん
NGNGOOPで関数型で人工知能エージェント型じゃなくて？
0598デフォルトの名無しさん
NGNG0599デフォルトの名無しさん
NGNG0600デフォルトの名無しさん
NGNGRuby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！
Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！
Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！
Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！
Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！
Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！
Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！
Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！
Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！Ruby最高！
0601デフォルトの名無しさん
NGNG>そして数百ページに及ぶ契約書を読まないと使えないのね。ｗ
おまえはDelphiのコンポーネントを使ったことがあるのかと問いたい。
問い詰めたい。小一時間問い詰めたい。
WindowsAPIのリファレンスを読むのと比較にならないくらい楽なのちゃうんかと。
>>594
激しく同意。
0602Delギコ
NGNG(,,ﾟ∀ﾟ) ＜ 問い詰めてヨシ
| つ[|lllll］). ＼＿＿＿＿＿＿＿＿＿
～| |
∪∪
∧ ∧ ／
（ ﾟДﾟ）＜ でも、疑問があるから聞いてよい？
|つ つ ＼
～| |
∪ ∪
MyClassというクラスがあってそれが実用的なGUI部品だとしよう
で、A,B,C,Dという4つの別々の機能があったとして
それをMyClassに組み込みたい場合
どうやって実装すると綺麗？
派生してMyClassExとしてA,B,C,Dをすべて詰め合わせパックにしたらいいの？
ここで全く別のアーキテクトから派生している
MyClassChildという実用的なGUI部品があったとして
その部品にA,B,C,Dの別々の機能を付加させたい場合も
考慮して設計を教えてくれるとありがたいのニャー
0603デフォルトの名無しさん
NGNGVCLが オブジェクト指向だという結論なら オブジェクト指向マンセー
>>602
MyClassをMyClassChildは継承してるの？
継承してるなら MyClass+A+B+C+D をメンバーに持つクラスを作ればいいし
継承してないなら、MyClassとMyClassChildにインターフェースを被せて
インターフェイスメンバーとして持たせた新クラスを作ったら？
0604デフォルトの名無しさん
NGNG純粋オブジェクト志向派みたいなのが
そういう場合は分析・設計段階が悪いみたいにのたまうんだよね >>602
プログラミング技術としては フックで簡単に解決出来るならフックでやっつければいいと思うんだけどね
0605Delギコ
NGNG(,, ﾟДﾟ) =3 ＜ 今日は寒いからｺｺｱ飲んだ
/つ日
～（＿ __)
VCLはクラスライブラなのでオブジェ指向っす。
オブジェ指向じゃないわけがないっす。
＞MyClassをMyClassChildは継承してるの？
名前の通りしてます。
イターフェースで実装すると
ソースが分離しませんか？
ソースコピペでインターフェース実装すればいいけど
それはソース分離を引き起こすという
ジレンマがあるような気がするのですが、、、勘違いかなあ。
いい方法論ってあるのっすか？
0606Delギコ
NGNG＠' ― (,,ﾟДﾟ)つ ＜ >>604 そのとーり。禿げ同ヨ
し― ∪ ＼＿＿＿＿＿＿＿＿＿＿＿
設計が悪いとかノタマーないで欲しい。>>純オブ志派
フック・・・安全にフックorフック解除する仕組みがVCLに欲しい
0607603
NGNGMyClassで使いそうな公開部を全部 MyClassExにコピーして
その実装は全部 メンバーにした MyClassを呼ぶだけにしとけば
外からは MyClassExは MyClassとそっくりに見える訳ですよね？
（ただ is as ではハネラレルけど）
これを使えばって事ですよ
0608Delギコ
NGNG| ∪ |
| ～
|∧ ∧ ／￣￣￣￣￣￣￣￣
( ,,ﾟДﾟ)つ ＜ ｺﾉｻｲだからガンガン質問してやれ
Ｕ ＼＿＿＿＿＿＿＿＿
ﾏﾀﾁｶﾞｳ ｼﾂﾓｿ ﾃﾞﾌ、
継承継承をガンガン行なっていくと
SubClassの末端では
メソッドの山ができるはずですが
そういう所に問題はないのでしょうか？
継承すればするほど
永遠にpublicメソッドが増えていって収集つかなくなると思うのです。
デザパタ読んでいると、場合によってこういう実装するときがあるそうな。
クラス A
メソッド 逝ってヨシ
メソッド 似てヨシ
メソッド 妬いてヨシ
メソッド 句ってヨシ
クラスB
メソッド 逝ってヨシ {(逝ってヨシの実装) 例外発生}
クラスＢから逝ってヨシメソッドを呼ぶと
呼ばれたくないから冷害を発生させるだけのメソッド。
こんなのを実装する意味があるですか？
項いう事を行なわなければならないのは
既存のＯＯ言語の問題点ではないかと思っているのですが
どう思います？
0609デフォルトの名無しさん
NGNGクラスB
メソッド 逝ってヨシ ; アボーン;
で無視されるようになっていればいいかも
（アボーンは継承先でも有効だけど復活も可能にする）
いくらなんでも例外発生を実装するのはダサい
0610デフォルトの名無しさん
NGNGMyClassにABCDメソッドを追加すれば良い。既に継承しているのなら、考える余地
がないと思うが。何が言いたいのかわからん。
0611デフォルトの名無しさん
NGNG他人のライブラリでソース無い場合は？
0612デフォルトの名無しさん
NGNG0613デフォルトの名無しさん
NGNG例えば、
1 メソッドA,B,C,Dを実装したクラスABCDを作る。
2 MyClassのpublicメソッドとA,B,C,DをもつインターフェイスMyClassAndABCD
をつくる。
3 MyClassの子供MyClassExをMyClassAndABCDをインプリメントして作る。
4 MyClassExには、MyClassAndABCDのオブジェクトを持たせて、メソッドA,B,C,D
はすべてそのオブジェクトのメソッド呼び出しへの委譲とする。
5 MyClassChildはソースがいじれるなら、4と同じ作業をする。だめならMyClassChildEx
を造って4と同じ作業をする。
6 以後、MyClassExとMyClassChild(またはMyClassChildEx)は、MyClassAndABCDとして
利用できる。
なんてどうかな。
0614Delギコ
NGNG>>602をみておいてね
∧ ∧ ／￣
（∩(,,ﾟДﾟ) ＜ A,B,C,Dは。それぞれ別機能
⊂,,＿_つつ. ＼＿ A,B,C,Dそれぞれに内部関数が複数あったり
メッセージ横取りをいろいろする必要があるとしよう。
出来ることなら構造化の概念から
Aを実装したMyClassA
Bを実装したMyClassB
Cを実装したMyClassC
Dを実装したMyClassD
を作りたいのだが、
ABを組み合わせたMyClassAB
ACを組み合わせたMyClassAC
BDを...MyClassBD
全部の組み合わせ
これも使いたい場合がある。
各々の実装を考えると気が狂うからABCDをすべて実装した
MyClassABCD=MyClassExと名前付けた
ものを実装するというイメージをしてくだされ。
(すでにこのあたりからOO的継承の問題点が露呈しまくり)
このMyClassExは普段プログラムで使えるﾍﾞﾝﾘ部品として
使いつづけるとしましょう。
で、それを
MyClassから更に別の機能をもたせた派生クラスMyChildClass
をもってきたとして（MyChildClassもﾍﾞﾝﾘ部品として使いつづける)
MｙChildClassABCDを作る時には
どうしたらいいのか？
ってｺﾄを聞きたい。
MyClassExのソースをコピペして
MyClildClassExを作るのは簡単ですがバカバカしいでしょ。
今時ソースコピペなんてさ。
0615Delギコ
NGNGデコレーションでしたっけ。
∧∧ ／￣￣￣￣￣￣￣￣￣￣￣
(,,ﾟДﾟ) ＜ ただ、既存のクラスライブラリ(VCL)を使ってると
ヽ/つ且~~ ＼＿無理なんですよね・・・・・・
（__ _）
ﾑｽﾞｶｼｲ ﾓﾝﾀﾞｲ
ここで「設計が悪い」なんて、
VCLより使いやすいクラスライブラリを作れる自信がないなら
言わないで欲しいニャ。
>>609さん。
∧∧ ／￣ですよねー。
(,,ﾟДﾟ) ＜ 継承先クラスが継承元クラスのすべての
ヽ/つ且~~ ＼＿メソドを実装する仕組み。が
（__ _） なぜ当然のものとして受け入れられているのか・・・ﾈｺﾆｬわからない
ただ、C++だと
クラスB
メソッド 逝ってヨシ ; アボーン;
の"アボーン"をマクロで例外発生するように
書いておけといわれるかもしれないけど、
言語レベルでその仕組みを(当然)実装するべきなんじゃないかと。
0616Delギコ
NGNG∧ ∧ ／￣ ありがとございます。
（∩(,,ﾟДﾟ) ＜ がんばって考えてみます。
⊂,,＿_つつ. ＼＿
【ｲﾝﾌﾟﾘﾒﾝﾄして作る】の意味が イマ３つ くらいわからないっす。
0617デフォルトの名無しさん
NGNG607じゃないけど、
>継承先クラスが継承元クラスのすべてのメソドを実装する仕組み。が
>なぜ当然のものとして受け入れられているのか・・・ﾈｺﾆｬわからない
って言っても、もし選択的に継承できたら、ポリモーフィズムができな
いんじゃないの？
0618613
NGNGごめん、Javaです。
インプリメント＝実装
インプリメントしてつくる、は単に、インプリメントする、と言うべき
でした。
0619Delギコ
NGNG> VCLより使いやすいクラスライブラリを作れる自信がないなら
> 言わないで欲しいニャ。
ﾁﾄｲｲｽｷﾞﾀ
∧ ∧ ／￣
（∩(,,ﾟДﾟ) ＜ 「設計が悪い」っていう言葉で
⊂,,＿_つつ. ＼＿思考停止しないで欲しいってｺﾄです。
どうやって設計しておくべきか。
どうやって改善するべきかを、考えてくださると、サイコーっす。
みなさんが知っているOO言語や
既存のクラスライブラリなどで
こういうことを解決されているものがあるのでしたら、
∧ ∧
(,,ﾟДﾟ) 教えてチョーダイ にゃー
/ つつ
⊂ ﾉ
／（/″
LISPで実行時にソースを読ませるｺﾄができるなら
簡単かもしれない...でもLISPは全く氏らん
0620Delギコ
NGNG(ﾟДﾟ,,) だって例外発生するだけならメソッドがないのといっしょじゃーん
⊂ ⊂)
⊂ ﾉ そのメソドについてはポリモする必要がない場合だと
／（/″ 考えておくんなまし。(どこの方言？)
0621デフォルトの名無しさん
NGNGC++/Java/ObjectPascal といった言語に拘らなければ方法はあるけどねぇ。
こういう言語で書かれた既存の資産があるという状況じゃ難しいわな。
0622610
NGNG> 他人のライブラリでソース無い場合は？
だったらMyClassなんて名前つけるなよ。付き合いきれん。
0623Delギコ
NGNGそれでもYOいから教えて教えて>>621
∧ ∧
(,,ﾟДﾟ) 教えてくんないとダダこねるぞ(ｳｿ)
/ つつ
⊂ ﾉ smalltalkやO-Cなどでは実現できるのかしら？
／（/″
∧_∧ <<しーちゃん
（*ﾟーﾟ）
C#でもいいです。
JavaかDelPascalかC#が何らかそういう進化をするとうれしい。
(C++の進化には気体しませんが)
0625617
NGNG前提として、なぜ子クラスで、親クラスにあるメソッドをなくしたいのか、という
点だけど、呼ばれるとまずいから、だよね。
であれば、呼ばれたら例外を投げるということで問題ないと思うけど。
コンパイル時にそれをチェックしたいということなら、javaの場合は、その
メソッド以外のpublicメソッドだけを含んだinterfaceを定義して、子クラス
はそれをインプリメントして、以後、子クラスのオブジェクトはそのinterface
の型として扱えばいいと思うけどね。
Delphiではどうやるのかな？
0626ななーし
NGNGデコレータパターソでそういうのはやるのでは？
ガイシュツか。
じゃ別の方法，
１）a,b,c,dの機能を実装したクラスA,B,C,Dをそれぞれ作る。
２）クラスA,B,C,Dのオブジェクトをメンバーに持ち委譲するための
メソッドを持つクラスmixA,mixB,mixC,mixDを作る。
３）MyClassとmixA～mixDを必要なだけ多重継承した新しいクラスMyClassExをつくる。
ってのは？
え？多重継承出来ないって？
0627デフォルトの名無しさん
NGNGというか A,B,C,Dにとって必要な操作 IMyInterface を定義しといて
MyClass と MyClildClass に被せて
A,B,C,Dは独立なインスタンスでいいんじゃないの？
0628Delギコ
NGNG＞であれば、呼ばれたら例外を投げるということで問題ないと思うけど。
∧∧l||l そっすか、ﾒｿｯﾄﾞ隠蔽の必要はないと・・・
/⌒ヽ) ﾄﾎﾎ
～（＿__）
''" ""''"" "''
>そのメソッド以外のpublicメソッドだけを含んだinterfaceを定義して、子クラス
>はそれをインプリメントして、以後、子クラスのオブジェクトはそのinterface
>の型として扱えばいいと思うけどね。
！
∧ ∧ ／￣￣￣￣￣￣￣￣￣￣
(,,ﾟДﾟ) ＜ なるほど！(ざ わうるど)
./ | ＼＿＿＿＿＿＿＿＿＿＿
～（＿__/
ﾃﾞ…ﾃﾞﾙﾌｨ でもできるかな…
>>626さん
>デコレータパターソでそういうのはやるのでは？
概念的に全てのメソドをデコレすれば
GUI部品でもｵﾅｼﾞｺﾄは出来そうなのですが
VCLのGUIクラスでは....できるのかな,,,なんか無理そうです。
＞え？多重継承出来ないって？
ガビーン・・・(ﾟДﾟ;)ツョック
>>627さん
そうですそうです。そうできればいいです。
＞多重継承の代わりにインターフェースでやればいいでしょ
でもｲﾝﾀﾌｪｽは毎度毎度同じ実装しなきゃいけない気が…
ｿｰｽｺﾋﾟﾍﾟ???
0629627
NGNG0630626
NGNGそのオブジェクトに委譲するようにすれば委譲のためのコードを書くだけですむから，
（本来の）実装コードを書く必要はないと思うけど？
0631デフォルトの名無しさん
NGNGスタティックバインドを前提にしてる言語に
ダイナミックバインドを付加するために
未定義メソッドが呼ばれたらそれ用のイベントを発生させて
そいつを呼び出された側のインスタンスで実装できるってのどうだろう？
こんなの。
main(){
(new Hoge()).undefinedMethod( x, y) ;
// Hoge には undefinedMethod は定義されていないとする。
// この呼び出しは Hoge::onMisbinding を呼び出す。
}
class Hoge{
handler void onMisbinding( CallContext context){
// context には呼び出されたメソッドの名前、
// 呼び出しの引数、期待される戻り値の型などが含まれる。
}
} ;
これとリフレクションを組み合わせれば、委譲の実装がすげー楽になるような。
あ、もちろん、そういう風な言語が作れないかな、って話ね。
0632627
NGNGtype
IMyClassCtl = interface (IUnknown)
function Execute: Boolean;
// とか MyClassの制御に 必要な全部のメソッドを定義
end;
後は
TMyClass = class(TOpenDialog,IMyClassCtl) end;
TMyChildClass = class(TSaveDialog,IMyClassCtl) end;
みたいに１行書くだけ
A,B,C,Dのメンバーに
var My: IMyClassCtl;
を持たせて
My:=TMyClass.Create(nil);
とかでメンバー設定すればいいわけで
A,B,C,DがMyClassを使う為にMyClass側のメソッドの置換（継承）が必要なら、
継承が必要な部分をイベントにして
A,B,C,Dの全てが使えるにようにしてやればいいんじゃないの？
0633627
NGNGOnMessageA/OnMessageB/OnMessageC と３つのプロパティを用意してやるって事ね
ただ、TMyClassを設計時に使いたいとか言い出したらメンドクサイ事になるけど
0634Delギコ
NGNG(,,ﾟДﾟ) ＜ >>632-633すばらC.
| つつヾ ＼＿＿＿＿＿＿＿
～| | ﾊﾟﾁﾊﾟﾁ
∪∪ ｱﾘｶﾞﾄｰ
実装しないとわからない所が出てきたのでｶﾞﾝﾊﾞﾃみます。
06351
NGNG0636デフォルトの名無しさん
NGNG>どうやって設計しておくべきか。
>どうやって改善するべきかを、考えてくださると、サイコーっす。
「この場合はこうだ」という明確な答えはない。
でも改善法なら教えられるぞ。
まず一つが状態遷移。継承がどうこう言う前に、オブジェクトがどのような状態をとるのか、
しっかり把握しないといけない。オブジェクトには状態がある。
内外から発生するイベントによって状態が変化するというモデルがある。
それをふまえた上でクラスを設計できるようになってないでしょ？
これについては憂鬱本が詳しいので参照して欲しい。
次に勉強すべきはデザインパターン。
今回のギコの例で言えば、Decorator、Facade、Mediator、Strategyなどのパターンが
応用できると思われるし、他のパターンも流用できるかもしれない。
どのパターンが適切かは状況にもよるし、設計者の好みにも依存するから、
ギコ自身が選択しなければならない。
とにかく新しいパターンを生み出す前に、過去のパターンをよく研究した方がいい。
そしてUML。設計の善し悪しを判断する最高の方法は現時点ではUMLを使うことだと思う。
目に見える形になることで頭の中が整理されるし、
オブジェクト同士の関連線を減らすという機械的な作業で設計を改善できるところがいい。
さらに他人でもクラスの設計が容易に把握できるようになり、
一人の考えではなく、大勢の意見を採り入れた設計ができるようになる。
言い換えれば、一人でコードをこねくり回しても限界があるということ。
0637デフォルトの名無しさん
NGNGたとえばStateパターンで実装するときに、当然それぞれのStateの
Concrete Classは同じインタフェースを持つわけだけど、状態に
よっては実行できないメソッドも出てくる。
元々のコードが
void foo::bar() {
if(state == xxx) 例外;
処理;
}
だとすると、その状態を抜き出したConcrete Classのメソッドは、
void fooStateA::bar() {
例外;
}
になると思う。
0638Delギコ
NGNG～''~（,,ﾟДﾟ） ＜ ありがとうございます。>>636-637
UU'UU ＼＿＿＿＿＿＿＿＿
ﾃﾞｻﾞﾊﾟﾀ はJava結城本で勉強中です.これ面白くてたまりません。
憂うつ本も1度は読んだのですが、身についてないのかな。
ｻｲｷﾝはDelphiでVCLの継承をして
機能追加を計ることが多いのですが
それで、中々うまく出来ない部分があって大変なのです。
…つまり、MyClassは素のクラスじゃなくてVCL継承クラスとして
想定していたのですが…
ﾃﾞｻﾞﾊﾟﾀの話も読んでいてわかるのですが
Java結城本に出ているような
簡単なものならOKですが
どうしても、GUI部品クラス(VCLでいうとTWinControl以下)になると
理想どおりには扱えなくて応用がつらいものがあります。
世間のクラスライブラリでGUIで
しっかりとﾃﾞｻﾞﾊﾟﾀ物を扱えるものってあるのでしょうか。
例えばJBuilderしか使った事ないのですが
JavaでTextField(JTextFieldでしたっけ？)を
HasAしてまるでTextFieldのように扱えるのでしょうか。
DelphiRADの設計時までを想定しているから
一人で落とし穴に落ちているだけかな…
0639デフォルトの名無しさん
NGNG0640亀レススマソ
NGNGAdapterパターン？
0641617
NGNG>JavaでTextField(JTextFieldでしたっけ？)を
>HasAしてまるでTextFieldのように扱えるのでしょうか
正直、これは大変すぎると思う。やったことないけど。やはり、この場合は、
素直に継承して必要な機能は付け足すか、または、継承せずとも、リスナなど
を工夫して、必要な機能を付加するなどのアプローチでは。
デザパタのDecoratorパターンでも、componentとdecoratorが共通して
継承するComponentクラスは軽くなければならないと言われているけれど、
javaのJTextFieldの継承しているJComponentクラスは、決して軽くない
からね。
0642デフォルトの名無しさん
NGNG知ってると思うけど、VCLはCompositeパターンだぞ。
無理に継承しなくていいんじゃないのか？
単にhasしておけばいいのでは。
ていうかこういう場合はC++の出番（Eiffelでもいいけど）。
TMyForm<TButton, TPanel> *p = new TMyForm<TButton, TPanel>(this);
C++Builderでは、このコード動くよ、マジで。
まぁこれがObjectPascalの限界ってことかな。
0643642
NGNGテンプレートでスーパークラスを抽象化してみると……。
template<class T> class MyForm : public TForm, public T
[C++ エラー] Unit1.cpp(18): E2278 VCL クラスでは複数の基本クラスはサポートされない
C++BuilderでもVCLだけは多重継承できないように制限されているのか…。
ObjectPascalは多重継承ができないから、
Javaのようにインターフェイスと実装を分けなければならなかったのに、
VCLは実装継承でライブラリのツリーを作ってしまった。
ここに問題があるのでは？
たぶんDelphiが元からC++だったら問題はなかったと思うよ。
だとするとやはりDecoratorパターンを使って誤魔化すしかないか。
多重継承できないんだからしょうがないよ。
0644デフォルトの名無しさん
NGNGDelｳｻﾞ&ﾀﾞｻﾞ
せいぜい低レベルＯＯＰやってろ お前にはその程度がお似合いだよ
0645デフォルトの名無しさん
NGNG何も継承してない「サブルーチン・ライブラリクラス」作って
何もかも詰め込んで委譲で実装。終了だな。
0646Delギコ
NGNG| ∪ | ｺﾝﾊﾞﾝﾊ ｱﾒ ﾀﾞｯﾃヨ
| ～
| ∧ ∧ ／￣￣￣￣￣￣￣￣
|( ,,ﾟДﾟ) ＜ おはようSUN
Ｕ Ｕ ＼＿＿＿＿＿＿＿＿
>>641
>デザパタのDecoratorパターンでも、componentとdecoratorが共通して
>継承するComponentクラスは軽くなければならないと言われているけれど
なるほどです。
DelphiのVCLも似たようなﾓﾝﾀﾞｲを抱えていて(本当かな)
TEditをHasAしてTEditのようには今ひとつ自由に扱えません(ﾀﾌﾞﾝ)
とくにRADとしての設計時の動作を考えると無理っぽいです。
(DelphiRADは設計時にもインスタンスが生成されてるから)
逆に実行時の事だけ考えたらTEditをHasAしてもなんとかなりそうだけど
>>642
>知ってると思うけど、VCLはCompositeパターンだぞ。
え？どのあたりがですか？
開発者にはあまり見えなくなっているのですかね。
>>643
泣きますか・・・
もうすこし、Interfaceの理解を深めてみます。
>>645
・・・そういえば折れはOO指向継承懐疑派です。
0647デフォルトの名無しさん
NGNGkHW賎N杏ﾚ1ｵ音 n痰~ ﾆ倪S ﾂ・躑ﾛﾖ・・雰ｻ・・2ﾆ♪Dｹ8FぼU・｢T・T&<・3 >he・ ~5
頚{土`ﾊﾀWｮﾐ堕ｷﾏoF ｽ・oｳﾟrｻ}ﾉ・儻lｺd閨ﾒｼｭl・｡ﾝ熬ﾚﾌLﾙ4ｶ`ｻ・7M@ ﾋ|鴻犒mﾟ
・(妥ﾁUH ﾉLm!ｦ`・ﾉﾛﾓ_些幼｣v・､忝紮ｭF蕈\yｭｫ鯆Q |fﾍ粫J `lwq ・覡X ﾑ卯Hｫﾕﾕ
?ﾘm/・能ｩｺ・{ﾍU25Ek私槁ﾛP cZlﾚﾈｸ・\
ﾛｫL・Yﾂﾕ・・ｭ・ﾉ5ｪﾆfｾ/ｪ %#K煙mxjJｵO<ｽ*・78=ｭｹｧｸﾆt杠<m智]ｱ`:ﾏ澵ｹ｡*ﾊ・ <
でd
+1ｸﾞｱVJﾀ',ｾBﾅJB\ｪ勧f・･ﾏﾋN%・Vrｹﾚe・Uｻｸ・P!Rｰ性ｧ]uﾕｷｳ云GｧS*g: ・^H4ｿ ｲ
ｳ隆e\m純9Rﾒﾃ@・{鏸b i ・・~ﾔH垈ｽmｪﾌ|Kｴｄ・~QｯﾆﾍN・呼.nWｵ罔NﾞNﾗﾃﾓi&問
妺破ﾗ隨Nc・ tﾅАJ・'ﾈkoﾋｼi儘∵ﾐx7ﾕFｾ蠕ｯ・sｽk^ﾗBﾖ?・~㊦ﾛwﾉ0Q%ﾙ6o假Afi
ｵｳぐ鏞;｡ＡﾉG6衞｡Yz朗鋠ﾏlBﾘ*)｣E・ｴｧｶ 達ﾕ髴神ｨ%?,ﾛ鋤De
0648
NGNGKDE, WindowsはNT3.51から, BeOS（これはある意味失敗か）
qmailもOOな設計ゆえあのような形態になったそうです。
0649デフォルトの名無しさん
NGNG0650デフォルトの名無しさん
NGNGHSPを忘れるな
プロジェクトと呼べる物をやってるやつがいるかどうかはあやしいが
0651デフォルトの名無しさん
NGNG0652デフォルトの名無しさん
NGNG>>知ってると思うけど、VCLはCompositeパターンだぞ。
>え？どのあたりがですか？
TComponentがだよ…
それと、これを継承した全てのクラス。
>開発者にはあまり見えなくなっているのですかね。
丸見えだと思うが…
本当にVCLを使ったことあるの？
0653Delギコ
NGNG～′,,,;;,, (,゜Д゜)
UU" " U U
ｱｱ ｶﾙｼｳﾑﾌﾞｿｸ
ちゃんと説明したらどうヨ？
＞Delギコ相談室スレ全部よんどけ。
・Compositeパターン
容器と中身を同一視して再帰的構造を作る
って、TComponentのどこに再帰構造があるの？
∧∧ ／￣￣￣￣￣￣￣￣￣￣￣
(,,ﾟДﾟ) ＜ 単なるあおりに反応してしまっただけかも。
＠/つ且~~ ＼＿＿＿＿＿＿＿＿＿＿＿
（__ _） ｵﾚ ｶﾞｷ ﾀﾞﾅｰ
0654デフォルトの名無しさん
NGNGたぶん後者だろう。
0655デフォルトの名無しさん
NGNGTComponent.Components
0656Delギコ
NGNG電 | ｶｹﾞﾃﾞｺｿｺｿ ｲｯﾃﾔﾙ
|∧ ∧
柱 |,,ﾟДﾟ) ＜ナナナ・・・るほど。
⊂ |
| | シカシ、普段ComponentsなんてFormでしか
|∪ つかーねだろ。むしろControlsプロパの方が･･･
, ' , ; ' ;
ﾐｸﾞﾙｼｲｲｲﾜｹﾀﾞ
0657655
NGNGすぐわかるかと思ったんだけど、どうやら真性みたいだからな。
いいか、TFormもTButtonもTComponentなんだよ。
一見するとTFormがTButtonなどのビジュアルコンポーネントを持てるだけに見えるかもしれないが、
しかしそういう仕組みにはなっていない。
TComponentがTComponentを所有できるようになっているだけ。
TComponentがTComponentを再帰的に所有できるんだよ。
TComponentのComponentsというプロパティに、
TComponentが所有している他のTComponentのリストが入っている。
これがあるからTFormはTButtonを所有することができる。
コンポーネントをクリエイトするときにOwnerへのポインタを渡すだろ。
これは、親のComponentsに自分を登録してもらうために渡している。
つまりキミは日常的にCompositeパターンを使っているんだよ。
TButtonがTFormを所有することもできるはず。
TFormが小細工していなければ、だけど。
TFormにTFormを貼り付けることもできる。
ただしフォームデザイナからはこういう操作はできない。
コンポーネントパターンはこうした自由度をもたらすパワーがあるけれど、
フォームデザイナの都合でちょっとパワーダウンしている。
それでもCompositeパターンの強力さを垣間見ることはできるはずだ。
ビジュアルコンポーネントではないTOpenDialogをTFormに貼り付けられるのも、
これがTComponentを継承しているからなんだよ。
これでわかった？
それともサンプルプログラムでも書かないとわからないかい？
0658デフォルトの名無しさん
NGNGおお、前後してしまった。
わかってくれたようでなにより。
VCLはコンポーネントのリンクを維持するためにComponentsプロパティをフル活用しているよ。
Visual "Component" Library という名前はCompositeパターンに由来しているくらいだからね。
0659デフォルトの名無しさん
NGNG0660デフォルトの名無しさん
NGNG関連スレ
0661デフォルトの名無しさん
NGNG| ありがとうございます。首相並に感動しました。
| 丁寧な解説でより理解できました。
| ご親切な方ですね。
＼＿＿＿ ＿＿＿＿＿＿＿＿＿
∨
♪ ∧ ∧ ♪
(,,ﾟДﾟ). ♪
|つ[|lllll］).
～| |
Ｕ Ｕ ｳｰﾚｼ
真性とかイワンで～
ﾃﾞｻﾞﾊﾟﾀしらないでいたら
Componentsが再帰的とか知らない&気が付いてない人は
山ほどおると思いますよ。
コンポ作成していてもInsertComponentをせずに
メンバーとして持つ事も多いでしょうし。
最近ﾃﾞｻﾞﾊﾟﾀやUMLﾏﾝｾｰっす
0662デフォルトの名無しさん
NGNG一般化して有効に使えるという証明など無かったのに一般化してしまった。
流行も内輪でやってるなら良いけど、宣伝で会社を巻き込まないで
欲しい。（仕事に影響出てくるんで）
0663デフォルトの名無しさん
NGNGComponentsとControlsという、いわば「Compositeパターンの二重管理」状態に
なってるのが、時として自由度を下げているかも、とは思う。
あんまり綺麗ではないな確かに。
>>661
>ﾃﾞｻﾞﾊﾟﾀしらないでいたら
>Componentsが再帰的とか知らない&気が付いてない人は
俺はデザパタなんて知らなかったが(というかデザパタ自体が
有名になってまだ数年しかたってない)、Delのその部分は
気付いてたぞ。実際自作コンポでもしばしば使ったし。
なんで知ってたかって？そりゃ「マニュアル読んだ」からに決まってる。
ComponentsがTComponent型だと気付いた瞬間に、「じゃあ再帰的に突っ込めるんだろうな？」と
突っ込みをいれたくなる(そしてテストコードを書いてみる)のは、
プログラマならデフォだろう。
抽象的なパターンを考えることと、
具体的なDelのComponentsを考えることとは、
似ているようで、微妙に違う。
もちろん両方を考えて、実は同じことを言っていると気付くことは
最終的に大事ではあるが、それは後でも間に合う。
>>662
証明を期待するなよ。証明できる物事もあるが、証明じゃなく経験で
有用性が見出されるものも、有っておかしいわけじゃない。
発明者(?)の意図を超えるほど有用なもの、ってのは
しばしば有るだろう。
Classもそういうものの1つだった、というだけだ。
それを無理矢理、流行で片付けようとヒッキーごっこするのは
カコワルィよ。
0664デフォルトの名無しさん
NGNG>ComponentsがTComponent型だと気付いた瞬間に、「じゃあ再帰的に突っ込めるんだろうな？」と
>突っ込みをいれたくなる(そしてテストコードを書いてみる)のは、
>プログラマならデフォだろう。
テストコードというより
画面の解像度に合わせて部品のサイズを自動調整するには普通そうするよね
0665デフォルトの名無しさん
NGNGあれぐらいモデリングをしっかりすれば自分で考え出せるだろう。
デザパタの意義は、カタログにしたその取り組みにあるだけ。
0666デフォルトの名無しさん
NGNGあれぐらいモデリングをしっかりすれば自分で考え出せるだろう。
デザパタの意義は、カタログにしたその取り組みにあるだけ。
0667デフォルトの名無しさん
NGNG天才だろ。時々考え出してしまうこともあるかもしれないが、
多くの状況では知ってなきゃ使わない類のもんだ。
初めて考え付くのが偉大なのに、知った後から「こんなもん簡単だ」
なんて思うのは当たり前。そんなこともわからないのは馬鹿の証拠。
0668Delギコ
NGNG>おいおい。あれを使える場面で当たり前のように考え出して使う奴は
>天才だろ。時々考え出してしまうこともあるかもしれないが、
∧ ∧ ／￣
（∩(,,ﾟДﾟ) ＜ よかった、ﾃﾞｻﾞﾊﾟ初心者だから
⊂,,＿_つつ. ＼ 変な意見を鵜呑みにするﾄｺだったよ。
今朝読んだFlyweightﾊﾟﾀｰﾝは自分で実装してたなあ。
＞デザパタ自体が有名になってまだ数年しかたってない)、
ﾌﾟﾛｸﾞﾗﾈｺ-になてからまだ数年しかたってないんですが…
>ComponentsがTComponent型だと気付いた瞬間に、「じゃあ再帰的に突っ込めるんだろうな？」と
>突っ込みをいれたくなる(そしてテストコードを書いてみる)のは、
>プログラマならデフォだろう。
デ・デフォなんですか？
> 抽象的なパターンを考えることと、
> 具体的なDelのComponentsを考えることとは、
> 似ているようで、微妙に違う。
ﾈｺにはまだまだだいぶ違うです
>もちろん両方を考えて、実は同じことを言っていると気付くことは
まだ、なかなか...その境地に達してないつーかニャー
0669デフォルトの名無しさん
NGNG表現はともかくとして>>666に私は賛成の立場です。
「利用する」より「考える」ことの方が重要と思います。デザパタを知る
ことでとても大切な事を考える事が疎かになるならばその先の成長は見込
めないと思います。利用する前になぜそれが必要なのかをじっくりと考え
られればまだ救われますが、それができる人もまた限りられたひとだろう
と思います。天才と簡単に言われていますが、天才というよりも、良い
デザインや実装をしようということに拘ったからこそ、デザパタが作られたので
あって天才だったから簡単に作り出したというわけではないという所が
肝かと思います。またデザパタを知ったからといって、それで簡単あるいは
優れた設計や実装ができる訳ではないと思います。それを知ってもさらに考える
事が必要ですから、その時に再度「考える」という事が問われます。そして
それを突き詰めて考え解決できるならば、デザパタも作り出せるだけの力が
付いていると思われますので、結局はデザパタを知ることよりも「考える力」
を付けることを重視した方が、先に繋がるでしょう。
0670デフォルトの名無しさん
NGNG急がば回れですね。う～ん。
確かにそういうことって多いよな～。学校教育ってもろそういう所
あるものね。問題解決能力を高める事が重要ってことね。
内容なくて、スマソ。
0671デフォルトの名無しさん
NGNGどういう関わりをすればそうなるのだろう.
0672デフォルトの名無しさん
NGNGなんか違くない？
>天才というよりも、良い
>デザインや実装をしようということに拘ったからこそ、デザパタが作られたので
>あって天才だったから簡単に作り出したというわけではないという所が
>肝かと思います。
>>667は、天才がデザインパターンを作ったとは言ってないよね。
いちいちデザパタを発明できるような天才はいないと言っているのでは。
デザインパターンがデザインを考える機会を削ぐという発想には反対。
アルゴリズムを学んだ人が新しいアルゴリズムを生み出せなくなったかというと、
そうでもないでしょう。むしろアルゴリズムに強い人は、
過去のアルゴリズムをよく知っている。
高速フーリエを知らない人がMP3を生み出せるとは思えないね。
アルゴリズムを教えると、アルゴリズムを考える力がなくなるから、
大学でアルゴリズムを教えない方がいいの？
それっておかしいよね。
アルゴリズムもデザインパターンも、基礎教育として教えるべきだと思う。
それで思考停止してしまう一万人は無視して、より深い指向ができる百万人を育てようよ。
0673デフォルトの名無しさん
NGNG|アルゴリズムもデザインパターンも、基礎教育として教えるべきだと思う。
それはなぜですか？
0674デフォルトの名無しさん
NGNG>>669の言ってることって全然違うだろ。
666みたいのを見ると、漫画初めて物語で観た
「コロンブスの卵」のエピソードを思い出す。
067522
NGNGhttp://www.max.hi-ho.ne.jp/%7Ehttp/
0676デフォルトの名無しさん
NGNG「情報工学を学ぶ学生の基礎教育として」という意味でした。
言葉足らずですいません。
0677デフォルトの名無しさん
NGNG感じます。
情報工学を学んだとしても、優秀でない人はあまりその恩恵は受けて
いないようにおもわれます。ここでの優秀というのは問題を突き詰めて考え
られるかどうかという程度です。
逆に、情報工学を学んでいなくても、問題を突き詰めて考える人は
どんどん伸びるように思われますが、どうでしょう？
もちろん学者になろうというのであれば、そういった工学を学び
研究していくという道もあろうかと思いますが、現在の情報工学
は現場ではそれほど生きていないように感じます。
一般的によくみるのは、流行の技術を追い掛け、ちょっと人より
知っていることに優越感を感じそれに満足しているというパター
ンです。そして、そういう人に限ってプロジェクトにあれこれと
文脈を無視した意見をしプロジェクトを路頭に迷わせ、だめな
やつらだと愚痴をいってまた自己満足。そんな人、多くないでしょうか？
デザパタが出てくる前にもＯＯですぐれたシステムは作られていた
訳ですから必須項目とは思えません。
工学としてならう枯れたアルゴリズムとデザパタを同列に扱うとおっしゃるとおり、知っていた
方がよいという考えになると思いますが、そういったアルゴリズムは
帰納的なもので、
設計というのはそのつど問題に向き合い解決していくものではありますが
答えが一つとは限らない演繹的なものなので、同列に扱うのはどうかと
思います。
0678デフォルトの名無しさん
NGNG0679Delギコ
NGNG(,,ﾟДﾟ) ＜ デザパタは設計を考え事を加速させる
| つ[|lllll］). ＼＿＿＿＿＿＿＿＿＿
～| |
∪∪
ｸﾗｽﾗｲﾌﾞﾗﾘを使っていただけで、なんでも作れると
思ってしまっていたけど
デザパタで深遠なるｵﾌﾞｼﾞｪ志向の扉を開けれた気がするよ。
＞デザインパターンがデザインを考える機会を削ぐという発想には反対。
そうそう。
機械を削ぐとはﾑｼﾛ逆。
ﾃﾞｻﾞｲﾝをより深く考えてﾃﾞｻﾞﾊﾟﾀを組み合わせたり
自分で新しいものを作る糧になるのでは？
>>672氏イイ！
でも、基礎教育で教えても
ﾌﾟﾛｸﾞﾗﾑが余り組めない人に役に立つかどうか…
0680デフォルトの名無しさん
NGNGあんま論理的思考が得意ではなさそうだな。
大学も出てなさそうだな。
SEとコミュニケーションがうまく取れてなさそうだな。
ストレス溜まってそうだな。
0681デフォルトの名無しさん
NGNG大抵のプログラマなら自分で同様の物を考え出して
過去に実際に使ってみたことがあるはず。
ただ、それをパターンという形に括りだして、分類して、
名前を付けて、ああいうカタログ本にまとめたことが偉い。
ノウハウは整理体系化されることでテクノロジーになる、そういうもんじゃない？
0682Delギコ
NGNGﾃﾞｻﾞﾊﾟﾀに縛られるっていうのは
いっつも、forループも使わずにｲﾃﾚﾀしちゃう人っていう事でしょうか？
それはそれで確かに迷惑かも。
そもそも、ｲﾃﾚﾀだけは役に立たないと感じたけど。
> 一般的によくみるのは、流行の技術を追い掛け、ちょっと人より
> 知っていることに優越感を感じそれに満足しているというパター
> ンです。
∧ ∧ ／￣￣￣￣￣￣￣￣￣￣￣￣
～′￣￣(；ﾟДﾟ)＜ ｶﾞﾋﾞｰﾝ。折れかも。
UU￣￣ U U ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
だけど、周りの人がちょっと(いや、かなり)知らないから
半年かかっても出来ない事を
ちょっと知ってて3日で出来たりしたらうれしいし
役に立つと思うんだけど…
例えばタブブラウザ作りたいって時に
ﾌﾞﾗｳｻﾞを1から作っちゃう人ばかりの中に
「IEのＡｃｔｉｖｅＸ使えばいいよ」
って言えるのって、だめ？
>>680氏
"だな"、多そうだな
0683デフォルトの名無しさん
NGNG最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね。
0684デフォルトの名無しさん
NGNGＯＯマンセー
0685Delギコ
NGNG(；ﾟДﾟ) おぬし、通よのぉ
(| |つ
～| |
∪∪
そうそう。ｲﾃﾚﾀを教科書どおりにバカ正直に実装されていたら
XPﾏﾝｾｰな折れとしては、ﾃﾞｻﾞﾊﾟﾀを知らなきゃ
ﾘﾌｧｸﾀﾘﾝｸﾞでシンプルなものを目指して
ブチ壊してたかもしれない。
今でもﾃﾞｻﾞﾊﾟﾀを読みこなせなければ(読み逃してしまったら)
ｲﾃﾚﾀはつぶしてしまうかもなあ。
要所要所でﾃﾞｻﾞｲﾝを考えたり、よりシンプルにしたり
その辺のバランス感覚って重要かもと思う。
＞最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね。
foreach構文はいいですね。括弧ヨサゲ。ｸｰﾙですわ。
Delにも搭載されないかしら。
0686672
NGNG>一般的によくみるのは、流行の技術を追い掛け、ちょっと人より
>知っていることに優越感を感じそれに満足しているというパター
>ンです。そして、そういう人に限ってプロジェクトにあれこれと
>文脈を無視した意見をしプロジェクトを路頭に迷わせ、だめな
>やつらだと愚痴をいってまた自己満足。そんな人、多くないでしょうか？
これについて一言あります。
私は数年前に転職しました。
前の会社はOOに積極的で、デザインパターンもとりいれ、
社内で○○パターンと言えば誰でもわかる状態でした。
多くのプログラムがデザインパターンやＯＯを活用して作られていましたが、
プロジェクトが路頭に迷ったりすることはなく、
開発効率が高くて開発コストは非常に安く、
不具合発生件数もかなり少なかったのです（この会社がＯＯに走る前の状態と比較して）。
小さな会社でしたが、品質が高いとよく誉められたものです。
今は別の会社に転職しています。
ここではオブジェクト指向は誰も知りません。
デザインパターンと言ってもさっぱりです。
開発効率も悪いですし、不具合発生件数は非常に高く、
潜在的な不具合は表面化している数値よりはるかに高いと思います。
何度かオブジェクト指向を取り入れさせようと頑張ってきましたが、
自分が頑張ってもしょうがないことを悟っただけでした。
大きな会社ですが、品質が低いとよく叱責されます。
今の会社で、あなたの言う「自己満足クン」になっています。
はたして私は間違っているのでしょうか？
ただ本を読んで得た知識だけで言っているのならともかく、
私は前の会社で、それが役立つことを、身をもって知っているのです。
情報だけの頭でっかちではなく、実際に経験して効果をあげた実績があるのです。
画期的な効果をあげた経験を、理解されないという下らない理由で捨てるのですか？
オブジェクト指向もデザインパターンも、それほど難しい理論ではなく、
きちんと学習すれば必ず身につくと思います。
学習が思ったように進まないのは効果が疑われているからです。
疑いが学習の妨げになっています。
しかし自分の経験では効果があります。
そもそもオブジェクト指向は演繹ではなく帰納なのです。
0687デフォルトの名無しさん
NGNGいい経験も悪い経験もしているようですね。
会社の雰囲気って大きいですよね。一所懸命やってもそれが生かすことができない
ようじゃ自己満足クンになるしかないですね。でもがんばってくださいね。
|そもそもオブジェクト指向は演繹ではなく帰納なのです。
言い切るだけでなくて、この説明をしてください。
0688デフォルトの名無しさん
NGNG初心者にとっては過去のアイディアであって、
上級者にとっては、テクニカルタームなわけです
デザパタのおかげで、コードにイテレーターって書いてあれば
読むの楽ですよね
>最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね
そうなんですか・・・
それはあまり好ましくないですね
世間一般で行われていることはレベルが低いといことでしょう
0689デフォルトの名無しさん
NGNGめずらしい転職のパターンだな。
前の会社のなにが不満だったの?
0690デフォルトの名無しさん
NGNG最初にいた会社とその後変わった会社では、作っているシステムは
同じだったんですか？
デザインパターンを使いＯＯを使うと品質が高くなるというその
理由は、なんですか？
そういう経験をしたという事を力をいれて説明されてもそうですか
しか意見をいえません。どういったことが影響して品質が高くなる
のかを述べてください。
どういう分析をされるかわかりませんが、ＯＯをしなくてもそれ以前
も現在の品質が高いものは作られたわけで、私にはＯＯをすれば単純
に品質が高まるという主旨のご意見には同意しかねます。
0691デフォルトの名無しさん
NGNG2点質問。
・OOPを理解してますか？実際の開発に適用したことは？
・あたなが最も効率的に開発を行える言語・手法・パラダイムは？
0692デフォルトの名無しさん
NGNGOOじゃないプログラムって、いったいなに作ってんだ？
OO＆デザインパターンを使ったほうが、
設計フェーズで楽できるし、いいものができるのって当たり前だと思うけど
JAVAのライブラリー（デザパタならSWING)とか使ったことないのか？
普通のセンスなら、OOやデザパタの良さが理解できると思うが
0693デフォルトの名無しさん
NGNGそうね。
686の話は、
ＯＯしているかとかデザパタを知っているかとは、
違った所に、問題がありそうですね。そういう経験を単純に関係付け
するような奴がまともにＯＯをやっていたとは思えないのだが。（藁
0694デフォルトの名無しさん
NGNGそれなのに、せっかくＯＯを使ってる奴を自己満足扱いにして邪魔者扱いに
するのはいかがなものか。ＯＯ使わなくちゃいけないとまではいかなくても、
ＯＯ使うのは別に悪いわけでは無いじゃん。
明らかに周りが悪いだろ。
0695デフォルトの名無しさん
NGNGRubyにしてもC++にしても、ＯＯで設計実装されてないじゃない。
何いってんの。UNIXだってLinuxだって、そうだよ。
上げだしたら切りがない。
ＯＯしないと品質が上がらないなんて思っているようじゃ厨房ですね。（藁
0696デフォルトの名無しさん
NGNG生産性があがった所もあれば下がったところもあるのが常識です。
ＯＯをしなくても生産性が高い所もあったという事実もしって
おいた方がよいでしょう。
0697デフォルトの名無しさん
NGNGお前らも論理に不自由そうだな(藁
0698デフォルトの名無しさん
NGNGＯＯしても品質が上がらない時があるとか、ＯＯをしなくても
素晴らしい品質のものを作ることが出来るとか、ＯＯに頼りすぎ
は良くないという話は認めるとするよ。
でも、それがなんでＯＯ知ってるのは自己満足の悪であると
いう話に発展するの？
むしろＯＯは多くの場合武器になると言うのに。
0699デフォルトの名無しさん
NGNG>ＯＯしないと品質が上がらないなんて
はて？
OOすると品質が上がると思うけど
>何いってんの。UNIXだってLinuxだって、そうだよ
一応、あれがC流のOOなんですが・・・
RUBYとC++はOOしてもしなくても大して変わらないのは
単純だから
コンパイラも作ったことないのか
ソース見たことないから、OOでコーディングしてるかは知らない
ただ､設計フェーズではOOです
0700デフォルトの名無しさん
NGNGハァ？
0701デフォルトの名無しさん
NGNGCOBOLなんて、ドメインによってはめちゃくて生産性も品質も高く
開発できますからね。生産性なんて部品的に使えるものが多ければ
高まりますからね。ＯＯかとかそうでないかというだけで、単純には
判断できないものだと思います。
どこに使うか、何に使うか、誰がつかうか、どのように使うかに
よって変わるものですね。
ＯＯをすればそうなるはずという机上論はわかるのですが、それが
実際に達成されるかどうかは別問題。そして、常識かどうかという
のを机上の話でしているのか、事例の話でしるのかを明確にして話
をしないといけないでしょうね。
0702デフォルトの名無しさん
NGNGOO叫んで袋叩きにあうのが、
ほとんどだよ。9割ぐらいそうだろ。
0703デフォルトの名無しさん
NGNGOOプログラマー多いです
とくにJAVAでは顕著です
OOの敷居は高いので、あまり見かけないと思うのですが
0704デフォルトの名無しさん
NGNG賛成！
0705デフォルトの名無しさん
NGNG0706デフォルトの名無しさん
NGNG|ソース見たことないから、OOでコーディングしてるかは知らない
|ただ､設計フェーズではOOです
おまえがRuby作ったわけじゃないのになんでわかるんだ。
ソースもみてもないのに。
ばーか。おまえみたいなのが、ＯＯ普及のじゃまをするんだよ。
0707デフォルトの名無しさん
NGNGOO使うまでもないね
確かに､何人かで作る時に
馬鹿が混じるとOOどころじゃないね
有能なプログラマーだけが使えばいいと思う
そういうわけで､月試福ｪ１００万を鋳ｴえてる場合に血ﾀり
OOを試gっております
それでも馬鹿は混ざるんですが
0708デフォルトの名無しさん
NGNGオブジェクト指向に見向きもしない向上心の無い
奴よりマシ。
経験をつめばいずれ気づくし。
0709デフォルトの名無しさん
NGNG普通のリーマンコーダなんてこんなもんでしょ。
だって、今までの経験でこれからも惰性で開発できるんだから
わざわざ自腹で本何冊も買って勉強するなんてアホらしいよ。
0710デフォルトの名無しさん
NGNG0711デフォルトの名無しさん
NGNGだから、普通のそういう奴はドキュソであり、最低ランクだな。
0712686
NGNG>デザインパターンを使いＯＯを使うと品質が高くなるというその
>理由は、なんですか？
私にはこれを演繹的に筋道立てて説明できません。
どういう経験を指して品質が高いと言っているのか、
ということであれば、前の会社がDelphiで開発しているような感覚であるのに対し、
今の会社ではWindows 16APIを直接操作しているような感覚です。
でもこの差を説明しようとすると、
どうしてオブジェクト指向が良いのかを証明しなくてはいけないかも？
0713デフォルトの名無しさん
NGNGコンパイラの本読んでみなよ
理由がわかるよ
って､ここ大学生少ないの？
0714デフォルトの名無しさん
NGNG>>708
大事なのは、顧客にとって質のあるものを作ることですね。
そう考えると、>>707 で書かれているような悪い環境では
ＯＯをすることよりも他の事に力をいれようと思う人もいる
訳です。現実主義の人、理想主義の人、保守主義の人など色々
といて多様です。どれがいい悪いというよりも、そういった人
達がいることを認め、とことん話をするしかないと思います。
場合によっては、ＯＯよりも構造化設計やCOBOLがいい場合も
あるのですから、何を使うのが顧客のためかという所を大切
にして話し合いをすることが何より大切と思います。
0715デフォルトの名無しさん
NGNG日本としては、いいチャンスなんだけどなぁ。
だれか仕切ってやればいいのに。
0716デフォルトの名無しさん
NGNGムキになるな。お前がたいしたことないのはすでにわかってるんだから。
0717デフォルトの名無しさん
NGNG0718デフォルトの名無しさん
NGNGお前の文章は、まったく論理的でないことを理解していっているのか？
本当に馬鹿だな。
0719713
NGNG0720686
NGNGOOの無い職場にOOを入れるのは大変で、
向上心のある人が何人かいても難しい。
パーツを一から作り上げないといけないし、
下手なパーツが積み重なって全体を壊すかもしれない。
ところがOOのある職場に、OOの経験が無い人を入れると、
それがオッサンでもすぐに馴染む。
上手くできているパーツを組み合わせるだけだから失敗しようがないし、
どういうパーツがいいパーツなのか、使うだけで勉強になる。
なんとかこの差を埋める方法は無いものかね。
いつの日かあの楽チン環境に戻りたいよ。
同じ事をするのに数倍の手間をかけていると思うと泣けてくる。
0721デフォルトの名無しさん
NGNGソースコード盗んでくればよかったのに。(ｗ
0722デフォルトの名無しさん
NGNGそのとき机に積んである書籍の種類を確認するといいよ。
ボロボロになったK&R一冊とかって会社はやめといた方がいい。
0724Delギコ
NGNG（ ＿(,,ﾟДﾟ) ＜ アホが混じってるみたいだ。
⊂,,＿_つつ. ＼＿
嫌オブジェクト指向スレでも立ててやってくれよ。
一向に、オブジェクト指向論議が進まなくない？
はじめから仕様が完璧に決まっているなら
OOでも非ＯＯでも品質は同じだろうけど
(多分、非OO派はこういう環境にいるんでしょ
そんな環境ではコーダーとか言われかねないよ)
#COBOLで簡単なものを作るとか、言ってる人もいらっしゃるが
それは違うぞ。仕事のやり方が、完璧な仕様を作ってからコードという
システムになっているらしい。
実際はウソッコだけど。
ＯＯすると仕様変更に非常に柔軟に対応できるようになる
現実のプロジェクトでは仕様変更が日常茶飯事、
特に、最近のプロジェクトは短納期という状況が多いですね。
それに短期間で対応できるOOが
結果的にＯＯは品質の高いものが作れるよ。
> ちなみに、OOを理解してると勘違いしている
> OOプログラマー多いです
> とくにJAVAでは顕著です
> OOの敷居は高いので、あまり見かけないと思うのですが
Javaの皮かぶったCOBOLerが多いですね。
話を聞いて、元コボラだったら気をつけましょう。
>>712
わかりやすいです。
>>723
ソースを盗むのではなく、ノウハウを盗もうよ。
0725デフォルトの名無しさん
NGNGもうすこしお勉強してから来てね。
0726Delギコ
NGNG（ ´∀｀）＜ >>725 オマエモナー
（ ） ＼＿＿＿＿＿
｜ ｜ |
（_＿）＿）
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
∧∧ ＜ よーし、定番定番。
（ﾟДﾟ∧)_∧ ＼＿＿＿＿＿＿＿＿＿＿＿＿
（￣⊃ ´∀｀)
｜ ｜￣|￣
（_＿）＿）
／￣￣￣￣￣￣￣￣￣￣￣￣
∧∧ﾊｯ! ＜ なに見てんだｺﾞﾙｧ!!
（#ﾟДﾟ∧_∧ ＼＿＿＿＿＿＿＿＿＿＿＿＿
（￣⊃ ´∀｀)
｜ ｜￣|￣
（_＿）＿）
0727686
NGNGノウハウは持ってるよ。
実際、そのソースの多くは自分のソースだし、
他人のソースにもある程度自分の意見が含まれている。
だけどそれを会社に広めるのは別次元なの。
一人だけで踊ってもしょうがないのよ。
C++でやるぞ、Javaでやるぞと言っても、
「また自己満足クンが何か言っているよ」と思われるだけだし、
一人だけC++で書いたモジュールを混ぜるというわけにもいかないし。
一人だけでシステム全てをコーディングするのも非現実的だし。
今は１０年計画で若い人を育てることに血道を上げてます。
0728ｽﾚｽﾄｯﾊﾟｰDelギコ
NGNG(,,ﾟДﾟ) ＜ ちょっと遊びすぎた。
Π￣￣￣| ＼
|つゴメン () ￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| |＿＿＿.|
∪∪
話を修正
>>714
現実問題として、OO以外の開発って何でやっているのですか？
少なくともOO言語でやっているのなら
ちょっと優秀な人にある部分を任せたら
すぐにOOをしてくると思うのですが...場合によってはそれを否定するのですか？
そんな状況、優秀な人、嫌気がさして辞めませんか？
そういう環境の究極的な解決方法としてXPというものがあります。
ペアプログラミングという方法論があって
それをしたら全員がOOをマスターするのは
人月的にみたら一瞬だと思いますが
どうしてそういうことをされないのでしょう？
>>720
よっぼど楽ならともかく
やめようよ、そういう会社は、
自分のキャリアを汚すだけにしかならないかもよ。
ﾌｷｮｳといえどもソフト業界は人手不足にあふれているさ。
> >オブジェクト指向に見向きもしない向上心の無い奴
> 普通のリーマンコーダなんてこんなもんでしょ。
> だって、今までの経験でこれからも惰性で開発できるんだから
> わざわざ自腹で本何冊も買って勉強するなんてアホらしいよ。
うーーーん、
職業意識とかは芽生えないか、な。
自分より年下の人間にバカにされたいか?
すぐに追い越されるぞ。
0729デフォルトの名無しさん
NGNG>今時OOがダメとかいう アホが混じってるみたいだ。
っていうのに現実感が感じられないのよ。
727のように、現場では、イタイ人間と紙一重なの。
そこから、責任者とチームを説得し、広めるのに
どれだけ苦労するのかわかる？
>>727
>１０年計画
遅いと思われ。出たほうが身のため。
10年後
前の会社にいた人間がどうなっているか想像してみて。
かけはなれてるだろ？
0730Delギコ
NGNG(,,ﾟДﾟ) ＜ >>727 大変よくわかります、その↓
Π￣↓←←←←←←←←←←←←←←←←←
|つ 境遇 () ￣￣￣￣￣￣￣￣￣￣￣￣￣
| |＿＿＿.| >>729ﾜｶﾘﾏｽ
∪∪
うちの会社はOOを理解してない人はいなかったから
まあまあマシだったけど
変な非効率なやり方を修正しようとすると、つらいっすよね。
面と向かって、"あの人だめだなあ"
なんて同僚でもいいにくいし。
ついでいうと、下請けだったら
上の会社がわかってない所から発注だと
旧態依然とした無意味な納品のためだけの仕様書
とか書かされる。
なんでこの業界、デキナイ人間がデキル人間の足を
とことん引っ張るわけだ？
せめて、生産性の高い人の足はひっぱるなよ、ﾋﾄﾄｼﾃ
とか、おもうたり～～～
このスレで言う所のOO否定者はOOを理解してから否定している？
そうじゃないのなら、足はひっぱらないで。
クレと、ひっぱらないでクレ、そうしてクレ、と、小一時間問い詰めたィ・・・・(ﾈﾀ)
ま、ﾈｺの意見だから無視したい人はしちゃって許してね
0731デフォルトの名無しさん
NGNG> ま、ﾈｺの意見だから無視したい人はしちゃって許してね
公の場に書き込んだ以上、逃げはいかんよ、ﾋﾄﾄｼﾃ
とか、おもうたり～～～
0732686
NGNG>よっぼど楽ならともかく
>やめようよ、そういう会社は、
>自分のキャリアを汚すだけにしかならないかもよ。
>>729
>遅いと思われ。出たほうが身のため。
>10年後
>前の会社にいた人間がどうなっているか想像してみて。
>かけはなれてるだろ？
いや、そこまで悲観しているわけじゃない。
今の会社は良くも悪くも普通。
決して技術力で劣っているわけではなく、
むしろ部分的には見るべきところもあるし。
OOは、あると楽できるというポジティブなものであって、
無いと困るというネガティブなものじゃない。
OOできなきゃ仕事にならんということは無いからね。
あと今後の成長に関しても、そんなに悲観していない。
OOが身に付いていれば最近の技術はすぐ身に付く気がするんだ。
デザインパターンとかUMLとか出てきたけど、
OOは大筋ではもう１０年以上変わってなくて、
OOに関連する技術である限り水が染み込むように吸収できると思う。
もうここまで来ると、そうそう若い奴らには負けん。
0733デフォルトの名無しさん
NGNG失礼かと思いますが、貴殿の話は何か、現実味が感じられません。
話作ってません？
気のせいだったら、ごめんなさい。
0734デフォルトの名無しさん
NGNG計画経済、統制、言論弾圧、思想改造、プロパガンダ、異端査問。
それらがもたらした物は人々の望まないこうした物でしかなかった。
祭りは終わった。
だが、まだ祭りの終わりに気付かずに酔いつづける人が星を掴もうとしている。
0735デフォルトの名無しさん
NGNG0737奈々氏ギコ
NGNG∧∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
(,,ﾟДﾟ) ＜ 演繹的・・・えんえきてきって読むんだ…
Π￣￣￣| ＼ ←
|つ奈々氏() ￣￣￣￣￣￣￣￣￣￣￣￣￣
| |＿＿＿.| ﾈｺ ﾆﾊ ｲﾐ ﾜｶﾗﾝ
∪∪
>>732
もったいない。オバケが・・・・
δ δ ｱﾅﾀﾉ ｷﾞｼﾞｭﾂ ﾓﾀ～ｲﾅｲ
♪ ∧ ∧ ♪ δ ﾓﾀ～ｲﾅｲ
（,,ﾟДﾟ) ♪ ｲﾅｲ ｲﾅｲ ﾊﾞｱ
|つ[|lllll］).
～( / δ
）,ノ
υ
でも、他の人より秀でていると
仕事も楽でいいかも、ですよね。
(これぞ人生の処世術)
＞そうそう若い奴らには負けん。
折れ、ﾌﾟﾛｸﾞﾗﾊｼﾞﾒﾃマル3年っす。
ネットで調べると後進からの追い上げは怖い。
0738デフォルトの名無しさん
NGNG0739デフォルトの名無しさん
NGNG出来るならやり方を教えてほしいです。
0740デフォルトの名無しさん
NGNG山ほどAssert関数作ってtest関数実行すればよい。
特にフレームワークなんて作る必要ないけど、探せば幾つか見つかるよ。
0741デフォルトの名無しさん
NGNG0742デフォルトの名無しさん
NGNGどの変が？
0743デフォルトの名無しさん
NGNG確かにRationalは頑張りすぎ。
UMLマンセーだったけど、最近の仕様追加にはうんざり。
使いたいところだけ使おう。
0744デフォルトの名無しさん
NGNG普通は、OMTで十分。
0745デフォルトの名無しさん
NGNGなんつうか。CだってOOPできるだろ。特に情報隠蔽やカプセル化
なんてまともなCプログラマならみんなやってると思う。
それより非効率な物を具体的に発見して、それの解決法を
提示したときになんでちゃんと納得させられないのか理解に苦しむ。
それができないのは
１・相手のプライドゆえ非効率を認めない。
２・相手が論理的思考が出来ない。
３・あなたが利点を人に説明できるほど理解していない。
４・そもそも(その状況では)利点がない。
５・説得する気なんかない
からじゃない？
１なら納得はさせているのだからあとは対人スキルの問題。
２ならほんとのドキュソ。OOPとかそういう問題以前。
ただ２と３は紙一重だから謙虚に考えたほうがいいと思う。
そして一生懸命説明しているうちに実は４だってことがよくある。
５ならまさに自己満足君だ
0746デフォルトの名無しさん
NGNG激しく同意。
ＯＯＰが出てからカプセル化、隠蔽、シリアライズ初めて知った
奴の方がＤＱＮ。
0747デフォルトの名無しさん
NGNGC言語で隠蔽された関数ってどうやって作るの？
C言語で派生後のクラスからアクセス出来ない変数どうやって作るの？
0748デフォルトの名無しさん
NGNG擬似的なものは十分作れるよ。
それに、隠蔽や継承＝ＯＯという考え方自体がキティ。
sage
0749デフォルトの名無しさん
NGNG>擬似的なものは十分作れるよ。
「みんなやってると思う」の直後に「擬似的なもの」ってのはやめてよ。恥ずかしいＹＯ！
0750デフォルトの名無しさん
NGNG>なんつうか。CだってOOPできるだろ。特に情報隠蔽やカプセル化
自分で言ってること分かってないでしょ！
0751デフォルトの名無しさん
NGNG745-746 != 748
ちなみに俺は 748。
745,746 はＯＯＰ自体はＣでも
可能(というか言語に依存するもんじゃない)で、
実際、ＯＯＰの要素技術として代表的な隠蔽その他もろもろは
Ｃでも実装できるし、その程度なら誰でも把握してるもんだろ、
という意味に取った。
外してるか？
0752デフォルトの名無しさん
NGNG情報隠蔽やカプセル化は手段であって
OOPと直接的な関連は無いぞ。
0753デフォルトの名無しさん
NGNG0754デフォルトの名無しさん
NGNG勉強足りないね。最近はOO言語から入る人が多いから仕方ないの
かもしれないね。でも、知ったかぶりはかっこ悪いよ。
OO言語は、OOがしやすい言語だよ。C言語でＯＯするには、
X toolkit を勉強してみよう。クラス(Widget)を設計するのは
とっても面倒だけど、隠蔽も継承もできるぞ。
0755デフォルトの名無しさん
NGNGOOらしい設計しようとか、ちゃんとデザパタしようとかするとめちゃくちゃ難しいよ。
仮想関数を活用しようとすると複雑度が危険なくらい増す。
特に非OOなコードがたくさん混じっている状況でOOするのは不可能に近い。
かろうじて自分だけが作ったモジュールだけがOOできるものの、
他のモジュールへのアクセスはやはり非OOにならざるを得ず、
Ｃではラッパーを作るのも厳しい。
0756デフォルトの名無しさん
NGNG>という意味に取った。 外してるか？
自分でアクセスしないことにしたから隠蔽っていうのは隠蔽じゃないんだ。
大型開発で一人の人間が規則を破ったら終り。また、デグレしやすい。
それに対して、コードでprivateって宣言すれば外からアクセス出来ない、こういうのを隠蔽という。
外してるということを分かって貰えましたか？
0757デフォルトの名無しさん
NGNG関数やデータや定数を無闇に隠蔽してしまうので困る。
0758デフォルトの名無しさん
NGNG>X toolkit を勉強してみよう。クラス(Widget)を設計するのは
>とっても面倒だけど、隠蔽も継承もできるぞ。
面倒なことはあなたがやって下さい。自分は嫌です。
0759デフォルトの名無しさん
NGNGOOするのなら最初からC++とかのOOPL使ったほうがいいんじゃないの？
0760デフォルトの名無しさん
NGNG>関数やデータや定数を無闇に隠蔽してしまうので困る。
自分が知らないんだろ。宣言をprivateからpublicに移動するだけじゃん。
0761748
NGNGよほど凝ったことをしなければアクセスできないようにすることはできるけど？
例えば、Windows の API にはおなじみの HANDLE。
HANDLE が指す対象のメモリ上の実データは隠蔽されている。
これじゃ不十分かい？
0762デフォルトの名無しさん
NGNGやっぱりOOがわかってないと思われ。
0763748
NGNGむ。そう言われると少しカチンと来るな。
俺にしてみれば Windows API のデザインは
一応ＯＯの原則に則っていると思っている。
実データの隠蔽やカプセル化、継承などもある程度成立している。
この考え方のどのあたりがダメなのか説明してくれ。
0764デフォルトの名無しさん
NGNGクラスにすると明らかに幾つもメリットがあるんです。
それは、このスレで出てるから読んでみて。
0765デフォルトの名無しさん
NGNGHandleはオブジェクトへの参照だろ。
ＣでＯＯする場合の常套手段だよ。
しかしHandleでOOするのは限界がある。
OOを良く知れば、Handleでは不十分なことも知っているはずだね。
0766Delギコ
NGNG(；ﾟДﾟ) って無茶苦茶な理論を振りかざしてきてるだけじゃないの？
(| |つ
～| | ﾊﾞｶは品なきゃ治らないとか？
∪∪
メモリをポインタ渡しで、間違ったものわたしても
コンパイルエラー出ないような言語
なんであえて使う必要が…
>>745
>なんつうか。CだってOOPできるだろ。特に情報隠蔽やカプセル化
>なんてまともなCプログラマならみんなやってると思う。
まともなプログラマなら他の言語使ってる。
0767デフォルトの名無しさん
NGNGhttp://piza2.2ch.net/test/read.cgi/tech/1001275287/571
0768748
NGNGん？
別にＣでも書けるんだからクラスなんて要らないよとか書いた覚えはないぞ。
ＯＯＰとＯＯＰＬとを混同するのはよくないという視点で書いただけ。
Ｃ＋＋処理系が手元にあったらＣでＯＯしたりなんかしないって。
0769748
NGNGだからぁ、俺はＣで十分だなんて言ってないってば・・・。
できないことはないよ、何故ならＯＯＰとＯＯＰＬは違うから、
と、そう言いたいだけ。
0770デフォルトの名無しさん
NGNG頭おかしいね。
無限の時間と全てのコードを頭に入れることが出来るんなら、ＯＯＰＬ以外でＯＯＰすれば良いだろう。
プログラミングは有限な中でやるもんだからね。
>Ｃ＋＋処理系が手元にあったらＣでＯＯしたりなんかしないって。
はやく手に入れろよ。
0771デフォルトの名無しさん
NGNGＯＯの概念の多くは、ＯＯＰＬが登場する以前から、
まともなプログラマならやっていた。
ＯＯＰＬいらないって主張なの？とか、ボケは勘弁。
0772オリジナルギコ
NGNG>と、そう言いたいだけ。
∧ ∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
～′￣￣( ﾟДﾟ)＜ 逝ってよし！
UU￣￣ U U ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
0773748
NGNGＯＯＰとＯＯＰＬは違う、というのは、
ＯＯＰＬはＯＯＰの実現手段に過ぎず、
その具体化である(個々の)ＯＯＰＬとＯＯＰは１対１対応しない、ということ。
だから、あるＯＯＰＬで提示されているＯＯＰのモデルが
ＯＯＰの全てのモデルを代表することはないし、
あるＯＯＰＬや、非ＯＯＰなプログラミング言語でも
ＯＯＰを実践することはできる。
そういう基本を言ってるだけ。
仕事はＣ＋＋でやってるよ。変な煽り入れないでくれ。
0774デフォルトの名無しさん
NGNG0775748
NGNGちょっと書き間違えた。
>あるＯＯＰＬや、非ＯＯＰなプログラミング言語でも
>ＯＯＰを実践することはできる。
以下のように訂正。
>異なったＯＯＰのモデルに基づくＯＯＰＬや、
>非ＯＯＰなプログラミング言語でも
>ＯＯＰを実践することはできる。
0776デフォルトの名無しさん
NGNG0777デフォルトの名無しさん
NGNGいや、そうじゃなくて,
昔からプログラマが自分で発見していたような技術をＯＯＰ出てから
「教えられて」初めて知って「時代に付いて行けないの何の」と
興奮して、「新知識」を振りかざしてる奴が滑稽だっつうの。
ＯＯので述べられているような事は自分で発見していて当然。
教えられて初めて判るような人は才能ないんじゃない？つう事だ。
0778デフォルトの名無しさん
NGNGＯＯＰＬしか知らない人達には、理解しづらい話だと思う。
この世代の人達って、実務でまともな設計経験も無いと思うし。
0779748
NGNGＯＯＰと個々別々のＯＯＰＬを切り離して考えるべき、
というのは電波な意見なわけ？
そこんところ納得できないんだよ～。
0780デフォルトの名無しさん
NGNG俺は今日初めて書いたんだよ。
0781デフォルトの名無しさん
NGNG>「教えられて」初めて知って「時代に付いて行けないの何の」と
>興奮して、「新知識」を振りかざしてる奴が滑稽だっつうの。
それに対して、自分も興奮して意見振りかざしてるんでわ？
スレと関係無い分、もっと醜いよ。
0782デフォルトの名無しさん
NGNG今ここには非OOPLでOOPできないなんて言っている奴は居ないのでは。
非OOPLで十分にOOPができるとする主張に異議があるのでは。
みんなそれは難しいと思っているのでは。
0783748
NGNGJava/ObjectPacal：多重継承なしのクラスベース。
C++：多重継承ありのクラスベース。
JavaScript：プロトタイプベース。
もしＣ＋＋しか知らなければ
多重継承ありでクラスあり＝ＯＯＰだと思うかもしれないけれど、
それはＣ＋＋に特有のＯＯＰのモデルであって、
他のＯＯＰＬでは通用しない。
こういう意味で、区別が必要だと言ってるの。
0784デフォルトの名無しさん
NGNG>というのは電波な意見なわけ？
別スレでやって下さい。ＯＯＰについてＯＯＰＬで説明してるスレなんで。
なぜＯＯＰＬで説明するかというと、動物-猿,犬,猫では現実味が無いという意見が出たから。
0786デフォルトの名無しさん
NGNG0787デフォルトの名無しさん
NGNG>それはＣ＋＋に特有のＯＯＰのモデルであって、
>他のＯＯＰＬでは通用しない。
>こういう意味で、区別が必要だと言ってるの。
がいしゅつです。クラスベースのoop対オブジェクトベースのoopのレスを参照して下さい。
0788デフォルトの名無しさん
NGNG俺は748じゃないが、勘違いしてるのはどっちか、読み返してみれば分かると思うが。
論点のすり替えは感心せんな。
0789748
NGNGこのスレで最初に「プロトタイプ」という単語使ったの実は俺。
ガイシュツなのにあんまり区別されてないなぁと思ったので出てきたの。
でもこれで引っ込みます。つか寝ます。
0790デフォルトの名無しさん
NGNGOOした事になるの？
0791デフォルトの名無しさん
NGNGボケは不要だっての。
0792デフォルトの名無しさん
NGNG0793デフォルトの名無しさん
NGNGうむ、OOを知らない人には信じられないかもしれないけれど、
例えばファイルハンドルはオブジェクトへの参照だ。
fopenはファイルオブジェクトのコンストラクタで、fcloseはデストラクタ。
ファイルハンドルを引数に取る標準関数は全てメンバ変数。
ファイルハンドルの先がファイルなのかデバイスなのか隠蔽されているし、
シークポインタも隠蔽されていて、ファイルハンドルに内緒で勝手に変更することは
できず、fseekメソッドでメッセージを送らないといけない。
0794デフォルトの名無しさん
NGNG簡単に高機能が実現できるが、提供されていない機能の実現には限界がある。
ソースでも公開してくれれば、話は別だが。
0795デフォルトの名無しさん
NGNG例えばファイル操作。
最下層ではopenだのcloseだのとよりハード寄りのコードを書くけど
上位層ではこういったファイル操作を意識せずファイル名を与えるだけで
読み書きできるように作る。
（何時までもファイル操作の度にopen,closeやっていたとしたらそいつは
プログラマーの才能無し）
上位層は下位層でやっているような手続きを全く意識させない作りにするのが
正しい設計である。
ＯＯＰＬの継承は下位層の手続きを丸ごと持ってくるというアホな発明なんで
全然意味無し。
アホＰＧを量産するだけ。
0796793
NGNG↓
ファイルハンドルを引数に取る標準関数は全てメンバ「関数」。
0797デフォルトの名無しさん
NGNG0798デフォルトの名無しさん
NGNG恥ずかしいから出てこなくていいよ。
0799デフォルトの名無しさん
NGNGいちおうコンポーネント自作できるぞ。
継承して機能拡張もある程度はできる。
ソースが公開されるならばいいのか。
0800デフォルトの名無しさん
NGNG0801デフォルトの名無しさん
NGNGたとえば君が、何らかのエディットコンポーネントで、
エディタプログラムを作るとしよう。
おそらくコンポーネントの機能拡張の限界に、
すぐにぶち当たるだろう。
0802デフォルトの名無しさん
NGNGそれは、File クラスの実装レイヤーの上に
インタプリタみたいなもののレイヤーを載せて、
最上層のレイヤーでは ReadTextFromFile( "filename.txt") ;
みたいな書き方をするべきだという話？
0803デフォルトの名無しさん
NGNGやっぱりわかってない・・・。
0804800
NGNG中途半端に理解して勉強を止めると>>795みたいになってしまうんだろうな。
私も気をつけよう。
0805デフォルトの名無しさん
NGNG根本から理解できてないね。
半端も何も理解度０％では？
0806デフォルトの名無しさん
NGNG0808800
NGNGプログラマ板も大したことはありません。
0809デフォルトの名無しさん
NGNGそしてここはプログラマ板ではない。
0810800
NGNGだからといってオブジェクト指向の新しい言語をつくるわけでもなし。
ただオブジェクト指向の枠組みを無視するアホと押し合いしているだけ。
コンポーネント指向は融通が利かなくてもそこは重箱の隅
コンポーネントを組み合わせて生産的になったほうがいいのでは？
0811デフォルトの名無しさん
NGNG厨君は勘違いしてるようだけどＯＯはＣより古い技術なんだよ
実はＣはＯＯの影響を受けている。面白いから本探して読んでみてね
0812デフォルトの名無しさん
NGNGＯＯについてもそうだが、欠点を指摘すると、
すぐ全否定者扱いしてくる奴がいる。（わざとか？）
大抵の物には、利点と欠点がある。
0813デフォルトの名無しさん
NGNGあまり評判良くないみたいね。
0814800
NGNG新しい言語を作る人ならば
欠点をついたからにはそれを直そうとする。
しかしそうでないならば、蟻の一穴から全否定を狙っている。
もしくは欠点をついて喜んでいるだけのひねくれ者です。
0815デフォルトの名無しさん
NGNG0816デフォルトの名無しさん
NGNG話にもならんな。
俺はコンポーネント指向は、簡単に高機能が実現できると、初めから言っている。
欠点を認めないなら、盲目的な信者だ。
0817800
NGNG欠点を認めた上でそれは重箱の隅といっているのです。
機能拡張ができずどうしても必要なものは
コンポーネントを自作すればいい。
それはオブジェクトを自作するのと労力は変わらない。
0818デフォルトの名無しさん
NGNG> コンポーネントを自作すればいい。
> それはオブジェクトを自作するのと労力は変わらない。
禿しく胴衣。
0820デフォルトの名無しさん
NGNG結局、欠点を指摘したら、全否定者扱いされて当然って意見だろ。
やっぱり、話しにならん。
0821デフォルトの名無しさん
NGNG同意も何も、それしかないだろ。
0822800
NGNG0823デフォルトの名無しさん
NGNG最後にして最上の技術ならば問題ないんでしょうけれどね。
そうでない限りは、次に出てくる技術によって解決されるだろう
何らかの問題を抱えているはずです。
僕は現状のオブジェクト指向やオブジェクト指向プログラミング言語には
建設的なダメだしをすべきところが沢山あると思います。
皆さんは、オブジェクト指向は至高にして最後の技術だと思われますか：）？
0825デフォルトの名無しさん
NGNG0826デフォルトの名無しさん
NGNG> コンポーネントを自作すればいい。
の方じゃなくて、
> それはオブジェクトを自作するのと労力は変わらない。
の方に要旨があるって事かな？
0828デフォルトの名無しさん
NGNGmix-inぐらいなら、多重継承が出来る言語なら実現できるよ。
自分でやる分にはこれで問題ないんだけどねー。
0829デフォルトの名無しさん
NGNGどういうアイディアなの？
0831デフォルトの名無しさん
NGNG欠点がよく理解していないためにそう見えるとしたら
やっぱり荒れるね
理解度は人さまざまなものだし
0832デフォルトの名無しさん
NGNGオブジェクト指向で提唱されてる技術を使うのが非常に厳しくなって
くるじゃん。
分析設計の方法を適用するのが難しいし、オブジェクト指向的なこと
をC言語でやるのも厳しいし、リファクタリングの方法も限られてくる。
そこまで不便な思いをしてオブジェクト指向を使わないことにする
気も起きない。ＯＯさえ導入すれば楽になる。
ＯＯ否定してる人をみると「そんな自ら厳しい道を選ばんでも・・・」と思う。
0833825
NGNGデフォルトではメンバ変数がサブクラスから見えなくなる「mix-in継承」って
構文があってもいいかなと。
0834デフォルトの名無しさん
NGNGはぁ？なんでそれがmix-inなの？
0835デフォルトの名無しさん
NGNG部品(mix-inクラス)＋本体（一つまで）→ 新しい本体
というパターンしか許さないってやつでしょ？
0836デフォルトの名無しさん
NGNGＯＯ否定してる人ってのは、ＯＯを全肯定しない人の事じゃないのか？
だとしたら、俺も含まれるな。
0837825
NGNG普通に実装継承するクラスとmix-inするクラスを構文を見た時に
わかるようにしてあれば見やすいかナット。
0838デフォルトの名無しさん
NGNG全否定とか部分否定とかじゃなくて、ＯＯを使わない人のこと。
0839デフォルトの名無しさん
NGNGなるほど。それは言えるね。
今のところコメントを使うという手ぐらいしかないかな。
0840825
NGNGで、単に多重継承するとメンバ変数の名前がぶつかったりするのがイヤ～
なので、mix-inするクラスに関してはメンバ変数へのアクセスを自動的に
制限してくれたらええのかも、と思いつきでいってみました。スマソ。
0841デフォルトの名無しさん
NGNG現実問題、ＯＯの全ての概念を使わないのは、不可能なんじゃないか？
0842デフォルトの名無しさん
NGNGそんな極端な話じゃない。
0843デフォルトの名無しさん
NGNGは必然的に使うことになる。
それらを全部使わないとＯＯ出来ない場合が出てくるからね。
そういう主要概念のレベルではそれらが全部合わさってＯＯでしょう。
確かに継承は、それと同等のことを別の方法でやる言語も存在するけど、結局
同等のことをやっている。
0844デフォルトの名無しさん
NGNG>>843
よく分からんが、ＯＯを使わない人（ＯＯ否定の人）の定義は、
継承・多態・クラスを全て使わない人って事で良いのか？
0845デフォルトの名無しさん
NGNGいや、だから、それら主要概念を一部でも使わない人。
0846デフォルトの名無しさん
NGNG継承・多態・クラス・その他主要概念の、
１つでも使わない人って事で良いのか？
0847デフォルトの名無しさん
NGNGクラスと同じようなことをクラスの無い言語でやってる人とか。
0848デフォルトの名無しさん
NGNGだからそうだって･･･
0849デフォルトの名無しさん
NGNG俺は多重継承が嫌いだが、俺はＯＯ否定者か？
0850デフォルトの名無しさん
NGNG違う。君重箱のすみつつき好きだね。
0851デフォルトの名無しさん
NGNGいや、俺はまじめだ。
> 全否定とか部分否定とかじゃなくて、ＯＯを使わない人のこと。
> いや、だから、それら主要概念を一部でも使わない人。
いろいろ個人で基準が違うようで、マジで良くわからん。
0852デフォルトの名無しさん
NGNGていうか、ＯＯ使う人と使わない人っていったら大体わかるでしょ。
それで良いじゃん。何でこだわってるの？
0853デフォルトの名無しさん
NGNGそういう人は意見の対象から除くってことだね。
0854デフォルトの名無しさん
NGNG俺はよくＯＯ否定者扱いされるが、今の基準じゃ、ＯＯ否定者じゃないぞ。
0855デフォルトの名無しさん
NGNGじゃあグレーゾーンですね。良かったね。
0856デフォルトの名無しさん
NGNG0857デフォルトの名無しさん
NGNG誰がどこでお前のこと否定者扱いしたのかもわからないのに、
勝手にぐちんなよ。（ｗ
否定者扱いされるんだったら多重継承以外にも嫌いなものが
あるんじゃないのか？
0858デフォルトの名無しさん
NGNG君の基準では、何が嫌いだと否定者扱いするんだい？
0859デフォルトの名無しさん
NGNG0860とおりすがり
NGNGタイプのプログラマに出会って嫌気がさし、「OO嫌い」になったのでは
なかろか？
マ板向きのテーマかな？
0862デフォルトの名無しさん
NGNGsage
0863デフォルトの名無しさん
NGNG俺をＯＯ嫌い（ＯＯ否定者）にするなよ。
>>861
アホだのＯＯ否定者だの、話と関係ない事で因縁つけてくる奴がいるから、
ＯＯの技術的な問題点一つ、まともに議論できないんだよ。
0864とおりすがり
NGNG>ＯＯの技術的な問題点
↑ここに話題を戻してみては。
0865デフォルトの名無しさん
NGNG話と関係の無いこと言い出したのはお前だろ。
せっかくOOの話をしてるところに、突然否定者の基準とは何だって
わけのわからん質問しやがって。何の意図があるのかちゃんと言えよ。
回りくどいんだよ。
OO否定者だと因縁つけられるのが気に入らなかったなら、
質問してるひまにはじめからそう言えよ。
0866デフォルトの名無しさん
NGNGきちんとした根拠があるなら、無下に非難も出来まい。
だから先に、基準を聞いたんだよ。
出かける準備があるから、これ以上書き込んでも返事は夜だぞ。
0867デフォルトの名無しさん
NGNGだったら、「きちんとした根拠があるならいいが、否定者と
決め付けるのはだめだ」ってはじめから言えよ。
お前逝っていいよ。
0868デフォルトの名無しさん
NGNG何を批判してたんだろう・・・？？
0869デフォルトの名無しさん
NGNG確かに、まわりくどすぎ。
0870デフォルトの名無しさん
NGNG詳しい情報求む
なんかおもしろそう
関数ポインタって落ちじゃないよね?
でも、基本的にはSystem370とかを意識してたんじゃなかったけ?
ファイルアクセスに関していってる人は
普通に実行時ポリモーフィズムがわかってないみたいだけど...
実行時ポリモーフィズムってどの程度の人が使いこなしてるのか知りたいね
実行時ポリモーフィズムを使う手段として継承は便利だよ
だからOOL好きだな
特にJAVAはいいね
多重継承はうまく使うとすごく便利
でも、普通に使うと終ってる
まあ、JAVAのインターフェースと単一継承みたいな感じでしか
設計しなくなってしまったけど....
たくさん覚えないと使えないC++
たくさん知ってないと使いこなせないJAVA(ライブラリの話じゃないですよ)
皆さんはどっち派ですか?
0871デフォルトの名無しさん
NGNGどうやって対処するんでしょうか？
0873デフォルトの名無しさん
NGNGこれをどういった意味で使ってるのか良く分からないけど
短絡的に言えばインターフェース
C++で言えば、
純粋仮想関数しかないクラスみたいなもので
いくつでもインプリメント(継承と同じ)できる
でも、多重継承のためのインターフェースと考えて設計することはない
名前通りの概念でとらえるのが普通かな
JAVAの継承はポリモーフィズムのウエイトが大きいって事なのかな?
0874デフォルトの名無しさん
NGNG>JAVAの継承はポリモーフィズムのウエイトが大きいって事なのかな?
禿同！
javaでは、継承も隠蔽も、多態を実現するための手段に思えてくるくらい、
多態しないでプログラムってできない気がする。そこがいい。
0875デフォルトの名無しさん
NGNGあほか、話の流れを見てないのか！
ＯＯＰＬの話だよ。
糞信者が！ レッテル貼り、揚げ足取りしかできんのか？
0876デフォルトの名無しさん
NGNGいや、基本的に下位層の実装をそのまま持ってくるのを
継承って言わないか？
インターフェイスの継承もあるが。
OOPLの問題か？
それ以前に、>>795は、継承がアホだといってるが
何がアホなのか良くわからん。
0877875
NGNG>>804,805,807は open～close並べてるクチだなｗ
0878デフォルトの名無しさん
NGNG継承やクラスはＯＯとは関係無い。
0879デフォルトの名無しさん
NGNG常に上位構造の構築を意識しながら書く奴と
ライブラリ層をベタベタ並べてるだけの奴。
後者に構造の話をしても大抵通じない。
そういうのがＯＯＰＬ覚えると只のクラスマニアになるだけ。
上位構造は一般に複数の構造の上位の構造を持っているもの。
0880デフォルトの名無しさん
NGNG>多態しないでプログラムってできない気がする。そこがいい。
だけど、javaプログラマーってポリモーフィズム使えない人多い（笑）
多態ってほんとに便利だと思う
Javaのストリームに感激
SWINGは作りこみ方がマニアックだと思う
そう考えると、マイクロソフトって人件費けちってた以外は
考えられない
0881デフォルトの名無しさん
NGNG0882デフォルトの名無しさん
NGNG他人にはＪａｖａを薦めておきながら自分は逃げる準備をしてたり。
0883デフォルトの名無しさん
NGNG自分もOOPL覚えたての頃はクラスライブラリをべたべたと利用する
だけで、いわゆる「open~closeを並べる」タイプだったです。
でもしばらくしてからプログラムしている内容をオブジェクトに切り
分けて、そのオブジェクト間のメッセージのやりとりという観点から
自前でクラス階層を構築する、という作業をしてみると以前よりずっと
実際の問題に近いレベルでプログラムを構造化（？）できるなあ、と
感じるようになりました。
openだとかcloseだとかは自分のつくったクラスのもっと具体的な名前
のメソッドのなかに隠されて外からはすぐに見えなくなると思うのですが。
ですから、>>795の
> ＯＯＰＬの継承は下位層の手続きを丸ごと持ってくるというアホな発明
という感想はそもそも継承の使い方を間違って理解している気がします。
0884デフォルトの名無しさん
NGNG継承では、下位層という風には考えないよね、普通。逆に上位でしょ。
つまり、「隠蔽したい下位層」を継承するという考え方ではない。
隠蔽したい実装はサブクラスで行う。上位では、共通したインターフェイス
を考える、ということ。
0885デフォルトの名無しさん
NGNG0886デフォルトの名無しさん
NGNG0887デフォルトの名無しさん
NGNG他人のつくったクラスライブラリのインターフェースが不十分で
言語的にはインターフェース継承、多重継承ができず、単一継承
のみの場合には、「インターフェースの奴隷」と呼んでいい状態
が発生するような気もしますが、少なくともインターフェース継
承ができれば、なんぼでも回避する方策があるよーな気がします。
0888デフォルトの名無しさん
NGNG>他人のつくったクラスライブラリのインターフェースが不十分
その場合、インターフェイスを変換(および追加)するクラスを
用意してやれぱいいんじゃない。単一継承でもできるとおもう
けど。
0889デフォルトの名無しさん
NGNGどういうクラスを作るものなの?
DBのテーブル = クラス、フィールド = プロパティって感じでいいのかな。
となると、フィールドをプロパティに代入するのはどのクラスが担当するの?
そのクラスにはselectメソッドやらupdateメソッドやらつければいいのかしらん。
0890デフォルトの名無しさん
NGNGでも任意のクラスを扱うんだったらAsStringみたいに
一つの文字列(内部はXML見たいなのにして)で扱うとか。
0891デフォルトの名無しさん
NGNG0892889
NGNGテーブル = コレクションクラス?
0893デフォルトの名無しさん
NGNGデザパタにあったね
アダプターだっけ？
0894デフォルトの名無しさん
NGNG結構鋭い指摘かも。
最上位がObjectクラスで最下位がアプリケーションのクラス？
ＯＯＰは奴隷用言語？
0895デフォルトの名無しさん
NGNGここらへんがＯＯＰの欠点かもね。
ＤＱＮＰＧ大量生産の予感・・・。
0896>
NGNG0897デフォルトの名無しさん
NGNG多分、君のプログラムの設計は、ハードに密着したところからスタートするんだろうね。
でも、プログラムの目的を見失わずに、最下位から這い登ってくるのって、大変だろうね。
0898デフォルトの名無しさん
NGNGいや、トップダウンだよ？
0899デフォルトの名無しさん
NGNGコンポーネントの責務とインタフェースの仕様さえしっかりしていれば、
どんな言語を使おうがプログラミングはなんとでもなる。
つーか、それができていない仕様で仕事まわされて泣く事が多い。
オブジェクト指向（つーかクラス図）は責務やインタフェースが分析・設計とも
ビジュアル化しやすくてよいと思ってる。
クラス図読める人が相手なら話もしやすいし。
0900デフォルトの名無しさん
NGNG￣￣￣￣￣∨￣￣￣ (´´
∧∧ ） (´⌒(´
⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
￣￣ (´⌒(´⌒;;
ｽﾞｻﾞｰｰｰｰｰｯ
0901デフォルトの名無しさん
NGNG擦れたテロよ
0902530
NGNGC++ つかってるときは多重継承きらい。
0903デフォルトの名無しさん
NGNG>C++ つかってるときは多重継承きらい。
両方知ってるぐらいの腕なら多重継承使っても問題なかろう。ど
ーとでも組めるのがC++だからね。
俺はインターフェースをくっ付けるって意味で純粋仮想関数一個だ
け持たせたクラスは割と使うな。C++屋は再利用が継承の主目的だ
と思ってる奴も多いから多重継承難しいと思ってる奴も多いけどな。
0904デフォルトの名無しさん
NGNG純粋仮想関数だけの抽象クラスを使ったオブザーバパターンは便利っす。
とりあえずこれ覚えただけでも設計しやすくなった。
0905デフォルトの名無しさん
NGNG0906デフォルトの名無しさん
NGNG禿げ同!
0907デフォルトの名無しさん
NGNGなんでそんなに難しく考えるんでしょか？（ｗ
0908デフォルトの名無しさん
NGNG難しいのではなく面倒なだけ。
新しい技術を学習・試行錯誤して習得するコストをかけるのが嫌なだけ。
0909デフォルトの名無しさん
NGNG0910デフォルトの名無しさん
NGNG>>709
0911デフォルトの名無しさん
NGNG私の具体的アンケートに、回答してみてくれませんか？
ＭＦＣでは、かなりのクラスがＣＯｂｊｅｃｔから派生していますが、これを好ましいと思いますか？
もし好ましくないのなら、貴方ならどうやって、各クラスにシリアライズをサポートしますか？
0912デフォルトの名無しさん
NGNGかなりのクラスがCObjectから派生すると何か問題でもあるの？
0913デフォルトの名無しさん
NGNG貴方の意見を聞かせてください。
0914デフォルトの名無しさん
NGNGよってCObjectから派生する・しないに関わらずC++/MFCは糞です。
0915デフォルトの名無しさん
NGNG有用な意見、ありがとうございます。
参考になりました。
0916デフォルトの名無しさん
NGNG言語は小さい方が良い。
0917デフォルトの名無しさん
NGNGﾊｧ？よくあんな理由で納得できるな。
0918デフォルトの名無しさん
NGNG納得ではありません。
１つの意見として、参考になったと言ったのです。
0919デフォルトの名無しさん
NGNG＞否定派の方々
0920デフォルトの名無しさん
NGNGということはC++は間違いなく糞です。
0921デフォルトの名無しさん
NGNG今さら間違いなくなんて逝ってるﾄﾞｷｭﾝをさらしｱｹﾞ
0922デフォルトの名無しさん
NGNGC++の話題は完全にスレ違いです。
直ちにここから出て行きなさい。
0923デフォルトの名無しさん
NGNG914ではないが、多重継承をサポートしない言語の話でないか？
0924デフォルトの名無しさん
NGNG純粋にＯＯＰの技術論ですよ。
0925デフォルトの名無しさん
NGNGとりあえず、CObjectのポインタで保持しておけって言うプロトタイピング
的なコーディングが出来るから。
それに、多態生も実現できる。
0926デフォルトの名無しさん
NGNGダメだと言ってる人はどんな理由でダメだと言ってるの？
0927デフォルトの名無しさん
NGNG0928デフォルトの名無しさん
NGNGを強制しないところがC++の良いところでもあり、オブジェ
クト志向言語としての致命的な欠陥でもある。
0929デフォルトの名無しさん
NGNGstroustrup曰く、オブジェクト指向'も'サポートする言語か。
0930デフォルトの名無しさん
NGNGいくつか聞いていますが、私の意見ではないので、
それらの意見を持った人達の発言を、待ちたいと思います。
0931デフォルトの名無しさん
NGNG結論になると思います。
0932デフォルトの名無しさん
NGNG0933デフォルトの名無しさん
NGNGでもこれがあっても損は無い…かな？
ダウンキャストは必要最低限に抑えたいと思っているので､
とりあえずCObjectのポインタでという組み方はちょっと。
0934デフォルトの名無しさん
NGNG伝搬で。
0935デフォルトの名無しさん
NGNG0936デフォルトの名無しさん
NGNG0937デフォルトの名無しさん
NGNG確かにstl使えばすむような気がするけど
stlでスタックってできたっけ？
stl使ったこと無いからよくわからん
テンプレートクラスとか使えばできるのかな・・・
0938デフォルトの名無しさん
NGNGあるインターフェースの背後に置く実体を多様化させる、という観点で捉えると
次の三つは同類でありつつ微妙に違うという話になる気がする。
継承を使った多態＝メソッドのセット単位での適合をコンパイル時に要求する。
ジェネリック型＝メソッド単位での適合をコンパイル時に要求する。
型なし言語での多態＝メソッド単位での適合を実行時に要求する。
だから何、とか言われても困るけど、こんな感じじゃない？
0939デフォルトの名無しさん
NGNG各クラスの共通部分が上位クラスになり、どんどん多段階層になる。
これがＯＯ的に当然だとするならば、ＯＯに則したプログラムは、
階層の深い、わかりにくい物となる気がするが？
0940902
NGNG>両方知ってるぐらいの腕なら使っても問題なかろう。
>どーとでも組めるのがC++だからね。
多重継承するとき
C++ は安心して実装継承や菱形継承ができない。
多重継承派の人がいてうれしい。多重継承派はよく嫌われる。
0941デフォルトの名無しさん
NGNG0942デフォルトの名無しさん
NGNG>これがＯＯ的に当然だとするならば、ＯＯに則したプログラムは、
>階層の深い、わかりにくい物となる気がするが？
実際Smalltalkのクラスライブラリの初期の敷居の高さは割と
言われてることだと思うし、MFCなんかもある程度基底クラス
の役割が見えてこないとさっぱ理解できんだろう。基底クラス
が膨らめば膨らむほどこの敷居は高くなるが、一度学習を終え
てしまえば皆が同じ世界を共有するので再利用に非常に有効だ
しコードの可読性も高まるしで、かなりおいしいメリットもあ
る。その取捨選択は言語の設計者のポリシー次第で、C++はそ
の辺全部外注しちまったってとこだろうな。
0943デフォルトの名無しさん
NGNG0944デフォルトの名無しさん
NGNGうーんこう思ってる人多いなあ……
0945デフォルトの名無しさん
NGNG数百万ステップの業務処理部分でも、学習さえしてしまえば、
可読性が高く修正等が容易かな？
0946デフォルトの名無しさん
NGNGどんな業務処理やねん。
0947デフォルトの名無しさん
NGNG某官庁系のシステムだけど、OS/2のサブシステム1つでも、
百万ステップ超えてるよ。
0948デフォルトの名無しさん
NGNGステップあたりいくらで受注してるんだろうね。
0949デフォルトの名無しさん
NGNG賄賂渡して水増しソースとお金交換とかやってるから。
0950IBM
NGNGhttp://www3.nikkeibp.co.jp/WAT2/971212/971212trein01.html
0951デフォルトの名無しさん
NGNG涛ﾆ立性が高いのｂﾅ、他のｸﾗｽとの多重継承もしやすい。
(只の文字列にしては重すぎるｹﾄﾞね)
0952デフォルトの名無しさん
NGNGそんなのわざわざ使わなくたってプログラムは組めます
0953>952
NGNG0954デフォルトの名無しさん
NGNG>継承を使った多態＝メソッドのセット単位での適合をコンパイル時に要求する
ってどういう意味でしょうか？
セット単位っていうのがわからないのですが
ちなみに､継承を使った場合C++,JAVAは実行時ですけど
時間があれば残り２つに関しても説明していただけるとうれしいです
0955デフォルトの名無しさん
NGNGもうちょっと詳しく説明してくれ。
特に多重継承がどのようなバグを引き起こすのか
解説ｷﾎﾞﾝ。
0956デフォルトの名無しさん
NGNG(強烈じゃなきゃやめとけって事。)
0957デフォルトの名無しさん
NGNG0958デフォルトの名無しさん
NGNGなんでただ、objectじゃいかんの？
0959デフォルトの名無しさん
NGNGそれはそれでいやなんでわ？
0960デフォルトの名無しさん
NGNGMFCのクラスの命名規則がC+頭大文字の単語って決まってるから。
0961デフォルトの名無しさん
NGNG古いけどええ記事だな
オブジェクト指向で大規模な開発だと参加PG全員を一定レベル
以上に教育しておく事が必要だね
0962デフォルトの名無しさん
NGNG後でおつりももらえていい感じかも
0963デフォルトの名無しさん
NGNGあんた、現実が見えてないよ
0964デフォルトの名無しさん
NGNG0965デフォルトの名無しさん
NGNGＯＯ礼賛の提灯記事や書籍を真に受けて「勉強」しちゃった人は現実など関係無いのです。
0966デフォルトの名無しさん
NGNG0967デフォルトの名無しさん
NGNGOOが絵空ごとに見えるんだろうな。
すべてをOOで設計・解決するわけじゃあないが
おいしいとこは、しっかりと使わせてもらってるよ。
0968デフォルトの名無しさん
NGNG0969963
NGNGあれ読んで、ＰＧの教育に問題があるなんて、
現実が見えてない。
どう考えても、もっと重要な問題があるだろ。
>>962
研修二日で、何か変わると思うのか？
明らかに現実を知らない。
>>964
俺の現実って何だ？
煽りでしか反論できない低脳。
>>965
俺はＯＯ否定派じゃない。
>>966
結論のない、無意味な書き込みやめろ。
荒れる理由は、964-967みたいなのがいるからだ。
>>967
俺の現場って何だ？
煽りでしか反論できない低脳。
0970sage
NGNG俺も何度か失敗したケースに立ち会ったが、
どうすればうまくいくのか、
何をしないのがうまくいくのか、
調べて、次にイカしたよ。
そういうノウハウをためてはじめて使えるもんだと思うがね。
たしかに、理論に夢中になってる連中を見ると、
現実をミロとも言いたくなる。
ミロ飲みてえな、久しぶりに。。
0971デフォルトの名無しさん
NGNGOO不要だっていってる人の
仕事のレベルが違うのでは？？
名前のところに年収でも書いてくれれば言いと思うけど
0972963
NGNG自分の発言に責任を持てない厨房じゃないなら、まずおまえが書け。
0973デフォルトの名無しさん
NGNG0974デフォルトの名無しさん
NGNG0975デフォルトの名無しさん
NGNG> >>966
> 結論のない、無意味な書き込みやめろ。
> 荒れる理由は、964-967みたいなのがいるからだ。
何故964-967みたいなのがいるのか？実は…
0976963
NGNG出たー。
低脳の極み。
出ると思ったんだよなー。
おまえみたいな論理のないやつは、プログラマやめろ。
むいてないんだよ。
0977デフォルトの名無しさん
NGNG多重継承できる言語だとアダプタパターソが楽だよ。
0978デフォルトの名無しさん
NGNG0979デフォルトの名無しさん
NGNGたのに。
0981デフォルトの名無しさん
NGNG基地を排除できないものか
0982デフォルトの名無しさん
NGNGモデルの話だから人によって流儀が違うことがある。
また、モデリングなんて必要ないという暴論も用意に口に出来る。
# CPUが必要ない、なんてことはありえない。
対象ずばりそのものじゃなくて射影(の流儀)について議論すると揉めることが多い。
例えば政治がその代表例。
ってな話がOOと関係あるかどうかでさえ揉めるだろう。(俺はあると思うのだが…)
0983デフォルトの名無しさん
NGNGCObjectの話題を今読み返しましたけど、なんか、やっぱり
つまんない話題ですね。
MFCがOOのすべてでもなかろに。
0984デフォルトの名無しさん
NGNG具体的個別事例で議論すべきでは？
0985デフォルトの名無しさん
NGNG0986デフォルトの名無しさん
NGNG0987デフォルトの名無しさん
NGNGわしもMFC嫌いだから、興味ない。
非抽象的題材なのは評価できるが、もっと別のネタないの？
0988デフォルトの名無しさん
NGNGスレ立てお願い。
おれがやろうとすると、何故かスレッド立てすぎです・・といわれる。
全然立ててないのにさ！
0989デフォルトの名無しさん
NGNG0990デフォルトの名無しさん
NGNG無駄な上位概念を作るのは、悪いＯＯの例です。
0991立てたよ
NGNGhttp://piza2.2ch.net/test/read.cgi?bbs=tech&key=1002523282
0992デフォルトの名無しさん
NGNG988が欲しかったスレとは違うのでは？？？
0993デフォルトの名無しさん
NGNG0994デフォルトの名無しさん
NGNG0995デフォルトの名無しさん
NGNGJavaベースにObjectクラスがありますが・・・
0996デフォルトの名無しさん
NGNG0997983
NGNGシリアライズのインターフェースも大抵Objectが持っている。
そこを「無駄な上位概念」とかわけわからんこという奴は、
C++のMFCとSTLだけでOOを語ろうとおもてるんではないかと
考えたわけで。
アホか、つまらんことぬかすな、と。
0998デフォルトの名無しさん
NGNG偏見の固まりだな。
0999デフォルトの名無しさん
NGNG>てかC++以外のOOPLは大抵共通のObject基底クラスを持ってるでしょう？
だったらいいじゃん
なぜそんなに否定的なの
1000デフォルトの名無しさん
NGNG￣￣￣￣￣∨￣￣￣ (´´
∧∧ ） (´⌒(´
⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
￣￣ (´⌒(´⌒;;
ｽﾞｻﾞｰｰｰｰｰｯ
1001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。