オブジェクト指向　Part2

・オブジェクト指向についての疑問、応答
・OOP言語、UML、分散オブジェクト、デザインパターン等

などなど、オブジェクト指向についての「技術的な」スレッド。

前スレ
オブジェクト指向スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001275287

オブジェクト指向
http://www.google.com/search?sourceid=navclient&q=%83I%83u%83W%83F%83N%83g%8Ew%8C%FC

デザインパターン
http://www.google.com/search?sourceid=navclient&q=%83f%83U%83C%83%93%83p%83%5E%81%5B%83%93

eXtreme Programming
http://www.google.com/search?hl=ja&q=extreme+programming&btnG=Google+%8C%9F%8D%F5&lr=lang_ja

リファクタリング
http://www.google.com/search?hl=ja&q=%83%8A%83t%83@%83N%83%5E%83%8A%83%93%83O&lr=

早すぎ。

ここだ！２番ゲットォォｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

>>1
死ねよ

は！名前を変えるのを忘れてしまった…鬱

>OOスレは必ず揉めます。それは何故か？実は…
答えが決まらん抽象論になるからだろ。Ａにとって正解でもＢにとって
間違いって問題が多い。多重継承なんか典型じゃないか？どの言語を使
ってるか、どのライブラリを使ってるか、一緒に開発してるやつのレベ
ルとかで使うかどうかは変えるだろ？

>>4-5
そのネタもう秋田

>>6
確かにそうですよね
ところで、みなさんはどんなオブジェクト思考言語をお使いですか？
私はプログラマーではないので、JAVAとC++ぐらいしか使わないのですが

>>8
自作言語

>>8
おれもLISP系の自作言語

日本語ＯＯＰＬコンパイラ？開発中
プリコンパイルでＣ＋＋に
変換するだけだが・・・

>>8
マイナーすぎてとても言えません‥‥。

あーう、自作言語オタが一杯・・・。

エラーメッセージちゃんと出るのですか？

構文解析や構造解析ちゃんとやってエラー出力するコンパイラと
ろくにエラー判定しないコンパイラは月とすっぽんぐらい違います。
つまらん言語自作してオナニーするのは止めましょう。

>>14
やってるけど・・・。
まじめにエラー出力しないと自分で使う気にもならないし・・・。

解決したい問題に特化した言語を作るのは間違いではないぞ。

C++(かjava)とlispが有れば大体足りると思うがな。

14はつまらん人間

XMLで新しい言語作ってみた

新しいDTDを作った
とどうちがうの？それ.

オブジェクト指向の次は何だろう？
エージェント指向は重そうだし、
コンポーネント指向なのかな。

コンポーネントでビジュアルに設計とか。

Smalltkの時代

九大病院の件は片付いたのか？>Smalltalk

<>　</>　が無いのが違う。

オブジェクト指向の次とか言う前に､
オブジェクト指向が使えるように教育するほうが先。

オブジェクト指向の次とか言ってるやつは
大抵オブジェクト指向を分かっていない

OOは十年前から極めていていますが何か？

２０＝１４

エージェント指向はオブジェクト指向と同列に扱ってもらいたいようだが、
あれはオブジェクト同士の関連の一形態に過ぎない。

オブジェクト指向を批判する奴はＯＯを理解できない馬鹿。
そんな奴はプログラマー辞めるべき。

Smalltalkってよく聞きますが、
もう過去の物ですか？

>>30
行き過ぎたオブジェクト指向。
それはもう、すべてがめんどくさいほど

実際に自分の関わってる開発にOOを適用して苦労した経験も持たずに
礼賛だけするのはダメ。

妄想で仮想敵でっち上げて批判しないよーに

OOで仕事して、バランスの取れた責任分担に腐心して、
クラスの名前を考えるだけで何日も悩み、
それでもコンスタントに月間0.5MBのソースが書けることに喜びを見出し、
そしてまた後々のメンテのしやすさに感謝している漏れは礼賛しちゃいけませんか。

>>34
>クラスの名前を考えるだけで何日も悩み、
俺がプロジェクトリーダーならクビにする

>>35
納期は守ってるよー。

>>36
クラスの名前を考えるだけで、何日も悩んでるのに？
嘘つけ。

>>37
嘘じゃないよー。
たまにはそういうこともあるという話。

>>38
まあ、そこまでいうなら、話半分信じてやろう

>>39
なんにも嘘ついてないのに・・・。泣くぞ（／＿；）

いやべつに敵を作ってるわけじゃないってばよ。
おれ、OOP好きだし。

ソースをバイト数で言われても困るんだけど、
蓄積したコードに対するメンテが少なければ少ないほど
よいコードだと思うんだよな。

ただそれがOOPに基づいた所以なのか
OOPでなくてもメンテ性の高いコードが書けるのか、
過去を振り返ってみたとき、
なんか結局どっちでも同じような気がしてくるんだよね。

どちらでも同じ品質でモノが書けるなら、
OOPをわざわざしらんでも、だれでもメンテできる
ふつうのコードの方が、よかったんじゃないかって考える。

え、OOPじゃなくてOOの話しをしてるって？

経験からいって、オーバーライドでメンテは不可能に近い。

漏れはハイソな仕事にゃありつけない市井のプログラマだから
OOPとかOOとか区別されてもピンとは来ないんだけどさ。
でも、クラス単位で考えるって絶対に楽。
関数単位での実装が前提だと過度に小回りを利かせようとして
ざくっと割り切った視点で考えられなくなっちゃいがちなんだよね。
OOだったら基本単位がクラス＝意味上のまとまりだから
プログラムの意味を自然と大切にしながら書けるのが気持ちいい。
もちろん、その中で意味のパターンみたいなものが見えてきて
こんな漏れにもそれなりのノウハウが蓄積できるのが嬉しい。
OOに感謝感謝。

ソースのバイト数って？

main(){
byte data=new byte[0x100000000];

なんか処理〜。
}

あ、ソースね
　寝る

>>43
ＯＯの最大の利点は、オブジェクトの独立性にある。この点は、実務でも十分な利
益が得られる。問題は継承まわり。

うぎょーん。なんか雑談スレになってる。
OOの有用性・啓蒙ネタはもういいよ。

継承はＯＯＰの話。
ＯＯＰ嫌い。

生産性をソースのバイト数でいうか、普通？
日曜プログラマじゃないのか？

>>47
こんなスレ作らんかったらよかったんや

>>1は責任とって割腹。

解りやすいように言ったんだろうね＞バイト数
正確に言うと進捗率。

>>49
プロが使う生産性の指標ってどんなものなんですか？

>>53
テスト項目をつぶした数、というのが最近のはやりかも。

>>53
俺んとこは、クラス数とステップ数

テストの時は、完了数／テストケース数

漏れ、43。
平均して、３ヶ月でソフト１本
年間４本のペースで作らされてるよー。
納期とソフトの規模が大体一定してるんで
目方で進み具合を量る癖がついた。
一本辺りソースのみで1.5MB、
リソース込みで2MB〜3MBになったら完成。
ちなみに漏れは在宅のパッケ屋。

>>46
ポインタを使いこなすにはメモリに対する正しい知識が必要なのと同じように､
継承を使いこなすには､デザパタを読んで理解できるくらいの理解が必要。
ポインタを使いこなすのも､継承を使いこなすのも､本人次第だろ。
批判する前に勉強しろよ。

業界標準みたいなものがあるのかと思ってました。
色々あるんですね。勉強になりました。
スレ違いな質問をしてしまってすいません。

勉強したよ。
低レベルプログラマーなら感動して使うだろうね。

>>58
うーん、もう聞き飽きたよ。

批判されると、相手の知識不足に問題をすり替えて、
優越感に浸って気分良いんだろうけど、言ってることは
非論理的な根性論なんだよね。

>>61
貴方が理解できていないようだから「知識を身に付ければ？」と
言われてるのに、「努力したくない」「理解できそうもない」から、
「知識不足だから勉強しろ　＝　根性論」にすりかえようとしている
ように思えてならない。
問題のすりかえをしているのは、どっちだ？

>>58
妄想君だねぇ
相手はデザパタ理解できない馬鹿ねぇ

>継承を使いこなすには､デザパタを読んで理解できるくらいの理解が必要。
ここに書き込むには、日本語が理解できるぐらいの理解が（ｗ）必要だよ

>>62
おまえ58だろ。
継承に問題があると聞いただけで、なんで理解できてないと分かる？
明らかに、問題をすり替えてるだろ。
言ってること理解できるか？

>>64
いや、ほんとに58じゃないんだけど。
継承に問題があるんじゃなくて
継承の使い方を知らないんじゃないの？

>>62

残念だけど、いってる事に根拠がないよ。妄想といわれてもしかたない・・

＞＞６５
継承の使い方を知らないんじゃないの？
明らかにもうそう
どこ書き込みでこう思ったの？？

>>67
いや、実はほとんど見てないんだわ。
単に俺は継承が便利ってだけ。
問題あるなら使わなければー？

そんなのほっとけよ。

それよりOOPやったことない人に、いかに短期間で
自分の設計を理解してもらうかで頭痛いんだから..

OOが出来てから20年以上経っているのに開発現場でデファクトスタンダードを
とれていない事実に不信感を抱くプログラマが多いのだと思うね。

なんか、俺はこうやってOOを広めた！
みたいなケースって、ある？

>>68

継承好きなのに、批判されたら気に入らないよね、よね、よね

でもキレないで、相手の矛盾を理論でうち破ってよ、破ってよ。破ってよ

>>69
障害になるなら採用しなきゃいいじゃんか。
頭固いのね。

>>72
めんどいのでお断り〜♪
俺が便利に使えればそれでいいわ。
アホくさ。

>>70
覚える暇がないってのもあるんじゃない？

>>75
また根性論・・・

>>76
いや、会社でそんな雰囲気に頭に来てるんだけど。
歴史のある会社はむずいやね。

>>74
説明できないなら最初から黙ってればいいのに

>開発現場でデファクトスタンダードをとれていない
OOPに関しては
カプセル化->継承->多態->コンポーネント
と確実に浸透していると思う。

ただ、それより上位の設計・手法に関しては
OOA, OOD, UML,デザパタ、XP、リファクタリング（無茶苦茶な並べ方だけど）
と確かに乱立してるね。

ここらへんの取捨選択の判断基準ってどういうものなんだろうね。

ネット関係はオブジェクト指向知らないと
仕事できないような気がするが。
これからますます重要になるぞ。

最低限の知識共有としてドキュメント化ははずせないと思うんで、
UMLだけは、なんとか、押さえておきたいなあ。

他は、やりたい人が勝手にやればいい感じ。（←乱暴

>>80
ある程度知った上で、問題点と運用方法
在るべき方法論について、議論しようとしてるんだけど
なんで問題点を指摘すると、相手の理解不足にしたがるの？

>>75
教育コストが馬鹿高いのが問題だよな。

オブジェクト指向はクラスがあってメソッドがあって、
というだけならまあ覚えるのにそんなに時間はかからないだろう。
が、実は分析や設計の方法論であり、UMLを使えデザインパターンを使え
何とかさんの何とか法を使えとなると、
実際にやるプログラミングとは少し離れた抽象思考の世界に入ってしまう。
(UMLやデザインパターンは世間のコンセンサスを得たものだからまだ分かりやすいが、
そうでない分析や設計の方法論なんかは妙な哲学にしか見えないものが多い)
で、その方法論でクラスを作るにはどうしたらいいの？
の答えは、自分で考えろ。だからね。

その点、言ってることが分かりやすいXPには期待してる。

>>79
そうか？
XP→リファクタリング→デザパタ→仕様書→UML

>>81
最低限の妥協点としてＵＭＬをフローチャートに書きなおして
持ってきて欲しい。

>>83
>実際にやるプログラミングとは少し離れた抽象思考の世界に入ってしまう。
少し離れたというよりベクトルとしては真逆だと思う

>>83
＞世間のコンセンサス

宣伝の結果に過ぎない。

フローチャートでは書けないからUML作ったんじゃないっけ？

あまり情けないこと言うなよ。>>85

UML書くまでは、よく分かってる人がやればいいよ。

それ以外の兵隊は、UMLだけ読めればよし。

実際の開発で採用した設計・開発手法はどんなものがありますか？
私がいま使っているのは
UML（一部）、UnitTest、リファクタリング、デザインパターン
くらいですね。割と小規模（三人）なので。
少人数なのでペアプログラミングっぽくなりますがちょっと違うかも...
代わりに書いたソースのレビューはやってます。

設計の人間が内輪でコンセンサス作って出来あがった糞デザインを
実装に「下げる」。
問題点を指摘すると「オブジェクト指向を理解出来ない奴」という
レッテルを貼られて切られる。
設計サイドはそりゃ楽だわな。

実際？
画面イメージと簡単なフローチャートをＳＥが持ってきて
実際の設計はＰＧがやる。

>>91
OOやるまえから設計する人間はそんなもんでしたがなにか？

やっぱJavaユーザーはDelphiユーザーとは違うね

>>93
そういえばそうですね。問題無いですね。何か？

>>94
？

君たち数学もコンピューターサイエンスも知らないくせに
何を偉そうに語ってるんですか？
とにかく、あんま調子んのらんどけや。

情報科の優秀な奴はプログラマーなんかにはならんのだよ。
難しい数学を使う偉い仕事につくのだよ。
君達は敗北者だからプログラマーやってるわけ、わかるか?
だいたい偉い人が作ったライブラリ使っとればアルゴリズムなんかしらんでもいいだろ。
お前らオートマトンとかわかってる?
数学基礎論わかるか?
アルゴリズムの計算量考えて作ってる?
あほはあほなりにがんばってるとは思うけどさ。
ああ、感情的になってしまったか。
わりいわりい、くだらんすれがあがるのがゆるせんだけなんだけどさ。
とにかく、あんま調子んのらんどけや

>>97
２元方程式までなら知ってるよ？

802ネタはもうお腹いっぱいだからやめて・・・

Delギコスレからの輸出品なので廃棄処分でよろしく。＜802

>>97-98藁た
ブラックユーモア(･∀･)イイ！

おもろいけどネタか

数学の話題は数学板でどうぞ。
ここはどっちかっていうと実務に近い人たちが
書き込むところです。ごめんなｗ

実務も抽象的に考えれば理論的に説明できるかもしれないのだけど
こっちはコストって概念まず一番にある世界なんだよな。
そこを分かってくれ。

104
書き忘れたけど、デキの悪いおれがここにいるのもその
コストを考えられた上での話なんだな。

>>98
そんな貴方にコレ。せめて人に見せられるもん書けや。
http://www.shiro.dreamhost.com/scheme/trans/gigo-1997-03-j.html

僕は童貞です。でも知識はあります。

＞＞１０４−１０５
何言ってるか分かりませんけど何か？

>>97
オートマトンぐらいなら知ってるぞ。

自動羊肉？

Ｃ言語が難しいってんでVBが大流行している現状では、
オブジェクト指向が理解できる奴が少なくてもしょうがないか。

>Ｃ言語が難しいってんでVBが大流行している現状
それはあんま関係ないような・・・

>>110
毎回でるようなことだけに
ワラタ

VBはオブジェクト指向取り入れだしたよね。
ていうか、C言語よりVBの文法の方が客観的に見て難しいよね・・・

頭の中が抽象的思考になるにつれ
英文ライクを目指した言語の方が文法は難しく

また駄スレになってきた……。

SQLってなんであーなんだ？
英文ライクらしいがあれよりもっといいもの作れただろ。
まったく、、、

OOとカンケーなくなってきたかも。

>>70
オブジェクト指向技術を使っている方の大半が
その技術をよくわかっていらっしゃらないからなのでは？

よくわかっていないために破綻してしまっている現状を
現場の人間は見ているので敬遠してしまうのかも．

…って，あんまり他人のことは言えないのですが．
恥ずかしながら最近ここに来るまでデザインパターンって知りませんでしたし
デザインパターンの本を読み始めて己の勉強不足を痛感してます．

以下、
「オブジェクト指向イッショニ勉強スレ」
というマターリな方向へもっていってはどうか？
OOの有用性、生産性批判の議論はもう飽きたYO。

賛成

>OOの有用性、生産性批判の議論はもう飽きたYO。
確かに
自分がOOを理解していると勘違いしている人が多いのは事実
そういう人にOOが駄目だって言われても・・・
根本的なとこで、エラーが出てるわけだからね

もっと具体的な話でもしましょう
例えば、Javaでスレッドを使うとき
どういう場合にrunnableをインプリメントして
どういう場合にThreadを継承するか？
とかさ

>>122
漏れはほとんどいつもRunnableを使う。内部無名クラスとしての場合が
多いけど。

別の処理シーケンスには実態としてのクラスを割り当てたく
なるのはﾍﾀﾚですか？

>>122
Javaやってないから今まで知らなかったんだけど、検索かけて
理解した。面白いね、Java。
たぶん自分で使うなら、>>123さんと同じくRunnableを使うと思う。

今作っているツールの「オプション」の設定を
セーブしたり反映させたりするのに
いい設計かパターンかないかな？
レジストリ読んでくるときも同じことで悩みます。

せっかくオブジェクト指向でくくってるのにJavaローカルの話題ださんでもいいじゃん。
Javaでスレッドがinterfaceとクラス継承の両方で実現できるのは多重継承が出来ない、
Mix-inもできない結果なんで。

>>127
多重継承できればオレもmix-inにするな。
mix-in派としてはインターフェース継承（runnable）がわかりやすひ。

>>126
メメントパターソだたかな？
デザパタ勉強中につき、うろおぼえなり。

Javaスレ他にもあるから駄目。
ＯＯを徹底的に叩くスレ。

>>130
違うだろっ！！

>>129
ちょっと勉強してみます。さんく。

>126
言語による。なに使ってんの？

>129
ちょっと違うような。OO、デザパタはあんま関係なさそう。

>>129
メメントはアンドゥ､リドゥの管理を自分でやらずに他人に任せるパターン。
>>126のどこに使えるのだろうか？
俺には想像できない。

みーめんとー
と読んでいたのは僕です。

恥。逝ってきますっ！！

>>126
特別な設計はいらないのでは。
オプションウィンドウを開くときに、
各モジュールが持つ状態を収集してウィンドウを構築。
閉じるときに各モジュールへ反映。
単純にこれでいいと思う。

オプション項目とモジュールの関連は抽象化されないけど。
オプションウィンドウに表示される項目が
動的に生成されて動的に並べられるものでもない限り､
具体的にならざるを得ないのでは。

>>126
情報を持っている各モジュールに保存、復帰に相当するインタフェースをもたせる。
このとき状態を記録するためのオブジェクトを引数にとることにする。
保存、復帰に相当するメソッド内からは引数に渡されたオブジェクトのメソッド
（書き込み、読み込み相当）を利用して情報を記録オブジェクトから出し入れする。
各モジュールをリストかなんかにいれてイテレータで順次、保存、復帰メソッドをコール。
どの情報を記録するかはそれぞれのオブジェクトに委ねられる点が良いような気が。

>どの情報を記録するかはそれぞれのオブジェクトに委ねられる点が良いような気が。

それで、オプションウィンドウのUIはどうなるのでしょうか？

>オプション項目とモジュールの関連は抽象化されないけど。
>具体的にならざるを得ないのでは。
まともなRTTIのある言語なら
例えばコントロールの変数名などをキーにしてやれば、
ほぼ自動化できるよ。それが出来るかどうかは言語による。

それってRTTI?

>>140

>オプションウィンドウに表示される項目が
>動的に生成されて動的に並べられるものでもない限り､
ここを抜くなよ。

>>139
ウィンドウの左側に各モジュールのリストを表示し、リストがクリックされたら
そのモジュールのプリファレンス表示メソッドをコールって具合にすれば、
UIもモジュール内に分散させられる気がします。
どっかでみたようなインターフェースですが。

>>133
言語はｃ＋＋っす。
みなさん、いろいろ案ありがとうございます。

>>138みたいな方法ってパターン名でいうと何になるんでしょうか？
＞デザパタのえらい人。

継承

メメント。

>>145
mementoの中途半端版

この>>126のような場合、メメントは有効なんでしょうか？
他のパターンの適合は？

思うんだけど、OOってコンソールかGUIかに限らずアプリを
作る時に処理を切り分けしやすいから良いんだけど、机上で
設計した後それを実践(実装)する時に困ることが多いと思う。
理想と現実ってとこかな。

一番広く使われてるのはC++だと思うけど、「C++FAQ」は
この妥協点を踏まえて書かれてて参考になった。多重継承
は漏れも好きじゃないけど、単一継承、それも純粋仮想クラス
は結構意味があると思う。

みんなは設計する時にどうやってる？UMLで書く？紙に丸とか
四角とか並べてる？漏れはいきなりソースのインターフェイス
(C++ならヘッダファイル)だけを書いてしまうことが多いの
だけど。。。

>>150
>設計した後それを実践(実装)する時に困ることが多い

どういうことで困るのか具体的に語ってよ。掘り下げてこそ面白い。

>>150
UML書きますね。
でも、ＵＩはいきなり実装が多いかな。
実装依存の場合が多いですもんね。

>>149
オブジェクトのカプセル化を壊さないという点からみれば
メメントを使うのは一つの方法かも。
あとはCompositeが使ってあればメッセージを行き渡らせるのが楽かな？

>>150
オレは逆かな？
設計するときに、どのくらいの粒度でオブジェクトに切り分けるか悩む。
実装は既存クラスを再利用しながらサクサク進む。

>>154
それは、オブジェクト指向がわかっていないから。

>>155
すっきりと設計できるようになるまでの過渡期みたいなもんあるし、
あまり冷たい言い方はせんでイイよ。

継承を使うより、
オブジェクトコンポジションを使え！

ってな書籍が少ないと思いませんka.

あと、オブジェクト指向たらＣ＋＋だか言ってる本が多い割には、
現実のコーディング場面で考慮するべきことがあんまり載ってない。

ソースファイル(.cpp)やヘッダ(.h)間の依存関係とかさぁ

なんかお勧めの本ってあります？
漏れ的には、
「大規模C++ソフトウェアデザイン」
http://www.pearsoned.co.jp/washo/prog/wa_pro15-j.html
が(・∀・)ｲｲ!って思ったんだけど。

>>158
http://www.amazon.co.jp/exec/obidos/ASIN/475611895X/ref=pd_sim_b_dp_1_3/250-2856788-2389052
http://www.amazon.co.jp/exec/obidos/ASIN/4756118089/ref%3Dpd%5Fsim%5Fb%5Fdp%5F1%5F1/250-2856788-2389052
http://www.amazon.co.jp/exec/obidos/ASIN/4756118534/ref=pd_sim_b_dp_1_1/250-2856788-2389052
http://www.amazon.co.jp/exec/obidos/ASIN/4881356194/ref=pd_sim_b_dp_1_2/250-2856788-2389052
http://www.amazon.co.jp/exec/obidos/tg/detail/glance/-/books/4797311126/qid=1002722823/ref=sr_sp_re_1_2/250-2856788-2389052
これらをまだ持ってないとは言わせない。

おお〜〜♪>>159
憂鬱な〜は持ってない(大学生協で立ち読み程度
そんなに良い本だったのか!!

けど、残り４つは持ってる/全部読んだﾖ。

特に「デザインパターン」は漏れの今までのＯＯに対する認識を一新したね!!
あれ読まずにＯＯＰするなって感じ。

「リファクタリング」も外せないですne.

>>159
Javaでいいのはない?
自分はC++わからないので

憂鬱本は入門講座。他の本の内容が理解できるなら不要かもしれない。
それでも他の本には載っていない状態遷移について詳しいから、
自分でそこが弱いと思うなら読む価値はある。
UML関係の本も一緒に読むといいよ。

>>159
Javaは解らない…。C++しか知らない。

>>162
http://www.hyuki.com/dp/index.html

ほ〜。
なんか過去ﾛｸﾞ宗教論争ばっかだったけどさ

名ｽﾚﾀﾞﾈ

>>166
>名ｽﾚﾀﾞﾈ
どこが？

MFCでDoc/Viewのちょっとしたプログラムを組み始めたんですが

AppWizardが吐いてるコードは、なんか全てのクラスが
CxxxAppクラスを知ってる(#includeしてる)のが気に入らなくて、
それらをCxxxAppから独立させて(絶縁して)組んでます
あとCxxxViewがDocを知ってるのも気に入らない。

こういう組み方してる人っています？実務レベルで.
どうなんだろ.

>>167少なくとも、ﾏﾄﾓな本読んでる人がいるってｺﾄで.

>>169
なるほど、本の紹介ね。

Doc/View構造ってデザインパターンに含まれてなかったよね？

>>171
observer petterがそれだ、と指摘を受けタ

>>171
Doc ->Subject
View->Observer

ってことか.

Model/View/Controllerってデザインパターンに含まれてなかったよね？

>>172
そうだったのか。

>>168
というわけで、デザパタの本でObserverパターンを確認してください。

>>174それなに？

なるほど…勉強になります
とりあえずMFCスレにでも逝ってきますです…

馬鹿がデザパタと聞いて「勉強」だってさ　ぷぷｗ

802師匠のお通りです。童貞喪失者は道をあけろ！

>>178
802ってのは良く知らんけど、あんたがそうなのか.
そういうあんたは>>158,>>159,>>165の本のどれかひとつでも
理解できてるんか、と問い詰めたい。小一時間問い詰めたい。

私の設計はそこらのデザパタ本など足元にも及ばないほど高度でかつ
洗練されておる。

語れ。

>>178
設計で一番重要なのは、クライアントとまともに
話せることなのよ。これが出来ないと、分析も要
件定義もない。一生コーダーならいいけどさ。

依頼主に会う前に相手の事は徹底的に調べておく。
用件は聞かなくても解る。

それから私の背後から近づかない方が良い。
報酬は指定したスイス銀行にアメリカドルで振りこんでくれ。

>>182
確かにねー
業務知識じゃ勝てないからねー
イヤな爺の話も聞かなきゃならない(-o-)

>>181>>183
802師匠童貞3流大学情報科院生低レベル厨房にしてはつまらないネタですね。

もしかして、童貞喪失者ですか。これは失敬。

802師匠の低レベル書き込みを拝見するならココ！
　　　　　　　　　(;;´∀｀)　　　　　　　　
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1002111261

ｲﾀｲ人だということがわかった。

>設計で一番重要なのは、クライアントとまともに
>話せることなのよ。これが出来ないと、分析も要
>件定義もない。一生コーダーならいいけどさ。
なんでこのスレにはこんな無内容な事しか話せない
糞厨房が後から後から湧いてくるのかねぇ？

しかも本人は結構気の利いたことを
言ってるように思い込んじゃってるのが余計に痛々しい。

>187
あんたも一生コーダーの口だね。

>>187
気の利いたこと、っつーよりｳﾞｧｶを叩く目的だから問題なしかと思われ。

>>188
あまり反応しすぎないほうが良い。ｵﾚﾓﾅｰ

煽りはほっとけ

本の紹介するヤツ
本の紹介をありがたがるヤツ
802ネタだすヤツ
関係ない話するヤツ
煽るだけのヤツ

やっぱＯＯスレはこうなるのね

>>191まぁそう言うなって。ﾏﾀｰﾘ｡

>>187
不快に感じたのなら、謝るよ。なお、188 は私じ
ゃないよ。

>182
不快云々よりスレ違いですよ。
正直このスレでその手の話題は食傷気味です。。。

>>191
最終的には手段だってことをどうしても忘れてしまうんだよね。
これが俺のイタさの原因。一応2chでも気をつけてはいるつもりだよ。

>>194
キチンとした会話は、ＳＥとして必須だよと、言
いたかっただけだけど、まずかったみたいね。以
後気をつけるよ。

吉野屋のメニューはＯＯである。
基本クラスは牛皿だ。
他は全て派生クラスだ。

語れ。

>>195
イタイのはお互い様
特にこのスレは(w

[C++]「インターフェイスと実装の分離」
つうことで、こんなのはいかがか。

--Class.h--
class Class
{
virtual void func1() = 0;
virtual void func2() = 0;
static Class* create();
};

--Class.cpp--
#include "Class.h"

class ClassImpl : public Class
{
virtual void func1(); // func1実装
virtual void func2(); // func2実装

//メンバ変数など
};

void ClassImpl::func1() {
...
}

void ClassImpl::func2() {
...
}

Class* Class::create()
{
return new ClassImpl();
}

Factoryクラスを用意するまでもないとき、こんなのはどうでしょう？

つーかなんで折れのほうが上なんだって優劣をつけたいわけ？
どうせみんな本に教えてもらってるんじゃん。

無理がある

童貞の802師匠と200をゲットしたのにそれに気がつかない>>200と
どちらが優秀かというと
劣等なのは802師匠がぶっちぎりだ。それに何か問題があるのか？

>>200
回答−＞真に実力のないプログラマの性
真の実力者なら、自分でいわなくても、他人が認めてくれる

>>200
だよな。全部の本を一度に読むにはムリがあるし。
その点2chでは本当の評価が聞けて良い。

>200-203
そ〜ゆ〜話題も食傷気味でちゅ

>>203
うむ､実力の中途半端な奴ほど回りに良く見られたがるよね。
他人の自分に対する評価もやけに気にする。

ていうか>>199はどうよ？
「無理がある」で終わりかYO!

>>203
あ、それ漏れだよ(T_T)

ごめん >>197向けに書いたのが誤爆。

どうみても牛皿は基底クラスに向かない。設計ミスだ。
の意味。

>>209ﾁｮﾄﾜﾗﾀ

OOを実践すると
290円でシステムを作らなければいけなくなる。

public:
virtual Discount();
virtual Price() const;

オブジェクトをどのレベルで捉えるかってのを
もっと段階的に論じてるものなんて読んだことある？
これがあるなら1000円ぐらい出してもいいな。

思いついた当時は結構あたまひねった記憶があるんだが。>>199
なんか普通の考えにみえるな…

データベースの設計における正規化のように、
クラス分けの正規化のようなモノがあってもよいと
考えたことはある。

>213
>これがあるなら1000円ぐらい出してもいいな。
もう少しだせよ（Ｗ

>>213お。どゆいみ？例を挙げてくだされい。

>215こっちも興味ありいい

>>213
何だか曖昧でよく分からないが、
適切な粒度と役割でクラスを切り出せる方法論はあるかってこと？

有名どころでは
ビジネスロジック向きの「アナリシスパターン」
http://www.rational.co.jp/products/books/bk_14.html
リアルタイムシステム向きの「オクトパス」
http://www.tech-arts.co.jp/oo/octopus.html
などがあるね。やたら難しいけど。

>>215
こんなのとか？
http://home.catv.ne.jp/dd/chiba/ken/Java/JavaStream.html

>>213
1000円は誰に払えばいいんですか？


考えていたのとは違うけど「アナリシスパターン」は
目次見て面白そうだから今度立ち読みしてみます。

ごめん、213は>>219の間違い。

だめだ、もう寝る。

>>219それ読んだことあるけど難しすぎ…
少なくとも趣味レベルからOOを習得しようとしてる漏れには
理解できんかった…(鬱

>>220何か違うような。

>221
Dare Ni Harau Ki Dattan Da ?

>>224
おれ自慢じゃないがパソコンの本なんて4冊しか持ってない。
あとは全部Web。これ最強。おれにとっての話ね。

パソコンの本って…「できるWindows」「超図解Excel」とか？

いや、仕事に関係する全て
読みたいものは全て立ち読みか
会社に買わせる。

>>227それ最強だね!!

俺は読むときに蛍光ペン引きまくるから私物でないと駄目なんだよな…

それわかる〜〜〜>>223

ネタふり
http://jcp.org/jsr/detail/26.jsp

>>223
「アナリシスパターン」は、プロでも頭を抱えるような難物だから無理はないと
思う。後半の実装に近い部分は大体理解できるのだけど、前半は本当に難解。
1回通読しただけで理解できる人はあまりいないと思う。

http://www.ogis-ri.co.jp/otc/hiroba/specials/img/Booch.gif
(´-`).｡ｏＯ（なでてあげたい・・・）

>>199
どういう利点があるのか説明きぼんぬ。
ふつうにNewとあまり差を感じないのですけど。

>>197
class GYUDON extends DONBURIMESHI implements BENISYOGA

あ、牛皿が基底クラスになってない‥‥。

牛皿を基底クラスにするのは却下。
なぜなら牛丼とは並盛のことであり､
大盛､特盛は牛丼から派生している。

１９８０年代にブーチ博士が出版した
「Object-Oriented Yoshinoya And Donburi」
（邦題・オブジェクト指向吉野家とドンブリ）によると、
牛丼一筋８０年という観測結果から
継承階層が１段階に限られていることが証明できるとあるのだ。

しかしこの本の内容は今となってはやや古臭い。
その後の研究で牛丼一筋１００年ではないことが通説となり、
それを機にブーチは松屋法のヤコブソン､すき屋法のランボーと協力して
Unified Gudon Language（統一牛丼言語）を開発､発表している。
これによりどのお店でも「特盛」や「つゆだく」が通じるようになり､
今年８月には並盛り２８０円を達成するという目覚しい効果をあげている。

ﾜﾗﾜﾗ

今日のお題は、吉野家のメニューのクラス設計ですか。

>>236
激ワラタ。

そしてクソスレへ…

>>236

牛丼設計方法論の前途洋洋かと思われたその前途に突如立ちはだかったのがXP(邦訳：狂牛病)、ってことでしょうか？

自分が明日狂牛病に発病するかどうかなんて事前に判らない！というのが、
XP一派の主張らしいです。

>>241
狂牛病だけにヤコブソンの松屋法はダメージが大きいですよ。
松屋は改装工事でおしゃれになってアベックでも入店しやすくなり、
ペアテイスティングを積極的に取り入れていますけどね。
カレーギュウの質が落ちたことについては残念ではありますが。

>>242
多重継承は駄目だという実例だな。

ちなみにヤコブソンが提唱するユースケースによって
顧客の要求を分析することで、松屋は他の牛丼屋にない
豊富なメニューを取り揃えています。
お客､店員だけでなく、自動食券販売機をアクターとみなしたことは
画期的な偉業だと言われています。

それにしても彼ら３人をスリーいらっしゃいズと呼んでいる人は
本当にいるのでしょうか？
彼らがそう呼んで欲しいだけのような気がするのは
私だけなのでしょうか。

他重軽傷って、牛＋ウイルスのこと？（ｗ

他重軽傷は自分自身の派生クラスを継承すると起こります。

>>242
は、ペアプログラミングのことで多重継承は関係ないのでは？

何時も通りの糞スレなのら〜
暇な３流大学生の溜まり場なのら〜
ら〜〜〜〜♪

今日は人が少ないのか‥‥。

>>234
例えば、privateメンバをClassImplに記述することで、
インターフェイスClass.hに見える部分をpublicメンバだけに制限できる。

っていうかそれくらい知っとけ。

#ていうか今日、Effective C++読んでたら同じやり方を見つけてショック(藁

>>250
> っていうかそれくらい知っとけ。
目くそ鼻くそ･･･
そう思ったの、漏れだけじゃないよね？ね？

ただの抽象クラス？？

がーーん<(ﾟoﾟ)>
ＯＯ理解できないアホとか、
デザパタ理解できないバカとかいってた人って、
もしかしてこのレベル？
もう、ここ来るのやめよ

>>252
にもなってない(T_T)

さすが、Effective C++読んでるだけのことはある(藁

皆さんデザパタ初めて読んだとき、既に使っていたパターンがいくつありました？
私は７つかな。（多少変形ありで。）

＞もしかしてこのレベル？

ってどのレベルだよ…
そんなにレベル低いのか…？

>>255
何読んでる？

レベル低いレスと高いレスの番号を挙げてもらえると、
僕みたいなへたれには勉強になるのですが。

>>258
このスレは捨ててニュースグループへ逝きましょう

>>256
そんなの数えて意味あるの？自慢？
パターンはいままであるものに名前を付けてるんだから
使ってて当然だろ。
変形あり・・・ってそのまま適用する方が少なくねーか？
そりゃ変形するだろ。銀の弾じゃねぇって書いてるだろ。

>>257
やっぱりCマガの「ローテク講座」じゃないでしょうか。

>>259
了解。

mata-ri

>>260
銀の弾と書く（書いてきた）人には注意
ストレスたまってます

>>261
もしかしてアノ人ですか・・・？

もしかして例のアレを何したアノ人ですか？

銀の玉玉検索してみました(俺って物好き?)
確かにヒステリー気味です 最低3日2chから離れましょう

誰かキレられないネタふってよ
何故このスレは・・・・

>>268胴衣・・・・

>>257
＞ってどのレベルだよ…
＞そんなにレベル低いのか…？
このソースの良い点／悪い点を解説してちょ

>>199について。
[目的]実装とインターフェイスを分離する。

大雑把に言えば、外部から見える.hファイルには
public:セクションしか置きたくないってことです。
この方法を使えば、データメンバやクラス内でしか
使わないメンバ関数などは
すべて実装側に記述することができます。

問題となる点としては
１．全てのメンバ関数がvirtualとなる。
このことによって
(1).関数呼び出しのオーバーヘッドが(わずかながら)増す。
(2).全てのメンバ関数が派生クラスで再定義されうる。

２．目的のクラスをnew演算子によって構築することができない。(悪い点？)
だから例のstatic 関数があります…

３．クラスの継承階層が一段階多くなるのでクラス階層の複雑さが増す。

４．friendを使う場合の問題。

っていうか何ら真新しいものじゃないんだけどさ…

（；´Д｀）さんの解説をきぼん

199さんの気づいてない悪い点も教えてあげて

>>273
いや漏れなんだけど

もっと言えば、いちいち他から参照されないprotected/privateメンバ関数や
データメンバを追加するたびに必要だった、
依存するモジュールの再コンパイルが必要無くなる。
publicインターフェイスが変更されるときだけ、
再コンパイルされる。
中・大規模プロジェクトでは結構無視できないと思われ。

ホントEffectiveC++で見つけたときは力抜けました。
結構頭ひねったつもりだったんだけど…

interfaceを宣言できないC++では、実装を隠す為には>>199のように
するしかない。
似たような感じで他にもバリエーションあり。
大規模どーたらという本にも載ってたかも。
Efectiveにものってたか？

>>277それ今日買ってきた。今読んでます…
上のほうで紹介されてたもんで。
中々良い感じです、
「C++に関する本は、ほとんどが論理デザインを取り上げている。」
大規模プロジェクトでは、ソースファイル同士の依存とかも
十分考慮に入れないと、大変なことになる。
そういった「実装デザイン」についても言及してます
でも高かった.

事実上、大規模プロジェクトでは、>>199みたいなことしないと開発
出来ないよね。
ベースクラスの方で、いちいち実装が変わってフルコンパイルかかったりすると、切れるね。

>>275-279
同じ人物が必死になってる気がするが。
ハッ、これは禁句？

お。プロの方ですかな
開発環境はなに使ってる？VC？>>279

１つバグがある
あと、継承先が１つなら、普通やらん

（；´Д｀） =278=281="199"
それ以外は知らない。

デストラクタ関連？>>282

がびーん
同じ人だったの
はずかし

あ、はずかしいのは、私ね

紛らわしくてｽﾏｿ.>>270

＞あと、継承先が１つなら、普通やらん
そういうもんなのかな…
あまりにも多くのクラスが「知っている」クラスはこれやっといたほうが
変更が効くと、思うんだけど
いかがなもんでしょ.

あとなにがバグなのかわからん.

確かにメンバ変数などのprivate部分をちょっと変えただけでも
全コンパイルに近い状態になるのはかなり邪魔くさいので
(C++Builderはコンパイルが遅い!)
うちもでかくなってくると自衛的に二段構えにしてるな。

VCだとDebugビルドだとあんまり気にしなくて済んでるかな。

要はコンパイルの手間の話だよね？
どちらも場合でも、publicメンバを変更しなければ、
使用しているクラスのソース変更はない。

通常の継承との混在はイヤだな。
使用頻度の低いクラスには、
ソースを複雑にするマイナスの方が大きい。
そう考えると、使用場面は限られてくる。

ポリモの為の抽象クラスほど、有用ではないな。

もしかしてバグって、１行足りないって事かな？

クラスのメンバ変数をヘッダに書かなくちゃいけないのが辛い。
C++の場合仕方のないことではあるけど
メンバ変数の宣言を実装側に切り離せれば楽なのに。
いちいち純粋仮想関数並べたインターフェース作るのもうざい。

>>199のバグか…
public:がないYO!(笑)

つーかC++固有の瑣末的な問題回避の話だな。
ぜんぜんオブジェクト指向と関係ない(笑)

これをインターフェイスの分離というのは間違いでは？
インターフェイスのファイルの分離でしょう。

やはりソースを出してもらうと、話が具体的になって良い。

そこから更に継承するときは、
ヘッダとソースを両方インクルードするのね。
なんか変。

>>296
いや、そーすだけだよ
さらにへんだが

書籍を真に受けると，こういう事もあるってオチで．

はぁ？誰が書籍を真に受けてるんだ？

>>298
本人は、自分で考えたと言っている。
>>299
まぁ、抑えていきましょう。

書籍に洗脳される→OOを使いまくる→失敗を繰り返しながらも経験を積む→
OOを使いこなせるようになる→ｳﾏｰ

書籍に洗脳されるやつは馬鹿だと主張して本を読まない→OO使えない→OO使ってる
やつの足を引っ張る→迷惑がられる→差をつけられる→ﾏｽﾞｰ

あなたはどちらの道を選びますか？

次のﾈﾀ誰か出してちょ

>>301
そのﾈﾀはやめようよ

>>289
>どちらも場合でも、publicメンバを変更しなければ、
>使用しているクラスのソース変更はない。

以下はC++の話。
public以外の実装（内部処理）を変更するときにもヘッダファイルを
変更しないといけないでしょ？
インタフェース（のようなもの）と、内部実装を切り離しておけば、
そのクラスを使う場合に、利用元の変更が波及しにくくなる。

>>294
>つーかC++固有の瑣末的な問題回避の話だな。
>ぜんぜんオブジェクト指向と関係ない(笑)

確かにそうですね。

>>296
>そこから更に継承するときは、
>ヘッダとソースを両方インクルードするのね。

ヘッダファイルだけでいいよ。

>>304
289と296についてはもう一度考えてみると良い

>>305
おかしいところがあれば、具体的に指摘してくれませんか？

>>306
少し考えてからにしてはどうか？
その後に説明する

うーん。
>>289では、クラスのソース変更はpublicメンバの変更があるときだと
言ってますよね。
これはそうではないと思います。

>>296
ソースをインクルードする必要があるということですか？

>>308
＞public以外の実装（内部処理）を変更するときにもヘッダファイルを
＞変更しないといけないでしょ？
この場合に、コンパイル以外の違いは何か？

＞ヘッダファイルだけでいいよ。
public以外のメンバはどうなる？

>>309
>この場合に、コンパイル以外の違いは何か？

うーん、質問の意味がわかりません。

>public以外のメンバはどうなる？

これもわからない。「どうなる」って何がでしょうか？
ソースファイルをインクルードする必要はないと思いますけど・・・。

>>310
たとえヘッダファイルか更新されても、
publicメンバ以外の変更であれば、
再コンパイル以外の処理は発生しない。

継承時は、protectedやprivateも必要になる。
これは、Class.cppに記述されている。

>>311
>たとえヘッダファイルか更新されても、
>publicメンバ以外の変更であれば、
>再コンパイル以外の処理は発生しない。

その再コンパイルを防ごうという話なんですけど・・・。
かっこよく、うさんくさく言えば、インタフェースと実装の分離。

>継承時は、protectedやprivateも必要になる。
>これは、Class.cppに記述されている。

？
それをClassImplで実装しましょうという話なんですけど・・・。

>>312
＞その再コンパイルを防ごうという話なんですけど・・・。
無論、分かっている。
つまり、使用クラス側のソース変更はない。

＞それをClassImplで実装しましょうという話なんですけど・・・。
継承時には、その実装ファイル（Class.cpp）のインクルードが必要。
Class.hは必要ない。

つまりこれは、インターフェイスの分離ではなく、
インターフェイスのファイルを分離して、
再コンパイルを少なくするという事。

広義的にはインターフェイスの分離といえるか。

あぁ、やっとわかりました。>>289を誤読してました。

しかし、インタフェースの分離か否かというのは、見解の相違という
ところに落ち着くと思います。

ベースクラスのインタフェースの変更が無い限り、それを使用する
ユーザはベースクラスの変更に無頓着でいいのですから、その
意味ではインタフェースが分離されているとも言えます。

ところで、Class.cppのインクルードは必要ないと思いますけど、
何か勘違いしてるでしょうか？

>>316
>ユーザはベースクラスの変更に無頓着でいいのですから、その
コンパイルの速度が速くなるだけだよ。プログラムはビルドしなおし。ユーザーは
影響を受ける。
それでもファイルが分離された分、少しはインターフェイスが分離されたと言える。

>>316
ＯＯよりも、まずプログラミングの基礎を勉強すべし

>>316
> ところで、Class.cppのインクルードは必要ないと思いますけど、
ClassImplを継承せずにClassを実装した別のクラスを作るんなら必要ないけど。

ちなみにXtはCで書かれてるけど、使用のためのインターフェースと継承のた
めのインターフェースが分かれてる。たとえばXawのダイアログなら

　X11/Xaw/Dialog.h 公開インターフェース
　X11/Xaw/DialogP.h クラス実装定義

という風になっていて、Dialogを使うときにはDialog.h、継承したクラスを作
るときにはDialogP.hをインクルードする(PはたぶんPrivateのP)。

荒れてるな。
牛丼の話に戻さないと・・・。

>>317
>コンパイルの速度が速くなるだけだよ。プログラムはビルドしなおし。ユーザーは
コンパイル速度の問題だけじゃない。
変更したのがライブラリクラスで多くの組織でそれを使ってる場合にそれぞれの組織に
再コンパイルを頼むのはコストがかかる。

OOでいう「インターフェースと実装の分離」っていうのは、
アブストラクトクラスとかJavaのインターフェース継承とか
のことだと思ってたんだけどなぁ。

>>317
>コンパイルの速度が速くなるだけだよ。プログラムはビルドしなおし。ユーザーは
>影響を受ける。

スタティックリンクの場合はリンクのみ必要。
ダイナミックリンクの場合は何も必要なし。
でしょ？勘違いしてるかな？

>>319
>ClassImplを継承せずにClassを実装した別のクラスを作るんなら必要ないけど。

あぁ、ここで食い違ってたんですね。
ClassImpleはClassの内部実装なのですから、class Classだけで閉じています。
というか、そのようにします。
継承も参照も保有もそうですけど、class Class以外のクラスは、Class.h
しか使いません。

>>322
>>199のようなコードは、ABCにせざるを得ませんから、その意味でも
インタフェースと言ってもいいんじゃないかと思います。まぁこの点は
異論があるかとも思いますけれど。

僕的には：
インターフェイス継承の場合はClass.hをインクルード
実装継承の場合は、ClassImplクラスの定義を(class{};の部分を)、
新たにClassImpl.hに移して、(はじめからそうしておけば良いんだけど)
そのClassImpl.hをインクルード。

てな感じでどうですか

＃.cppをインクルードするのは禁じ手かと。

結局>>319と同じことなんだけど…

クラス同士はうまくやれば独立に出来るけどさ､
クラスの中はスパゲッティーになること多くない？

あの関数とこの関数が依存しすぎ､とか。
これって漏れが下手なんかな？

他の人はどう？

というかClassインターフェイスを持つ実装が複数ある場合は、
Factoryクラスでもつくって、
そいつに具象クラスの生成をさせると良いと思う。
というか、それが一般的なのか？

結局漏れが言いたいのは、newで生成する側はクラスの実装の詳細を
知らないといけないから、
それをstatic Class* create()みたいに宣言して、
定義をClassImplと同じスコープに置いた、
こりゃどうでしょ、ということ

>>327
abstract factoryじゃだめ？

>>326
＞あの関数とこの関数が依存しすぎ､とか。
どゆいみ？

>>328 そのとおり。(だと思う)

>>329
あの関数の処理を変更するとこっちの関数も直さないと
だめでこっちの関数を直すとそっちの関数も...

みたいな．逝ってよし？

とりあえず、複数人数共同開発出来ないコードだね>>331

>>332
え？332のところって一つのクラスを複数の人間でコーディング
するの？ふつうクラスごとに割り振るんじゃないの？

あ､もちろんクラスのインターフェイスでは整合性を取ってるよ．
>>331はローカル関数の事ね．

>>331
とりあえず構造化が必要じゃないのかな
それぞれの関数の役割を明確にしておけば、
その中身の振る舞いを多少変えても大丈夫、みたいな。

「リファクタリング」とかが良い例かも。
メソッドの移動、とか.

>>334と、えらそうなことを言ってみたけど
「構造化」とか言ってる時点で
なんかおかしい様な気がしてきた…

>>326
のクラスにやたら関数が入ってるのは、そのクラスを管理するクラス
（マネージャクラス）が無いんじゃないの？

参照スパゲッティは怖かもしれんが、やたらとプライベート関数詰め込むと
誰かにfinalにされるぞ（藁

>>335
いや、意見産休。
やっぱりどうも自分が下手な気がしてきた。
まだまだ経験不足なのかも。

>>336
うーん、なんていうか、マネージャクラスに対する
インターフェイスを整備しようとしてローカル関数が
そうなっちゃう場合が多い気がする。

自分だけならあんまりならない。

ClassImplを実装継承するってどんな場合なんでしょうか？
僕はこれをやらないので、「.cppをインクルードする必要がある」
という意見が理解できないのです。

>>338
C++ならマネージャクラスをフレンドにしとけば
マネージャのためだけにインターフェイスを準備しなくて済むのでは？

…どうなんだろ。

>>339
いや、
「.cppをインクルードする必要がある」
というのは、もとに挙げた>>199の例が悪いっす。ｽﾏｿ。
前にも書いたけど、class ClassImpl{…};の部分だけ新ヘッダに
移してそれをインクルードすれば良いと。

実装継承は…ﾁｮﾄ自信ないけど、
「ClassImplの一部の動作を変更して再利用」みたいになるのかな…

>>338
それはユーティリティークラスとして別のパッケージに追いやってでも
クラスを簡素化すべき。クラスは寂しいくらい簡素な方がヨイ。

ただテストはたまったもんじゃないだろうが。バグの追跡も。

>>341
>実装継承は…ﾁｮﾄ自信ないけど、
>「ClassImplの一部の動作を変更して再利用」みたいになるのかな…

それってClassImplをpublic継承して動作を変えるんでしょうか？
うーむ、デザインパターンを知らないんですが、そういうことって
よくやるんでしょうか。
Classを継承するのと何が違うのか良く分かりません（汗

たった今入った情報によると、このスレにビンラディンの工作員が紛れ込んでいる。
さりげない会話の中で彼らの日本でのテロ開始の指示が行われようとしている。
開始のキーワードだけは解っている。
それは「生産性」だ。
決してこの単語を書きこんではいけない。

Javaやればオブジェクト思考なんて自然に見に付く
swingをデザインパターン併せて勉強しろ
糞のままでいたくなかったら普遍的な知識を見に付けろ
オブジェクト思考はやっといて損はない
アーキテクチャとかアルゴリズムとかも忘れんどけや

344の糞房は私ではないのでよろしく

345は考えが浅い。

>>347
なぜ?
反論するんならきちんとしてくれな

>Javaやればオブジェクト思考なんて自然に見に付く
それはない
オブジェクト指向できないと、くそコードしかかけないだけ
自分がくそコード書いてる事に気づかないと・・・

＞swingをデザインパターン併せて勉強しろ
同意
デザパタできなきゃswing使いこなせない

>糞のままでいたくなかったら普遍的な知識を見に付けろ
>オブジェクト思考はやっといて損はない
>アーキテクチャとかアルゴリズムとかも忘れんどけや
ライバル増やさないでー
他にできる奴がいないから、俺らは２千万以上稼げるんだから
年収１千万以下でPGとかSEとか言ってる人は
かわいくていいよ

>>348
じゃあ、
>Javaやればオブジェクト思考なんて自然に見に付く
なんて思ってるとは考えが浅い。
で、どう？（ｗ

正直、Javaを勉強するとオブジェクト指向の勉強になる、に一票。

生産性、反対から読んでも・・・

携帯Javaやってもオブジェクト指向は身につかんな。
JavaScriptやってもオブジェクト指向は身につかんな。

>携帯Javaやってもオブジェクト指向は身につかんな
自分でライブラリーとか作らないと・・・
ライブラリーを使ってるうちは身につかないと思うよ

>JavaScriptやってもオブジェクト指向は身につかんな。
おもしろい
ところで、JavaScriptってプログラミングって
言えるようなものなの？

>>354
上段
作るのはいくらでも出来ますが
ライブラリを置くスペースがありません。

下段
プログラミングと言えるようなものではありません。
というか、あれはJavaでもなんでもありません。

>ライブラリを置くスペースがありません
10kbだっけ？
まあ、確かにそうだね（笑）
ライブラリを書かなきゃいけない・・・
要するにポリモーフィズムとかを使ったライブラリを
（別にライブラリじゃなくてもいいんだけど、
巨大なプログラムって複数人でつくるから設計できない人にはやらせてくれないよね）
設計する機会がないとオブジェクト指向は身につかないんだよね
携帯で動かすくらいのプログラムにオブジェクト指向は必要ないかもね
iアプリとかのサーバークライアントのプログラム作る時がくれば
サーバー側はいろいろと複雑だから、それまでに身につけとかないとね
オブジェクト指向は設計フェーズの話だからね

やっぱ,JavaScriptはプログラミングってもんじゃないんだ
使う機会無さそうだし
JavaScriptでできることって
全部サンプルプログラムになっちゃってる気が

ああ、ＯＯ厨に荒らされて下がるばかり・・・。

>>357
お前の方が荒らし。

まぁまぁ。
てなわけで新しいネタきぼんぬ。

一気にレベルが下がった……。
マトモな人たちはこのスレを見捨てたようだ。

357=360は消えてください。

publicとprotectedについて
どう使い分けるかについて話しませんか？

んなもん話す余地なし

C++で戻り値がオーバーライド出来ないのって
設計した後の実装の時辛い事あるよね。

id型とかを持つ言語なら大丈夫なんだろうけど、
これだと型チェックが甘くなるし・・・

おれ、実装って意味わかんねーンダ。
頼むから一回分かりやすく説明してから
使い放題にしてクレ

>>364
covariantのこと？

>>364
Javaでも、オーバーライドしたメソッドの戻り値の型は、変更できない。
確かに変更したいときもあるけど、それを許すとポリモーフィズムに影響
がでる。
Javaでメソッドを区別するシグナチャは、メソッド名とパラメータの並びで
戻り値の型とアクセス修飾子は含まれないけど、オーバーライドする場合は、
アクセス修飾子は狭くなる方には変更できないし、戻り値の型は変えられない
という制約がある。
結局、その方がオブジェクト指向に適合しているということだよね。

>>365
ごめん漏れの言葉の使い方がおかしいのかもしれない
漏れは概念的に設計した後の実際のコーディングの事を実装って
呼んでる。C++で実装、Javaで実装とか。

>>366
あ、うん。
多分これのことだと思うんだけど、よく知らないので酢。良かったら
教えてください。資料がほとんど無いので・・・
C++相談スレへ逝ったほうが良いかな？

>>367
適合してるのかどうかは漏れには分からないけど、
例えば、ファイルを扱うCFileというクラスがあったとして
CFile::Load()の戻り値はファイル形式によって色々あっても
良さそうじゃない。テキストファイルなら
CText * CFile::Load()だし、画像ファイルなら
CImage * CFile::Load()だし。
CFileのサブクラスで実装するにしても、インターフェイスで
型が決められてしまうとこれが出来ないでしょ？

ばかばかしくてやる気も起きないけど、
そういうクラスがほしいのだったら、

CText, CImageの基底クラスを作ってそれを読み書きするんでないの？

class CFileImage;
class CText : public CFileImage {}
class CImage : public CFileImage {}

CFileImage* CFile::Load();

なぜばかばかしいかはじっくり考えてくれ

>>370
それはわかるんだけど、それだとCFileから返ってくる物は
全部メタクラスから派生した方でなきゃいけないでしょ？

外部ライブラリを使った時なんかはそれが出来ない事もあるわけ。

外部ライブラリはadapter patternでなんとかすれ。

>>372
やっぱりそうなるだよね・・・
それがすっきしなくて好きじゃないから>>364と書いたのだが

>>373

class CLoadableImage {
public:
bool Load(CFile &f);
};

class CText : public CLoadableImage {}
class CImage : public CLoadableImage {}

こっちでいいんでないの？
パターンなんて言うか忘れた。

なにが「すっきしない」のかな？
ていうか>>370いうところのばかばかしい理由をじっくり
考えて３００字以内にまとめる事。>>371

こういう事がやりたいんじゃないの？

class CImage;
class CText;

class CFile {
public:
void load() {};
};

class CImageFile : public CFile {
public:
void load(string name, CImage *img) {/*...*/}
}
class CTextFile : public CFile {
public:
void load(string name, CText *img) {/*...*/}
}

CFile file;
CImage *img;
CText *txt;
file.load("filename1", img);
file.load("filename2", txt);

>>376
気持ちは分かるが、それおかしすぎ。

ゴメソ、俺OO厨房なんだけど>>376のような時って
どうやるのが定石なの？

>>378
>>374が正解だと思う。

間違えた・・・
これじゃコンパイルエラーじゃん藁

CImageFile ifile;
CTextFile tfile;
ifile.load("filename1", img);
tfile.load("filename2", txt);

>>380
それも気持ちは分かるが、それおかしすぎ。

>>379
つまりOO的にはloadはファイルの仕事じゃないって事？

バイト単位の（低レベルなI/O）はCFile
バイトの並びを知っているのは各オブジェクト。

各オブジェクトがCFileに依存する形で書くのが
OO的にスマートだろ。

だが376, 380は、それ以前におかしい。

>>383
ゴメソ・・まだよく理解してないんだけど、ファイルをオープン
するのはCFileで、そのなかのデータを画像として扱うのは
CImage、ということ？

>>384
うん。

でも、当初の368の逝っているケースだと
CFileが、それぞれのバイトの並びを知らなければいけない。
（もしくは、CImage, CTextなどの末端のオブジェクトを知らなくてはいけない）

CFileは、CImageやCTextに対する責任を負うべきではない。

というのは、わかるよね？

>>385
ｻﾝｷｭ
なんとなくﾜｶﾀﾖ

<<367
>Javaでも、オーバーライドしたメソッドの戻り値の型は、変更できない。
>確かに変更したいときもあるけど、それを許すとポリモーフィズムに影響
>がでる。

戻り値をcovariantにしてもポリモーフィズムに影響がでないというのが定説。

>>388
>戻り値をcovariantにしてもポリモーフィズムに影響がでないというのが定説。
言われてみれば確かにそう。367での発言は、covariantの場合は当てはまらない。
sunのサイトで調べてみたら、javaでもcovarinatのサポートが検討されている
ようだし。
勉強不足、反省して逝きます。

>>374
Loadableよりも「Serializable」の方がＯＯ的に良いと思われ。

…蛇足ですが。

ＯＯなんかいらねー！
プログラムは根性で作るものだ！
理屈こねてんじゃねーぞ！！！

あんたが上司じゃなくてよかったよ

そして、部下でもなくてよかったよ

実は同僚。

生産性のアップには設計と実装の二人三脚が必要です
っつーか、設計なんてしてないから関係ないかｗ

体育会系だろうがなんだろうがちゃんとやれる人はいる。
>>391は体育会系の人に失礼

そんな事より１よ、ちょいと聞いてくれよ。スレとあんま関係ないけどさ。

このあいだ、久しぶりにシステム設計したんです。システム設計。
そしたらなんか設計会議にに人がめちゃくちゃいっぱいで座れないんです。
で、よく見たらなんかホワイトボードに書きこみがしてあって、「ハード仕様、言語未定」、
とか書いてあるんです。
もうね、アホかと。馬鹿かと。

お前らな、設計会議でハードの仕様未定でどーすんだよ、ボケが。
システム設計だよ、システム設計。
なんか発注元のＳＥとかも来てるし。発注元４人で途方に暮れてるのか。おめでてーな。
よーし、ＯＯ使って納期守っちゃうぞー、とか言ってるの。もう見てらんない。
お前らな、俺の寝袋やるからその席空けろと。
システム設計ってのはな、もっと殺伐としてるべきなんだよ。
開発中にいつ大幅な仕様変更が来てもおかしくない、
誰に責任をなすりつけるか、自分だけは助かろう、そんな雰囲気がいいんじゃねーか。
ＯＯオタは、すっこんでろ。

で、やっと座れたかと思ったら、隣の奴が、んじゃインターフェースで、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、インターフェースなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、んじゃインターフェース、だ。
お前は本当にインターフェースでプログラム組みたいのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、実際に仕様が固まったらそのインターフェースじゃおっつかないじゃないんかと。

システム設計通の俺から言わせてもらえば今、システム設計通の間での最新流行は
提案設計、これだね。
仕様より先に作っちまって提案。これが通のシステム設計のし方。
提案設計てのこちらの都合が多めに入ってる。そん代わり発注元の希望が少な目。これ。
で、発注先の担当者に催眠術かけて誘導。これ最強。

しかしこれは発注元が気付いたら信用を失うという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前、１は、ＶＣでＷＩＮアプリでもつくってなさいってことだ。

ほ〜。

このスレって、他でデザパタ論議してる人とは
違う人達だよね?。
皆さん学生さんだよね?。
そうだと言って下さい!　(´Д｀；)
まともなOOなんか一生させてくれない気がして来た...

ビジネスモデリングというものに興味があるやつはいるかい？

ＯＯの学習はまず、ＯＯの絶対性、無謬性を知る事から始めます。

「ある町に２つの会社がありました。
　頭の良い社員の集まったＡ社と頭の悪い社員の集まったＢ社です。
　あるとき、頭の良いＡ社の社員はＯＯを採用する事に決めました。
　頭の悪い社員のいるＢ社は従来の設計手法のままでした。

　やがて日本の景気が悪くなってきました。
　業界にも冬がやって来たのです。
　以前からせっせとＯＯを取り入れていたＡ社は高い生産性によって
　注文が減るどころか、むしろ増えていました。

　一方、ＯＯを採用しなかったＢ社は仕事が減って会社が火の車に
　なっていました。・・・・・・」

　小学生向けＯＯ思想普及パンフレットより。

まずは適材適所を知れ。

ＯＯ <-これなによ？、

ＯＯ＝ObjectOrientedの略　オブジェクト指向

>>404
ども、隠語かと思った（ｗ

Fileの話。

Fileという大雑把な言い方だから混乱するんじゃないかな。
Fileには機能的に二つの面があって、
1つはファイル名とかを扱う部分、もう1つはファイルの「中身」だ。
後者についてはSerializableとかStreamとかMarshalとかいう呼び名を
使うケースが多いね。

で、TextとかImageとかに必要なのは、まず絶対にStream経由での中身、
そして時として必要となるファイル名(拡張子連動とかで使う)。

分けて考えたほうがいいよ。
FileオブジェクトからStreamを取得して、Streamを使って中身を読み書きする、とかね。

Ｊａｖａ房はなんで只のファイル読み書きをStreamとか言ってんの？

だってＪａｖａ房なんだもん

言語機能によらず処理が必要なデータの受け渡し。
これをストリームと呼ぼう。
とするとFileの読み書きはStreamの一種といえそうだ。

>>409
>これをストリームと呼ぼう。

新しい俺用語の誕生ですか。
Streamという言葉にはもっとまともな定義がある筈ですが？

>>410
連続性を持ったデータの並び、だっけ？

>>410
>新しい俺用語の誕生ですか。
当然だ。俺が作るライブラリだからな！！ｶﾞﾊﾊ

>>411
辞書にはそうでてるかも知れないけど、普通は、受け取り側の都合も考えずに
ドンドンやってくるデーターの事を言うような・・・。
連続性なんて言ったら殆どのデーターが該当するような・・・。

>>397
あんた人間に対してOOPしてる。ダークサイドだ。こえー。
>>OO信者様
C++にはnamespaceとtemplateがあるんだぜ。カッコつけんなよ。
OOPなところはsusieとかPhotoShop etc.

http://www.atmarkit.co.jp/fdotnet/opinion/kawamata/2001_10.html

この人の言っていることって
正しいのですか？

> 　一方、筆者が別れざるを得なくなったのがオブジェクト指向である。オブジェクト指向
> といえば、クラスの再利用性が重要といわれるが、筆者の経験からいえば、再利用を意識
> したクラスを作ると、当面必要のない機能まで書き込む必要が生じて、時間と手間を食う。
> しかも、手間を掛けてもそのまま再利用できるケースはほとんどない。そのうえ、使わな
> い機能がソースコード上にあることで、ソースの分かりやすさは低下する。再利用を意識
> しても、結局よいことはあまりない。
>
> 　また、現実のモノになぞらえたモデリングを行うあまり、何重にもクラスの継承を重ね
> ることもあるが、これも問題になる。このようなクラスは、メソッド呼び出し1つでも、
> いったいどのクラスのメソッドが呼び出されるのか分かりにくい。モノになぞらえるより
> も、継承の数を減らした方が、ずっとソースコードが分かりやすくなる。1980年代には、
> goto文がプログラムを分かりにくくする悪とされたが、継承は21世紀のgoto文といえるか
> もしれない。

まあ、GOTO文は馬鹿には理解出来ない高度に抽象的なプログラミング
テクニックですから、落ちこぼれてそう言う事を言う人も居ますが
気にしないで下さい。

>>415
なぜオブジェクト指向と継承や再利用が同義であるかのごとくに語られているのか。

>>417
ページ，読んできましたが，
この方，オブジェクト指向，全然否定してません．
彼の主張は
「再利用性を考えるあまりに複雑な継承をやるくらいなら
使い捨ての短いプログラムをさっと作ってしまった方がいいじゃん」
ってことなのではないかと．

彼の『オブジェクト指向』の言葉の使い方は間違っていると思いますが
主張自体は一理あるかなと思います．
確かになんでもかんでも継承にすることの問題点は
γさんとかが書いたデザインパターンの本でも指摘されていますし．
今作っているプログラムがクラスの設計でドツボにはまっているところだったので
いろいろ考えさせられてしまいました．



ただ，挙げられていたサンプル，Delphiで書けば

1: TSample1 = class
2: private
3: FSampleData: integer;
4: public
5: property SampleData: integer read FSampleData write FSampleData;
6: // 続く
7: end;

『隠蔽』をちゃんとやっても七行で済んでしまうのですが（笑）．
彼にDelphiを教えてあげたい．

やっぱDelphiはスゴイや！

Ruby だと3行やね。smalltalk だとどうだろう。

class Sample
attr_accessor :sample_data
end

彼はオブジェクト指向がよくわかっていないのではないですか？

　　オブジェクト指向＝複雑な継承

という式しか成り立っていないので
複雑な継承をやめる＝オブジェクト指向を否定
と勘違いしているのでは？

何でも"短いプログラムがよい"という
決め付けは言語が変われば状況が変わるのに
そういう事が彼には理解できないのではないでしょうか。

定型的なメンバーアクセスメソッドを書くと行数が多いから
読みにくくてだめなコードという判断は
どう考えても、おかしいと思います。

優れたライブラリを使えば
ソースコードが短くて済み、その事は大変よいことでしょうが

そのライブラリを作っている人が
OO志向を否定して、メンバー変数をPublicばかりに
しているようなものは使えるものには
ならないと思うのですが、どうなのでしょう。

OOでやらんでいいことをOOでやって、ダメだというのはどんなものか？

>>421
どこにも「複雑な継承」の話は出てきてませんけど・・・。

>何でも"短いプログラムがよい"という
>決め付けは言語が変われば状況が変わるのに

そうですか？

>定型的なメンバーアクセスメソッドを書くと行数が多いから
>読みにくくてだめなコードという判断は

という話も出てきてません。
短いプログラムが正しいという前提だとすると、セクセッサを
使わないコードの方が「正しいということになってしまう」と書いてます。

XPでも「必要ないアクセッサを今インプリメントするな(YAGNI)」
というのがありますね。

＞短いプログラムが正しいという前提
短くて分かりやすくて意図した通りに正しく動くプログラムが正しい

氏は言葉をはしょり過ぎ。肉を減らして言葉を増やせといいたい。

編集段階で削られている可能性あるね。

記事は鵜呑みにしないようにね。

＞　また、現実のモノになぞらえたモデリングを行うあまり、何重にもクラスの継承を重ねることもあるが、これも問題になる。

>>423
これを複雑な継承という風に解釈したのですが？違いますか？

>>何でも"短いプログラムがよい"という
>>決め付けは言語が変われば状況が変わるのに
>そうですか？

そうでしょう、実際、DelphiやRubyの話も出ているようですが？

短いプログラムがよいという決め付けなら
アクセスメソッドを簡単に定義できる言語なら定義するのはよくて
C++ではメンバーはアクセスメソッドを付けない
のが正解なのですか？

実際、本人もC#はコードが短くなるからよいという事を書いていますけど


>>定型的なメンバーアクセスメソッドを書くと行数が多いから
>>読みにくくてだめなコードという判断は
>という話も出てきてません。

出ているでしょ。どこを読んでいます？

>短いプログラムが正しいという前提だとすると、セクセッサを
>使わないコードの方が「正しいということになってしまう」と書いてます。

前提という言葉があれば、どんな意見でもまかりとおるわけではないでしょう。
彼はオブジェクト指向より、短いソース志向が優れていると主張しているわけですよね。

XPは良い理論だと思いますが
彼の意見は短絡的で何も考えられてないと思います。
コードのリファクタリングは小さなプログラムを作れという指示ではないでしょう。

そんな文意をねじ曲げかねない
編集の仕方はしないでしょう。


>短いプログラムでは複雑な処理ができないではないか、と思う人もいるだろう。
>もちろん、そのとおりである。本当に必要な機能に絞り込んで短いプログラムに仕上げれば、
>単機能のプログラムになるのは必然である。


つまり、多機能ライブラリを作れないし作っている奴の事は除外して
自分だけの狭い世界でだけ通用する前提について
この人は語っているのですか？

必要なものを絞って、小さく書こう、といっているんだろ。

『XP本三部作と「UNIXという考え方」を読んでくれ』 の一行で済む内容だな。

なんか議論するのもアホらしいけど

>彼はオブジェクト指向がよくわかっていないのではないですか？
>
>　　オブジェクト指向＝複雑な継承
>
>という式しか成り立っていないので
>複雑な継承をやめる＝オブジェクト指向を否定
>と勘違いしているのでは？

と誤読しておいて、自分の読解能力を露ほども疑わない、
そんな無邪気な君に乾杯。

君は筆者を貶めたい、ただそれだけちゃうんかと。小１時間問い詰めたい。

age

.NET会議室の馴れ合い連中が
牛ノ屋関連で流れ着いてデブ擁護？

>君は筆者を貶めたい、ただそれだけちゃうんかと。小１時間問い詰めたい。

質の悪い記事を書いたら
叩かれるのは当たり前でしょう。

でもたいした問題じゃないよな。
ソースが長くて見難いたって、アクセサ程度じゃどうってことない。
アクセサならなにやってるかも名前で一目瞭然だしな。
時間がかかるってのもデバッグの時間に比べれば屁でもない。(w

>>431
>.NET会議室の馴れ合い連中が
>牛ノ屋関連で流れ着いてデブ擁護？

電波受信？
言ってることがさっぱりわからん。

>質の悪い記事を書いたら
>叩かれるのは当たり前でしょう。

マトモな批判ならＯＫ。
426は論理的な思考も読解力も無いアホだから、議論するのも無駄。

吉野家inプログラマ板
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=1002008783

まあお前、433は、このスレの115番でも読んでなさいってこった。

人のことアホ呼ばわりするなら
もっとまともな反論しろよ。
あなたこそ、誤読がとか読解能力がとかしか言ってないでしょ。

あーヤダヤダ。核心つかれるとすぐ怒るから。

んじゃー、ちょっとだけ。

>>421
>　　オブジェクト指向＝複雑な継承

>という式しか成り立っていないので

と君が読み取っただけだね。どこにもそんなこと書いてない。

>複雑な継承をやめる＝オブジェクト指向を否定
>と勘違いしているのでは？

どこにオブジェクト指向を否定してる記述があるんだ？

>何でも"短いプログラムがよい"という
>決め付けは言語が変われば状況が変わるのに

あのさー、記事全部読んでる？
「決め付け」なんてしてないだろ。

>そういう事が彼には理解できないのではないでしょうか。

「そういう事」って何を指してる？
また、DelphiやRubyでアクセッサを簡潔に書けることと、あの記事は
どういう関係がある？

>読みにくくてだめなコードという判断は

ダメだなんて判断してないでしょ。してると言うんだったら、該当箇所を引用しなさい。

>そのライブラリを作っている人が
>OO志向を否定して、メンバー変数をPublicばかりに
>しているようなものは使えるものには
>ならないと思うのですが、どうなのでしょう。

日本語おかしいね。何言ってるかわかりません。
どうなのでしょうって、何が？

そもそも、筆者が「OOを否定している」なんて思い込んでいるから、
記事の内容を読み取れないんだよ。

>>434
>あーヤダヤダ。核心つかれるとすぐ怒るから。

君って筆者の略歴にコンプレックスもって、筆者に粘着してるだけなんでしょ。

・・・なんて書かれたら、もう有効な反論は出来ないでしょ。
そんな低レベルなことは止めようや。

426は極端に曲解してるところがあるというのはその通りだし、
430は正しいのだが、揚げ足取りの感があるなあ。
430の指摘は枝葉末節だろう。

どこにそんなこと書いてる？
誤読だろ？

と言われたら、自分がそう判断した根拠を提示すればよろしい。
それをしないから非難されるのだ。

それに、筆者がよそで何をやろうと関係ないでしょ。
あのコラムの内容で閉じた話をしよう。

それともあの筆者について語りたいのか？

ｼﾞｻｸｼﾞｴｰﾝとか書かれそうだが（藁

>>437
>426は極端に曲解してるところがあるというのはその通りだし、
>430は正しいのだが、揚げ足取りの感があるなあ。
>430の指摘は枝葉末節だろう。

うん、その通り。揚げ足取りだよ。
426がちゃんとした対話をする知性を持ち合わしているのかどうか、試してるだけなんだ。

なぜ426が、絶大な自信を持ってるのかも知りたい。
怖いもの見たさっていうか・・・（藁

くだらねぇ争いだなぁ。
次行こうぜ。

>>440
おっけー。もうやめる。
ごめーん。

なんか話そうよ

IIOSSの本買ったよ。これから読むとこ。

俺もアクセサごときで見難いだの面倒だの言ってるのは間違ってると思うな。
継承のし過ぎは確かに良くないが、それはオブジェクト指向批判には
結びつかないと思うのだが。「別れざるを得ない」の理由にならないのは
言うに及ばず。

誰か「OO志向」につっこんでやれよ。

再利用性はプログラミングの生命線だぞ。
これが駄目ならＯＯは駄目つうことだ。
それが判らん奴はただの言語ヲタ。
日経あたりの提灯記事を見ぬけないのは技術者とは言えない。

>>446
誰もＯＯでは再利用性が駄目だと言ってないだろ？
どこからそんな話になるんだ？

ＯＯは再利用性が駄目ってのは多くの経験者の結論。
関連スレ読み返すべし。

唐突な話だな。
出てきたとしてもずっと昔だろう。
ま、俺としてはOOを使うと再利用性が上がるのは当然と思うがな。

>>448
??
OOの再利用性が低いっていうのは、どこのレベルでのプログラミング
の話しですのん？
C++使っててクラスライブラリを使わない人っているのン？

川俣さんはC#の（たのまれもしない）守護神なんですよ。
これまでは大体、Java逝ってよし→C#ｲｲ！って感じでしたが、
（OldProgrammerの地が出て）GUI,OOP逝ってよし→C#ｲｲ！
ってことになっただけですよ。

あのスクロールのクソ遅いMSX版DQ2を移植したのはコイツ
だたのか‥‥。逝ってよしっ！

ライブラリって再利用にカウントするんだｗ

ＯＯ信者の言ってる「再利用」ってのはそれだったのか。
やっぱ只のライブラリヲタが騒いでるだけだったのね。
納得。

>>456,454
クラスライブラリを利用してるときはOOの恩恵をさんざん
受けてる癖に自分が再利用できるクラスを構築できないから
「OOは再利用性が低い」って言ってるようにしか聞こえませ
んが何か？

＞454
ライブラリなんてOOじゃ無くてもあるしね

ついでに言っとくと自分でプログラムするときは，
再利用できそうな部分と使い捨ての部分を切り分けて
クラス設計してるよ。
再利用しそうなほうはもちろん，アクセサを丁寧に用
意するし，はなから使い捨てのほうは必要最低限のメ
ソッドしか用意しない。
仕様変更が起こりそうな部分は継承せずに委譲して
ブラックボックス再利用。
ああOOって便利……。

457=450ね。

>>456
あらら，自分はOOの恩恵を受けてないと思ってる人がまた
ひとり。
ま，そうゆー人は，APIをずらずら並べるプログラミング
してたらいいんじゃないの？(w

いや455のレスに適当な発言をしただけですよん

ＯＯの継承は再利用そのものだと思うが。

再利用性の高い実用クラスの設計と実装にはコストがかかる
という話しだと思われ。

でも、再利用することによって、それ以上にコストが浮くんだけども。

ようするに、「面倒だから再利用性の高いクラスを作らない」ってのは、
「面倒だから勉強は身に付けない」って言ってる受験生と同じだな。
勉強しておけば将来いい思いが出来るのにね。（藁

川俣はC#の守護神ではなくて、C#の寄生虫だろう。
あんな奴についていったらC#はわけわからない言語になりさがる。
川俣C#はDelphiでいう所の吉田翁以下だよ

C#入門　第13回 言語に内蔵されたイベント機能
http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_013/csharp_abc01.html
イベント機能をCUIで利用するなんていうバカ見たことないな
それをサンプルにしてしまうのも、非常にセンスなし
イベントドリブンは元々ウィンドウプログラムから発生した機能だから
ユーザーの入力がないのにイベントを発生させて何が面白いのだ？

>>444そうそう。

>>455その通り。

>>457それは当たり前だが、川俣はそういうのも理解していないだろうな。
全部使い捨て

利用されるクラスを書くのと、再利用もにらんだクラスは違うぞ。
クラスライブラリは前者。
ごっちゃに議論すると話がややこしくなる。

>>465
C#ネタはC#スレでやってくれ。

>>466　どう違うのでしょうか。

自分は再利用をにらんだクラスを作る時には
ｸﾗｽﾗｲﾌﾞﾗﾘを作っているつもりや
ｸﾗｽﾗｲﾌﾞﾗﾘを拡張している気になって作ってしまうのです。

>>468
究極的に言えば、クラスライブラリは再利用性なんか考えなくて良い。
過不足無く要求仕様を満たせばそれで良し。

再利用をにらんだクラスは、要求仕様＋αが必要。
（必要ないかもしれない）抽象度を高めたり、独立性を高めたり、
今は必要ないリファクタリングをしたりする必要がある。

>>469
部品屋さん、と、アプリ構築屋さんの違いでは？

再利用性を考える＝要求仕様を満たす

という状況もあります。＋αが確実な要求仕様になるのです。
>（必要ないかもしれない）抽象度を高めたり、独立性を高めたり、

程度の問題ではありますが
これが要求仕様になるのですよ。


話題は異なりますが
XPのいくつかの理論はアプリ構築の為の方法論であり
元々XPを導入しなくてもスキルがあり生産性の十分高い部品屋には
通じない事もあると思います。

結局、今の納期と将来の納期を見比べて、どこまで作り込むかという
話しに帰結するだろ。

とりあえず今をしのぐために手早く確実に作り込むか、
将来楽をしたいからしっかり作り込むのか、の違いなんだよ。

どちらかというと、後者の方が失敗（予測見積もり）したときの
リスクが大きいから、企業活動としてやるなら
とりあえず「そこまではやらんでいい」のだ。

些末すぎてあのペ−ジに書いてある例は議論の対象にもならんと思うが、ね。

ではあの文章は駄文で
K川俣は堕デブということでよろしいですか？>>471

川俣の本、何冊か呼んで、結構ためになってるからなあ。

後で本当にオブジェクト指向を消化したうえで、
もういちど読み直しとけばいいよ。
だが、毒にもならんし薬にもなってはない、と思う。

と思ったら、ぜんぜん別人だった。
どれも読まなくていい本。

>>472でよろしい。

>>465
私はDelphiのコンソールプログラムでもクラスを作ってイベント定義してます．
イベントをフック，コールバック関数のようなものと考えれば
利用する場面は結構多いとように思うのですがどうでしょう．

たとえばある種のデータを処理するクラスで
時間の掛かるエンコードやデコードを行うメソッドがあるとすると
進行状況を表示する手段としてイベントを用意するのは有効だと思います．

どんなやつかと思ってたらただのﾃﾞﾌﾞｵﾀか

>>474
ﾜﾗﾀ

水俣？
http://www.autumn.org/selfint.html#NOTPROGRAMMER

プログラマではないのは結構なのだが
それなら知ったかぶりして技術駄文をwebサイトで執筆する

という行為はやめてもらいたい。

>>475
そのイベントの使い方は正しいですが
その利点があの川俣氏のサンプルでわかりますか？

ウィンドウプログラムのイベントドリブンだけが
イベントの利点だと思われたのならスマソ。書き方が悪かった。

しかし、コンソールベースでも隠蔽などの事を考えなければ
イベントなどは必要なく単にコールバック関数を指定すれば
いいわけなので、それほど利点になるわけではないと思います。
やはりイベントドリブン系のUIを持つ所での
使用が主として役に立つのではないかと、私は思います。

川俣氏の理論でいうと
イベント定義するより関数を直接呼んだ方が
短いプログラムになるはずですが、

それについてどう思いますか？

その機能が実際の開発でどのように使われているかなんて
奴に書けるわけがない。
だって奴は実際の開発なんてやってないんだから。

責任は人選誤った編集部にある。
奴を責めるのはかわいそうだ。

>>477
のリンク先を見ていて思うのだが
自分のことを天才(と周囲に思われている)という人間が書く文章は
どうして凡才以下の文章になるのだろうか？

不思議でならない。

あの一連の記事を読む限り天才さの微塵も感じないばかりが
技術者としてダメな所ばかり目立つ反面教師の姿しか見えない。

太った奴はあつかましくて自己中という事なのだろうか。


>>479
責任は文章を書いた本人にあるのではなく
それを書かせた社会が悪いとでも？

本人が書きたくもないのに、
ああいう趣旨の文章を無理矢理書かされたというのなら
そういう理論も通るだろうが。

>イベント機能をCUIで利用するなんていうバカ見たことないな
そうか、>>475さんはこの文に対してのレスだったのですね、スマソ

ああいう単純なHallowWorld的サンプルで
イベント機能を紹介するというのはひどいという事が言いたかったのです。

HallowWorldだって、はずかし！

Hell Worldにでも逝けってんだ。（藁

人物論評するならプログラマ板でやってくれ。

んーコスト意識の無い人達に生産性などと持ち出しても無駄だったか。
再利用が可能かどうかなんて話になってるし。

誰こいつ

要は You Aren't Going to Need It を説得力なく語った川俣が悪いと。

また「OOは生産性が‥‥」って一人で言ってる奴が来たよ。
アンタ懲りずに毎度毎度同じネタばかりでウザイよ。

>>415は間違いなく確信犯だな。

>>486
説得力がないのではなく、彼は理解も何もしていない。
理解していないのに説得力など出るわけがない。

じゃＯＯ導入で何パーセントコストダウンしたんだよ？
死ね！

「俺が書いたクラスは再利用性最高だぜ」っていうやつのコード見ると
「再考だぜ？」の間違いかと思われる事が多いから問題なんだよな。
実際自分以外の奴が素直に再利用しているクラスって書けてる？
「なんちゅう使い方してんだ、ｺﾞﾗｧ!!」と思っている奴、使っている奴も
きっと憤懣やるかたない気持ちで使っているんだと思うよ。

マズ「再利用」ヲ定義セヨ。

定義してやるからここに持って来い。

http://slashdot.jp/article.pl?sid=01/10/21/0838203&mode=thread&threshold=

ここでも川俣さんは叩かれているようです。

>>478
ごめんなさい，川俣氏の理論が正しいかどうかはわかりません．
でも「イベントを使えば簡潔なソースになるよ〜」の説明としては
呪文のようなコードを見せられても説得力がありませんね．

>そのイベントの使い方は正しいですが
>その利点があの川俣氏のサンプルでわかりますか？
わかりません（笑）．

川俣さん関係は以降はこちらで続けましょう↓
★デブプログラマーってどうよ★
http://mentai.2ch.net/test/read.cgi/prog/1001686611/133-

JavaとかC#みたいなOOLのプログラムエントリって、
どうして適当なclassの中に書くの？
class A { public static void main(...) {...} }
非常に気持ち悪いんだけど。

Javaで.jarに固めるときに、Manifestファイルを書くけど、
プログラムの起動はManifestにクラス名を記述するけど、
だったら、最初から プログラム本体＋起動定義ファイルで起動するようにして、
実行は起動定義ファイルで記されたクラスのコンストラクタからでいいと思うんだけど。

age

>>497
テストコードを埋め込むためじゃないの？

>>497
単独で実行してそのクラスの機能をテストするためのコードを main に書いたりする。

499だけど、mainから始めるという仕様はどこから来てるものなのか？
C/C++の名残というだけの理由なんですか？

まさにそうでしょ。
Java は C/C++ と見た目の互換性を考えて作られた言語だからして。

データが入っているオブジェクト(dA)があります。
このdAに対し、処理を行うオブジェクトが3つあります。(mB,mC,mD)

dAはmBにより処理され、その結果をmCが処理し、そのまた結果をmDが
処理します。このとき、各処理の入出力はdAです。

dAのカプセル化を保持したままmB,mC,mDで処理できるのでしょうか？
dAのデータ部分はpublicにするしかないのでしょうか？

Javaでは「MVC」とかで、なんか「表示する内容」と「表示」を担当する部分と
あと、もう一つ、何かをうまく分けてあると今月のCmagaに載ってたんで
なんかやり方があるのではないかと思いまして。。
よろしくお願いしますです。

>>503

ﾜﾗﾀﾖ

>>505　すいません。いたってまじめです。。
クラス設計を知りたいと言わなかったのがいけないの。。？

>>503
カプセルかも何も、
mB.func(dA);
mC.func(dA);
mD.func(dA);
じゃないの？

やりたいことが今ひとつわからん。

>>506

安心しろ。
dAにgetter,setterがあるんだろ。
だったらカプセル化は保持されてると思われ。

>>506
mBやmCやmDがdAのprivateなデータを操作するためのメソッドが
dAによって提供されていて、mBやmCやmDが必要なメソッドにアク
セスできればいいだけでしょ。

簡単なサンプルとしてはIteratorパターンなんかそうだよね。

>簡単なサンプルとしてはIteratorパターンなんかそうだよね。

ハァ？

>>510
処理とデータを個別にカプセル化するサンプルじゃよ。

>>511

いや、だからカプセル化の簡単なサンプルで、
Iteratorパターンは出ないと思われるが。
どうでもいいけど。

すいません。具体的なことを書きます。
ターゲットはJPEGの圧縮処理みたいなやつを想定しています。

画があってこれにDCTして量子化(Q)してVLCして圧縮データを得るわけですが、

画のデータを収めるクラス(Pic)があり、
DCTを行うクラス、Qのクラス、VLCのクラス、
そして圧縮データのクラス(Stream)を作ろうと思ってます。

んで、このとき、画のクラスの情報を隠蔽しつつDCTを行えるのか？という疑問です。

画のPicクラスにDCT、Q、VLCを集約し、機能を委譲すればいいかとも
思いましたがたとえばDCTには4種類ほどやり方があるのでどうやって
Picクラスに入れればいいか、そしてDCTクラスをどのように設計すればいいかが
わかりませんでした。
　言語はJavaです。よろしくお願いしますです。

>>503
>dAのデータ部分はpublicにするしかないのでしょうか？
publicとprivateの間にJavaならパッケージスコープやインナークラスがあるし、
C++ならファイルスコープやインナークラス、そしてfriendがある。
publicにする必要はないぞ

データがふらふら〜っとオブジェクト間を渡り歩く。
で、OOPなのでデータのオブジェクトはしっかり情報隠蔽したい。
・・・データ部分をさらけ出すのはしょうがないんですかね？

Strategyパターンか。
getterを適切に作れば良いだけだと思うが。
ピクセル要素やピクセルフォーマットにアクセスできない画像クラスなんて
なんの役に立つんだ？
それを隠蔽する事になんの意味がある？

Ｃ＋＋ならStrategy抽象クラスに対してフレンド宣言して
そいつにprotectedでgetterを書く。
Ｊａｖａなら画像と
同じパッケージに入れてgetterをpublic宣言しなけりゃ良いだけ。

>>516-517
どもです。ストラテジーについて調べてみます！

>ピクセル要素やピクセルフォーマットにアクセスできない画像クラスなんて
>なんの役に立つんだ？
>それを隠蔽する事になんの意味がある？
すいません。OOPがよく分かってないもんで。。
原則に対する割り切り方がまだ分からないんです。。
「Javaの格言」読んだら「データはprivate!　protectedも危ないぞ！」って
書いてるもんだから。。

>Ｊａｖａなら画像と同じパッケージに入れてgetterをpublic宣言しなけりゃ良いだけ。
パッケージレベルでの情報隠蔽ってことですね？なるほど。。

また疑問が出てきたら質問させていただきます。どうもありがとうございましたです！

StrategyだのIteratorだのはデザインパターンの話。
デザインパターンのスレ有ったと思うからそこみて本買うよろし。
おいらはVisitorパターンのような実装にするかな。

class Image {
CompressedImage compress(Compressor compressor) {
return compressor.compress(pixels, pixelFormat);
}
}

>「Javaの格言」読んだら「データはprivate!　protectedも危ないぞ！」って
例えばJavaのVectorクラス。
あれはメンバ変数にはアクセスできないが、
要素にはアクセスできるだろう？
メンバ変数を公開するのは（勝手に書き換えられたりして）危険だが
メンバ関数を通じてアクセスや操作させるように作れば問題無い。
Javaの標準ライブラリ見てそのへんを考えてみては？

Strategyを見てみました。感想は、、なんかTemplate methodと
ほとんど同じのような気が。。理解が足りてないんでしょうか？？
まぁ、これでどのようにして4種類のDCTを切り替えるかの方法が分かった気がします。
>>519　Visitorパターンですか。。これから調べてみます。どもです！

>>520　Vectorの例、なるほどです。
>要素にはアクセスできるだろう？
情報隠蔽とはまた違うことですが、(Vectorに格納されているオブジェクトどもは
情報隠蔽されたオブジェクトだから)
でも、その観点からも考えて見ます。

>Javaの標準ライブラリ見てそのへんを考えてみては？
標準ライブラリをほとんど知らないので。。勉強してみます。
(なにかお勧めのパッケージとかありますでしょうか？)

皆さん、どうもありがとうございますです。

>>520
Vector のメンバ変数って何よ？

>>522 ソース見ましょう。
protected Object elementData[];
protected int elementCount;
とか。
ところで新しめの似非VectorであるArrayListでは
上の２つ相当のメンバーはprivateになってる。

>>523
というか、Java厨として C++ 用語を糾弾してみた。
フィールドまたはインスタンス変数と読んでほしい。

あんまいい例えじゃなかったかな。

>>521
例えばあなたがVectorクラスを自作したとします。
おそらくメンバ変数としてObjectの配列を持つと思います。
これをpublicにするといつでも外から読み書きができてしまいます。
これによって、Vectorを使う側が勝手にVectorがやるような処理を
実装してしまうかもしれません。
しかもその処理がVector側の処理と矛盾があったりするかもしれません。
これではVectorを一つの独立したオブジェクトとみなして安心して使う事は
できません。Vector内部の処理、Vectorを使っている処理
すべてに注意を払いながらコーディングしなければなりません。

一方、このObjectの配列をprivateで宣言し、代わりに
pubic Object get(int index) このように任意の位置のオブジェクトを
取得するメンバを実装したとします。
するとVectorが内部にもつ配列自体には干渉できないので
配列に関する処理はすべてVectorのメンバ関数に頼ることになります。
このように実装されていれば配列の管理は外部から隠蔽されます。
Vectorは独立したオブジェクトとして安心して
使いまわすことが出来ます｡

長文ですまんが雰囲気だけでも伝わるだろうか。

>>524
そういう事かい！！
フィールド、メソッドって呼び方もよいが
メンバ変数、メンバ関数て呼び方のほうが法則性があって好きなんだYO・・

メンバ変数、関数メンバじゃなかったっけ？

んなこたぁない。

メンバー稲垣

データ隠蔽は手段であって目的ではない。
そこを勘違いして､公開属性を必ず悪と考えるのは間違い。
goto問題の轍を踏んではいけない。

その目的とは､あえて難しい言い回しをすれば、
「オブジェクトが交わした契約の履行」。
これを中心に考えるべきなのに､
データ隠蔽を中心に考えるのはよくない。

Member稲垣は紅白にでるらしいゾ！

すでにＯＯ教徒のセントラルドグマと化していると思われ。

>>521
Template MethodとStrategyって目的が全然違うと思うけど。

Template Methodは基本的に振る舞いは同じだが、細かいところで異なる
クラスを作る場合に、基底クラスのメソッドに振る舞いの大枠を作っておき、
振る舞いの違う分をprotecedなメソッド呼び出しにしておいて、それを
派生クラスでオーバーライドすることで振る舞いを替えられるようにする
パターン。

Strategyは動的にアルゴリズムを変更できるようにするパターン。
Template Methodと組み合わせることも可能。

>>533

つまるところTemplateMethodはそのObjectのメソッド定義を変える必要があるので、
クラスのメソッドを実行時に差し替えたり
クラスすら放置してObjectのメソッドをいきなり差し替えたり
できる言語(例：ruby)でもなければ、静的な変化しか得られない。

一方Strategyはメソッド持ちObjectを差し替えれば済むことだから、
今目の前に有るObject(のクラス)すら変化させることが出来ない
困った言語(例：C++(藁))でもなければ、動的な変化がばんばんやれる。

勿論、クラスにハードコードしちゃうほうが便利
(いちいちObject増やすのもうざい)な場合も多いので、
両パターンの間に明白な優劣があるわけではない。
なにをどう作りたいか？によって使い分ければいい。

キーワードは「差し替え可能」だな。

というかデザパタの多くが、ある特定の部分を「差し替え可能」になっている
ってのが売りなわけだけど。
逆にいえばその外の部分が固定になってて不便する、というパターンも多いから、
どこが「差し替え可能」になってると嬉しいか？によって、使うパターンは選ぶべきもの。

スイッチングメソッド
http://www.kame-net.com/jplop/PatternRepository/PatternBody/SwitchingMethod/SwitchingMethod.doc
…通常、振る舞いの切替りには別のオブジェクトが利用される。
本イデオムでは、そうでなく、メソッドを利用する。…(抜粋)

どうよ？C++向けだけど

この手のスレのタイトル見て、いつも副作用逝って良し
派とかdeterminisitic computing逝って良し派の意見を
期待するんだが、、、、
中はいっつもCとかそれ系側からの単なる煽り文なのはなんで？

激しく誤爆。すまぬ。

>determinisitic computing
これなに？

なんか今更もう一つの方に書く気も萎えた...
ちなみにnondterminisiticはPrologとかだな。
スレ違いなのでsage。

副作用はともかくnondeterministicだと良い事ってあるの？

はじめて見た。
Prolog
http://www.kprolog.com/doc/ja/language.html
えぐい言語ですね.

カットが宣言型言語としては不純だよな。

すくいage

批判スレでＯＯを熱く語るんじゃないage

煽られてこそ議論も白熱すると思われ

Modula-2の後継言語 Oberonを教えてください。

546です。 名前:738は意味ありません。

ねんちゃっくです。738はこれしか考えられません
http://pc.2ch.net/test/read.cgi/tech/1003815855/738

>>548 当たり!

sage

C言語でなんとかアプリ組めるようになってきたんで、次はオブジェクト指向
の言語をやろうと思ってます。

もう数年も「どの言語を覚えるべきか」について考えつづけてきたのですが、
私の目には Java が一番スマートで有望に思えます。今年から
情報処理技術者試験の科目にもなりましたしね。

なお Java が「サーバサイドばかり」という批判はまったく気になりません。
私が相手にすることになるのは基幹システムなど大きなシステムだからです。
別に GUI とかまで全部一つの言語でやらなくても気にはなりませんし・・・。

私の判断に何かコメントありますか？

>>551

どう見ても、Ｊａｖａ厨のネタ＆煽りなんだが。

こんな事書くと、「ネタじゃないです、真剣です。」

とか言われるんだろうか？

しまった、これ「Java死滅Part2」のスレに書き込んだ
つもりでした。

>>どう見ても、Ｊａｖａ厨のネタ＆煽りなんだが。

そーですね、潜在的 Java厨ですから、少し煽りはいってます.

JavaとC++の文法を勉強して、オブジェクト指向がなんとなく分かってきたけど、
実際にどうやってコーディングすれば良いのか分からない・・・

>>554
＞ JavaとC++の*文法を勉強*して、*オブジェクト指向がなんとなく分かって*きたけど
つっこみ希望の方ですか？

>>555
何もおかしくないと思うが？

>>554
初めは、そんなもんさね
っていうか、文法について言えば、
おおまかな使い方さえ知ってれば、さほど詳細にこだわらなくて良い

君は、ちょうどサッカーのルールを知ったくらいのレベル
ルール自体には、DFを何人、MFを何人なんて書いてないしね
さらに、ゾーンプレスなんてルールだけから思いつけるものではない
一般的に、ルールより戦術理解の方が重要
（ただし、審判なんかをやる人には、ルールの方が重要）

あの行き当たりばったり的な指導力がガンダルフの一番の魔法だ。

超誤爆

やっと分かったぞ .
クラス = システムに組み込みなリエントラント機構 ( オマ毛で継承機能付き )
だな .

>>558
いきあたりばったりなコーディングでもすげープログラムを書いてしまうのが
ウィザードというもの。カコイイ。
# もう公開されてるのか LoadOfRings ...

asage

プログラマ専用の護身術としてオブジェクト指弾とか
会社を辞めても安心の資格としてオブジェクト指圧とかやれば
儲かるんかなア。

真面目なオブジェクト指向のスレが埋もれてたんだね。
戦場やら幻想やらでアンチも懲りた頃のはずだし、こちらで真面目な話を
再開しませんか？

オブジェクト指向なプログラミング学習なら
本が沢山出てて選り取り緑だけど、それ以外の
OOAやOOD、OOにマッチしたプロジェクト管理
なんかのよい本が少なくないですが。

いまRUPの本を読んでいるのですが、少し抽象的で
具体例と結びつける作業が必要です。もう少し、
Tip的なものや、チュートリアル形式のの本や
サイトがあれば教えていただけないでしょうか？

>>564
真面目な話だとヲタ同士がヲタ用語連発して終わるので盛りあがらないのです。

おやおや、「真面目な」スレは沈むばかりですな（藁

>>564
言った瞬間、アンチがよってきて荒らす罠。

>>568
もう５日も経つけど、そうはならなかったという罠。

>>565

やはり自分でプログラム書くのが、早道なのでは。
急がば回れ。

信者隔離あげ

>>565
Unified Processで検索すれば書籍はそれなりに出てくる。
俺的には翻訳されてる本だけで十分だと思う。実践的な
内容は日々のルーチンワークにこそあると思えるから。

>>570
なんでそこでプログラミングの話になるんだよ。アホか？

>>572
15日前のレスに何反応してるのやら・・・。

マンセー派の方がレベルが低いと感じるのは私だけでせうか？？

http://www.nextengineer.com/browsing/pdf/NEXTENGINEER.pdf

>>574
マンセーもアンチもまともな人はこんなところ見てないだろ

必死になって、祭り状態を作ろうとしているヤツがいるな（ｗ　暇なのか？

ちょい微妙なのが、本当の意味でデキるプログラマにはオブジェクト指向は
あまり、必要性は無いといえば無いんだよね。

オブジェクト指向プログラミングってのは、デキる人がさらにデキるように
なるってよりは、デキない人も一緒にデキる人になりましょう、っていう、
プログラミング技法という感じ。

>>578
できるシリーズ読め
http://dekiru.impress.co.jp/books/index.htm

>>578
うそつきは消えろ

「デキるプログラマ」の指す範囲が狭すぎ。

zipなどのアーカイブの中身や普通のファイルからの読み込みを透過的に扱いたい。
たとえば、test/file.txtというパスが与えられた場合、test/file.txtが存在していれば
それをオープン、なければカレントディレクトリのtest.zipからfile.txtを読み込む、など。

こんな場合、みなさんならどんな設計をしますか？

578の言ってる事はとても的を得ていると思ふ

>>583

的を得るような人にはそう思へるのですね。（Kusakabe調）

そりゃそうだ
オブジェクト指向やテンプレートライブラリは
出来ない奴にも仕事をさせる為の道具として使うのが一番効率的


どっちにしても出来る奴は数少ない上、著作権だの何だのすぐ主張しやがるからな

>>584 デフォルトの名無しさん sage wrote:
>的を得るような人にはそう思へるのですね。（Kusakabe調）
的を射る、の間違いですね。

>>585
でも「出来なさすぎるやつ」とか「そもそもやる気のないやつ」に
OOをやらせようとすると、かえってめちゃくちゃになるんだよね。
そういうやつらって卑屈だったりして、遠まわしに反発されたりもするし。

オブジェクト指向を使えない人が捨て台詞を吐くスレはここでしたか。

使える所で使えば良い。
つうかごく一部でしか使えん。
よってＣ＋＋最強。

土日使って本買おうと思っているのですが
Cをそこそこかじった程度の人間でも理解できるような
若しくは皆さんお勧めの本を紹介してもらえないでしょうか？

>>590
http://pc.2ch.net/test/read.cgi/tech/1016722820/1

オブジェクト指向を解説しているすべての本は、なにを言っているのかわからない。

みんな裸の王様だと思う。

裸の王様の話のガキがあれからどうなったか知ってるかい？
仕立て屋といっしょに縛り首になったんだよ……

>>592
「あなたが理解出来ないもの」は、すべて「存在しないはずのもの」ですか？

>592
いま君が５００円玉で缶ジュースを買ったとしよう。
オブジェクト指向ではこう考えるんだ。
お金はただの「もの」ではなくて、
金額という性質と「ものを買う」機能
があるんだ。「買う」という指令を受
けると一定の金額だけ減らし、その減
った分が缶ジュースと交換されるんだ
ね。
気付いたかい？
このなかでどこにも君なんて登場しな
いんだ。オブジェクト指向の世界には
君なんかいないんだよ。

どうでもいいがＣ＋＋ぐらいのオブジェクト指向なら、
クラス → 変数型
オブジェクト → 変数
として
オブジェクトをがんがん使えばオブジェクト指向。

と言う理解ではだめ?

制御構造 -> while, for, until, if
データ -> 変数
として制御構造をがんがん使えば構造化プログラミング。

という理解でダメなのと同じようにダメ。

Object

オブジェクト指向で制作された最高傑作のソフトは何ですか？

Hello, World

WINDOWS

Smalltalk

HellowWould

オブジェクト指向は裸の王様
儲かるのは入門書書いてるヤツだけ

モナジェクト指向

amazon.com

数人でやる場合の難易度
(←高)
オブジェクト指向>>>>>>>>>>>コンポーネント指向

同じ所をぐーるぐる

>591
どうもです。

最近会社に泊まりっきりなので歯がオブジェクト歯垢でいっぱいです

ついでにチンコもオブジェクト恥垢でいっぱいです

さて、>>611の寒いギャグが一ヶ月放置された訳だが…

さて、>>612が書込まなければ、
その状態が２ヶ月でも３ヶ月でも続いていた訳だが…

>>612　>>613
そんなことより、オブジェクト恥垢とは何かを語りませんか？

隠蔽された恥垢

親から子に継承される恥垢

of Xect si chuo

まだあったのかこのスレ。ウザ。

いまどき「継承」かよ。(ﾌﾟ

VB 使いを小寒しますた

>>618 は、ウォーターフォールな分割詳細化設計で、
　内容の9割9分が重複してるシステム作って、
　「大規模SIは難しい」とか言っているんだろうなぁ

>>616
面白い！(笑

Delphiでオブジェクト恥垢を１から学習しようと思い、基本から作ってみたのですが、
実行後に例外が出ました。
どこがおかしいのでしょうか？

unit frmClass;

interface

uses
　Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
　Dialogs, StdCtrls;

type
　TForm1 = class(TForm)
　　Button1: TButton;
　　procedure Button1Click(Sender: TObject);
　private
　　{ Private 宣言 }
　public
　　{ Public 宣言 }
　end;
　TNum = class
　　num1, num2, num3: Integer;
　　function numChange(add: Integer): TNum;
　end;

var
　Form1: TForm1;

implementation

{$R *.dfm}

function TNum.numChange(add: Integer): TNum;
var
　n2: TNum;
begin
　n2 := TNum.Create;
　n2.num1 := Self.num1 + add;
　n2.num2 := Self.num2 + add;
　n2.num3 := Self.num3 + add;
　Result := n2;
　n2.Free;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
　n1: TNum;
begin
　n1 := TNum.Create;
　n1.num1 := 1;
　n1.num2 := 2;
　n1.num3 := 3;
　n1 := n1.numChange(3);
　ShowMessage('3足すと、num1=' + IntToStr(n1.num1) + ',num2=' + IntToStr(n1.num2)
　　　　　　　　　　+ ',num3=' + IntToStr(n1.num3));
　n1.Free;
end;

end.

//例外メッセージです。
---------------------------
デバッガ例外が発生
---------------------------
プロジェクト GUIClass.exe が EAccessViolation クラスの例外を生成しました。
'モジュール 'GUIClass.exe' のアドレス 004034D0 でアドレス FFFFFFFF に対する読み込み違反がおきました。'
プロセスは停止しています。再開するにはステップ実行または実行を選択してください。
---------------------------
OK ヘルプ(H)
---------------------------

>>620
618 には理解不能とおもわれ

n2.Free; が変。
Resultに代入しても、オブジェクトそのものはひとつなので、
計算結果を捨ててしまっています。

>>624
レスありがとうございます。

n2のフィールドの値をn1のフィールドに代入した後だから、Freeでインスタンスを捨てても良いのでは？
>>621で実行後に例外が出ましたと書きましたが、ShowMessageは正常に実行されて、その後に例外が出るという事です。
それとほぼ同様な感じでnumChangeメソッドの戻り値をIntegerにしてみたら、例外は無く実行されるので、
それ以外の部分に誤りがあると推測していたのですが…。

もう少し詳しく教えて頂けたら幸いです。

クラス型変数の代入はコピーでは無く参照先を変えるだけです。
まず、n1 := n1.numChange(3) で、元々のn1の参照先オブジェクトを見失ってメモリーリーク。
Result := n2 で、Resultとn2が同じオブジェクトを指しているのに、n2.Freeして、
その後同じオブジェクトをn1.Freeしているので2重解放。(恐らくここで例外)

n2.Freeで解放後の領域をアクセスして動いているのは、
直後なので同じメモリーが他の用途に使われておらず、内容が残っているためと思われます。

Delphiは歴史的に値型と参照型が混在していてしかもBoxingもGCも無いので
参照型(クラス、インターフェース)と他の型は区別して扱う必要があります。

>>625 = 俺
>それとほぼ同様な感じでnumChangeメソッドの戻り値をIntegerにしてみたら、例外は無く実行されるので、
>それ以外の部分に誤りがあると推測していたのですが…。
戻り値をIntegerにした時にn2 := TNum.Create; 、n2.Free;　を消してるので、この部分はおかしかったです。
何かを勘違いしてました、すみません。

>>626さん
ありがとうございます。

n2にn1が代入されるため、numChangeメソッド内でも n2.Free; = n1.Free; されてしまい、2重開放になるということは理解できました。
そこでもう一つ疑問なのですが、numChangeメソッドの n2 := TNum.Create; の一行を削除したら、再び例外が出ました。
破棄の時と同様に、これもインスタンスを2度生成しているような気がするのですが、こっちは必要の様ですね。
(オブジェクトはひとつなのに、2回生成するのはおかしいような…。)
その一行がどうして必要なのかが理解できないのですが、どうしてなのでしょうか？
こちらも教えて頂けたら嬉しいです。

仮に行列クラスがあったとして

x, y: TMatrix;
...
x := TMatrix.Create( ... );
y := x.Add( ... ); {*}

で、{*}の一行でxの内容が変わったら変でしょう？
使う側は

var
　n1, n2: TNum;
begin
　n1 := TNum.Create;
　n1.num1 := 1;
　n1.num2 := 2;
　n1.num3 := 3;
　n2 := n1.numChange(3);
　ShowMessage(...); {n2を表示}
　n1.Free;
　n2.Free;
end;

で、どうです？

>>621

なんとなく、普通はこうしそうな気がする

procedure TNum.numChange(add: Integer);
begin
　Self.num1 := Self.num1 + add;
　Self.num2 := Self.num2 + add;
　Self.num3 := Self.num3 + add;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
　n1: TNum;
begin
　n1 := TNum.Create;
　n1.num1 := 1;
　n1.num2 := 2;
　n1.num3 := 3;
　n1.numChange(3);
　ShowMessage('3足すと、num1=' + IntToStr(n1.num1) + ',num2=' + IntToStr(n1.num2)
　　　　　　　　　　+ ',num3=' + IntToStr(n1.num3));
　n1.Free;
end;

end.

計算結果を別オブジェクトで返すか、自身を書き換えるか…と問題を一般化してみる。

例えば、イテレータを進める時、Ite.Next; とするか、Ite := Ite.Next; とするか…皆さんどちら派？
もしイテレータではなく行列オブジェクトだったら？

>>627
> そこでもう一つ疑問なのですが、numChangeメソッドの n2 := TNum.Create; の一行を削除したら、再び例外が出ました。

そのままのソースで、単純に、n2 := TNum.Create; を削除したら、
次の行の、

n2.num1 := Self.num1 + add;

で、存在しない（Createされていない）インスタンス n2 にアクセスしようとしているのだから、
例外が出て当然。

n2をどうしても使いたいなら、n2 := TNum.Create;　n2.Free; を消して、
n2 := TNum.Create; の代わりに、n2 := Self;　って入れるとか(笑
意味はほとんど、>>629 と同じになるけど。

>>631 割り込みすいません......

>>630
イテレータは、Ite.Next のほうが、自然な気がする。
というか、Ite := Ite.Next; これだと、結局自分を書き換えてない？

代入させる場合だと、自分以外の変数に入れてやることができるけど
ただの代入だと結局、インスタンスは同じだから、別々に扱いたい場合は
自分の中でインスタンスのコピー作って返してやればいいのか・・・
ただ、それだと、コピーされたインスタンスの破棄には責任もてないし、
上みたいに、自分自身に代入してしまうと、元のインスタンスを見失って
メモリリーク起すから、扱いに気を使いそう・・・。
必要な時以外は、あまり使いたくない気がしてきた(笑

>>632 あ。気にしないでください。間に時間空いてるんで

>>633
interfaceを使えば破棄は自動化できますし。
Delphiに限った話でも無くGCのある言語なら尚更問題は無いし。

Ite := Ite.Next; 方式ですと、同一のイテレータを複数箇所が参照していても
勝手に書き換えられる心配が無いので
C#のstringがimmutableなのと同じ理屈で共有できますね。

みなさんありがとうございます、>>621でございます。
みなさんの書き込み見ると、まだ理解できてなかったっぽい…(汗

>>628さん
使う側の例でn2 := TNum.Create; してないのは、numChangeメソッド内で生成してるからですよね？
それに対して n2.Free; は使う側にありますが、このようなメソッドはpublicで他のユニットで使う時など、
メソッドのコードが見えないので、開放するのを忘れちゃいそうですよね？
これは(;;゜Д゜)ﾏｽﾞｰ

>>629さん
それの方がシンプルだし、自然っぽいですよね。
今は戻り値がクラス型なメソッドの勉強中なので、不自然ですが勘弁してください。

>>631
>n2をどうしても使いたいなら、n2 := TNum.Create;　n2.Free; を消して、
>n2 := TNum.Create; の代わりに、n2 := Self;　って入れるとか(笑
この方法は結局オブジェクトを二つ作るのではなく、
newChangeメソッド内でn1をあたかもn2の様に扱うということですね。
その方法だと、使う側でFree; しなくて良いので大変助かります。(笑)

>>635
>>628 のコードで生成と解放を同じ場所に書くようにするとすると、こんな感じかなぁ？
こうなると、n1のメソッドである意味がほとんどないけど(笑

function TNum.numChange(n2: TNum; add: Integer): TNum;
begin
　n2.num1 := Self.num1 + add;
　n2.num2 := Self.num2 + add;
　n2.num3 := Self.num3 + add;
　Result := n2;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
　n1, n2: TNum;
begin
　n1 := TNum.Create;
　n1.num1 := 1;
　n1.num2 := 2;
　n1.num3 := 3;
　n2 := TNnu.Create;
　n2 := n1.numChange(n2,3);
　ShowMessage(...); {n2を表示}
　n1.Free;
　n2.Free;
end;

要は、戻り値でインスタンスを返す以上、そのインスタンスの解放はメソッド抜けるまで
やっちゃダメなので、Freeを置くとしたら、外に置くしかない。
で、CreateとFreeはセットに、ってことで、Createも外置いて、呼ぶときに渡してやる、と。

ちなみに上のコードだと、最後の代入はあってもなくても同じだったり(笑

あとは、考え方を変えると、同じく >>628 のコードで、コードはそのまま

function TNum.numChange(add: Integer): TNum;
　　　　　　　　　　↓
function TNum.Create_And_numAdd(add: Integer): TNum;

とかね(笑
新しいインスタンス作ってるよ！と判るようにしてやる(笑

>>636
ありがとうございます。

>あとは、考え方を変えると、同じく >>628 のコードで、コードはそのまま

>function TNum.numChange(add: Integer): TNum;
　　　　　　　　　　↓
>function TNum.Create_And_numAdd(add: Integer): TNum;

>とかね(笑
>新しいインスタンス作ってるよ！と判るようにしてやる(笑
それもいいアイディアですね。
でもよく考えると、VCLのクラスでも、使用する際に生成・破棄しなくてはいけないので、
自作のクラスでもクラスないに生成・破棄コードを書くのは不自然なのかもしれませんね。

JBuilderも無料なのでJavaもやったことがあるのですが、
本を一冊読みましたが、インスタンスを破棄するという内容は出てきませんでした。
Javaではインスタンスの破棄はしなくてもいいんですかね？

>637
> Javaではインスタンスの破棄はしなくてもいいんですかね？
ガーベジコレクションって聞いたことない？

>>638
初耳でした。
本には書いてなかったですね。
JBuilderのヘルプ見たら項目はありましたけど、中身が見れませんでした。(泣)
でも、ガーベジコレクションが本に出てなかったってことは、破棄しなくてもいいのかな？
Google検索してみます！

>>638
なるほど、Java VMが勝手に使用しなくなったメモリ領域を使える様にしてくれるっちゅーことですね。
これは便利だ…。
ありがとうございます！

>>621以降、色々とＯＯについて教えて戴いた者ですが、また知りたいことがあるので質問させてください。
クラスは何のために作るのですか？
作り方はわかってきたのですが、実際に何かソフトを作るケースにおいて、どういう時に作って良いのかわからないのです。
ユニットを作ることにより、プログラムの再利用が容易にできるというのは聞いたことがありますが、
１回しか使わない物をクラス可する利点というのはあるのでしょうか？

>>641
> クラスは何のために作るのですか？
そこにクラスがあるから。

> プログラムの再利用が容易にできるというのは聞いたことがありますが、
まやかしです。

> １回しか使わない物をクラス可する利点というのはあるのでしょうか？
データ部は野ざらしにするより、アクセス関数とセットで管理した方が安全です。

>>639
ガベコレのってなかったの？
その本捨てちまえ

>>641
> クラスは何のために作るのですか？
オブジェクト指向をやろうとする場合に、一番クラスが利用しやすいから

> プログラムの再利用が容易にできるというのは聞いたことがありますが、
んなこたあない。必ずしもそうはならない。

> １回しか使わない物をクラス可する利点というのはあるのでしょうか？
642に同意

>>642-643
どうもありがとうございます。

>んなこたあない。必ずしもそうはならない。
一度作ったものをusesやimportに加えるだけで再利用できるのに、容易じゃなくなる場合もあるんですか？

>データ部は野ざらしにするより、アクセス関数とセットで管理した方が安全です。
野ざらし＝クラスに属さないという事ですよね？
それが理由なら、TForm1にフィールド変数やメソッドを追加すれば良いのでは？と思うのですが。

>ガベコレのってなかったの？
>その本捨てちまえ
ガベコレは載ってなかったけど、他の説明はわかりやすくて、とても良い本だと感じましたが。
ちなみに「Java本格入門(技術評論社)」っていう本です。

>>644
TForm1自体が、TFormから継承して作られたクラスだが・・・

例え再利用しなくても、プログラムの規模が大きくなってくると、人間の管理能力を
越えるようになってくる。その際にオブジェクト指向的な作り方をしてあると、
比較的管理がしやすくなる。

>>645
よくわかりました。
ありがとうございます。m(_ _)m

コンポーネントとクラスって違うのですか？
イメージがわかないです。

きっとわかってない

>>647
コンポーネントはクラスに含まれています。
Delphiだったら、クラスの中でTComponentを継承しているクラスをコンポーネントと呼びます。
俺は>>646なんで全然くわしくないけど、これは多分合ってます。(笑)

>>649

いや、あってないです。

それは単にDelphiでの話では？
コンポーネントって意味広いような。

なんか、難しいっすね。

インポの仲間です。
俺は>>646なんで全然くわしくないけど、これは多分合ってます。(笑)

皆さんの知識と技術を、こちらの板でも披露してください
http://pc.2ch.net/test/read.cgi/tech/1023986216/

オーバーロードってのは言うなれば、拡張子を変えるようなもんで、
オーバーライドってのは言うなれば、上書きってことでいいの？

>>655

オーバーロード：アシュラマン
オーバーライド：モンゴルマン

mage

オブジェクト指向なんぞ簡単だろ？

言語によって実装が違うから、各言語を行き来してるとストレスがたまる。

そうストレスが溜まる

ギコやモナー達はオブジェクト指向！
「公式設定」が存在しないので、だいたいの役割から
具体的なキャラクタを作り出している。