- 1 名前：仕様書無しさん mailto:sage [2007/03/29(木) 01:28:08 ]
- 過去スレ
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★4
pc11.2ch.net/test/read.cgi/prog/1173529414/
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★5
pc11.2ch.net/test/read.cgi/prog/1174746731/
スルー推奨ワード（相手をした場合は荒らしとみなされます）
電球、たかひろ
このスレは設計、実装含めた形でのOOに関する話題について語り合う目的で立てています。
なので設計だけ、実装だけといった縛りは特にありません。
設計には方針レベルからデザインパターンなどの実装設計レベルまで幅広くあります。
いままでの流れをみるかぎり、各々OOに対する考え方や適用レベルが異なるため、煽りや中傷のレスが書き込まれていますが、
書き込む方はどのスコープでOOを適用するかを伝えた上で書き込むのが良いかと思います。
- 560 名前：仕様書無しさん mailto:sage [2007/04/19(木) 21:13:55 ]
- むかしむかし、あるところに、OOでメッセージがどうのとか言っていた人
がおったそうな。
- 561 名前：仕様書無しさん mailto:sage [2007/04/19(木) 22:23:44 ]
- オブジェクト同士のメッセージのことだろ
普通じゃん
さすが仕様書読まない奴だけあるなｗｗ
- 562 名前：仕様書無しさん mailto:sage [2007/04/19(木) 22:42:35 ]
- >>551
うちは顧客にもUML（PJ内での拡張版）で説明する。
確かにサンプル画面は見てくれだけなら速いが、詰めが甘い。
そこでUMLで業務分析をした上で了承を取らんと。
コーディングが先でUMLを後で作るって時点で、おかしいだろ。
なんで分析ツールがあとで出てくるんだ？後だしならいらんし。そんなもん見らんわ。
つかさあ、担当者変わったあとでカスタマイズが入る度にソース全部追っかけてんのか？
めんどくない？
ソース＝仕様書ってのはオッケーだと思うが、
そのソース（仕様書）の分析をせずにコーディングするんだろ？
そこが謎。
あと他の奴も言ってるが、偽者うっとーしいからトリつけてくれや
- 563 名前：仕様書無しさん [2007/04/19(木) 22:57:29 ]
- 要求仕様書→UMLモデリング→顧客へ確認OK？→実装→だろ？
- 564 名前：仕様書無しさん mailto:sage [2007/04/19(木) 22:57:53 ]
- クラス図でも、分析モデルと実装モデルとは用途がちがうぞ。
- 565 名前：仕様書無しさん [2007/04/19(木) 23:01:11 ]
- UMLって描くのめんどいね
- 566 名前：仕様書無しさん mailto:sage [2007/04/19(木) 23:02:40 ]
- >>563
スレタイ【OOD/P】の意味わかるか？
- 567 名前：仕様書無しさん [2007/04/19(木) 23:03:36 ]
- 話題沸騰ポットを知ってるか？
- 568 名前：仕様書無しさん mailto:sage [2007/04/19(木) 23:08:39 ]
- >>566
OOAの話題はおいや？
- 569 名前：仕様書無しさん mailto:sage [2007/04/19(木) 23:11:38 ]
- >>568
どうぞ
- 570 名前：仕様書無しさん [2007/04/19(木) 23:15:49 ]
- OOD⊇OOAなんだけど？
- 571 名前：仕様書無しさん [2007/04/19(木) 23:16:44 ]
- ポットの水とかお湯とかって本質的に不要だろｗ
- 572 名前：仕様書無しさん mailto:sage [2007/04/19(木) 23:29:57 ]
- 全然おもしろくないｗ
- 573 名前：仕様書無しさん mailto:sage [2007/04/19(木) 23:31:13 ]
- ｗついてるやん
- 574 名前：仕様書無しさん mailto:sage [2007/04/19(木) 23:35:01 ]
- >>559
お前まさか読めんのか？
「読解力」だよ
- 575 名前：仕様書無しさん mailto:sage [2007/04/20(金) 11:41:34 ]
- >>559
>何が言いたいのか分からないな。
ばかだからでは？
- 576 名前：仕様書無しさん mailto:sage [2007/04/20(金) 12:44:32 ]
- 核心を突いてやるなってｗ
- 577 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/20(金) 22:53:29 ]
- >575
575の意見を思考停止という。
575はただの煽りとしても、思考停止を確信と核心する576には脱力だな。
まあ馬鹿じゃないんだろうけど、考えない癖がついているんだろうな。
でも何も考えない方が幸せになれるから、それはそれでいいのかもしれない。幸せになれよ。
- 578 名前：仕様書無しさん [2007/04/20(金) 22:55:46 ]
- 厨房だな・・・・
- 579 名前：仕様書無しさん mailto:sage [2007/04/20(金) 22:57:15 ]
- アドレナリン中毒の愚かな野生動物だからな。
- 580 名前：仕様書無しさん mailto:sage [2007/04/21(土) 00:38:13 ]
- >577
おもしろくありません
もうすこしがんばりましょう
- 581 名前：仕様書無しさん [2007/04/21(土) 01:18:03 ]
- 何だかんだ言って、技術ってすぐに過去のものになっちまうよな
- 582 名前：仕様書無しさん mailto:sage [2007/04/21(土) 01:26:46 ]
- とはいえ今ある技術について行かなきゃ、次の技術が理解できないしな
- 583 名前：575 mailto:sage [2007/04/21(土) 01:42:47 ]
- >>577
そう、ただの煽りです。
でも、見たままの感想ですよ。
自分では気づいていない (莫迦故に) でしょうけれど。
>思考停止を確信と核心する
ほら。
- 584 名前：仕様書無しさん mailto:sage [2007/04/21(土) 01:46:12 ]
- つまらん
- 585 名前：仕様書無しさん mailto:sage [2007/04/21(土) 01:52:40 ]
- 鳥付けてんのは偽もんだろ
モノホンは鳥も付けれんほど馬鹿だから
- 586 名前：仕様書無しさん mailto:sage [2007/04/21(土) 02:02:47 ]
- アドレナリンからかうと面白いな。
アフォな事言い出してる所に水を向けると
10も20もレスを返してくる。
心にゆとりがないというか、
愚かで劣等感に苛まれている可哀想な人というかｗ
- 587 名前：仕様書無しさん mailto:sage [2007/04/21(土) 02:06:05 ]
- おじゃばが食いつけそうなネタふることさえ出来なくなっちゃったの？
かわいそうにｗ
- 588 名前：仕様書無しさん mailto:sage [2007/04/21(土) 02:46:25 ]
- ・基本的にスルー力が足りないのだと思う。
・「荒しに反応するのは荒し」という経験則が、
荒し検出に非常に有効である事が再確認できた。
・同様に「キ○○○という単語に過剰反応を示す奴は、
たいてい本人がキ○○○」という経験則が得られた。
- 589 名前：仕様書無しさん mailto:sage [2007/04/21(土) 03:12:24 ]
- オブジェクト指向で説明せよ
- 590 名前：仕様書無しさん mailto:sage [2007/04/21(土) 03:19:09 ]
- 猫はにゃーにゃーと鳴き
犬はわんわんと鳴き
蝙蝠は黙して語らなかった
- 591 名前：仕様書無しさん [2007/04/21(土) 10:40:03 ]
- キチガイ、キチガイ、キチガイ、これがオブジェクト思考でつ
- 592 名前：仕様書無しさん mailto:sage [2007/04/21(土) 11:03:19 ]
- VIPと間違えた。
- 593 名前：仕様書無しさん mailto:sage [2007/04/21(土) 17:30:29 ]
- オブジェクト指向での製造方法を学ぶためには、
どういう点に注意したらいいですか？
クラスやインスタンスや継承など言語技術は理解していますが、
どうしても機能重視になってしまいがちで、
本質的に間違ってるという気持ちがあります。
- 594 名前：仕様書無しさん mailto:sage [2007/04/21(土) 17:36:46 ]
- ほんとにやる気あるなら、メイヤーのオブジェクト指向入門よめ
- 595 名前：仕様書無しさん mailto:sage [2007/04/21(土) 17:38:56 ]
- >>593
使う言語に応じてチームが使いやすいように設計すればいいよ
オブジェクト指向に本質とか意味ないし
但し一人よがりな設計はやめよう。チーム全体で理解出来るようにね
って書くと口だけで実践ともなってない奴とかがしゃしゃりでてくるんだろうけどなww
- 596 名前：仕様書無しさん mailto:sage [2007/04/21(土) 19:04:00 ]
- なんだ似非コンサルの事か。
自覚症状があるならさっさと引退すればいいのに。
- 597 名前：仕様書無しさん mailto:sage [2007/04/22(日) 07:56:46 ]
- >>581
技術って集中を分散の間を
ぐるぐる回っているだけだから、
止っていたら戻ってくるよ。
- 598 名前：仕様書無しさん mailto:sage [2007/04/22(日) 09:31:34 ]
- シンプルに考えることを常に心掛けること。
デザインパターンが素晴らしいのもシンプルな考え方だからだね。
流行りものは、そこから概念だけを見切って、自分のフォースに取
り込むこと。がんばれ。
- 599 名前：仕様書無しさん mailto:sage [2007/04/22(日) 09:45:26 ]
- 「概念だけを見切って、自分のフォースに取り込む」＝半島人が俺様解釈でパクる行為のこと
- 600 名前：仕様書無しさん [2007/04/22(日) 10:06:34 ]
- 俺様解釈が新しいパラダイム生む。
- 601 名前：仕様書無しさん mailto:sage [2007/04/22(日) 10:30:46 ]
- 池沼の戯言
- 602 名前：仕様書無しさん [2007/04/22(日) 11:37:15 ]
- 最初からＯＯで入るからでしょ。
ＯＯが生まれた理由も価値もわからず、ＯＯを習うから結局、ＯＯが生まれることになった原因と同じような
ことを繰り返している。
gotoレスが叫ばれた時代と同じ。なにも考えずなにも疑問に思わないやつが使ってるから結局、元の木阿弥。
- 603 名前：仕様書無しさん [2007/04/22(日) 15:13:56 ]
- 価値が分かるの４０代？
- 604 名前：仕様書無しさん [2007/04/22(日) 16:41:40 ]
- そんなことないだろ、新興会社でなきゃ、古い顧客も抱えてるから自然に触れるだろ過去のシステムも
- 605 名前：仕様書無しさん [2007/04/22(日) 17:23:46 ]
- ウインドウ＝スレッドと思ってる香具師。
- 606 名前：仕様書無しさん mailto:sage [2007/04/22(日) 20:05:01 ]
- モードレスダイアログのウィンドウプロシージャって別スレッドだっけ？
- 607 名前：仕様書無しさん [2007/04/22(日) 20:31:16 ]
- だめりゃコリャｗ
- 608 名前：仕様書無しさん mailto:sage [2007/04/22(日) 21:15:29 ]
- >>602
なんで伏字なんだよ。
と誤解されるのが日本で流行らない理由だな。きっと。
- 609 名前：仕様書無しさん mailto:sage [2007/04/22(日) 21:16:48 ]
- せめて半角英数で書けばいいものを
- 610 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/23(月) 09:50:46 ]
- >593
言語仕様を理解しているなら次は「物をクラスで表現する事」だ。
まあ概念を説明しても今までと同じになってしまうので、実装方法から説明しよう。
機能で考えるてしまうと言うので、非OOでのC言語は理解していると仮定する。
まず構造体の要素を、クラスのprivateのフィールド変数に定義する。
次にそれぞれの変数のゲッターセッターを作る。そして機能毎に考えていた関数を分解して、
ゲッターとセッターの中に入れ込む。ちなみに機能毎に考えていた関数と、入れ込むゲッターは1:1に
なるとは限らない。どうしても入らない部分は、適当なメソッドを作って入れておく。
すべてのクラス分けが終わったら、一旦休憩した後に、もう一度クラスを見直す。
この時にクラスに相応しくないフィールド変数やメソッドがないか確認する。
例えば「商品クラス」に「顧客」の情報が入っていないかなどの確認だ。
ここで相応しくないと思った変数やメソッドは、相応しいクラスに移動する。適切にメソッドを作って
あれば、フィールド変数と関連するメソッドの移動だけで済む。ここでメソッドを移動しようとすると
別の変数を参照していて移動出来ないとか発生するが、これがうまくメソッド分けされていない部分である。
もう一度その部分を考え直して分離する。分離した時に前より複雑にならないように心掛ける。
- 611 名前：仕様書無しさん mailto:sage [2007/04/23(月) 10:09:54 ]
- 堕ちコン
- 612 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/23(月) 19:30:33 ]
- 次に重要なのは「仕様変更を繰り返す」事だ。仕様変更を行う度にクラスを見直す事になるが、
正しく抽象化されていると、変更を繰り返しても構造が悪化しない。
悪化どころか、仕様変更の度に抽象度が増して、洗練されて行くのを感じるようになるだろう。
まあ、これを体感出来るようになるのは、普通の人で1〜2年ぐらいかかるから焦る必要はない。
ちなみにデザインパターンや専門書は、上記の抽象化をマスターしてから見た方がいい。
抽象化も知らずにいきなりデザインパターンや専門書を見て、OOを理解出来る人などいないと思う。
- 613 名前：仕様書無しさん mailto:sage [2007/04/23(月) 21:25:09 ]
- で？
このコテの文章って冗長なだけで
主観ばっかで何が言いたいかわからん
- 614 名前：仕様書無しさん mailto:sage [2007/04/23(月) 22:28:40 ]
- 作文だろ。文章能力を2chを使って養ってんだと思う。
素養の無さからくる整合性の欠落や、曖昧さ、そして中々上達
しないその様は見ていて痛々しいが、本人も一生懸命らしい。
ま、ほっといておいてやれ。
多分、この人の周りには、彼以上に優秀な人がいないのだろう。
そういう環境に長年浸って、自分を人一倍優秀だと勘違いして
しまったのだと思う。ある意味可哀想ではある。
- 615 名前：仕様書無しさん mailto:sage [2007/04/23(月) 23:53:44 ]
- >>610
private変数のゲッターやセッターを作るんだったら
最初からpublicにすればいいと思ったのですが、
何か間違っているでしょうか？
ゲッター・セッターメソッドがづらづらと並ぶことにもなりますし、
変数が直接触れない以外、メリットがよく分かりません。
- 616 名前：仕様書無しさん mailto:sage [2007/04/23(月) 23:55:51 ]
- >>610
アクセッサにロジック入れるのかよ(゜д゜)
- 617 名前：仕様書無しさん mailto:sage [2007/04/24(火) 00:01:57 ]
- >>615
いやそうじゃない。private変数にはカプセル化の利点がある
いまさらそんな事言うまでもないがな。
つまりだ、お前は根本的に考え方が間違っている
りかい出来るまでは、オブジェクト指向の本を読みあさるんだ。
だんかいを踏んで、徐々に理解した方が今後の為にもなる。
なん度も繰り返しオブジェクト指向で考えれば必ず身に付くから。がんがれ
- 618 名前：仕様書無しさん mailto:sage [2007/04/24(火) 00:06:43 ]
- >>617
レスありがとうございます。
ゲッターとセッターはprivate変数１個に対して１つずつ書くのですか？
これはカプセル化はカプセル化ですが、必要性がよく分からず・・・
private
int a;
int b;
public
getA();
getB();
setA();
setB();
- 619 名前：仕様書無しさん mailto:sage [2007/04/24(火) 00:11:14 ]
- オブジェクト指向の本を読みあさった俺でも、
setter、getterをづらづら並べ、それをカプセル化言うのは何かが違うと感じる。
- 620 名前：仕様書無しさん mailto:sage [2007/04/24(火) 00:20:08 ]
- 気分的にはもうちょっと壊滅的に壊れてほしいな
ずいぶん手間隙かけたんだし
- 621 名前：仕様書無しさん mailto:sage [2007/04/24(火) 00:23:39 ]
- つーか、どこの莫迦が getter/setter なんて発想をし始めたんだろう。
インスタンスの「状態」を戻す、あるいは変更するのが目的なんだから
内部変数と対応している必要なんざこれっぽっちもないってのに。
- 622 名前：仕様書無しさん mailto:sage [2007/04/24(火) 00:27:58 ]
- >>621
入れ物として使われ始めたのはbeansからじゃね？
- 623 名前：仕様書無しさん mailto:sage [2007/04/24(火) 02:59:00 ]
- 極論すれば、Publicにするのは、インターフェースに限定するのが理想的。
内部変数はPrivateにして、公開しないのが原則。しかし場合によっては、
クラス内部でカウントされた値や、集計値などを公開する必要があるだろう。
その場合は、その値を、ゲッターとして実装し公開する。セッターはそのク
ラスの要件として必要な場合に限り公開する。
セッターは、グローバル変数に匹敵するぐらい危険な要素を孕んでいるこ
とを認識するべき。常に外部からの変更の可能性を考慮しないとならない
ため、人がコードを読む際にかかるストレスも大きくなる。private変数は
クラス外部からの変更の可能性は排除できるので、スコープを絞って集中
してコードを追うことができる。またメンバ変数は、そのクラスの機能を実現
するための必要最低限のものだけにするべき。当たり前だが、計算に使う
一時変数等をメンバ変数にしてはいけない。これもコードの可読性に関わっ
てくる。不要な情報は極力排除し、クラスのメンバとするべきではない。
OOの手法は開発時というより寧ろ、変更や保守性、拡張性といった方面での
貢献が大きいものだと思う。ゲッター、セッターを使うことで、値の代入に
対する仕様の変更があった場合に、その対応ロジックを１箇所に集中するこ
とができる。ゲッター、セッターを使わず直接代入していた場合、その代入
箇所すべてを変更しなければならないかもしれない。いわば事前にかけてお
く保険みたいなものだ。変更や保守がされないソフトウェアというものはな
いのだから。
- 624 名前：仕様書無しさん mailto:sage [2007/04/24(火) 03:24:29 ]
- つーか、そんなに直代入使うか？
OOPやってると、セッタ自体滅多に使わないと思うんだが。
- 625 名前：624 mailto:sage [2007/04/24(火) 03:45:06 ]
- ちと言葉足らずか。
単に値チェックして代入するだけのセッタなんて使うか？
って訂正しとく。
- 626 名前：仕様書無しさん mailto:sage [2007/04/24(火) 09:15:50 ]
- 様々な言語で提供されるほとんどの文字列クラスにセッターがないことに気づいているか。
文字列長？ そんなもの内部で適切に管理されている。中身を変更したい？ copy-on-writedだ。
つまりよい設計とはそういうものだ。必要の無いものは提供しない。よく分からないけどこの
メソッドはPublicにした方がいいかなぁ。と思うならPublicにするな。公開する時は信念をもって
公開しろ。無計画にメソッドやプロパティを公開してはならない。徒に混乱の種をばらまくような
ものだ。
- 627 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/24(火) 09:51:46 ]
- >615
ちょっと説明が足りなかったようだ。
確かに値を設定／取得するだけのメソッドなら、publicにしたのと変わらないと思うかもしれない。
しかしそれは慣れないうちは最初にそうした方がいいと言う事で、作った後から要らない物は削除したり
統合したりして構わない。
例えば、セッターが10個あるとしよう。もし文字列を読み込んで分解して、それぞれを設定する場合しか
なかったとする。その場合いはセッター10個を削除して「void setRecord(String rec)」の1つにしてもいい。
また、設定ファイルを表すPropertyFileと言うクラスを作ったとする。
内容は「No:RECORD」が数十行続くレコードだったとしよう。
読み込みはファイル、取得はNoを指定してRECORDを取得するだけだとする。
その場合、セッターを全て廃止して「boolean read(String fname)」にして、ゲッターを
「String getRecord(int no)」の1つに集約してもいい。
慣れているならゲッターやセッターを作らずに、最初からこれでも良い。
これが進むと変数が隠蔽され、抽象化が進む。
- 628 名前：仕様書無しさん mailto:sage [2007/04/24(火) 10:32:35 ]
- 腐れコテがコテを付けたり外したりしながら独り言を書くスレ
- 629 名前：仕様書無しさん mailto:sage [2007/04/24(火) 11:51:28 ]
- 相変わらず主観だらけで冗長なだけ
挙げ句どっちかっつーと個人の感想止まりやんｗ
- 630 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/24(火) 19:16:08 ]
- >629
うるせーバカ。少しは頭使え、カス。
と、簡潔に書いてみた。
- 631 名前：仕様書無しさん mailto:sage [2007/04/24(火) 19:19:37 ]
- de?
- 632 名前：仕様書無しさん [2007/04/24(火) 19:25:47 ]
- >>630
うるせーバカ。少しは頭使え、カスキチオジャバ
- 633 名前：仕様書無しさん mailto:sage [2007/04/24(火) 19:30:43 ]
- >>627
そのような”機能分類”したメソッドが存在するのは
すでに今まで自分でもうやってた手法です。
レコード文字列渡して必要なところだけセットする、とか。
もちろんprivateにするべきところ（と思ったところ）はそうしていました。
でも、これってオブジェクト指向って言うのでしょうか？
構造化プログラムとの違いがよく分からなくって・・・
違いといえばクラスと構造体ぐらいで、
構造体自体が関数持ってますよ（クラスで操作しますよ）、
ってぐらいしか違いが無いように思えるんです。
- 634 名前：仕様書無しさん mailto:sage [2007/04/24(火) 19:34:01 ]
- >>630
昔の口調に戻ったな。うんうん。
やっぱりお前の知能程度にはそれくらいが丁度いい。
- 635 名前：仕様書無しさん [2007/04/24(火) 19:37:21 ]
- >>633
もう1段階上の抽象化があるのだよ
- 636 名前：仕様書無しさん mailto:sage [2007/04/24(火) 20:21:27 ]
- ちゅうしょーかっ！ ってタカアンドトシもゆってた。
- 637 名前：仕様書無しさん mailto:sage [2007/04/24(火) 20:29:03 ]
- >>628
要するに基地害の寝言スレ
- 638 名前：仕様書無しさん mailto:sage [2007/04/24(火) 22:43:03 ]
- つまりは良く考えて作りなさいよ。ということだな。
- 639 名前：仕様書無しさん mailto:sage [2007/04/24(火) 22:58:18 ]
- そうそう。お前の親に言っとけ
- 640 名前：仕様書無しさん mailto:sage [2007/04/24(火) 23:03:48 ]
- ほんとになぁ・・・
- 641 名前：仕様書無しさん mailto:sage [2007/04/24(火) 23:16:26 ]
- setter,getter作るだけでカプセル化とか、setter,getterを必ず作るとかいうアホが湧いとるな
とくにわけの分からんクソコテ
痛い突っ込みされてまたわけのわからんこと言うとる
中途半端にOOを知ってる奴が一番タチが悪い
- 642 名前：仕様書無しさん mailto:sage [2007/04/24(火) 23:17:09 ]
- でも構造化設計が最高！ソースも見やすいしね。
オブジェクト指向は、部品だらけで、組合せがソースから見えないよ！
- 643 名前：仕様書無しさん mailto:sage [2007/04/24(火) 23:20:18 ]
- ソースをテキストで作るのはもう古いのでは？！
- 644 名前：仕様書無しさん mailto:sage [2007/04/24(火) 23:33:45 ]
- >643
これからの時代はパンチカードだな
- 645 名前：仕様書無しさん mailto:sage [2007/04/25(水) 00:31:55 ]
- 縦読みが３０分も放置されてる・・・
- 646 名前：仕様書無しさん mailto:sage [2007/04/25(水) 03:34:45 ]
- >645
どれ？
- 647 名前：おじゃばさま ◆GxjxF3yEw6 [2007/04/25(水) 09:28:37 ]
- >633
メソッドが機能になるのは正しい。次に問題になるのが「クラスが物を表しているか」だ。
これがオブジェクト指向と呼ばれる所以になる。誰かが言っていたもう一段階の抽象化も多分これだろう。
落ち着いてクラスを見て、クラスが「商品」や「利用者」などの物になっていて、それらに関連する
フィールド変数とメソッドで構成されているればOKだ。
そして前にも書いたが、そうなるように変数やメソッドを移動する。
構造化の考えだと機能重視になって、クラスが「書き込み」や「計算」などの機能になって、単に書き込み
メソッドを集めたメソッド集や、計算を集めたメソッド集になってしまう事がある。これはNGだ。
ただし分かりにくいのは、「物」と言ってもまれに目に見えない物をクラスにする必要があると言う事だ。
前のオセロの例で言うと、「ゲームのルール」などである。
またまれに、機能なのか物なのか微妙な物や、ある場合では物になる機能などもある。
例えば先ほどの「書き込み」もWriter（書き込む人）などにして、物として扱う場合もある。
まあこのあたりは最初から考えると分からなくなるので、そういう場合もまれにあるという認識だけあればいい。
- 648 名前：仕様書無しさん mailto:sage [2007/04/25(水) 10:44:27 ]
- >>633
な？訊くだけ無駄だったろ？
- 649 名前：仕様書無しさん [2007/04/25(水) 11:11:18 ]
- 糖質との会話は、はたで見てる分にはとても滑稽だ。
常に話題がずれていき、二度と元の話に戻ってこない。
- 650 名前：仕様書無しさん mailto:sage [2007/04/25(水) 11:13:42 ]
- >>648
同意。
>>647のようなレスでは出来上がったものを「盲人象をなでる」様に評しているだけに過ぎない。
>>633は（ここでの表現を使えば）「もう一段上の抽象化」をなしえるための方法論、
およびその方法論の背景となるパラダイム自体をたずねているのに
全く回答になっていない。
素直に「わかりません」と回答するほうが簡潔でわかりやすいワイ
- 651 名前：仕様書無しさん mailto:sage [2007/04/25(水) 11:37:18 ]
- >>649
へー等質なんだ。
- 652 名前：仕様書無しさん mailto:sage [2007/04/25(水) 11:49:50 ]
- アホコテのひとは3行で的確にまとめるように努力してみては。
あまりにもイミフで哀れ。
- 653 名前：仕様書無しさん [2007/04/25(水) 11:54:17 ]
- 確かに。
自分が言いたいことをダラダラ書いているだけだから読む気がしない。
読む側の事を考えていない。
まさにコーダー。
コミュニケーション出来ないのは自明だが、コードも冗長なんだろうなと思ってしまうね。
- 654 名前：仕様書無しさん mailto:sage [2007/04/25(水) 12:30:07 ]
- 構造化設計でいう所謂モジュールと、オブジェクト指向のクラスとの一番の
大きな違いはその集合体のインスタンスを生成できるかできないかじゃまいか。
複数のインスタンスを生成しないでいい、つまり一つのインスタンスだけでい
い場合はモジュール的な使い方とほぼ同じだと思う。
その場合は、メンバを全てクラスの静的メンバにするとか、シングルトンパ
ターンやモノステートパターンにするとかOO的な工夫はあるけど、つまりは
メソッドやプロパティを集めたモジュールと同じような使い方になる。
- 655 名前：仕様書無しさん [2007/04/25(水) 13:12:44 ]
- デザインパターンなんか実際に使ってる人いるの？
業務系だけ？
- 656 名前：仕様書無しさん mailto:sage [2007/04/25(水) 13:27:57 ]
- >>654
うん。
インスタンスを複数作れるという点が大きな違いではなかろうか
- 657 名前：仕様書無しさん mailto:sage [2007/04/25(水) 13:34:30 ]
- >>655
君のように理解できてない人は使ってないでしょうね、少なくとも。
- 658 名前：仕様書無しさん [2007/04/25(水) 13:54:31 ]
- 657は理解できてるように思えないけど
理解できてる人はどこに使ってるの？
- 659 名前：仕様書無しさん mailto:sage [2007/04/25(水) 16:37:00 ]
- 例えば、商品リストを表現しようとすると、構造化の場合、商品という構造体と
その商品構造体の集合を保持するリストや配列、そしてそれらを検索したり、
追加したりするアルゴリズムをいっしょくたにして管理してしまいがちになるけど、
オブジェクト指向の場合、商品クラスとリストクラスを使ってそれぞれの特性や
役割を分離して表現できるんだな。つまり、構造化の場合、本来役割の違う
データ構造同士が密接に結合してしまいがちだが、きれいにクラス設計された
オブジェクト指向では、クラス同士が疎結合となり、それぞれの役割が明確にな
るため、保守性や拡張性が向上するんだな。しかし、設計や実装が汚いとメリット
を充分に享受できないどころか、人によってはＯＯアレルギーを招きかねない。
構造化の場合もいえることだが、ＯＯの有効性を充分に生かすためには、きれ
いな設計と実装が必須となる。
- 660 名前：仕様書無しさん mailto:sage [2007/04/25(水) 21:03:18 ]
- >>655
「OOPに慣れた奴は自然と使ってるパターンがあるが名前が無く
どういうパターンと言われても説明が長くなる」
というモノに名前を付けたのがデザパタだろ？
だからちゃんと使えてる奴は意識せずとも使ってるのさ
|
 |
