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

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

【OOD/P】オブジェクト指向開発はなぜ流行らないの?★3

1 :仕様書無しさん:2007/02/18(日) 23:14:56
前スレ

●●オブジェクト設計は何故流行らないの?●●02
http://pc10.2ch.net/test/read.cgi/prog/1169570260/

過去重複スレ
●●オブジェクト設計は何故流行らないの?(2)●●
http://pc10.2ch.net/test/read.cgi/prog/1169568701/

哲学論で否定、肯定はせずに、まずは参考URLを読んだ上で語りましょう。

【参考ページ】
ドメインモデル貧血症
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

ドメインロジックとSQL
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL

データ中心指向とオブジェクト指向
ttp://hp.vector.co.jp/authors/VA020635/system/dataorient.html

さあ、張り切っていきましょう。

2 :仕様書無しさん:2007/02/18(日) 23:37:30
張り切ったら負けかなと思っている

3 :仕様書無しさん:2007/02/18(日) 23:47:35
>>1

4 :仕様書無しさん:2007/02/18(日) 23:51:36
ぶるーまんでー;;

5 :仕様書無しさん:2007/02/19(月) 00:25:02
>>1おつ
こっちつかえばいいの?

6 :仕様書無しさん:2007/02/19(月) 00:30:10
ぉまぃら早く寝ろよ
それとも明日は鬱発症か?
・・・あぅぅ・・仕事行きたくねぇ・・

7 :仕様書無しさん:2007/02/19(月) 00:57:26
スレタイ、なんでOOAは無視?別にいいけど。

8 :仕様書無しさん:2007/02/19(月) 08:11:32
コードが腐ってやがる、人類にOOは早すぎたんだ

9 :仕様書無しさん:2007/02/19(月) 20:51:11
インターフェース、インターフェースって、AOP厨はインターフェースの定義
しか頭にないの。定義するだけならバカでもできるじゃん。
DBが変わったときのためにぃ抽象化しとくぅとか、今までDB変えたためし
あるか? 俺は無い。最初のDBがずぅーっと動いてる。アホか。
DB変えるような事態になったらシステムごとリプレースするっちゅーねん。
その方が儲かるっちゅうねん。
実際の現場じゃ実装部分だけ差し替えるなんて滅多にあるもんじゃないっつーの。
まったく自己満足のためにやってるとしか思えん。コストの高い保険だぜ。

10 :仕様書無しさん:2007/02/19(月) 23:11:44
>>9
日本語でおk

11 :仕様書無しさん:2007/02/20(火) 00:17:28
レスが無いから、>>9でも解読するか。

2行目と3行目はつながりが無いのかな?だとすると>>AOP厨は
>>ORM厨の誤り、と見せかけて>>OOP厨の誤りと考えるのが自然か。

3行目以降はORMについて書いているようだが、
ORMはDBMSの置き換えリスクに対してやるものではないな。

12 :仕様書無しさん:2007/02/20(火) 00:21:46
>>11
日本語でおk

13 :仕様書無しさん:2007/02/20(火) 00:33:17
OO厨 俺w

14 :仕様書無しさん:2007/02/20(火) 00:51:07
設計段階で、
業務分析から製造までをオブジェクト指向で稼動できてるPJってどれぐらいあるんだろ。
一般的なPJってこんな感じだろ。

設計=業務を知ってる奴、又は覚えていく過程にある奴が、ファイルに落とす。
その過程で設計規約などの存在は薄れていく。

製造=設計書に文句をつけながらコーディング。
設計者→製造担当ならまだなんとかなるが、
理想といわれる分業をやると多くは悲惨な目にあう。

テスト=テストファーストなんてものは納期優先のため存在しない。
ユーザーテストが単体テスト。

あんたらの現場は違うか?
大方こんなとこばっかりだと思うんだけどな。

15 :仕様書無しさん:2007/02/20(火) 00:56:40
XPがちょっと入ってるのはスルーしてくれ。

16 :仕様書無しさん:2007/02/20(火) 01:09:18
>テスト=テストファーストなんてものは納期優先のため存在しない。
>ユーザーテストが単体テスト。

こんな感じの現場だと、むしろ設計担当=製造担当=テスト担当のところが多い気がする。

17 :仕様書無しさん:2007/02/20(火) 01:14:42
「オブジェクト指向」
言ってみただけで偉くなったように勘違いする呪文。
実際はコンフュ。

18 :仕様書無しさん:2007/02/20(火) 01:20:30
Q:何故流行らないの?

A:努力不足

みんなデスマには耐性あるくせに

19 :仕様書無しさん:2007/02/20(火) 01:26:36
ラクをするためのはずのオブジェクト指向なのに、
設計では一向にラクだと実感したことが無いんだが。
どっちかといえばイライラした記憶ばかりだ。

20 :仕様書無しさん:2007/02/20(火) 01:35:51
昔ながらの設計書(業務単位に手続きをだらだら書いてある)を受け取って、
一生懸命OOPに翻訳していかなきゃいけないのは苦痛以外の何者でもない。

21 :仕様書無しさん:2007/02/20(火) 01:43:50
>17
一人よがり乙
銀の弾丸はないのに
自分に都合よい視点で考えてるだけだろw

OOが魔法の呪文になるのは
お前にも原因があると思ってない時点で終わっとるな。



22 :仕様書無しさん:2007/02/20(火) 01:44:24
そりゃ苦痛だろうな。
そんな無駄なことやってんだから。
上流と下流で別のもん作ってりゃあ世話ないわ。

23 :仕様書無しさん:2007/02/20(火) 01:45:36
>>21
欧米かw

24 :仕様書無しさん:2007/02/20(火) 01:48:42
ぶ 銀の弾丸w

25 :仕様書無しさん:2007/02/20(火) 01:54:07
IT国家が生き残る。
インドを見よ。
国立の理系は、4年間オブジェクト設計を必須にする。
まじ、国家のためになる。(乙の乙

26 :仕様書無しさん:2007/02/20(火) 01:57:27
>>25
オブジェクト指向の名が知れて
4年以上経ってる日本のIT業界はダメってことだな。

27 :仕様書無しさん:2007/02/20(火) 01:57:59
銀の弾丸てwwwwwwwww

28 :仕様書無しさん:2007/02/20(火) 02:02:08
オブジェクト指向は仕様変更や拡張を楽するためのもんじゃね
最初しんどいのは仕方ない

29 :仕様書無しさん:2007/02/20(火) 02:04:41
そこでYAGNIですよ

30 :仕様書無しさん:2007/02/20(火) 02:05:15
山羊煮?

31 :仕様書無しさん:2007/02/20(火) 02:09:37
>25
あまり関係ないがインドの九九は
一桁違うらしいな。

まぁ、地頭で差がつくと
埋めるはどの道厳しいけどな。



32 :仕様書無しさん:2007/02/20(火) 02:14:08
オブジェクト指向開発は一般化しとる。しとるが、
導入はしてるように見えるだけで昔となんも変わっとらんな

33 :仕様書無しさん:2007/02/20(火) 02:40:13
ソフトウェア開発にあたって、画一的な手順を確立して最適化してっていう
発想を変えていかないとだめなんじゃね?
プログラムを組むプログラムを組もうとする、果て無き取り組みに見える。

34 :仕様書無しさん:2007/02/20(火) 02:42:02
>>19,28 うむ。
設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。
そして通常、設計の工数よりも実装〜保守の工数の方が多いから
設計段階で手間をかける方が効率がよいというわけだ。
OOに限った話じゃないけど、OOだとそれが顕著な気はするね。

35 :仕様書無しさん:2007/02/20(火) 03:06:39
>>28
最初しんどい
後もしんどい

36 :仕様書無しさん:2007/02/20(火) 03:13:07
OOD支援ツールと名のつくもの全てが糞なんだよ。きっとOODで開発
してないんだろうなって思う。

37 :仕様書無しさん:2007/02/20(火) 05:43:36
>>34
まだ、そんな現実に即してない理想論いうボーヤがいるのか?
会社で仕事してからこいよw

>設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。
この1文だけでかなり大きな矛盾を抱えている
まず、設計と実装、テスト、保守をする人間がそれぞれ別であること。
この状態で設計の時間だけ多くとって実装〜テストにかかる時間を削ってそれで誰が納得できるだろうか?
しかも、それもどのくらい設計に時間をかければ、どのくらい実装〜テストの時間を抜いていいという基準が無い。
単純に設計にかける時間を2倍にしたら、実装〜テストの時間は2分の1でいいのか?という問いに答えられなければ
現実、どうであろうがビジネスの場では意味が無い。

>設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。
それとこの1文にはまだある。
設計を丁寧にやるといっているが、丁寧にやったところで実装で覆る場合は少なくない。
これは完全に設計担当者の腕による。
場合によっては設計に時間をかけるだけ無駄になる場合も少なくない。
それとそもそもこの1文が常に真である保障も無ければ、高い確率で真である証明もできない。
そういう場でその設計が正しいかどうかを判断する方法として一番手っ取り早い方法は実装をしてみることである。

俺の感覚では実装をするコストは設計でおきるかどうかわからない不具合を想定してるコストよりも
はるかに少ないと考えるがそこはどうか?

38 :仕様書無しさん:2007/02/20(火) 08:45:40
>>37
金魚にエサをあげて
まで読んだ

39 :34:2007/02/20(火) 08:52:13
>37
真面目に論じたいなら煽り文入れるなや。

 昔ながらのウォーターフォールでも、手戻りが後工程になってから
起きるほど工数がかかるってことはよく知られてるだろう。
そこから自然に導かれることだ。
よく設計が練られてるほど、手戻りの生じる確率は低いことが期待できるからな。

 それと想定してる前提が幾つか私と食い違ってるみたいだな。
設計者=実装者=保守担当者の前提で考えてたよ。異なる現場ってそんなにある?
結合テストには別の人間が欲しいところだが。

 設計担当者の腕が大きく影響するのはそのとおりだが、
上述したように実装者と同じ人間が担当するならこうなる。
設計:図を描きながらプログラムの枠組みをコーディング
実装:前段階で作成された枠組みの中身の部分を詰め込む
みたいな感じ。
 こういう場合だって枠組みがきちんとできる前に中身を詰め込んじゃうと、
枠組み変更した場合に無駄になることが多い。

40 :34:2007/02/20(火) 08:54:49
あー、ひょっとして「設計」って全然違うものをイメージしてるのかな?

41 :仕様書無しさん:2007/02/20(火) 09:29:58
>>26
お前が知って4年だろ?w

オブジェクト指向自体は既に10年以上前から知られてるし。
言語レベルで実運用に耐えられるC++が出て既に何年だよ。


42 :仕様書無しさん:2007/02/20(火) 10:04:23
「設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。」
これこそがウォーターフォール的な発想じゃないのか?

43 :仕様書無しさん:2007/02/20(火) 10:50:12
>>42
だな。仕様や要求が変わって、何回も設計を手直しすることを前提にするからこそ
汎用化して切り分けよう、という考えがOOだもんな。

44 :仕様書無しさん:2007/02/20(火) 11:07:57
>>41
今年はオブジェクト指向紀元45年なんですが。
>言語レベルで実運用に耐えられるC++が出て既に何年だよ。
「出てから何年」ではなく多数の人間が使うようになってからの年数で考えるべきかと。

45 :仕様書無しさん:2007/02/20(火) 11:13:37
>>44
じゃ、VC++ 1.0 からでいい?

46 :仕様書無しさん:2007/02/20(火) 11:22:51
OOP言語の登場と、OO開発の一般化の話は同じに考えちゃマズイでしょ。

OOP言語なんて半世紀近く前から登場している。

なのに、現在でもOOP言語を使って手続きプログラミングしてるのは何故かってところじゃない?

1.OOが理解できない
2.今まで長年手続き型コーディングしてきて、この方法で実装できることは分かっているから変えるつもりはない
3.OOPなんてのは妄想だ。継承だポリモーフィズムなんてのは実業務においては幻想に過ぎない
4.設計書が手続き型で設計されている(設計者がOO知らない)
5.データと処理は分離したほうが理解しやすい。データが処理を持つはずがない。


47 :仕様書無しさん:2007/02/20(火) 11:24:46
>>44
多数の人間が使えるようになるまで後何年かかるのだろう・・

設計する人って何書いてんの? UML? それともコード自体が設計?

48 :仕様書無しさん:2007/02/20(火) 12:00:02
>>1の参考ページより引用

オブジェクト指向では、データベースは単なる記憶装置に過ぎません。
極端な場合、データベースのデータをそのままメモリにオブジェクトとして取り込み、メモリ上ですべてを実現します。
オブジェクト指向の人にとってはエンティティクラスがドメインの中心であり、DBは永続ストアで陰に隠れています。

データ中心指向では、データベースを中心に考え、SQLで実現できるロジックはすべてSQLで実現します。
そのため、プログラムで使用するオブジェクトは、ユーザインターフェースとの受け渡し、処理用のテンポラリとして使ったり、
キャッシュとして使い、あくまでも補助的な位置づけになります。データ中心指向の人にとってエンティティはDBそのものであり、
エンティティクラスを作る必要はほとんどありません。

後者で設計するシステムだったらOOP言語なんて要らないな。

俺の周りの設計者(経験豊富とされるオッサンが多い)はみんな後者の設計方法だな。
処理とデータは分けてデータはDBに入れとく。

で、俺が「こんな情報がほしいときは?」と聞くと、「SQLでこのカラムとこのカラムを紐付けて、これを条件にしてひっぱってくればいい」と答える。
OOPならエンティティに尋ねて取得するのが正解なはずなんだけどね。

49 :仕様書無しさん:2007/02/20(火) 12:08:33
とりあえず引用文の前半と後半で口調が変わってるのは理解できた。

50 :仕様書無しさん:2007/02/20(火) 12:09:10
>>49
後半は俺の意見だw

51 :仕様書無しさん:2007/02/20(火) 13:07:44
>>48
で、貴方はオブジェクト指向、データ中心志向どちらが便利だと思ったの?


52 :仕様書無しさん:2007/02/20(火) 13:16:04
OOP知らない奴が中途半端にOO使うからやっかいなんだよ。
OO否定する奴は一切使うな!大きなアプリケーションクラスだけ作って、
後は全部スタティックに宣言すればいいじゃね? 
まぁどうせならOOの成果物(コンポーネント等)もいっさい使わないぐらい
の根性欲しいけど。

53 :仕様書無しさん:2007/02/20(火) 13:28:51
俺が設計するときには、ドメイン設計からやってるな。クラス図がすべて。

オブジェクトの永続化先は全件メモリ上に展開して問題ないなら基本はXML。
永続化したオブジェクトを検索したりする必要がある場合にはDBに永続化してる。

54 :仕様書無しさん:2007/02/20(火) 16:02:33
この世のオブジェクトって有限じゃん?
みんなでオブジェクト設計して、共有するようになったら、
そのうち設計するオブジェクトが無くなっちゃうねぇ。
オブジェクト設計者失業ケテーィwww

55 :仕様書無しさん:2007/02/20(火) 16:49:06
>>53
純粋な質問なんだけど、
設計時ってどこまでクラス設計する?
俺は基本クラスとインターフェースくらいしか書かないんだけど
全部設計してからPGに渡したほうがいいのかなあ。

56 :仕様書無しさん:2007/02/20(火) 17:12:48
>>53ではないが、
基本クラスとインターフェースだけ設計することにどんだけの意味があるのだろう。
それって表面だけ設計して、後の面倒毎や辻褄合わせはPG任せってこと?
投げっぱなしじゃなくて、その後のフォローがあるなら別だが。

57 :仕様書無しさん:2007/02/20(火) 18:05:22
>>56
コンポーネント設計なら、インタフェースとデータだけ設計したら実装は
PGまかせってのはあるかも知れないが、手続きで実装されたら意味ないでしょ?

各永続エンティティが、属性とメソッドを持つクラス図が仕様書だよ。
メソッド内はご自由に実装どうぞかな。

IFはドメイン操作クラス用に切る。

58 :仕様書無しさん:2007/02/20(火) 18:20:07
エンティティの属性とメソッドしか書かないの? DB設計書とたいして変わんなくない?
クラス間の依存関係とかシーケンス図とかは? 
手続きで実装されないためには、そっちの方が重要な気がするが。

59 :55:2007/02/20(火) 18:38:50
>>56-57
基本のクラスとインターフェースを作ってあげれば
後は各機能を実装するには適切な基本クラスを継承して差分を書けばいいから
いいかなあ、と思ってさあ。

自分がPGやるときに細かいクラスまで全て設計されてたらやりたい実装が出来なくて
困ることもあるなあ、と。
だから一応SEやるときはPGの手足まで縛らないようにしたいなあ、という考えだったんだけど、、、

やっぱ間違いかなあ。

60 :仕様書無しさん:2007/02/20(火) 18:39:16
基本設計時には要件から抽出したオブジェクトに対して、
コントローラから線が引かれる分析レベルのシーケンスが出来上がる。

この時点では、当然処理が流れるかどうか確認するだけなので永続化に関する概念は不要。

しかし詳細設計時になって初めて永続化の概念が出てくる。
だけどこれは「どうインスタンスを永続化するか」、「どう永続化したインスタンスを取得するか」くらい定義しとけばいいはず。
Persisterクラスにエンティティ渡して永続化するんですよ。とか。

シーケンス図上では、画面のボタンが押されてからオブジェクト操作して永続化するまでだと思う。
あとはPGがエンティティのインスタンスを(オブジェクトグラフごと)DBにマッピングして保存してくれればいい。
通常は楽するためにORM使うけどね。

61 :仕様書無しさん:2007/02/20(火) 18:46:52
>>59

その考え方は正しい。
ただし基本クラス継承して差分実装させるのはコマンドパターンを考えるとき。
つまり実装をパターン化したいというフレームワークを実装するときの考え方かな。

OOだと、エンティティ同士がお互いに細かく関連、依存し合って、
それぞれ実装すべき処理も異なるからAbstractMethod化は難しいかもしれないねぇ


62 :仕様書無しさん:2007/02/20(火) 19:15:24
ドメインの一部のエンティティになら
AbstructMethodパターン使えると思うけどな。



63 :仕様書無しさん:2007/02/20(火) 19:17:23
誰か「オブジェクト指向とは!」でまとめろ。
このスレが混乱してるように現場も混乱してる。
そんな考え方なんか採用してまともに仕事できんだろ。

64 :仕様書無しさん:2007/02/20(火) 19:21:49
オブジェクト指向とは!
どうぞ、↓

65 :おじゃばさま:2007/02/20(火) 19:27:49
まず初心者が陥りやすい問題としては、オブジェクト指向を機能設計に適用しようとする事だ。
オブジェクト指向は詳細設計/コーディングに適用する物だが、オブジェクト指向をマスターしたての頃は、
機能設計にも適用出来るのではないかと思えてしまう。そして実際にやるとそれなりに出来る。
しかし他人が見ると理解困難な上に、多くの場合、無意味な拡張性があったりする。
これはなぜかと言うと、以前に野球選手や消費税計算をオブジェクト化して失敗した例を見てもらえば
分かると思う。

次にオブジェクト指向をソフトウェア工学に適用しようとする者もいる。
まあ気持ちは分かる。しかし意味はない。XPもスパイラルもオブジェクト指向とは関係ない。
XPやスパイラルはプロトタイプ方式から出た物で本質的に変わりがない。
そしてプロトタイプ方式は「新しい物を開発するのに優れた手順」であり、ソフトウェア以外でも
使われている古い方法である。

ましてやオブジェクト指向が、オンメモリかどうかなどは関係ない。
オブジェクトが永続であろうが、非永続であろうが、スタティックであろうが、オブジェクト指向とは
関係ない。


66 :おじゃばさま:2007/02/20(火) 19:32:27
オブジェクト指向とは「データと処理のグループ化」である。

本では継承やカプセル化、ポリフォーリズムやインタフェースなどの言葉が出て来るが、
それは「データと処理のグループ化」の方法やそれによってもたらされた効果であり、
その本質ではない。


67 :仕様書無しさん:2007/02/20(火) 19:41:39
そんな抽象的な説明いらない。
実務(例えば業務アプリ)にどう使えばいいのか、どう適用すればいいのか。
について具体的に説明してくれ。

68 :仕様書無しさん:2007/02/20(火) 19:42:47
俺の頭では結局何を言いたいのか分からんが、
ポリフォーリズム って何だろ音楽用語かな。

69 :仕様書無しさん:2007/02/20(火) 19:43:32
「データと論理のレイヤー化」
のほうが正しいと思うけど。

70 :仕様書無しさん:2007/02/20(火) 19:50:06
>>66
ちゅーことは、OOやるには、構造体にデータと関数ポインター
いれとけばいいっちゅうことか。


71 :仕様書無しさん:2007/02/20(火) 19:53:48
俺の認識

サービス層でユーザー要求を受け付ける

サービスはオブジェクトに答えを求める

オブジェクトは自身の属性や関連をもとにして結果を返す

サービスはその結果を返す。

だと思うけどな。

サービスがエンティティ数だけ繰り返しや比較ロジックを持ってはならない。

認証機能がいい例だ。
パスワード属性を知っているのはユーザーエンティティなのに、
ユーザーエンティティからパスワードだけ取得してパスワード比較をサービスでやることが多いだろ?
OOで考えればユーザーに聞けば済む話じゃん。



72 :仕様書無しさん:2007/02/20(火) 19:59:42
>>68
一応マジれす。
×ポリフォーリズム って何だろ音楽用語かな。
○ポリモーフィズム

73 :仕様書無しさん:2007/02/20(火) 20:00:12
>>71
いきなり「層」とか使うな。
ユーザーに分かる言葉で説明よろ。

74 :仕様書無しさん:2007/02/20(火) 20:09:22
>>73
なんでユーザーに説明せにゃなんねんだよ。

75 :仕様書無しさん:2007/02/20(火) 20:10:44
>>73
http://www.atmarkit.co.jp/fdotnet/architecture/aafn02/aafn02_01.html

ここ読め。

76 :仕様書無しさん:2007/02/20(火) 20:17:56
オブジェクト指向の全体図は知らん。
知らんが、部品は便利だ。
ドメイン?なんじゃそりゃ。
エンティティ?DBのテーブル設計のことだろ?
クラス・インスタンス・カプセル化、ここらへんしか知らんが、
それで不便だと思ったことは無い。知識不足は認識しとるけどな。

具体性が必要なデスマ場に、
抽象的な考え方なんかは邪魔だ。

77 :仕様書無しさん:2007/02/20(火) 20:19:24
>>65
ソフトウェア工学ってXPとかスパイラルのことだっけ。
そういった開発プロセスとか、OOPとかデザパタとかもひっくるめた
もっと全般的なものかと思ってた。違うのかな、なんか混乱してきた。



78 :76:2007/02/20(火) 20:19:26
>>75
おまぃ、いい奴だな。
ちょっと学習してみる。

79 :76:2007/02/20(火) 20:26:52
リンク先、挫折。
用語の洪水におぼれたぞ。
こっちが頑張ろうと思っても辟易してしまう。
ここまでして覚えなきゃならんのか疑問だ。
つか、リンク先を理解できるおまぃらすげーよ。

80 :仕様書無しさん:2007/02/20(火) 21:14:36
パスワードが正しいことを検証するのはシステムで認証を行うからで
認証サービスになるんじゃねぇのか

OOで考えればユーザーに聞けば済む話じゃん。って
認証するのはユーザーじゃなくてシステムだろ

81 :仕様書無しさん:2007/02/20(火) 21:40:54
結局、層をかぶせる従来のやり方が最強
または、業務システムならデータフローがあれば事足りる
オブジェクトが必要なシステムは、オブジェクトが必要

オブジェクトが存在しないシステムに無理にオブジェクトを抽出してもうまくいくはずが無い
オブジェクト指向は画面とかを作ったり
コンポーネントを作るのには向いている

だが、それ以外は向いてない


82 :仕様書無しさん:2007/02/20(火) 21:43:44
>>80
その考えだと、エンティティにはもはやアクセッサ以外のメソッドは不要
だね。・・・って俺釣られたのか? 判断が難しいスレだよぉ。

83 :仕様書無しさん:2007/02/20(火) 21:44:11
>オブジェクトが存在しないシステムに無理にオブジェクトを抽出してもうまくいくはずが無い

単なる整理整頓のやり方なんだから臨機応変にアサインすればいいんじゃないのか

84 :仕様書無しさん:2007/02/20(火) 21:50:58
>>65
何故、ただの構造的な側面を、あたかもそれだけがOOの本質であるかのような書き方をする
のだろう。しかも言葉の理解や使い方を間違っているし。データと処理のグループ化などOO以
前から行われていたことだ。今や習いたてのプログラマが理解する概念だ。
オブジェクト指向の本質は月並みだけど、やはり、継承、ポリモーフィズム、カプセル化だよ。そ
して、これらが適切に活用されていないところで問題が発生している。それは何故か?
物事を抽象化する能力が未熟だからだ。データと処理のグループ化のみに捕らわれていては
全時代的なプログラミングとたいして変わらない。OOに習熟するためには、もう少し引いた目で
全体を俯瞰し物事を捉える能力を養う必要がある。

85 :仕様書無しさん:2007/02/20(火) 21:56:23
ユーザーは認証されるのであって認証するのではない

認証の主語はユーザーではない

システムがユーザーを認証する

86 :仕様書無しさん:2007/02/20(火) 22:00:30
OOを否定している香具師は手をあげて。

87 :仕様書無しさん:2007/02/20(火) 22:17:16
>>85
ユーザはパスワードを保持している。← これ前提ね。

システムが「このパスワードはあなたのパスワードと同じものですかぁ?」と
ユーザに問い合わせる。

ユーザは、「そうですよぉ」又は「違ぇよヴぉけ!」と
答える。

システムは、「了解、後はこちらで処理しときます。」と
結果を処理する。

これが普通の考え方。

88 :仕様書無しさん:2007/02/20(火) 22:17:52
お前のは、

システムが「ユーザーさん、ちょっとあなたのパスワードを教えてください。」と
ユーザに要求する。

ユーザは、「あいよっ」て差し出す。

システムは、ユーザのパスワードと、手元のパスワードを照合する。

結果を処理する。

って考えだろ。

これで、例えば、認証のために、ユーザーの住所とか生年月日とかも必要に
なったとしたら? 前者の場合は外面のロジックは弄る必要がない。お前の
考えだと、システムにいろんなロジックが集中しちまうことになるっていうのが、
感覚的に理解できてない時点でお前はOOに向いてない。

89 :仕様書無しさん:2007/02/20(火) 22:26:11
>>87-88
要約すると、
世間的には後者のやり方が一般的かもしれないが、
実は、OO的には前者の方が正しい。

といいたいのか?


90 :仕様書無しさん:2007/02/20(火) 22:26:54
>>65-66
>陥りやすい問題としては、オブジェクト指向を機能設計に適用しようとする事だ。
>オブジェクト指向は詳細設計/コーディングに適用する物だ

もしかして、これって相当正しい見解だと思うよ

実現したい機能はあくまでも要求を合理的に機能面から検討して推奨する方向や
現実を考慮してより便利で価値あるものにするための設計のはずだと思う

そこにメンテナンス性や開発の効率性などを考慮して「OO設計による実装をする」
のだと思った

やはり求められ、かつ実現するべき機能は、その開発方法とは本来は別次元のもの
だったという正論に一票を入れたいと思う!

91 :仕様書無しさん:2007/02/20(火) 22:29:06
>>88
>お前はOOに向いてない。
向き不向きだけで考えたら、向いてない人ばっかりな気がするが

みんな頑張ろうぜ。
始めてプログラムを組んでみようとしたあの日、みんな頓珍漢だったろ。

92 :仕様書無しさん:2007/02/20(火) 22:33:07
適切な項目を適切な場所ですることに何の問題が?

ユーザーの住所とか生年月日とかも必要に なったとしたらユーザーオブジェクトがidとpassでも渡す設計か?
それこそインターフェイスが変わるだろうがよ

システムサービスのインターフェイスが変わるんだろ
最低だな

ユーザーのログインとかのメソッドならばまだわかるが
その場合でもあくまでシステムが認証する

システムサービスの認証機能に移譲する形でログインの実装だな
システムサービスのインスタンスはユーザーにインジェクションする

93 :仕様書無しさん:2007/02/20(火) 22:33:55
>>90
> >オブジェクト指向は詳細設計/コーディングに適用する物だ
> もしかして、これって相当正しい見解だと思うよ

こういう部分に於いては、オブジェクト指向はうまく普及していると思うよ。

94 :仕様書無しさん:2007/02/20(火) 22:34:24
idとpassだったインターフェイスを
idとpass、住所とか生年月日にとかの

95 :仕様書無しさん:2007/02/20(火) 22:34:50
>>89
ちがうよ、一般的にもOO的にも前者の方が正しいの。

ただ、例えば認証するのにユーザだけじゃなく他のオブジェクトにも情報
を問い合わせないといけないというような場合には、ユーザに認証を任せ
るわけにはいかないので、認証用のオブジェクト(ファサードパターンっ
ていったりする)にロジックを集中する場合もあるけど、この場合は単純
だから上の前者の例が一般的。

96 :仕様書無しさん:2007/02/20(火) 22:36:16
話の途中ですまんが
前者ってどれのことを言ってるんだ???

97 :仕様書無しさん:2007/02/20(火) 22:36:53
>>94
認証情報クラスを引数にしてたらの話。細かいことつっこむなよ。

98 :仕様書無しさん:2007/02/20(火) 22:38:27
>>96 あぁすまん、前者=>>87 で言ってることね。

99 :仕様書無しさん:2007/02/20(火) 22:40:49
CHAPかPAPか。

100 :仕様書無しさん:2007/02/20(火) 22:46:03
iocぐらい知っとけよ

101 :仕様書無しさん:2007/02/20(火) 22:51:30
>>100
国際オリンピック委員会

102 :仕様書無しさん:2007/02/20(火) 22:53:51
>>95
>>87の例、俺的に目から鱗。コロンブスの卵だった。
あ、そうか。と一瞬おもたんだよ。

普及しているのが>>88の方式なのは、セキュリティの都合に合わせているだけなんだろうな。

103 :仕様書無しさん:2007/02/20(火) 23:04:38
サービス層の概念がない87のほうが問題だと思うんだが

SOAとか切り出す単位をそれでどうするんだ

インジェクションとかVisitor等で実装

ユーザーのログインの呼び出しは実装を知らない限り
87にちかいフローに見えるだと思うんだが

87のいってることも結局主語はシステムだしな

104 :仕様書無しさん:2007/02/20(火) 23:12:00
結局おまぃら、
「オブジェクト指向とは!」
なんなんだ?
傍から見てるとちっとも認識が合ってるようには見えん。

105 :仕様書無しさん:2007/02/20(火) 23:15:37
ちょくちょく出てきてる委譲の概念、IOCが>>95にない気がする

IOC(Inversion of Control)
http://jakarta.jp/hivemind/ioc.html

サービスに委譲する実装てなだけであって
OO的には問題ないと(個人的にはこっちのほうが変更に強いかなと)

106 :仕様書無しさん:2007/02/20(火) 23:21:47
パスワード比較をユーザーで行う 後者
パスワード比較をシステムで行う 前者

の認識であっとる?

107 :仕様書無しさん:2007/02/20(火) 23:27:18
1.ユーザーがシステムにログインを試みる
2.システムがユーザーの認証を行う
3.ユーザーはログイン結果をシステムより取得

よって認証責任はシステム

108 :仕様書無しさん:2007/02/20(火) 23:30:17
オブジェクト指向がどうたらってのはどうでもよくて、
書いた設計書が理解すべき人間に
理解されなければただのごみだよな。
それを平易なものに書き直す必要がどっかで出るわけだ。
UMLなんか出されてもエンドユーザーからは
「こんな分かりにくい資料は無意味」と一蹴される。
オブジェクト指向のルールも一定のものが無く(あるのかもしれんが)、
小難しい話の応酬で、本来すべき作業がちっとも進まない。

こんなの流行るわけねーだろ。

109 :仕様書無しさん:2007/02/20(火) 23:31:50
>>103
すまん、フロはいってた。
なんでいきなりサービス層とかSOAの切りだしの話がでてくるのか分かんない
んだけど、もしかして最初から想定している状況が食い違ってていたのかな。
だとしたら誤る。すまん。

俺が話していたのは、処理をどのオブジェクトが受け持つかという委譲の話。
パスワードの妥当性の検査はその属性をもっているユーザオブジェクトに受
け持たせて局所化した方がいいだろうということ。パスワードの妥当性の検査
の話よ。認証自体はそりゃ認証サービスが最終的な責任をもつべきだろうよ。

例えば、別のサブシステムで、同じようにパスワードの妥当性の検査を組み込
む必要がでてきた場合に、ユーザーオブジェクトに実装してあれば、ユーザー
クラスをサブシステムに持っていけばいい話だが、その外側のクラスでパスワ
ードの検証をしていたら、ユーザークラスの他にその外側のクラスももっていか
なきゃなるだろって話。IOCのことは全然考えて無かったよ。

110 :仕様書無しさん:2007/02/20(火) 23:36:29
>>109

妥当であると判断するのは認証サービスでないの?

111 :仕様書無しさん:2007/02/20(火) 23:39:43
認証認可はオブジェクトではなく横断的関心事としてひとまとめにするのが吉
世間の常識

112 :仕様書無しさん:2007/02/20(火) 23:44:46
>>108
不勉強を呪え

113 :仕様書無しさん:2007/02/20(火) 23:45:41
ユーザーに認証サービスがインジェクションされるほうが
他システムに持ってけると思うんだがどうよ

おんなじ認証なら同一のものをインジェクションすればいいし
認証方式が違うのであれば認証インターフェイスの違う実装をインジェクションすれば

>111のいうように認証における横断的関心事ひとまとめにしたのが認証インターフェイスになると

114 :仕様書無しさん:2007/02/20(火) 23:45:41
>>110
問い合わせてきた利用者に認証結果を返すのは、認証サービスだろうね。
ただその認証結果を判断するプロセスの一つとして、ユーザーオブジェ
クトにパスワードの妥当性を問い合わせるというプロセスがあるの。
サービスクラスで、
if(pw.equals(user.getPassword()) {〜 てやるか、又は
if(user.isValidPassword(pw)) {〜  ってやるかってこと。
で、俺は後者の方がいいだろっていってんの。単純にいうとそんだけの話。
別にこれは認証に限った話ではなくて、一般的に処理をどこに受け持たせる
かという話。あ〜、なんか話が食い違ってるな。いつのまにかAOPの話になっ
てるし。

115 :仕様書無しさん:2007/02/20(火) 23:47:47
>>108
エンドユーザーの不勉強を呪ってどうするんだよ。

116 :仕様書無しさん:2007/02/20(火) 23:52:44
if(user.isValidPassword(pw)) {〜
なんでユーザーに正しいパスワード通知する実装になるんだ?

認証サービスが正しいパスを放り込んでくるのは
機能設計時点でアウトだろ

117 :仕様書無しさん:2007/02/20(火) 23:55:25
>>116 とか
スレ違い。よそでやれ。

118 :仕様書無しさん:2007/02/20(火) 23:55:44
>>116
機能(セキュリティ・認証)ではアウトでも、
構造としては面白いとおもうんだが。

119 :仕様書無しさん:2007/02/20(火) 23:55:46
>>116
いや、だから俺が話してんのは認証サービスに限った話ではなくて、
メソッドは、そのメソッドを処理するのに必要な情報を保持している
クラスにやらせるのがいいだろうという話をしてんの。
SOAはおいといてくれ。

>なんでユーザーに正しいパスワード通知する実装になるんだ?
これはすまん意味がわからん。

120 :仕様書無しさん:2007/02/20(火) 23:56:09
機能(もしくはその一部)をオブジェクトとして捉えているのと
エンティティのみしかオブジェクトとして捉えていないやつの違いだな

121 :仕様書無しさん:2007/02/21(水) 00:02:27
ぃい奴がオブジェクト指向の話に持っていく

例え話をする奴が出現する

突っ込みが入る

以下無限ループ

122 :仕様書無しさん:2007/02/21(水) 00:05:34
>>119
メソッドは、そのメソッドを処理するのに必要な情報を保持している
クラスにやらせるのがいいだろう

処理を(処理を実装するオブジェクトのメソッドを呼び出すことで)委譲する
ということで「クラスにやらせる」を満たしているとはみなせんか?

オブジェクト指向の委譲についてってことで

123 :仕様書無しさん:2007/02/21(水) 00:08:59
>>120
なんの制約も無きゃドメインモデルが一番いいのは当然として、
現実問題ドメインモデルはアーキテクチャとのすり合わせがいろいろ大変だよってのが現状。

124 :仕様書無しさん:2007/02/21(水) 00:10:25
セキュリティがどうこうじゃなくて単純に、ユーザーオブジェクトのほうがシステムオブジェクトより
一般的というか普遍性が高いから、ユーザーオブジェクトに認証ルーチンを持たせるのは良くない
設計ってことじゃないの?

125 :仕様書無しさん:2007/02/21(水) 00:14:24
機能面として実装しえないものを論じ合っても仕方ない。
ユーザーがシステムに問い合わせをする。
これが大前提。
システムが口を開けて待ってる、ってのはシステム論。

126 :仕様書無しさん:2007/02/21(水) 00:15:49
>>122
すまん、よく分かんないんだけど、
例えばよ、まぁまた例え話になっちゃって申し訳ないけど、
パスワードの認証のために、パスワードの暗号化とか妥当性の検査とか
するのに 10行ぐらい書かないといけないとすると、いちいちそんな処理を
認証サービスに書くんじゃなくて、いったんユーザオブジェクト(処理に
ひつような属性は保持しているわけだし)に書いとけば、あとはどこでも
そのメソッドを呼ぶだけで妥当性の検査ができちゃうだろっていうことを
いいたいだけなのよ。別に難しいことをいってるわけじゃない。そして
これは別にパスワードの妥当性検査(認証処理じゃないよ)に限らず一般
的じゃないのというだけの話。

以上。ちょっと用事あるんで離席する。

127 :仕様書無しさん:2007/02/21(水) 00:17:52
>>ユーザーがシステムに問い合わせをする。
このユーザーとユーザーオブジェクト(エンティティ?)は別物だよねぇ。

128 :仕様書無しさん:2007/02/21(水) 00:20:28
オブジェクト指向って、結局なんなの? (´д`)

129 :仕様書無しさん:2007/02/21(水) 00:24:38
>>128
立体プログラミング

130 :127:2007/02/21(水) 00:25:12
>>128
あなたが理解していないことはよく分かりました(T T)

131 :128:2007/02/21(水) 00:26:33
>>129
全然わかりませぬ・・・

132 :仕様書無しさん:2007/02/21(水) 00:27:07
え〜、俺>>127だけど >>130は↑は俺じゃないよ〜

133 :仕様書無しさん:2007/02/21(水) 00:32:05
>>129
言いえて妙だな

134 :128:2007/02/21(水) 00:33:20
調べた。
エンティティ=クラスのことか〜。
そういえばいいのに〜。

135 :仕様書無しさん:2007/02/21(水) 00:41:34
エンティティ=クラス って... 本当に調べたのか?
たしかにクラスがエンティティな場合もあるが...

136 :仕様書無しさん:2007/02/21(水) 00:48:15
エンティティじゃないクラスもいっぱいあるぞ。

137 :仕様書無しさん:2007/02/21(水) 00:50:03
エンティティクラスはテーブル、エンティティのインスタンスはテーブルレコードと考えられる。


138 :128:2007/02/21(水) 01:04:38
「オブジェクト指向でなぜつくるのか」を全部読んだけど、
エンティティなんて言葉は出てこなかった・・

http://e-words.jp/w/E382A8E383B3E38386E382A3E38386E382A3.html
ここも辞書なのに中途半端なこと書いてるし・・・

エンティティってなんなんだぁぁあ( TДT)

139 :128:2007/02/21(水) 01:06:45
>>135-137
な、謎が深まる(ノД`)シクシク

140 :仕様書無しさん:2007/02/21(水) 01:11:08
>>139
まぁ大雑把に言えば、エンティテイ=クラス という理解で問題無いと思うけど、
俺の感覚的なイメージからすると、クラスの中でも永続化の対象となりそうなク
ラスかな。つまり、DBのテーブルと対応付けられるようなクラスのことかな。

141 :仕様書無しさん:2007/02/21(水) 01:22:15
>>128
そのうち理解できるようになる(かもしれない)から泣くな。
オブジェクト指向を端的に定義できるならば
こんなに長い間、沢山のスレが立つわけないだろ。
「民主主義とは、日曜に体育館や公民館に投票しに行くことだ」
という低レベルな理解で判った気になっていればそれでよいのだ。
自分の理解?。自分の理解は低レベルだから書かない。

142 :128:2007/02/21(水) 01:31:58
>>139-140
エンティティ=各テーブルのクラス・インスタンスでOK?
な、何かが違うような気がする・・。・゚・(ノД`)・゚・。ウエエェェン
現場でC++やJavaをやってて、
SJC-Pに合格してても未だに分からない(´・ω・`)
言語を把握しててもスレを見ると
オブジェクト指向が理解できてない、
っていう気持ち悪さがなんとも・・・

143 :仕様書無しさん:2007/02/21(水) 01:38:08
オブジェクト指向というのはつまりこうなんだ
「くだらない仕事なんかさっさとかたして、お家に帰ろう!」
この思いが強ければ強いほど、オブジェクト指向が身につく!
仕事好きで、いつまでも帰らない人、家に持ち帰ってまで仕事をする人
趣味の無い人をよく観察してみてください
彼らはオブジェクト指向を全然理解していないし、これからも理解できません

144 :仕様書無しさん:2007/02/21(水) 08:13:13
クラスってのは型とメソッドをあわせたもの。
ただ型を定義するのはインターフェースクラスだけの仕事で、
実装クラスの型は言語上の便宜的なもんなので設計段階でいっしょにしないように。

145 :仕様書無しさん:2007/02/21(水) 08:22:47
>>1
Javaイコールコポルの位置づけ
大手ポータルはPHP技術者を募集しているJavaの案件も多少あるが全体の5%程度
ではJavaはどのフィールドで生かされるか、基本的に生かさない。
SIerがこれからはコボルの代わりにJavaですよと営業布教しているだけ。
よって金融系でよく利用される。
SQLをEJBで操作しようとして大失敗したEJB1.0がその根拠

結論 コポラーがやるからオブジェクト指向設計はいらない。だから普及しない。
これからもしない。
Javaをやっている事で「おれたちオブジェクト指向やってるもんね」のような
自己満足で簡潔し閉じて終了。

ここで語っている人は業務プロセスの専門職ばかり。これだけもめるのも
潜在的にSQL業務処理をどうするのかに焦点がフォーカスされているため。

146 :仕様書無しさん:2007/02/21(水) 08:32:57
データ入れとく箱用のクラスと、処理用のクラスとに分けるんじゃなくて
データと処理を一緒のクラスにしましょうねというのがオブジェクト指向。

生存期間を伸ばすためにオブジェクトの属性値だけDBに入れて永続化する。
読み込む時は読み込み先のクラスはメソッドいっぱいもってるクラスになるわけですよ。

そうすれば読み込んだクラスのメソッドはすぐに使えるでしょ。
DAO、DTOとは違う考え方になります。

147 :仕様書無しさん:2007/02/21(水) 08:54:53
おはよう、おじゃばさん

148 :仕様書無しさん:2007/02/21(水) 09:02:29
>読み込む時は読み込み先のクラスはメソッドいっぱいもってるクラスになるわけですよ

まちがいなくジャワVMが悲鳴をあげてフルgc状態にはいりますね

149 :仕様書無しさん:2007/02/21(水) 09:38:31
>>146
静的なクラス図だけ見てプログラムの全体図を見た気になるのは
生き物の分類図だけ見て自然のダイナミズムを見た気になるのと一緒

てGoFに書いてあった

150 :仕様書無しさん:2007/02/21(水) 10:10:53
超大量のすべてのレコードをインスタンス化するのはアホ。
レイジーロードと一緒に使う。

151 :仕様書無しさん:2007/02/21(水) 10:12:33
>>126
普通「認証ロジック」って、IDやパスワードの妥当性の他に
どのアクセス権限があるかとか、社内接続かどうかとか、色々入るじゃない。
そーいうのも全部ユーザクラスに書いたほうがいいの?

システム「このパスワードはあなたのパスワードと同じものですか?」

ユーザ「はい、そうですよ」

もOOだと思うんだけどさ、「責任の分担」ということで考えたら

ユーザ「あの、ログインしたいんですけどいいですか」

認証サービスセンター受付「わかりました。そこに座ってお待ちください」

認証サービスセンター受付「ログイン終わりました。ハイこれ会員証。これアクセス権限許可書。これが社内接続交付書ね。」


というのはOOではないの?

152 :おじゃばさま:2007/02/21(水) 10:13:17
>67
まずStrutsのデータビーンを参考に、構造体をクラス化するといい。

>77
ソフトウェア工学と言うのは、ソフトウェアを「いかに高品質で安く作れるか」を研究した物である。
大抵は開発手法の話である。

>84
では「継承、ポリモーフィズム、カプセル化」が何のためにあるかを考えた事はないか?
ちなみに構造化プログラミングも同様に、手段と目的が曖昧になっている人もいる。
あと構造化定理を使えば構造化プログラミングな訳ではないから、間違えている人は気をつけた方がいい。

どうしてもオブジェクト指向を視覚的に説明したい人は、Windowsのウィンドウを例に説明するとよい。


153 :仕様書無しさん:2007/02/21(水) 10:16:15
Struts(笑)

154 :仕様書無しさん:2007/02/21(水) 10:39:15
>構造化定理を使えば構造化プログラミングな訳ではないから、間違えている人は気をつけた方がいい。
構造化定理というのは単に論理を構造化するための理論的な背景だぞ。
それをいうなら
「構造化構文を備えた言語を使えば構造化プログラミングな訳ではない」だろ。
まったく「間違えている人は気をつけた方がいい」な。

155 :仕様書無しさん:2007/02/21(水) 10:41:01
ジャワでSSL使うと遅延してよくタイムアウトするけど
ここにいるやつらのようなお馬鹿タンたちが重々しくなるように設計してる
からなんだなあと納得した。

156 :仕様書無しさん:2007/02/21(水) 11:04:19
>>151 なんでもっと柔軟に考えられないんだよ、
その目的のための情報をユーザオブジェクトが全部もってればユーザオブジェクト
でやればいいだろうし、そうでなければ、認証を受け持つ役割のオブジェクトがやれ
ばいいだけの話だろ。ただ認証プロセスの一つであるパスワードの照合はユーザ
オブジェクトでやらせればいいんじゃないの? という話でしょ。
ユーザ認証という機能レベルの話しと、パスワードの照合という粒度の細かいメソッド
レベルの話をいっしょくたにしているから、話がかみ合ってない。

157 :仕様書無しさん:2007/02/21(水) 11:21:29
>>155
>重々しくなるように設計してる

これMSにも言うべきだろ
あの重さは尋常じゃない、OOPのくだらない弊害はあまりに大き杉w

158 :仕様書無しさん:2007/02/21(水) 11:35:50
>ソフトウェア工学と言うのは、ソフトウェアを「いかに高品質で安く作れるか」を研究した物である。
ソフトウェア工学の対象事物は確かのソフトウェアだが、
そのソフトウェアには「安く」という特性なぞ無いぞ。ちなみに「早く」という特性も無い。
ソフトウェア工学が対象とするのはソフトウェアの品質だけだ。
デリバリーとコストはソフトウェア工学では扱わないのだよ。
ツールベンダーのキャッチコピーなどに踊らされたかどうかは知らないが、
勝手に言葉の再定義をしないでほしいね

159 :仕様書無しさん:2007/02/21(水) 11:36:44
>>151
ユースケース図でいうところのユーザーアクターとユーザーエンティティが混同されているようだね。

>システム「このパスワードはあなたのパスワードと同じものですか?」
>
>ユーザ「はい、そうですよ」 ←※ このユーザは恐らくユーザエンティティ


>ユーザ「あの、ログインしたいんですけどいいですか」 ← ※このユーザは恐らくアクター
>
>認証サービスセンター受付「わかりました。そこに座ってお待ちください」
>
>: ←※恐らくここでユーザエンティティ(つまりDB)に問い合わせが行われる。
>
>認証サービスセンター受付「ログイン終わりました。ハイこれ会員証。これアクセス権限許可書。これが社内接続交付書ね。」

というかんじ?

160 :仕様書無しさん:2007/02/21(水) 11:40:44
>ツールベンダーのキャッチコピーなどに踊らされたかどうかは知らないが

言葉が先行するジャワ糞。実のない果実主義。

161 :仕様書無しさん:2007/02/21(水) 11:44:44
なあんかここでOO語る人たちって
四畳半一間に住んでいるのに脳内はセレプ気分なとこがいいですね。

のせる器の事はさておいて、とりあえず理想論。まあ夢持つ事は
大事な事だからね。とりあえずがんばって下さい。

162 :仕様書無しさん:2007/02/21(水) 11:52:05
∩( ・ω・)∩ おー、がんばるゾー

163 :仕様書無しさん:2007/02/21(水) 12:02:07
自分はもう引退が近いので、夢なぞ持っていないぞ

164 :仕様書無しさん:2007/02/21(水) 13:46:18
OOPはプログラムに動的な構造を持たせるための手段に過ぎない
現実の事象に割り付けようとして上手くいかないのは当然
頭が固い

165 :仕様書無しさん:2007/02/21(水) 16:32:21
美少女プログラマーがOOPを解説したら、一気に普及
インドがなんぼのもんじゃ〜い!

166 :仕様書無しさん:2007/02/21(水) 16:34:23
関連スレ
http://pc10.2ch.net/test/read.cgi/prog/1162409953/



167 :仕様書無しさん:2007/02/21(水) 16:40:57
美少女がおおーきなおおぱいぷるるぅ〜ん、について
      O     O     P
解説してくださると聞いて駆けつけてまいりました。
o(・_・= ・_・)o ドコドコ


168 :仕様書無しさん:2007/02/21(水) 19:10:46
比較可能インターフェースを実装する美少女クラスの属性は身長、体重、年齢、スリーサイズ、顔レベルだ。

利用者クラスが保持する比較器に美少女インスタンスが渡されることで初めて美少女かどうかを利用者は判断するわけだな。

しかし、この出会い系システムを使い利用者がリアルで会ってみたら実は男だったということもありうる。
これはドメインモデル分析が失敗していることを意味している。



169 :仕様書無しさん:2007/02/21(水) 19:30:44
ちょ、属性にまずいれるべきは性別だろが

170 :仕様書無しさん:2007/02/21(水) 19:39:44
あほか

どこのシステムで登録済みパスワードをユーザーに提示して
ユーザーがはいそうですと答えるシステムがあるんだ

ユーザーが「はい、そうですよ」
って答えればだれでもいいんかよ

オブジェクトは現実に即してモデリングするからオブジェクトなんだろが

171 :仕様書無しさん:2007/02/21(水) 19:51:38
>>170
システムの中の「ユーザ」(システムに登録されているユーザ)と、
ブラウザの向こうにいる「ユーザ」の同一性を、
パスワードを提示できるかどうかで確認することが認証でしょ?

本人確認ていうくらいだし。

だから、システムの中に登録されているユーザに対して、
システムが、ブラウザからこんなパスワードが送られてきたんですけど、これで合ってます?
って聞けばいいだけのことでしょう。


172 :仕様書無しさん:2007/02/21(水) 19:57:56
つまりアクターはオブジェクトでないと

171のいうのはデータでオブジェクトじゃねぇ

アクターを表すオブジェクトはなんだよ
アクターはActionのトリガなだけか

ブラウザの向こうにいる「ユーザ」はデータ定義上なだけで
ユーザーオブジェクトじゃねぇ

173 :仕様書無しさん:2007/02/21(水) 19:59:37
本人確認を本人に対して行うのかよw

本人が本人と確認できる情報を提示することで確認するんだろ

174 :仕様書無しさん:2007/02/21(水) 20:09:36
比較をどこでやるかの違いだとおもうけどね。

OO的
1.select userid,password from user where userid='yamada'でユーザクラスの山田さんインスタンスをメモリ上に展開する。
2.山田さんに入力されたパスワードとの比較をお願いする。

システム的
1.select userid,password from user where userid='yamada'でユーザクラスの山田さんインスタンスを生成する。
2.山田さんからパスワードを教えてもらう
3.入力されたパスワードと比較する

SQL的
1.select count(*) from user where user_id='yamada' and password ='hogehoge'があれば認証成功とする。

175 :仕様書無しさん:2007/02/21(水) 20:13:56
>オブジェクトは現実に即してモデリングするからオブジェクトなんだろが

176 :仕様書無しさん:2007/02/21(水) 20:15:34
アクターであるユーザーとシステムにおけるユーザーを
同一視できる抽象レベルでとらえられてないだけじゃねぇか

システムの中の「ユーザ」(システムに登録されているユーザ)と、
ブラウザの向こうにいるアクターである「ユーザ」は同一のユーザーオブジェクト

これがオブジェクト指向なんじゃねぇの

177 :仕様書無しさん:2007/02/21(水) 20:23:24
現実に即すと・・・

俺がシステムだとする。

今、俺は誰かも分からん奴に、「俺のIDは173なんだよ、システムに登録されてるだろ?頼むからメール送ってくれよ。」と頼まれる。

でも俺はそいつがだれだかわからない。第一信用できん。

だから俺は聞く「じゃあ、IDが173のユーザしか知りえない情報教えてくれよ」。

173だと自称する奴は、パスワードを俺に教える。

ここで俺は、173のユーザインスタンスを探す。(ここで無ければ、んなやつぁ存在しねーよ馬鹿でおしまい)

173のユーザインスタンスを生成した俺は、こいつに聞くんだ。「おい、変な奴がお前だって言ってきてるぞ」

173のユーザインスタンス「ちょwwwマジで?騙りかよwwwwwっうぇww」

俺「こいつ、こんなパスワード俺に教えてくれたんだけどさ・・・」

173のユーザインスタンス「うはwwww俺だしwwwwwwww」

俺「おk、ログインさせてやる」

178 :仕様書無しさん:2007/02/21(水) 20:37:26
大丈夫か?
やっぱ、オブジェクト指向は危険だな。
といことで流行しません。

179 :おじゃばさま:2007/02/21(水) 21:01:43
>154
154の言う通りだ。編集していたら間違えた。書こうとしたのは、
「処理、判断、繰り返しを使えば構造化プログラミングな訳ではない」

>158
安くと言うのは「コストを低く」と言う事である。
コストには時間的コスト、リソース的コスト、距離的コストなどいろいろあるが、
多くの場合、金額に跳ね返って来る。そのため、分かりやすく「安く」と表現した。
コストを無視すれば品質はいくらでも上げられるだろう。
要素にコストがなければ○○工学は全て無意味になる。


180 :仕様書無しさん:2007/02/21(水) 21:53:45
>>177
分かったけど、良い例えではないな。いや、マシな方かな。
とりあえず、乙。

181 :仕様書無しさん:2007/02/21(水) 22:35:02
オブジェクト指向はソフトウェア開発のための方法論です。
従って、最終的にオブジェクト化される対象物はコンピュータシステムの中だけで
生存可能(電子媒体上にインスタンスとして抽象的に表現可能なもの)なものに限
られます。当然ですね、生きた人間をメモリに転送することはできません。

システム化の対象はユースケース図でいうと四角形の境界の内側ということになります。
境界の外側にいるアクターはシステム化の対象からは除外されます。
アクターはあくまで開発対象の目的や位置づけ、役割等を分かり易く表現するための一
要素にすぎません。

設計段階ではまだしも、なんでもかんでもオブジェクトとしてコンピュータ上に表現しよう
考えるのは無理があります。この辺の考え方を誤っている人が多いようだね。

182 :仕様書無しさん:2007/02/21(水) 22:51:03
だから認証するっていうユースケースはどうドメイン設計するんだよ

183 :仕様書無しさん:2007/02/21(水) 22:52:04
メイドに任せる。

184 :仕様書無しさん:2007/02/21(水) 22:57:02
システムがユーザーを認証する

185 :仕様書無しさん:2007/02/21(水) 22:58:18
ウルセーボケを何度か投げかける。

186 :仕様書無しさん:2007/02/21(水) 22:59:21
j2eeセキュリティだとプリンシパル(認証主体)とクレデンシャル(秘匿情報)って言葉を使ってるが
これが認証のエンティティなのか?

プリンシパルってユーザやシステムひっくるめた概念らしいがよくわからん。



187 :仕様書無しさん:2007/02/21(水) 22:59:53
なんでそこまで認証に拘るのか判らんが、認証にもいろいろありますわなぁ。
OSが提供するもの、WebサーバやAPサーバが提供するもの、フィルターパターン使うもの、
DIコンテナでインターセプトしたり、PGで直接実装したり、ケースバイケースでございましょう。

188 :仕様書無しさん:2007/02/21(水) 22:59:54
>>183
メイドのインスタンスくれ。

189 :仕様書無しさん:2007/02/21(水) 23:04:40
上のほうで出てたけど、セキュリティ関係は全部アスペクトでもういいだろ。

190 :仕様書無しさん:2007/02/21(水) 23:06:11
システムが入力を受け付ける。
システムがデータを計算する。
システムが画像を読み取る。
システムがエンティティを永続化する。
システムが計算結果を表示する。
システムがウルセーボケを投げる。
システムが俺を金持ちにする。
システムがかわいい彼女を俺に(Ry
って全部システムでOk?

191 :仕様書無しさん:2007/02/21(水) 23:06:59
セキュリティだけどユースケースに記載されちゃったら認証業務だろ?


192 :仕様書無しさん:2007/02/21(水) 23:14:28
>>191
ユースケース アスペクト
でググって見れば。

193 :仕様書無しさん:2007/02/21(水) 23:19:57
AOP厨乙 ちゅぅかいいかげんウゼェ

194 :仕様書無しさん:2007/02/21(水) 23:20:53
俺はOOでメイドを作ることに非常に高い関心があるのだ。

195 :仕様書無しさん:2007/02/21(水) 23:24:22
厨扱いかよ。。

196 :仕様書無しさん:2007/02/21(水) 23:34:55
漫喫でメイドさんにチラチラ目が行くんだが、
はたしてこれは横断的関心事といえるのか・・・
いや、こっちの話。

197 :仕様書無しさん:2007/02/21(水) 23:43:39
>>196
シーケンス図よろ。

198 :仕様書無しさん:2007/02/21(水) 23:47:20
>>191
>ユースケースに記載されちゃったら認証業務だろ?

意味解らん。認証業務だとどうなの?

199 :仕様書無しさん:2007/02/21(水) 23:50:32
・店に入る
・会員認証をする
・席に着く
・マンガを取りに行く
・飲み物を取りに行く
等、各々のロジックを実行するたびに「メイドに目をやる」という
共通処理を行うのなら、これは立派な「横断的関心事」だ。
「メイドに目をやる」という処理はアスペクトとして組み込む方が
それぞれのロジックの実装はシンプルになる。

200 :仕様書無しさん:2007/02/22(木) 00:02:16
メイドが何かする度に「メイドに目をやる」
これもアスペクトになるぞ。

201 :仕様書無しさん:2007/02/22(木) 00:23:10
               ユースケース図
           __________
   ,[俺アクター]|   _____     |
  〜二二二   |   /      \   |
   (  ~∀') −−−( チラ見する )  | [メイドアクター]
   (    )   |   \_____/  |   (( 从 从 ))
    |  |  |   |     ____     |   ((*‘ー ‘))
   (__)_)  |   /     \   |  と\▽/つ
           |  ( お仕事する )−−−  /二二二ゝ
           |   \____/   |    ∪ ∪
           |__________|


202 :仕様書無しさん:2007/02/22(木) 00:26:20
問題はそもそもチラ見をどう実装するかだな。

203 :仕様書無しさん:2007/02/22(木) 00:35:03
メイドはチラ見されたとき、どういう状態変化するのか?

204 :仕様書無しさん:2007/02/22(木) 00:40:00
たぶん・・・
表面上は、ニコニコ
内面は、「さっきからチラチラ見てんじゃねぇよキメェんだよっ」
かなぁ・・・特に見た目に変化はあらわないと思うが。

205 :仕様書無しさん:2007/02/22(木) 00:45:47
不毛だな・・・

206 :仕様書無しさん:2007/02/22(木) 00:49:48
メイド喫茶の設計中・・・・

207 :仕様書無しさん:2007/02/22(木) 01:23:27
アスベストは体に良くないぞ
特に肺に良くないらしいぞ
骨肉種になるらしい

208 :151:2007/02/22(木) 12:06:40
>>174
そのOO的でもシステム的でも1に当たる部分は専用の認証クラスを組むわけでしょ。
だとすると認証機能、というくくりのうちパスワード比較だけユーザのクラスでする、ってのが何か気持ち悪い。
なんとなく結合が密な感じもするし。
せっかく「認証クラス」という大層な名前ついてる割に、認証に関すること全部自分で出来ないのかよ!と思っちゃう。

ログインしちゃって、セッションメモリとかにユーザクラスがいる状態になったら、あとの事はユーザクラスに任せても
いいと思うんだよ。
このメニューに入れるか、とか、英語表示するか日本語表示するか、とかはユーザクラス内に書いたり、判断させたりしても
いいと思うんだけど。。。


209 :仕様書無しさん:2007/02/22(木) 12:27:49
パスワードの代わりに指紋認証などにも拡張可能なように、とか
認証関連情報の格納場所を可変に、とか拡張性をきちんと考えると厄介だぞ。
そこはそれこそ設計の腕の見せ所で、簡単に決められるもんじゃない。

210 :仕様書無しさん:2007/02/22(木) 16:11:51
>>209
主語がないから意味が通じない。
何がどうなってると厄介なのか。

211 :OOP ◆SWtzLesEmM :2007/02/22(木) 20:51:26
オブジェクト指向の勉強方法をオススメ下さい。
当方結城浩先生のJava本(上)を読みました。
クラス設計はどういう本読めば勉強できますか?
最初はやっぱ、関数をクラスで包むだけの形から入れば良いでしょうか?

212 :仕様書無しさん:2007/02/22(木) 21:16:34
オブジェクト指向を勉強するのに一番いい方法は

213 :仕様書無しさん:2007/02/22(木) 21:44:59
糞して寝ること。

214 :仕様書無しさん:2007/02/22(木) 22:04:51
メイド喫茶のコスチュームローテを
オブジェクト指向設計するのは、意味があると思われ。

215 :仕様書無しさん:2007/02/22(木) 22:06:27
>>209
拡張する予定なんて、現時点では未定なんだから無問題。
手元にある情報で最適解を出すのが、設計の腕の見せ所だろ。

216 :おじゃばさま:2007/02/22(木) 22:17:24
>211
関数をクラスで包んではダメです。
最初は構造体の項目をプライベートのフィールド変数に定義し、それに対するGetter/Setterを作る
所から始めましょう。次にそのSetter/Getterに処理を追加したり、処理のたくさん入ったGetterもどき
を新たに追加したりします。この時、今まで連続して記述していた処理は、それぞれのメソッドの中に
分割されて入る事になるでしょう。
表現はしにくいのですが、今まで横割りだったプログラムが縦割りになるぐらいの大きな変化があります。
これが出来るようになるには普通の人で半年ぐらいかかります。

それが完成したら、どんどん仕様変更や機能追加を行います。
変更を繰り返すことで、本当に処理や変数を記述するべき位置が分かってきます。
適切にオブジェクト指向で設計されたソースは、変更が入る度に洗練されて行きます。
これが出来るようになるには、1年半ぐらいかかります。

参考にするべきよい本はありません。
業務で使われていて、長い間変更が繰り返されている、社内開発のミドルウェアのソースなどを参考に
するといいでしょう。
もしないならI○MのHPやミドルなどにいいソースがあるので参考にするといいでしょう。


217 :仕様書無しさん:2007/02/22(木) 23:09:02
>>216
本は読んだ方がいいと思うぞ、基本的な考え方は押さえとかないと、よっぽどの天才でも
ない限りいきなりソース読んでも遠回りだからな。へたすっと違う方向に行きかねん。

>>211
Amazonで、オブジェクト指向とかOOPで検索してレビュー数が多く評価の高い奴選んで1
冊ぐらいは読んだ方がいい。できれば何冊も読んで自分なりに咀嚼し実践してみるのが
いい。生兵法は怪我のもとだぞ。

218 :仕様書無しさん:2007/02/22(木) 23:24:57
>>211
>216の話は「カプセル化」とか「アクセサー(OR アクセッサー)」
あたりで検索すれば概念的なものは理解できるはず。

同じ結城浩先生の本でデザインパターンの入門書があるが、
オブジェクト指向やるなら読んでおいて損は無い。
デザインパターンの概念は初心者には少々難しいかもしれんが
サンプルコード見るだけでも十分勉強になると思う。


219 :仕様書無しさん:2007/02/23(金) 01:24:46
このアホコテは本当にうぜーなぁ。
こういう典型的な俺俺オブジェクト指向詐欺師がいるからオブジェクト指向が広まらんのだろう。
211はインターフェースクラスの定義や使われ方に注目してデザインパターン勉強しろ。
終わったらメイヤーのオブジェクト指向入門読め。1版な。2版は初心者には重いだろう。

220 :仕様書無しさん:2007/02/23(金) 01:39:57
>>219
アホコテって、>>216のことだろ?

221 :仕様書無しさん:2007/02/23(金) 08:30:22
ドメインドリブンデザインて本読め。
英語だがわかりやすい。

222 :おじゃばさま:2007/02/23(金) 09:37:26
最初にデザインパターンの本を読むのはお勧めしない。
デザインパターンと言うのはオブジェクト指向実装例の一種で、しかも少々特殊な例である。
そのため、オブジェクト指向を理解した後で、参考のために読むのがいいだろう。

ちなみに最初にデザインパターンの本を読んでしまって、これをオブジェクト指向の本質だと誤解し、
自分で組むプログラムを全てを、強引にデザインパターンに当てはめてコーディングし破綻する人が
Sヨネタに出て来る。
初心者にデザインパターンを勧めるのは、タチの悪いジョークなので本気にしないほうがよい。


223 :仕様書無しさん:2007/02/23(金) 09:41:37
デザパタってオブジェクト指向を実践する上での指南書だと思ってたけど。
意識するのとしないのとでは可読性も効率も全然違ってくる。

224 :仕様書無しさん:2007/02/23(金) 09:59:30
>>223
デザパタって今まで構造化プログラミングで慣れてきた人がいきなり入るのは
少々敷居が高い気がするなあ。
まずはクラスの概念、多態性と差分プログラミング、で簡単なプログラムを数本書いてからでいいと思う。

225 :仕様書無しさん:2007/02/23(金) 10:18:32
またでざぱたですか?w
単なる知恵袋を後生大事にするのは如何なものかと。
伊藤家の食卓ネタはあくまでそれレベル。


226 :仕様書無しさん:2007/02/23(金) 10:23:37
デザパタは言ってみたらお手本であり共通規格だと思うよ。
みんなが実践して初めて意味がある。

227 :仕様書無しさん:2007/02/23(金) 10:28:49
>>222
>デザインパターンと言うのはオブジェクト指向実装例の一種で、しかも少々特殊な例である。

一般人がこう断定しちゃうってどうなのよ。誤解を与えないためにもせめて、「俺は〜と思う」ぐらい
の表現にしておくべきかと。
デザパタにも、テンプレートメソッド、イティレータ、シングルトン等、特殊?でない一般的なものも含
まれているよ。デザパタを理解して始めてOOPを理解したと言えるのではないかと思う。
Gofの23個のデザパタを理解するには基礎を覚えた人で2年ぐらいはかかると、俺は思います。

228 :仕様書無しさん:2007/02/23(金) 10:45:27
2年。w

そんなのどうとでもいえるわな。
普通は見ればとりあえず判る、で実際に使いこなせるなんて一生かかっても無理なのが普通。
結局、あんな綺麗に適用できる事例なんて無いから。


229 :仕様書無しさん:2007/02/23(金) 10:46:50
だから「参考に」するんだろうが

230 :仕様書無しさん:2007/02/23(金) 10:52:31
オブジェクト指向の基礎を理解して基本的なクラスの設計、実装ができるようになったあとで
デザインパターンを理解すると適用箇所の勘どころがつかめる。

231 :仕様書無しさん:2007/02/23(金) 11:03:45
有名どころのオープンソースのソースを読むとデザパタがさりげなく、
というか当たり前に適用されている。ファクトリメソッド、コマンド、
シングルトン、ビジター、普通に使われている。
イティレータ、デコレータ、プロトタイプ等はJava等、言語標準のライ
ブラリで提供されてるし、実装にも使われている。

デザパタを絵に描いた餅などと言うのは食わず嫌いか単に勉強不足な
だけだと思う。良し悪しの判断はそれぞれすればいいと思うが、一通
り実践してみなければその判断すらできないだろう。ましてや応用等
できるはずもない。

232 :227:2007/02/23(金) 11:11:48
えーと、
>2年ぐらいは〜
っていうのは、>>216のカキコへの皮肉のつもりだったんだけど、伝わらないもんだな。

233 :仕様書無しさん:2007/02/23(金) 11:14:40
OOスレでは散々の議論になるが、デザパタ覚えただけなやつは、サルと一緒。
使いたくてしょうがないくて、使うことが目的で、使ったら死ぬまで使う。
本来の目的を忘れてでざぱた適用に必死なのは滑稽。

234 :仕様書無しさん:2007/02/23(金) 11:16:27
>>219
名著だし当時は眼から鱗がぼろぼろ落ちたが
さすがに内容が古くない? > オブジェクト指向入門 1版

235 :仕様書無しさん:2007/02/23(金) 11:18:12
金槌を初めて手にした子供は全てのものが釘に見える。

236 :仕様書無しさん:2007/02/23(金) 11:33:20
...と、デザパタすら覚えられない>>233 がオレオレ解釈して自分を慰めております。

237 :仕様書無しさん:2007/02/23(金) 12:06:06
だから、でざぱたなんぞ覚えるものじゃないんだよ。
そんなのあったなー程度を知っとけばいいの。
で、実際に使えそうだなーってときに見て、フィットさせて使えばいいだけ。

そもそも、きちんとGOFなり読んでれば、覚えるなんて考えが出ること自体おかしいと思うが。


238 :仕様書無しさん:2007/02/23(金) 12:12:09
そうそう、デザインパターンなんて何となくしっときゃ後で調べて適用できる

239 :仕様書無しさん:2007/02/23(金) 12:20:08
つーか、俺のロジックがデザパタになる

240 :仕様書無しさん:2007/02/23(金) 12:46:39
俺3日で覚えたけど。。そんなに大変?

241 :仕様書無しさん:2007/02/23(金) 12:50:42
覚えると理解するの違いが判らない人には無理だよ。
覚えるだけなら幼稚園生のほうが凄い。


242 :仕様書無しさん:2007/02/23(金) 12:53:32
いい加減黙れって>お邪魔

243 :仕様書無しさん:2007/02/23(金) 12:54:36
覚えたってのは名前とか構造のこと。理解するだけだったら2日でできたけど。

244 :仕様書無しさん:2007/02/23(金) 12:59:01
でざぱたは理解して使うものであって、覚えるものじゃねーよ。
本見て勉強したデザパタなんて使い物にならない。


245 :仕様書無しさん:2007/02/23(金) 13:05:55
なぜ俺が2日で理解できたか、それはほとんどを実践の中で
それとしらず使っていたからなんだな。 おっと、仕事、仕事

246 :仕様書無しさん:2007/02/23(金) 13:17:51
知らないうちに使っているものを明文化したものがデザインパターン
同じような処理でも実装は個人によって違うが
デザインパターンという明文化された基準を共有することによって
効率的で均一なコードが書けるようになる

247 :仕様書無しさん:2007/02/23(金) 13:47:26
デザパタ適用しても均一なコードにはなりえないのだが。
まあ、覚えて使ってる人は均一なのかもしれないが。w


248 :仕様書無しさん :2007/02/23(金) 13:54:40
さすが暖冬
春厨が目を覚ましたか

249 :おじゃばさま:2007/02/23(金) 21:25:52
>227
初心者に説明する場合は、多少の例外があったとしても断定した方がよい。
また普段使われない例が大量に入っているデザインパターンは、初心者には有害となる。
初心者に教えるコツは情報を絞る事である。

俺が言いたいのは、デザインパターンの学習が全くの無駄だと言う事ではない。
オブジェクト指向をマスターした後なら、いい勉強になるだろう。
オブジェクト指向をマスターしている人で、デザインパターンを知らない人は一度見てみるといい。
理解するのに3日もかからないだろうから。


250 :仕様書無しさん:2007/02/23(金) 21:29:33
| 釣れますか?                ,
\                         ,/ヽ
   ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄         ,/   ヽ
   ∧_∧          ∧∧  ,/         ヽ
  ( ´∀`)         (゚Д゚,,),/            ヽ
  (    )      (|おじゃ@               ヽ
  | | |   ___ 〜|ば |                ヽ
  (__)_) |――|.  ∪∪                     ヽ
   ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|                 ヽ
  /⌒\/⌒\/⌒\/⌒\|彡~゚ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~
  ⌒\/⌒\/⌒\/⌒\/⌒\彡 〜 〜〜 〜〜 〜〜 〜 〜

251 :仕様書無しさん:2007/02/23(金) 23:05:57
勤勉な方に多い行動パターンとして,
一つのことを深く掘り下げすぎるというのがあります。
これは大変すばらしいことなのですが,
分析や設計をするうえで視野が狭いというのは,致命的な欠点と言えます。

252 :仕様書無しさん:2007/02/23(金) 23:18:07
オブジェクト指向の本質がわからないんだっだらさ構造化プログラミングで書いてよ
継承、委譲てんこ盛りのオブジェクト指向スパゲッティのメンテでもうぐったりだ…

253 :仕様書無しさん:2007/02/23(金) 23:26:34
>>252
C++で多重継承を乱用されるともう手のつけようがないよね。

254 :仕様書無しさん:2007/02/24(土) 00:41:50
DQNなプログラマの存在を無視せず、現実的にいくとすれば、
rubyで書くのが一番マトモだろ。良い感じで制限が有って。
C++は自由度高すぎて最悪。JAVAはまあまあ。


255 :仕様書無しさん:2007/02/24(土) 00:44:15
>>254
つ D言語

256 :仕様書無しさん:2007/02/24(土) 00:49:22
なんでいきなりRubyが・・・

257 :仕様書無しさん:2007/02/24(土) 00:54:34
Rubyはいいよねー

258 :仕様書無しさん:2007/02/24(土) 00:57:54
多重継承っつーかそもそも最近じゃ継承は使わない方向なんだが。
お前らなんで継承がダメなのかちゃんとわかってんの?

259 :仕様書無しさん:2007/02/24(土) 01:04:59
多重継承は殆どの場合インタフェースで表現できるから

260 :仕様書無しさん:2007/02/24(土) 01:06:11
委譲てんこ盛りの

何が問題?

261 :仕様書無しさん:2007/02/24(土) 01:10:07
オーバーライドめ〜〜〜

262 :仕様書無しさん:2007/02/24(土) 01:16:34
>>256
ruby以外のオブジェクト指向言語には複数のスーパークラスから
継承する機能(多重継承)を持つものもあるが,rubyは意図的に
この機能を持っていない.
その代わりモジュールを使ったmixinという方法で同じことを
実現できる.

多重継承とmixinの違いは以下の通りである.
* モジュールはインスタンスを生成しない(抽象クラスであることが保証される).
* (主たる)継承関係がtree構造になることが保証される.

どちらもクラスの関係の複雑さを抑える働きがある.

rubyが多重継承を持っていない理由は,それが複雑さの
原因になるからだ.クラスが複数のスーパークラスを持ち,
関係のネットワークを形成する状況は,大体において
人間の頭には複雑すぎることが多い.
すくなくともDQNには無理だ.



263 :仕様書無しさん:2007/02/24(土) 01:28:04
継承はオーバーライドや、親の実装を引き継ぐので複雑化を招きやすい。
インタフェースならメソッドが存在することを強制するだけだからまだいい。

264 :仕様書無しさん:2007/02/24(土) 01:43:51
多重継承よりオーバーロードが嫌いな俺ガイル
理屈よりも感覚的に嫌い

265 :仕様書無しさん:2007/02/24(土) 02:25:56
DQNにプログラム言語を使わせたいならVBかCOBOLでもやらせてろ
ま、JavaやRubyでも構わないけどな

間違ってもC++やLispなどは使ってはいけない

266 :仕様書無しさん:2007/02/24(土) 02:32:38
PythonならまだしもRubyは完全にC++やLisp側の言語ですぜ

267 :仕様書無しさん:2007/02/24(土) 03:37:14
どうしても言語仕様の話になるんだな・・・

268 :仕様書無しさん:2007/02/24(土) 03:54:33
>>267
細かい言語仕様の差異で設計が左右すると思ってる厨がいっぱい居るからな。


269 :仕様書無しさん:2007/02/24(土) 09:41:16
多重継承で問題なのは、菱形継承とかで起こりがちな同階層同シグネチャのメンバ関数(メソッド)が
定義されている場合に、どちらを優先するのか(あるいはどちらも排除して改めて定義させるか)を
機械的には決められないってことだろ? Ruby のモジュールもこの問題には対処できていないから
Smalltalk の Traits からのパクリを Matz は模索しているしているところ。

http://www.rubyist.net/~matz/20060224.html#p02

270 :仕様書無しさん:2007/02/24(土) 12:20:41
多重継承が便利そうなケースってどんな場合よ?
俺は今まで、あぁ多重継承使いたいぁ〜、なんて状況に遭遇したことがないんだが。
必要か?

271 :仕様書無しさん:2007/02/24(土) 13:33:35
>>268
左右するに決まってんだろが。
CとLispで作り比べしてみれや。

272 :仕様書無しさん:2007/02/24(土) 13:36:14
>>270
ドメインモデルの実装を、永続レイヤとしてのクラス構造とドメインレイヤでのクラス構造の
多重継承にするとか。

273 :仕様書無しさん:2007/02/24(土) 13:49:52
>>270
たとえばJavaのスレッドで「Threadを直接継承する方法」と
「Runnableを実装してThreadに渡す方法」の2通りの方法が
存在するのなんて多重継承を禁止した弊害だと思うが。

でもC++のようにダイアモンド継承をまったくガード出来ない仕様も怖いよな。
もし引き継いだコードがC++のstreamクラスみたいな設計されてたら泣くよ。


274 :仕様書無しさん:2007/02/24(土) 14:11:31
Javaにもそのうちmix-inが標準実装されんじゃね?

275 :仕様書無しさん:2007/02/24(土) 15:07:44
OOが銀の弾丸と思ってる人は
DQNという事でw



276 :仕様書無しさん:2007/02/24(土) 15:25:57
文末にwをつける人は
DQNという事でw

277 :仕様書無しさん:2007/02/24(土) 15:37:03
>276
自らDQN宣言ですか?

お前はプログラムは組むなよw
っていうか、違う業界逝け。



278 :仕様書無しさん:2007/02/24(土) 15:38:56
C++はテンプレートがあるから多重継承を強力に使いこなす方法があるけど、
javaやc#じゃ無理だな。

279 :仕様書無しさん:2007/02/24(土) 15:53:12
つ Generic

280 :仕様書無しさん:2007/02/24(土) 16:04:19
>>279
C++知らない奴はすっこんでろ

281 :275:2007/02/24(土) 16:05:19
OOに限った話じゃないが
物事には必ず制約がある


しかし、レベルの低い技術者は
その境界線がまず見えてない。
その結果、0か1の様な短絡思考になる。

つまり、OO信者もアンチOOも
等しくレベルが低いって事だ。



282 :仕様書無しさん:2007/02/24(土) 16:09:27
頭悪そうな文章だなぁ

283 :仕様書無しさん:2007/02/24(土) 16:27:58
>282
レベル低そうな文章だなぁ


284 :仕様書無しさん:2007/02/24(土) 16:35:14
やっぱさ、いや真面目な話ね。
良書って評判の本読んで、自分で考えないと駄目なんだよな。

285 :仕様書無しさん:2007/02/24(土) 16:40:26
このスレで文章の後を無駄に改行してたのは全部お前かよ。

286 :仕様書無しさん:2007/02/24(土) 16:59:20
>284
真面目な話さ
意欲的に学習する技術者と
そうでない技術者の差は
学生の頃の比じゃないよな。(一部の天才は除く)

単純に考えても年数比で差が開くし、
実際のところ複利法の様に差が開くからな。

287 :仕様書無しさん:2007/02/24(土) 17:09:21











>285
妄想乙w


288 :仕様書無しさん:2007/02/24(土) 17:31:55
OOPを勉強します!
みんなよろしく!

289 :仕様書無しさん:2007/02/24(土) 17:49:39
勉強なんかいらねぇよw、OOPなんてなぁ勘でやっとけw


290 :仕様書無しさん:2007/02/24(土) 19:02:13
開発、設計のスレなのにOOPって言ってる奴はOOPを理解できないだろうね

291 :仕様書無しさん:2007/02/24(土) 20:48:06
>>290
OOA、OODあたりを勉強しないといけないですか?

292 :仕様書無しさん:2007/02/24(土) 21:05:17
スレタイの漢字が読める程度の学習は。

293 :仕様書無しさん:2007/02/24(土) 21:20:04
>>290
実装方法に品質やコストが深く依存している
現状では実装を抜きにして設計だけを語る事は
ナンセンスというかほぼ意味のない事だろ。

将来的にはそれと似た様な時代に
なるかも知らんけどな…

294 :仕様書無しさん:2007/02/24(土) 22:03:30
スレタイの漢字が読める程度の学習は。

295 :仕様書無しさん:2007/02/24(土) 22:25:29
>>290みたいな、
周りの人間の意見を鵜呑みにして満足するタイプの人間には
死ぬまで何もわかりゃしないさ。

296 :仕様書無しさん:2007/02/24(土) 23:52:19
今から
いちばんやさしいオブジェクト指向の本 井上樹
を読んでみる。

297 :仕様書無しさん:2007/02/24(土) 23:55:15
>>290の一文から>>295みたいな考えが出てくる奴の頭の中ではそうなんだろうな

298 :仕様書無しさん:2007/02/25(日) 00:23:34
> ラマヌジャンは多くの定理で誤りを犯したが、それが彼の天才をわずかでも傷つけることはなかった。
> しかし多くの人は、自分のアイデアを他の人に伝えようとする冒険の過程で時折間違いを犯すよりも、
> 何か自明な正しいことを言ったり、あるいは単に誰にも聞かれないことの方を好むようだ。

299 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/02/25(日) 00:23:44
こんなことより仕様変更なくしたほうが数倍効率上がるのに

300 :仕様書無しさん:2007/02/25(日) 00:31:47
>>299
構造化でやってっからだろ。
つか、仕様変更が無いプロジェクトなど存在しないし。

301 :仕様書無しさん:2007/02/25(日) 15:57:44
>>300
>つか、仕様変更が無いプロジェクトなど存在しないし。
いやいや。

302 :仕様書無しさん:2007/02/25(日) 17:17:43
某会社では言語能力に優れている奴は
オブジェクト指向にも対応しやすいとして
積極的に帰国子女を入れているようだけど
どうなんだろうか?
あと、オブジェクト指向を理解するには
一定の知能が必要という考え方も
あるようですが
どうなんでしょうか?

303 :仕様書無しさん :2007/02/25(日) 18:02:04
>>302 一定の知能が必要
おまえが理解できずに挫折したところをみると必要なんだろ

304 :仕様書無しさん:2007/02/25(日) 18:04:37
>>302
オブジェクト指向は、むしろ馬鹿指向と思われる。

・自販機の内部処理がどうなってるか知っている人間は少ないが、
自販機で買い物出来ない人間はもっと少ない。
・自販機を当たりつき自販機に改造するとき、自販機の内部処理が
どうなっているか知る必要は無い。

305 :仕様書無しさん:2007/02/25(日) 19:14:43
で?

306 :仕様書無しさん:2007/02/25(日) 20:05:46
>>304
すまんが何を言いたいのかさっぱり分からん。

307 :仕様書無しさん:2007/02/25(日) 20:24:08
>>304
つまり自販機壊して金盗む奴は賢いって事?


308 :仕様書無しさん:2007/02/25(日) 20:29:54
>>307
それはオブジェクト指向的じゃないからダメだな

309 :仕様書無しさん:2007/02/25(日) 20:42:00
つまり、馬鹿でも自販機は使えるし、馬鹿でも自販機を当たりつき自販機に改造できる
ということが言いたいんだろ。だから馬鹿指向と。

310 :仕様書無しさん:2007/02/25(日) 20:42:17
>>304
オブジェクト指向分かってるの?
何を持って馬鹿思考?


311 :仕様書無しさん:2007/02/25(日) 20:44:55
>>309
なるほど。
どんな馬鹿でも改造ができるって事でしょ?
いいじゃん。やさしいつくりで。

無駄に長いコードを描いて理解するのが難しいほうが馬鹿思考だと思うけど。


312 :仕様書無しさん:2007/02/25(日) 20:46:46
馬鹿にも自販機は使えるが、馬鹿が自販機を一から作るのは無理だろ。

313 :仕様書無しさん:2007/02/25(日) 21:10:30
>>304
バカに連れましたな
チャンチャンw

314 :仕様書無しさん:2007/02/25(日) 21:32:27
ぉまぇもなw

315 :仕様書無しさん:2007/02/25(日) 21:44:07
自販機を例にするなら確実にたとえが馬鹿。

基本の自販機機能に対して何を実現するかが各実装だろ?
ジュースでも切符でも得ろ本でも。
実装は馬鹿でも出来るが、基本のコンポーネントはまた別。


316 :仕様書無しさん:2007/02/25(日) 22:03:40
自販機作るなら内部知らんとつくれないな。


317 :仕様書無しさん:2007/02/25(日) 22:37:48
っていうか、自販機なら
当たり付きの機能部分の方が
コスト掛かるんじゃないの?

知らんけどw

318 :仕様書無しさん:2007/02/25(日) 22:40:44
>>317
圧倒的に金識別部だろ?
昔なら勧告の金を500円認識するほど馬鹿だったけど、今じゃすごいじゃん。


319 :仕様書無しさん:2007/02/25(日) 22:50:07
>>316
内蔵する、クーラやヒータの仕組みまで知る必要はない。

320 :仕様書無しさん:2007/02/25(日) 22:55:02
運用するにはしらないと出来ないな。

321 :仕様書無しさん:2007/02/25(日) 22:55:53
おまいら本当にわかってんのかw

322 :仕様書無しさん :2007/02/25(日) 23:02:19
おまえらが上っ面のコーディングしかしてないことがよくわかった
オブジェクト指向について語るのは無理

323 :仕様書無しさん:2007/02/25(日) 23:06:15
>>322
おまいがミクロなコーディングしかしてないことがよくわかった
分析・設計について語るのは無理

324 :仕様書無しさん:2007/02/25(日) 23:07:32
てか>>304でこれだけ揉めるのに驚いた
あんま判ってない人って本当に居るんだね


325 :仕様書無しさん:2007/02/25(日) 23:14:11
>>324「揉める」=「判ってない」って思ってるらしいな。

326 :仕様書無しさん:2007/02/25(日) 23:16:39
>>318
金識別部分のコスト被るのは
むしろハード屋かと。

当たり機能の方が
パチなんかの制御みたいに
当たりの精度やら細かい仕様があるんじゃないかね?
知らんけどw

327 :仕様書無しさん:2007/02/25(日) 23:16:41
俺が結論を言う、金儲けに勤しめ、世の中銭や、銭! 

328 :仕様書無しさん:2007/02/25(日) 23:19:33
結局、銭指向か...うちの社長と一緒だな。

329 :仕様書無しさん:2007/02/25(日) 23:32:32
>>326
実際に自販機作る話してるんじゃないし
例え話だろ

330 :仕様書無しさん:2007/02/25(日) 23:44:49
>>329
例のずれ方が面白かったから
釣られてみた訳だがw

331 :仕様書無しさん:2007/02/25(日) 23:46:30
>>330
どうずれてんのか説明してもらおうじゃない。

332 :仕様書無しさん:2007/02/25(日) 23:56:18
>>331
うん、うん、そうだ、>>330説明責任はたすよね

333 :仕様書無しさん:2007/02/26(月) 00:00:22
自販機のシミュレータをオブジェクト指向で作るのって入門者の課題であるだろ
お前ら、社内研修でやらなかったのか?

334 :仕様書無しさん:2007/02/26(月) 00:00:49
OODで説明よろw

335 :仕様書無しさん:2007/02/26(月) 00:12:10
つぅかよ、自販機のセッターつったら、商品の補充とつり銭の補充なわけだろ。
しかし、このセッターを使えるのは、商品担当者だけで、購入者にはこのメソッド
を使う権限は与えられてないわけだ。

これって、Javaでどう表現すんのよ。メソッドをpublicにはできんわなぁ。つぅと
protected にして、担当者が自販機を継承すんのか? そりゃおかしいだろ。
それじゃぁ担当者が商品とつり銭溜め込んじまうわなぁ。さぁ、こまった。どうする?

C++ だとfriend なんつう便利な指定子があるが、Javaにはねぇしなぁ・・・
あぁ! 自販機のメソッドのアクセスレベルをpackageにして、担当者を同じパッ
ケージにしとけばいいのか・・・すまんかった。出直してくる。

336 :仕様書無しさん:2007/02/26(月) 00:18:43
補充メソッドの引数に担当者インタフェースを取れば問題ないんでわ?

337 :仕様書無しさん:2007/02/26(月) 00:24:20
多分>>336みたいな発想が出てこないのって
自販機は人間が使うものっていう固定観念があるからだよねw

338 :仕様書無しさん:2007/02/26(月) 00:27:53
そうだよ、>>336みたいにすっと、窃盗団が偽担当者を作って悪さしね?
現実モデルに倣うとしたら、やっぱり担当者にアクセスするための鍵を
もたせるべきだろう。つぅかなんでインターフェース? AOP厨か?

339 :仕様書無しさん:2007/02/26(月) 00:28:42
おまえ何の話してんだよw

340 :仕様書無しさん:2007/02/26(月) 00:32:00
OOなんとかだよ。このスレでよくきくアレだよっ!

341 :仕様書無しさん:2007/02/26(月) 00:46:22
オブジェクト指向ってのは、結局現実と仮想の鬩ぎ合いなんだよな。
あまりにも現実的だと、現実がそうであるように複雑系になっていく。
現実からどんだけ妥協できるか、経済性を念頭においてどこに落とし
所をもってくるか、その辺の見極めにセンスが問われるわな。

342 :仕様書無しさん:2007/02/26(月) 00:50:49
>オブジェクト指向ってのは、結局現実と仮想の鬩ぎ合いなんだよな。

誰がそんなこと言ったの
独立性を高め依存性を低くするためのただの方法論だよ

343 :仕様書無しさん:2007/02/26(月) 00:53:55
つまり、
人はひとりでは生きられない

オブジェクトは一個でも生きられる
ってこと?

344 :仕様書無しさん:2007/02/26(月) 01:03:19
うちの爺ちゃんが言ってたよ、
オブジェクトってのはなぁ、独立心が強いわりには、他のオブジェクトに
依存したがるんだって、私は誰にも染まらないなんていいながら八方美人
なんだって。可笑しいよねっ

345 :仕様書無しさん:2007/02/26(月) 01:18:19
>>344
うまいこと言うじじだなっ。

346 :仕様書無しさん:2007/02/26(月) 01:19:18
訂正>うまいこと言うじじいだなっ。

347 :仕様書無しさん:2007/02/26(月) 07:25:38
>>336 だと、担当者インターフェースをどこでも生成できちゃうと
結局、アクセス制限にならないよな。むやみに複雑にしてるだけ
のような気がするが。
やっぱ担当者と自販機を同一パッケージにして、担当者をシン
グルトン、若しくはファクトリメソッドとの併用ってパターンでいいと
思うが・・・

348 :仕様書無しさん:2007/02/26(月) 08:26:51
自販機開ける鍵を補充担当者はもっている。

だから自販機のステートチャート書いて、状態が解放中の時だけ補充可能なようにセッターにチェック処理いれとけばよくね?

349 :仕様書無しさん:2007/02/26(月) 08:33:16
自販機のドア開いてない時にセッター呼べばセキュリティ例外だろ。

350 :仕様書無しさん:2007/02/26(月) 08:45:28
オブ的にはインタフェースを実装してればいいだろ
セキュリティ云々は別の話
ましてfriendつけたら他クラスに内部構造を滅茶苦茶にされるだろ

351 :仕様書無しさん:2007/02/26(月) 08:47:45
そんなに鍵が欲しいなら
補充メソッド内で鍵の確認でも何でもしたらいいよ
アクセス制限を何か勘違いしてる

352 :仕様書無しさん:2007/02/26(月) 09:01:40
オブジェクト状態も関係ない、ステートレスな自販機作ろうってか(笑)
商品補充しなくても無限にジュースが出てくるんですか?

状態考慮すれば自販機インターフェースの開けるメソッドに鍵渡せば済む話なのに
なんで担当者インターフェースを渡すとかになってるんだ。


353 :仕様書無しさん:2007/02/26(月) 09:21:39
担当者インタフェースを実装するものは誰でも
商品補充のメソッドを実装していることを保証するからだ

354 :仕様書無しさん:2007/02/26(月) 09:58:58
この場合Visitorパターンだよね・・・

355 :仕様書無しさん:2007/02/26(月) 10:25:59
>>343
なんでそんなもん保証しなきゃなんねんだよw 目的を見失ってねぇか?
寧ろ担当者に自販機インターフェース渡せよ。
アクセス制限かけたかったら自販機のメソッドの中で instanceof で
確認すればいいだろ。

356 :仕様書無しさん:2007/02/26(月) 10:36:20
どっちにどっちを渡そうが好きにしたらいいよ

bool 補充(IOperator operator)
{

357 :仕様書無しさん:2007/02/26(月) 10:42:43
class 自販機{
public bool 補充(IOperator operator)
{
if(operator.getKey() == this.key)
{
if(this.juiceEmpty()){
this.addJuice(operator.getJuice());
}
operator.addMoney(this.getMoney());

return true;
}
return false;
}
}

補充メソッドを一度書いておけばIOperatorを実装するだけで
商品の補充が保証される。
それともいちいち担当者ごとに補充するためのメソッド書くのか?
担当者が変わったらどう実装するの?

358 :仕様書無しさん:2007/02/26(月) 10:52:34
すまん、このパターンで面倒臭さと引き換えに何が解決されているのか
さっぱり分からないんだが。

359 :仕様書無しさん:2007/02/26(月) 10:57:46
俺はどうして判ってもらえないのか理解に苦しむ

360 :仕様書無しさん:2007/02/26(月) 11:05:05
担当者のバリエーションが増えた場合に便利なんじゃないの多分。

361 :仕様書無しさん:2007/02/26(月) 11:21:45
現在の「スレ違いのレス率」は推定約70%。
・・・って、オマイラいい加減にしろ

362 :仕様書無しさん:2007/02/26(月) 11:47:53
スレタイにOOPを付けたのがそもそもの間違い。
なくても、プログラムのことしかいわない奴がいるから一緒だが。

363 :仕様書無しさん:2007/02/26(月) 11:51:07
自分なんてプログラミングしないけど、本で得た知識だけでOOP語るもんね。

364 :仕様書無しさん:2007/02/26(月) 12:52:17
>>362
オブジェクト指向設計についてなんか語ってみてくれよ、語れるもんならw

365 :仕様書無しさん:2007/02/26(月) 13:06:43
>>364
「何か語ってみてくれよ」って「何かギャグやって」くらいハードル高いムチャ振りだと思う。

366 :仕様書無しさん:2007/02/26(月) 13:13:14
ばかやろ、プロならやるんだよ

367 :仕様書無しさん:2007/02/26(月) 14:03:48
プロなら無料ではやらないよ

368 :仕様書無しさん:2007/02/26(月) 18:57:53
オブジェクト指向は銭指向を実現するたねに開発されたソフトウェア産業分野の手法の1つです。
オブジェクト指向を理解するためには銭指向を先ず理解しなければなりません。
ソフトウェア産業分野での銭指向のわかりやすい実例としては、派遣PGがあります。

369 :仕様書無しさん:2007/02/26(月) 19:04:33
勘定指向プログラミング AOP(Account Oriented
Programming)のはじまりであった

370 :おじゃばさま:2007/02/26(月) 20:45:18
世の中で一番重要なのは銭ではありません。健康です。

健康志向プログラミングの始まりであった。


371 :仕様書無しさん:2007/02/26(月) 21:19:42
人類の歴史は貧困と病気との闘いの歴史

372 :仕様書無しさん:2007/02/26(月) 22:40:01
2chシステムをOOで構築するとオブジェクトは何になるんだ?
板、スレッド、レス辺りかね。
CGIに比べればOOだとレス抽出とかソートとかの拡張が簡単にできそうだな。



373 :仕様書無しさん:2007/02/26(月) 22:49:01
datファイルとsubject.txtが無いと専ブラが動かない

374 :仕様書無しさん:2007/02/26(月) 22:50:10
このスレを見ている人はこんなスレも見ています。→鉄拳かよ・・・

375 :仕様書無しさん:2007/02/26(月) 23:01:22
オブジェクトの永続化先をファイルにすればいいよ

376 :仕様書無しさん:2007/02/27(火) 08:15:23
だーかーらあああああ
なぜ流行らないの?

377 :仕様書無しさん:2007/02/27(火) 08:51:55
設計できる奴を集めれないから

378 :仕様書無しさん:2007/02/27(火) 09:20:04
上の奴らは設計者、プログラマを代替可能なリソースとしか見てない。

つまり俺らは人月で計算される個性の無い馬車馬なんだよ。
つまりOOなんて俗人的なオブジェクトでシステム組むなんて夢物語ってことさ。

379 :仕様書無しさん:2007/02/27(火) 09:47:26
プログラマ=コードを書く機械
という認識なら、OOD/OOPよりも従来のウォーターフォール的手法のほうが
やりやすいよ

380 :仕様書無しさん:2007/02/27(火) 09:51:30
プログラマ蔑視だな、差別だ、>>379のプログラマはコードを産む機械発言の謝罪と保証を・・・。

381 :仕様書無しさん:2007/02/27(火) 09:57:35
個人レベルでの生産性が100倍違うのがザラなのに
「プログラマ=コードを書く機械という認識なら」
こんな前提を考慮するだけ空しいわ

382 :仕様書無しさん:2007/02/27(火) 10:10:47
現実、そういう認識で人月単価で人身売買が行われているわけだが。

383 :仕様書無しさん:2007/02/27(火) 10:20:06
>>382
それは皆知っているし、それが間違いのもとだということも知っている。
更にいえば、営業的な側面ではウォータフォールにするしかない事も知っているし
>>381の状況下においてはそれが現場でうまく機能しないことも知っている。

384 :仕様書無しさん:2007/02/27(火) 19:04:09
それでありながら開発モデルを再検討することは
まったく考慮されない

385 :仕様書無しさん:2007/02/27(火) 22:51:50
開発プロセスをXPに変更したら、大規模開発じゃ嫌でもオブジェクト指向になるだろうよ。
ウォーターフォールでやる場合、ソフトウェアの進化や成長を無視するからオブジェクト指向で開発する意味が無くなるからな。

386 :仕様書無しさん:2007/02/27(火) 23:48:56
プロセスと手法は別に直結せんがね。
>>385は典型的なしったか、覚えた言葉を使いたいだけの猿。

387 :仕様書無しさん:2007/02/27(火) 23:51:38
>>386
俺にもそうみえる
てか、こういう馬鹿(>>385)何度もくるけど共通して過去ログみねぇのなw

388 :仕様書無しさん:2007/02/27(火) 23:53:30
>>383
ぶっちゃけ、PJの成功失敗って末端のPGの個人レベルに思いっきり依存してるよねw

389 :仕様書無しさん:2007/02/27(火) 23:54:09
X個人レベル
○個人のスキルレベル

390 :仕様書無しさん:2007/02/27(火) 23:55:04
>>388
規模によるだろ?
ピークが10人以上の小の大ぐらいからはリーダーの資質次第。
100人率いるマネージャーは中小企業の社長と同じだよ。

391 :仕様書無しさん:2007/02/28(水) 00:00:29
>>390
おめぇの日本語全く理解できねぇ
翻訳しろ翻訳

392 :仕様書無しさん:2007/02/28(水) 00:06:24
で、オブジェクト指向が流行らない理由は?
メーカーでは流行ってる(踊らされてる)けど、
偽装請負PGが(不勉強で)使いこなせてないだけだと思うけどね。

393 :仕様書無しさん:2007/02/28(水) 00:09:42
>>392
スレ読めばわかると思うけど、誰かが不勉強だからとかじゃなくて
メリットがわかりにくい(=数字で説明できない=ビジネスで使えない)んだよ。

394 :仕様書無しさん:2007/02/28(水) 00:16:27
>>393
そうとは限らないんじゃない?
メリットがわかりにくいってのはSEやPGにとってでしょ。
結局使うのは現場でなんだし。

395 :仕様書無しさん:2007/02/28(水) 00:21:23
つか今現在オブジェクト指向以外で何らかの分析設計手法が既に流行っているってのならともかく、
相対的に見てオブジェクト指向がどうかんがえても一番流行ってるだろ。

396 :仕様書無しさん:2007/02/28(水) 00:22:20
>>394
何を言ってるのかわからないけど
とりあえず、数字で表せないだろ?

オブジェクト指向なら、従来○○ヶ月かかったプロジェクトをXXヶ月に短縮できます!

こうやって「バーン!」って出せるもんがねぇじゃん。

397 :仕様書無しさん:2007/02/28(水) 00:26:34
オブジェクト指向という考え方の「存在」は浸透してる。
けど、流行ってない(理解してる奴が少ない)ってことでしょ?
数字で表すとかって、なんか関係あるの??


398 :仕様書無しさん:2007/02/28(水) 00:29:04
>>396
それって、オブジェクト指向じゃない「何か」ならだせるのか?

399 :仕様書無しさん:2007/02/28(水) 00:31:35
>>397
流行ってないの認識が違うな。

400 :仕様書無しさん:2007/02/28(水) 00:32:56
>>386 >>387

385だけども、進化的な開発プロセスを採用するのなら
進化的な開発のしやすい言語や技法を使うって流れになるのは当然だろ
インタフェースクラスや継承の意味をちゃんと理解してる?

401 :仕様書無しさん:2007/02/28(水) 00:33:21
>>396
メトリクスを計測するツールなんて、オブジェクト指向言語向けのばっか出てるじゃん。
十分数字で出せるじゃん。

402 :仕様書無しさん:2007/02/28(水) 00:33:24
>>398
ないんじゃない?
ただ、従来のやり方はノウハウがある(と思ってる上は)わけだから
変えるにはそれなりの理由がいるよ。

403 :仕様書無しさん:2007/02/28(水) 00:33:57
>>399
流行る・流行らないの状態を持ってるのはPG・SEオブジェクトでしょ。(なんてことを言ってみる)
認識が違うってのは、そしたら流行ってるかどうかを判定するのは何?

404 :仕様書無しさん:2007/02/28(水) 00:34:26
>>401
おめぇ頭腐ってるだろw

405 :仕様書無しさん:2007/02/28(水) 00:36:04
>>403
このスレの前提が「流行ってネェ」ってのなんだからそんな判定はいらねぇだろ。
「流行ってネェ」は事実かどうかは置いておいて前提なんだよ。
どっから話をはじめるんだ。お前は。

406 :仕様書無しさん:2007/02/28(水) 00:39:42
>>405
めちゃくちゃな論法だなw
ぶっとびすぎwww

407 :仕様書無しさん:2007/02/28(水) 00:41:22
>>405
前提はオッケー。
でもこれだけは教えて。
流行ってないってのは、誰にとって流行ってないの?
何が事実に含まれてるのか明確にしてよ。

408 :仕様書無しさん:2007/02/28(水) 00:42:21
>>402
つか、プロジェクト始まる前からそんなガチガチにやり方決まってるものなのか?
PDCAもなにもあったもんじゃない気がするんだけど。

うちなんか完全に担当まかせでやってるから、オブジェクト指向だろうがなんだろうが
やりたきゃやればってなもんだけど。

409 :仕様書無しさん:2007/02/28(水) 00:42:32
こないだの総理大臣(名前忘れた)だな
格差解決の議論をしてる中で「格差があるというならば」とかいいだすアレ。

410 :仕様書無しさん:2007/02/28(水) 00:43:36
オブジェクト指向でどんだけ利益を得てるかは具体的にはだせないが、
今さら昔の組み方で作ってくれっていわれても無理だな。
体(頭?)が無理。機能中心で考えようとしてもどうしても、オブジェ
クトを抽出しようとしてしまう。無理だ。ということで、多分やっぱり
物事を整理するのには役立ってんだと思う。


411 :仕様書無しさん:2007/02/28(水) 00:43:50
>>407
全員でいいんじゃない?

412 :仕様書無しさん:2007/02/28(水) 00:44:50
>>410
俺もそうおもう

413 :仕様書無しさん:2007/02/28(水) 00:44:56
>>410
別に共存できないわけでもないと思うけど
今だって、1つのクラスにプロジェクト全体の汎用関数全部突っ込む奴いるじゃないw

414 :仕様書無しさん:2007/02/28(水) 00:48:10
>>413
それはアーキテクチャと業務を分離できてなかった、昔の話だろ。

415 :仕様書無しさん:2007/02/28(水) 00:50:18
そもそも、
オブジェクト指向が流行ってるんなら
こんなスレが立つこともないのか。
「携帯電話がブームです」
って言うことのに違和感があるぐらいオブジェクト指向が浸透すれば評価しようもあるけど、
自分も含めてちゃんと理解できてる奴が少ないから、
ブームに過ぎない(流行ってない)ような気がする。
メリットどうこうを判断するところに達してないし。

416 :仕様書無しさん:2007/02/28(水) 00:50:19
>>414
じゃあ、昔のプロジェクトの改修作業でオブジェクト指向は使えないの?

417 :仕様書無しさん:2007/02/28(水) 00:52:07
>>415
いや、まずメリットありきでしょ?
大きく動きだすのなんて大手が教育システム導入して中小が後に続くしかないんだから。
まずメリットが見えなきゃ教育もありえないよね。

418 :仕様書無しさん:2007/02/28(水) 00:52:08
つ リエンジニアリング とか

419 :仕様書無しさん:2007/02/28(水) 00:53:08
ま、なんだかんだいっても、本当はみんなオブちゃんのこと好きなくせに。

420 :仕様書無しさん:2007/02/28(水) 00:54:07
>>417
オブジェクト指向の導入のメリットってなに?
再利用とかまあそこらへんがあるってのはみんな認識してるけど、
混乱するデメリットの方が大きいって考え方もあるよね。

421 :仕様書無しさん:2007/02/28(水) 00:55:47
>>420
俺が教えてほしいぜ>メリット

422 :仕様書無しさん:2007/02/28(水) 00:56:17
>>417
うちはかなりの大手だけど、とっくの昔にWeb系はオブジェクト指向開発が社内標準だぜ?
あとどうなればいいっていうの?

423 :仕様書無しさん:2007/02/28(水) 00:57:46
品質向上とか期間短縮にしても
それがどういう理由でどうしてそうなるのか?
って説明できなきゃこの技術は金にならずにもうそろそろ消えるなw

424 :仕様書無しさん:2007/02/28(水) 00:59:45
感覚的にオブジェクト指向は浸透するとは思えない。
でも知らないと嫌なので本を読んでみたりしてる。
なので いちばんやさしいオブジェクト指向の本 840円 を読書中。

425 :仕様書無しさん:2007/02/28(水) 01:00:44
>>422
オブジェクト指向って何ができるとオブジェクト指向ができたっていうの?
ってのを各社定義しはじめると思うんだ。
作るもんがこうのとき、こういうUMLがかけて、それに基づいてクラス作って・・・とか、
または単純にソースにクラスっぽいのがあればオブジェクト指向ですっていうところもあるかもな。
そういう定義ができてちゃんと個人がそれに対してできるできないって言えるようになったら
流行ってるとも言えるかな・・・。

426 :仕様書無しさん:2007/02/28(水) 01:01:18
>>424
憂鬱本買えよー

427 :仕様書無しさん:2007/02/28(水) 01:01:53
オブジェクト指向 なんてわかりにくい名前が足を引っ張ってる
だってわからんもん。 オブジェクト?指向? ???ってな感じで

428 :仕様書無しさん:2007/02/28(水) 01:02:47
>>427
沈めよ。お前。

429 :仕様書無しさん:2007/02/28(水) 01:02:57
結局、向上心やセンスの無い奴にオブジェクト指向導入のメリットを
理解させるには、共産主義国家に資本主義のメリットを説くのに似て、
相応の時間と犠牲が必要なのかもしれない。数十年もすればごく普通
の考え方になってるかもしれないし、或いは別の思想が根付いている
かもしれん。俺自身はオブジェクト指向は好きだが。ただ理解してな
い奴とはあまり一緒に仕事はしたくない。みんなも北朝鮮で仕事はし
たくないだろ?

430 :仕様書無しさん:2007/02/28(水) 01:03:11
・・・消えないで欲しいけどね。

431 :仕様書無しさん:2007/02/28(水) 01:04:14
>>429
またそうやって閉鎖的になる。
あきらかに万人に理解を得られなきゃ話にならない部分なのに何をそんな高尚なものにしたがるのか理解できない。
馬鹿かお前はw

432 :仕様書無しさん:2007/02/28(水) 01:04:57
>>425
そうそう!
どの成果物がオブジェクト指向で作られてます!
ってのが明確にわからないから、
結局流行ってないんじゃね?みたいに感じる!

433 :仕様書無しさん:2007/02/28(水) 01:05:08
憂鬱本ってどこらへんがそんなにいいの?
そこらへんのJavaの入門書に書いてあるオブジェクト指向の解説の域を出てないと思うんだが。
オブジェクト指向入門の方がオブジェクト指向の定義が厳密だし、
オブジェクト指向を導入するまでの論理が明快でわかりやすかったが。


434 :仕様書無しさん:2007/02/28(水) 01:06:39
>>431
なんで万人に理解を得られないといけないの?
俺はそんだけソフト開発の仕事が専門性を帯びてきてるんだと思うけど。
医者の仕事が万人に理解を得られているわけじゃないだろ?

435 :仕様書無しさん:2007/02/28(水) 01:08:34
オブジェクト指向って、なんか神格化してる人がいてたりすると、
わからんちんの自分はさらに敬遠しちゃう
オブジェクト指向の本を読んでも結局、何を作ればいいの??ってなる。
やっぱ環境なのかなあ。

436 :仕様書無しさん:2007/02/28(水) 01:09:09
憂鬱本ってなんですか?

437 :仕様書無しさん:2007/02/28(水) 01:09:27
>>434
同意。
ソフトウェア開発においては「一定のやり方に従うと一定の効果が得られる」
っていう幻想から脱却しなきゃなにやっても結局うまくいかんとおもう

438 :仕様書無しさん:2007/02/28(水) 01:11:58
パラダイムにしても開発モデルにしても
旧来の手法/方法で行き詰ってきて、
(現在に至るまでの要求の増大という遷移を勘案すれば)
さらに行き詰ることがはっきりしているから。
新たな手法/方法が幾つも提示されているわけだ。
その先頭に立っているのがOOであるわけだが。
このような認識を持っている人間が現場に少なすぎる。

439 :仕様書無しさん:2007/02/28(水) 01:12:49
エンドユーザーにUMLを見せても、
「こんなの分かんないので意味ないです」
と言われる官庁系システム。

440 :仕様書無しさん:2007/02/28(水) 01:13:33
>>425
社内標準あるけど何も変わらんぞ。大体、だれも従わんし。
外的要因待っててもムダとおもう。

441 :仕様書無しさん:2007/02/28(水) 01:13:54
結局はPLが何のために導入するかを説明してないってことでOK?

442 :仕様書無しさん:2007/02/28(水) 01:16:05
>>439
外人は理解してもらえるらしいぞ。頭の構造が違うのだろうか。
もちっと漫画チックにすれば日本人にも受け入れらると思うんだが。

443 :仕様書無しさん:2007/02/28(水) 01:16:25
>>439
見せ方悪いんじゃないのー?ユースケースなんて結構客先で評判いいぞいつも。
中途半端にシステム開発しってる客には受けないのかな。

444 :仕様書無しさん:2007/02/28(水) 01:20:14
UMLで描いて満足してるからわかってもらえないんだろ。
だいたいUMLで描いたからどうだって言うんだ?
UMLはただの表記法だって話はもう何度もループしてるぞ。

445 :仕様書無しさん:2007/02/28(水) 01:22:13
神に愛されし者だけがオブシェクト指向を理解できる
ということでおk?

446 :仕様書無しさん:2007/02/28(水) 01:27:33
オブジェクト指向が流行らない一因として、ユースケースから設計・実装への落とし込みが
長い間不透明すぎたってのがあるとおもう。

447 :仕様書無しさん:2007/02/28(水) 01:28:50
| UML釣れますか?             ,
\                         ,/ヽ
   ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄         ,/   ヽ
   ∧_∧          ∧∧  ,/         ヽ
  ( ´∀`)         (゚Д゚,,),/            ヽ
  (    )      (|  つ@               ヽ
  | | |   ___ 〜|  |                ヽ
  (__)_) |――|.  ∪∪                     ヽ
   ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|                 ヽ
  /⌒\/⌒\/⌒\/⌒\|彡~゚ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~
  ⌒\/⌒\/⌒\/⌒\/⌒\彡 〜 〜〜 〜〜 〜〜 〜 〜


448 :仕様書無しさん:2007/02/28(水) 01:29:53
もう流行なくていいよ。理解る奴だけ理解れば。
しょせんゴキブリと人間は仲良くなどできないのだよ。

449 :仕様書無しさん:2007/02/28(水) 01:33:17
みんなもう1時すぎだ。
デスマまで体力温存しようぜ

450 :仕様書無しさん:2007/02/28(水) 01:34:50
やだぷー

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)