5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

分かり始めたオブジェクト指向

1 :仕様書無しさん:04/11/10 14:16:32
結局一長一短、使わなくても差し障り無いって事でFA?

前スレ
http://pc5.2ch.net/test/read.cgi/prog/1094395462/

2 :仕様書無しさん:04/11/10 14:17:48
【関連スレ】
マ板のPGにオブジェクト指向を覚えさせたい!
http://pc5.2ch.net/test/read.cgi/prog/1081700132/l20
ガンダムでオブジェクト指向を語るスレ
http://pc5.2ch.net/test/read.cgi/prog/1068040637/l20

【過去スレ】
結局オブジェクト指向って
http://pc3.2ch.net/prog/kako/1080/10807/1080724890.html
オブジェクト指向を理解できんとが何で悪いとや?
http://makimo.to/2ch/pc_prog/1060/1060622436.html

オブジェクト指向は戦場では必要なし
パート1 http://pc.2ch.net/tech/kako/1011/10119/1011997945.html
パート2 http://pc.2ch.net/tech/kako/1013/10132/1013266554.html
パート3 http://pc.2ch.net/tech/kako/1013/10138/1013875413.html
パート4 http://pc3.2ch.net/tech/kako/1021/10214/1021468476.html
パート5 http://pc3.2ch.net/tech/kako/1027/10279/1027983898.html
パート6 http://pc3.2ch.net/tech/kako/1029/10292/1029297075.html
パート7 http://pc3.2ch.net/tech/kako/1030/10300/1030029357.html
パート8 http://pc3.2ch.net/tech/kako/1031/10310/1031028125.html
パート9 http://pc3.2ch.net/tech/kako/1032/10329/1032985885.html
パート10 http://pc.2ch.net/prog/kako/1033/10339/1033919004.html

3 :仕様書無しさん:04/11/10 14:20:12
スレタイ、解りが正しくないか?


4 :仕様書無しさん:04/11/10 14:24:45
> 結局一長一短、使わなくても差し障り無いって事でFA?

前スレの最後の方で議論されたように業務アプリの場合な

# 結構ナイスなスレタイだ。それは誉めてやる。

5 :仕様書無しさん:04/11/10 14:25:28
>>3
理解するほどの事じゃないという事情が分かったという意味です。

6 :仕様書無しさん:04/11/10 14:26:56
オブジェクト指向使わない奴は馬鹿。
シンプルデザイン極める為に必須。

7 :仕様書無しさん:04/11/10 14:30:41
マンコ

8 :仕様書無しさん:04/11/10 14:31:13
          ;' ':;,     ,;'':;,
       ;'   ':;,.,.,.,.,.,,,;'  '';,  ブフッ
      ,:'           `:、
     ,:'    /' '\     ',
     ,:'    -・=-, 、-・=-    ;'
     ;     ノ( 、_, )ヽ     ;'  またクソスレか
     ';,    ノ、__!!_,.、    ;'
     `:、    ヽニニソ   .,;:''  
       ';             '':;,
       ';             ';,  ,;`;,
       ';              ':,;' ;'
       ';               ;:,:''
      ;"   "; .,.,..,.,., ;"   "; .,.,.;''
       "''''''''"     "'''''''''''"

9 :仕様書無しさん:04/11/10 14:32:44
明日を乱すことさ

10 :仕様書無しさん:04/11/10 14:37:11
誰かに伝えたいよ

11 :仕様書無しさん:04/11/10 14:43:38
で、結局コード量減るってのは真実?

12 :仕様書無しさん:04/11/10 14:48:15
うまく抽象化で来てれば減ることが多いだろうが、コード量が減るか減らないか議論しても生姜ない

13 :仕様書無しさん:04/11/10 14:54:08
「分かりました」と「解かりました」で意味が違うわけか。
どうりで・・・

14 :仕様書無しさん:04/11/10 14:54:26
一概に減るわけじゃないよね。
バッチ処理向きのものを、オブジェクト指向で作った場合は確実に増える。

問題は、メンテナンス性、拡張性が本当にあるのかじゃないの?
既存への影響に対して本当に強いのか。

まあ、議論の前提として屑が作ったものって言うのは排除しておく?
それとも屑が作ってもメンテナンス性が保てることも議論する?


15 :仕様書無しさん:04/11/10 14:56:39
コード行数で見積もりが決まるんだけど、
ならオブジェクト指向的な作りにしない方が稼げるって事か・・・

16 :仕様書無しさん:04/11/10 15:12:13
>>15
それはまたレトロなところで。
行数って結果として請求するの?
それとも見積時の単位として行数を求めてきてるの?

後者だとすれば、その行数ってのは単なる単位だから、別に最終的に逆算すればいいんじゃないの?
(このシステムなら何人月->1日あたりの生産効率=nKSだから、結果xKSっていう見積)




17 :仕様書無しさん:04/11/10 15:12:19
> 結局一長一短、使わなくても差し障り無いって事でFA?

あのな、ほとんどの技術は長所と短所を備えてるんだよ。
何が長所で何が短所か、どうやったら長所の恩恵があって、
短所の影響が出ないかを知るのが技術を学ぶってことだろ。
勧善懲悪の次が諸行無常なんて、ガキかよ。

18 :仕様書無しさん:04/11/10 15:51:58
>>15
コメントで行数稼げ!!!!

19 :仕様書無しさん:04/11/10 17:00:32
   :::         ,.- ..,                  :
.   :        ,゙   ゙ ' ‐ ‐ ‐/⌒ヽ' ' ゙ ',    ..:::..
.     ∧     :          .! ,.γ⌒ヽ ;    ::
    <  '7   ,'゙        ゙'‐-ヘ,   ノ.,⌒)
     レt-! . ,'            ~ ^ヾ_ノ
       !‐‐┼-                  ;
       !‐┼- (●),     、(●)、 ー┼-
         !.‐十   ,,ノ(、_, )ヽ、,,     ‐┼-   ウフフ
        ,.!- ヽ、  `-=ニ=-       ゙メ、
        ',.と   ゙ ッ‐,-.,.,.,.,.,.,.,n‐ッ, ‐ ' ゙
.          ` !、  ./  ゙' -∠ィ^'゙    ゙ヽ、
           `.7 .,‐^- 、  ゙ヽ、    i

20 :仕様書無しさん:04/11/10 17:01:26
    :::         ,.- ..,                  :
 .   :        ,゙   ゙ ' ‐ ‐ ‐/⌒ヽ' ' ゙ ',    ..:::..
 .     ∧     :          .! ,.γ⌒ヽ ;    ::
     <  '7   ,'゙        ゙'‐-ヘ,   ノ.,⌒)
      レt-! . ,'            ~ ^ヾ_ノ
        !‐‐┼-                  ;
        !‐┼-   '-=・=-'  '-=・=-'  ー┼-  
          !.‐十      ○      ‐┼-
         ,.!- ヽ、     Д       ゙メ、 コメントで行数稼げ!!!!
         ',.と   ゙ ッ‐,-.,.,.,.,.,.,.,n‐ッ, ‐ ' ゙
 .          ` !、  ./  ゙' -∠ィ^'゙    ゙ヽ、
            `.7 .,‐^- 、  ゙ヽ、    i
    ..::..      ノ   ι、r'     ヽ、,._ノ
 .     ::       ,∠..,,_     ゙         >   .:.
           ` ''! ゙ヽ.,, _ _     , イ   ...:: ::...
                 ヽ、  ヽ、  ̄  ,ノ    :: ::
                ゙ ' ' ゙   ゙ ' ' ゙

21 :仕様書無しさん:04/11/10 18:40:03
  ∧ ∧          ゝ、  丿 ((   ) ) 丿
 ( ´・ω・)         (  )( )/⌒ヽ ( (丿
/    \          ( )((/ ;`Д´ )丿 ) )
| r     r.\__  n   。(,..。.| ゚。  / o.._ノ
l |    |\___⊂(⌒)二| ̄ ̄ ̄ ̄ ̄ ̄ ̄|
| |    |        ̄ 从\从从从从从 /从

22 :仕様書無しさん:04/11/10 18:41:39
>>16
見積もり時の単位として行数を求められます。
ただし開発が終わった時点で行数カウントツールで計測され、
次期開発の見積もりに活かされます。係数は顧客が保持する数値です。
(OO言語の値かは謎です。ウォーターフォール基本だし)

リファクタリングでコードが減って品質が上がる、
わかっちゃいるけど重複コード量産の毎日です。

ちなみに空行、コメント行はカウントされません・・・

23 :仕様書無しさん:04/11/10 18:44:58
苦労して習得するほどの価値は無いな。手当て付かないし。

24 :仕様書無しさん:04/11/10 18:49:23
なにごともほどほどが一番

25 :仕様書無しさん:04/11/10 19:29:05
同じことやるのに行数多いほうが少ないより簡単に書けるが品質は最悪

26 :仕様書無しさん:04/11/10 19:43:12
?

27 :仕様書無しさん:04/11/10 20:00:53
結局UMLって・・・

28 :仕様書無しさん:04/11/10 22:10:07
えとここまでなんも読んでないんだけど
未だにオブジェクト指向な考え方で設計してないところなんてあるの?
びっくらこいた
んじゃさいなら

29 :仕様書無しさん:04/11/10 22:14:08
このスレタイって、やっぱり渡辺美里?
それと、誰か前スレ総括してよ。
暇してる厨房、勉強になるからやってみ。


30 :仕様書無しさん:04/11/10 22:55:58
>>29
再履修が一番必要なのはお前。

31 :仕様書無しさん:04/11/11 01:23:11
>>30
漏れはずっと読んでたから内容はしってるよ。
ただ、スレが新しくなったので話の筋がつながるように
だれか総括してくれたらいいのにと望んでるわけ。

今後の問題は、
質のいいOO技術者を増やすのに、どこから手を付けるかだよな。
情報処理試験も、is-aとhas-aくらいしか聞いてこないからな。
今年のアプリケーションも、実態はDOAだったしね。
受けてない人間にはわかんないだろうけど。

漏れとしては、
前スレを終えた感想、次は業務系なら分析に踏み込むしかないでしょ。
メモリ管理に工夫する分野ではないわけだからね。
最も、分散処理や可用性の向上や証明可能性等の問題はのこってるが、
この話ができる人間は業務系では僅かだろうし。大学の研究レベルだ罠。

ところで、
OOでユースケース図→シーケンス図と作って、分析したあと、
クラス図→ユースケース図(ロバストネス図?)→シーケンス図で
設計完了なんて流れが参考書読んで頭に焼き付いてるだろうけど、
これは、実際のところ飛躍が大きすぎる。
分析まではとりあえずいいとして、
現状、みんなDOAなんかを睨みつつ、試行錯誤でクラス図書いてる
んじゃないのか? どうなんだろ。

その辺、漏れは聞いてみたいね。経験論になるんだろうけど。
UMLなんて言っても、肝はクラス設計に集約されてるわけで、
極論、個々以外は誰がやってもかわらんのやし。


32 :仕様書無しさん:04/11/11 01:25:05
分析まではとりあえずいいとして → (削除)


33 :仕様書無しさん:04/11/11 01:30:38
UML書くのって結構無駄が多いんだよね。
図を半分くらいまで描いたところで大方の設計は終わってたりするので
後はコミュニケーション用に作成するとかになる。

34 :仕様書無しさん:04/11/11 01:31:17
UMLに関して漏れの認識を述べておくと、
一応、単なる記法の定義だけど、その心は、
設計時の注意点の明確化と、抽象度合いの維持。
 設計時の注意点の明確化とは、設計時に見落とし
ちゃいけない情報を指さし確認させること。
 抽象度合いの維持とは、分析者や上流設計者が
プログラマの裁量の領域を侵さないようにするため
手段であって、要求定義上の問題を意識したもの。


35 :仕様書無しさん:04/11/11 01:42:19
自己注釈
>現状、みんなDOAなんかを睨みつつ、試行錯誤でクラス図書いてるんじゃないのか?
なんでこういう話になるかというと、
業務系はDBへ高速アクセスできる事が多いから、データを管理する必要がそれほど
ないわけで、OOの効果は変更対策等に期待される。
つまり、DOAな見方だけではだめなわけだ。
そこで、DOA以外の、効率的な、OOの備える例えば継承等の特性を生かせる分析が必要になる。
それが試行錯誤以外に、誰かいい経験論を持ってないか、日本のITが壊滅する前に教えろと言うことだ。

36 :仕様書無しさん:04/11/11 01:47:15
分析・設計のやり方で手軽に使える方法論がないからね。

37 :仕様書無しさん:04/11/11 01:55:00
>>33
それは、そうなんだけど、ほんとはまずいんじゃないかな。
UMLって考えるための道具になるべくして作られたんだと思うよ。
本音はね。 言語が先か、思考が先かなんて話もあるけど。

>>36
あっても、神懸ってて書けないとか?(w
最後は試行錯誤になっちゃうんだろうけどね。
問題をどう整理するかってことだよね。


38 :仕様書無しさん:04/11/11 02:08:00
>>36
ゲロっちゃえよw

39 :仕様書無しさん:04/11/11 02:08:32
くーすでいいよくーすで。

40 :仕様書無しさん:04/11/11 02:28:30
↓面白い。
tp://www.relaxer.org/process/sample/library/LibrarySystem1.1.1/LibrarySystem.html

ICONIXをカスタマイズって感じですか。
書籍でもここまで書いてくれてるのはなかなかないと思います。

41 :仕様書無しさん:04/11/11 12:36:22
OOの特徴である、カプセル化、継承(抽象性、ポリモフィズム)、委譲、メッセージ駆動、etcの
効果を生かせる分析手法が必要なわけで、それがDOAでは足りてないってことですか。

42 :仕様書無しさん:04/11/11 12:39:01
業務系では、DBはDOAで設計して、クラスはDBのデータに対応させて(ORマッピング)
考える訳だけど、変更に対する柔軟性を出すには、継承なんかを生かした設計が必要に
なると。

43 :仕様書無しさん:04/11/11 12:41:42
継承すると変更しにくくなる

44 :仕様書無しさん:04/11/11 12:50:13
is-aとhas-a以外の分割が必要になる?
is-aもhas-aもXMLを使うと、分割不要になる場合が増えそうだけど。
XMLで後付けしたデータを処理することを考えると、寧ろ、イベント
をうまく活用した方が変更対策が楽そうに思える。
変更前のモデルを、フックするような感じで拡張できるし。

45 :仕様書無しさん:04/11/11 12:54:47
>>43
漏れも、そう思う。
継承構造の作り方の問題ではあるんだろうけど、
業務モデルを経験の少ないマが勝手に分析して、
継承でかいてもオナニーになるはず。
実際業務は哲学に基づいて設計されてるもんではないわけだし。

46 :仕様書無しさん:04/11/11 13:01:34
そりゃサブクラスがis-aになってないからだよ

けど、業務だとそれがめちゃくちゃ難しい

なんつったって業務完全に把握してないから、後から
「そんな業務しらねーよ!」でis-aが崩れる。

47 :仕様書無しさん:04/11/11 13:02:11
>>44
各処理を小さな単位に分割して、前処理イベントと後処理イベントを発生させる
なんてことをやると、カプセル化に真っ向から対立する方法になるね。
末はメッセージのスパゲティか。
カプセル化と如何に共存させるかってのも、問題だろうな。

48 :仕様書無しさん:04/11/11 13:05:32
メッセージを管理するツールを作って、処理をパイプで設計…DFDだな、こりゃ。


49 :仕様書無しさん:04/11/11 13:12:02
結局OOのアイデンティティはカプセルかにあるんだろうか?
>>46
業務モデルで継承が使えないとなると、業務モデル以外で継承を
使うことになるわけで、つまり、結局業務モデルのフレームワークがOOに
なって、業務モデルそのものはOOではなくなるのかも。
フレームワークだけOOでやるのが最適とか言うレスが前スレにもあったっけ。

50 :仕様書無しさん:04/11/11 13:49:25
DB中心の業務アプリで、トランザクションごとにDBの入出力が完了するようなアプリだったら、
別にOOにこだわる必要ないって。

DBや(Webアプリだったら)サーブレットエンジンとかのフレームワークとかを含めた全体を
見渡した場合、OO的な相互作用として捉えることも可能だが、コーダさんたちのコーディング
作業の段階では、「受け取ったデータを登録する」「条件に合うデータを表示する」「集計した
データをどっかに渡す」というレベルでしかないんだから。

毎回データをDBのような永続的な媒体に反映させるわけにいかないアプリでは、当然データを
メモリ上に持つしかないわけだが、グローバルな領域にいろんなデータが無秩序に並んでると
わけわかんないし誰でもいじれて危険だしデータの構造が変わったりすると大変だから、オブジェクト
という形で管理してその操作もメソッド経由でやったほうがいいというのがOOの第一歩。

その第一歩の部分をDBMSがほとんど面倒見てくれるような環境では普及しないのは当たり前。
必要がないんだから。





51 :仕様書無しさん:04/11/11 14:09:56
業務アプリケーションのアーキテクチャパターン
http://www.nri-aitd.com/tips/g-patern.html

JavaだとDomain Modelパターン、.NETだとTable Moduleパターン

52 :仕様書無しさん:04/11/11 18:40:26
わかり始めたまーいれぼりゅーしょん

53 :仕様書無しさん:04/11/11 18:40:54
>>50
コーダなんて全然関係ないだろ?設計の話なんだし。

>グローバルな領域(以下略)
カプセル化って言えよ。

>その第一歩の部分をDBMSがほとんど面倒見てくれる
なんでやねん。

あかんなー。前スレ最後にわけわからんこと書いてた厨房か?





54 :仕様書無しさん:04/11/11 18:51:23
>>47
MSの新しい技術に、なんかそんなのあったよ。
前後でフックがかけられるコンポーネント呼び出しフレームワークみたいなの。

そうかぁー、スパゲティ化とカプセル化が対極にあるのかぁ。
そうすると、処理のタイミングだけを設計したフレームワーク、例えば、特定の
上流イベントを受け付けて処理を実行するクラスであって、その委譲されてるクラスに
対し下流イベントを発行するような、メッセージの流れに局所性を与えるようなクラス
が中道的解法になるのかな。 そういうクラス設計してるのいる?

>>41
エラー処理もOOの特徴かもね。トライ・キャッチ・スルーを使えるのはデバッグや
安定動作に有効でしょう。ろくにエラー処理書いてないオレが言うのはどうかと思うけど。



55 :仕様書無しさん:04/11/11 19:00:30
クラスを乱造(みだ)すことさ


56 :仕様書無しさん:04/11/11 19:01:31
>>54
>処理のタイミングだけを設計したフレームワーク
普通はこういう設計をするんじゃない?
MFCだろうがOpenGLだろうがStrutsだろうが、色々垣間見れる。

ここの話題を掘り下げていくとアスペクト指向が視野に入っていく罠。
エラー処理も含めて。

57 :仕様書無しさん:04/11/11 19:23:10
>>56

>>47はアスペクト指向っぽいよね。
好きにフックができるのと、同一の前処理/後処理を追加するのとは別だけど。

OOっていうのは、操作対象のデータに着眼して処理をまとめてあるわけだけど、
”一連の処理”という表現が表す、タイミングについてはまとまっていないわけだよね。
だから、データをカプセル化するカプセル化クラスと、”一連の処理”を隔離するタイミングクラス
の2種類を作って、カプセル化クラスのインスタンスをタイミングクラスのインスタンスへ委譲する
っていうことが言いたかった。
MFCって、例えばコントロールがフォームのメッセージディスパッチャへ登録するっていうやりかた
だよね。コントロールがカプセル化クラスなのはそうだけど、フォームって、タイミングクラスといより、
なんでもイベントを受け取っておく郵便受けだよね。


58 :仕様書無しさん:04/11/11 19:45:33
例えば、{前処理、本処理、後処理}っていうメッセージルーティングクラスを作る
ってことか。平凡だな。
でも、確かにDOAにはない視点だな。
例えば、継承にしとけば、エラー処理もまとまられるし、グローカルなデータの扱いも良くなるかも。


59 :仕様書無しさん:04/11/11 19:48:59
>>57
そうそう、そうすれば保守の工数も少なくなって、新規PJでは
「ここの発注管理、前のフレームワーク流用できるねぇ」なんて有意義な意見が飛び出し、
18時ごろには退社できる、明るく活気のある楽しい職場が・・・。

できねーよ! ヽ(`Д´;)ノ
なぜだ・・・。

60 :仕様書無しさん:04/11/11 19:50:11
DOAっていうのは、言ってみれば発生と消滅に関するデータの固まりを見ていて、
DFDやIDEFなんかは、変更に関するデータの固まりをみてるのかもしれんな。
あんまり書くと、チラシの裏へ(ryと言われるので、このへんにしとく(w

61 :仕様書無しさん:04/11/11 19:51:57
>>59
>>57みたいなそういう設計やっててるの?
漏れ的には脳内なんだけど。

62 :57:04/11/11 20:00:39
>>61
やっているよ。各々のPGがどこまで感じているかは分らないけど。
大抵はディスパッチされた部分をさらに委譲して、特定の処理だけを行うクラスに渡したりする。
こうすると純粋なOO指向の観点で見ると非常に汚いかもしれないけど、業務系なんかでは
保守・新規開発共に楽になるよ。
人の出入りが激しい開発だと「○×処理はここでやっているから。」の一言で伝えられた方が楽だしね。

63 :62:04/11/11 20:01:25
すまん、俺は59だった。

64 :仕様書無しさん:04/11/11 23:22:05
単一の処理しかしないクラスってOOの観点からはあまりよくないのかもしれないけど
実際、クラスの責務を明確にしようとするとそういうクラスも現れてくる。
ミニStrategyパターンとでも名づけておこうか。

65 :仕様書無しさん:04/11/11 23:22:21
フォームを持ってるスタンドアロンのアプリなんかだと、
GUIのイベントを振り分けるフォームクラスと、
フォームのイベントプロシージャから、特定の処理を行うクラスへ
イベントをディスパッチするイベントクラス(ディスパッチャ)と、
特定の処理を行うプロセスクラスと、
カプセル化クラスの、基本は4階層構造でつか。 φ(..)メモメモ




66 :仕様書無しさん:04/11/11 23:30:37
長期トランザクションとか入ってくると、トランザクションクラスとかも必要になってくるのかな。
業務系じゃそこまでやんないのかな。
やっぱり、いまいち業務系の定義がわからないなぁ。具体例ないと…

67 :仕様書無しさん:04/11/11 23:53:43
>>59
で、何でとらぶってるわけよ。

68 :仕様書無しさん:04/11/12 00:01:30
なんつーかパターンとして、設計に酔うと
自己満足に陥ってしまうよね
で、振り返って自分のコードを見ると設計に凝っていても
本質はなんら難しいことではない
なんか高尚なことをしているように見えるだけ・・・

結局は病的なまでに規則にこだわったCのソースのほうが
メンテしやすかったりすることも多い

クラスの関連を統一的に把握してるのって
結局プロジェクトが終わるまで、フレームワークを担当した
人間だけしかわかってないことが多いよなぁ

69 :59:04/11/12 00:26:30
>>67
設計以前。

70 :仕様書無しさん:04/11/12 00:32:29
つうか (オブジェクト指向が世に出て)これだけ時間が経ってるのに、DB中心の
業務系じゃたいして普及してない原因を分析したほうが早いんじゃないのか?

71 :仕様書無しさん:04/11/12 00:42:33
かなり普及してないか?

72 :仕様書無しさん:04/11/12 00:43:50
>>68
大切なのは、パターンより、セオリーだな。
セオリー通りに作って、問題が明確になった部分だけ、パターンで置き換える。
GoFのパターンなんて、OO分析と設計のセオリーが確定した次のはなしなのに、
一部ではOO入門者が飛びついたりして、おかしなことになってる、2chのスレみてる。

>>69
分析? 要求定義? ヒアリング?

73 :仕様書無しさん:04/11/12 01:06:03
業務系にて失敗するパターンを書いてみる
あくまで経験談です

1.知らない業務の設計をおこなうため
→仕様変更に弱い、もしくは知らない仕様があるため、ある日それが
表に出ると設計が崩れる、リカバリする時間もない
もちろん業務を完全に覚える工数は無い

2.モデリングした設計モデルをエンドユーザーが理解しようとしない
→業務仕様と設計モデルとの剥離が起こる、あとは1番と同じか

3.PGのコーディング能力に多々頼るために、理解していないPGだとなし崩しになる
→理解しているPGなんて見たこと無い
メソッド1つ作ることを監視する工数なんて無い
もちろん気づいたときには遅し、単体終わってるなんてありえるし
戻る工数は無い

4.最後に納品のためになし崩しになりやすい
最後は、PM SEでさえもなし崩しを期待してしまう
納品・検収してしまえば、後の修正は別工数です。


あー、なんか金と時間とユーザーの理解さえあれば
業務系でも出来るんだろうけど、そこが出来たら
この業界はこんなになってないか(笑)

74 :仕様書無しさん:04/11/12 01:07:21
適当に書いたから、変なとこあるな
失礼

75 :仕様書無しさん:04/11/12 02:38:59
アンチパターン乙

76 :仕様書無しさん:04/11/12 02:47:21
>>73 をろくに読まずに書いてるんだが、
要求定義を階層的にやってます?
例外とか細部を階層的に分離して、客の納得するよう階層化して定義しないと後でもめることおおい。
モデリングも、極力これに対応させてやる。
モデルの修正は、細部や例外に対して発生することがおおいので、結局変更対策にもなる。
なんというか、漏れたちは職業柄、いきなり抽象的で情報量の多い議論されてもある程度
理解できるけど、周りはそうでもない。

77 :仕様書無しさん:04/11/12 02:48:45
4番がとても身にしみてきます。
最終的にはそれしかないよなあ。はあー。

78 :仕様書無しさん:04/11/12 02:56:43
>>73
>もしくは知らない仕様があるため、(略)
階層的に要求定義して、レビューしてサインもらってた場合、
承認済みの階層に矛盾するような仕様であればミスを転嫁できます。
書き落としの責任は転嫁しにくいけど、これはやれる。
これやらないといくらでも仕事増える。


79 :仕様書無しさん:04/11/12 06:47:05
なんつーか
そんなにまじめにやることないと思う
綺麗な設計やコーディングは
趣味でやればいい

80 : :04/11/12 09:49:03
>>73
なるほど・・・
仕事の責任範囲をきっちり決めるって意味での
設計ってことか
設計に時間かけるとコーディング期間にリスクが増えると
思っていたけど、トータルで考えると逆なんだねぇ

81 :仕様書無しさん:04/11/12 09:51:22
業務系でなぜ少ないか。

単純に完全な新規案件が少ないからでは。
90年代に大体システム化が終わっていて、今の仕事てそれのリプレースが多いから。
設計などは流用が前提になっていたりして、なんともいえないところが多い。

82 :仕様書無しさん:04/11/12 10:59:11
>>79
アホが集まってるプロジェクトだと、
デスマになって最悪の事態にまで悪化することがあるんじゃない?
うちの会社は自分で設計をやれないとゴネ始めるクセに設計能力の無い上司がいるから、
絶対にOO取り入れない。
っていうかそれでもデスマばっかで会社辞めたい。

>>80
> 設計に時間かけるとコーディング期間にリスクが増えると
> 思っていたけど、トータルで考えると逆なんだねぇ
まあケースバイケースだとは思うけど、
設計に時間をかけなければ最悪の事態になり得る。

83 :仕様書無しさん:04/11/12 16:26:28
「♪分かり始めた・・・」って渡辺美里か?なのか?


84 :仕様書無しさん:04/11/12 19:24:42
>>80
きっちり設計やるとマジで楽。
コーディングの量も減るので、テストする時間も減る。
規模にもよるかもしれないけど自分の場合
変更あっても関数1〜2個いじれば終わり、
機能追加も増えた分を製造してテーブルに追加しておしまい、
なんてのがあった。
マジで
「1時間でデバッグ(保守)に10時間かかるものではなく
3時間かけてでもデバッグが5時間で済むものを作るのが仕事」って
思ってる。

85 :仕様書無しさん:04/11/12 20:43:50
>84
でも現実は設計は1時間しかない

86 :仕様書無しさん:04/11/12 21:09:09
設計なんてしない

87 :仕様書無しさん:04/11/12 23:11:31
>>85
そのためにセオリーが必要。


88 :仕様書無しさん:04/11/13 00:48:43
セオリーに頼る奴はデスマ

89 :仕様書無しさん:04/11/13 01:01:00
>>88
共通のセオリーを持っててデスマなら、そいつらは何をどうやってもデスマ。


90 :仕様書無しさん:04/11/13 17:21:11
なにかつーとセオリーではとか
こうしたほうがいいと言われているとか・・・
いいけどさ、それだけじゃ説得力ねぇよなぁ
それプラス決定的な説明が出来ないのは
どういうことよ

本当に仕事を良くしたいとかじゃなくて
そういう本で読んだばかりの知識を実践してみたい
のがミエミエのやつはイラネ

91 :仕様書無しさん:04/11/13 21:52:45
>>90
「決定的な説明」って、ようするにあらゆるプロジェクトのあらゆる問題を
簡単に解決できる「銀の弾丸」が欲しいってことかい?
オブジェクト指向に限らず、そんなものは存在しないとしか返答できんよ。

92 :仕様書無しさん:04/11/13 23:41:36
>>90は批判してるだけで決定的な反論が無いのでこのスレにイラネ

93 :仕様書無しさん:04/11/14 00:44:58
オブジェクト指向は「Don't think. FEEL!」だよ。

94 :仕様書無しさん:04/11/14 01:23:30
とにかく、どんな最悪の事態が発生するか前もって予測せずに
「よしできた!これでいける!!」と勝手に決断を出す奴が一番危ない。
どんなに良い状況でも更に良くなるよう
現実的なリスク回避策や改善策を考えることが一番重要。

95 :仕様書無しさん:04/11/14 01:37:16
業務系をまともにやろうとすると、「アナリシスパターン」とかのファウラーが現在定
式化しつつある話になる。ということは、まだ方法論自体ができてないというだけでは?

96 :仕様書無しさん:04/11/14 15:42:52
出来るやつが、業務系には居ないだけでしょ。

97 :仕様書無しさん:04/11/14 16:13:06
ていうか業務系て一言でくくるけど範囲が広すぎる
もちろんセオリーみたいなものはあるけどそれは僅かで
大部分はイレギュラーな部分、つまりその業務固有の部分を設計するのが大変なんだな

98 :仕様書無しさん:04/11/14 16:38:55
最近のはデータマイニングを意識して、情報の可視化というのも要求されるし。
そうなると、単純にデータのエントリ/表示とは行かなくなって、
プログラム側で、DBからすいあげた情報を処理して、グラフィカルに表示しなくちゃいけなかったりとか。
その表示方法も、業務ごとによって見やすいルックスって違うし。
あとは、位置情報取得システムとか、外向けに公開するために、異常に見た目にこだわったりとかもあるし。

処理する単位が、抽象的な何らかのイメージを持つ以上、
オブジェクト指向が有効なのは、間違いないよ。
扱うデータの単位のくくりが、少なくなるだけでも、
設計時に、クラス単位で話をまとめようとする方向性は、正しいと思う。

99 :仕様書無しさん:04/11/14 17:07:03
表示の問題とオブジェクト指向て関係ないだろ
一旦オブジェクト指向で作ってしまえば可視化が楽だってことか?
むしろ大変じゃねえの?

100 :仕様書無しさん:04/11/14 17:34:46
リレーショナルDBはオブジェクト指向との相性は必ずしも良くない思う
まぁ使うけど、無理やり感否めず。


101 :仕様書無しさん:04/11/14 17:35:25
結局イメージ出来ない人は出来ないんだろうなあ。全く違うこと考えちゃったり。

102 :仕様書無しさん:04/11/14 17:38:33
この種のはOOPより上手く記述できる方法もあるからね。

103 :仕様書無しさん:04/11/14 17:39:29
データ−ベースは実体を重視するのに対して、オブジェクト指向は抽象化作業だからな。
実体が何であろうがお構いなしっていうか、扱う枠が違いすぎる。

104 :仕様書無しさん:04/11/14 17:40:35
>>100
うそお!?

RDBの行ごとにしかなっていなかったデータをオブジェクトとして扱えるようになったメリット、全然感じないの?
まじ?

105 :仕様書無しさん:04/11/14 17:43:14
>>104
なる事はなるけど、構造が悪いじゃん。
行をオブジェクトにすると列がオブジェクトとして記述できにくいし、その逆もしかり。
どうやっても美しくならない。


106 :仕様書無しさん:04/11/14 17:44:07
>>99
さらに、うそお!?

業務系ならまだしも、
たとえばゲームとか作るときに、
オブジェクト主体で作ったほうが全然コード綺麗じゃん!
業務でも、オリジナルのコンポーネントとか作るときも、オブジェクトそのままじゃん。

VB→VB.NETの恩恵感じてるだろ?

107 :仕様書無しさん:04/11/14 17:48:11
>>105
そのためにORマッピングするんじゃん。
処理をする際、レコードのままじゃ扱いづらいから、オブジェクトに「翻訳」してるわけだ。

一回マップが作成されれば、扱いにくいRDB上のデータの羅列が、
なんと一つの抽象データになります!

ってことでしょ。

RDB上に落とすときは、オブジェクトを「登録/更新」とやれば、
隠蔽された内部で、自動的にRDB上の適切な位置にデータが落ちる。

ってことでしょ。
ね。

108 :仕様書無しさん:04/11/14 17:51:24
>>107
その種の方法だったら関数型を使うともっともっと綺麗に記述できるんだ。
他にもっと良い方法があるって事。
混在させるのは現在は難しいから、現状は素直にOOPで行くけど。

109 :仕様書無しさん:04/11/14 17:52:49
>>108
>その種の方法だったら関数型を使うともっともっと綺麗に記述できるんだ。
そんなの言い張ったってしょうがないだろう。
じゃあ、
その種の方法だったらオブジェクト指向を使うともっともっと綺麗に記述できるんだ。
って言ったらどうすんの。

110 :仕様書無しさん:04/11/14 17:56:04
>>109
こだわってもしょうがないって事、運良くよりよい方法が使えるとか、
見つかったとかなら迷わずそれを使うのが吉。
無理してOOPを使うと返ってはまる。
実務でもそんなもんでしょ

111 :仕様書無しさん:04/11/14 17:57:05
経験から感じたことを言ったまでだろ
学生さんは気楽でいいな

112 :仕様書無しさん:04/11/14 17:58:05
>>110
じゃあ、オブジェクト指向開発選択肢に入れたっていいんじゃん・・・。

113 :仕様書無しさん:04/11/14 17:59:05
おいおい、使ってるって書いてあるじゃないか

114 :仕様書無しさん:04/11/14 18:05:32
>>111
いや、俺、学生じゃないよ。

>>113
分かってるよ。
でも、そのスタンスは勿体無いってこと。
実感してないのは残念だが、オブジェクト指向のメリットはあるよ。嘘じゃないよ。

もしかしたら、周りにうるさいこと言うヤツがいて(これはOOじゃない、こうでないとOOじゃない)、
うんざりしてるんかしれないけど。

115 :仕様書無しさん:04/11/14 18:08:41
>>109は関数型プログラミングについて勘違いしてる希ガス。

116 :仕様書無しさん:04/11/14 18:10:36
>>114
関数型というのはいわゆるC言語とかのようなものではないです、
写像を行う事に特化した言語で、マッピングというのはまさにうってつけなんですよ。
しかしまぁ、それ以外のことには使いにくかったりするわけで、
これを全部に適用するわけにいかないし、実際問題として実用的な処理系が無いという問題がある。
要するに言いたい事は、OOPが最高だって思い込まないほうが良いという事です、あくまで次善。
またそのうち新しい方法論も登場してくるでしょうし・・・

117 :仕様書無しさん:04/11/14 19:20:30
>>116
それってもしかして、
Lisp系の言語に代表されるやつ?
もしそうなら、オブジェクト指向に対する手続き型指向よりも、なおまずいと思うんだけど。

118 :仕様書無しさん:04/11/14 19:20:56
ORマッピングってまさにDBとオブジェクト指向の相性の悪さゆえにあるもんじゃん


119 :仕様書無しさん:04/11/14 19:34:14
>>118
RDBとオブジェクト指向は、簡単には組み合わないよ。
そのための緩衝材として、ORマップという余計な(?)手順が必要になるのも確か。
ただ、そうしてRDB上のデータをオブジェクトに変換するのは、
ただのデータの列として扱うよりも遥かに効率がいいから。

というか、実際に使用されるデータというのは、本来オブジェクトとして扱ったほうがいいものばかり。
それをデータベースに登録する場合だけ愛称の悪いRDBなのは、単純に、
・これまでのノウハウを捨てがたい。
・単純性
・安全性
と言った、使いやすさとは別の理由。
たとえば伝票データ。ヘッダ部データと明細部データの対応について考えただけでも、
これはRDB上に一行のデータとして保持するより、オブジェクトとして、データ構造を持たせたほうが扱いやすいのは明らか。
RDBのメリットが捨てずらいから、依然としてRDBが使われているし、これからも使われていくだろうけど、
人間が扱うデータとしては、オブジェクト(抽象データ)の方が楽なのは、それはそうでしょう、というところ。

というか、逆にアンチOOPの人は、構造体の類もまったく使わないってこと?

120 :仕様書無しさん:04/11/14 19:43:16
>>119
同意できない

>これはRDB上に一行のデータとして保持するより、オブジェクトとして、データ構造を持たせたほうが扱いやすいのは明らか。
ちなみにどういう設計をする?


121 :仕様書無しさん:04/11/14 20:23:32
>>120
>>119の伝票の例じゃだめなのか?

122 :仕様書無しさん:04/11/14 20:28:31
RDBのメリットが捨てずらいとか以前にOODBが一般的じゃないから

123 :仕様書無しさん:04/11/14 20:59:17
OODBが発展しないのは、DB中心の業務アプリではRDBで十分だから

124 :仕様書無しさん:04/11/14 21:00:59
ようするに現実的にRDBしかないから

125 :仕様書無しさん:04/11/14 21:45:09
Pro*C使ってたって構造体にマッピングするんだろ?
RDBを何のマッピングもせずに使える言語なんて無いよ。

126 :仕様書無しさん:04/11/14 21:56:10
オブジェクトがそのまま保存できるDBが欲しいな

127 :仕様書無しさん:04/11/14 22:01:18
>>126
いまさら何言ってるんだ、こいつ

128 :仕様書無しさん:04/11/14 22:32:47
スルースルヨロシ

129 :仕様書無しさん:04/11/14 22:40:37
スレ一通り呼んだけど、>>1の暴言よりも渡辺美里に反応してる奴が多いのがワロタ

130 :仕様書無しさん:04/11/15 01:32:16
RDBがOOで使いづらいのは、
RDBは業務データを論理付けして、すべての側面から整合性を保つのを、
OOでは業務的な側面でしかデータを見ないので、
RDBの論理的な見方とOOの論理的な見方の差異にあるんじゃないか?

RDBはすべての業務から再利用が可能なようになっているが
OOのオブジェクトでは、そのオブジェクトの担当分しかデータを保持しては
ならないから、更新時や登録時に使いづらいと思われ。

よって、RDBがOOPにふさわしいといえば、かならずしもそうならない。
けど、現状では業務には選択肢は無い。

ということでは?

131 :仕様書無しさん:04/11/15 09:43:45
きちんと正規化されたテーブル群から、業務で要望される結構複雑な画面の情報を取り出すのが
ORマッピングだけだと上手くいかん。

従来型であればSQLを兎に角突き詰めることになるんだけどね。

まず業務系の場合、オブジェクト的に考えたらなんでこれが一つ?っていう画面は幾らでも出てくる。
そうしたときに、下手にオブジェクトにこだわると、各々のオブジェクトがデータを取得、つくり的にはいいけど性能でない。

かといって、画面=オブジェクトとしてやると、それはオブジェクト指向ではなく従来型を単にオブジェクト指向言語で作っただけ。



132 :仕様書無しさん:04/11/15 10:12:14
そんなの性能と論理構造のトレードオフに決まってら。
これだから学生さんは。

133 :仕様書無しさん:04/11/15 10:25:03
>そんなの性能と論理構造のトレードオフに決まってら。
両立できない=オブジェクト指向の限界
って事です


134 :仕様書無しさん:04/11/15 10:30:37
>>130
RDBはこれでいいと思うね、変にいじると返って悪くなる
OODBが良い例、変更が必要なのはOOPの方だと思う。

135 :仕様書無しさん:04/11/15 10:30:54
UMLって必要なのか?

○○図とかいって、何種類も図を作る必要あるの?
誰が必要としている図なんでしょう?

途中で考えが変わったら、その図も全部作り直しでしょ?
ものすごくめんどくさい事やってる気がする。

136 :仕様書無しさん:04/11/15 10:53:05
>>132
>>133さんの言うとおり、両方の美味しいとこ取りができないのがオブジェクト指向の限界だと思う。
半端な適用ってメリットがないから、私は131の場合はオブジェクト指向にこだわらずに
画面=オブジェクトでつくってしまうけどね。

137 :仕様書無しさん:04/11/15 10:55:39
>>135
1.必要な図面だけ作ればいい。それはUML本とかにも書いてある。必ずしも全部が必須じゃない。
2.UMLの設計ツールを使えば、ステートとシーケンスと・・・とかいう同じ情報を共有する図面は連携して変更できます。


138 :仕様書無しさん:04/11/15 11:01:04
自分だけ、自分のチームだけ、自社だけの開発をしてたら有意性が分からんかもね
作り直しが面倒な図は書く意味ない。設計が悪いだけ。

いつでもさくっと手で書けて、その場でレビューができるくらいの簡単な設計にしとけ。

従来のフローチャートやDFDではOO的な設計、思想を伝えることができなかった
そこで、「どういう構造を考えているのか」をその場で相手に伝えるのに使う言語がUML

設計に使う→アフォ。設計は頭でやるもんだ。ツールベンダに毎年ライセンス料を献納してろ
他人のコードを読むのに使う→アフォ。そこまでしてもダメコードからは有意な図は得られない
納品用ドキュメントとして使う→アフォ。一生図をメンテしてろ
設計とコード作成を兼ねる→アフォ。UMLのコード記述性は低い。手で追記するコードが増えて意味がなくなる

良く分からなかったら設計のレビューにだけ使っとけ


139 :仕様書無しさん:04/11/15 12:48:27
このスレでは、フォームを表現するオブジェクトとDB実体のオブジェクトが同じ構成じゃないとオブジェクト指向じゃないのか。

すごいところだな。

140 :仕様書無しさん:04/11/15 12:51:32
>>139
誰がそんなこと書いてるの?
性能面と客勝手な仕様が出た場合に、必ずしもORマッピングが上手くいかないことを書いてるとはおもうが。


141 :仕様書無しさん:04/11/15 12:59:27
>>135
お前、仕様をにつめて、顧客とのコンセンサスのために資料作成したことないだろ?
そんなことばっかりやっているから後で要望や仕様変更が噴出するんだ。
自業自得で損失だしてるくせに、客のせいにして文句言っているタイプだな。

142 :仕様書無しさん:04/11/15 13:39:35
>>131
>つくり的にはいいけど性能でない。
それのどこが「つくり的にはいい」んだよヴォケ

143 :仕様書無しさん:04/11/15 13:45:16
>>142
OO厨のオナニー的つくりといえばいいのかな?
覚えたてとか妄信的な奴にありがちな、とりあえずオブジェクトになってればOK的原理主義をいいたかった。


144 :仕様書無しさん:04/11/15 14:12:49
そこで>>51のファウラーたんですよ

145 :仕様書無しさん:04/11/15 14:24:26
正直、この考え方が落し所としては
現実的なんじゃないでしょうか

tp://seasarproject.g.hatena.ne.jp/tanigon/20040913

ドメインモデルとかいって、お客さん判んないよ・・・・
アナパタ読むと、顧客の方が優秀ですぐ理解するとか
書いてるけどさあ、無理だ・・・。

146 :仕様書無しさん:04/11/15 17:04:33
いつのまにか業務系はDOA+OOPがトレンドになってたりしてね

147 :仕様書無しさん:04/11/15 20:14:40
アナパタをパッと見理解出来る顧客が居たら尊敬する。

148 :仕様書無しさん:04/11/15 20:18:13
O/Rマッピングは使いにくいねぇ。
現実的にはオブジェクトのFactoryMethodを作ってSQLで生成すると楽だよ。

149 :仕様書無しさん:04/11/15 20:47:13

 現在進行中の議論

1.【RDB(DOA)とOOの使い分け、OOによるうまいアプローチ】
  ORマップ、処理性能、
2.【UMLを何のために使うか】
  設計レビュー、客向け、CASE
3.【アナリシス・パターンの可能性】


どの話か明記しとけや。

150 :仕様書無しさん:04/11/15 20:55:50

 ・基本的にOOのスレです。枝葉に突っ込んで議論を錯綜させないよう協力しましょう。
 ・不毛なマ板に立った不運なスレですが、他のプログラマに対して技術的文献的価値がある
 議論となるよう協力しましょう。そうすれば日本IT壊滅の期日が延びるかもしれません。

151 :仕様書無しさん:04/11/15 21:09:22
OOで性能の話は置いといてほしいな。
性能なんてところ変われば要件変わりすぎだし

152 :仕様書無しさん:04/11/15 22:00:10
DOAってなに?
DAOなら聞いたことあるけど

153 :仕様書無しさん:04/11/15 22:01:40
Damena
Ossan
Arienai

154 :仕様書無しさん:04/11/15 22:04:57
>>152
Data Oriented Approachでググれ

155 :仕様書無しさん:04/11/15 22:14:21
sleipnirの全IT用語辞典ではDOAはヒットなし
data oriented approachでもヒットなし

googleで分かったがこんな言い方してんのは日本ぐらいでは?
http://www.google.co.jp/search?q=cache:kPVudyh2jvkJ:www.doaplus.com/html/s13.html+Data+Oriented+Approach&hl=ja&start=21&lr=lang_ja

156 :仕様書無しさん:04/11/15 22:17:20
だから何よ

157 :仕様書無しさん:04/11/15 22:19:05
>>151
性能は別にしても問題の事情は代わらんだろう

158 :仕様書無しさん:04/11/15 22:23:53
>>155
アホほどヒットするじゃん。
http://www.google.co.jp/search?hl=ja&c2coff=1&q=%22Data+Oriented+Approach%22&lr=

日本語的には「データ中心アプローチ」かな。
超基礎用語なので覚えて下さい。

159 :仕様書無しさん:04/11/15 22:27:14
和製英語だけど俺ら日本人だから問題なし

160 :仕様書無しさん:04/11/15 22:27:44
だからdata centric approachって書いてくれよ
あるいはデータ中心アプローチって

日本でしか通じない英語をわざわざ略して書かないでくれw

161 :仕様書無しさん:04/11/15 22:29:49
このスレで通じば十分

162 :仕様書無しさん:04/11/15 22:36:32
性能の問題って、オブジェクトの生成コストと、
ガーベッジコレクションという言語仕様の事だよね。
これらがボトルネックになったプロジェクトを見た事が無いんですが。

設計的にはむしろ無駄な処理を省くし、
カプセル化されたボトルネック箇所だけの修正も容易だから、
他言語よりも性能面で苦労しないよ。

開発コストも安いからハードに金掛けられるしね。

163 :仕様書無しさん:04/11/15 22:37:46
>>160
>>158

164 :仕様書無しさん:04/11/15 22:48:39
ところで完全にOOじゃない開発ってどういうの?
javaのクラスつかった時点で何がしかOOにならざるをえないし・・

Cの構造体だって関数ポインタいれたらOOみたいなもんだろ


165 :仕様書無しさん:04/11/15 22:53:20
つか、日本じゃDOAって略語が普及しちゃってるんだから、つべこべいうな
キミって、「アイロンって何?」とかいう人?

166 :仕様書無しさん:04/11/15 22:59:30
>>164
ハァ?

167 :仕様書無しさん:04/11/15 22:59:40
Java使ってOOじゃない開発って悪い所取りじゃんw
構造体的なクラスとメソッドだけのクラスで構成するのか?

168 :仕様書無しさん:04/11/15 23:11:15
>性能の問題って、オブジェクトの生成コストと、
>ガーベッジコレクションという言語仕様の事だよね。
んなわきゃーない

169 :仕様書無しさん:04/11/15 23:19:56
まじめにOOAでやるのかって話じゃないの

170 :仕様書無しさん:04/11/15 23:28:44
ここで言ってるOOは文学のようなもの。
漢字覚えたての小学生が書いた作文じゃないの。

Javaを使ったからといってOOではない。(が、OOの恩恵は受ける。)


171 :仕様書無しさん:04/11/15 23:44:29
>170
同意

OOPの言語仕様の恩恵がある分楽かなって感じ

絵が描けるからって、漫画が連載できるわけではない

172 :仕様書無しさん:04/11/15 23:45:19
悪い喩えの見本ですな。

173 :仕様書無しさん:04/11/16 00:24:19
>>168
じゃ何?

174 :仕様書無しさん:04/11/16 01:24:55
1.【RDB(DOA)とOOの使い分け、OOによるうまいアプローチ】
についてだけど、
RDBの性能っていっても、いろいろあるよね。
性能って、定量的な性質をいう言葉なんだろうけど、処理速度、リソース管理の効率、
リニアな拡張特性なんかがあるよね。
他にも、信頼性なんてものも言える。拡大解釈で、ACIDの全部も性能と言えるかも。

究極的に、データをOOで管理するなんて現時点では考えない方がいいかもしれない。
RDBはそれくらいに強力になってる。

じゃ、OOは何をするかというと、エージェントとしてRDBにアクセスするってことだろうね。
簡単に言うと、アプリから見た仮想的なOOレイヤを作るって事。
実態は、例えばSQL発行や、トランザクション実行の代理になるんだろうけど、
これをどんな風にやるかって言うのが、ポイントだろうね。

175 :仕様書無しさん:04/11/16 01:45:33
>>170-171
初心者の着眼点と本質のありかという点の比較でならよくわかるけど…
わかってないヤシが読んでもわからんかも。

>>164
OOは、分析、設計段階で言うと構造化アプローチと、DOAの間にあるような手法だから、
完全にOOでない何かを探すのは難しいんじゃなかろうか。
コーディングの段階で考えると、DOAの位置づけがわからん。現実的にはRDB=DOA
になってるのかもな。思想はそうじゃないんだろうけど。




176 :仕様書無しさん:04/11/16 08:47:38
そんな難しく考えなくても、オブジェクトなんて構造体の延長線上にあるもの、と言う意識でいいと思うけど。

別にOOPじゃなくても、データの構造体は使うんだし、それがバラバラになった単独の変数より扱い易いというのが理解できるなら、そのデータに、専用の処理関数をセットにしてまとめよう、という発想も普通に理解できそうだけど。

177 :仕様書無しさん:04/11/16 09:37:45
蒸し返すけど、DOAってこの業界じゃ普通に通じる基礎用語です。
確かIBM系の標準化から発生しているはず。
和製英語じゃありません。
あと>>160さんはあまり無知をばら撒かんほうがいいよ。

178 :仕様書無しさん:04/11/16 09:59:07
知ったかがいい気になるためのスレかよ

179 :仕様書無しさん:04/11/16 10:04:11
>>165
あーちくしょー、アイロンがあったか。
いい例ないかとずっと考えてた。

180 :仕様書無しさん:04/11/16 10:39:26
>>177-179
なんかすごい粘着くさくてうざい。

181 :仕様書無しさん:04/11/16 11:28:05
スレタイは、「分かる奴だけ分かればいいオブジェクト指向」の方が
良かったのかも・・・

182 :仕様書無しさん:04/11/16 12:13:08
分かる奴だけ分かればいいオブジェクト指向の正体は分ったつもり

183 :仕様書無しさん:04/11/16 12:23:09
>OOは、分析、設計段階で言うと構造化アプローチと、DOAの間にあるような手法
俺は構造化手法とDOAは似たようなもんだとずっと思ってたんだが違ったのか?

184 :仕様書無しさん:04/11/16 12:29:35
>>182
そんなしちめんどくさい思想は、製造現場に根付かない。

185 :仕様書無しさん:04/11/16 12:38:06
>>183
DOAの適用範囲は分析(が主)−設計で、構造化手法は設計と私は認識しているが。


186 :仕様書無しさん:04/11/16 15:48:17
DOAって人事不省のことだろ?

187 :仕様書無しさん:04/11/16 17:11:52
ググっても、チチバレー関係しか引っかからん・・・

188 :仕様書無しさん:04/11/16 17:13:24
到着時死亡。
救急車の中で死んじゃう事。

生死問わず。哀川翔と竹内力が地球壊す映画。

人事不省ってのは初耳。

189 :仕様書無しさん:04/11/16 17:29:00
DOA データ

で検索したら幾らでもひっかかるけど。

190 :仕様書無しさん:04/11/16 18:47:40
もっと駄レスつけてあらそうぜ。

191 :仕様書無しさん:04/11/16 18:52:58
分析・設計をやったことないプログラマは、編集中の関数程度の視野しか持つことができないという罠。


192 :仕様書無しさん:04/11/16 19:14:04
Dead or Alive = 生きてるか死んでるかわからない

193 :仕様書無しさん:04/11/16 19:14:39
おいおい
DOAって堀内一とかデータ総研から生まれた言葉だろ

194 :仕様書無しさん:04/11/16 19:19:06
っていうか、
Java>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>C#>>>>>>>>>>>>>>>>>>>>>>VB
だろ。

195 :仕様書無しさん:04/11/16 19:19:55
>>194
誤爆くさいな

196 :仕様書無しさん:04/11/16 19:21:19

日本がインドや中国に負けるのは、どうも避けられなさそうくさいな。


197 :仕様書無しさん:04/11/16 19:28:16
>>192
普通は慣用表現で
>>188の「生死問わず」だと、思うよ

198 :仕様書無しさん:04/11/16 21:40:59
ウォンテッドDOA

199 :仕様書無しさん:04/11/16 22:04:47
>196
中国にはどうかわからんが、
英語圏の方が有利だな、確実に。

日本語がオブジェクト名メソッド名になるだけで、かなり楽になるはず。

200 :仕様書無しさん:04/11/16 22:05:17
Do as infinity

201 :仕様書無しさん:04/11/16 23:00:13
>>199
Javaで実現可能だね。
String 氏名 = 顧客.get氏名(); とか解かりやすい。
でも文字化けとかどこかで問題になりそうで怖くて使えない・・・

202 :仕様書無しさん:04/11/17 00:53:50
>>194
むしろ、
ハードウェア>>>>>>>>>>>>>>ソフトウェア
だろ。

203 :仕様書無しさん:04/11/17 00:54:19
インド人は0を発明したので
コンピュータがあるのはインド人のおかげなのです。
もうその時点で負けておるのです。

204 :仕様書無しさん:04/11/17 00:55:19

おまえらさ、ほんとに議論に向いてないな。


205 :仕様書無しさん:04/11/17 01:10:26

 ・基本的にOOのスレです。枝葉に突っ込んで議論を錯綜させないよう協力しましょう。
 ・不毛なマ板に立った不運なスレですが、他のプログラマに対して技術的文献的価値がある
 議論となるよう協力しましょう。そうすれば日本IT壊滅の期日が延びるかもしれません。


206 :仕様書無しさん:04/11/17 01:11:59
>>149
 現在進行中の議論

1.【RDB(DOA)とOOの使い分け、OOによるうまいアプローチ】
  ORマップ、処理性能、
2.【UMLを何のために使うか】
  設計レビュー、客向け、CASE
3.【アナリシス・パターンの可能性】



207 :仕様書無しさん:04/11/17 01:59:33
こんな気分転換の雑談掲示板で生産性のある話を強いるなよ。
本気で議論したいならマトモな場は沢山あるんだから。

208 :仕様書無しさん:04/11/17 07:48:47
>>207

まともな場で相手にされないオナニー君たちの楽しみを奪うようなこと言うなよ

209 :仕様書無しさん:04/11/17 08:53:24
うん、うん。 チミだけが真実を知っているよね。

210 :仕様書無しさん:04/11/17 11:40:37
そもそも楽にコーディングするための技術なんだから、一番根底にあるオブジェクト指向の本質は簡単なことだ。

それはデータを数値と文字の集合ではなく、現実の世界にある、「商品」とか、「得意先」とかって言うイメージとして扱うこと。

オブジェクト指向の世界では、コードの中で、これらのイメージを操作して処理を行なっている。


211 :仕様書無しさん:04/11/17 12:07:57
>>199
なにをトンチンカンなことを言っているんだよ、お前は・・・

212 :仕様書無しさん:04/11/17 12:11:09
>>210
それは抽象化の技法のことであってオブジェクト指向とは違うような気がするが・・・

213 :仕様書無しさん:04/11/17 12:24:13
>>212
抽象データはデータ単体だな。
じゃあ、そこから「オブジェクト」に進むには?

214 :仕様書無しさん:04/11/17 12:32:34
>>213
オブジェクト指向というのはオブジェクトというものがまずあって、
それには内部状態とメッセージという通信手段が存在する。
これを使って全体を構築してゆくもの。
抽象化は別にオブジェクト指向特有のものではない。

215 :仕様書無しさん:04/11/17 12:42:51
>>210
ちょっと話がずれてるし、実務としては業務系のほうが、ハードファーム系よりオブジェクトを取り入れにくい。
業務のオブジェクトって兎に角曖昧すぎる。


216 :仕様書無しさん:04/11/17 16:07:01
Object Thinking, by David West は好きか?
http://dotnetjunkies.com/WebLog/darrell.norton/archive/2004/08/03/21117.aspx

217 :仕様書無しさん:04/11/17 18:43:37
装置A と 装置B を使って, 作業1 や 作業2 を行うプログラムの開発において,
私は, 装置というオブジェクトに対して色々な命令を送るメソッドを与え,
それらをメニューから選択して, 作業を行うように実装しました.
しかし, ボスは
「それでは分かりにくい. もっと, オブジェクト指向になれないかね?
作業というオブジェクトに対して, 必要なパラメータの入力やデータの保存
などのメソッドを書くべきだ」
といいます.
私のオブジェクト指向に対する認識っておかしいのでしょうか?


218 :仕様書無しさん:04/11/17 19:05:05
オブジェクト指向とは一言で言えば、
「何を、どうする」
ということ。これだけわかれば後は簡単だ。

219 :仕様書無しさん:04/11/17 19:47:53
>>217
それだけの説明だとはっきりしたことは何もいえないんだけど、
多分君のボスはGoFのCommandパターンか、それに近いものを考えていると思われ。
そのプログラムにおいて本当にCommandパターンが適合するかどうかは
自分でデザパタを読んだ上で判断汁。

220 :仕様書無しさん:04/11/17 20:16:28
なんか
オブジェクト指向を間違って理解している人が一人いるような希ガス

221 :仕様書無しさん:04/11/17 20:22:26
>>214

222 :仕様書無しさん:04/11/17 20:40:10
>>221
自作自演乙

223 :仕様書無しさん:04/11/17 20:57:47
>>218
「何を、どうする」ではなく、
「オブジェクト同士のメッセージのやり取り」こそが
オブジェクト指向なのでは?


224 :仕様書無しさん:04/11/17 21:02:49
例えば
>>217 のように

>私は, 装置というオブジェクトに対して色々な命令を送るメソッドを与え,

という文を、オブジェクト指向的に解釈するならば、
まずは命令をあたえる「私(>>217)」が、そのソースコード内に
オブジェクトとして存在していなければならない。


225 :仕様書無しさん:04/11/17 21:14:56
要は「クラス」っていう概念を使って問題を簡単にする方法って事だよね。
だから「物」ってのは初心者向けの説明であって、
「良く使うデータの集合」をクラスとするのが基本だね。
パターン知らなくてもこのくらいの知識で十分成果を上げられるわけで。

つまり>>215は業務分析が下手なわけで。

226 :仕様書無しさん:04/11/17 21:31:51
>>224-225
説明が変だよ
クラスはオブジェクトを効率よく生成するための手段に過ぎないから、
そちらに目を向けると迷走するよ。

ついでに、もしクラス指向を使いこなしたいなら、関数型それもHaskellのような言語を一度やってみるといい
あれは抽象化の権化なので、よく使うなんてあいまいなものではなくてはっきりした物になる。
数学的なものとしては準同型という概念があるので、それを参考にしてみるもよし。

227 :仕様書無しさん:04/11/17 23:22:07
Javaなら惰性で使ってもシステム動くし。

228 :仕様書無しさん:04/11/18 00:02:36
まあ、なんにしても、オブジェクトが現実世界の操作するべき「物」であることはご理解いただけたとおもう。

オブジェクト指向は「物」と、それに対する操作をそのままコード上に記述することで、人間が理解しやすいコードを実現するわけだ。

オブジェクトは現実の「物」としての性質を記述するために、抽象データ、構造化データにさらに2つの機能がくっついている。
ひとつは物に対する操作を表す「メソッド」。もう一つは「アクセス制限」だ。


229 :仕様書無しさん:04/11/18 00:13:00
オブジェクト指向でコードを記述する場合、必ず、やってはいけないこと、という制約がついてまわる。
慣れないうちはこれが煩わしく、周りからあれやこれやと指図され、オブジェクト指向自体がうっとおしく感じたりもする。

が、この制約を決定しているルールのひとつが、オブジェクトが現実世界の「物」である、という前提なのだ。

オブジェクトがコード上に記述された「物」であると理解できれば、何故そのメソッドをそのクラスに記述してはいけないのか、何故そのプロパティがPUBLICではいけないのかが解る様になる。

230 :仕様書無しさん:04/11/18 00:26:47
>>228
「現実世界」って何?

231 :仕様書無しさん:04/11/18 00:28:06
なんかキモイ思想だな

232 :仕様書無しさん:04/11/18 00:57:17
でも、現実に物と対応のとれないクラスも存在してるよね。
こういうモノを例外として一くくりに扱うのも無理があると思う。

233 :仕様書無しさん:04/11/18 01:24:19
結局講釈垂れたってデスマはデスマ

234 :仕様書無しさん:04/11/18 01:38:35
>>232
つか、>>228-229は完全に妄想。
普通にC++かJavaを使ったことがあればイテレータはおなじみだと思うが、
イテレータクラスは現実世界の物と対応しているかね?
これに限らず、デザパタでは「現実に物と対応しない」クラスこそが
むしろ主役となる。
逆に、現実世界の物がクラスと対応しないってことも多々ある。
例えばGUIの設計において、一般的には現実世界のCRTをオブジェクトとするのでなく
OSが提供する仮想的なウィンドウをオブジェクトにするのが普通だ。

コードにおけるクラスやオブジェクトは、そのプログラムにおいて「クラスや
オブジェクトとして扱うのが妥当な」概念に対応する。
その「概念」が物理的に実在するものか、抽象的な分析上の実在か、
プログラミング技術上の存在かにはよらない。
ただそう扱うのが妥当か否かによる。
何をもって妥当とするかと言えば、それによってプログラムの開発・変更・保守が
容易になるか否か、それのみが基準である。

235 :仕様書無しさん:04/11/18 02:18:09
まあハシカみたいなもんだな。
ちゃんとシステム作った事あれば
絶対に「現実世界」なんて事思わない。

236 :仕様書無しさん:04/11/18 06:45:31
228-229は専門学校生だろ
ほっとけ

237 :仕様書無しさん:04/11/18 07:42:58
>>234
OOAを真っ向から否定する文章ですな。
コーダさん?

238 :sage:04/11/18 08:01:45
Logical Object does exits, you know that!

239 :goumantarou ◆uuJAVAsys2 :04/11/18 08:15:20
自らが神となり
仮想世界を構築する

240 :仕様書無しさん:04/11/18 09:40:38
「ちゃんと」理解しないと使えない様なものが、広く一般に受け入れられる
とは思えない。

「ちゃんと」理解してるお前らはパンピーと違うんだろうけど、そんな突然
変異だけで開発してるわけではない。

241 :仕様書無しさん:04/11/18 11:02:02
「ちゃんと」理解すれば、全ての開発論法には限界があることが分るさ

>「ちゃんと」理解してるお前らはパンピーと違うんだろうけど、そんな突然
>異だけで開発してるわけではない。

などという事にはならない、
「理解しないと使えない様なもの」はその時点でありえない。
しかしオブジェクト指向が最高でこれ以外ないとか信じ込む「押し付け狂信者」が現れる、
コイツらは最悪。

開発にもっとも重要なのは使えるものは何でも使えって臨機応変ささ


242 :仕様書無しさん:04/11/18 12:27:37
>>237
君はOOA/OOD/OOPがごっちゃになっているようだね。
分析モデルで現れるクラスとコードに現れるクラスは同じではないよ。
全くの別物と言う訳でもないが。

243 :仕様書無しさん:04/11/18 12:38:38
つーかこのスレ全体が全部ごっちゃで
話してるから噛み合ってないと思う。

244 :仕様書無しさん:04/11/18 12:55:06
みんな違うおかずでオナニーしてるだけだからしょうがないよ

245 :仕様書無しさん:04/11/18 12:57:07
明らかにかみくだいて書かれている説明に、くってかかってみたりな。

246 :仕様書無しさん:04/11/18 13:08:17
具体的に例示してみて下さい。

247 :仕様書無しさん:04/11/18 15:39:10
>>242
だって君のOOって「実装上の都合」以外に登場しないんでしょ?(プゲラ

248 :仕様書無しさん:04/11/18 17:45:19
>>240
> 「ちゃんと」理解しないと使えない様なものが、広く一般に受け入れられる
> とは思えない。

C だってちゃんと理解しないと使えないが、受け入れられてるぞ。


249 :仕様書無しさん:04/11/18 17:49:21
240は中級釣り師

250 :石黒 ◆VNX0nxDxEo :04/11/18 17:56:45
不毛なスレに認定しますた

251 :仕様書無しさん:04/11/18 20:18:37
まあなんだな、
コーダとヨーダがぱっと見
そっくりだという事が判った。

252 :仕様書無しさん:04/11/18 22:25:27
ちゃんと理解しないで完成出来るのは、きっと他の人のおかげです。

253 :仕様書無しさん:04/11/18 22:49:50
兵隊さんの おかげです。


254 :仕様書無しさん:04/11/18 23:23:28
昔、104のダイヤルで、電話番号を調べてもらうときに
「どういうカンジ(漢字)の人ですか?」と聞かれ、
「おもしろくて明るいカンジ(感じ)の人です」とこたえ、
電話局のお姉さんを1分間笑わせてしまった

255 :仕様書無しさん:04/11/18 23:44:17

結局、OOA/OOD/OOPは全部別物であって、
業務系で仕様変更に伴う再プログラミングを減らすためには、
OODで頭を使う必要があるって言うこと?

256 :仕様書無しさん:04/11/18 23:45:41
情報、要件を、構造を伴ったものとして理解したり考えたりできないと
だめということだな。

257 :仕様書無しさん:04/11/19 00:30:39
結局、要求定義へ行き着くわけか。

258 :豆乳 ◆1T2swboMiw :04/11/19 01:13:53
要求定義は、理工学系、特に情報系ではしっかりやっとくべきだろうね。
結局究極、客が納得するかどうかなんだから。
>>76でも書いてたりするんだけど。

>255
OOA/OOD/OOPは全部別物であったとしても、
OOAからOODへ行くときに、うまくオブジェクトを抽出する方法が必要
なわけで、こういうのって厳密にはメタOOって呼ぶべきなのかもしれないね。


259 :仕様書無しさん:04/11/19 01:15:17
えーと、オブジェクト指向を分かっている人は多い。
そのうちで困るのが、「オブジェクト指向を誤解している人が多い」と思っている人が多いこと。

260 :仕様書無しさん:04/11/19 03:17:41
>>255
>OODで頭を使う必要があるって言うこと?
それだけだと不十分。
正しくは、OOAとOODとOOPで頭を使う必要がある。

>>258
このスレを見る限り、それ以前な香具師がいるんだよな。

そもそもオブジェクト指向以外の方法論でも分析と設計と実装は別物なのだけど、
オブジェクト指向の場合は分析から実装までクラスやオブジェクトという一貫した
概念で行えてしまう分、かえって分析と実装がごっちゃになって、>>228みたいな
>オブジェクト指向は「物」と、それに対する操作をそのままコード上に記述する
という妄想を産む原因になっている面もあるんだよなあ。

別物ってことを認識してさえいれば、一貫した概念が使えるのは便利なんだけどね。

261 :仕様書無しさん:04/11/19 06:56:34
>>259-260
ワロタ

262 :仕様書無しさん:04/11/19 09:48:25
>>260
分かった、分かった。
じゃあOOPについてだけ説明してみな?

263 :仕様書無しさん:04/11/19 14:00:20
>>259
このスレ見ただけでも、勘違いしてる奴がいることは事実だろ。
多いかどうかは知らんが。

264 :豆腐 ◆1T2swboMiw :04/11/19 15:35:02
まぁ、もちついて。
ここで一般的な定義でも確認してみよう。

オブジェクト指向 【object oriented】
読み方 : オブジェクトシコウ
ソフトウェアの設計や開発において、操作手順よりも操作対象に重点を置く考え方。
ttp://e-words.jp/w/E382AAE38396E382B8E382A7E382AFE38388E68C87E59091.html


265 :仕様書無しさん:04/11/19 15:46:14
こんなの見つけますて。

オブジェクト脳オンライン
http://www.geocities.jp/objectbrain/


266 :豆腐 ◆1T2swboMiw :04/11/19 15:48:01
アウトプットの観点から定義してみると、
OOA:既存のシステムを表すUML図を書くこと
OOD:これから開発するシステムのUML図を書くこと
OOP:OODで得られたUML図より、より詳細な詳細UML図を作成し、
  その詳細UML図に現れるクラス等のみでコーディング可能ならしめること
この辺かな。

267 :仕様書無しさん:04/11/19 16:00:01
>>266
違う。
OOAの範囲がまず狭すぎ。あなたの書き方じゃOOA=現システム分析ですよ。


268 :仕様書無しさん:04/11/19 16:08:36
これも面白そう。DOAとOOA
ttp://www.drinet.co.jp/technical6_14.html

269 :豆腐 ◆1T2swboMiw :04/11/19 16:50:03
ttp://www.ogis-ri.co.jp/otc/hiroba/others/trainerEssay/tressay03.html
OOAは、システムが要求されていることを押さえてモデルに表す活動です。

ガーン 世間一般では要求定義と分析が分離されてるのか。
要求定義の時に、主キーまで検討して矛盾が無いか調べてるのは、ひょっとしてオレだけ!?
通りで時々おれだけ浮いてると思ったヨ。

OOA:既存のシステムと要求定義とを踏まえて機能を表すUML図を書くこと
コレデイイ?

270 :仕様書無しさん:04/11/19 17:07:36
>>269
それが有効ならばいいんじゃないのか?
自分も小規模なシステム(ネット証券の発注管理ぐらい)までだけど、実装まで考慮して設計するよ。
逆に言えば明確にどこまでが分析で設計で実装なのか分離できてないだけなのかも試練が

271 :仕様書無しさん:04/11/19 17:08:30
>>269
現状分析はあくまで要件定義のために行うものです。
(現状業務が存在しないものを創造するのにどうするんだ?)
あと、UML図を書くことが仕事じゃありません、UML図はあくまで表現方法です。


272 :仕様書無しさん:04/11/19 17:19:45
要求と同時に分析に入っちゃうと
散漫になっちゃって取りこぼししそうだなあ。
ざっくりとでもいいから網羅性を重視しないとあとで泣きそう。
なんとかなってた>269は相当頭良くて優秀。

現状分析はしてもしなくてもいいと思うよ。
場合によりけりだと思う。

渡辺幸三先生いわく、ここに橋をかけられるかどうか
現在橋がかかってないので判りませんと
いってるようなもんだ、との事。
まあこりゃ頭良い人だから言えるんだってのもあるけどさー。

273 :仕様書無しさん:04/11/19 17:24:50
いや、規模が小さかったとか、お客さんが優秀でフォローとか打ち合わせが楽だった可能性も・・・。


274 :豆腐 ◆1T2swboMiw :04/11/19 17:27:43
>>258
そのリンク先、OOへの不安を見事に書き表してないか?
ちょっと感動した。
大規模化を考えるとDOA有利か。確かにMSの広告も、窓や外壁にまでUML書いてるよな。
あれは大規模なシステム統合に向かうオブジェクト指向の未来を皮肉ってるわけだ。(ホントか?)
セマンティックを処理しない汎用プログラムっていう考え方はUML2にも現れてるね。
そう考えると、処理とデータの分離は必然であって、オブジェクトは怠慢ということか。
OOAへの疑問にある、「オブジェクト切り出しの客観的基準はないのでしょうか。」
っていうのが、OOの一大テーマだよな。そこでアナリシスパターン→UML2へと
流れていくんだろうか。
 結局、OOが適当なのは、中規模開発ってことなのかな。



275 :仕様書無しさん:04/11/19 17:36:05
ttp://www.doaplus.com/html/s13_006.html

276 :仕様書無しさん:04/11/19 17:42:59
>275
呼んだけどニュータイプの考えをまったく理解できない戯言に思えます。

277 :豆腐 ◆1T2swboMiw :04/11/19 17:44:07
>>270
できてないかも。
若しくは、実現不可能な仕様書書きたくないでしょ。それでがんばっちゃうわけだ。
>>271
そうです。現状ない場合のことをすっぽりと忘れておりました。
>>272
網羅にはもちろん神経使ってます。めちゃ疲弊します。
>>273
お察しの通り、
あまり大きいのはやっておりません。だからこそ、体力勝負に持ち込んでしまえているんだと思う。


278 :270:04/11/19 17:49:18
いや之は自分に対してです。

おおきい物だって実質同じだと思うんですが。
結局はいくつかのシステムに分割して人が理解できる範囲に落とし込むんだし。
全体をいくつかのサブシステムに分けてその間の関係性を把握するのはシステムが大きかろうが小さかろうが同じでしょ。

279 :270:04/11/19 17:51:03
>>277さんは自分の作りたいものを作るようにしないともったいないのかも。
人のうんこシステム作るのに労力すり減らしてるといやになってきませんか?
好きなものを好きなように作ったほうが能力発揮できそうなきガス。

280 :仕様書無しさん:04/11/19 17:51:40
>>277
このスレでそのコテハンだと
豆蔵に見えてしかたない

281 :仕様書無しさん:04/11/19 17:58:47
>>274
tp://nekop.programmers.jp/diary/?date=20041024
ここの人がいうには逆みたいよ
アナパタとかそういうのはスケールが違うとさ
DBとつなげるだけのそこらに転がってる業務システムと
ファウラーの扱う世界を一緒にするな、だってさ。

って事は、俺にはアナパタだのPofEAAは用無しだな。
自分の経験した億単位の大きい仕事だって、これによれば
どうやらそこらに転がってる業務システムの範囲内だしな。

282 :豆腐 ◆1T2swboMiw :04/11/19 18:25:14
>>278
>全体をいくつかのサブシステムに分けて
そうそう。中規模にのみ適当だとしても、OOの性質から考えると
それほどデメリットにはならないんでしょうね。

アソンデシマッタ、ソロソロシゴトシマツ

283 :仕様書無しさん:04/11/19 22:36:46
OODA OODA うるせーんだよ!

284 :仕様書無しさん:04/11/19 22:42:04
>>283
うーん、どっちかというと
OODA OODA してんじゃねーよ
じゃない?

285 :仕様書無しさん:04/11/19 23:00:34
訂正: OODA OODA してんじゃねーよ!

286 :仕様書無しさん:04/11/19 23:35:35
>>281
つか、10人で10ヶ月やれば億いっちゃうわけで。それって大規模?
大規模って1000人月越えた辺りからそういうんじゃないの?まぁ人月で比較するというのがアレなわけだが。

287 :仕様書無しさん:04/11/19 23:43:58
正直そんなでかいシステム作るのなんかぞっとする。
自社パッケージ作るならまだしも

288 :仕様書無しさん:04/11/19 23:56:44
でっかいとな。チームがたくさんできるんだな。どうやっても
各チームで進捗がマチマチにずれるんだな。
それぞれのチームが別々の会社だったりするんだな(下請け)。
うまい具合に、先に出来上がらないといけないチームが遅れて、
それができていないと作れないチームが暇ぶっこいたりしちゃうんだな。
OOでもなんでも。

289 :仕様書無しさん:04/11/20 00:06:24
100人で1,2年とかそれこそゴロゴロでしょう。
数百人で2,3年とか4,5年とか・・・。

290 :仕様書無しさん:04/11/20 00:08:46
でっかいシステムだと、NECとか日立とか富士通とかNTTなんとかとかが入り混じることもある。

291 :仕様書無しさん:04/11/20 01:15:49
2、3年も掛けるのは大規模ってわけじゃなくて、
単にバージョンアップが繰り返されてるだけでしょ。
又は予算無尽蔵のウォーターフォールデスマ。

292 :仕様書無しさん:04/11/20 01:22:51
>>291
知らないなら発言しなくていいよ

293 :仕様書無しさん:04/11/20 02:43:34
工数がいくらで大規模化はさておいて、
結局>>281のって、OOとかEAってのは
すんげー規模を相手にしないと
良さは判らんって事ですか。

豆腐君、そういう事らしいよ。
俺たち出る幕なしよ、寝よう寝よう。

294 :仕様書無しさん:04/11/20 02:47:17
>>288
OOは「この部分が先に出来上がらないといけない」ってのを見出す助けにはなるが、
それが実際に先に出来上がるようにするのは元請けのマネジメント能力の責任だからな。

295 :豆腐 ◆1T2swboMiw :04/11/20 03:38:27
>>281 >>293
 また大変なお仕事をされてる方の日記を探して来られたんですね。
EAは長期トランザクションなんかが必要なシステムだという薄々先入観を持ってる
のですが、残念ながらFowloer等と併せて、正しくは存じておりませぬ。
近く勉強しておきます。

 でも、バグがなかったりリニア特性の強い設計は誰もが求めるものであるし、
可読性が高く使い回しの効くものであれば尚更みんな欲しいでしょ。
そこで、エレガントな解法をもとめてるわけじゃないんだけど、方法論は必要だと思うし、
手分けして仕事をするんなら、エンジニアリングとして必須なってくる。
残った部分が、個人が腕力で解かなきゃならん問題なんでしょうね。

( ゚д゚)寝る!

296 :仕様書無しさん:04/11/20 04:03:40
>>294
OOってプロセスエンジニアリングの範疇じゃなくて、ソフトウェアエンジニアリングのほうだよ。

297 :仕様書無しさん:04/11/20 07:14:17
他人に言われた仕事しかしない奴に、
オブジェクト指向が理解できるはずが無いな。


298 :仕様書無しさん:04/11/20 07:15:47
関係ないだろ

299 :仕様書無しさん:04/11/20 07:17:16
早朝から糸を垂らした途端に食いつく298



300 :仕様書無しさん:04/11/20 07:23:04
野比で働いてる人いますか?
もう5年行ってないのですが、近況を教えてください。

301 :仕様書無しさん:04/11/20 08:04:21
OOAって、業務をオブジェクトを使って記述することか。

OOPってそれを元にコードを書くことか。

302 :仕様書無しさん:04/11/20 12:02:24
>>295
何をいいたいかよく分からん。
>>301
プログラマは、キーを上から下へ押さえる人です。
あんまり考えすぎないように。

303 :仕様書無しさん:04/11/20 12:15:33
>>302
そうか、プログラマーって渡辺貞夫とかコルトレーンとかのことか。


304 :仕様書無しさん:04/11/20 12:54:00
つまんね

305 :仕様書無しさん:04/11/20 14:22:08
>>129
2人だけじゃん…
って、渡辺美里とどういう関連が?

306 :仕様書無しさん:04/11/20 14:56:28
分かり始めたMy Revolution
  明日を乱すことさ

誰かに伝えたいよ
  my tears my dreams 今すぐ

夢を追いかけるなら
  たやすく泣いちゃダメさ

君が教えてくれた
  my fears my dreams 走り出せる

307 :仕様書無しさん:04/11/20 20:51:11
例えばイテレータパターンってのはOOPのパターンだよな。
OODのレベルでは単に集約として表現されている対象を
走査するためのOOPの技術って感じで。


308 :仕様書無しさん:04/11/20 21:33:52
このスレはレベルが高すぎてついいけない

309 :仕様書無しさん:04/11/20 21:45:23
馬鹿にするな、キーを下から上に離すこともできるぞ。


310 :仕様書無しさん:04/11/20 22:32:26
現在進行中の議論

4.【「オブジェクト」とは?】
  現実の物、イテレータクラス
 >>210-241
5.【OOA/OOD/OOPの各定義】
  ごっちゃになってる、要求定義
 >>242-307
ネタがきれてきたっぽいので、もう一回コピペ

過去の議題
>>206

311 :仕様書無しさん:04/11/20 22:44:52
>>269 のリンクによると、
 要求定義
 分析
 設計
 実装
 テスト
の工程があるわけだよな。 で、分析/設計/実装の各工程に置いてOOA/OOD/OOP
をやるわけだ。んで、一口にOOといってもそれぞれ目的が異なると。
そこで、どこをどうすればプログラムの変更を最小限にできるかっていうことが問題なんだな。



312 :仕様書無しさん:04/11/20 23:15:54
>>310
>>206って結論出てたか?

313 :仕様書無しさん:04/11/20 23:35:03
OOA:ビジネスモデリング。Analysys Patternとか。
OOD:実装を意識したクラス設計。Design Patternとか。
OOP:「クラス」の実装ノウハウ。フレームワークとか。

何も調べずにイメージだけで書いたので誰か突っ込んで下さい。

314 :仕様書無しさん:04/11/20 23:35:42
オブジェクト脳(笑)

315 :仕様書無しさん:04/11/21 01:40:26
>>312
本題にかかるまでに、基礎部分で合意しないといけないことが多いらしい。

316 :納豆 ◆y7XUmHaaYQ :04/11/21 02:10:29
>>311
やっぱり、仕様の変更に備えるという意味では上から順に大切だと思うし、
より上位の方法論により下位の方法論はアダプトさせる必要があるし、
まずは、要求定義が一番効くんだと思うよ。
本質的に問題を切り分けられるか否かはここにかかってるし、
それが成功すれば変更を局所的なものに押さえ込める可能性が出てくる。

あと、各部を見て「こうあるべき」っていう話をすると収集つかないと思うな。
プログラミングは、機械や電気の技術と比べると自由度が高くて小説にも似てるとこがある。
優秀なマが議論しても不毛だろうね。
例えば理屈っぽい森鴎外とある意味エロティックな三島由紀夫とが共著した小説なんて、想像できない。

仕様変更対策を考えるなら、
マの本分でないにしても、要求定義から地道に合意の枠組みをつくるしかないだろうね。
分業体制で仕事してる集団には越えにくい問題だろうな。他人事みたいに言ってるけど。

そういうわけで、>>312の挙げる個別技能的な話しに戻したらどうよ。

>>313
なんていうか、OOA/OODを知りません!っていうのがよく分かる記述ですね。
わからない言葉をつなげてもわからないし、本人もそうだろうから、専門用語に捕らわれるのは
やめた方がいいかもね。
実感持てない他人の言葉で書かれた本なんて読んでるのは実は足踏みなわけで、
もっと感じるプログラミングをやるべきだと思うな。議論にしても。本読むのが悪いって言うんじゃなくて。
そういうことをやってるから、後手に回って、他人の駄文を数千円払って買った上、夜中まで読んで
鬱になってるのかもしれんな。鶏と卵の例えのように。


317 :仕様書無しさん:04/11/21 06:57:59
喩え

318 :仕様書無しさん:04/11/21 08:08:20
>>316
は文系出身

319 :仕様書無しさん:04/11/21 09:54:04
>>316
>なんていうか、OOA/OODを知りません!っていうのがよく分かる記述ですね。

そう思うなら1箇所でも良いので具体的に正しい説明を教えて下さい。
他人を否定するばかりだと、永久に自分の理解度はチェックされませんよ。

320 :仕様書無しさん:04/11/21 10:50:23
意見を書く前にデスマかデスマじゃないかを書くべきだな。

321 :仕様書無しさん:04/11/21 13:13:21
>>319
なんでいちいちお前に説明してやらにゃならんのだ?

322 :仕様書無しさん:04/11/21 13:17:24
説明できないならひっこんでろよ

323 :仕様書無しさん:04/11/21 13:20:28
んじゃ>>313みたいなたわごと書かずにひっこんでろ

324 :仕様書無しさん:04/11/21 13:35:32
たわごと書いてんのはお前だろ

325 :仕様書無しさん:04/11/21 14:27:35
結論:どっちもアフォ

326 :仕様書無しさん:04/11/21 16:28:44
>>316
が言いたいのは、「書を捨て町へ出よう」*ってことじゃないのか。
こう書くと文系扱いされるのかなw (*寺山修司著)
もっと自分のセンスを信じて、実践していくべきだってことでしょ。
別に、バカにしてるようには読めないけどな。わかりずらいけど。

316じゃないんだけどさ、>>319よ。
社会じゃ、いつでも欲しい答えが貰えるわけじゃないし。
知りません!って内容のこと言っても教えて貰えないこと多い。
誠意を見せればいい場合もあるけど、立ち読みで済む範囲の内容なら
自分で調べた方が労力省けるし、そういう態度が誠意だったりもする。




327 :仕様書無しさん:04/11/21 16:35:47
追加。

>何も調べずにイメージだけで書いたので誰か突っ込んで下さい。
これはアカンわw。事実だとしても、「スレをまとめてみました、どなたか正否ご教示下さい。」
くらい書いてたら流れが違っただろうけど。
技術者やっていこうとすると、こういう作法も必須。

そういうと昔、「礼儀正しい学生は、丁寧に教えて貰えるので学力も伸びる」という意見が
教育関係の掲示板にあった。 スレ違いスマソ。


328 :仕様書無しさん:04/11/21 16:36:03
>>319は教えて欲しい云々じゃなくて否定するならまず>>316の考えを答えてくれ
ってことじゃねぇの?じゃなきゃ議論にもならんと。


329 :仕様書無しさん:04/11/21 18:04:46
否定するも何も、イメージだけの妄想なんだから、議論にも値しないだろ。
議論したいなら、それなりの書き込みしろよ。

330 :仕様書無しさん:04/11/21 18:09:28
>>313みたいな粘着馬鹿には関わるだけ時間の無駄

331 :313:04/11/21 19:09:48
>>327
枕言葉は謙遜だよ。
挙げた単語はそれぞれ2、3冊以上本読んでるし実践もしてるし成果も上げてる。
でもOOA/OOD/OOPという定義の境界は実践に近付くほど曖昧に感じてるから、
みんなどう思ってんのかな、って思って書いてみました。

332 :仕様書無しさん:04/11/21 19:12:16
>>331
あんたばかぁ?

333 :仕様書無しさん:04/11/21 19:16:51
分析と設計と実装の違いを教えてください。

334 :仕様書無しさん:04/11/21 19:26:50
アナルシスとデザインとインプリメンテーションだな

335 :仕様書無しさん:04/11/21 19:35:22
でも、このスレを見ていると、否定するだけで、具体的な根拠がないと思うことは、多くあるな。
否定している方も、じゃあ、なにが正しいの、と言われると、それは答えられない、というレベルなんだろうな。

なんとなく違うのは分かるが、でも、何が違うのかは説明できない。
自分で一本説明を書くことも出来ない。
突っ込まれると、言葉に詰まる。

まったく知らないわけじゃないんだが、
なんとなくは、分かってる、という人間の説明というのは、そんなレベルなんだろう。
きっと。

そんな人間ばかりが集まっているから、一定レベル以上には議論が踏み込めないんだろう。
きっと。

336 :仕様書無しさん:04/11/21 19:47:06
どう違うか教えてもらえて当然と思ってる馬鹿

337 :仕様書無しさん:04/11/21 19:50:05
>>336
いいや。
たんじゅんな感想。

338 :仕様書無しさん:04/11/21 19:51:55
>>336
その一行を書く手間でなにかネタフリを。

339 :仕様書無しさん:04/11/21 20:01:05
「このスレ」じゃなくて、この板全体でしょ。
脳内多すぎw

340 :仕様書無しさん:04/11/21 20:04:32
ここまで来ても何一つ具体的な話がでないからそうなんだろうな。

341 :仕様書無しさん:04/11/21 20:06:59
モノそのものに機能を設ける風潮は好きじゃないなぁ

データとファンクションは分けるべきだというのは
今の時代じゃ古いの?

342 :仕様書無しさん:04/11/21 20:24:55
>>333
情報処理技術者試験に、スキル標準っていうのがある。
平凡な開発標準にあわせて、米国で作られたのを日本風にアレンジした奴。
それ読んでみそ。 上流だと、AN,PM,AE等があるけど一通り流れがつかめるかもな。


343 :仕様書無しさん:04/11/21 20:28:07
>>341
だいぶベテランだとお見受けしましたが。

データの構造化
論理の構造化
データと論理の統合化した構造化
さらに・・・

との順をおって変遷してきております。

344 :仕様書無しさん:04/11/21 20:31:12
>>335
ちがうな。
おそらく、
本では読むけど、実務では方法論を意識してないのが主因だろうな。
言葉を知ってるし、経験もしてるんだけど自分の頭で考えたことがないから
自発的に表現できないんだ。 おれもそう。


345 :仕様書無しさん:04/11/21 20:39:18
>>343
それはそうかもしれないんだけど
ソフトウェアの設計とはデータ構造の設計である というのが
信念なので、その根幹が揺るぐような仕様変更の場合には
変に設計を流用しないですっぱり切った方がいいと思うんだよね。

データの取り出しひとつにもメソッドを使う今の風潮だと
入出力したデータが 本当はどう処理・保存されているか を
いかに見せないようにするかが勝負なわけで、ちょっとね。

346 :仕様書無しさん:04/11/21 20:48:48
>>345
2番目の段落、どうしてちょっと、なんだろう。

データ構造の設計である、という信念に矛盾する?

347 :仕様書無しさん:04/11/21 21:00:35
プログラム作成時に、処理対象となるデータをオブジェクトとして構造化し、
そのオブジェクトを操作する処理をメソッドとして記述し、適切なアクセス権を設定して、
情報を隠蔽、カプセル化した。

共通の性質を持つオブジェクトはリファクタリングをかけて抽出し、
上位クラスを作成して、継承を使用して記述するようにした。
同じ性質のメソッドを持ち、実装の異なるクラス群では、インタフェースを使用して、
実装を切り離した。

これはOOPといえるか、いえないか。

348 :341:04/11/21 21:07:24
>>346
ごめん。うまく説明できなくて逃げた。
本能的に矛盾を感じてるんだが説明できん。

349 :仕様書無しさん:04/11/21 21:16:40
>>347
その話は、いったいどこに行くのだ?

350 :仕様書無しさん:04/11/21 21:35:29
ビジネスロジックとデータの永続化のレイヤーは分けるってのは変わらんなあ

351 :仕様書無しさん:04/11/21 23:02:50
>>333
分析と設計と実装を厳密に分けるとすると、
実装とはタイピングの事です。
つまりOOPはタイピングの事です。

352 :仕様書無しさん:04/11/22 09:25:52
>>349
OOPと呼ぶに必要十分かどうか、という問掛けのつもりだった。

OOPだと思うなら、Y、で終了。Nなら、何が不足か、何が不要かで話が膨らむかなあ、と。

353 :仕様書無しさん:04/11/22 12:54:36
実装設計という言葉も一般的なので、却下。
むしろ、組み立て=タイピングでわ?


354 :仕様書無しさん:04/11/22 15:12:31
>>343
アルゴリズムとデータ構造は一体不可分であって、
カプセル化が望ましいっていうのが、OOな考え方なんでしょうね。
客体の限られたインタフェース(メソッド)だけを利用可能として、
主体は、そのインタフェースを扱う反復や分岐だけの論理から成る…

見方をかえると、客体毎に独立したインタフェースっていうレイヤを設けるって事なのかもしれません。


355 :仕様書無しさん:04/11/22 15:14:21
で、レイヤ化が進むと、”層”というより、”ハブ”ができて繋がっていくっていうことになるのかな。

356 :仕様書無しさん:04/11/22 23:05:29
>>354
これをホニャクすると、
何かを操作する場合、どんな操作があるかは、操作されるものによる、ってことだな。

車なら、「運転する」。
ドアなら、「開ける」。
キーボードなら、「たたく」。
画面上の文字列なら、
「挿入する」、「削除する」、「上書きする」、「切り取る」、「コピーする」、「貼り付ける」。


357 :仕様書無しさん:04/11/23 00:02:06
>>353
実装設計ってハードウェア開発系の用語じゃね?

358 :仕様書無しさん:04/11/23 22:13:15
オブジェクト指向なんて最初言われてもサッパリでした、
本読んでも全然理解も何もできなかった。
プログラミングとは殆ど関係ないが、OSI基本参照モデルを理解したあとOO習うと、
なんか分かった気がした。

359 :仕様書無しさん:04/11/23 22:21:31
>>358
その心は?

360 :仕様書無しさん:04/11/23 22:28:53
>>348
データの取り出しにメソッドをわざわざ使うのは、変数へのアクセスするインターフェイスを共通にするためだろう。
そのことによって、内部で使用されている変数がiでもjでも何でもいいと。
メソッドを使用することは隠蔽をすることではなく、使用者にインターフェイスを提供するためでは。

361 :仕様書無しさん:04/11/23 22:40:21
多分358は全然解ってないんだろうなw

362 :仕様書無しさん:04/11/23 22:59:48
>>359
>>360でも触れられてるけど、インターフェースの事かな
OSI〜なんかの考え方は(正しくないかもしれないけど)
「各層が、有るべき機能と隣接層とのインターフェースを備えているなら
中身は他と全く無関係に作っても良い」という風に理解してる。

OOを使わない、例えばC言語では、この概念はちょいと難しいなぁと思う。

戻り値void型の関数が他とデータを共有するにはグローバル変数しかないし、
グローバル変数を使うってことは、全体が左右されるし。
部品化には向かないよね。

理解できなかったってのは、C使いが陥りやすいと言われている(?)
「クラス(オブジェクト指向)なんか使わなくても一緒じゃない?」
っていう思い込みから、全て意味のないものになってしまってたことに由る。
理解しようとしてなかったんだな、きっと。

363 :仕様書無しさん:04/11/23 23:01:25
>>361
ま、世の中には電話帳を読んでオブジェクト指向が
分かるようになった奴もいるかも知れないし・・・

いいんじゃないの?
自分がそう思っている分には。


364 :仕様書無しさん:04/11/23 23:23:08
結局OOってあれだろ?大規模な釣りだろ?

365 :最凶VB厨房:04/11/24 00:56:51
>>364
そのとおりだ。

366 :仕様書無しさん:04/11/24 10:17:12
>>360
オイオイ。
お前はtestと言うフィールドにgetSampleとかってアクセサを書くのか?

367 :仕様書無しさん:04/11/24 10:47:02
>>366
それはそこまで決まるものじゃないだろ?

アクセサはあくまで外部へのインターフェースだから、内部フィールドがどうこうは関係ない。
内部フィールドとアクセサが一致してることが前提じゃ、単なる機械作業で、初心者にありがちなオブジェクトの理解だと思うぞ。


368 :仕様書無しさん:04/11/24 11:45:40
内部を隠蔽して、外部にはインターフェースを提供してるんだろうが

369 :仕様書無しさん:04/11/24 12:43:21
ま、普通は常識で考えて、フィールドとアクセサは同名にするよな。
言いたいことは解るが、例が良くないな。

370 :仕様書無しさん:04/11/24 13:10:23
だからアクセサとフィールドには関係がないと何度いったら

371 :仕様書無しさん:04/11/24 13:12:58
>>369
その普通と常識は間違ってるぞ。


372 :仕様書無しさん:04/11/24 14:03:35
369が釣りだったらまだ救われるが、マジなんだろうなw

373 :仕様書無しさん:04/11/24 14:12:51
アクセサに関する書籍の例とか、統合開発ツールでの自動下駄雪駄作成機能が、誤解を生んでいるのかな?


374 :仕様書無しさん:04/11/24 16:18:10
フィールドについて設定されるアクセサはアクセス制限の意味しかないよ。
逆にフィールドにアクセサを設定するのは、別名を割り当てられるようにするためじゃない。
頼むから、「オブジェクト指向では内部が隠蔽されるから、アクセサの名前はなんでもいいんです」なんて言って、フィールドとアクセサの名前をずらすような真似、しないでくれよ。
頼むぜ、ホント。
フィールドに対するアクセサ、って意味を汲んでくれ。

375 :仕様書無しさん:04/11/24 16:25:44
まあPublicなフィールドで済むはずの物を
くだらない制限でいちいちアクセサを
作らなきゃならん言語が糞ってこった。

376 :仕様書無しさん:04/11/24 16:31:37
>>374さんは多分>>369と同じとして。
必要条件と十分条件の違いとかがわかっていないんじゃないのか?

フィールドの名前が外に出すのに適切ならば、”たまたま”同じ名前のアクセサでOK。特に変える必要ないし。
そう考えられないのかな?

アクセサの名前がどうでもいいなんて誰も話していない。
アクセサには外部からアクセスできる適切な名前が必要。
それが”たまたま”フィールド名と同じならそれでいいだけ。

フィールド名とイコールが普通で常識という考えが間違っていることを指摘しているんですよ。

377 :仕様書無しさん:04/11/24 17:15:51
構造体クラスしか作れない人には理解出来ないですよ。

378 :仕様書無しさん:04/11/24 18:03:15
374=369さんにはCOBOLとかをお勧めしたほうがいいんじゃないかな

379 :仕様書無しさん:04/11/24 18:16:40
>>376

>>374を読む限り、そういう指摘は奴には通じないw


380 :仕様書無しさん:04/11/24 18:17:36
>>376
フィールド=アクセサと”たまたま”同じ名前になっているのではなく
”本来”同じ名前であるべき だと思うのは間違いかな。

緊急事態回避手段としてフィールド≠アクセサも許容できるように
フィールド直いじりではなくアクセサを別途設けてる と考えないと
マズイと思うのです。

381 :仕様書無しさん:04/11/24 19:24:35
俺はフィールドもアクセサも知らない素人だが、

・フィールドとアクセサを“なるべく”同じにする という考え方の“利点”
・フィールドとアクセサは“たまたま”同じならそれでいい という考え方の“利点”

を双方挙げて終わりでいいんじゃないかな。
>>378 みたいに罵倒しても、相手が今更考え方を変えるとは思えない。

382 :仕様書無しさん:04/11/24 20:17:01
フィールドってどこの方言?

383 :仕様書無しさん:04/11/24 20:25:24
>>382
Javaじゃフィールドと呼ぶんじゃない?

>>380
インターフェースと実装の分離ていう概念は理解してる?

384 :仕様書無しさん:04/11/24 20:31:37
>>383
ほー、Java用語でしたか。サンクス

385 :仕様書無しさん:04/11/24 21:23:58
なんか、フィールドとアクセサのここでの議論は全然違うと思うんだが。

そもそもフィールドに対してアクセサがあるとは限らないのと同様に、
アクセサに対してフィールドがあるとも限らない。
getFooというメソッドの内部でフィールドfooをそのまま返しているのか、
それともフィールドbarとbazから計算しているのかは外部には隠蔽されている。
例えば、あるクラスはもともとfooというフィールドを持っていたが
アルゴリズムの変更によりfooを直接は持たなくなった、という
シナリオを考えると良いと思う。

ただし、本当にフィールドに代入したりフィールドの値を返すだけの
アクセサの場合は、名前をそろえた方が良いとは思う。
そうした方がそのクラス内部のメンテナンスが容易になるからね。
でも、これは外部のクラスからのアクセスの問題とは関係が無い。

386 :仕様書無しさん:04/11/24 21:30:38
お、今>>385がいいこと言った。







ように見えるけど、当たり前の事を言ってるだけじゃん。
横からチ○○゚入れてスマン。

387 :仕様書無しさん:04/11/24 21:39:14
どの道アクセサだらけのクラスは屑クラス。
OO言語習い立てがやりそうな設計だから議論すること自体がばかばかしい。

388 :385:04/11/24 22:03:04
>>386
いえいえ、本当に当たり前のことですから。
…つか、この程度のことは当たり前と認識してもらいたいもんだよなぁ。

389 :仕様書無しさん:04/11/24 23:01:20
>>382-384
完全に釣りだろうけど、「フィールド(Field)」ってOOでは常識的な単語だよ。
日本語で「属性」、Cなんかでは構造体の名残りで「メンバ変数」とも呼ばれる。
「プロパティ」は誤解を招きやすい単語なのでOOの議論では出さないのが吉。

で、君らは何て呼んでたの?

390 :仕様書無しさん:04/11/24 23:06:32
アトリビュート/属性

391 :仕様書無しさん:04/11/24 23:34:41
メンバ変数とかプロパティとかインスタンス変数とかクラス変数とか

アトリビュートとか属性とか

392 :仕様書無しさん:04/11/24 23:41:14
日本語で属性ならアトリビュートでしょ

393 :仕様書無しさん:04/11/25 00:05:37
Smalltalk風のインスタンス変数、クラス変数という呼び名以外は全部方言。

394 :仕様書無しさん:04/11/25 00:11:04
>>393
100%同意

395 :仕様書無しさん:04/11/25 01:08:43
属性って言っときゃOK?
インスタンス変数、クラス変数を呼び分けなきゃ駄目?

396 :仕様書無しさん:04/11/25 01:15:21
オブジェクト指向使わなきゃOKだろ。

397 :仕様書無しさん:04/11/25 12:33:37
根底から覆すな

398 :仕様書無しさん:04/11/25 12:51:18
>>380
機能が単純なオブジェクトを対象にしているうちはそれでいいけど。
それが通じるのは、馬鹿が見てもすぐに内部構造まで理解できてしまう程度の範囲。

基本的にはフィールドとアクセサは分離して考えるべきもの。
それがたまたま、その形のまま見せたり入れたりしていい場合で、内部的に名前がそれでいい場合、イコールで出していいだけ。

若干曲がった例になるが、コーディング規約とかでプレフィクスを指定されている場合、そのまま出すより取ったほうがいぐないけ?

399 :仕様書無しさん:04/11/25 13:02:58
。若干曲がった例になるが、コーディング規約とかでプレフィクスを指定されている場合、そのまま出すより取ったほうがいぐないけ?

意味不明。



400 :399:04/11/25 13:03:56
スマソ
>のつもりが。に・・・

ついでに400ゲッツ

401 :仕様書無しさん:04/11/25 13:37:29
>「フィールド(Field)」ってOOでは常識的な単語だよ。
>「フィールド(Field)」ってOOでは常識的な単語だよ。
>「フィールド(Field)」ってOOでは常識的な単語だよ。

分かり始めた「ことにしたい」オブジェクト指向。

402 :仕様書無しさん:04/11/25 13:47:34
>>398
>馬鹿が見てもすぐに内部構造まで理解できてしまう程度
これはデータ構造を設計する上での 目標 だと思う。
わかりやすさ=高い保守性 というやつだよね

403 :仕様書無しさん:04/11/25 13:57:51
>>402
若干認識が違う。
あなたが言っているのはモデル化した後の状態でしょ?

モデル化する前のものを見て、一目で機能属性が把握できてしまう程度のものなら、フィールド=アクセサでOKという意味で書いた。
そうじゃなく、どうしても対象が複雑な場合、その複雑さを隠蔽して結果として適切なアクセサを与えるのが設計でしょ?
そうなると、必ずしもイコールにこだわる必要がない。


404 :仕様書無しさん:04/11/25 14:14:37
元の話がそんな複雑な話しをしてるとは思えないから
もうこの話いいんでねぇの?

405 :仕様書無しさん:04/11/25 14:18:27
分かり易くするためには、分かりやすい単語を使う必要がある。

使い慣れない外国の言葉をそのまま持ち込もうとするから、訳が
分からなくなる。 間違いない。

イテレータ?イテモウタ? オマエ何もんやねん?  みたいな。

406 :仕様書無しさん:04/11/25 14:20:47
フィールドはオブジェクト内部のアルゴリズムに依存した状態を持つ。
アクセサはオブジェクトの機能から「外部から操作可能であるべき」と要請される
対象へのアクセスを提供する。
後者は機能には関係があるがアルゴリズムとは無関係なものであり、
しばしばプロパティと呼ばれる。
本質的にアクセサはプロパティへのアクセスを提供するものなのであって、
フィールドへのアクセスを提供するものではない。

407 :仕様書無しさん:04/11/25 14:34:28
>>406
>>405は極端だが、それを平易な日本語で説明できないと、単なるOO厨だと思う。
つうか、もうこの話は繰り返しに入ってるから終わりだね。
普通で当然だと思ってる人が、考えを改める前に一緒に仕事しないことを祈る。

408 :仕様書無しさん:04/11/25 14:35:09
たぶん誰も困らない

409 :仕様書無しさん:04/11/25 14:54:29
> 普通で当然だと思ってる人が、考えを改める前に一緒に仕事しないことを祈る。

平易な日本語でお願いします


410 :仕様書無しさん:04/11/25 15:08:40
>>409
今の>>369とは一緒に仕事したくない。


411 :仕様書無しさん:04/11/25 15:20:24
>>410
結局みんなそれが言いたかっただけなんだねw

412 :仕様書無しさん:04/11/25 15:28:35
なんつうか、典型的な・・・
構造体のメンバーを隠蔽してGetter、Setter、関連関数を付けてクラス完成!
っていうレベルどまりのような人に思えて。

それで通用するのは本の例題レベルだけだと。


413 :仕様書無しさん:04/11/25 16:05:10
勝手に妄想しすぎなんだよ

414 :仕様書無しさん:04/11/25 21:49:39
>>412
なるほど、そういう人もいるのか。

インターフェースと実装の分離がオブジェクト指向の基本的な
方向性だと言うことと、GetterやSetterはインターフェースで
個々のメンバ変数は実装だという区別の、二点を踏まえれば
何も難しいことなど無いはずなんだが、それ以前の問題の人もいるのか。

415 :仕様書無しさん:04/11/25 22:39:59
>>369ももう十分反省しただろうから そろそろ勘弁してやれや

416 :仕様書無しさん:04/11/26 00:08:47
正直、アクセサの話なんかどうでもいい。

振るネタもないけどな。

417 :仕様書無しさん:04/11/26 00:12:43
随分浅い指向でしたね。

418 :仕様書無しさん:04/11/26 00:27:39
StateとStrategyって構造一緒だよね。
何で2つあるのこれ?

419 :仕様書無しさん:04/11/26 03:22:45
目的が違うと思えばいいんでないか?
そのそものStateは状態の変化による動作の変化を隠蔽するためだし、Strategyはアルゴリズムを入れ替えるためでしょ?
同じ構造とかいうならAbstractFactoryとかたたい使うものほとんど一緒になって舞う。

420 :仕様書無しさん:04/11/26 15:14:49
チンチンぶらぶらアセンブラ

421 :仕様書無しさん:04/11/26 15:51:43
>>420
そんなオブジェクトはしまっとけ

422 :仕様書無しさん:04/11/26 16:01:02
包皮で亀頭を完璧にカプセル化

423 :仕様書無しさん:04/11/26 16:41:50
もうすぐガベコレ

424 :仕様書無しさん:04/11/26 16:46:42
親クラスになれません

425 :仕様書無しさん:04/11/26 16:47:27
369が来ないと盛り上がらんな

426 :仕様書無しさん:04/11/26 16:50:32
>>422
プライベートでしか接触、内部遺伝子情報抽出がないから、アクセサは不要ですね。
まあ、あまりパブリックな場で堂々と出されても困るし。
適切なアクセサをつけるようがんばってください。

427 :仕様書無しさん:04/11/26 18:10:39
ここで「○○みたいな実装をしたいんですが、どのような設計をしたらいいかわかりません」
的な質問を投げてもよろしゅうですか?
一応、クラス関連の話です。

428 :仕様書無しさん:04/11/26 18:23:08
いいんじゃね?
たぶんすぐレス帰ってくる。

429 :仕様書無しさん:04/11/26 18:48:05
煽りのレスがな

430 :427:04/11/26 19:00:21
本当はゲ作板の方がいいのですけど、過疎ですのでこちらに質問。
RPGゲームにおいて、全ての登場キャラクターがプレイヤーとなり得るとした場合
キャラクタオブジェクトをどのように扱えばいいのか悩んでいます。

最初、キャラクタを同列に扱えるようマネジャーの導入を行い、インターフェースで
イベントを拾っていたのですが、外部ファイルにて個々のキャラクタが独自のイベントの
通知を行えるよう拡張した際に、非効率さが見えてきました。
例えば、あるキャラクタが他のキャラクタに衝突した時イベントを発生させるよう
設定した場合、マネジャーは常に全てのキャラクタの衝突を見張らなければいけなくなります。

特定のフックを必要なところだけに掛けておく、という設計でなく、あらゆるイベントに
対して同列にならんだオブジェクトに網を張り巡らす、という巧いやりかたは無いでしょうか?

雑でスマソ。

431 :仕様書無しさん:04/11/26 19:07:29
イベントごとに関連するオブジェクト群に対し網を作る。それが必要に応じて生成・削除されるイメージ。

432 :427:04/11/26 19:36:28
>>430
関連するオブジェクトが分っているなら、網に用はないんだけど・・・。

今のところは、イベントの対象を「現在操作しているキャラクタ」に限定
して対処しているんですけど、今後NPC同士のイベントを定義する事を考えて
いる為どうしても外せないんですよね・・・。

433 :427:04/11/26 19:37:18
誤 >>430
>>431

434 :431:04/11/26 19:42:46
そもそもどう非効率で何が問題なのか?
あるイベント起きたときに全部をなめるのが非効率ということ?
イベントの種類により関連するオブジェクト軍を絞り込めないの?たとえばある地域にいるもの同士とか魔法使いクラス群とか。
そんな風なインデックスを動的に場合に応じて生成することでなんかできないかと思ったのだけれど。

435 :427:04/11/26 20:14:56
>>431
もっと低水準の問題なんです。
ポリゴンのコリジョン判定や、BOIDの関心空間なんかをイベント定義したいわけです。

他のオブジェクトが多大に絡むイベントを、どのように対処して行けばいいのかなと思ったのですが。
ひょっとしたら、非効率ではなく「必要」な処理で、
今までイベントの発生の所在がはっきりしていたので非効率に思えるだけかもしれませんけど。

436 :仕様書無しさん:04/11/27 00:39:14
>>430
その文章だと断定出来ないけど、プレーヤーが共通のインタフェースを持っていて、
マネージャが全プレーヤーのインタフェースにアクセスしてるって事?

もしそうなら逆がいいと思う。具体的にはプレーヤーがイベント発生時にマネージャに通知する。
監視対象となる共通イベントについてはプレーヤーの基底クラスで定義。
必要なら、プレーヤー、マネージャー共にもう1階層の継承関係を作って、
必要なまとまり毎にイベントの通知、処理を行うと。

Observerパターンが近いかも。

437 :仕様書無しさん:04/11/27 00:46:07
インスタンス生成 → メソッド呼び出し で2行。
関数なら1行。沢山書かなきゃいけない指向など、選択の余地は無い。

438 :仕様書無しさん:04/11/27 18:36:21
>>437
あんまり面白いこと言うからレス止まっちゃったじゃないか。


439 :仕様書無しさん:04/11/27 20:20:33
>>437
関数の引数の定義にあと2行ほどいるだろ。


440 :仕様書無しさん:04/11/28 00:17:34
名無しクラスみたいに名無し関数ってできないだろうか。

  { ... }(a, b, c);

とか。


441 :仕様書無しさん:04/11/28 00:35:10
>>440
言語によっては、クロージャという仕組みが言語使用にある。

442 :仕様書無しさん:04/11/28 12:29:42
>>440
それは本来 Java の言語仕様にも入る筈だったのだが、

「これは Java が対象とする
"普通のプログラマ"(要するにヴァカ)
には使いこなせないだろ」

というので、お蔵入りになった事で有名な機能だな。


443 :仕様書無しさん:04/11/28 12:55:09
>>442
お前、普通に人間小さめ。

444 :仕様書無しさん:04/11/28 13:36:13
実際Javaはそういう用途で開発されたものだし
要は現代のCOBOL

445 :仕様書無しさん:04/11/28 13:40:37
>>443
お前、普通にアナル小さめ。

446 :仕様書無しさん:04/11/28 13:45:14
C#のデリゲートも、MSがJava仕様に提案したけど
却下されたらしいですね。勿体無い。

447 :仕様書無しさん:04/11/28 14:05:13
>>445
お前、異常にチンポ小さすぎ。

448 :仕様書無しさん:04/11/28 14:52:06
>>447
お前、異常にイクの早すぎ。

449 :仕様書無しさん:04/11/28 16:43:37
お前らの戯れ方が理解できん

450 :最凶VB厨房:04/11/28 17:40:41
>>449
オブジェクト指向が好きなやつは
妄想好きなのさ。

451 :仕様書無しさん:04/11/28 22:24:54
>>477-478
待て待て。
お前らどういう関係だ。

452 :仕様書無しさん:04/11/29 00:34:18
未来の>>477-478さん、
大変ですが連携プレーよろしく。

453 :仕様書無しさん:04/11/29 00:48:17
どうでもいいけどJavaでも無名クラス作れるぞ。

454 :仕様書無しさん:04/11/29 09:37:59
将来の書き込みに対応して予め連携を決めておく、デザインパターンですね。>>451


455 :仕様書無しさん:04/11/29 19:20:16
>>451
え!?どんな関係なんだろう?
最近のドラマ予告より、わくわくするぞ。w

456 :仕様書無しさん:04/11/29 22:46:56
>>453
>>437あたりの発想に従えば、クロージャと同じ事をするのに
いちいち無名クラス作ってメンバ関数として実装するのは
タイプ量が2行ほど増えるからクソってことになるんじゃないか?

457 :仕様書無しさん:04/11/29 23:32:19
苦労するじゃ。


458 :仕様書無しさん:04/11/29 23:36:54
サムイ

459 :仕様書無しさん:04/11/30 00:12:31
お前等って、技術的な話にはダンマリなのに、
安い煽りには過敏ですね。

460 :仕様書無しさん:04/11/30 00:20:28
そりゃ2chですから

461 :仕様書無しさん:04/11/30 00:26:25
そりゃマ板はネタ板ですから

462 :仕様書無しさん:04/11/30 00:27:42
クロージャって書き方違うだけで、出来る事はクラスと一緒だろ?
ならいらないじゃん。

463 :仕様書無しさん:04/11/30 00:35:27
まずはクラスでYコンビネータを作ってから
口を利け。


464 :仕様書無しさん:04/11/30 09:35:13
Yコンビネータの「Y」は、女性の股間をあらわしてるんですか?
技術的な質問なのでちゃんと答えて下さい。

465 :仕様書無しさん:04/11/30 10:18:17
アゲハ蝶の幼虫のくさいところ

466 :仕様書無しさん:04/11/30 22:43:42
Y結線をΔ結線に変換してから
口を利け。


467 :仕様書無しさん:04/11/30 22:47:07
股間のデルタゾーン

468 :仕様書無しさん:04/12/01 01:44:23
結局オブジェクト指向って厨の集まりだね。

469 :仕様書無しさん:04/12/01 12:27:33
アンチオブジェクト指向の人間って実在するのか?

470 :仕様書無しさん:04/12/01 13:11:58
All or Nothing な主張は、どっちにしても厨。
自分で適用できる範囲、理解できる範囲でいいじゃん。


471 :仕様書無しさん:04/12/01 13:45:11
>>469
ややアンチ↓
http://www.doaplus.com/html/s13_006.html

472 :仕様書無しさん:04/12/01 14:30:05
>>471
その人業務システムに凝り固まってるローとるという感じしか受けない。

473 :仕様書無しさん:04/12/01 14:39:54
でも業務系でDB前提だとしたら、言ってることは間違っていない。
別に無理に、ビジネスロジック部にオブジェクト指向を取り込む必要なし。

474 :仕様書無しさん:04/12/01 14:43:28
業務系に限定しての話だからあながち間違いとも思わないなぁ、俺も

475 :仕様書無しさん:04/12/01 15:03:37
業務系の場合、ORマッピングはどうしても性能劣化を招くからね。
RDBに匹敵する性能・信頼性のあるオブジェクトDBが出てこない限り、あまり無理してオブジェクトに固まる必要ないし。
この考えでいくと、実はJAVAより.netのほうが開発しやすいということになるんだが。
(理想論のJAVAと現実解の.net)

476 :仕様書無しさん:04/12/01 15:42:48
業務系にはVBが最適

477 :仕様書無しさん:04/12/01 15:54:11
スモールクライアントが安定してるなら。
.netでWinFormのスモールクライアント+Webサービス+DBが一番綺麗なように思う。


478 :仕様書無しさん:04/12/01 16:22:06
業務系の話は定期的に盛り上がるなあ。


479 :仕様書無しさん:04/12/01 16:23:48
スモールライトが安定してるなら。
四次元ポケットでドラえもんのスモールライト+どこでもドア+暗記パンが一番綺麗なように思う。


480 :仕様書無しさん:04/12/01 19:14:51
>>479
よりによって暗記パンですか

481 :仕様書無しさん:04/12/01 19:16:58
スモールライトで小さくなって
どこでもドアで女湯へ
暗記パンで目に焼き付けておいて
あとで使うわけだな。

482 :仕様書無しさん:04/12/01 22:05:17
な に に?

483 :仕様書無しさん:04/12/01 22:17:31
ちょっと待って!
暗記パンは 覚えたい対象に押し付けてコピーしないと駄目じゃん!


・・・押し付ければいいのか。問題ないな。

484 :仕様書無しさん:04/12/01 22:24:57
そのためのスモールライト。
だが流されないか心配。

485 :仕様書無しさん:04/12/01 23:01:00
しかしだな・・・
どこでもドアは、宇宙地図の範囲(地球から半径十光年以内)でしか移動はできないぞ。


486 :仕様書無しさん:04/12/02 12:36:26
十分だろ。銀河鉄道を廃業に追い込んだほどだぞ。

487 :仕様書無しさん:04/12/02 14:25:00
コーヤコーヤ星にはもう行けないんだったな・・・

488 :仕様書無しさん:04/12/02 22:37:18
>>485
そういう場合はワープコアを使えばいい。


489 :仕様書無しさん:04/12/05 11:17:46
オブジェクトの事をオブジェって言う女性が居るんですが、
告白してもよいものでしょうか。

490 :仕様書無しさん:04/12/05 12:29:23
>489
おフランス好きは元オリーブ少女だな。

フリッパーズ・ギターとか好きだぞ多分。

491 :仕様書無しさん:04/12/08 02:06:49
>>471
「ソフト産業は混乱している」と言いながら、どう混乱していて
その混乱の何が問題なのかが全く分からない文章だな。
つか、混乱しているのはお前の頭の方じゃねーの? みたいな〜
6.(1)の文章を書くのに一々文献を参照している辺りから見ても
この筆者が大した経験を積んでいるようには思えないんだが…

レスポンスを出すために「オブジェクト指向の設計を崩してバイパスを設け」
なければならないケースがあるからオブジェクト指向なんて無駄だって論理は、
レスポンスを出すために正規化を崩さなければならないケースがあるから
正規化なんて無駄だって論理と同じ。
こういう発想はDOA的にもよろしくないと思うのだが…それとも、この筆者は
そういうポリシーで今までシステムを作って来たのだろうか…

492 :仕様書無しさん:04/12/08 10:33:07
無勉強で一般論かき集めて書いてるだけだよ。
このスレの大半の人達みたいにw

493 :仕様書無しさん:04/12/08 17:08:56
オブジェクト指向をある本で分かりやすく書いてあったが
『自分ができないことを、専門家や担当者にお願いしてやってもらうこと』
自分BASIC(年的には実年齢+10年の技術)しか分からないんだが

例に挙げて
BASICだと
『料理を調達して料理を作って料理を出す』
システムが一からついて回っていちいち指示を出す
これだと別の仕事のとき、始めからもう一度人を雇うことからやらなければいけなかったものを

オブジェクト指向だと
『・料理を作る人
 ・材料を調達してくる人
 ・できた料理を運ぶ人
と役割分担してやったものをシステムが次の人に手渡しする。
そのために次にやるときも、同じことするなら人を使いまわせる』
という見解でいいのかな。

>491
いまITが盛んに言われている中でも、ITに頼っちゃだめだと悪い部分のみを主張する奴がいるからそれと同じ感じじゃない?
2chのいろんな板でも
いい面をあげても『そんなことはしらん。聞いたことがない。でも○○はだめなんだ!!』と、全く知らない奴が抜かすことあるんだから
まあ専門家ぶっている頭の悪いDQNが、自分で自分の顔に泥塗って他人に塗りたくったつもりでいるだけなんだからほっとけばいい。

494 :仕様書無しさん:04/12/08 17:19:37
>>493
>見解でいいのかな
全然×。
つーか知らんでけなすというのはまだしも
知らんで見当違いのことを言って持ち上げるあんたのほうがよっぽど害悪。


495 :仕様書無しさん:04/12/08 20:08:28
一番害悪なのは理由も言わずに否定するお前

496 :仕様書無しさん:04/12/08 21:08:44
>>495
>>493のレスは営業畑のアホ社長のコンサル口まねお猿とまったく変わらんだろうが。
つーかあんたも部外者だな。


497 :仕様書無しさん:04/12/08 21:37:30
>>496
>>495は、>>493の内容がどうこうじゃなくて、
お前の書き込みが、このスレでは、一番レベルが低いとして扱われる種類のものだ、
って指摘してるんだよ。
お前からしてみれば「俺は>>493よりよく知ってるはずなのになんで?」
と思うだろうが、言ってみれば、>>493よりも下なんだよ。

>>335,344


498 :仕様書無しさん:04/12/09 11:53:27
その例で言うなら「料理人」と「材料」はそれぞれ分けて考えるべきと思う。

料理人は料理人で 中華担当とかイタリアマンとかクラスが分かれてて
材料は材料で 根野菜とかしいたけとかクラスが分かれてて
料理する人される人別なんだよ。

499 :仕様書無しさん:04/12/09 11:56:09
で、更に言うと、料理人には「切る」とか「炒める」とかメソッドがある

材料には、自分自身について「鮮度」とかのプロパティを見る機能は
あるけれども、自ら進んで何かをするような能動的なファンクションは
無い。

という感じで分離するべき

500 :仕様書無しさん:04/12/09 12:26:36
例えなんだから重箱の隅をつつくなよ

501 :仕様書無しさん:04/12/09 12:40:02
まあ、そういう部分が原理主義者臭くて、こういう奴がいると議論が止まるんだよね。w


502 :仕様書無しさん:04/12/09 13:32:38
まあ データと機能は分離しなさい という話だよ
原理主義といえばそうなるだろうけど

503 :仕様書無しさん:04/12/09 14:31:55
>>502
> まあ データと機能は分離しなさい という話だよ

アンチOOの方ですか?
もしかして「インターフェースと実装の分離」というのを勘違いして覚えてしまったとか?w


504 :仕様書無しさん:04/12/09 15:39:54
>>503
いや。OO使ってるよ。多態めちゃくちゃ便利じゃん。

たとえば、ストリームクラスとかが野菜に相当する。

505 :仕様書無しさん:04/12/09 16:26:45
で、本当に「データと機能は分離しなさい 」と思ってるわけ?w

506 :仕様書無しさん:04/12/09 19:41:18
>>499は、まあ、そうかもな。

が、>>502で何故そうまとめるんだ、馬鹿たれが。
そのものいいじゃ、俺だって突っ込むよ。
違うだろが。

はい。やり直し。

507 :仕様書無しさん:04/12/09 20:52:19
>>506はどう考えてるんだ

508 :仕様書無しさん:04/12/09 23:41:37
>>498
>その例で言うなら「料理人」と「材料」はそれぞれ分けて考えるべきと思う。

”べき”っていうのが一番ズレてる発言だと思う。
要件に応じて最適な粒度は変わるんだから。

509 :仕様書無しさん:04/12/10 00:25:24
>>508
つっこみどころ、そこかあ?
単独ならともかく、俺は>>493に対するつっこみとしての>>498-499は、
それこそ根こそぎ的外れだと思いますがね。

>>493
>BASICだと
>『料理を調達して料理を作って料理を出す』
>システムが一からついて回っていちいち指示を出す
>これだと別の仕事のとき、始めからもう一度人を雇うことからやらなければいけなかったものを

>オブジェクト指向だと
>『・料理を作る人
> ・材料を調達してくる人
> ・できた料理を運ぶ人
>と役割分担してやったものをシステムが次の人に手渡しする。
>そのために次にやるときも、同じことするなら人を使いまわせる』
>という見解でいいのかな。

>>498-499
>その例で言うなら「料理人」と「材料」はそれぞれ分けて考えるべきと思う。
>で、更に言うと、料理人には「切る」とか「炒める」とかメソッドがある

>>508
>>その例で言うなら「料理人」と「材料」はそれぞれ分けて考えるべきと思う。
>”べき”っていうのが一番ズレてる発言だと思う。
>要件に応じて最適な粒度は変わるんだから。

どうよ、これ?

510 :仕様書無しさん:04/12/10 10:26:50
>>509
どうよ といわれても引用だけで意見が書いてないから
なんにも言えないよ

511 :仕様書無しさん:04/12/10 21:12:24
>>509
誰もが自分の脳内の理解者だと勘違いしないで下さいね。

512 :仕様書無しさん:04/12/10 21:15:32
デザインパターンって噛めば噛むほど味が出るな。
2年くらい前にGoF勉強した時は、なんだこんなもんかと思ってたけど、
今読み返したら宝の山に見えてくる。

513 :仕様書無しさん:04/12/10 22:17:59
オブジェクト指向はインターネットに転がるエロ画像に似ている。
最初は興奮するんだがね・・・
それはもう一日中繋ぎっぱなし


514 :仕様書無しさん:04/12/11 03:15:24
野菜たん.切腹;

515 :仕様書無しさん:04/12/12 17:09:17
>>512
パターンにのっとってるときは人に説明するのが楽だしな。
アルゴリズム集というか、ひながた・スケルトンの類だよね

516 :仕様書無しさん:04/12/12 18:16:56
なんでこうも実務の世界でOOが浸透しないんだ。

アメリカやインドはどうなんよ?

517 :仕様書無しさん:04/12/12 20:02:25
別に日本で普通に浸透してるがな。
Java開発なら100%オブジェクトしこうだがな。

518 :仕様書無しさん:04/12/12 20:03:04
だから浸透してないのは、底辺が集まる業務系だけだって・・。
それなりのところでは当たり前に普及している。

519 :仕様書無しさん:04/12/12 20:56:23
OOが唯一神だと考えるほうこそ底辺

520 :仕様書無しさん:04/12/12 21:24:58
Javaってほぼ100%業務系だよな。

521 :仕様書無しさん:04/12/12 21:34:37
>>520
組み込み分野でも少々

522 :仕様書無しさん:04/12/12 22:00:58
ファームウェアみたいにして使う事もあると知った

523 :仕様書無しさん:04/12/12 22:01:44
今、実際に組み込みの制御プログラムにJAVAが使われているものはなくはないか?
i-modeみたいのはしらないけど、そのハード自体を制御するプログラムの開発言語としてJAVAが採用されているケースはないと感じるんだが。
具体的にはなんの組み込みなの?

524 :仕様書無しさん:04/12/12 22:04:42
火星探査機オボチュニティの制御ソフトって、JAVAで書かれてたんじゃないの?

525 :仕様書無しさん:04/12/12 22:18:08
>>523
TINIとか

526 :仕様書無しさん:04/12/12 22:30:21
オポチュニティってトラブッてたじゃん

527 :仕様書無しさん:04/12/12 22:36:22
でも回復してなかった?

528 :仕様書無しさん:04/12/12 23:20:47
分かり始めたmy revolution 明日を変えることさ

529 :仕様書無しさん:04/12/13 02:05:07
オブジェクト指向の達人のおまいらは開発環境なに使ってんの?
自分はWindows系主体なのでVisulalStudilo+自分で作ったモデリングツールもどき使ってる。
おまいらの満足してる環境、こんな理想の環境を教えてくれ。

530 :仕様書無しさん:04/12/13 10:28:47
>>529


貧乏なので

531 :仕様書無しさん:04/12/13 12:33:00
オブジェクト指向の開発環境ってのは考えたことなかったなあ。


532 :仕様書無しさん:04/12/13 16:29:55
>>529
Delphiかな・・・
厳格なOOは出来ないけど、これで十分と思っております

533 :仕様書無しさん:04/12/13 16:35:18
だったら VB (ry

534 :仕様書無しさん:04/12/13 16:40:09
>>532
>厳格なOOは出来ないけど、これで十分と思っております
厳格なOOってどんなイメージ?

535 :仕様書無しさん:04/12/13 16:54:09
>>534
横レスだけど、多分全てがオブジェクトで構成される言語では?
JAVAも基本型部分がNG。

536 :529:04/12/13 17:13:08
ごめん質問の趣旨違ったかも・・・
OOする上で便利なツールあればって意味で聞きました。
自分はC++で紙と自分で作ったシーケンス図がソースに吐き出せるツール使ってやってるんだけどそこらへんをみんなはどうしてるのかを聞きたかったんです。
モデリングツールとか実際に使って満足してる人いるのかと。

537 :仕様書無しさん:04/12/13 18:31:51
EAさいこー

538 :仕様書無しさん:04/12/13 22:45:14
OOする上で最も便利なツールはホワイトボードだよ。

539 :仕様書無しさん:04/12/13 23:38:34
EAつかえねぇ

540 :仕様書無しさん:04/12/14 03:43:21
OOする上で最も便利なツールは会社の壁である。

                     マイクロソフト

541 :仕様書無しさん:04/12/14 10:17:05
会社の壁が全面ホワイトボードって会社
あるらしいですね。うらやましい。

542 :仕様書無しさん:04/12/14 11:09:28
>>541
折檻部屋じゃなくて?w


543 :仕様書無しさん:04/12/14 12:23:18
お前んちの折檻部屋は、6面全部ホワイトボードの立方体にでもなってるのか。

544 :仕様書無しさん:04/12/14 12:53:45
6面て、床と天井も?
プロジェクトメンバー全員忍者か、かっこいーな!

545 :仕様書無しさん:04/12/14 12:57:05
んで隣の部屋につながっててわけわからん数字かいてあったりな

546 :仕様書無しさん:04/12/14 16:50:10
とりあえず、6面ホワイトボードだと効率悪そうだ。
室内で移動できるように、電池駆動なホワイトボード欲しい、てか乗り回したい。

547 :仕様書無しさん:04/12/14 16:58:18
>OOする上で最も便利なツールは会社の壁である。
マジやってくんないかな、パーテーションがホワイトボードでもいいな。


548 :仕様書無しさん:04/12/14 17:02:06
21型2面使ってると結構快適

549 :仕様書無しさん:04/12/14 17:18:50
アップルも壁がホワイトボードだと噂に聞いた。
真面目に羨ましい。床に粉がたまりそうだけど。

550 :仕様書無しさん:04/12/14 17:24:21
↓これ、まねっこしてみた。
tp://d.hatena.ne.jp/t-wada/20041114

いいかんじ。愉快。
OOな人って、アナログ好きだよね。

551 :仕様書無しさん:04/12/14 17:30:18
図を描くのがドローツールになじまないんだよね。
ワンノートってどうよ。

552 :仕様書無しさん:04/12/14 17:43:52
自社開発とかの場合、考えを相手に伝えることより、自分が考えたことをとりあえず残すことが大事だからね。
ツールとか下手に使うより、とりあえず書いとくっていう姿勢は試行錯誤する段階で正しいと思う。

553 :仕様書無しさん:04/12/14 21:04:37
会社の開かずの扉をこじ開けてみたら、全面ホワイトボードばりの部屋で、その上に赤のマーカーで、一面にびっしり、
「マネージャー、出して。」
「マネージャー、出して。」
「マネージャー、出して。」
「マネージャー、出して。」


554 :仕様書無しさん:04/12/14 22:36:19
つまんね

555 :仕様書無しさん:04/12/17 22:20:51
お前等ドキュメントってどうしてますか?
開発進める段階でクラス図とかをメモ書きしたりするけど、
結局統一的に書いたものが無くて、
JavaDocの印刷とリバースしたクラス図で客ごまかしてるんだけど。
やっぱりOOの開発ってそんな感じだよね?

556 :仕様書無しさん:04/12/17 22:23:24
DQN会社はそんなもんだろうな


557 :仕様書無しさん:04/12/17 22:25:42
DoQument Nothing

558 :仕様書無しさん:04/12/18 00:56:05
5年前だがインド人の会社ですらUML使った図でバリバリに書いてたぞ

559 :仕様書無しさん:04/12/18 00:57:06
インド人の会社ですらは失礼。インド人の会社では。

560 :仕様書無しさん:04/12/18 23:20:27
ソースコード全部印刷って馬鹿ですか?
Javaでコードレベルの全フローチャートって本格的な馬鹿ですか?
この規模の納品でドキュメント1mって脳味噌に違う物が入っていますか?

561 :仕様書無しさん:04/12/19 00:13:06
>>560
そのソースリストに通し番号を手でつける職場もあったりする。
そうやってみな時間で稼ぐような奴隷根性が身に着くんだよ。

562 :仕様書無しさん:04/12/19 01:13:54
この規模かどの規模か知らんが、環境に優しくないからやめてくれ。

563 :仕様書無しさん:04/12/19 02:36:26
脳味噌の位置に脳味噌が入ってない人は確かに多い。

564 :仕様書無しさん:04/12/20 13:55:31
>>559
途上国なんだから、別に失礼じゃない。

565 :仕様書無しさん:04/12/20 14:55:38
ソフトに関しては日本のほうが途上国

566 :仕様書無しさん:04/12/20 15:05:53
途中で追い抜かれた。 やり方が完全に間違っていたのだ。

567 :仕様書無しさん:04/12/20 15:42:55
無効下請けを海外でやるだけあって、UMLなどは1998年でかなり使いこなしてた。

568 :仕様書無しさん:04/12/20 15:43:53
向こうね。

569 :仕様書無しさん:04/12/20 15:59:04
>>565-566
君らが平均レベルを下げているんじゃないか?

570 :仕様書無しさん:04/12/20 16:15:06
だな、自分=日本とかって考えないで欲しいね。w

それと、別にUMLは特別なものじゃないし。
そもそもUML=オブジェクト指向じゃないし。
あくまで表記法の1つであって、別にそれが出来たから何?って思うんだけど。
(読むのは馬鹿でも出来る、問題は描くときの脳みそ側)


571 :仕様書無しさん:04/12/20 16:56:04
ところで、UMLって「描く」ものなの?。
いままで「書く」ものだと(ry

572 :仕様書無しさん:04/12/20 17:00:26
>>571
こだわる人がいれば議論になるんじゃないの?w
UMLは文章か図表かで、私は図表だと思ってるので描くだけど。


573 :仕様書無しさん:04/12/20 17:39:22
第一候補になってる方で。

574 :仕様書無しさん:04/12/20 17:54:27
>>569
オマエ様のような優秀な人間は、平均レベルを上げる程
たくさんはいない訳だ。 良かったな、貴重品で。

575 :仕様書無しさん:04/12/20 18:18:35
>>570
大した意味は無いけど「使える」のニュアンスが自分と違うなと思った。
自分が「UMLが使える」と言ったら
それは「オブジェクト指向の設計ができて
時と状況に応じて図を的確に使い分けられる」を意味している。
つまり570の言うところの「描くときの脳みそ側」だね
(そして自分はまだUMLを使えない訳だがw)。
「使える」をこういう風に定義している人ってあまりいないのかな。

自分も勉強し始めのころは「表記法」と感じた。
しかし単なる表記法の本がこんなに出版されるわけないから
何か便利な使い方があるはずだと思っていろいろと調べた。
いまのところ「きちんと使えれば」考えをまとめるのに
役に立つツールとして認識している。

576 :仕様書無しさん:04/12/20 23:28:21
結局は単なる表記法って事じゃね?
「使える」とは脳内を的確に表現出来るって事で、
脳味噌のレベルは別次元の問題だし。
>>575がUMLで考えを纏められるのはオブジェクト脳が発達したからでしょ。

577 :仕様書無しさん:04/12/21 01:17:34
おいどんは設計時にシーケンス図書かないとだめでごわす

578 :仕様書無しさん:04/12/21 01:57:23
>>575
C言語でもオブジェクト指向のプログラムを書くことは出来るが
C++の方がより自然に書くことが出来る。
同様に、UMLを使わなくともオブジェクト指向の設計を書くことは出来るが
UMLを使えばより自然に書くことが出来る。

579 :仕様書無しさん:04/12/23 01:08:54
Cでオブジェクト指向書けないだろw

580 :仕様書無しさん:04/12/23 04:40:21
 C++で書いたソースはオブジェクト指向で、そのコンパイラが吐いた
機械語コードは非オブジェクト指向だ、なんてことはないだろう。
 たしかに煩雑なコードは増えるが、動作の骨格はオブジェクト指向的な
プログラムは書けるはず。
 ただ、工数は増えるわ一見ただのコピペの嵐に見えるわで、
メリットはあまりないだろうが。

 むしろ、JAVAやC++を汎的業務指向言語として活用する例が多すぎ。

581 :仕様書無しさん:04/12/23 07:41:47
>>580
> ただ、工数は増えるわ一見ただのコピペの嵐に見えるわで、
>メリットはあまりないだろうが。
そこはバランス感覚。
確かに1から10まで実現しようとしたら大変なことになると思うけど
流用に重点をおいて設計する分には大変なことにならない。
設計段階で1機能を1クラスにまとめ
コーディングはCに合ったやり方ですればいい。
オブジェクト指向って設計手法の一つなんだから
手法に振り回される必要はない。

582 :仕様書無しさん:04/12/23 13:36:40
工数増えるのはスキル低いからだよ

583 :仕様書無しさん:04/12/23 23:07:05
>>579
無知だな〜

584 :仕様書無しさん:04/12/25 11:03:51
>>583
マジで?じゃクラスとか書けるの?

585 :仕様書無しさん:04/12/25 11:25:25
>>582
工数増えるのは交渉能力の低さだと思うな。
アホみたいな工数を取ってこれる奴がスゴイ奴

586 :仕様書無しさん:04/12/25 11:32:00
工数って見積もり工数と実作業工数のどっちの話ですか?

587 :仕様書無しさん:04/12/25 11:32:08
工数増えるのは交渉能力が低いからなんだ。

アホみたいな工数を取ってくる・・・?

工数増える

スゴイ奴

・・・?

588 :仕様書無しさん:04/12/25 12:48:46
もしやユーザ目線?

589 :仕様書無しさん:04/12/25 13:05:56
>>584
Windows API みたいなのが純 C でオブジェクト指向(もどき)をしている良い例。


590 :仕様書無しさん:04/12/25 13:17:11
>>584
WindowsAPItって思いっきり手続き指向な気がするけど・・・。
っと、思ったが、中のつくりはオブジェクト指向なのか・・・?

591 :仕様書無しさん:04/12/25 13:56:54
>>590
ウィンドウを作るために思いっきり WINDOWCLASS なる構造体があるし、
既存のウィンドウの機能を拡張(制限)するために「サブクラス化」なる手法を使う。
サブクラス化というのは、本来処理すべきウィンドウプロシージャ(イベント処理関数)を
差し替えることなんだけど、これがいわゆるポリモーフィズムの考え方と同じ。

592 :仕様書無しさん:04/12/25 13:59:30
WINDOWCLASS じゃなくて WNDCLASS だった。

593 :仕様書無しさん:04/12/25 14:05:02
オブジェクト指向の根幹になっているメッセージ交換もキッチリ実装されてるしね
SendMessage/PostMessage が . 演算子で、メッセージ番号がメソッド名に対応している。

594 :仕様書無しさん:04/12/25 15:47:18
WindowsAPI は置いとくとして、
他の言語では言語仕様レベルで実装されてるものを
自力で実装しないといけないわけじゃん。
わざわざ C でオブジェクト指向やらないといけない場面なんて、
相当限られてくるよね。

595 :仕様書無しさん:04/12/25 15:50:04
>>594
>自力で実装しないといけないわけじゃん。

それが間違い。
既製のライブラリは山ほどある。


596 :仕様書無しさん:04/12/25 15:54:37
それ、JavaとC、どっちが楽?って話じゃないの。

597 :仕様書無しさん:04/12/25 16:07:29
どうあがいても、言語として実装されてるほうが使い勝手はよいでしょ。
C#のような属性とかCでどうやって実装する気?

598 :仕様書無しさん:04/12/25 16:09:53
>>594
「わざわざ C」ではなく「C でもできる」というのが
大事なのかも。

599 :仕様書無しさん:04/12/25 16:12:02
>>597
たとえ C#(や Java)でも最終的には機械語に落ちてそれを CPU が解釈する以上、
それと等価な C のコードは理論的には書けるでしょ。

むろん、コーディングのやりやすさとかは無視してるけど。

600 :仕様書無しさん:04/12/25 16:51:43
>>599
Cなら論理的にかけて、他のだと書けない、なんてことはないよ。

601 :仕様書無しさん:04/12/25 17:18:19
Cと、C++やC#を取り違えてない?
それともCにオブジェクト指向を実現するようなライブラリがあるの?

>>599はオブジェクト指向は理論的に機械語で書けるみたいな事言ってるからスルーだけど。

602 :仕様書無しさん:04/12/25 18:47:25
>>601
たとえば、Windows API。
たとえば、GTK+。
たとえば、C++ の初期の実装のプリプロセッサ。

603 :仕様書無しさん:04/12/25 18:53:04
Smalltalkモナー

>古くて誰も見向きもしなかったApple Smalltalk上で、新たなSmalltalkのイメージを開発、
>さらにSmalltalkで書いたSmalltalk Interpreterを、やはりSmalltalkで書かれたトランスレータで
>Cに変換してコンパイル。コンパイルしてできたVM上で新たなイメージファイルを動かして、
>またInterpreterをデバック、それを変換して。。。
>
>どうです。まるで輪廻のように循環してるじゃないですか。こりゃすごい。

ttp://www.mars.dti.ne.jp/~umejava/smalltalk/squeak/

604 :仕様書無しさん:04/12/25 19:17:15
>>599
クラスの継承をCで実装してみてくれ。
機械語レベルで等価になっても人間の頭が追いつけるか
どうかは別問題だと思うぞ。

605 :仕様書無しさん:04/12/25 19:25:38
>>604
だから、WinAPI はクラスの継承を実装してるじゃん。
関数ポインタを実行時に書き換える形で。

606 :仕様書無しさん:04/12/25 20:07:15
>>604
型情報と関数テーブル(vtable)でできると思うが。
そんなにムズイか?
ただ、インスタンスの生成(組み立て)はFactoryMethodパターンを使うなりして、
隠蔽しないと、利用する人の頭に追いつかないかも。

607 :仕様書無しさん:04/12/25 20:17:24
http://plaza.rakuten.co.jp/batrowa/
ここに行ってゲームのことを一から学ぶ<丶`Д´>ニダー

608 :仕様書無しさん:04/12/25 20:20:30
なんかオブジェクト指向言語で作るのが
オブジェクト指向、みたく変な勘違いしてる奴いない?
オブジェクト指向なんて設計手法なんだよ。
クラスだってオブジェクト指向の考え方を構成する
概念に過ぎないんだよ。こういう考え方をするとまとめ易いとか。
ここでCとかJavaとか下らないこと言ってる奴って
オブジェクト指向言語でコーディングしてるってだけで
オブジェクト指向を理解できていないんじゃないかな。

609 :仕様書無しさん:04/12/25 21:18:16
たとえば、最近、Java でアスペクト指向なんてのが流行りつつあるけど、そもそも
Java の言語仕様にアスペクト指向に対する考慮なんてないでしょ。
AspectJ とかは、陰に陽にアスペクト指向の仕組みを後付けでねじ込んでるだけ。

オブジェクト指向もそれと同じで、必ずしもオブジェクト指向が考慮された言語を
使うことだけがオブジェクト指向プログラミングではない。

610 :仕様書無しさん:04/12/25 23:46:05
入門書の「オブジェクト指向とは?」に書かれているよーな事
恥ずかしげもなく書いているな・・・学生かな?


611 :仕様書無しさん:04/12/26 00:04:28
まあ、>>604はGTK/GObjectのソースでも読んでろってこった。

612 : :04/12/26 02:24:29
ゲームPGと業務PGは別の職種だからな。
一緒にすんなボゲェ。

613 :仕様書無しさん:04/12/26 02:26:00
オブジェクト指向で重要なのは上流工程でプログラム組む段階ならなんでもいい
OOLの方がいいのはそりゃそうだけど

614 :仕様書無しさん:04/12/26 04:34:51
オブジェクト指向言語ってなんだすか?もう、見てらんない。
なら見るな!

そうでつか。。。

615 :仕様書無しさん:04/12/26 18:30:17
>>608
ちんげ

616 :仕様書無しさん:04/12/26 21:24:27
>>615
図星か( ̄ー ̄)。

617 :仕様書無しさん:04/12/27 08:58:48
確かに自分だけが分かっている、と思えたときは嬉しいもんだしな……。

618 :仕様書無しさん:04/12/27 09:11:54
まあ、ここでCでも書ける、と、言っている人間の本懐は、
本人も言っている通り、「でも」にあるんだろう。
言語に依存しないという実例を示したかっただけだろうから、それ以上の追及は無用だな。

619 :仕様書無しさん:04/12/27 09:56:11
亀レスだが、SendMessageは別にオブジェクト指向じゃないだろ?
そもそもメッセージキューという仕組みがあるわけで、別にオブジェクト指向を取り入れてメッセージを作ったわけじゃない。

620 :仕様書無しさん:04/12/27 13:26:40
そういった以上、>>619
これこそ「オブジェクト指向」だ!
と呼べるものを挙げられるんだろうな。


621 :仕様書無しさん:04/12/27 14:18:13
>>620
なんで私が上げなきゃいけないの?
SendMessageとかメッセージキューの仕組みが別にオブジェクト指向独自じゃないと指摘したまでなのに。
文書読めない人ですか?

622 :仕様書無しさん:04/12/27 19:00:23
キューの仕組みじゃなくて、送られてくるメッセージによって各ウィンドウクラスが
独自の処理をするのがオブジェクト指向っぽいねって話だろ。

623 :仕様書無しさん:04/12/27 21:50:25
>>602
Linuxカーネルの中も。
file_operations構造体とかはvtableそのものだし。

624 :仕様書無しさん:04/12/28 02:18:17
>>623
FILE 構造体。

625 :仕様書無しさん:04/12/28 23:36:51
そろそろCでオブジェクト指向なコードを晒してくれよ。

626 :仕様書無しさん:04/12/29 00:34:00
#include<stdio.h>

void CLASS_hoge (void);

void main (void){
printf("オブジェクト指向");
CLASS_hoge();
}

void CLASS_hoge(void){
printf("だろ?");
}

627 :仕様書無しさん:04/12/29 00:46:28
めっさ関数型やん

628 :仕様書無しさん:04/12/29 00:49:16
>>627
どこらへんが?
Cにしても、際立って関数型らしい性質の見当たらないコードだが?

629 :仕様書無しさん:04/12/29 01:23:11
>>625
マジレスすれば、「C でオブジェクト指向なコード」なんて書けるわけない。
C 言語はそもそも言語仕様としてオブジェクト指向なんて考慮されてないんだから。

ただしソフトウェア全体のデザインを俯瞰すれば、ああ、オブジェクト指向なデザインだね、
というものは山ほどある。

630 :仕様書無しさん:04/12/29 01:40:08
>>628
そもそもCは関数型じゃない

631 :仕様書無しさん:04/12/29 02:34:17
関数型+手続き型ハイブリッド:Scheme とか
手続き型:C、BASIC、Pascal とか
手続き型+オブジェクト指向型ハイブリッド:Java、C++ とか
関数型+オブジェクト指向型ハイブリッド:CLOS とか

632 :仕様書無しさん:04/12/29 07:58:48
勉強になるなぁ。
Javaは純粋なオブジェクト指向じゃないんだね。
.NETは何で入って無いの?

633 :仕様書無しさん:04/12/29 10:44:42
>>632
Javaは(純粋な)オブジェクト指向かつ手続き型の言語だよ。
関数型か手続き型かという問題とオブジェクト指向か
そうでないかという問題は直交している。


634 :仕様書無しさん:04/12/29 11:37:29
関数型も手続き型もオブジェクト指向も別の尺度って事?

635 :仕様書無しさん:04/12/29 12:17:30
+--------+-----------------+---------------+
|       | 非オブジェクト指向 | オブジェクト指向 |
+--------+-----------------+---------------+
| 手続き型 | C, Pascal       | C++, Java     |
+--------+-----------------+---------------+
| 関数型  | Lisp          | CLOS        |
+--------+-----------------+---------------+

636 :仕様書無しさん:04/12/29 13:42:33
ここは専門学校生のスレですね

637 :仕様書無しさん:04/12/29 15:34:34
>>625
名前のあがっているgtk+やlinuxカーネルはもう読んだのかい?
まさかスレに貼ってもらわなきゃ読めないとか言わんよな?

638 :仕様書無しさん:04/12/29 16:50:10
>>637
読んだけど、オブジェクト指向なコードなんて見つからなかったよ。

639 :仕様書無しさん:04/12/29 22:57:13
オブジェクト指向なコードってなによw

640 :仕様書無しさん:04/12/30 00:57:59
>>639
その切り返しでは、例え逃げ口上と言われてもしかたない気がする。

641 :仕様書無しさん:04/12/30 15:17:15
UMLを勉強すればすべ解決する。
ここにいるやつは、言語云々よりも早く勉強しろ!!!

642 :仕様書無しさん:04/12/30 20:19:49
>>641
UMLってそこまで言うような勉強か?
まあ、煽りなんで相手にするのもあれだけど、銀の弾丸はなし。
あれは単なる表記の1つ、それ以上それ以下なし。

643 :仕様書無しさん:04/12/30 21:34:04
>>642
UMLで設計を表記してJavaで実装すればそれでオブジェクト指向だと思い込みたいんだよ。
C言語でもオブジェクト指向のプログラムを書くことが出来るとか言われると
その思い込みを全否定されることになるから、必死になって拒絶する。

644 :仕様書無しさん:04/12/30 23:02:35
UMLって、たんなるJIS記号じゃないの?

645 :仕様書無しさん:04/12/31 07:57:37
UML = Universal Media disc Launcher

646 :仕様書無しさん:04/12/31 12:38:22
UML使いこなしてる人ほどUMLという単語は発しないね。

647 :仕様書無しさん:04/12/31 13:13:13
だって、漢字を少し多く知ってると同じ程度だから。
問題は、その漢字をつかって書く良い文書側なわけで。

648 :仕様書無しさん:04/12/31 13:21:36
正直UMLもどきで十分
必要なのオブジェクトの関連とかだし
UMLにあわせると却って見づらくなったりもするし。

649 :仕様書無しさん:04/12/31 15:36:36
>>638
このライブラリの作りがオブジェクト指向でなければ、
AWT/SWING もオブジェクト指向ではないことになるが。
http://www.gtk.org/tutorial/ch-gettingstarted.html#SEC-HELLOWORLD

650 :仕様書無しさん:05/01/01 18:51:48
>>649
えっ・・・と言ってる意味が良く分からんけど、
リンク先のコードはオブジェクト指向とは違うんじゃないの?
オブジェクトはどこに出て来てるの?

651 :仕様書無しさん:05/01/01 20:58:47
>>650
分析/設計段階で

652 :仕様書無しさん:05/01/01 21:16:02
>>651
よかったね。この話は終りだね。

653 :仕様書無しさん:05/01/01 21:22:17
>>652
プ。

654 :仕様書無しさん:05/01/01 21:23:13
>>650
ああ、君はきっと"class"という言語定義のキーワードでなにかが定義されなければ
それはオブジェクトではないと思い込んでいるんだね。
なるほど、無知だね。

655 :仕様書無しさん:05/01/01 22:00:30
>>654
散々OOPの話してるのに分析・設計とか言われてもフーンとしか言えない。
君の論理ならCのみならずアセンブラでもOOPが出来てしまうわけだが。

656 :仕様書無しさん:05/01/01 22:08:57
>>655
すまん。
665が言うところの「OOP」とは一体なんなのだ?
説明(もしくは定義)してくれ。

657 :仕様書無しさん:05/01/01 22:10:20
あなたのOOPはコーディングだけですか。そうですか。

658 :仕様書無しさん:05/01/01 22:39:50
>>656
OOP=オブジェクト指向プログラミングの認識ってそんなに違うものなんですかね?

僕の認識を簡単に言えば「オブジェクト」をプログラミングすることで、
「オブジェクト」とはデータと処理のまとまり、
もっと言えば、それらは「カプセル化」「継承」「多態性」等の概念によって
実現されるという認識です。教科書レベルの話ですいません。

あなたの認識するOOPを教えて頂けないでしょうか。

659 :仕様書無しさん:05/01/01 22:41:59
>もっと言えば、それらは「カプセル化」「継承」「多態性」等の概念によって
お前いつの時代の人間だよ

660 :仕様書無しさん:05/01/01 22:46:34
プログラミングとコーディングって違うのか?

661 :仕様書無しさん:05/01/01 23:16:49
>>659
今も本質はかわらんだろ

662 :仕様書無しさん:05/01/01 23:40:45
>>659
いつだってそれが間違いであることはないでしょう。

663 :仕様書無しさん:05/01/01 23:47:10
>>661
オブジェクト指向の本質は概念をオブジェクトとメッセージパッシングに移し変えることだろ。
カプセル化なんてオブジェクト指向とか以前の問題だし、
継承や多態性がなくてもオブジェクト指向は成り立つ。

664 :仕様書無しさん:05/01/01 23:51:59
>>663
でも C 言語なんてカプセル化できないし(モジュール単位の static は
隠れるけど、struct のメンバごとに隠すとかできない)。
OOP を想定していない言語で、アクセス制限できるのあるのかな。


665 :仕様書無しさん:05/01/01 23:56:19
>>664
全部隠すんだよ

666 :仕様書無しさん:05/01/02 00:03:27
まともに取り合うだけ無駄だな。

667 :仕様書無しさん:05/01/02 00:06:00
>>666
どっちサイドへのレスかわからん

668 :仕様書無しさん:05/01/02 00:08:00
唐揚げだ〜 から揚げ入りました。
証明がまぶしかった。
僕も大晦日に20時間も勉強してしまいました。
今年こそは合格しないとね。
機械が爆発とかしてさ、25分で終わらなかったっけ。
先日友達とスケートに行きました。


669 :仕様書無しさん:05/01/02 00:17:50
>>664
構造体は全て隠してメンバごとにアクセッサ用意すれば良いんだよ。
C++でもメンバ変数を個々にpublic公開するようなことはしないだろ?

670 :仕様書無しさん:05/01/02 00:18:02
>>663
>オブジェクト指向の本質は概念をオブジェクトとメッセージパッシングに移し変えること
って分かりにくい文章だけど、予測するに分析・設計に関する話だね。あと

>継承や多態性がなくてもオブジェクト指向は成り立つ。
これってカプセル化してればOOPだよ、って意味なら同意だけど、
抽象化はオブジェクト指向じゃない、って意味なら・・・んなわけないか。
どちらにせよ僕の理解では反論にはなってないんだよね。
解釈の仕方を教えて下さい。

671 :仕様書無しさん:05/01/02 00:27:22
>>670
>>オブジェクト指向の本質は概念をオブジェクトとメッセージパッシングに移し変えること
>って分かりにくい文章だけど、予測するに分析・設計に関する話だね。あと

は ぁ ! ?
オブジェクト指向の教科書の最初の方に書いてある話だぞ
僕の理解とかいってるけど、お前ちゃんと勉強したこと無いだけだろ

672 :仕様書無しさん:05/01/02 00:36:56
そんなの知るか!


673 :仕様書無しさん:05/01/02 00:38:09
>>672
自分の浅学を放り出して逆切れですか。ワロタ。

674 :仕様書無しさん:05/01/02 01:09:29
>>660
誰もわかってないらしい

675 :仕様書無しさん:05/01/02 01:18:20
>>674
http://dictionary.goo.ne.jp/search.php?MT=%A5%D7%A5%ED%A5%B0%A5%E9%A5%DF%A5%F3%A5%B0&kind=jn&mode=0&base=1&row=1
コーディング∈プログラミング

676 :仕様書無しさん:05/01/02 04:24:59
>>671
つーか、君。

>>オブジェクト指向の本質は概念をオブジェクトとメッセージパッシングに移し変えること

って文章の本質的な意味はちゃんと理解してるんですか?

677 :仕様書無しさん:05/01/02 04:56:15
>>671
わかりづらいからコテハンかとリップつけてくれ

678 :仕様書無しさん:05/01/02 05:24:07
オブジェ区と思考って難しいけど・・

結局何か物に対するアクションはすべてその物の中に含んでしまおうって感じでよかった??

そのアクションの共通化として継承元ってのがあるって認識でよかったかい?


679 :仕様書無しさん:05/01/02 05:27:08
うー、、今日エッチしてきました・・・ぼーっとする・・・。
30日になんかエッチしてもいいようなダメなようなそんな雰囲気で二人もんもんとしながら
エッチしなかったせいか、
今日は二人で漫画喫茶のペアシートで漫画よんでたらむらむらと・・・

彼が上にのっかってきて「たまんない」って言うから私もなんだかそんな気持ちになってきて・・。
隣の人に聞こえないようにキスしたり胸さわっってきたり・・・。
彼の股間はパンパンで、なんかもう、入れてぐりぐりしたくなっちゃって・・。

それから二人でラブホへ行って、すぐエッチしました。
半脱ぎの状態でいちゃいちゃして、私の下着をやらしく半分のこしてエッチ。
「すぐ、いっちゃいそうだ」って言う顔がすごいセクシーでした。

彼のいく前の真剣な顔みてたらなんとも言えない気分になって二人同時にはてました。
うーーーーー、、なんかもう、ほんとうずいてしまう。
ダメだ・・・あんなにしたのにまた・・・。私ってえろすぎ!!


680 :仕様書無しさん:05/01/02 06:53:28
>>658
>656=>608
教科書レベルのことで悪いが658みたいな人間に対して
皮肉を込めて書かせてもらってる。
610に言わせると入門書に書いてあるようなことだそうなので
入門書を読み直してみてくれ。

681 :仕様書無しさん:05/01/02 10:48:40
今時オブジェクト指向かよ...

682 :仕様書無しさん:05/01/02 15:22:11
匿名掲示板は>>676みたいな無能でもえらそうな発言できるから良いね

683 :仕様書無しさん:05/01/02 16:18:05
メッセージパッシングの具体的な意味がわからない。
関数コールとどう違いますか?

684 :仕様書無しさん:05/01/02 16:38:43
>>683
捉え方の違い。その違いが重要なんだけども。

685 :仕様書無しさん:05/01/02 16:38:47
>>683
C++ や Java しか知らないと、そう思っても仕方ないだろな・・・。

686 :683:05/01/02 17:01:42
メッセージというとキューを連想。
プログラム全体の進行とは非同期という意味ですか?

687 :仕様書無しさん:05/01/02 17:10:42
>>686
どうも君は考えが実装の方に偏ってる。
もっと抽象的なお話。
OOで言うメッセージとは、あるオブジェクトから別のオブジェクトへの要求のこと。
あるオブジェクトが別のオブジェクトからメッセージを受け取ると、
そのオブジェクトはメッセージ内容に応じた操作を行う。
この相互作用だけでシステム全体が動作すると考えるのがオブジェクト指向。
C++やJava等ではこのメッセージを送る行為をメンバ関数呼び出しと言う形で表現してるだけ。

688 :仕様書無しさん:05/01/02 17:14:28
C++やJavaだと、オブジェクトの操作の定義が
オブジェクトのインターフェースの定義も伴っちゃってる辺りが
さらに話をややこしくしてる気がする。
結局一番話をややこしくしてるには世に溢れる入門書だけど。

689 :仕様書無しさん:05/01/02 18:21:50
呼び出し側が実装を知らなければいけないかそうでないかの例。
こんなのCやアセンブラでも前からやってたよな。
OOなんてそんなもん。

Cの構造体は隠蔽機能がないけど、FILE *やハンドルなんかもうまく隠蔽した例。

struct Foo {
char name[256];
int age;
};
void tetsuduki_shikou() {
Foo foo;
scanf(" %256s", foo.name);
scanf(" %d", foo.age);
printf("name %s\n", name);
printf("age %d\n", age);
}
void Foo_input(Foo *pfoo) {
scanf(" %256s", pfoo->name);
scanf(" %d", pfoo->age);
}
void Foo_output(const Foo *const pfoo) {
printf("%256s\n", pfoo->name);
printf("%d\n", pfoo->age);
}
void object_shikou() {
Foo foo;
Foo_input(&foo);
Foo_output(&foo);
}


690 :仕様書無しさん:05/01/02 18:30:35
かといって、FILE *がOOだというのは無理があるけどな。
標準入出力系の関数に渡すパラメータは、低レベルすぎて抽象化されてないからね。

低レベルってのはあれだ。
バイトストリームであることを意識しなければならないとか(fwrite, fread, fseek)
そういうこと。

GTKとかDirectXとかはいい感じに抽象化された設計とI/Fを持ってる。
XlibとかWin32は微妙。

根底のデザインにOOが取り入れられてるライブラリなんかを利用する場合、
呼び出し側がライブラリの実装に手を付けることはほとんど無くなる。

細かい実装に気を配りつつ、メモリレイアウトや手順(アルゴリズム)に気を配らなきゃいかんのが構造化プログラミング。
オブジェクトの特性とI/Fに注意を払いつつ、それらと親和性の高いプログラミングをするのがOOP。


691 :仕様書無しさん:05/01/02 19:42:06
事の発端は>>578
>C言語でもオブジェクト指向のプログラムを書くことは出来るが
だよね?

つまりC言語を使ったOOPが可能かどうかが論点であって、
オブジェクト指向はもっと概念的だ、実装方法は二の次だ、
みたいな意見はそもそもズレてるかと。
意見が食い違ってるんじゃなくて、論点が食い違ってるっぽい。
具体的な事書かない「勉強しろ厨」はもちろん別格だけど。

で、結局C言語でOOPは無理だと思ってます。
OOPって僕の認識では>>658みたいな話を言語レベルで
実現してる事が前提だと思ってますがどうでしょうか?

692 :仕様書無しさん:05/01/02 19:48:40
>>691
>で、結局C言語でOOPは無理だと思ってます。
「無理」とは?

693 :仕様書無しさん:05/01/02 19:51:19
>>691
OOPはオブジェクト指向に乗っ取ったプログラミング技法のことです。
OOPLはオブジェクト指向をサポートする機能の付いたプログラミング言語のことです。
OOPLじゃなくてもOOPはできるけど、OOPをサポートする機能が備わっている方が
コーディングが楽なのでOOPLが作られ続けるのです。

694 :693:05/01/02 19:51:42
>>692

695 :694:05/01/02 19:52:24
>>691であってたorz

696 :仕様書無しさん:05/01/02 19:59:26
てか>>691の自分の無学っぷりを棚に上げたレスにいい加減ムカついてきた。

697 :仕様書無しさん:05/01/02 20:18:53
>>693
>OOPはオブジェクト指向に乗っ取ったプログラミング技法のことです。

この一行に関する説明がどうも納得出来てないです。
「実装方法はどうあれ、OOによる設計を実現すればアセンブラ使ってもOOPですか?」
という質問の答えはYesなんでしょうか?

例えば”オブジェクト”というプログラム群を一つのポインタが示す先として
定義出来ないとOOPにならないのではないか、
という考え方はどのように間違っているのでしょうか?

698 :仕様書無しさん:05/01/02 20:33:26
>>697
>「実装方法はどうあれ、OOによる設計を実現すればアセンブラ使ってもOOPですか?」
YES

>例えば”オブジェクト”というプログラム群を一つのポインタが示す先として
>定義出来ないとOOPにならないのではないか、
>という考え方はどのように間違っているのでしょうか?
オブジェクトの実装をどう表現するかなんて言語や処理系依存

699 :仕様書無しさん:05/01/02 20:34:12
例えば言語的に、オブジェクト内のプライベートな要素への外部からのアクセスが禁止出来ない場合、オブジェクト指向であるプログラムの作成は不可能なわけですが、これはCでは可能でしょうか、不可能でしょうか。

700 :仕様書無しさん:05/01/02 20:43:21
>>699
>オブジェクト指向であるプログラムの作成は不可能なわけですが、
だから、この時点でお前は間違ってるっちゅーの。
オブジェクト指向の基本概念は>>687じゃこの糞ボケ。
カプセル化は重要な概念だが抽象データ型の時点で出てきた話じゃ。

ついでにCでそれは可能。

701 :仕様書無しさん:05/01/02 21:09:12
>>699はPHP4以前のPHPやPythonではオブジェクト指向プログラミングできないとでも言うおつもりだろうか
ついでにSmalltalk等にもアクセス制御は無い(フィールドはprotectedな感じでメソッドは全てpublic)
Objective-Cもメソッドは全てpublic

702 :仕様書無しさん:05/01/02 21:12:55
べつにさ、言語仕様で制限かけられてなくても、実装で制限すればいいだけ。
なんでも決められないとできないんかい。

703 :仕様書無しさん:05/01/02 21:29:02
>>698
”実装方法はどうあれ”にYES付けたって事は、
OOPは実装方法に関するカテゴリでは無いって事?

704 :仕様書無しさん:05/01/02 21:38:21
>>703
うん。
オブジェクト指向は広義には分析/設計を含めたオブジェクト指向ソフトウエア開発全体を指す。
狭義にはオブジェクト指向分析/設計の結果をコードに落とす作業のことを言うのであって、
オブジェクト指向言語でコーディングすることを指すのではない。

705 :704:05/01/02 21:38:53
>オブジェクト指向は
オブジェクト指向プログラミングは

706 :仕様書無しさん:05/01/02 21:49:03
>>691
>OOPって僕の認識では>>658みたいな話を言語レベルで
>実現してる事が前提だと思ってますがどうでしょうか?

関数「型」プログラミングや、論理「型」プログラミングは
言語レベルのサポートが必要。
仮にそれを無理矢理やろうとしても、それは結局
新たな言語処理系を作るのと(本質的に)同じ作業になってしまう。

それに対して、オブジェクト「指向」プログラミングには
言語レベルのサポートは無くても良い。
だからこそ「型」では無くて「指向」。


707 :仕様書無しさん:05/01/03 00:53:51
それより百人一首で骨折しました。


708 :仕様書無しさん:05/01/03 00:54:39
m9(^Д^)プギャー

709 :仕様書無しさん:05/01/03 08:29:25
「オブジェクト指向をプログラミングする」と
「オブジェクト指向プログラミング」の食い違いなような・・・

710 :仕様書無しさん:05/01/04 03:31:40
>>707
とりあえずもう来ないかもしれないけど聞きたい。どうしても聞きたい。
どうやってどこを???

>>709
「オブジェクト指向プログラミング」
っていった場合、
「オブジェクト指向な考え方に乗っ取ったプログラミング」
だと思っているんだけど、あなたの認識は違うと言うこと?

少なくとも「オブジェクト指向に適した言語を使うこと」が
オブジェクト指向プログラミングでは無いと思う。

711 :仕様書無しさん:05/01/04 10:34:50
結局は言葉の定義だけの問題だね。
オブジェクト指向プログラミング=Object Oriented Programming
の定義に関するソース(コードじゃない)を探してみます。

712 :仕様書無しさん:05/01/04 23:39:49
>>710
それより聞いてくれ。
昨日いたずらに彼女のアナルに人差し指を
つっこんでみたら「きゃあ!」って声出して彼女が体ひねるんよ。
そしたらそのときアナルにつっこんだ人差し指が変な方向向いてるんだよ。
病院にいってみたら脱臼だった。
彼女にはぶんなぐられるし、指は痛いし新年早々我ながらアホだと思った。

713 :仕様書無しさん:05/01/05 22:38:40
>>712
アナルセックスやって見たいとは思う。
でも彼女に言い出す勇気が無い。

714 :711:05/01/05 23:18:05
C言語でOOP可能か。色々調べてみました。

そもそもOOはPARCのAlan KayらがDynabook(個人が使う本のようなコンピュータ)
実現の為に開発したといわれるSmalltalkの言語概念が起源とされています。
つまり言語ありきで、歴史的にはOOP→OOD→OOAの順に生まれています。

じゃその言語概念は何かと言うと、オブジェクト単位で実装し、
オブジェクトへのメッセージパッシングで要求を実現するというものです。
カプセル化、継承、多態性(多相性)も基本概念として組み込まれています。
OOPも当然これらの実現が必須になってきます。だからOOPLは前提で、
実際OOPはOOPLでPGする事だよっていくつかのサイトに書いてあります。
(1/2)

715 :711:05/01/05 23:18:49
ではCでOOP出来ないかと言うと、ここに抜け道が。
>>649のGTK+しかり、OOPLに相等するものをCで作れれば良いわけで。つまり
 1.機械語でSmalltalkが記述出来る。
 2.SmalltalkでOOが記述出来る。
 3.ゆえに機械語でOOが記述出来る。
の三段論法を認めるならば、GTK+を記述出来るCはOOが記述出来る事になります。

ではOOPLに相等するAPIの使用が前提となってもOOP出来ると言えるのか。
「機械語でOO書けるよ。Smalltalk使えばね。」という発言を認めるのか。
感覚的にはNOですが、こんがらがって来たのでここまでで。

ちなみにソース探すって書いといてソース無いのは、
公式の決定的なのが見つけられなかったからです。知ってたら教えて下さい。
(2/2)

716 :仕様書無しさん:05/01/05 23:58:07
>>711
good job!
公式サイト見つけられなかったのは惜しいけど偉いぞ。
自分なんかそこまでする気ないもんな(<-おい)。

717 :仕様書無しさん:05/01/06 01:23:58
Xt Intrinsics の実装でも調べた方が早いんじゃ…?

718 :仕様書無しさん:05/01/07 22:44:45
>>717
何が早いの?

719 :仕様書無しさん:05/01/07 22:49:27
>>713

 や ら な い か ?

720 :仕様書無しさん:05/01/08 00:22:08
>>718
アレがはやいの。

721 :仕様書無しさん:05/01/08 08:17:10
>>718
あ、>>714 に向けて言ったんだけど、「色々調べ」た挙句
>実際OOPはOOPLでPGする事だよっていくつかのサイトに書いてあります。
こんな間抜けな記述を信用するくらいなら
実際にやってるコード読んだ方が理解が早いよ、って話。

722 :仕様書無しさん:05/01/08 13:37:49
う〜ん...理に適ってないな。
OOPLで記述したのがOOPで無いとすると、思考や製造過程が問われるのか?そりゃ違うだろ。

結局OOPと言える形式があって、良くも悪くもその形式さえ満たせばOOPと言えるのでは無いか?

つまりオブジェクト操作をしているプログラムはOOPと言える訳だ。
ではオブジェクトとは何かと言えばオブジェクトとしてプログラムにて定義したモノだから、
如何見ても構造化プログラムの流儀で書かれたソースでもオブジェクトの定義構文があれば、
OOPといえる。

まり、程度の問題でOOPか否かを言っているならば、それは論理的では無い。
と思うが如何です?



723 :仕様書無しさん:05/01/08 13:42:46
んーs−だねーよくわかったねー

724 :仕様書無しさん:05/01/08 13:58:18
>>722
>OOPはOOPLでPGする事だ
いや、この説明ってOOPがわからない奴にとってなにかプラスになるの?
ってことがいいたかったんじゃね?

725 :仕様書無しさん:05/01/08 14:11:25
>>722
構文的にはそう見えなくても、意味論的にオブジェクトを操作しているとなれば、
それは OOP と考えて良い?

726 :仕様書無しさん:05/01/08 14:55:59
>>722
>思考や製造過程
が、オブジェクト指向です。コーディングなんてどうでもよいのです。
ビジネスモデリングだってオブジェクト指向でやろうという動きがあるでしょう?
プログラムとはまったく関係ないですがオブジェクト指向です。
オブジェクトとはプログラムにて定義したものではありません。
OOPLはオブジェクト指向をやるための単なる道具です。

727 :仕様書無しさん:05/01/08 16:05:23
日経BPの「オブジェクト指向でなぜつくるのか」によると、
オブジェクト指向とは「共通メインルーチン」を実現するための仕組みであり、
(構造化プログラミングでは、共通サブルーチンしか出来なかった)
そのポイントは、メモリの使い方にある。
オブジェクト指向は、手続き型プログラムの発想を捨てて
現実のとらえ方を変えねばならないという見解がよくあるが、それは間違い。
逆にハードウェアの知識がないとオブジェクト指向は理解できない。
オブジェクトは現実を計算機の中に持ちこむものではない。
著者は最初オブジェクト指向に思想的な幻想を持っていたが、
それで手痛い失敗を繰り返し、上のような考えに変わったそうだ。

728 :仕様書無しさん:05/01/08 16:23:13
>>727
上っ面だけの肉茎の記事、ってだけでも胡散臭いのに
要約したら益々ワケワカラン…
>逆にハードウェアの知識がないとオブジェクト指向は理解できない。
誰が書いたか知らないが、頭おかしいんじゃないか?

729 :仕様書無しさん:05/01/08 16:50:49
>>727
すごい釣りだな巨匠レベルだw
まさか、エサやルアーどころか針もつけずに糸を垂らすとはw

730 :仕様書無しさん:05/01/08 18:03:55
>>728-729
それが、日経だ。
書く奴も、オブジェクト指向を理解してるわけではない。
儲かりそうな匂いに釣られているだけだ。

731 :仕様書無しさん:05/01/08 20:58:10
>>727の本を読まずに否定してないか?
かなりの良本だぞ。

732 :722:05/01/08 22:35:01
>>724
なるほど、その意見は解り易いですね。納得です。


733 :722:05/01/08 22:44:29
>>726
それは「オブジェクト指向」の捉え方の一つと思います。
私はその様な主張をされる方を認識学派と申しています。

認識学派にて疑問に思うのは、それを無理やり工学と結びつけて語る事です。
例えば、工学の話をしている最中に「オブジェクト指向」というキーワードが出ただけで、認識学派の話を持ち出す人が多過ぎますよね。

認識学派の云う事は一理あります。しかし認識学派の云う定義を現在、そのまま実装する手段はありません。

今、出来ない事を大風呂敷で広げて工学議論をしている人達に話をするのは場違いだと常々感じます。
ただ、言語を作成している人達への発言であれば良いですが、言語を利用する人達にするのは場違いです。

またオブジェクト指向はプログラミング&言語が先に認識され、その後にプログラミング&言語をより効果的に設計する手法としてOOAやOODが考えられ、また、その後OOAやOODを考える思想や見方として認識学派が生まれたと認識しています。

つまり、認識学派オブジェクト指向は全く関係の無い所から出たのでは無く、言わば下流工程からそれぞれの要望が転換され生まれたモノなので、工学のオブジェクト指向も肯定しなければいけないのではないでしょうか?


734 :仕様書無しさん:05/01/09 01:33:23
認識学 → OOD、OOA 
工学  → OOP

って事?

735 :仕様書無しさん:05/01/09 01:56:15
なんでオブジェクト指向なんて簡単な概念なのに
変な記号ばっかり付けたがる人多いんだろうね。

実際のプログラミングに役に立てることができるかどうかってのは
はっきりいって素質以外何物でもないだろ。
匂いを感じ取れるかどうかの一言だね。
そこには生きた技術や経験、知識しか入り込む余地はないんだよ。

言語厨房や定義厨房じゃ一生かかっても使えるようにはならない。
だからといって、経験しか頼るものが無い奴にも理解は不可能。

736 :仕様書無しさん:05/01/09 02:10:28
>>733
そもそも明確にOOP,OOA,OODを分類できる人はいるのか?またそれに意味あるのか?
プログラムを書いているとオブジェクト指向のありがたみはよくわかる。けれど、自分は設計もするしコードも書くがそれらは混ざり合ってます。
にわとり論は意味がないと思いますが。Simulaを最初に作った人がOOA的な考えをまったくしなかったとでも?

737 :仕様書無しさん:05/01/09 02:18:30
>>736
OOP OOでPすること
OOD OOでDすること
OOA OOでAすること

でいんじゃね?
分類出来ないのはOOPDAじゃなくて作業の質だろ?
OOPだけ、OODだけ、OOAだけ考えて作業する事があまり無いだけで。
分類する事は十二分に意味があるよ。

738 :仕様書無しさん:05/01/09 02:50:50
>>737
>分類する事は十二分に意味があるよ。
どんな?

739 :仕様書無しさん:05/01/09 03:03:28
>>737
の考えるおのおのの分類上げられる?

740 :仕様書無しさん:05/01/09 10:13:30
>>739
>>737を穴の空くほど読めよ

741 :仕様書無しさん:05/01/09 11:58:06
>>740
あほか。作業をその3つに分類しろつってんだよ。そんぐらいの行間読めないのかでこすけ。

742 :733:05/01/09 14:20:13
>>736
>そもそも明確にOOP,OOA,OODを分類できる人はいるのか?またそれに意味あるのか?

その分類に意味は無いが、分析,設計,実装に別ける事にはシステム開発に置いて重要な意味がある。
それを分解して認識した時、認識学派が分析,設計の性質や難しさをオブジェクト指向の話として語っている問題に気がつく。


>プログラムを書いているとオブジェクト指向のありがたみはよくわかる。

私も思う。


743 :733:05/01/09 14:28:27
>>736
>自分は設計もするしコードも書くがそれらは混ざり合ってます。

言語の発達により昔の工程概念では、確かに同一行為になりますね。SQLとCOBOLのデータ処理なんか最もたる所。

ただ(1)要求や業務定義をシステム化する際に発生する問題解決を目的とした設計と(2)システムへ要求する際に最適化を行う設計に分かれる。
その意識改革はオブジェクト指向とは関係なしに必要と思う。


>にわとり論は意味がないと思いますが。Simulaを最初に作った人がOOA的な考えをまったくしなかったとでも?

それを言うと昔から皆オブジェクト指向はしていた。そして単にその行為に対して「オブジェクト指向」と名づけた。

実際、認識の定義と関係の重要性は、オブジェクト指向という言葉が出る前から分析や設計では重要視されている。

つまり、認識学派は高学な話をしている訳ではない。簡単言えば、
「オブジェクト指向とは認識している事が何かを定義し、各々の認識した関係を定義し、全体や個別を考慮する事となる。」
それ以上でもそれ以下でも無い。

でもこう、言っちゃうとありがたみが無いから、難しい話を色々と出しす最悪な状況に落ちいった。
しかし本当はありがたみの無い定義でいいんだ、難しいのはその意識を継続する事なんだから。

と思うよ。


744 :仕様書無しさん:05/01/09 20:53:31
難しいことを難しい言葉で表現することは簡単です。
難しいことを簡単な言葉で表現できなければ、理解してないと考えられます。

745 :仕様書無しさん:05/01/09 21:37:04
デザパタみたいなもんか。
まともなプログラマなら誰でもやってたちょっとした工夫なんだけど、
それぞれに名前を付けたのが GoF の面々の偉いところ、と・・・。

746 :仕様書無しさん:05/01/09 22:04:58
>>745
そうかぁ?
シングルトンとか
どう考えても厨房クラスなんて作っちゃうあたり
あいつ等もよくわかってないんじゃね?

747 :仕様書無しさん:05/01/09 23:37:01
>>746
シングルトンは厨房クラス???
loggerやらobject poolやらは、誰が設計しても大概はシングルトンになるだろーが。
もちろん何でもかんでもシングルトンにするのは厨房だけど、
シングルトンを全部厨房クラスと思っている君も厨房だ。

748 :仕様書無しさん:05/01/09 23:45:48
>>744
勉強する意思も能力も無い馬鹿の常套句だな。
こういう奴が「相対性理論は間違っている、なぜなら誰も
俺に理解できるように説明できないからだ」って言い出すんだよな。

749 :仕様書無しさん:05/01/10 02:27:59
>>748
一理ある。ただ否定の仕方はちょっと意見が食い違う。

掲示板にて問題なのは前提知識を揃える事が出来ない事。
そして議論されている内容に対し自分の前提知識が明らかに無いのに反論や意見を云う奴が多い事。

前提知識が無いなら質問形式で聞け!と常々思うね。


750 :仕様書無しさん:05/01/10 02:28:30
>勉強する意思も能力も無い馬鹿の常套句だな。
>こういう奴が「相対性理論は間違っている、なぜなら誰も
>俺に理解できるように説明できないからだ」って言い出すんだよな

釣られ返してあげるけど、その喩えおかしくない?
お前だけだろ、そんな台詞思いつくの。

751 :仕様書無しさん:05/01/10 02:34:51
>>747
>loggerやらobject poolやらは、誰が設計しても大概はシングルトンになるだろーが。
つーか、こんなもん全部いらねーじゃん。
別のアプローチ探せよ。

752 :仕様書無しさん:05/01/10 02:56:12
>>751
別に、そんなことどうでもいいじゃん。

753 :仕様書無しさん:05/01/10 09:32:55
>>751
いらないようなものしか作ったことないんだね。
それにそこは話の本筋じゃないから突っ込んでもしょうがないでしょ

754 :仕様書無しさん:05/01/10 11:21:03
>>749
ほぼ同意。
たまに説明出来る程理解して無い奴が逃げ口上で「勉強しろ」とか発するのは不愉快だけど。
あとは有識者が質問に素直に答る土壌が必要かもね。

755 :仕様書無しさん:05/01/10 11:41:31
>>753
ちがうって、このシングルトンとかいうクラスは
グローバル変数と変わらないんだよ。
いつどこでそのクラス(インスタンス)の状態が変わるかまったく管理できない。
こんなもん作った時点で即厨房決定だろ。

756 :仕様書無しさん:05/01/10 11:59:18
面白くなってきたー

757 :755:05/01/10 12:02:48
あー、つかレスいらね。
何度いっても理解できない人の思考回路って

「デザインパターンに載っているんだから間違いない」

って思考回路なんだよね。
そもそもデザインパターンって俺にはオブジェクト指向を
理解して無い奴が書いたように見える。
「クラスの変な使い方集」にしか見えない。

758 :仕様書無しさん:05/01/10 12:07:55
すげー。GofよりもOO理解してる>>755の光臨に立ち会えるなんて感動だ。

759 :仕様書無しさん:05/01/10 12:11:05
>>757
インスタンスを1つに限定したい場合の
「クラスの正しい使い方」を教えて頂けませんか?
手元のシングルトン全部置き換えたいので。

760 :仕様書無しさん:05/01/10 12:17:30
>>759
インスタンスを1つしかつくらなけりゃいいじゃん。
インスタンスが複数存在してしまっているかどうかは宣言でわかるはず。
あとは引数で渡す。
こうすることで(引数に渡されたことで)そのクラスの変化がわかる。
少なくとも自分が知らないところで勝手に状態が変化していたという
最大の恐怖を回避できる。
また、クラス同士の関連も明確になるので多少記述が長くなってしまっても
引数で渡す形が一番スマートだと考えるけどね。
これ以外の方法をとるとグローバル変数になるはず。

761 :仕様書無しさん:05/01/10 12:47:23
>>755
おまいさんなら、GoFなんかより良い本が書けそうだ。

762 :仕様書無しさん:05/01/10 13:08:01
>>760
>インスタンスが複数存在してしまっているかどうかは宣言でわかるはず。
どこかの関数内部で生成されても?
複数のインスタンスを static に作っていても?
自分以外の誰かが犯すかもしれない、そうしたミスを
検出・回避できるのが Singleton ですよ。

なんて事は GoF にしっかり書いてあるので、どうしても
「GoF 読め」
ってことになるんですが、>>757 の様に
自分の無学を棚に上げちゃう人がいるんで困ったものです。

763 :仕様書無しさん:05/01/10 13:50:40
なんか嫌なことでもあったんだろ。
愚痴スレならいくらでもあるのに。。。
部下に、無能を気づかされたら、きっとあんなふうになるんだよ。

764 :仕様書無しさん:05/01/10 14:21:05
>>762
だったら生成2回目でエラーを返して終了するほうがいいじゃん。
なんで動いちゃうんだよ。
明らかにシングルトンはグローバル変数目的で作られてるんだよ。

765 :仕様書無しさん:05/01/10 14:21:24
>>760
>インスタンスを1つしかつくらなけりゃいいじゃん。

だからそれを制限することが目的のパターンなんですけど・・・
引数で渡さなくてもどこで触ってるかわかるとは思うんですが。

766 :仕様書無しさん:05/01/10 14:27:58
>>765
>引数で渡さなくてもどこで触ってるかわかるとは思うんですが。
わからないですよ。
よく考えてみてください。

767 :仕様書無しさん:05/01/10 14:32:33
引数で渡すとなんでわかるんですか?

768 :仕様書無しさん:05/01/10 14:34:56
だいたいさ、インスタンスを1つしか作らないようにする処置なら
2つ目でエラーを返せよ。
実行時にこんなこと必要になる事態なんて絶対にないんだから。
よしんば必要とかいいだされたらぶん殴るけどね。
アプリケーションでたった1つのインスタンスの
生成場所が不特定なんてのは設計が悪過ぎるだろ。

769 : ◆SQ2Wyjdi7M :05/01/10 14:37:33
わかりにくいからトリップつけてくれ

770 :仕様書無しさん:05/01/10 14:40:22
>>767
プログラム書いたことないのか?w
引数で渡すようにすれば、そのインスタンスが生成された場所からの
変化する場所が特定しやすいだろ?
インスタンスがメンバ変数ならそのクラスの中の関数か
呼ばれてる関数の引数だけに注目すればいい。
シングルトンを使ってしまうと、クラスが定義されてるヘッダーファイルが
インクルードされている箇所すべてを調べなくてはならない。

771 :仕様書無しさん:05/01/10 14:42:16
>>769
つけかたしらん。
それに名無しで十分。
ちゃんとアンカーつければ会話になるはず。

772 : ◆hEpdoZ.tHU :05/01/10 14:44:51
トリップ変更
名前欄の跡に#の後に好きな文字入れればなる例: #test

新しくそのクラスを使いたいクラスが出てきたらどうするんですか?

773 :仕様書無しさん:05/01/10 14:47:39
>>772
普通に引数でわたしゃいいじゃん。

774 :仕様書無しさん:05/01/10 14:49:49
>>768
2つ目でエラーを返すのはどういうコーディングがいいですか?

775 :仕様書無しさん:05/01/10 14:50:10
遣いたい新しいクラスが出てくるたびに引数渡す側を変更しないといけないんですか?

776 :仕様書無しさん:05/01/10 14:51:17
名前で検索する人とかもいるからトリップつけてくれ。そのほうがほかの人が見やすい

777 :仕様書無しさん:05/01/10 14:52:07
つーか適当なレス付けて暇潰してる馬鹿は放置でいいんじゃね?

778 :仕様書無しさん:05/01/10 14:53:00
まぁどこまで醜態さらすのか見てみたかったんだが

779 :仕様書無しさん:05/01/10 14:55:25
>>775
そりゃその方がいいだろう。
処理も変わってるんだから。

780 :仕様書無しさん:05/01/10 14:56:57
ログクラスみたいな多数のクラスで使うと起動するのか?
多人数で開発しているとき全部初期化コード書いた人にお伺い立てなきゃいけないのか?
ほかの人も自由にインスタンスかできるんですがそれをどうやって防ぐのか?

781 :仕様書無しさん:05/01/10 14:57:28
いい加減トリップつけろよ。ほんとに人のはなしきかねーな。

782 :777:05/01/10 14:57:52
スマソ、お前等の楽しみに水差しちゃった。

783 :仕様書無しさん:05/01/10 15:00:27
>>777
普段知識不足で参加出来ない人が「シングルトン」っていう聞いた事ある単語に
反応して久しぶりに良い気分で知識ひけらかしてるんだからほっいてあげて。

784 :仕様書無しさん:05/01/10 15:00:30
>>764
なんで生成しちゃうんだよ。

785 :仕様書無しさん:05/01/10 15:03:07
一番の責任は>>746に反応した奴だな。

786 :仕様書無しさん:05/01/10 15:03:12
>>768
2 回目でエラー返しちゃったら Singleton パターンの意味がないじゃん。
何回でも getInstance() できるからええねん。


787 :仕様書無しさん:05/01/10 15:03:51
>>780
ログクラスは引数渡ししたほうがいいよ。
どの関数を通ってそこにいたったかも記録しておかないと
デバッカがあるときはいいけどリリースビルドしたときのログとして役に立たないから。

他のはクラスのドキュメント不足っつーか。
メンバーとのコミュニケーション不足みたいなもんでしょ。

どうしても自由にインスタンス化できるのがまずいなら2つ目でエラーでいいでしょ。
なんで取得までできちゃうの?必要なら引数用意して渡さなきゃ駄目。

788 :仕様書無しさん:05/01/10 15:04:34
>>786
俺はその設計がまずいっていってるの。

789 :仕様書無しさん:05/01/10 15:05:00
スタックトレース・・・

790 :仕様書無しさん:05/01/10 15:08:00
>>788
馬鹿だなあ。何回getInstance()しても、いつも必ず同一のインスタンスに
アクセスできるからいいんだよ。
それが目的なんだし。


791 :仕様書無しさん:05/01/10 15:08:42
>>787
ログクラスはポイントカットにしたほうがいい。


792 :仕様書無しさん:05/01/10 15:10:26
>>788
>>786みたく使うのが目的なんだから、そう設計するのが正解なのだ。


793 :仕様書無しさん:05/01/10 15:11:39
>>790
それじゃグローバル変数用意して同じことやってみなよ。
使い勝手は同じだと思うよ。
(インスタンスも1つだしね)

794 :仕様書無しさん:05/01/10 15:12:10
(・∀・)イイ!!からトリップつけろよでこすけ。こいつと同じグループで開発するやつがかわいそうでしかたねぇ。
PMのいうこととかきかねーんだろうなぁ。ぼくのせんすでGUIを修正しましたとかしてそうだ。
なんつーか飽きた。あとはだれかいじってくれ。

795 :仕様書無しさん:05/01/10 15:12:56
>>791
そう思う根拠を挙げろよハゲ!

796 :仕様書無しさん:05/01/10 15:15:12
シングルトンはグローバル変数な罠

797 :仕様書無しさん:05/01/10 15:15:39
>>794
人に強制する前にてめぇからつけろよ!

798 :仕様書無しさん:05/01/10 15:15:46
>>793
Abstract Factory パターンの ConcteteFactory クラスがいっぱいなとき、
すごく無駄じゃん。


799 :仕様書無しさん:05/01/10 15:16:40
>>798
その「無駄じゃん」の基準ってあくまでコーディングでの話でしょ?

800 : ◆TJ9qoWuqvA :05/01/10 15:17:02
ほらよ。お前もつけろ

801 :仕様書無しさん:05/01/10 15:17:38
>>795
1. ログクラスと、ログクラスを必要とするクラスの結合度が低くなる。
2. ログクラスを必要とするクラスがログクラスを知らなくていい。


802 :仕様書無しさん:05/01/10 15:18:04
>>799
メモリも。


803 :仕様書無しさん:05/01/10 15:18:11
NGワード「TJ9qoWuqvA」
よいしょっと。

804 :仕様書無しさん:05/01/10 15:20:01
>>796
グローバル変数はどこからでもアクセスできちゃうが、
シングルトンクラスは限られたところからしかアクセスできない。


805 :仕様書無しさん:05/01/10 15:21:46
>>801
だったらログクラスだって1つである必要ないじゃん。
必要なクラスでメンバ変数としてもたせればいいじゃん。

806 :仕様書無しさん:05/01/10 15:22:51
>>805
> 必要なクラスでメンバ変数としてもたせればいいじゃん。

そうしたら、

801>> 2. ログクラスを必要とするクラスがログクラスを知らなくていい。

が満たせない。


807 :仕様書無しさん:05/01/10 15:23:03
>>804
シングルトンはどこからでもアクセス出来るだろw

808 :仕様書無しさん:05/01/10 15:24:02
満たす必要が無い。

809 :仕様書無しさん:05/01/10 15:24:14
>>807
そのように作ればそうだが、そのようにしなければそうではない。


810 :仕様書無しさん:05/01/10 15:24:39
>>806
いや、それ、オブジェクト指向的にどうしてそういうプログラムが許されちゃうわけ?w

811 :仕様書無しさん:05/01/10 15:24:44
>>808
馬鹿だなあ。そうしたら、クラスはログクラスと一枚岩になってしまう。


812 :仕様書無しさん:05/01/10 15:25:32
>>810
ログクラスをログクラスを必要とするクラスのメソッドの
ポイントカットにするからだ。


813 :仕様書無しさん:05/01/10 15:26:10
protected class ASingleton {

とかな。


814 :仕様書無しさん:05/01/10 15:26:26
>>809
そのように作らない方が珍しいんですけど・・・

815 :仕様書無しさん:05/01/10 15:27:05
>>814
君にはそうなのかもしれないな。


816 :仕様書無しさん:05/01/10 15:29:16
グローバル変数

log.WriteLog("aaaa"); ==> NullPointerException

シングルトンパターン

LogSingleton.getInstance().WriteLog("aaa"); // 必ず成功


817 :仕様書無しさん:05/01/10 15:29:45
>>815
publicでない君のシングルトンクラスに興味がある

818 :仕様書無しさん:05/01/10 15:30:35
なんにしろ、不必要に公開してはならない。


819 : ◆TJ9qoWuqvA :05/01/10 15:31:12
でトリップまだなのかよ。
そんなに自分のいうことに責任も手ねーのか。
まぁもうはなしあうことないけどな。見限った。

820 :仕様書無しさん:05/01/10 15:31:43
>>816
シングルトンがnullを返さないなんて完全に実装依存だろ。
上もしかり。

821 :仕様書無しさん:05/01/10 15:33:02
>>820
グローバル変数は、ユーザはいつ初期化されているのかわからない。
Singletonは気にしなくていい。

822 :仕様書無しさん:05/01/10 15:34:20
>>820
そうだけど、nullを返すシングルトンなんて、シングルトン・パターンの
目的ではない。必ず意味のある唯一のインスタンスを返すときに使う。


823 :仕様書無しさん:05/01/10 15:35:48
まあまあ。
シングルトン使いたいやつは使えばいいし、使いたくなきゃ
つかわなけれゃいい。
どちらでやったとしたって、プログラムが組めないと言うことは
起こりえない。


824 :仕様書無しさん:05/01/10 15:36:55
>>822
そこまで書いてないんじゃない?
別にインスタンスの状態にまで責任持つクラスでもないし。

825 :仕様書無しさん:05/01/10 15:37:10
そうそう。大差無いんだから熱くなんなや。

826 :仕様書無しさん:05/01/10 17:00:11
特定のパターンの議論なんてどうでもいいよ。
そんなの出来てもなんの自慢にもならんし、普通に議論することじゃないだろ?
まさか空気を吸い込める程度のことを自慢してる馬鹿がいるのか?

827 :仕様書無しさん:05/01/10 17:03:50
>>826
こいつ読んでねーぞw

828 :仕様書無しさん:05/01/10 20:57:47
>>826
ジサクジエーンで消化、乙

829 :仕様書無しさん:05/01/10 22:13:24
>>820
シングルトンのgetInstanceはnullは返さないよ、エラーが無い限りは。
初回のgetInstance呼び出しが返るまでに確実に一個だけのインスタンスを
生成するってのがシングルトンパターンの意味なんだから。
単なるグローバル変数だと「確実に一個だけ」を保証することが出来ない。
特にマルチスレッドでね。

830 :仕様書無しさん:05/01/10 22:16:42
そもそも getInstance はインスタンスの生成じゃないでしょ
インスタンスがどう生成されているかはきにしない

831 :829:05/01/10 22:22:04
>>830
いや、だから「返るまでに〜生成する」と書いたわけなんだが。
初回のgetInstanceが返る前だったらどの時点で生成しても構わないんだよ、もちろん。

832 :仕様書無しさん:05/01/10 22:32:12
だから、そんなミクロな話はどうでもいいよ。


833 :仕様書無しさん:05/01/10 22:47:52
>>829
>エラーが無い限りは。

エラー処理は無視ですか?

834 :仕様書無しさん:05/01/10 22:48:30
OOの話になると色々と超越する奴が居るな。

835 :仕様書無しさん:05/01/10 22:57:41
>>833
そりゃ、例えばログオブジェクトだったらログファイルが開けなければ
エラー処理が必要だろうし、そういう場合はオブジェクトの生成にも
失敗するだろう。
そんなのはそれこそ個別に対応する部分であって、シングルトンパターンとしては
特に語られてはいない。
ただし、単なるグローバル変数だとエラーに対する統一的な管理が不可能なのに対し、
getInstanceでオブジェクトを取得するようにしておけば例外を投げるなどの処理を
一括して行うことは出来る。

836 :仕様書無しさん:05/01/10 22:59:44
>>835
でもべつにそれってシングルトンの利点じゃないよね?

837 :仕様書無しさん:05/01/10 23:25:15
グローバルクラスだって生成時に例外出せるぞ。

838 :仕様書無しさん:05/01/11 00:10:59
>>837
そうすると、その例外はプログラム実行前に発生するかも知れませんね。

839 :仕様書無しさん:05/01/11 00:29:15
エラー処理の話は実装依存と言語依存とアプリ仕様にかかわる話だから、
話あっても平行線になるだけだと思われ。

840 :仕様書無しさん:05/01/11 22:11:46
平行線っていうかシングルトン厨が過信し過ぎ。

841 :仕様書無しさん:05/01/11 22:25:10
シングルトンだけに同一性の意見しか出ません。w

842 :仕様書無しさん:05/01/11 22:37:32
次に語るのはIteratorあたりか?
これも存在意義が薄いパターンだよな。

843 :仕様書無しさん:05/01/11 23:10:42
>>840
「シングルトン厨」ってのも初めて聞きました。
ところで、「過信」とは?

844 :仕様書無しさん:05/01/12 09:50:44
デザパタ厨の典型として、手段が目的になってしまうことが上げられると思う。
デザパタなんぞあくまで手段なのに、それが唯一で崇高なる理念になってるような・・・。w
まあ言うと違うと否定するんだろうけど、その他の発言は全然否定できない。

845 :仕様書無しさん:05/01/12 14:58:37
Iteratorが無ければSTLはゴミになるよ?いいの?

846 :仕様書無しさん:05/01/12 15:07:42
>845
必要なときだけ使う。

Iteratorじゃないとまずいってのは、業務系だとめったないな。
マルチスレッドが出てこないと必要性を感じない。

847 :仕様書無しさん:05/01/12 15:08:07
オブジェクト指向の話は、C++ 限定ですか、そうですか。

848 :仕様書無しさん:05/01/12 15:10:24
馬鹿な俺のために
イテレータとマルチスレッドの関連性を説明してクダセェ

849 :仕様書無しさん:05/01/12 15:16:20
JAVAしかしらない>>864が、JAVAのイテレエタがスレッドセーフだからそう考えた。だと思う。
だから、そういうミクロなことしか考えられない奴は話が合わないから口出すなといいたくなるんだが。

850 :848:05/01/12 15:23:35
>>849
ああそうなのですか。サンクス
#後半同意。だけどここは匿名掲示板だからねw。どうしても経験が浅い人の方が多いしね

851 :仕様書無しさん:05/01/12 19:09:12
>>848-850
自演乙

852 :仕様書無しさん:05/01/12 19:22:22
イテレータ厨もイテレータを過信し過ぎ。

853 :仕様書無しさん:05/01/12 23:42:18
デザパタはあくまでパターンの一つであって、
付随するメリットは他の多くの実装方法でも満たせる事を忘れてはいけない。

854 :仕様書無しさん:05/01/13 00:17:47
>>853
つーかやっぱ駄目なものは駄目だよ。
そろそろ駄目なものといいものを見抜く目を養えよ。

855 :仕様書無しさん:05/01/13 00:23:54
>>852
何故、イテレータを過信してはいけないか、理由を説明してくれ

856 :仕様書無しさん:05/01/13 00:37:23
>>853
Abstract Factoryとかについて語っているならわりと同意だけど…
その程度のオブジェクトを生成するのにわざわざBuilderをFactoryで作る必要があるのか
おまえデザパタ言いたいだけじゃないんかと小一時間問い詰めたい、ってことならある。

でも、IteratorとかSingletonみたいなプリミティブなパターンは、特に意識せずに
何となくで使うよなあ。
特にIteratorは、JavaでもTigerでforeachと同じことが出来るようになって
完全に言語に統合されちゃったし。
むしろ、あまりにも当たり前になった為に特にパターンとはいえなくなってはいるかもしれんが。

857 :843:05/01/13 00:51:34
>>852
繰り返しになりますが、
「イテレータ厨」ってのも初めて聞きました。
ところで、「過信」とは?

「自分が理解せずに使って失敗した」以外の回答を期待しています。

858 :仕様書無しさん:05/01/13 00:55:48
>>856
>特にIteratorは、JavaでもTigerでforeachと同じことが出来るようになって

これが過信の例。配列もforeach使えるし、
そもそもIteratorパターンに関する話ではない。
あとプリミティブとか軽々しく使うな。馬鹿に見えるから。

859 :仕様書無しさん:05/01/13 00:58:16
>>857
>>858の「配列もforeach使えるし」の記述から察するに、
ただ単純にIteratorとは何かを理解していないだけと思われ。

860 :仕様書無しさん:05/01/13 01:04:48
>>859
配列ってCollectionの事じゃないけど、当然理解しての発言だよね?
んでIteratorパターンって何か教えてもらえます?
僕の認識と全然違いそうなんで。

861 :仕様書無しさん:05/01/13 01:48:33
>>857
>「自分が理解せずに使って失敗した」以外の回答を期待しています。
つか、Iteratorってのは使うことで何かに失敗する類のものですらないと思うんだが。
配列を使って失敗したからリンクリストに替えた、でもIteratorを使っていたから
簡単に挽回できた、という話なわけで。
結果的にIteratorを使う必要がなかったって話ならまああるだろうけど、
Iteratorを使ったことで失敗した例ってのは、あれば聞きたいくらいだなー。

862 :仕様書無しさん:05/01/13 01:55:24
Iteratorのメリットは配列やコレクション、ストリームを共通のインターフェースで
使えるのはもちろんのこと、Lispのジェネレータと同じ感覚で無限に続く乱数列や
キーボードからの入力文字列なんかも表現できちゃうところだと思う。

863 :仕様書無しさん:05/01/13 06:27:30
プログラム言語の1課題として、ソース上で複数行に渡って記述される繰返を如何に排除するか?
って所があると思います。

だから、Iteratorを話す事はデザパタを語る以上の非常に意義があると思うけど。どう?


864 :仕様書無しさん:05/01/13 07:41:43
>>863
オブジェクト指向と関係無いしw

お前の頭にはそれしかないだろ?w

865 :仕様書無しさん:05/01/13 09:27:05
ペンデルトンさん age

866 :仕様書無しさん:05/01/13 09:52:55
木を見て森を見ずどころか、葉を見た気になって森を見ずぐらいな奴だな。いてちゅう。

867 :仕様書無しさん:05/01/13 22:15:00
>>863
つN88-BASIC>複数行に渡って記述される繰返を如何に排除するか

868 :仕様書無しさん:05/01/14 10:14:40
モリモリを見て全部読んだ気になる。いでじゅう。

869 :仕様書無しさん:05/01/14 22:46:07
>>864
実装とオブジェクト指向を分けて考えるのは悪い癖だ。
プログラムの品質向上こそがオブジェクト指向の目的だからだ。

870 :仕様書無しさん:05/01/14 22:53:18
いままで「再利用」がオブジェクト指向の最大の目的だと
思っていたが

871 :仕様書無しさん:05/01/14 23:06:18
ソフトウェア品質特性には移植性という項目もある。

872 :仕様書無しさん:05/01/14 23:49:18
オブジェクト指向を口にする割に認識能力、定義能力、関係意識が
恐ろしく低い人達が多いのは何故ですか?


873 :仕様書無しさん:05/01/15 00:10:35
OOの目的はソフトウェアの開発生産性をあげること、それに尽きる
その為の抽象化と関心の分離

874 :仕様書無しさん:05/01/15 00:11:06
>>872
あなたがここに来るのと同じ理由です。

875 :仕様書無しさん:05/01/15 00:11:51
ソフトウェア品質特性には効率性という項目もある。

876 :仕様書無しさん:05/01/15 00:26:25
>>869
つか、今まで提案されたあらゆる手法がプログラムの品質向上を目的としているんだよ。
プログラムの品質を向上させるために何を重視するかってところが違うわけで。

877 :仕様書無しさん:05/01/15 00:39:30
デザインパターンの本読んで
オブジェクト指向って、こういう事をするための物なのか
と思ったんだけど、そういう考え方で合ってる?
てか、こんなクラスを一から設計できねーよ!
下手な設計で開発に踏み切ったら地獄見るじゃねーか!

878 :仕様書無しさん:05/01/15 00:46:37
>>877
俺のオブジェクト指向の認識は違うな。
デザパタなんて糞。
まったく役に立たねぇ。
よく、
「オブジェクト指向を理解するには素質が必要で
理解出来る奴は10分でできて、出来ない奴は一生無理」
って聞いたこと無いか?
あれ、まったくその通りなんだよね。
いいか?10分だ。10分で理解できなきゃ。
オブジェクト指向覚えないでいまのやり方で組んでろ。どうせ無駄だ。

879 :仕様書無しさん:05/01/15 01:00:48
>>878
出来なかったんだね…可哀想…

880 :仕様書無しさん:05/01/15 01:04:46
>>878
その10分の内容を知りたいな。
本を読むには短すぎるしな.....

881 :仕様書無しさん:05/01/15 01:18:50
>>880
いいだろう。
ただし、金もらってるわけじゃないし手短にいくぞ。
まず、オブジェクト指向で一番大事なのは感覚だ。
この感覚をつかむのに知識なんて役に立たん。
いいか?説明は一瞬で終わるぞ。
では、どぞー!以下説明。

シューティングゲームを作るときに自機、敵、弾を
それぞれ自機クラス、敵クラス、弾クラスとしてプログラムを作る。
これがオブジェクト指向だ。

はい、終わり!これ以上説明いりません。
さあ、理解しろwあと、10分!これで君の運命が決まる!
※2ちゃんオススメ書籍「憂鬱な〜(省略)」から抜粋。

882 :仕様書無しさん:05/01/15 01:40:51
>>881
あ、なるほど。
そういう事ね。

883 :仕様書無しさん:05/01/15 01:55:32
>>881
糞つまらんオチだな。

884 :仕様書無しさん:05/01/15 02:05:40
>>883
マジレスするとこれ(>>881)がオブジェクト指向の本質。
これが理解出来ない奴がデザパタのパターン数を覚えることに力を注いだり、
テンプレートに妙な技巧を凝らしたり、とんちんかんなことをはじめる。

俺の経験からいうとなんか知識ばっかり重たい奴に多い気がする
体で覚えようとしないっつーか、いちいち何かを定義してやらないと何もできないっつーか。
まあ、よくわからんが「素質」がねぇんだろうなw

885 :仕様書無しさん:05/01/15 02:08:30

小物しか作ったことがないバカ

886 :仕様書無しさん:05/01/15 02:11:05
>>884
GoFに挫折した君はさっさと引退しないよ、邪魔だからさ

887 :仕様書無しさん:05/01/15 02:19:55
>>885-886
オブジェクト指向も理解できないチンカスが
何、図星つかれてキレてんだよw

普通にオブジェクト指向理解してりゃデザパタなんて
いらないっつーか、デザパタってオブジェクト指向がどうとかってもんじゃねーじゃん。
つか、あんまり変なクラスの使い方してて引く。
使っちまったら、プロジェクト全体でデザパタ本をみんなで共有しなきゃならんぐらい
なにやってんだかわからんようになるだろうな。
はっきりいって絶対にはやらないw(どの職場いったって使ってるところなんて無いよ。言い切れる。)

888 :仕様書無しさん:05/01/15 02:21:23
>>887
はぁ?

889 :仕様書無しさん:05/01/15 02:26:06
>>887
落ちこぼr

890 :仕様書無しさん:05/01/15 02:29:47
>>881
全然具体的じゃないな
日本語勉強しよう

891 :仕様書無しさん:05/01/15 02:57:53
>>890
うん。
これがわからない人は何年やっても駄目だと思ってる。

892 :仕様書無しさん:05/01/15 03:00:49
>>890
つか、オブジェクト指向って確実に
そのあいまいなレイヤーにあるもんだぞ。
これ以上具体的にはならない。
つか、>>881の説明でプログラム組むのに
後、何が足りねぇんだよ。
とりあえず、理解できない奴は

自機クラス、敵クラス、弾クラス

を作って、簡単なインベーダーゲーム(壁無し)でも作ってミロや。

893 :仕様書無しさん:05/01/15 03:04:32
>>892
本質の説明になってない
具体例だろ、それ

894 :仕様書無しさん:05/01/15 03:04:35
よくわからないなら。
はじめだし。

自機クラス、敵クラス、弾クラス

以外のクラスはいっさい作らないで
これだけでなんとかインベーダーゲーム作ってみろ。
ちなみに敵クラス、弾クラスはそれぞれ敵一匹、弾一発分のクラスだ。

895 :仕様書無しさん:05/01/15 03:05:48
>>893
本質の説明は>>881だってこれ以上の説明は無意味だ。
これで理解しろ。
できなきゃオブジェクト指向は理解できねぇで終わる。
ただそれだけだ。
別に俺は困らない。
てめぇでなんとか理解しろ。

896 :仕様書無しさん:05/01/15 03:08:22
>>890のは同意だがその上でModernC++Designとか読むとさらに目が開かれる。

897 :仕様書無しさん:05/01/15 03:09:56
>>896
俺はその本もオブジェクト指向の理解にはいらないといっておく。

898 :名無しさん(新規):05/01/15 03:33:35
うわぁウルトラ馬鹿が勢ぞろいだな

899 :仕様書無しさん:05/01/15 03:36:07
>>898
>新規
ぷ、必死過ぎるw

900 :仕様書無しさん:05/01/15 07:56:51

                    ‖   ~" ー 、,,_
      |           ‖ 900    ,>
   \ |  /      ‖   _,:-−'´
                ‖/~         ヽ | /
                    ‖     ,   ))
       ,、      ,、   /'ll__/ ヽ
      / ヽ__/ ヽ/ _‖   _  ヽ.    ∧___∧
    /       /  ´ ‖ー/  `   l ロ. / _    _
    / ´ 、__,  ` |.    ‖∨      ,! || | l--l `
   _l    ∨    ヽ/ ̄)( ̄ ̄`"::::ノ (⌒ヽ, ..ヽノ   ,
  ( ヽ_        /   /ll `'ー、....::ノ ∀\/ー- /`l  ヽ
   ヽ、       ,ヽ:..:ノ ‖   '::::|⊃  iー- l (_〕i__
     l          : :::Y  ‖     ::|   |"|ー-,|   |(

       900とった〜!! ありがとー。やったよ〜。

901 :仕様書無しさん:05/01/15 09:04:35
>>878

× 理解出来る奴は10分でできて

○ 理解出来ない奴は10分で見切りをつけて

902 :仕様書無しさん:05/01/15 09:49:35
転職して1年弱。
もうGoFすら理解できない人間がいる職場には戻れない。

903 :仕様書無しさん:05/01/15 11:59:18
>>902
そんな結論に達するまでに一年もかかったんですか?
周りの人はアナタの転職を願ってるでしょうねw

904 :仕様書無しさん:05/01/15 12:00:34
>>902
知識ばっかり詰め込んで安心を得る人間にはオブジェクト指向は理解できない。
毛色の違う技術もあるってことですよ。

905 :仕様書無しさん:05/01/15 12:05:40
コピペの事か? コピペの事かーーーーっ!!

906 :仕様書無しさん:05/01/15 13:15:34
>>904に同意ですね。

逆になぜオブジェクト指向が理解出来ないのか考え、導いてやる事の方が、
オブジェクト指向の理解度を測り、自分自身の理解度を促進出来る。

例えば、相手の認識事象をオブジェクトとして、それを図面化してやる。
そこから解らないとされる不明オブジェクトを導き出し、
勉強すべき事、必要な知識の提示、知識関連の整理をしてやればよい。
これはオブジェクト指向関連技法を学ぶよりオブジェクト指向を学べる。

「オブジェクト指向」というキーワードを用いて他人を馬鹿にしている奴で
「オブジェクト指向」を理解していると思えた奴はいない。


907 :仕様書無しさん:05/01/15 13:21:59
OOPだのOOPLだの記号を出してくる奴は絶対にオブジェクト指向を理解してないしな。
そもそも知識として保管できるもんじゃねぇし、わかりにくいだけ。
いくら言葉の定義を覚えても覚えられないのがオブジェクト指向と他の技術との一番の違いだろうな。

908 :仕様書無しさん:05/01/15 13:30:32
まぁでざぱたの序章を読んでおけ

909 :仕様書無しさん:05/01/15 13:31:58
>>908
まったく関係無い。
なぜなら、あれを作った奴等がオブジェクト指向を理解できていないから。

910 :仕様書無しさん:05/01/15 13:35:02
オブジェクト指向覚えるのに>>881以外の理解は必要ないよ。
逆、これが理解できなきゃ何もはじまらない。

911 :仕様書無しさん:05/01/15 13:48:59
>>910
> >>881以外の理解は必要ないよ。

> これが理解できなきゃ何もはじまらない。
がちっとも「逆」じゃないんですが。

で、クラスが自機・敵・弾それぞれ一種類しかないシューティングって
面白いんですか?

912 :仕様書無しさん:05/01/15 13:50:46
ここにいるやつは、自分以外には誰もオブジェクト指向を分かっていない、
と思い込んでいるのが笑える。

913 :仕様書無しさん:05/01/15 13:51:57
そこは 継承 でw

914 :仕様書無しさん:05/01/15 13:52:09
>>911
あくまでオブジェクト指向の説明なんだけど?

915 :仕様書無しさん:05/01/15 13:54:49
>>881の方が>>911より上だと思う。
なんとなく、直感的に。

916 :仕様書無しさん:05/01/15 14:26:35
>>914
いえね、コードとデータをカプセル化しただけで
>>910
> >>881以外の理解は必要ないよ。
などと言っちゃう人が居たものですから。
それで済むなら、それに越したことはないですが。

917 :仕様書無しさん:05/01/15 14:33:57
>>916
だから言葉で定義しようとするな、
>>881を感覚で理解することは、
おまいの言う「コードとデータ〜略」ではおさまらないぐらい
たくさんのことを覚えることにつながる。
ここで言葉での定義を求めると、オブジェクト指向を理解できなくなる。

918 :仕様書無しさん:05/01/15 14:35:14
>>912
それは逆。
ここにいる奴は、分かってないのに必死な奴が一人だけいる、と思っている。

つか、Iteratorをクソって言うのは流石にネタだろ?

919 :仕様書無しさん:05/01/15 14:37:05
サッカーでのボールの蹴り方。
野球でのボールの投げ方、バットの振り方。
水泳での泳ぎ方。
そんなもんに近いんじゃねぇかな。
頭の固い人はプログラムにもそういうものがあるって理解することのが先かな。

920 :仕様書無しさん:05/01/15 14:37:52
>>918
イテレータ云々の話は俺は参加してない。
ただ、オブジェクト指向とは関係ないね。

921 :仕様書無しさん:05/01/15 14:43:05
>>917
みんながみんな、あなたのようなバカじゃないんですからw

922 :仕様書無しさん:05/01/15 14:48:21
>>921
ということは、みんなオブジェクト指向理解できてねぇのかな?
君だって、C++の後付けの機能であるテンプレートの妙な機能いじって
オブジェクト指向理解しましたとは思ってないでしょ?

知識じゃないんだよ。
オブジェクト指向は。
詳しくは>>881をみてくれ。
これで理解できなきゃ。もう、無駄だから。

923 :仕様書無しさん:05/01/15 14:59:39
もう冬休みは終わったはずなのに・・・・

924 :仕様書無しさん:05/01/15 15:08:24
>>923
お前働きすぎ。
お前には関係ないかもしれないが、
世間様では今日は土曜日っつって、冬休み関係なく、普通に休みだ。

925 :仕様書無しさん:05/01/15 15:14:57
>>916
適切と思われるデータの集合を抽象化データとして、クラスに起こし、
必要なフィールドは適宜隠蔽/カプセル化し、アクセサをつけ、プロパティとした。
必要に応じて適切に継承し、オーバライドした。
mainにてこれらのクラスを操作し、処理を行うように記述した。

これはオブジェクト指向プログラミングといえるか、いえないか。

926 :仕様書無しさん:05/01/15 15:18:48
>>925
「適切と思われる」の部分があいまいだから、
場合によっては言えないかな?

927 :仕様書無しさん:05/01/15 15:22:13
>>925
それが正しいか間違ってるかは問題じゃねぇと思うけど
そんなわかりにくい文章にしてなにか楽しいの?
っておもっちゃうけどね。俺は。

要するに>>881が全てなわけだし。
>>925はクラスを作った後の話だからオブジェクト指向が
わからない人間への説明にはならないんじゃないかな?

928 :仕様書無しさん:05/01/15 15:24:26
>>926
適当、じゃなくて、適切、だから、お前がもっとも正しいと思うやり方がなされた、と思っていいんじゃない?
個人個人によって異なるが。

>>927
説明じゃなくて、聞いてるんだが。
お前、どっちだと思う。
いえるか、いえないか。

929 :仕様書無しさん:05/01/15 15:34:02
>>928
難しいな。
違うともあってるとも言いきれないし。
まず、アプローチはオブジェクト指向じゃないんじゃないかな?
少なくとも俺のやり方とは違うのかも。
データの集合をクラスにしてるわけじゃないし?
でも自機、敵、弾というくくりも解釈次第でそうとも言えるのか?
いや、まさにそうなのか?抽象化データとデータの定義って?
はっきりいってわからない。

2行目からはクラスの手入れの仕方だからオブジェクト指向とは関係ないかな。

だから、言葉で定義するより>>881だって。

930 :仕様書無しさん:05/01/15 15:47:30
>自機クラス、敵クラス、弾クラス
これを見て、「???、違うくねぇ?」って思ったヤシが理解できてる希ガス。

931 :仕様書無しさん:05/01/15 15:59:45
これはどうだろうか。

>>881のケースで、自機、敵、弾をクラスにした。
各クラスには適切にプロパティを配置したが、各プロパティは全てpublicで、
何も隠蔽しなかった。
つまりカプセル化の放棄だな。

自機や、敵などの抽象イメージをクラスに落としたら、それだけでオブジェクト指向と言えるだろうか。
単純にデータの問題でなく、イメージとして、隠蔽されていないといけないと思えるプロパティもあるかもしれない。
たとえば。

敵クラスに、3フレーム毎に属性が光学バリアと、磁気バリアが切り替わり、
プレイヤーがレーザーとミサイルを切り替えないといけないような性質を付加した。
敵クラスは内部にカウンタcountを持ち、3フレームを数えると、内部属性attrを切り替えるようにした。
countは、敵クラスに記述したメソッドmove(a)を使用して、
1フレーム毎に指定した角度a(rad)の方向に、敵クラス内部で保持している速度s(pixcel/ms)分だけの距離を移動するように設定し、
moveが呼ばれるたびに内部のカウントが1上がるようにmoveに記述した。
このとき、count, attrなどは隠蔽しないで(publicで)記述した。

この場合はオブジェクト指向といえるかいえないか。

>>930
思わない・・・。何が違うんだ?

932 :仕様書無しさん:05/01/15 16:05:13
881はスタート地点としては正しいが、それだけじゃ足りないよ。
その定義じゃ敵が10種類いたら10種類の敵クラスがポリモーフィズムも無く
コピペまみれで作られて、自機インスタンスとの当たり判定に

if(敵 instanceof 敵A) {
 // 敵Aの当たり判定処理
} else if(敵 instanceof 敵B) {
 // 敵Bの当たり判定処理
} else if(敵 instanceof 敵C) {
 // 敵Cの当たり判定処理

     (中略)

} else if(敵 instanceof 敵Z) {
 // 敵Zの当たり判定処理
}

とか書く奴いるぜ。
881だけからきちんとポリモーフィズムまでたどり着く奴がそんなに沢山いれば、
俺だって腐れソースのメンテ仕事しないですむんだがね。
一を聞いて十を知れってのは教える側の傲慢だよ。


933 :仕様書無しさん:05/01/15 16:06:33
>>924
>お前働きすぎ。

ああそうだよ! 今会社だよ! 働かずに2chやってたよ! スマンかったな!!
やってられっかよ!!

934 :仕様書無しさん:05/01/15 16:12:07
>>932
逆にポリモルフィズムを無視したら、オブジェクト指向でないのかどうか。

時に、>>932はそのコードをポリモルフィズムを理解したうえで、どう書いて欲しい?
public static hitCheck(敵A a){
 // 敵Aの当たり判定処理
}
public static hitCheck(敵B a){
 // 敵Bの当たり判定処理
}
・・・とか?

そしてそれをどこに書こうとしているんだろうか。

935 :仕様書無しさん:05/01/15 16:13:54
>>931
> 思わない・・・。何が違うんだ?
自機、敵、弾も共にゲームに出てくる駒の一種であるからかな?
位置は共通な情報だよな。


936 :仕様書無しさん:05/01/15 16:17:12
>>881は言いたいことはわかるが、自機、敵、弾がお互いを知らなくてはいけないから設計としてはくそだろう。

937 :仕様書無しさん:05/01/15 16:21:51
よく分からないなあ。
全体を俯瞰して語る人と、いきなりクラスの設計を語る人とが入り乱れてない?

938 :仕様書無しさん:05/01/15 16:25:58
>>935
class Unitとかを定義して、

class Player extends Unit
class Enemy extends Unit
class Bean extends Unit

とかってやれ、ってこと?
まあ、良し悪しはともかく、わざと省略したところもあるんじゃ。


939 :仕様書無しさん:05/01/15 16:29:36
>>934
自分は 932 ではないが 934 が
ポリモーフィズムを理解していないことは良く分かった。。。

940 :仕様書無しさん:05/01/15 16:30:52
>>937
まあ、自分が思うように話が進まなくて不満はあるだろうが・・・。

ただ、実装方法を聞いているのは、「オブジェクト指向」が分かっていれば、
自然、実装方法も大体固まってくる、ってことがあるからさ。
「オブジェクト指向」思考が出来れば、たとえ知らなくても、
「それはこうした方がいいじゃんじゃない?」という意見が言えるはず。なのさ。

だから、聞いているのはあくまで、実装方法じゃない。
オブジェクト指向思考に照らして考えて、この実装はどう?という話。

941 :仕様書無しさん:05/01/15 16:31:43
>>939
とりあえず書いてみれば?
そこで終わりの書き込みばかりだから、先に進まない。

942 :仕様書無しさん:05/01/15 16:34:40
>>931-934
どうして勝手に新要素を入れて語りだすかな。
当り判定とか座標ってこの段階で出てくる話なの?

943 :仕様書無しさん:05/01/15 16:35:28
>>937
同意。
こいつらアホ過ぎて話にならない。

944 :仕様書無しさん:05/01/15 16:37:18
>>942
いや、どれも読めば普通に、何を言わんとしているのかは分かるが・・・?
そういうことじゃなくて?

945 :仕様書無しさん:05/01/15 16:39:21
>>939
マ板的にはモリポーフィズムと言うべきなんだけどなw

946 :仕様書無しさん:05/01/15 16:51:53
なんか非常にストレス溜めて帰っていった人がいたらしいな。

947 :930:05/01/15 17:12:58
>>938
あえてそれを省略されると、腑に落ちないっす。

948 :932じゃないが:05/01/15 17:30:05
>>934
public abstract Abs敵 {
 public abstract boolean checkHit(自機 jiki);
}

普通こうじゃないの?
あたり判定は全ての敵共通だろうし。
あたり判定メソッドをを自機に持たすのがいいのか
敵に持たすのがいいのかは俺はアホなので分からん。

949 :仕様書無しさん:05/01/15 17:38:21
>>948
俺はそんなことしないな。

950 :仕様書無しさん:05/01/15 18:16:08
そうか

951 :仕様書無しさん:05/01/15 18:19:03
>>950
元気出せ

952 :仕様書無しさん:05/01/15 19:27:53
>>941
class 敵
{
virtual public hitCheck(void) = 0;
}
class 敵A:public 敵
{
void 敵A::hitCheck(void){
 // 敵Aの当たり判定処理
}
}
class 敵B:public 敵
{
void 敵B::hitCheck(void){
 // 敵Bの当たり判定処理
}
}
C++で悪いが(Javaは記述法知らん)こんな感じか。
これで例えば
void hitCheck(敵* teki){
teki->hitCheck();
}
みたいな関数があったら敵A、Bどちらのポインタを渡しても
適切なhitCheckメソッドを呼び出してくれる。

953 :仕様書無しさん:05/01/15 19:43:28
敵ってなにかの分析があいまいすぎてとてもOOとはいえないあたりがこのスレの限界か

憂鬱あたりからようやく一歩踏み出せる程度の言語知識はあるようだが

954 :仕様書無しさん:05/01/15 19:51:53
敵って、、、、モニタ上に自分の絵を描き、移動し、弾から位置を聞かれたら答え
弾から当たったと宣言されたら消滅し、時々自分も弾を発生させるもの....だろ?

955 :仕様書無しさん:05/01/15 19:55:33
設計レベルが低すぎて話にならない。
なんで当り判定の話なんてしはじめるのか非常に謎だ。
しかも、設計悪いし。

956 :仕様書無しさん:05/01/15 19:56:44
>>954
弾が敵を知ってるってのはおかしいと思うから間に何か噛ませたほうがいい気はする。
このスレのデザパタ反対派は反対するだろうけど。

957 :仕様書無しさん:05/01/15 19:57:37
>>954
表示をつかさどるクラスに
敵インスタンスの情報を渡す形にしたほうが綺麗な設計だな。

958 :仕様書無しさん:05/01/15 19:59:54
hitCheckとか関数作ってる奴がいるが
hitCheckはもちろんあたりの判定をするだけだよな?
まさか当たった後の処理までここでやらないよな?

959 :仕様書無しさん:05/01/15 20:01:17
>>948
なんで敵のクラスに自機クラスがいるんだよw
お前のソースは自機のクラスにも敵クラスがいるのか?
ソースが大変そうだなw

960 :948:05/01/15 20:52:10
>>959
スマソ、言ってる意味が分からん。
自機インスタンスとのあたり判定処理ってことで引数で自機インスタンスを渡してみたんだけど。
>>敵のクラスに自機クラスがいる
ってどういうこと?

>>958
checkっていう名前なんだから真偽を返すんではなかろうか。

961 :仕様書無しさん:05/01/15 21:09:20
>>960
敵classと自機classは互いに独立じゃないといけない、ってことだろうか。
そもそも、2つのオブジェクトが衝突しているかどうかを判定するメソッドを記述する場所は、
それを判定されるオブジェクトの中でほんとにいいの? という問題もあって、それは>>956-957当たりが指摘している。

962 :948:05/01/15 21:17:09
>>961
あぁなるほど。
それならば納得。

ついでにいうと俺は956でもあったりする。
>>948>>932からの流れで書いたもんだからその辺は気にせんで貰いたかったんだが。
俺はmediatorを置いたほうがいいと思う。


963 :仕様書無しさん:05/01/15 22:07:14
>>953
ひょっとして934?
934がポリモーフィズムを理解していないのを
指摘しただけなのだが。

964 :仕様書無しさん:05/01/15 23:33:51
>>963
::::::::/           ヽ::::::::::::
:::::::::::|  ば  じ  き  i::::::::::::
:::::::::::.ゝ か   つ   み  ノ:::::::::::
:::::::::::/  だ  に  は イ:::::::::::::
:::::  |  な。       ゙i  ::::::
   \_         ,,-'
――--、..,ヽ__  _,,-''
:::::::,-‐、,‐、ヽ. )ノ      _,,...-
:::::_|/ 。|。ヽ|-i、      ∠_:::::::::
/. ` ' ● ' ニ 、     ,-、ヽ|:::::::::
ニ __l___ノ     |・ | |, -、::
/ ̄ _  | i     ゚r ー'  6 |::
|( ̄`'  )/ / ,..    i     '-
`ー---―' / '(__ )   ヽ 、
====( i)==::::/      ,/ニニニ
:/     ヽ:::i       /;;;;;;;;;;;;;;;;

965 :仕様書無しさん:05/01/15 23:51:10
どうでもいいけど10分で人の限界が測れるわけ無いじゃん。
俺の友達は小3まで九九が出来なかったのに、
最終的に一流国立大の理系学部に現役合格したよ。

俺には>>881の主張が「分数の割り算で躓く奴は一生数学が苦手」
程度の迷信にしか感じられないよ。

自分で努力しない奴ほど人の努力を過小評価しがち。

966 :仕様書無しさん:05/01/15 23:58:52
>>965
ぷw
人はいいから自分を磨けよw

967 :仕様書無しさん:05/01/16 00:08:19
>>966
お前ウザイからトリップ付けろよ。

968 :902:05/01/16 00:28:50
「GoFって何?美味しいの?」な職場から、
GoF程度の基礎レベルはみんなが基礎教養としてもっていて
なおかつ各自の関心領域を中心にアンテナを張り価値観を磨いている職場に転職したのだよ。

仕事がやりやすいことこの上ない。
意思疎通のレベルや効率性が段違いだ。

前職の環境だと、いろんな知識領域についてメリットや存在意義がら共有させていかないとならない。
いまの環境だと、みんなで「その先」に向かっていける。

オブジェクト指向が100%分かる日なんて、少なくとも自分には来ない。

969 :仕様書無しさん:05/01/16 00:58:53
>>968
教えてくれ。どこの会社か。つーかいりませんか?メールで。

970 :仕様書無しさん:05/01/16 02:10:52
>>969
惨めな奴。

971 :仕様書無しさん:05/01/16 10:47:27
オブジェクト指向関連技術の形式的技法云々は云いから、
各技法や仕様が生まれた背景や元となる要求、
また現状に落ち着いた制約の所在等を知りたい。

これって、オブジェクト指向に限らず重要な意識だと思うが?

後、何故この様な本が無いのか不思議。
結局、オブジェクト指向伝導師達は、「オブジェクト指向」という看板で
自分達の名を伝導する事が仕事なのか...?
ま、商売だからね...

972 :仕様書無しさん:05/01/16 12:49:58
>>971
入門書の類でなければ、そういったことは各々の技法や仕様の本の
序章か1〜2章または最終章の辺りに大体は書いてあると思うけど。
もちろん、そういった本だと主題とする技法に対して好意的な纏め方になるけど
その点は他の技法の本と比較検討すればよい。

それとも、いろいろな技法について網羅的に書いてある本が欲しいってこと?
でも、仮にそういう本があったとしてもその本の著者が不偏不党ということは
多分ありえないから、他の見方を知るためには他の本との比較が結局は必須となる。

973 :仕様書無しさん:05/01/16 14:13:59
>>964
相手にするな。
けちだけつける、「俺だけが分かってる厨」は、
何を言おうと、このスレでももっとも低レベルなやつだ。
相手にするだけ損。

>>335の通りだな。

974 :971:05/01/16 15:21:47
>>972
ご意見ありがとう。
>いろいろな技法について網羅的に書いてある本が欲しいってこと?
そうです。在り来たり的な所ですが
「UMLモデリングの本質」や「なぜオブジェクト指向でつくるのか」に
記述されている技術背景や歴史を読んだ解きに、私は後付理論の恐ろしさを感じました。

いまの、オブジェクト指向では後付理論がまかり通り、目先の議論
つまり、現在整合性の取れる理論を求めている様に感じます。

しかしながら個別の技法は各々の問題や欲求解決の為に存在しているのですから
統合的に整合性を取った見解を求める事は非常に危険では無いでしょうか?

たとえ形式技法であっても、その裏には要求がある訳です。

そしてシステム工学の技術の発展置いては過去、問題を完全に解消できた
技法や技術は存在していない訳ですから、
オブジェクト指向も漏れなく関連技法の向こう側にある要求が何であるかを
意識しないというのは危険な話だと、後輩達を見て懸念している次第であります。

その懸念解決を、伝導師に委ねてしまっている私個人の問題もありますが...

975 :仕様書無しさん:05/01/16 17:58:42
>>974
この本にはいろいろな技術の誕生背景とか、オブジェクト指向だと、
他の学問領域のどの辺を参考にしたのかが、簡単に書いてある。

「ソフトウェア設計の基礎」
ttp://www.amazon.co.jp/exec/obidos/ASIN/4890194843/qid=1105864096/sr=1-3/ref=sr_1_10_3/249-5099150-4694751

たしかに各技法の本を見ると、技法についての記述はあるが、そもそもその技法
を採用するにいたった理由については薄いコメントしか書かれていない。
限定された状況でのメリットをさも万事適用できるかのように書かれているのは気に入らない。

各技法を比較検討して、それぞれの適切な適用領域を誰か教えてくれねぇかなと思う。

あと、974の言うとおり、「要求」を理解していないと、使えない新技術を銀の弾丸として信じ込んでしまう
ことになると思う(そういえばLyeeはどこに行った?)。

976 :仕様書無しさん:05/01/16 18:10:26
現在淘汰されつつある技法が劣種だという事実だけは信頼出来る情報。

977 :仕様書無しさん:05/01/16 22:08:39
実装と概念は別、って考えの人、いるみたいんだね。
実装の話をされると、それは今の話題じゃない、みたいな。

確かに言語ごとの実装方法は違うわけだし、
概念を語る上で実装を示す必要はないわけだけど、
逆に実装を示されたときに、それが正しいか、間違っているか、
くらいはいえないと不味いんじゃないのかね。

実装と概念は別、って言っても、このコードはオブジェクト指向に照らしてみて、
適切か不適切かと聞かれて、どうとも答えられない、なんて、何のための概念なの。
よりよいプログラムを書くための概念だろ。
ただの思想じゃないんだから。
たとえ言語の知識はなくとも、どのクラスにどのメソッドを実装するべき、とか、
どのプロパティを隠蔽するべきか、なんてことは、本当に理解しているなら、
答えられるはず。

おかしな詭弁であれこれ逃げ口上を探して、その上、
突っ込まれると黙り込むなんて、見ているほうが恥ずかしい。
少し自分の知識と思考のレベルについて、まじめに考えたほうがいい。

978 :仕様書無しさん:05/01/16 22:16:43
>>977
スマンがどのあたりの話なのかポインタ指してくれ。

979 :仕様書無しさん:05/01/16 22:28:59
NullPointerException

980 :仕様書無しさん:05/01/16 23:56:15
>>977
だって設計から実装を特定できないの
なんてそいつのレベルが低いからだもん。
相手するだけ時間がもったいないじゃん。
ある程度の能力があればまかせちゃっていい部分だろ。
話なんてする必要が無い。
っつーかアンカーつけろよ。お前。

981 :仕様書無しさん:05/01/17 00:32:47
>>980
なんか>>977へのレスとして噛み合ってなくないか???

982 :仕様書無しさん:05/01/17 01:05:27
>>981
俺は噛み合ってるようにみえるけど?

983 :仕様書無しさん:05/01/17 01:19:00
レベルの違いがあると相互理解もできないね。

984 :仕様書無しさん:05/01/17 04:21:15
>>980
実装を考慮しない設計をして悦に入ってるSEですか?
死んでくれ。

985 :仕様書無しさん:05/01/17 04:29:19
素直に何をどうして良いか分かりませんと言えよお前ら。

986 :仕様書無しさん:05/01/17 09:51:25
つうかさ、これ自体が定理じゃなくてあくまで技法であることを理解しないと。
唯一の絶対解は存在しないと、綺麗に言えばげーじつとかと同じようなもの。

だから、みようみまねの型から入って出来たつもりになる、xx厨もいれば、
あれはこういうことだ、あの部分はどうだと、オタクのように語る奴もいればとなるわけで。

987 :仕様書無しさん:05/01/17 19:17:12
Javaでオブジェクト指向なプログラム設計って、今、あんまりやんねーのかね。
おれ、Java案件6こくらいまわってるけど、2つしか、オブジェクトな感じじゃ、ねかった
みんな、if文な感じだった。
そして、オブジェクトでつくってると、難しくてわかんねーって、文句言われるんだが(つд`)
おれ的に、仕様とかわかりやすいし、バグ出たときも直しやすくっていいのに

988 :仕様書無しさん:05/01/17 19:22:48
>>980は実装の話になると、眠くなるタイプ。

989 :仕様書無しさん:05/01/17 19:29:23
少なくとも>>987のような文章を書く奴の(ry

990 :仕様書無しさん:05/01/17 19:36:12 ,
(・∀・)?ネムクナル

991 :仕様書無しさん:05/01/17 21:53:04
>>987
>みんな、if文な感じだった。

if文指向プログラミング?


992 :仕様書無しさん:05/01/17 23:10:38
オブジェクト指向設計も確り出来ない組織にて
各自バラバラにオブジェクト指向プログラミングなんかしたら、

最悪だな!


993 :仕様書無しさん:05/01/18 00:05:05
>>992
問題ない。
最終的にクラスをそいつが書いた仕様orサンプルどおりに
使ってみて正常に動くかどうかしか問題にならない。
(うちはグローバル変数禁止だからね)
テメェのケツはテメェで拭けってスタンスだから誰も困らない。

994 :仕様書無しさん:05/01/18 00:19:37
>>993
なんか最悪の組織だな

995 :仕様書無しさん:05/01/18 00:39:08
>>994
これが一番効率いいぞ。
もちろんそいつが辞めたらそいつが作ったクラスごと破棄。
(破棄っつってもすべてが使えないわけじゃないしね)
同じ仕様を満たしたクラスを作ればいいだけ。
こっちのほうがヘタな保守よりよっぽどてっとりばやい。

996 :仕様書無しさん:05/01/18 12:51:51
>>995
一見、無駄で最悪だけど、現実的な方法だよね。
下手な保守よりかはマシって意味でね。

997 :仕様書無しさん:05/01/18 20:11:54
>>995
その上で汎用的になりそうなクラスをみんなで話し合えよ
どっかにこんな暮らすあるよ掲示板見たいのつくって。
そうすりゃ、資産どんどんできるだろうが。

998 :997:05/01/18 20:12:29
お前ら少しはコミュニケーションしろよ・・・

999 :仕様書無しさん:05/01/18 20:13:37
1024!!

1000 :仕様書無しさん:05/01/18 20:20:03
だ め

だ ね

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

247 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)