【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3
前スレ
●●オブジェクト設計は何故流行らないの？●●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
さあ、張り切っていきましょう。
●●オブジェクト設計は何故流行らないの？●●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
さあ、張り切っていきましょう。
|
|
|
張り切ったら負けかなと思っている
>>1 乙
ぶるーまんでー；；
>>1おつ
こっちつかえばいいの？
こっちつかえばいいの？
ぉまぃら早く寝ろよ
それとも明日は鬱発症か？
・・・あぅぅ・・仕事行きたくねぇ・・
それとも明日は鬱発症か？
・・・あぅぅ・・仕事行きたくねぇ・・
スレタイ、なんでOOAは無視？別にいいけど。
コードが腐ってやがる、人類にOOは早すぎたんだ
インターフェース、インターフェースって、ＡＯＰ厨はインターフェースの定義
しか頭にないの。定義するだけならバカでもできるじゃん。
ＤＢが変わったときのためにぃ抽象化しとくぅとか、今までＤＢ変えたためし
あるか？ 俺は無い。最初のＤＢがずぅーっと動いてる。アホか。
ＤＢ変えるような事態になったらシステムごとリプレースするっちゅーねん。
その方が儲かるっちゅうねん。
実際の現場じゃ実装部分だけ差し替えるなんて滅多にあるもんじゃないっつーの。
まったく自己満足のためにやってるとしか思えん。コストの高い保険だぜ。
しか頭にないの。定義するだけならバカでもできるじゃん。
ＤＢが変わったときのためにぃ抽象化しとくぅとか、今までＤＢ変えたためし
あるか？ 俺は無い。最初のＤＢがずぅーっと動いてる。アホか。
ＤＢ変えるような事態になったらシステムごとリプレースするっちゅーねん。
その方が儲かるっちゅうねん。
実際の現場じゃ実装部分だけ差し替えるなんて滅多にあるもんじゃないっつーの。
まったく自己満足のためにやってるとしか思えん。コストの高い保険だぜ。
>>9
日本語でおｋ
日本語でおｋ
レスが無いから、>>9でも解読するか。
2行目と3行目はつながりが無いのかな？だとすると>>ＡＯＰ厨は
>>ORM厨の誤り、と見せかけて>>OOP厨の誤りと考えるのが自然か。
3行目以降はORMについて書いているようだが、
ORMはDBMSの置き換えリスクに対してやるものではないな。
2行目と3行目はつながりが無いのかな？だとすると>>ＡＯＰ厨は
>>ORM厨の誤り、と見せかけて>>OOP厨の誤りと考えるのが自然か。
3行目以降はORMについて書いているようだが、
ORMはDBMSの置き換えリスクに対してやるものではないな。
>>11
日本語でおｋ
日本語でおｋ
13 ：仕様書無しさん：2007/02/20(火) 00:33:17
OO厨 俺ｗ
設計段階で、
業務分析から製造までをオブジェクト指向で稼動できてるPJってどれぐらいあるんだろ。
一般的なPJってこんな感じだろ。
設計＝業務を知ってる奴、又は覚えていく過程にある奴が、ファイルに落とす。
その過程で設計規約などの存在は薄れていく。
製造＝設計書に文句をつけながらコーディング。
設計者→製造担当ならまだなんとかなるが、
理想といわれる分業をやると多くは悲惨な目にあう。
テスト＝テストファーストなんてものは納期優先のため存在しない。
ユーザーテストが単体テスト。
あんたらの現場は違うか？
大方こんなとこばっかりだと思うんだけどな。
業務分析から製造までをオブジェクト指向で稼動できてるPJってどれぐらいあるんだろ。
一般的なPJってこんな感じだろ。
設計＝業務を知ってる奴、又は覚えていく過程にある奴が、ファイルに落とす。
その過程で設計規約などの存在は薄れていく。
製造＝設計書に文句をつけながらコーディング。
設計者→製造担当ならまだなんとかなるが、
理想といわれる分業をやると多くは悲惨な目にあう。
テスト＝テストファーストなんてものは納期優先のため存在しない。
ユーザーテストが単体テスト。
あんたらの現場は違うか？
大方こんなとこばっかりだと思うんだけどな。
XPがちょっと入ってるのはスルーしてくれ。
>テスト＝テストファーストなんてものは納期優先のため存在しない。
>ユーザーテストが単体テスト。
こんな感じの現場だと、むしろ設計担当＝製造担当＝テスト担当のところが多い気がする。
>ユーザーテストが単体テスト。
こんな感じの現場だと、むしろ設計担当＝製造担当＝テスト担当のところが多い気がする。
「オブジェクト指向」
言ってみただけで偉くなったように勘違いする呪文。
実際はコンフュ。
言ってみただけで偉くなったように勘違いする呪文。
実際はコンフュ。
Q：何故流行らないの？
A：努力不足
みんなデスマには耐性あるくせに
A：努力不足
みんなデスマには耐性あるくせに
ラクをするためのはずのオブジェクト指向なのに、
設計では一向にラクだと実感したことが無いんだが。
どっちかといえばイライラした記憶ばかりだ。
設計では一向にラクだと実感したことが無いんだが。
どっちかといえばイライラした記憶ばかりだ。
昔ながらの設計書（業務単位に手続きをだらだら書いてある）を受け取って、
一生懸命OOPに翻訳していかなきゃいけないのは苦痛以外の何者でもない。
一生懸命OOPに翻訳していかなきゃいけないのは苦痛以外の何者でもない。
>17
一人よがり乙
銀の弾丸はないのに
自分に都合よい視点で考えてるだけだろw
OOが魔法の呪文になるのは
お前にも原因があると思ってない時点で終わっとるな。
一人よがり乙
銀の弾丸はないのに
自分に都合よい視点で考えてるだけだろw
OOが魔法の呪文になるのは
お前にも原因があると思ってない時点で終わっとるな。
そりゃ苦痛だろうな。
そんな無駄なことやってんだから。
上流と下流で別のもん作ってりゃあ世話ないわ。
そんな無駄なことやってんだから。
上流と下流で別のもん作ってりゃあ世話ないわ。
>>21
欧米かｗ
欧米かｗ
ぶ 銀の弾丸ｗ
25 ：仕様書無しさん：2007/02/20(火) 01:54:07
IT国家が生き残る。
インドを見よ。
国立の理系は、4年間オブジェクト設計を必須にする。
まじ、国家のためになる。（乙の乙
インドを見よ。
国立の理系は、4年間オブジェクト設計を必須にする。
まじ、国家のためになる。（乙の乙
銀の弾丸てｗｗｗｗｗｗｗｗｗ
オブジェクト指向は仕様変更や拡張を楽するためのもんじゃね
最初しんどいのは仕方ない
最初しんどいのは仕方ない
そこでYAGNIですよ
山羊煮？
>25
あまり関係ないがインドの九九は
一桁違うらしいな。
まぁ、地頭で差がつくと
埋めるはどの道厳しいけどな。
あまり関係ないがインドの九九は
一桁違うらしいな。
まぁ、地頭で差がつくと
埋めるはどの道厳しいけどな。
オブジェクト指向開発は一般化しとる。しとるが、
導入はしてるように見えるだけで昔となんも変わっとらんな
導入はしてるように見えるだけで昔となんも変わっとらんな
ソフトウェア開発にあたって、画一的な手順を確立して最適化してっていう
発想を変えていかないとだめなんじゃね？
プログラムを組むプログラムを組もうとする、果て無き取り組みに見える。
発想を変えていかないとだめなんじゃね？
プログラムを組むプログラムを組もうとする、果て無き取り組みに見える。
>>19,28 うむ。
設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。
そして通常、設計の工数よりも実装〜保守の工数の方が多いから
設計段階で手間をかける方が効率がよいというわけだ。
OOに限った話じゃないけど、OOだとそれが顕著な気はするね。
設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。
そして通常、設計の工数よりも実装〜保守の工数の方が多いから
設計段階で手間をかける方が効率がよいというわけだ。
OOに限った話じゃないけど、OOだとそれが顕著な気はするね。
OOD支援ツールと名のつくもの全てが糞なんだよ。きっとOODで開発
してないんだろうなって思う。
してないんだろうなって思う。
>>34
まだ、そんな現実に即してない理想論いうボーヤがいるのか？
会社で仕事してからこいよｗ
>設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。
この１文だけでかなり大きな矛盾を抱えている
まず、設計と実装、テスト、保守をする人間がそれぞれ別であること。
この状態で設計の時間だけ多くとって実装〜テストにかかる時間を削ってそれで誰が納得できるだろうか？
しかも、それもどのくらい設計に時間をかければ、どのくらい実装〜テストの時間を抜いていいという基準が無い。
単純に設計にかける時間を２倍にしたら、実装〜テストの時間は２分の１でいいのか？という問いに答えられなければ
現実、どうであろうがビジネスの場では意味が無い。
>設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。
それとこの１文にはまだある。
設計を丁寧にやるといっているが、丁寧にやったところで実装で覆る場合は少なくない。
これは完全に設計担当者の腕による。
場合によっては設計に時間をかけるだけ無駄になる場合も少なくない。
それとそもそもこの１文が常に真である保障も無ければ、高い確率で真である証明もできない。
そういう場でその設計が正しいかどうかを判断する方法として一番手っ取り早い方法は実装をしてみることである。
俺の感覚では実装をするコストは設計でおきるかどうかわからない不具合を想定してるコストよりも
はるかに少ないと考えるがそこはどうか？
まだ、そんな現実に即してない理想論いうボーヤがいるのか？
会社で仕事してからこいよｗ
>設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。
この１文だけでかなり大きな矛盾を抱えている
まず、設計と実装、テスト、保守をする人間がそれぞれ別であること。
この状態で設計の時間だけ多くとって実装〜テストにかかる時間を削ってそれで誰が納得できるだろうか？
しかも、それもどのくらい設計に時間をかければ、どのくらい実装〜テストの時間を抜いていいという基準が無い。
単純に設計にかける時間を２倍にしたら、実装〜テストの時間は２分の１でいいのか？という問いに答えられなければ
現実、どうであろうがビジネスの場では意味が無い。
>設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。
それとこの１文にはまだある。
設計を丁寧にやるといっているが、丁寧にやったところで実装で覆る場合は少なくない。
これは完全に設計担当者の腕による。
場合によっては設計に時間をかけるだけ無駄になる場合も少なくない。
それとそもそもこの１文が常に真である保障も無ければ、高い確率で真である証明もできない。
そういう場でその設計が正しいかどうかを判断する方法として一番手っ取り早い方法は実装をしてみることである。
俺の感覚では実装をするコストは設計でおきるかどうかわからない不具合を想定してるコストよりも
はるかに少ないと考えるがそこはどうか？
>37
真面目に論じたいなら煽り文入れるなや。
昔ながらのウォーターフォールでも、手戻りが後工程になってから
起きるほど工数がかかるってことはよく知られてるだろう。
そこから自然に導かれることだ。
よく設計が練られてるほど、手戻りの生じる確率は低いことが期待できるからな。
それと想定してる前提が幾つか私と食い違ってるみたいだな。
設計者=実装者=保守担当者の前提で考えてたよ。異なる現場ってそんなにある？
結合テストには別の人間が欲しいところだが。
設計担当者の腕が大きく影響するのはそのとおりだが、
上述したように実装者と同じ人間が担当するならこうなる。
設計：図を描きながらプログラムの枠組みをコーディング
実装：前段階で作成された枠組みの中身の部分を詰め込む
みたいな感じ。
こういう場合だって枠組みがきちんとできる前に中身を詰め込んじゃうと、
枠組み変更した場合に無駄になることが多い。
真面目に論じたいなら煽り文入れるなや。
昔ながらのウォーターフォールでも、手戻りが後工程になってから
起きるほど工数がかかるってことはよく知られてるだろう。
そこから自然に導かれることだ。
よく設計が練られてるほど、手戻りの生じる確率は低いことが期待できるからな。
それと想定してる前提が幾つか私と食い違ってるみたいだな。
設計者=実装者=保守担当者の前提で考えてたよ。異なる現場ってそんなにある？
結合テストには別の人間が欲しいところだが。
設計担当者の腕が大きく影響するのはそのとおりだが、
上述したように実装者と同じ人間が担当するならこうなる。
設計：図を描きながらプログラムの枠組みをコーディング
実装：前段階で作成された枠組みの中身の部分を詰め込む
みたいな感じ。
こういう場合だって枠組みがきちんとできる前に中身を詰め込んじゃうと、
枠組み変更した場合に無駄になることが多い。
あー、ひょっとして「設計」って全然違うものをイメージしてるのかな？
41 ：仕様書無しさん：2007/02/20(火) 09:29:58
「設計を時間かけて丁寧にやれば、その分実装、テスト、保守が楽になる。」
これこそがウォーターフォール的な発想じゃないのか？
これこそがウォーターフォール的な発想じゃないのか？
43 ：仕様書無しさん：2007/02/20(火) 10:50:12
>>44
じゃ、VC++ 1.0 からでいい？
じゃ、VC++ 1.0 からでいい？
OOP言語の登場と、OO開発の一般化の話は同じに考えちゃマズイでしょ。
OOP言語なんて半世紀近く前から登場している。
なのに、現在でもOOP言語を使って手続きプログラミングしてるのは何故かってところじゃない？
１．OOが理解できない
２．今まで長年手続き型コーディングしてきて、この方法で実装できることは分かっているから変えるつもりはない
３．OOPなんてのは妄想だ。継承だポリモーフィズムなんてのは実業務においては幻想に過ぎない
４．設計書が手続き型で設計されている（設計者がOO知らない）
５．データと処理は分離したほうが理解しやすい。データが処理を持つはずがない。
OOP言語なんて半世紀近く前から登場している。
なのに、現在でもOOP言語を使って手続きプログラミングしてるのは何故かってところじゃない？
１．OOが理解できない
２．今まで長年手続き型コーディングしてきて、この方法で実装できることは分かっているから変えるつもりはない
３．OOPなんてのは妄想だ。継承だポリモーフィズムなんてのは実業務においては幻想に過ぎない
４．設計書が手続き型で設計されている（設計者がOO知らない）
５．データと処理は分離したほうが理解しやすい。データが処理を持つはずがない。
>>1の参考ページより引用
オブジェクト指向では、データベースは単なる記憶装置に過ぎません。
極端な場合、データベースのデータをそのままメモリにオブジェクトとして取り込み、メモリ上ですべてを実現します。
オブジェクト指向の人にとってはエンティティクラスがドメインの中心であり、DBは永続ストアで陰に隠れています。
データ中心指向では、データベースを中心に考え、SQLで実現できるロジックはすべてSQLで実現します。
そのため、プログラムで使用するオブジェクトは、ユーザインターフェースとの受け渡し、処理用のテンポラリとして使ったり、
キャッシュとして使い、あくまでも補助的な位置づけになります。データ中心指向の人にとってエンティティはDBそのものであり、
エンティティクラスを作る必要はほとんどありません。
後者で設計するシステムだったらOOP言語なんて要らないな。
俺の周りの設計者（経験豊富とされるオッサンが多い）はみんな後者の設計方法だな。
処理とデータは分けてデータはDBに入れとく。
で、俺が「こんな情報がほしいときは？」と聞くと、「SQLでこのカラムとこのカラムを紐付けて、これを条件にしてひっぱってくればいい」と答える。
OOPならエンティティに尋ねて取得するのが正解なはずなんだけどね。
オブジェクト指向では、データベースは単なる記憶装置に過ぎません。
極端な場合、データベースのデータをそのままメモリにオブジェクトとして取り込み、メモリ上ですべてを実現します。
オブジェクト指向の人にとってはエンティティクラスがドメインの中心であり、DBは永続ストアで陰に隠れています。
データ中心指向では、データベースを中心に考え、SQLで実現できるロジックはすべてSQLで実現します。
そのため、プログラムで使用するオブジェクトは、ユーザインターフェースとの受け渡し、処理用のテンポラリとして使ったり、
キャッシュとして使い、あくまでも補助的な位置づけになります。データ中心指向の人にとってエンティティはDBそのものであり、
エンティティクラスを作る必要はほとんどありません。
後者で設計するシステムだったらOOP言語なんて要らないな。
俺の周りの設計者（経験豊富とされるオッサンが多い）はみんな後者の設計方法だな。
処理とデータは分けてデータはDBに入れとく。
で、俺が「こんな情報がほしいときは？」と聞くと、「SQLでこのカラムとこのカラムを紐付けて、これを条件にしてひっぱってくればいい」と答える。
OOPならエンティティに尋ねて取得するのが正解なはずなんだけどね。
とりあえず引用文の前半と後半で口調が変わってるのは理解できた。
>>49
後半は俺の意見だｗ
後半は俺の意見だｗ
OOP知らない奴が中途半端にOO使うからやっかいなんだよ。
OO否定する奴は一切使うな！大きなアプリケーションクラスだけ作って、
後は全部スタティックに宣言すればいいじゃね？
まぁどうせならＯＯの成果物（コンポーネント等）もいっさい使わないぐらい
の根性欲しいけど。
OO否定する奴は一切使うな！大きなアプリケーションクラスだけ作って、
後は全部スタティックに宣言すればいいじゃね？
まぁどうせならＯＯの成果物（コンポーネント等）もいっさい使わないぐらい
の根性欲しいけど。
俺が設計するときには、ドメイン設計からやってるな。クラス図がすべて。
オブジェクトの永続化先は全件メモリ上に展開して問題ないなら基本はXML。
永続化したオブジェクトを検索したりする必要がある場合にはDBに永続化してる。
オブジェクトの永続化先は全件メモリ上に展開して問題ないなら基本はXML。
永続化したオブジェクトを検索したりする必要がある場合にはDBに永続化してる。
この世のオブジェクトって有限じゃん？
みんなでオブジェクト設計して、共有するようになったら、
そのうち設計するオブジェクトが無くなっちゃうねぇ。
オブジェクト設計者失業ケテーィｗｗｗ
みんなでオブジェクト設計して、共有するようになったら、
そのうち設計するオブジェクトが無くなっちゃうねぇ。
オブジェクト設計者失業ケテーィｗｗｗ
>>53ではないが、
基本クラスとインターフェースだけ設計することにどんだけの意味があるのだろう。
それって表面だけ設計して、後の面倒毎や辻褄合わせはＰＧ任せってこと？
投げっぱなしじゃなくて、その後のフォローがあるなら別だが。
基本クラスとインターフェースだけ設計することにどんだけの意味があるのだろう。
それって表面だけ設計して、後の面倒毎や辻褄合わせはＰＧ任せってこと？
投げっぱなしじゃなくて、その後のフォローがあるなら別だが。
>>56
コンポーネント設計なら、インタフェースとデータだけ設計したら実装は
PGまかせってのはあるかも知れないが、手続きで実装されたら意味ないでしょ？
各永続エンティティが、属性とメソッドを持つクラス図が仕様書だよ。
メソッド内はご自由に実装どうぞかな。
IFはドメイン操作クラス用に切る。
コンポーネント設計なら、インタフェースとデータだけ設計したら実装は
PGまかせってのはあるかも知れないが、手続きで実装されたら意味ないでしょ？
各永続エンティティが、属性とメソッドを持つクラス図が仕様書だよ。
メソッド内はご自由に実装どうぞかな。
IFはドメイン操作クラス用に切る。
エンティティの属性とメソッドしか書かないの？ ＤＢ設計書とたいして変わんなくない？
クラス間の依存関係とかシーケンス図とかは？
手続きで実装されないためには、そっちの方が重要な気がするが。
クラス間の依存関係とかシーケンス図とかは？
手続きで実装されないためには、そっちの方が重要な気がするが。
>>56-57
基本のクラスとインターフェースを作ってあげれば
後は各機能を実装するには適切な基本クラスを継承して差分を書けばいいから
いいかなあ、と思ってさあ。
自分がPGやるときに細かいクラスまで全て設計されてたらやりたい実装が出来なくて
困ることもあるなあ、と。
だから一応SEやるときはPGの手足まで縛らないようにしたいなあ、という考えだったんだけど、、、
やっぱ間違いかなあ。
基本のクラスとインターフェースを作ってあげれば
後は各機能を実装するには適切な基本クラスを継承して差分を書けばいいから
いいかなあ、と思ってさあ。
自分がPGやるときに細かいクラスまで全て設計されてたらやりたい実装が出来なくて
困ることもあるなあ、と。
だから一応SEやるときはPGの手足まで縛らないようにしたいなあ、という考えだったんだけど、、、
やっぱ間違いかなあ。
基本設計時には要件から抽出したオブジェクトに対して、
コントローラから線が引かれる分析レベルのシーケンスが出来上がる。
この時点では、当然処理が流れるかどうか確認するだけなので永続化に関する概念は不要。
しかし詳細設計時になって初めて永続化の概念が出てくる。
だけどこれは「どうインスタンスを永続化するか」、「どう永続化したインスタンスを取得するか」くらい定義しとけばいいはず。
Persisterクラスにエンティティ渡して永続化するんですよ。とか。
シーケンス図上では、画面のボタンが押されてからオブジェクト操作して永続化するまでだと思う。
あとはPGがエンティティのインスタンスを（オブジェクトグラフごと）DBにマッピングして保存してくれればいい。
通常は楽するためにORM使うけどね。
コントローラから線が引かれる分析レベルのシーケンスが出来上がる。
この時点では、当然処理が流れるかどうか確認するだけなので永続化に関する概念は不要。
しかし詳細設計時になって初めて永続化の概念が出てくる。
だけどこれは「どうインスタンスを永続化するか」、「どう永続化したインスタンスを取得するか」くらい定義しとけばいいはず。
Persisterクラスにエンティティ渡して永続化するんですよ。とか。
シーケンス図上では、画面のボタンが押されてからオブジェクト操作して永続化するまでだと思う。
あとはPGがエンティティのインスタンスを（オブジェクトグラフごと）DBにマッピングして保存してくれればいい。
通常は楽するためにORM使うけどね。
>>59
その考え方は正しい。
ただし基本クラス継承して差分実装させるのはコマンドパターンを考えるとき。
つまり実装をパターン化したいというフレームワークを実装するときの考え方かな。
OOだと、エンティティ同士がお互いに細かく関連、依存し合って、
それぞれ実装すべき処理も異なるからAbstractMethod化は難しいかもしれないねぇ
その考え方は正しい。
ただし基本クラス継承して差分実装させるのはコマンドパターンを考えるとき。
つまり実装をパターン化したいというフレームワークを実装するときの考え方かな。
OOだと、エンティティ同士がお互いに細かく関連、依存し合って、
それぞれ実装すべき処理も異なるからAbstractMethod化は難しいかもしれないねぇ
ドメインの一部のエンティティになら
AbstructMethodパターン使えると思うけどな。
AbstructMethodパターン使えると思うけどな。
誰か「オブジェクト指向とは！」でまとめろ。
このスレが混乱してるように現場も混乱してる。
そんな考え方なんか採用してまともに仕事できんだろ。
このスレが混乱してるように現場も混乱してる。
そんな考え方なんか採用してまともに仕事できんだろ。
オブジェクト指向とは！
どうぞ、↓
どうぞ、↓
65 ：おじゃばさま：2007/02/20(火) 19:27:49
まず初心者が陥りやすい問題としては、オブジェクト指向を機能設計に適用しようとする事だ。
オブジェクト指向は詳細設計／コーディングに適用する物だが、オブジェクト指向をマスターしたての頃は、
機能設計にも適用出来るのではないかと思えてしまう。そして実際にやるとそれなりに出来る。
しかし他人が見ると理解困難な上に、多くの場合、無意味な拡張性があったりする。
これはなぜかと言うと、以前に野球選手や消費税計算をオブジェクト化して失敗した例を見てもらえば
分かると思う。
次にオブジェクト指向をソフトウェア工学に適用しようとする者もいる。
まあ気持ちは分かる。しかし意味はない。XPもスパイラルもオブジェクト指向とは関係ない。
XPやスパイラルはプロトタイプ方式から出た物で本質的に変わりがない。
そしてプロトタイプ方式は「新しい物を開発するのに優れた手順」であり、ソフトウェア以外でも
使われている古い方法である。
ましてやオブジェクト指向が、オンメモリかどうかなどは関係ない。
オブジェクトが永続であろうが、非永続であろうが、スタティックであろうが、オブジェクト指向とは
関係ない。
オブジェクト指向は詳細設計／コーディングに適用する物だが、オブジェクト指向をマスターしたての頃は、
機能設計にも適用出来るのではないかと思えてしまう。そして実際にやるとそれなりに出来る。
しかし他人が見ると理解困難な上に、多くの場合、無意味な拡張性があったりする。
これはなぜかと言うと、以前に野球選手や消費税計算をオブジェクト化して失敗した例を見てもらえば
分かると思う。
次にオブジェクト指向をソフトウェア工学に適用しようとする者もいる。
まあ気持ちは分かる。しかし意味はない。XPもスパイラルもオブジェクト指向とは関係ない。
XPやスパイラルはプロトタイプ方式から出た物で本質的に変わりがない。
そしてプロトタイプ方式は「新しい物を開発するのに優れた手順」であり、ソフトウェア以外でも
使われている古い方法である。
ましてやオブジェクト指向が、オンメモリかどうかなどは関係ない。
オブジェクトが永続であろうが、非永続であろうが、スタティックであろうが、オブジェクト指向とは
関係ない。
66 ：おじゃばさま：2007/02/20(火) 19:32:27
オブジェクト指向とは「データと処理のグループ化」である。
本では継承やカプセル化、ポリフォーリズムやインタフェースなどの言葉が出て来るが、
それは「データと処理のグループ化」の方法やそれによってもたらされた効果であり、
その本質ではない。
本では継承やカプセル化、ポリフォーリズムやインタフェースなどの言葉が出て来るが、
それは「データと処理のグループ化」の方法やそれによってもたらされた効果であり、
その本質ではない。
そんな抽象的な説明いらない。
実務(例えば業務アプリ)にどう使えばいいのか、どう適用すればいいのか。
について具体的に説明してくれ。
実務(例えば業務アプリ)にどう使えばいいのか、どう適用すればいいのか。
について具体的に説明してくれ。
俺の頭では結局何を言いたいのか分からんが、
ポリフォーリズム って何だろ音楽用語かな。
ポリフォーリズム って何だろ音楽用語かな。
「データと論理のレイヤー化」
のほうが正しいと思うけど。
のほうが正しいと思うけど。
俺の認識
サービス層でユーザー要求を受け付ける
サービスはオブジェクトに答えを求める
オブジェクトは自身の属性や関連をもとにして結果を返す
サービスはその結果を返す。
だと思うけどな。
サービスがエンティティ数だけ繰り返しや比較ロジックを持ってはならない。
認証機能がいい例だ。
パスワード属性を知っているのはユーザーエンティティなのに、
ユーザーエンティティからパスワードだけ取得してパスワード比較をサービスでやることが多いだろ？
OOで考えればユーザーに聞けば済む話じゃん。
サービス層でユーザー要求を受け付ける
サービスはオブジェクトに答えを求める
オブジェクトは自身の属性や関連をもとにして結果を返す
サービスはその結果を返す。
だと思うけどな。
サービスがエンティティ数だけ繰り返しや比較ロジックを持ってはならない。
認証機能がいい例だ。
パスワード属性を知っているのはユーザーエンティティなのに、
ユーザーエンティティからパスワードだけ取得してパスワード比較をサービスでやることが多いだろ？
OOで考えればユーザーに聞けば済む話じゃん。
>>73
なんでユーザーに説明せにゃなんねんだよ。
なんでユーザーに説明せにゃなんねんだよ。
オブジェクト指向の全体図は知らん。
知らんが、部品は便利だ。
ドメイン？なんじゃそりゃ。
エンティティ？DBのテーブル設計のことだろ？
クラス・インスタンス・カプセル化、ここらへんしか知らんが、
それで不便だと思ったことは無い。知識不足は認識しとるけどな。
具体性が必要なデスマ場に、
抽象的な考え方なんかは邪魔だ。
知らんが、部品は便利だ。
ドメイン？なんじゃそりゃ。
エンティティ？DBのテーブル設計のことだろ？
クラス・インスタンス・カプセル化、ここらへんしか知らんが、
それで不便だと思ったことは無い。知識不足は認識しとるけどな。
具体性が必要なデスマ場に、
抽象的な考え方なんかは邪魔だ。
リンク先、挫折。
用語の洪水におぼれたぞ。
こっちが頑張ろうと思っても辟易してしまう。
ここまでして覚えなきゃならんのか疑問だ。
つか、リンク先を理解できるおまぃらすげーよ。
用語の洪水におぼれたぞ。
こっちが頑張ろうと思っても辟易してしまう。
ここまでして覚えなきゃならんのか疑問だ。
つか、リンク先を理解できるおまぃらすげーよ。
80 ：仕様書無しさん：2007/02/20(火) 21:14:36
パスワードが正しいことを検証するのはシステムで認証を行うからで
認証サービスになるんじゃねぇのか
OOで考えればユーザーに聞けば済む話じゃん。って
認証するのはユーザーじゃなくてシステムだろ
認証サービスになるんじゃねぇのか
OOで考えればユーザーに聞けば済む話じゃん。って
認証するのはユーザーじゃなくてシステムだろ
結局、層をかぶせる従来のやり方が最強
または、業務システムならデータフローがあれば事足りる
オブジェクトが必要なシステムは、オブジェクトが必要
オブジェクトが存在しないシステムに無理にオブジェクトを抽出してもうまくいくはずが無い
オブジェクト指向は画面とかを作ったり
コンポーネントを作るのには向いている
だが、それ以外は向いてない
または、業務システムならデータフローがあれば事足りる
オブジェクトが必要なシステムは、オブジェクトが必要
オブジェクトが存在しないシステムに無理にオブジェクトを抽出してもうまくいくはずが無い
オブジェクト指向は画面とかを作ったり
コンポーネントを作るのには向いている
だが、それ以外は向いてない
＞オブジェクトが存在しないシステムに無理にオブジェクトを抽出してもうまくいくはずが無い
単なる整理整頓のやり方なんだから臨機応変にアサインすればいいんじゃないのか
単なる整理整頓のやり方なんだから臨機応変にアサインすればいいんじゃないのか
>>65
何故、ただの構造的な側面を、あたかもそれだけがＯＯの本質であるかのような書き方をする
のだろう。しかも言葉の理解や使い方を間違っているし。データと処理のグループ化などＯＯ以
前から行われていたことだ。今や習いたてのプログラマが理解する概念だ。
オブジェクト指向の本質は月並みだけど、やはり、継承、ポリモーフィズム、カプセル化だよ。そ
して、これらが適切に活用されていないところで問題が発生している。それは何故か？
物事を抽象化する能力が未熟だからだ。データと処理のグループ化のみに捕らわれていては
全時代的なプログラミングとたいして変わらない。ＯＯに習熟するためには、もう少し引いた目で
全体を俯瞰し物事を捉える能力を養う必要がある。
何故、ただの構造的な側面を、あたかもそれだけがＯＯの本質であるかのような書き方をする
のだろう。しかも言葉の理解や使い方を間違っているし。データと処理のグループ化などＯＯ以
前から行われていたことだ。今や習いたてのプログラマが理解する概念だ。
オブジェクト指向の本質は月並みだけど、やはり、継承、ポリモーフィズム、カプセル化だよ。そ
して、これらが適切に活用されていないところで問題が発生している。それは何故か？
物事を抽象化する能力が未熟だからだ。データと処理のグループ化のみに捕らわれていては
全時代的なプログラミングとたいして変わらない。ＯＯに習熟するためには、もう少し引いた目で
全体を俯瞰し物事を捉える能力を養う必要がある。
85 ：仕様書無しさん：2007/02/20(火) 21:56:23
ユーザーは認証されるのであって認証するのではない
認証の主語はユーザーではない
システムがユーザーを認証する
認証の主語はユーザーではない
システムがユーザーを認証する
OOを否定している香具師は手をあげて。
>>85
ユーザはパスワードを保持している。← これ前提ね。
システムが「このパスワードはあなたのパスワードと同じものですかぁ？」と
ユーザに問い合わせる。
↓
ユーザは、「そうですよぉ」又は「違ぇよヴぉけ！」と
答える。
↓
システムは、「了解、後はこちらで処理しときます。」と
結果を処理する。
これが普通の考え方。
ユーザはパスワードを保持している。← これ前提ね。
システムが「このパスワードはあなたのパスワードと同じものですかぁ？」と
ユーザに問い合わせる。
↓
ユーザは、「そうですよぉ」又は「違ぇよヴぉけ！」と
答える。
↓
システムは、「了解、後はこちらで処理しときます。」と
結果を処理する。
これが普通の考え方。
お前のは、
システムが「ユーザーさん、ちょっとあなたのパスワードを教えてください。」と
ユーザに要求する。
↓
ユーザは、「あいよっ」て差し出す。
↓
システムは、ユーザのパスワードと、手元のパスワードを照合する。
↓
結果を処理する。
って考えだろ。
これで、例えば、認証のために、ユーザーの住所とか生年月日とかも必要に
なったとしたら？ 前者の場合は外面のロジックは弄る必要がない。お前の
考えだと、システムにいろんなロジックが集中しちまうことになるっていうのが、
感覚的に理解できてない時点でお前はＯＯに向いてない。
システムが「ユーザーさん、ちょっとあなたのパスワードを教えてください。」と
ユーザに要求する。
↓
ユーザは、「あいよっ」て差し出す。
↓
システムは、ユーザのパスワードと、手元のパスワードを照合する。
↓
結果を処理する。
って考えだろ。
これで、例えば、認証のために、ユーザーの住所とか生年月日とかも必要に
なったとしたら？ 前者の場合は外面のロジックは弄る必要がない。お前の
考えだと、システムにいろんなロジックが集中しちまうことになるっていうのが、
感覚的に理解できてない時点でお前はＯＯに向いてない。
>>65-66
>陥りやすい問題としては、オブジェクト指向を機能設計に適用しようとする事だ。
>オブジェクト指向は詳細設計／コーディングに適用する物だ
もしかして、これって相当正しい見解だと思うよ
実現したい機能はあくまでも要求を合理的に機能面から検討して推奨する方向や
現実を考慮してより便利で価値あるものにするための設計のはずだと思う
そこにメンテナンス性や開発の効率性などを考慮して「OO設計による実装をする」
のだと思った
やはり求められ、かつ実現するべき機能は、その開発方法とは本来は別次元のもの
だったという正論に一票を入れたいと思う！
>陥りやすい問題としては、オブジェクト指向を機能設計に適用しようとする事だ。
>オブジェクト指向は詳細設計／コーディングに適用する物だ
もしかして、これって相当正しい見解だと思うよ
実現したい機能はあくまでも要求を合理的に機能面から検討して推奨する方向や
現実を考慮してより便利で価値あるものにするための設計のはずだと思う
そこにメンテナンス性や開発の効率性などを考慮して「OO設計による実装をする」
のだと思った
やはり求められ、かつ実現するべき機能は、その開発方法とは本来は別次元のもの
だったという正論に一票を入れたいと思う！
92 ：仕様書無しさん：2007/02/20(火) 22:33:07
適切な項目を適切な場所ですることに何の問題が？
ユーザーの住所とか生年月日とかも必要に なったとしたらユーザーオブジェクトがidとpassでも渡す設計か？
それこそインターフェイスが変わるだろうがよ
システムサービスのインターフェイスが変わるんだろ
最低だな
ユーザーのログインとかのメソッドならばまだわかるが
その場合でもあくまでシステムが認証する
システムサービスの認証機能に移譲する形でログインの実装だな
システムサービスのインスタンスはユーザーにインジェクションする
ユーザーの住所とか生年月日とかも必要に なったとしたらユーザーオブジェクトがidとpassでも渡す設計か？
それこそインターフェイスが変わるだろうがよ
システムサービスのインターフェイスが変わるんだろ
最低だな
ユーザーのログインとかのメソッドならばまだわかるが
その場合でもあくまでシステムが認証する
システムサービスの認証機能に移譲する形でログインの実装だな
システムサービスのインスタンスはユーザーにインジェクションする
94 ：仕様書無しさん：2007/02/20(火) 22:34:24
idとpassだったインターフェイスを
idとpass、住所とか生年月日にとかの
idとpass、住所とか生年月日にとかの
>>89
ちがうよ、一般的にもＯＯ的にも前者の方が正しいの。
ただ、例えば認証するのにユーザだけじゃなく他のオブジェクトにも情報
を問い合わせないといけないというような場合には、ユーザに認証を任せ
るわけにはいかないので、認証用のオブジェクト（ファサードパターンっ
ていったりする）にロジックを集中する場合もあるけど、この場合は単純
だから上の前者の例が一般的。
ちがうよ、一般的にもＯＯ的にも前者の方が正しいの。
ただ、例えば認証するのにユーザだけじゃなく他のオブジェクトにも情報
を問い合わせないといけないというような場合には、ユーザに認証を任せ
るわけにはいかないので、認証用のオブジェクト（ファサードパターンっ
ていったりする）にロジックを集中する場合もあるけど、この場合は単純
だから上の前者の例が一般的。
96 ：仕様書無しさん：2007/02/20(火) 22:36:16
話の途中ですまんが
前者ってどれのことを言ってるんだ？？？
前者ってどれのことを言ってるんだ？？？
>>94
認証情報クラスを引数にしてたらの話。細かいことつっこむなよ。
認証情報クラスを引数にしてたらの話。細かいことつっこむなよ。
CHAPかPAPか。
100 ：仕様書無しさん：2007/02/20(火) 22:46:03
iocぐらい知っとけよ
>>100
国際オリンピック委員会
国際オリンピック委員会
103 ：仕様書無しさん：2007/02/20(火) 23:04:38
サービス層の概念がない87のほうが問題だと思うんだが
SOAとか切り出す単位をそれでどうするんだ
インジェクションとかVisitor等で実装
ユーザーのログインの呼び出しは実装を知らない限り
87にちかいフローに見えるだと思うんだが
87のいってることも結局主語はシステムだしな
SOAとか切り出す単位をそれでどうするんだ
インジェクションとかVisitor等で実装
ユーザーのログインの呼び出しは実装を知らない限り
87にちかいフローに見えるだと思うんだが
87のいってることも結局主語はシステムだしな
結局おまぃら、
「オブジェクト指向とは！」
なんなんだ？
傍から見てるとちっとも認識が合ってるようには見えん。
「オブジェクト指向とは！」
なんなんだ？
傍から見てるとちっとも認識が合ってるようには見えん。
ちょくちょく出てきてる委譲の概念、IOCが>>95にない気がする
IOC（Inversion of Control）
http://jakarta.jp/hivemind/ioc.html
サービスに委譲する実装てなだけであって
OO的には問題ないと（個人的にはこっちのほうが変更に強いかなと）
IOC（Inversion of Control）
http://jakarta.jp/hivemind/ioc.html
サービスに委譲する実装てなだけであって
OO的には問題ないと（個人的にはこっちのほうが変更に強いかなと）
パスワード比較をユーザーで行う 後者
パスワード比較をシステムで行う 前者
の認識であっとる？
パスワード比較をシステムで行う 前者
の認識であっとる？
1.ユーザーがシステムにログインを試みる
2.システムがユーザーの認証を行う
3.ユーザーはログイン結果をシステムより取得
よって認証責任はシステム
2.システムがユーザーの認証を行う
3.ユーザーはログイン結果をシステムより取得
よって認証責任はシステム
オブジェクト指向がどうたらってのはどうでもよくて、
書いた設計書が理解すべき人間に
理解されなければただのごみだよな。
それを平易なものに書き直す必要がどっかで出るわけだ。
UMLなんか出されてもエンドユーザーからは
「こんな分かりにくい資料は無意味」と一蹴される。
オブジェクト指向のルールも一定のものが無く（あるのかもしれんが）、
小難しい話の応酬で、本来すべき作業がちっとも進まない。
こんなの流行るわけねーだろ。
書いた設計書が理解すべき人間に
理解されなければただのごみだよな。
それを平易なものに書き直す必要がどっかで出るわけだ。
UMLなんか出されてもエンドユーザーからは
「こんな分かりにくい資料は無意味」と一蹴される。
オブジェクト指向のルールも一定のものが無く（あるのかもしれんが）、
小難しい話の応酬で、本来すべき作業がちっとも進まない。
こんなの流行るわけねーだろ。
>>103
すまん、フロはいってた。
なんでいきなりサービス層とかSＯＡの切りだしの話がでてくるのか分かんない
んだけど、もしかして最初から想定している状況が食い違ってていたのかな。
だとしたら誤る。すまん。
俺が話していたのは、処理をどのオブジェクトが受け持つかという委譲の話。
パスワードの妥当性の検査はその属性をもっているユーザオブジェクトに受
け持たせて局所化した方がいいだろうということ。パスワードの妥当性の検査
の話よ。認証自体はそりゃ認証サービスが最終的な責任をもつべきだろうよ。
例えば、別のサブシステムで、同じようにパスワードの妥当性の検査を組み込
む必要がでてきた場合に、ユーザーオブジェクトに実装してあれば、ユーザー
クラスをサブシステムに持っていけばいい話だが、その外側のクラスでパスワ
ードの検証をしていたら、ユーザークラスの他にその外側のクラスももっていか
なきゃなるだろって話。IOCのことは全然考えて無かったよ。
すまん、フロはいってた。
なんでいきなりサービス層とかSＯＡの切りだしの話がでてくるのか分かんない
んだけど、もしかして最初から想定している状況が食い違ってていたのかな。
だとしたら誤る。すまん。
俺が話していたのは、処理をどのオブジェクトが受け持つかという委譲の話。
パスワードの妥当性の検査はその属性をもっているユーザオブジェクトに受
け持たせて局所化した方がいいだろうということ。パスワードの妥当性の検査
の話よ。認証自体はそりゃ認証サービスが最終的な責任をもつべきだろうよ。
例えば、別のサブシステムで、同じようにパスワードの妥当性の検査を組み込
む必要がでてきた場合に、ユーザーオブジェクトに実装してあれば、ユーザー
クラスをサブシステムに持っていけばいい話だが、その外側のクラスでパスワ
ードの検証をしていたら、ユーザークラスの他にその外側のクラスももっていか
なきゃなるだろって話。IOCのことは全然考えて無かったよ。
認証認可はオブジェクトではなく横断的関心事としてひとまとめにするのが吉
世間の常識
世間の常識
>>108
不勉強を呪え
不勉強を呪え
ユーザーに認証サービスがインジェクションされるほうが
他システムに持ってけると思うんだがどうよ
おんなじ認証なら同一のものをインジェクションすればいいし
認証方式が違うのであれば認証インターフェイスの違う実装をインジェクションすれば
>111のいうように認証における横断的関心事ひとまとめにしたのが認証インターフェイスになると
他システムに持ってけると思うんだがどうよ
おんなじ認証なら同一のものをインジェクションすればいいし
認証方式が違うのであれば認証インターフェイスの違う実装をインジェクションすれば
>111のいうように認証における横断的関心事ひとまとめにしたのが認証インターフェイスになると
>>110
問い合わせてきた利用者に認証結果を返すのは、認証サービスだろうね。
ただその認証結果を判断するプロセスの一つとして、ユーザーオブジェ
クトにパスワードの妥当性を問い合わせるというプロセスがあるの。
サービスクラスで、
if(pw.equals(user.getPassword()) {〜 てやるか、又は
if(user.isValidPassword(pw)) {〜 ってやるかってこと。
で、俺は後者の方がいいだろっていってんの。単純にいうとそんだけの話。
別にこれは認証に限った話ではなくて、一般的に処理をどこに受け持たせる
かという話。あ〜、なんか話が食い違ってるな。いつのまにかAOPの話になっ
てるし。
問い合わせてきた利用者に認証結果を返すのは、認証サービスだろうね。
ただその認証結果を判断するプロセスの一つとして、ユーザーオブジェ
クトにパスワードの妥当性を問い合わせるというプロセスがあるの。
サービスクラスで、
if(pw.equals(user.getPassword()) {〜 てやるか、又は
if(user.isValidPassword(pw)) {〜 ってやるかってこと。
で、俺は後者の方がいいだろっていってんの。単純にいうとそんだけの話。
別にこれは認証に限った話ではなくて、一般的に処理をどこに受け持たせる
かという話。あ〜、なんか話が食い違ってるな。いつのまにかAOPの話になっ
てるし。
>>108
エンドユーザーの不勉強を呪ってどうするんだよ。
エンドユーザーの不勉強を呪ってどうするんだよ。
if(user.isValidPassword(pw)) {〜
なんでユーザーに正しいパスワード通知する実装になるんだ？
認証サービスが正しいパスを放り込んでくるのは
機能設計時点でアウトだろ
なんでユーザーに正しいパスワード通知する実装になるんだ？
認証サービスが正しいパスを放り込んでくるのは
機能設計時点でアウトだろ
>>116 とか
スレ違い。よそでやれ。
スレ違い。よそでやれ。
>>116
いや、だから俺が話してんのは認証サービスに限った話ではなくて、
メソッドは、そのメソッドを処理するのに必要な情報を保持している
クラスにやらせるのがいいだろうという話をしてんの。
SOAはおいといてくれ。
>なんでユーザーに正しいパスワード通知する実装になるんだ？
これはすまん意味がわからん。
いや、だから俺が話してんのは認証サービスに限った話ではなくて、
メソッドは、そのメソッドを処理するのに必要な情報を保持している
クラスにやらせるのがいいだろうという話をしてんの。
SOAはおいといてくれ。
>なんでユーザーに正しいパスワード通知する実装になるんだ？
これはすまん意味がわからん。
機能（もしくはその一部）をオブジェクトとして捉えているのと
エンティティのみしかオブジェクトとして捉えていないやつの違いだな
エンティティのみしかオブジェクトとして捉えていないやつの違いだな
ぃい奴がオブジェクト指向の話に持っていく
↓
例え話をする奴が出現する
↓
突っ込みが入る
↓
以下無限ループ
↓
例え話をする奴が出現する
↓
突っ込みが入る
↓
以下無限ループ
>>119
メソッドは、そのメソッドを処理するのに必要な情報を保持している
クラスにやらせるのがいいだろう
処理を（処理を実装するオブジェクトのメソッドを呼び出すことで）委譲する
ということで「クラスにやらせる」を満たしているとはみなせんか？
オブジェクト指向の委譲についてってことで
メソッドは、そのメソッドを処理するのに必要な情報を保持している
クラスにやらせるのがいいだろう
処理を（処理を実装するオブジェクトのメソッドを呼び出すことで）委譲する
ということで「クラスにやらせる」を満たしているとはみなせんか？
オブジェクト指向の委譲についてってことで
セキュリティがどうこうじゃなくて単純に、ユーザーオブジェクトのほうがシステムオブジェクトより
一般的というか普遍性が高いから、ユーザーオブジェクトに認証ルーチンを持たせるのは良くない
設計ってことじゃないの？
一般的というか普遍性が高いから、ユーザーオブジェクトに認証ルーチンを持たせるのは良くない
設計ってことじゃないの？
機能面として実装しえないものを論じ合っても仕方ない。
ユーザーがシステムに問い合わせをする。
これが大前提。
システムが口を開けて待ってる、ってのはシステム論。
ユーザーがシステムに問い合わせをする。
これが大前提。
システムが口を開けて待ってる、ってのはシステム論。
>>122
すまん、よく分かんないんだけど、
例えばよ、まぁまた例え話になっちゃって申し訳ないけど、
パスワードの認証のために、パスワードの暗号化とか妥当性の検査とか
するのに 10行ぐらい書かないといけないとすると、いちいちそんな処理を
認証サービスに書くんじゃなくて、いったんユーザオブジェクト（処理に
ひつような属性は保持しているわけだし）に書いとけば、あとはどこでも
そのメソッドを呼ぶだけで妥当性の検査ができちゃうだろっていうことを
いいたいだけなのよ。別に難しいことをいってるわけじゃない。そして
これは別にパスワードの妥当性検査（認証処理じゃないよ）に限らず一般
的じゃないのというだけの話。
以上。ちょっと用事あるんで離席する。
すまん、よく分かんないんだけど、
例えばよ、まぁまた例え話になっちゃって申し訳ないけど、
パスワードの認証のために、パスワードの暗号化とか妥当性の検査とか
するのに 10行ぐらい書かないといけないとすると、いちいちそんな処理を
認証サービスに書くんじゃなくて、いったんユーザオブジェクト（処理に
ひつような属性は保持しているわけだし）に書いとけば、あとはどこでも
そのメソッドを呼ぶだけで妥当性の検査ができちゃうだろっていうことを
いいたいだけなのよ。別に難しいことをいってるわけじゃない。そして
これは別にパスワードの妥当性検査（認証処理じゃないよ）に限らず一般
的じゃないのというだけの話。
以上。ちょっと用事あるんで離席する。
>>ユーザーがシステムに問い合わせをする。
このユーザーとユーザーオブジェクト（エンティティ？）は別物だよねぇ。
このユーザーとユーザーオブジェクト（エンティティ？）は別物だよねぇ。
オブジェクト指向って、結局なんなの？ (´д｀)
>>128
立体プログラミング
立体プログラミング
>>128
あなたが理解していないことはよく分かりました(T T)
あなたが理解していないことはよく分かりました(T T)
>>129
全然わかりませぬ・・・
全然わかりませぬ・・・
>>129
言いえて妙だな
言いえて妙だな
調べた。
エンティティ＝クラスのことか〜。
そういえばいいのに〜。
エンティティ＝クラスのことか〜。
そういえばいいのに〜。
エンティティ=クラス って... 本当に調べたのか？
たしかにクラスがエンティティな場合もあるが...
たしかにクラスがエンティティな場合もあるが...
エンティティじゃないクラスもいっぱいあるぞ。
エンティティクラスはテーブル、エンティティのインスタンスはテーブルレコードと考えられる。
「オブジェクト指向でなぜつくるのか」を全部読んだけど、
エンティティなんて言葉は出てこなかった・・
http://e-words.jp/w/E382A8E383B3E38386E382A3E38386E382A3.html
ここも辞書なのに中途半端なこと書いてるし・・・
エンティティってなんなんだぁぁあ（ ＴДＴ）
エンティティなんて言葉は出てこなかった・・
http://e-words.jp/w/E382A8E383B3E38386E382A3E38386E382A3.html
ここも辞書なのに中途半端なこと書いてるし・・・
エンティティってなんなんだぁぁあ（ ＴДＴ）
>>135-137
な、謎が深まる(ﾉД`)ｼｸｼｸ
な、謎が深まる(ﾉД`)ｼｸｼｸ
>>139
まぁ大雑把に言えば、エンティテイ＝クラス という理解で問題無いと思うけど、
俺の感覚的なイメージからすると、クラスの中でも永続化の対象となりそうなク
ラスかな。つまり、ＤＢのテーブルと対応付けられるようなクラスのことかな。
まぁ大雑把に言えば、エンティテイ＝クラス という理解で問題無いと思うけど、
俺の感覚的なイメージからすると、クラスの中でも永続化の対象となりそうなク
ラスかな。つまり、ＤＢのテーブルと対応付けられるようなクラスのことかな。
>>128
そのうち理解できるようになる（かもしれない）から泣くな。
オブジェクト指向を端的に定義できるならば
こんなに長い間、沢山のスレが立つわけないだろ。
「民主主義とは、日曜に体育館や公民館に投票しに行くことだ」
という低レベルな理解で判った気になっていればそれでよいのだ。
自分の理解？。自分の理解は低レベルだから書かない。
そのうち理解できるようになる（かもしれない）から泣くな。
オブジェクト指向を端的に定義できるならば
こんなに長い間、沢山のスレが立つわけないだろ。
「民主主義とは、日曜に体育館や公民館に投票しに行くことだ」
という低レベルな理解で判った気になっていればそれでよいのだ。
自分の理解？。自分の理解は低レベルだから書かない。
>>139-140
エンティティ＝各テーブルのクラス・インスタンスでＯＫ？
な、何かが違うような気がする・・｡･ﾟ･(ﾉД`)･ﾟ･｡ｳｴｴｪｪﾝ
現場でC++やJavaをやってて、
SJC-Pに合格してても未だに分からない(´･ω･`)
言語を把握しててもスレを見ると
オブジェクト指向が理解できてない、
っていう気持ち悪さがなんとも・・・
エンティティ＝各テーブルのクラス・インスタンスでＯＫ？
な、何かが違うような気がする・・｡･ﾟ･(ﾉД`)･ﾟ･｡ｳｴｴｪｪﾝ
現場でC++やJavaをやってて、
SJC-Pに合格してても未だに分からない(´･ω･`)
言語を把握しててもスレを見ると
オブジェクト指向が理解できてない、
っていう気持ち悪さがなんとも・・・
オブジェクト指向というのはつまりこうなんだ
「くだらない仕事なんかさっさとかたして、お家に帰ろう！」
この思いが強ければ強いほど、オブジェクト指向が身につく！
仕事好きで、いつまでも帰らない人、家に持ち帰ってまで仕事をする人
趣味の無い人をよく観察してみてください
彼らはオブジェクト指向を全然理解していないし、これからも理解できません
「くだらない仕事なんかさっさとかたして、お家に帰ろう！」
この思いが強ければ強いほど、オブジェクト指向が身につく！
仕事好きで、いつまでも帰らない人、家に持ち帰ってまで仕事をする人
趣味の無い人をよく観察してみてください
彼らはオブジェクト指向を全然理解していないし、これからも理解できません
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業務処理をどうするのかに焦点がフォーカスされているため。
Javaイコールコポルの位置づけ
大手ポータルはPHP技術者を募集しているJavaの案件も多少あるが全体の5%程度
ではJavaはどのフィールドで生かされるか、基本的に生かさない。
SIerがこれからはコボルの代わりにJavaですよと営業布教しているだけ。
よって金融系でよく利用される。
SQLをEJBで操作しようとして大失敗したEJB1.0がその根拠
結論 コポラーがやるからオブジェクト指向設計はいらない。だから普及しない。
これからもしない。
Javaをやっている事で「おれたちオブジェクト指向やってるもんね」のような
自己満足で簡潔し閉じて終了。
ここで語っている人は業務プロセスの専門職ばかり。これだけもめるのも
潜在的にSQL業務処理をどうするのかに焦点がフォーカスされているため。
データ入れとく箱用のクラスと、処理用のクラスとに分けるんじゃなくて
データと処理を一緒のクラスにしましょうねというのがオブジェクト指向。
生存期間を伸ばすためにオブジェクトの属性値だけDBに入れて永続化する。
読み込む時は読み込み先のクラスはメソッドいっぱいもってるクラスになるわけですよ。
そうすれば読み込んだクラスのメソッドはすぐに使えるでしょ。
DAO、DTOとは違う考え方になります。
データと処理を一緒のクラスにしましょうねというのがオブジェクト指向。
生存期間を伸ばすためにオブジェクトの属性値だけDBに入れて永続化する。
読み込む時は読み込み先のクラスはメソッドいっぱいもってるクラスになるわけですよ。
そうすれば読み込んだクラスのメソッドはすぐに使えるでしょ。
DAO、DTOとは違う考え方になります。
おはよう、おじゃばさん
148 ：仕様書無しさん：2007/02/21(水) 09:02:29
>読み込む時は読み込み先のクラスはメソッドいっぱいもってるクラスになるわけですよ
まちがいなくジャワVMが悲鳴をあげてフルgc状態にはいりますね
まちがいなくジャワVMが悲鳴をあげてフルgc状態にはいりますね
超大量のすべてのレコードをインスタンス化するのはアホ。
レイジーロードと一緒に使う。
レイジーロードと一緒に使う。
>>126
普通「認証ロジック」って、IDやパスワードの妥当性の他に
どのアクセス権限があるかとか、社内接続かどうかとか、色々入るじゃない｡
そーいうのも全部ユーザクラスに書いたほうがいいの?
システム「このパスワードはあなたのパスワードと同じものですか?」
ユーザ「はい、そうですよ」
もOOだと思うんだけどさ、「責任の分担」ということで考えたら
ユーザ「あの、ログインしたいんですけどいいですか」
認証サービスセンター受付「わかりました。そこに座ってお待ちください」
認証サービスセンター受付「ログイン終わりました。ハイこれ会員証。これアクセス権限許可書。これが社内接続交付書ね。」
というのはOOではないの?
普通「認証ロジック」って、IDやパスワードの妥当性の他に
どのアクセス権限があるかとか、社内接続かどうかとか、色々入るじゃない｡
そーいうのも全部ユーザクラスに書いたほうがいいの?
システム「このパスワードはあなたのパスワードと同じものですか?」
ユーザ「はい、そうですよ」
もOOだと思うんだけどさ、「責任の分担」ということで考えたら
ユーザ「あの、ログインしたいんですけどいいですか」
認証サービスセンター受付「わかりました。そこに座ってお待ちください」
認証サービスセンター受付「ログイン終わりました。ハイこれ会員証。これアクセス権限許可書。これが社内接続交付書ね。」
というのはOOではないの?
152 ：おじゃばさま：2007/02/21(水) 10:13:17
>67
まずStrutsのデータビーンを参考に、構造体をクラス化するといい。
>77
ソフトウェア工学と言うのは、ソフトウェアを「いかに高品質で安く作れるか」を研究した物である。
大抵は開発手法の話である。
>84
では「継承、ポリモーフィズム、カプセル化」が何のためにあるかを考えた事はないか？
ちなみに構造化プログラミングも同様に、手段と目的が曖昧になっている人もいる。
あと構造化定理を使えば構造化プログラミングな訳ではないから、間違えている人は気をつけた方がいい。
どうしてもオブジェクト指向を視覚的に説明したい人は、Windowsのウィンドウを例に説明するとよい。
まずStrutsのデータビーンを参考に、構造体をクラス化するといい。
>77
ソフトウェア工学と言うのは、ソフトウェアを「いかに高品質で安く作れるか」を研究した物である。
大抵は開発手法の話である。
>84
では「継承、ポリモーフィズム、カプセル化」が何のためにあるかを考えた事はないか？
ちなみに構造化プログラミングも同様に、手段と目的が曖昧になっている人もいる。
あと構造化定理を使えば構造化プログラミングな訳ではないから、間違えている人は気をつけた方がいい。
どうしてもオブジェクト指向を視覚的に説明したい人は、Windowsのウィンドウを例に説明するとよい。
Struts（笑）
>構造化定理を使えば構造化プログラミングな訳ではないから、間違えている人は気をつけた方がいい。
構造化定理というのは単に論理を構造化するための理論的な背景だぞ。
それをいうなら
「構造化構文を備えた言語を使えば構造化プログラミングな訳ではない」だろ。
まったく「間違えている人は気をつけた方がいい」な。
構造化定理というのは単に論理を構造化するための理論的な背景だぞ。
それをいうなら
「構造化構文を備えた言語を使えば構造化プログラミングな訳ではない」だろ。
まったく「間違えている人は気をつけた方がいい」な。
155 ：仕様書無しさん：2007/02/21(水) 10:41:01
ジャワでSSL使うと遅延してよくタイムアウトするけど
ここにいるやつらのようなお馬鹿タンたちが重々しくなるように設計してる
からなんだなあと納得した。
ここにいるやつらのようなお馬鹿タンたちが重々しくなるように設計してる
からなんだなあと納得した。
>>151 なんでもっと柔軟に考えられないんだよ、
その目的のための情報をユーザオブジェクトが全部もってればユーザオブジェクト
でやればいいだろうし、そうでなければ、認証を受け持つ役割のオブジェクトがやれ
ばいいだけの話だろ。ただ認証プロセスの一つであるパスワードの照合はユーザ
オブジェクトでやらせればいいんじゃないの？ という話でしょ。
ユーザ認証という機能レベルの話しと、パスワードの照合という粒度の細かいメソッド
レベルの話をいっしょくたにしているから、話がかみ合ってない。
その目的のための情報をユーザオブジェクトが全部もってればユーザオブジェクト
でやればいいだろうし、そうでなければ、認証を受け持つ役割のオブジェクトがやれ
ばいいだけの話だろ。ただ認証プロセスの一つであるパスワードの照合はユーザ
オブジェクトでやらせればいいんじゃないの？ という話でしょ。
ユーザ認証という機能レベルの話しと、パスワードの照合という粒度の細かいメソッド
レベルの話をいっしょくたにしているから、話がかみ合ってない。
157 ：仕様書無しさん：2007/02/21(水) 11:21:29
>ソフトウェア工学と言うのは、ソフトウェアを「いかに高品質で安く作れるか」を研究した物である。
ソフトウェア工学の対象事物は確かのソフトウェアだが、
そのソフトウェアには「安く」という特性なぞ無いぞ。ちなみに「早く」という特性も無い。
ソフトウェア工学が対象とするのはソフトウェアの品質だけだ。
デリバリーとコストはソフトウェア工学では扱わないのだよ。
ツールベンダーのキャッチコピーなどに踊らされたかどうかは知らないが、
勝手に言葉の再定義をしないでほしいね
ソフトウェア工学の対象事物は確かのソフトウェアだが、
そのソフトウェアには「安く」という特性なぞ無いぞ。ちなみに「早く」という特性も無い。
ソフトウェア工学が対象とするのはソフトウェアの品質だけだ。
デリバリーとコストはソフトウェア工学では扱わないのだよ。
ツールベンダーのキャッチコピーなどに踊らされたかどうかは知らないが、
勝手に言葉の再定義をしないでほしいね
>>151
ユースケース図でいうところのユーザーアクターとユーザーエンティティが混同されているようだね。
>システム「このパスワードはあなたのパスワードと同じものですか?」
>
>ユーザ「はい、そうですよ」 ←※ このユーザは恐らくユーザエンティティ
>ユーザ「あの、ログインしたいんですけどいいですか」 ← ※このユーザは恐らくアクター
>
>認証サービスセンター受付「わかりました。そこに座ってお待ちください」
>
>： ←※恐らくここでユーザエンティティ（つまりＤＢ）に問い合わせが行われる。
>
>認証サービスセンター受付「ログイン終わりました。ハイこれ会員証。これアクセス権限許可書。これが社内接続交付書ね。」
というかんじ？
ユースケース図でいうところのユーザーアクターとユーザーエンティティが混同されているようだね。
>システム「このパスワードはあなたのパスワードと同じものですか?」
>
>ユーザ「はい、そうですよ」 ←※ このユーザは恐らくユーザエンティティ
>ユーザ「あの、ログインしたいんですけどいいですか」 ← ※このユーザは恐らくアクター
>
>認証サービスセンター受付「わかりました。そこに座ってお待ちください」
>
>： ←※恐らくここでユーザエンティティ（つまりＤＢ）に問い合わせが行われる。
>
>認証サービスセンター受付「ログイン終わりました。ハイこれ会員証。これアクセス権限許可書。これが社内接続交付書ね。」
というかんじ？
160 ：仕様書無しさん：2007/02/21(水) 11:40:44
>ツールベンダーのキャッチコピーなどに踊らされたかどうかは知らないが
言葉が先行するジャワ糞。実のない果実主義。
言葉が先行するジャワ糞。実のない果実主義。
161 ：仕様書無しさん：2007/02/21(水) 11:44:44
なあんかここでOO語る人たちって
四畳半一間に住んでいるのに脳内はセレプ気分なとこがいいですね。
のせる器の事はさておいて、とりあえず理想論。まあ夢持つ事は
大事な事だからね。とりあえずがんばって下さい。
四畳半一間に住んでいるのに脳内はセレプ気分なとこがいいですね。
のせる器の事はさておいて、とりあえず理想論。まあ夢持つ事は
大事な事だからね。とりあえずがんばって下さい。
∩( ・ω・)∩ おー、がんばるゾー
自分はもう引退が近いので、夢なぞ持っていないぞ
OOPはプログラムに動的な構造を持たせるための手段に過ぎない
現実の事象に割り付けようとして上手くいかないのは当然
頭が固い
現実の事象に割り付けようとして上手くいかないのは当然
頭が固い
美少女プログラマーがOOPを解説したら、一気に普及
インドがなんぼのもんじゃ〜い！
インドがなんぼのもんじゃ〜い！
美少女がおおーきなおおぱいぷるるぅ〜ん、について
Ｏ Ｏ Ｐ
解説してくださると聞いて駆けつけてまいりました。
o(･_･= ･_･)o ﾄﾞｺﾄﾞｺ
Ｏ Ｏ Ｐ
解説してくださると聞いて駆けつけてまいりました。
o(･_･= ･_･)o ﾄﾞｺﾄﾞｺ
比較可能インターフェースを実装する美少女クラスの属性は身長、体重、年齢、スリーサイズ、顔レベルだ。
利用者クラスが保持する比較器に美少女インスタンスが渡されることで初めて美少女かどうかを利用者は判断するわけだな。
しかし、この出会い系システムを使い利用者がリアルで会ってみたら実は男だったということもありうる。
これはドメインモデル分析が失敗していることを意味している。
利用者クラスが保持する比較器に美少女インスタンスが渡されることで初めて美少女かどうかを利用者は判断するわけだな。
しかし、この出会い系システムを使い利用者がリアルで会ってみたら実は男だったということもありうる。
これはドメインモデル分析が失敗していることを意味している。
ちょ、属性にまずいれるべきは性別だろが
あほか
どこのシステムで登録済みパスワードをユーザーに提示して
ユーザーがはいそうですと答えるシステムがあるんだ
ユーザーが「はい、そうですよ」
って答えればだれでもいいんかよ
オブジェクトは現実に即してモデリングするからオブジェクトなんだろが
どこのシステムで登録済みパスワードをユーザーに提示して
ユーザーがはいそうですと答えるシステムがあるんだ
ユーザーが「はい、そうですよ」
って答えればだれでもいいんかよ
オブジェクトは現実に即してモデリングするからオブジェクトなんだろが
>>170
システムの中の「ユーザ」（システムに登録されているユーザ）と、
ブラウザの向こうにいる「ユーザ」の同一性を、
パスワードを提示できるかどうかで確認することが認証でしょ？
本人確認ていうくらいだし。
だから、システムの中に登録されているユーザに対して、
システムが、ブラウザからこんなパスワードが送られてきたんですけど、これで合ってます？
って聞けばいいだけのことでしょう。
システムの中の「ユーザ」（システムに登録されているユーザ）と、
ブラウザの向こうにいる「ユーザ」の同一性を、
パスワードを提示できるかどうかで確認することが認証でしょ？
本人確認ていうくらいだし。
だから、システムの中に登録されているユーザに対して、
システムが、ブラウザからこんなパスワードが送られてきたんですけど、これで合ってます？
って聞けばいいだけのことでしょう。
つまりアクターはオブジェクトでないと
171のいうのはデータでオブジェクトじゃねぇ
アクターを表すオブジェクトはなんだよ
アクターはActionのトリガなだけか
ブラウザの向こうにいる「ユーザ」はデータ定義上なだけで
ユーザーオブジェクトじゃねぇ
171のいうのはデータでオブジェクトじゃねぇ
アクターを表すオブジェクトはなんだよ
アクターはActionのトリガなだけか
ブラウザの向こうにいる「ユーザ」はデータ定義上なだけで
ユーザーオブジェクトじゃねぇ
本人確認を本人に対して行うのかよw
本人が本人と確認できる情報を提示することで確認するんだろ
本人が本人と確認できる情報を提示することで確認するんだろ
比較をどこでやるかの違いだとおもうけどね。
OO的
１．select userid,password from user where userid='yamada'でユーザクラスの山田さんインスタンスをメモリ上に展開する。
２．山田さんに入力されたパスワードとの比較をお願いする。
システム的
１．select userid,password from user where userid='yamada'でユーザクラスの山田さんインスタンスを生成する。
２．山田さんからパスワードを教えてもらう
３．入力されたパスワードと比較する
SQL的
１．select count(*) from user where user_id='yamada' and password ='hogehoge'があれば認証成功とする。
OO的
１．select userid,password from user where userid='yamada'でユーザクラスの山田さんインスタンスをメモリ上に展開する。
２．山田さんに入力されたパスワードとの比較をお願いする。
システム的
１．select userid,password from user where userid='yamada'でユーザクラスの山田さんインスタンスを生成する。
２．山田さんからパスワードを教えてもらう
３．入力されたパスワードと比較する
SQL的
１．select count(*) from user where user_id='yamada' and password ='hogehoge'があれば認証成功とする。
＞オブジェクトは現実に即してモデリングするからオブジェクトなんだろが
176 ：仕様書無しさん：2007/02/21(水) 20:15:34
アクターであるユーザーとシステムにおけるユーザーを
同一視できる抽象レベルでとらえられてないだけじゃねぇか
システムの中の「ユーザ」（システムに登録されているユーザ）と、
ブラウザの向こうにいるアクターである「ユーザ」は同一のユーザーオブジェクト
これがオブジェクト指向なんじゃねぇの
同一視できる抽象レベルでとらえられてないだけじゃねぇか
システムの中の「ユーザ」（システムに登録されているユーザ）と、
ブラウザの向こうにいるアクターである「ユーザ」は同一のユーザーオブジェクト
これがオブジェクト指向なんじゃねぇの
現実に即すと・・・
俺がシステムだとする。
今、俺は誰かも分からん奴に、「俺のIDは173なんだよ、システムに登録されてるだろ？頼むからメール送ってくれよ。」と頼まれる。
でも俺はそいつがだれだかわからない。第一信用できん。
だから俺は聞く「じゃあ、IDが173のユーザしか知りえない情報教えてくれよ」。
173だと自称する奴は、パスワードを俺に教える。
ここで俺は、173のユーザインスタンスを探す。（ここで無ければ、んなやつぁ存在しねーよ馬鹿でおしまい）
173のユーザインスタンスを生成した俺は、こいつに聞くんだ。「おい、変な奴がお前だって言ってきてるぞ」
173のユーザインスタンス「ちょｗｗｗマジで？騙りかよｗｗｗｗｗっうぇｗｗ」
俺「こいつ、こんなパスワード俺に教えてくれたんだけどさ・・・」
173のユーザインスタンス「うはｗｗｗｗ俺だしｗｗｗｗｗｗｗｗ」
俺「おｋ、ログインさせてやる」
俺がシステムだとする。
今、俺は誰かも分からん奴に、「俺のIDは173なんだよ、システムに登録されてるだろ？頼むからメール送ってくれよ。」と頼まれる。
でも俺はそいつがだれだかわからない。第一信用できん。
だから俺は聞く「じゃあ、IDが173のユーザしか知りえない情報教えてくれよ」。
173だと自称する奴は、パスワードを俺に教える。
ここで俺は、173のユーザインスタンスを探す。（ここで無ければ、んなやつぁ存在しねーよ馬鹿でおしまい）
173のユーザインスタンスを生成した俺は、こいつに聞くんだ。「おい、変な奴がお前だって言ってきてるぞ」
173のユーザインスタンス「ちょｗｗｗマジで？騙りかよｗｗｗｗｗっうぇｗｗ」
俺「こいつ、こんなパスワード俺に教えてくれたんだけどさ・・・」
173のユーザインスタンス「うはｗｗｗｗ俺だしｗｗｗｗｗｗｗｗ」
俺「おｋ、ログインさせてやる」
178 ：仕様書無しさん：2007/02/21(水) 20:37:26
大丈夫か？
やっぱ、オブジェクト指向は危険だな。
といことで流行しません。
やっぱ、オブジェクト指向は危険だな。
といことで流行しません。
179 ：おじゃばさま：2007/02/21(水) 21:01:43
>154
154の言う通りだ。編集していたら間違えた。書こうとしたのは、
「処理、判断、繰り返しを使えば構造化プログラミングな訳ではない」
>158
安くと言うのは「コストを低く」と言う事である。
コストには時間的コスト、リソース的コスト、距離的コストなどいろいろあるが、
多くの場合、金額に跳ね返って来る。そのため、分かりやすく「安く」と表現した。
コストを無視すれば品質はいくらでも上げられるだろう。
要素にコストがなければ○○工学は全て無意味になる。
154の言う通りだ。編集していたら間違えた。書こうとしたのは、
「処理、判断、繰り返しを使えば構造化プログラミングな訳ではない」
>158
安くと言うのは「コストを低く」と言う事である。
コストには時間的コスト、リソース的コスト、距離的コストなどいろいろあるが、
多くの場合、金額に跳ね返って来る。そのため、分かりやすく「安く」と表現した。
コストを無視すれば品質はいくらでも上げられるだろう。
要素にコストがなければ○○工学は全て無意味になる。
オブジェクト指向はソフトウェア開発のための方法論です。
従って、最終的にオブジェクト化される対象物はコンピュータシステムの中だけで
生存可能（電子媒体上にインスタンスとして抽象的に表現可能なもの）なものに限
られます。当然ですね、生きた人間をメモリに転送することはできません。
システム化の対象はユースケース図でいうと四角形の境界の内側ということになります。
境界の外側にいるアクターはシステム化の対象からは除外されます。
アクターはあくまで開発対象の目的や位置づけ、役割等を分かり易く表現するための一
要素にすぎません。
設計段階ではまだしも、なんでもかんでもオブジェクトとしてコンピュータ上に表現しよう
考えるのは無理があります。この辺の考え方を誤っている人が多いようだね。
従って、最終的にオブジェクト化される対象物はコンピュータシステムの中だけで
生存可能（電子媒体上にインスタンスとして抽象的に表現可能なもの）なものに限
られます。当然ですね、生きた人間をメモリに転送することはできません。
システム化の対象はユースケース図でいうと四角形の境界の内側ということになります。
境界の外側にいるアクターはシステム化の対象からは除外されます。
アクターはあくまで開発対象の目的や位置づけ、役割等を分かり易く表現するための一
要素にすぎません。
設計段階ではまだしも、なんでもかんでもオブジェクトとしてコンピュータ上に表現しよう
考えるのは無理があります。この辺の考え方を誤っている人が多いようだね。
だから認証するっていうユースケースはどうドメイン設計するんだよ
メイドに任せる。
184 ：仕様書無しさん：2007/02/21(水) 22:57:02
システムがユーザーを認証する
ｳﾙｾｰﾎﾞｹを何度か投げかける。
j2eeセキュリティだとプリンシパル(認証主体)とクレデンシャル(秘匿情報)って言葉を使ってるが
これが認証のエンティティなのか？
プリンシパルってユーザやシステムひっくるめた概念らしいがよくわからん。
これが認証のエンティティなのか？
プリンシパルってユーザやシステムひっくるめた概念らしいがよくわからん。
なんでそこまで認証に拘るのか判らんが、認証にもいろいろありますわなぁ。
ＯＳが提供するもの、WebサーバやＡＰサーバが提供するもの、フィルターパターン使うもの、
ＤＩコンテナでインターセプトしたり、ＰＧで直接実装したり、ケースバイケースでございましょう。
ＯＳが提供するもの、WebサーバやＡＰサーバが提供するもの、フィルターパターン使うもの、
ＤＩコンテナでインターセプトしたり、ＰＧで直接実装したり、ケースバイケースでございましょう。
>>183
メイドのインスタンスくれ。
メイドのインスタンスくれ。
上のほうで出てたけど、セキュリティ関係は全部アスペクトでもういいだろ。
システムが入力を受け付ける。
システムがデータを計算する。
システムが画像を読み取る。
システムがエンティティを永続化する。
システムが計算結果を表示する。
システムがｳﾙｾｰﾎﾞｹを投げる。
システムが俺を金持ちにする。
システムがかわいい彼女を俺に(Ry
って全部システムでＯｋ？
システムがデータを計算する。
システムが画像を読み取る。
システムがエンティティを永続化する。
システムが計算結果を表示する。
システムがｳﾙｾｰﾎﾞｹを投げる。
システムが俺を金持ちにする。
システムがかわいい彼女を俺に(Ry
って全部システムでＯｋ？
セキュリティだけどユースケースに記載されちゃったら認証業務だろ？
AOP厨乙 ちゅぅかいいかげんウゼェ
俺はOOでメイドを作ることに非常に高い関心があるのだ。
厨扱いかよ。。
漫喫でメイドさんにチラチラ目が行くんだが、
はたしてこれは横断的関心事といえるのか・・・
いや、こっちの話。
はたしてこれは横断的関心事といえるのか・・・
いや、こっちの話。
>>196
シーケンス図よろ。
シーケンス図よろ。
・店に入る
・会員認証をする
・席に着く
・マンガを取りに行く
・飲み物を取りに行く
等、各々のロジックを実行するたびに「メイドに目をやる」という
共通処理を行うのなら、これは立派な「横断的関心事」だ。
「メイドに目をやる」という処理はアスペクトとして組み込む方が
それぞれのロジックの実装はシンプルになる。
・会員認証をする
・席に着く
・マンガを取りに行く
・飲み物を取りに行く
等、各々のロジックを実行するたびに「メイドに目をやる」という
共通処理を行うのなら、これは立派な「横断的関心事」だ。
「メイドに目をやる」という処理はアスペクトとして組み込む方が
それぞれのロジックの実装はシンプルになる。
メイドが何かする度に「メイドに目をやる」
これもアスペクトになるぞ。
これもアスペクトになるぞ。
ユースケース図
＿＿＿＿＿＿＿＿＿＿
,［俺アクター]｜ ＿＿＿＿_ |
〜二二二 | ／ ＼ |
（ ~∀'） −−−（ チラ見する ） ｜ [メイドアクター]
（ ） | ＼＿＿＿＿_／ ｜ (( 从 从 )）
| | | | ＿＿＿_ | （（*‘ー ‘））
（_＿）＿） ｜ ／ ＼ ｜ と＼▽／つ
｜ （ お仕事する ）−−− /二二二ゝ
｜ ＼＿＿＿_／ ｜ ∪ ∪
｜＿＿＿＿＿＿＿＿＿＿|
＿＿＿＿＿＿＿＿＿＿
,［俺アクター]｜ ＿＿＿＿_ |
〜二二二 | ／ ＼ |
（ ~∀'） −−−（ チラ見する ） ｜ [メイドアクター]
（ ） | ＼＿＿＿＿_／ ｜ (( 从 从 )）
| | | | ＿＿＿_ | （（*‘ー ‘））
（_＿）＿） ｜ ／ ＼ ｜ と＼▽／つ
｜ （ お仕事する ）−−− /二二二ゝ
｜ ＼＿＿＿_／ ｜ ∪ ∪
｜＿＿＿＿＿＿＿＿＿＿|
問題はそもそもチラ見をどう実装するかだな。
メイドはチラ見されたとき、どういう状態変化するのか？
たぶん・・・
表面上は、ニコニコ
内面は、「さっきからチラチラ見てんじゃねぇよキメェんだよっ」
かなぁ・・・特に見た目に変化はあらわないと思うが。
表面上は、ニコニコ
内面は、「さっきからチラチラ見てんじゃねぇよキメェんだよっ」
かなぁ・・・特に見た目に変化はあらわないと思うが。
不毛だな・・・
メイド喫茶の設計中・・・・
アスベストは体に良くないぞ
特に肺に良くないらしいぞ
骨肉種になるらしい
特に肺に良くないらしいぞ
骨肉種になるらしい
>>174
そのOO的でもシステム的でも1に当たる部分は専用の認証クラスを組むわけでしょ。
だとすると認証機能、というくくりのうちパスワード比較だけユーザのクラスでする、ってのが何か気持ち悪い。
なんとなく結合が密な感じもするし。
せっかく「認証クラス」という大層な名前ついてる割に、認証に関すること全部自分で出来ないのかよ！と思っちゃう。
ログインしちゃって、セッションメモリとかにユーザクラスがいる状態になったら、あとの事はユーザクラスに任せても
いいと思うんだよ。
このメニューに入れるか、とか、英語表示するか日本語表示するか、とかはユーザクラス内に書いたり、判断させたりしても
いいと思うんだけど。。。
そのOO的でもシステム的でも1に当たる部分は専用の認証クラスを組むわけでしょ。
だとすると認証機能、というくくりのうちパスワード比較だけユーザのクラスでする、ってのが何か気持ち悪い。
なんとなく結合が密な感じもするし。
せっかく「認証クラス」という大層な名前ついてる割に、認証に関すること全部自分で出来ないのかよ！と思っちゃう。
ログインしちゃって、セッションメモリとかにユーザクラスがいる状態になったら、あとの事はユーザクラスに任せても
いいと思うんだよ。
このメニューに入れるか、とか、英語表示するか日本語表示するか、とかはユーザクラス内に書いたり、判断させたりしても
いいと思うんだけど。。。
パスワードの代わりに指紋認証などにも拡張可能なように、とか
認証関連情報の格納場所を可変に、とか拡張性をきちんと考えると厄介だぞ。
そこはそれこそ設計の腕の見せ所で、簡単に決められるもんじゃない。
認証関連情報の格納場所を可変に、とか拡張性をきちんと考えると厄介だぞ。
そこはそれこそ設計の腕の見せ所で、簡単に決められるもんじゃない。
210 ：仕様書無しさん：2007/02/22(木) 16:11:51
211 ：OOP ◆SWtzLesEmM ：2007/02/22(木) 20:51:26
オブジェクト指向の勉強方法をオススメ下さい。
当方結城浩先生のJava本（上）を読みました。
クラス設計はどういう本読めば勉強できますか？
最初はやっぱ、関数をクラスで包むだけの形から入れば良いでしょうか？
当方結城浩先生のJava本（上）を読みました。
クラス設計はどういう本読めば勉強できますか？
最初はやっぱ、関数をクラスで包むだけの形から入れば良いでしょうか？
212 ：仕様書無しさん：2007/02/22(木) 21:16:34
オブジェクト指向を勉強するのに一番いい方法は
糞して寝ること。
メイド喫茶のコスチュームローテを
オブジェクト指向設計するのは、意味があると思われ。
オブジェクト指向設計するのは、意味があると思われ。
216 ：おじゃばさま：2007/02/22(木) 22:17:24
>211
関数をクラスで包んではダメです。
最初は構造体の項目をプライベートのフィールド変数に定義し、それに対するGetter/Setterを作る
所から始めましょう。次にそのSetter/Getterに処理を追加したり、処理のたくさん入ったGetterもどき
を新たに追加したりします。この時、今まで連続して記述していた処理は、それぞれのメソッドの中に
分割されて入る事になるでしょう。
表現はしにくいのですが、今まで横割りだったプログラムが縦割りになるぐらいの大きな変化があります。
これが出来るようになるには普通の人で半年ぐらいかかります。
それが完成したら、どんどん仕様変更や機能追加を行います。
変更を繰り返すことで、本当に処理や変数を記述するべき位置が分かってきます。
適切にオブジェクト指向で設計されたソースは、変更が入る度に洗練されて行きます。
これが出来るようになるには、1年半ぐらいかかります。
参考にするべきよい本はありません。
業務で使われていて、長い間変更が繰り返されている、社内開発のミドルウェアのソースなどを参考に
するといいでしょう。
もしないならI○MのHPやミドルなどにいいソースがあるので参考にするといいでしょう。
関数をクラスで包んではダメです。
最初は構造体の項目をプライベートのフィールド変数に定義し、それに対するGetter/Setterを作る
所から始めましょう。次にそのSetter/Getterに処理を追加したり、処理のたくさん入ったGetterもどき
を新たに追加したりします。この時、今まで連続して記述していた処理は、それぞれのメソッドの中に
分割されて入る事になるでしょう。
表現はしにくいのですが、今まで横割りだったプログラムが縦割りになるぐらいの大きな変化があります。
これが出来るようになるには普通の人で半年ぐらいかかります。
それが完成したら、どんどん仕様変更や機能追加を行います。
変更を繰り返すことで、本当に処理や変数を記述するべき位置が分かってきます。
適切にオブジェクト指向で設計されたソースは、変更が入る度に洗練されて行きます。
これが出来るようになるには、1年半ぐらいかかります。
参考にするべきよい本はありません。
業務で使われていて、長い間変更が繰り返されている、社内開発のミドルウェアのソースなどを参考に
するといいでしょう。
もしないならI○MのHPやミドルなどにいいソースがあるので参考にするといいでしょう。
>>216
本は読んだ方がいいと思うぞ、基本的な考え方は押さえとかないと、よっぽどの天才でも
ない限りいきなりソース読んでも遠回りだからな。へたすっと違う方向に行きかねん。
>>211
Amazonで、オブジェクト指向とかOOPで検索してレビュー数が多く評価の高い奴選んで１
冊ぐらいは読んだ方がいい。できれば何冊も読んで自分なりに咀嚼し実践してみるのが
いい。生兵法は怪我のもとだぞ。
本は読んだ方がいいと思うぞ、基本的な考え方は押さえとかないと、よっぽどの天才でも
ない限りいきなりソース読んでも遠回りだからな。へたすっと違う方向に行きかねん。
>>211
Amazonで、オブジェクト指向とかOOPで検索してレビュー数が多く評価の高い奴選んで１
冊ぐらいは読んだ方がいい。できれば何冊も読んで自分なりに咀嚼し実践してみるのが
いい。生兵法は怪我のもとだぞ。
>>211
>216の話は「カプセル化」とか「アクセサー(OR アクセッサー)」
あたりで検索すれば概念的なものは理解できるはず。
同じ結城浩先生の本でデザインパターンの入門書があるが、
オブジェクト指向やるなら読んでおいて損は無い。
デザインパターンの概念は初心者には少々難しいかもしれんが
サンプルコード見るだけでも十分勉強になると思う。
>216の話は「カプセル化」とか「アクセサー(OR アクセッサー)」
あたりで検索すれば概念的なものは理解できるはず。
同じ結城浩先生の本でデザインパターンの入門書があるが、
オブジェクト指向やるなら読んでおいて損は無い。
デザインパターンの概念は初心者には少々難しいかもしれんが
サンプルコード見るだけでも十分勉強になると思う。
219 ：仕様書無しさん：2007/02/23(金) 01:24:46
このアホコテは本当にうぜーなぁ。
こういう典型的な俺俺オブジェクト指向詐欺師がいるからオブジェクト指向が広まらんのだろう。
211はインターフェースクラスの定義や使われ方に注目してデザインパターン勉強しろ。
終わったらメイヤーのオブジェクト指向入門読め。1版な。2版は初心者には重いだろう。
こういう典型的な俺俺オブジェクト指向詐欺師がいるからオブジェクト指向が広まらんのだろう。
211はインターフェースクラスの定義や使われ方に注目してデザインパターン勉強しろ。
終わったらメイヤーのオブジェクト指向入門読め。1版な。2版は初心者には重いだろう。
ドメインドリブンデザインて本読め。
英語だがわかりやすい。
英語だがわかりやすい。
222 ：おじゃばさま：2007/02/23(金) 09:37:26
最初にデザインパターンの本を読むのはお勧めしない。
デザインパターンと言うのはオブジェクト指向実装例の一種で、しかも少々特殊な例である。
そのため、オブジェクト指向を理解した後で、参考のために読むのがいいだろう。
ちなみに最初にデザインパターンの本を読んでしまって、これをオブジェクト指向の本質だと誤解し、
自分で組むプログラムを全てを、強引にデザインパターンに当てはめてコーディングし破綻する人が
Sヨネタに出て来る。
初心者にデザインパターンを勧めるのは、タチの悪いジョークなので本気にしないほうがよい。
デザインパターンと言うのはオブジェクト指向実装例の一種で、しかも少々特殊な例である。
そのため、オブジェクト指向を理解した後で、参考のために読むのがいいだろう。
ちなみに最初にデザインパターンの本を読んでしまって、これをオブジェクト指向の本質だと誤解し、
自分で組むプログラムを全てを、強引にデザインパターンに当てはめてコーディングし破綻する人が
Sヨネタに出て来る。
初心者にデザインパターンを勧めるのは、タチの悪いジョークなので本気にしないほうがよい。
デザパタってオブジェクト指向を実践する上での指南書だと思ってたけど。
意識するのとしないのとでは可読性も効率も全然違ってくる。
意識するのとしないのとでは可読性も効率も全然違ってくる。
224 ：仕様書無しさん：2007/02/23(金) 09:59:30
>>223
デザパタって今まで構造化プログラミングで慣れてきた人がいきなり入るのは
少々敷居が高い気がするなあ。
まずはクラスの概念、多態性と差分プログラミング、で簡単なプログラムを数本書いてからでいいと思う。
デザパタって今まで構造化プログラミングで慣れてきた人がいきなり入るのは
少々敷居が高い気がするなあ。
まずはクラスの概念、多態性と差分プログラミング、で簡単なプログラムを数本書いてからでいいと思う。
またでざぱたですか？ｗ
単なる知恵袋を後生大事にするのは如何なものかと。
伊藤家の食卓ネタはあくまでそれレベル。
単なる知恵袋を後生大事にするのは如何なものかと。
伊藤家の食卓ネタはあくまでそれレベル。
デザパタは言ってみたらお手本であり共通規格だと思うよ。
みんなが実践して初めて意味がある。
みんなが実践して初めて意味がある。
>>222
>デザインパターンと言うのはオブジェクト指向実装例の一種で、しかも少々特殊な例である。
一般人がこう断定しちゃうってどうなのよ。誤解を与えないためにもせめて、「俺は〜と思う」ぐらい
の表現にしておくべきかと。
デザパタにも、テンプレートメソッド、イティレータ、シングルトン等、特殊？でない一般的なものも含
まれているよ。デザパタを理解して始めてＯＯＰを理解したと言えるのではないかと思う。
Gofの23個のデザパタを理解するには基礎を覚えた人で２年ぐらいはかかると、俺は思います。
>デザインパターンと言うのはオブジェクト指向実装例の一種で、しかも少々特殊な例である。
一般人がこう断定しちゃうってどうなのよ。誤解を与えないためにもせめて、「俺は〜と思う」ぐらい
の表現にしておくべきかと。
デザパタにも、テンプレートメソッド、イティレータ、シングルトン等、特殊？でない一般的なものも含
まれているよ。デザパタを理解して始めてＯＯＰを理解したと言えるのではないかと思う。
Gofの23個のデザパタを理解するには基礎を覚えた人で２年ぐらいはかかると、俺は思います。
228 ：仕様書無しさん：2007/02/23(金) 10:45:27
２年。ｗ
そんなのどうとでもいえるわな。
普通は見ればとりあえず判る、で実際に使いこなせるなんて一生かかっても無理なのが普通。
結局、あんな綺麗に適用できる事例なんて無いから。
そんなのどうとでもいえるわな。
普通は見ればとりあえず判る、で実際に使いこなせるなんて一生かかっても無理なのが普通。
結局、あんな綺麗に適用できる事例なんて無いから。
だから「参考に」するんだろうが
オブジェクト指向の基礎を理解して基本的なクラスの設計、実装ができるようになったあとで
デザインパターンを理解すると適用箇所の勘どころがつかめる。
デザインパターンを理解すると適用箇所の勘どころがつかめる。
有名どころのオープンソースのソースを読むとデザパタがさりげなく、
というか当たり前に適用されている。ファクトリメソッド、コマンド、
シングルトン、ビジター、普通に使われている。
イティレータ、デコレータ、プロトタイプ等はJava等、言語標準のライ
ブラリで提供されてるし、実装にも使われている。
デザパタを絵に描いた餅などと言うのは食わず嫌いか単に勉強不足な
だけだと思う。良し悪しの判断はそれぞれすればいいと思うが、一通
り実践してみなければその判断すらできないだろう。ましてや応用等
できるはずもない。
というか当たり前に適用されている。ファクトリメソッド、コマンド、
シングルトン、ビジター、普通に使われている。
イティレータ、デコレータ、プロトタイプ等はJava等、言語標準のライ
ブラリで提供されてるし、実装にも使われている。
デザパタを絵に描いた餅などと言うのは食わず嫌いか単に勉強不足な
だけだと思う。良し悪しの判断はそれぞれすればいいと思うが、一通
り実践してみなければその判断すらできないだろう。ましてや応用等
できるはずもない。
233 ：仕様書無しさん：2007/02/23(金) 11:14:40
OOスレでは散々の議論になるが、デザパタ覚えただけなやつは、サルと一緒。
使いたくてしょうがないくて、使うことが目的で、使ったら死ぬまで使う。
本来の目的を忘れてでざぱた適用に必死なのは滑稽。
使いたくてしょうがないくて、使うことが目的で、使ったら死ぬまで使う。
本来の目的を忘れてでざぱた適用に必死なのは滑稽。
金槌を初めて手にした子供は全てのものが釘に見える。
...と、デザパタすら覚えられない>>233 がオレオレ解釈して自分を慰めております。
237 ：仕様書無しさん：2007/02/23(金) 12:06:06
だから、でざぱたなんぞ覚えるものじゃないんだよ。
そんなのあったなー程度を知っとけばいいの。
で、実際に使えそうだなーってときに見て、フィットさせて使えばいいだけ。
そもそも、きちんとGOFなり読んでれば、覚えるなんて考えが出ること自体おかしいと思うが。
そんなのあったなー程度を知っとけばいいの。
で、実際に使えそうだなーってときに見て、フィットさせて使えばいいだけ。
そもそも、きちんとGOFなり読んでれば、覚えるなんて考えが出ること自体おかしいと思うが。
そうそう、デザインパターンなんて何となくしっときゃ後で調べて適用できる
つーか、俺のロジックがデザパタになる
俺３日で覚えたけど。。そんなに大変？
覚えると理解するの違いが判らない人には無理だよ。
覚えるだけなら幼稚園生のほうが凄い。
覚えるだけなら幼稚園生のほうが凄い。
いい加減黙れって＞お邪魔
覚えたってのは名前とか構造のこと。理解するだけだったら２日でできたけど。
でざぱたは理解して使うものであって、覚えるものじゃねーよ。
本見て勉強したデザパタなんて使い物にならない。
本見て勉強したデザパタなんて使い物にならない。
なぜ俺が２日で理解できたか、それはほとんどを実践の中で
それとしらず使っていたからなんだな。 おっと、仕事、仕事
それとしらず使っていたからなんだな。 おっと、仕事、仕事
知らないうちに使っているものを明文化したものがデザインパターン
同じような処理でも実装は個人によって違うが
デザインパターンという明文化された基準を共有することによって
効率的で均一なコードが書けるようになる
同じような処理でも実装は個人によって違うが
デザインパターンという明文化された基準を共有することによって
効率的で均一なコードが書けるようになる
デザパタ適用しても均一なコードにはなりえないのだが。
まあ、覚えて使ってる人は均一なのかもしれないが。ｗ
まあ、覚えて使ってる人は均一なのかもしれないが。ｗ
さすが暖冬
春厨が目を覚ましたか
春厨が目を覚ましたか
249 ：おじゃばさま：2007/02/23(金) 21:25:52
>227
初心者に説明する場合は、多少の例外があったとしても断定した方がよい。
また普段使われない例が大量に入っているデザインパターンは、初心者には有害となる。
初心者に教えるコツは情報を絞る事である。
俺が言いたいのは、デザインパターンの学習が全くの無駄だと言う事ではない。
オブジェクト指向をマスターした後なら、いい勉強になるだろう。
オブジェクト指向をマスターしている人で、デザインパターンを知らない人は一度見てみるといい。
理解するのに3日もかからないだろうから。
初心者に説明する場合は、多少の例外があったとしても断定した方がよい。
また普段使われない例が大量に入っているデザインパターンは、初心者には有害となる。
初心者に教えるコツは情報を絞る事である。
俺が言いたいのは、デザインパターンの学習が全くの無駄だと言う事ではない。
オブジェクト指向をマスターした後なら、いい勉強になるだろう。
オブジェクト指向をマスターしている人で、デザインパターンを知らない人は一度見てみるといい。
理解するのに3日もかからないだろうから。
| 釣れますか？ ,
＼ ,／ヽ
￣∨￣￣￣￣￣￣￣ ,／ ヽ
∧＿∧ ∧∧ ,／ ヽ
（ ´∀｀） (ﾟДﾟ,,),／ ヽ
（ ） (|おじゃ@ ヽ
｜ ｜ | ＿＿_ 〜|ば | ヽ
（_＿）＿） |――|. ∪∪ ヽ
￣￣￣￣￣￣￣￣￣￣￣￣| ヽ
／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~
⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡 〜 〜〜 〜〜 〜〜 〜 〜
＼ ,／ヽ
￣∨￣￣￣￣￣￣￣ ,／ ヽ
∧＿∧ ∧∧ ,／ ヽ
（ ´∀｀） (ﾟДﾟ,,),／ ヽ
（ ） (|おじゃ@ ヽ
｜ ｜ | ＿＿_ 〜|ば | ヽ
（_＿）＿） |――|. ∪∪ ヽ
￣￣￣￣￣￣￣￣￣￣￣￣| ヽ
／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~
⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡 〜 〜〜 〜〜 〜〜 〜 〜
勤勉な方に多い行動パターンとして，
一つのことを深く掘り下げすぎるというのがあります。
これは大変すばらしいことなのですが，
分析や設計をするうえで視野が狭いというのは，致命的な欠点と言えます。
一つのことを深く掘り下げすぎるというのがあります。
これは大変すばらしいことなのですが，
分析や設計をするうえで視野が狭いというのは，致命的な欠点と言えます。
252 ：仕様書無しさん：2007/02/23(金) 23:18:07
オブジェクト指向の本質がわからないんだっだらさ構造化プログラミングで書いてよ
継承、委譲てんこ盛りのオブジェクト指向スパゲッティのメンテでもうぐったりだ…
継承、委譲てんこ盛りのオブジェクト指向スパゲッティのメンテでもうぐったりだ…
>>252
C++で多重継承を乱用されるともう手のつけようがないよね。
C++で多重継承を乱用されるともう手のつけようがないよね。
254 ：仕様書無しさん：2007/02/24(土) 00:41:50
DQNなプログラマの存在を無視せず、現実的にいくとすれば、
rubyで書くのが一番マトモだろ。良い感じで制限が有って。
C++は自由度高すぎて最悪。JAVAはまあまあ。
rubyで書くのが一番マトモだろ。良い感じで制限が有って。
C++は自由度高すぎて最悪。JAVAはまあまあ。
>>254
つ D言語
つ D言語
なんでいきなりRubyが・・・
Rubyはいいよねー
258 ：仕様書無しさん：2007/02/24(土) 00:57:54
多重継承っつーかそもそも最近じゃ継承は使わない方向なんだが。
お前らなんで継承がダメなのかちゃんとわかってんの？
お前らなんで継承がダメなのかちゃんとわかってんの？
多重継承は殆どの場合インタフェースで表現できるから
260 ：仕様書無しさん：2007/02/24(土) 01:06:11
委譲てんこ盛りの
何が問題？
何が問題？
オーバーライドめ〜〜〜
262 ：仕様書無しさん：2007/02/24(土) 01:16:34
>>256
ruby以外のオブジェクト指向言語には複数のスーパークラスから
継承する機能(多重継承)を持つものもあるが，rubyは意図的に
この機能を持っていない．
その代わりモジュールを使ったmixinという方法で同じことを
実現できる．
多重継承とmixinの違いは以下の通りである．
* モジュールはインスタンスを生成しない(抽象クラスであることが保証される)．
* (主たる)継承関係がtree構造になることが保証される．
どちらもクラスの関係の複雑さを抑える働きがある．
rubyが多重継承を持っていない理由は，それが複雑さの
原因になるからだ．クラスが複数のスーパークラスを持ち，
関係のネットワークを形成する状況は，大体において
人間の頭には複雑すぎることが多い．
すくなくともDQNには無理だ．
ruby以外のオブジェクト指向言語には複数のスーパークラスから
継承する機能(多重継承)を持つものもあるが，rubyは意図的に
この機能を持っていない．
その代わりモジュールを使ったmixinという方法で同じことを
実現できる．
多重継承とmixinの違いは以下の通りである．
* モジュールはインスタンスを生成しない(抽象クラスであることが保証される)．
* (主たる)継承関係がtree構造になることが保証される．
どちらもクラスの関係の複雑さを抑える働きがある．
rubyが多重継承を持っていない理由は，それが複雑さの
原因になるからだ．クラスが複数のスーパークラスを持ち，
関係のネットワークを形成する状況は，大体において
人間の頭には複雑すぎることが多い．
すくなくともDQNには無理だ．
継承はオーバーライドや、親の実装を引き継ぐので複雑化を招きやすい。
インタフェースならメソッドが存在することを強制するだけだからまだいい。
インタフェースならメソッドが存在することを強制するだけだからまだいい。
多重継承よりオーバーロードが嫌いな俺ガイル
理屈よりも感覚的に嫌い
理屈よりも感覚的に嫌い
DQNにプログラム言語を使わせたいならVBかCOBOLでもやらせてろ
ま、JavaやRubyでも構わないけどな
間違ってもC++やLispなどは使ってはいけない
ま、JavaやRubyでも構わないけどな
間違ってもC++やLispなどは使ってはいけない
PythonならまだしもRubyは完全にC++やLisp側の言語ですぜ
どうしても言語仕様の話になるんだな・・・
多重継承で問題なのは、菱形継承とかで起こりがちな同階層同シグネチャのメンバ関数（メソッド）が
定義されている場合に、どちらを優先するのか（あるいはどちらも排除して改めて定義させるか）を
機械的には決められないってことだろ？ Ruby のモジュールもこの問題には対処できていないから
Smalltalk の Traits からのパクリを Matz は模索しているしているところ。
http://www.rubyist.net/~matz/20060224.html#p02
定義されている場合に、どちらを優先するのか（あるいはどちらも排除して改めて定義させるか）を
機械的には決められないってことだろ？ Ruby のモジュールもこの問題には対処できていないから
Smalltalk の Traits からのパクリを Matz は模索しているしているところ。
http://www.rubyist.net/~matz/20060224.html#p02
多重継承が便利そうなケースってどんな場合よ？
俺は今まで、あぁ多重継承使いたいぁ〜、なんて状況に遭遇したことがないんだが。
必要か？
俺は今まで、あぁ多重継承使いたいぁ〜、なんて状況に遭遇したことがないんだが。
必要か？
>>270
たとえばJavaのスレッドで「Threadを直接継承する方法」と
「Runnableを実装してThreadに渡す方法」の２通りの方法が
存在するのなんて多重継承を禁止した弊害だと思うが。
でもC++のようにダイアモンド継承をまったくガード出来ない仕様も怖いよな。
もし引き継いだコードがC++のstreamクラスみたいな設計されてたら泣くよ。
たとえばJavaのスレッドで「Threadを直接継承する方法」と
「Runnableを実装してThreadに渡す方法」の２通りの方法が
存在するのなんて多重継承を禁止した弊害だと思うが。
でもC++のようにダイアモンド継承をまったくガード出来ない仕様も怖いよな。
もし引き継いだコードがC++のstreamクラスみたいな設計されてたら泣くよ。
Javaにもそのうちmix-inが標準実装されんじゃね？
OOが銀の弾丸と思ってる人は
DQNという事でw
DQNという事でw
文末にwをつける人は
DQNという事でw
DQNという事でw
>276
自らDQN宣言ですか？
お前はプログラムは組むなよw
っていうか、違う業界逝け。
自らDQN宣言ですか？
お前はプログラムは組むなよw
っていうか、違う業界逝け。
C++はテンプレートがあるから多重継承を強力に使いこなす方法があるけど、
javaやc#じゃ無理だな。
javaやc#じゃ無理だな。
つ Generic
>>279
C++知らない奴はすっこんでろ
C++知らない奴はすっこんでろ
OOに限った話じゃないが
物事には必ず制約がある
。
しかし、レベルの低い技術者は
その境界線がまず見えてない。
その結果、0か1の様な短絡思考になる。
つまり、OO信者もアンチOOも
等しくレベルが低いって事だ。
物事には必ず制約がある
。
しかし、レベルの低い技術者は
その境界線がまず見えてない。
その結果、0か1の様な短絡思考になる。
つまり、OO信者もアンチOOも
等しくレベルが低いって事だ。
頭悪そうな文章だなぁ
>282
レベル低そうな文章だなぁ
レベル低そうな文章だなぁ
やっぱさ、いや真面目な話ね。
良書って評判の本読んで、自分で考えないと駄目なんだよな。
良書って評判の本読んで、自分で考えないと駄目なんだよな。
このスレで文章の後を無駄に改行してたのは全部お前かよ。
>284
真面目な話さ
意欲的に学習する技術者と
そうでない技術者の差は
学生の頃の比じゃないよな。（一部の天才は除く）
単純に考えても年数比で差が開くし、
実際のところ複利法の様に差が開くからな。
真面目な話さ
意欲的に学習する技術者と
そうでない技術者の差は
学生の頃の比じゃないよな。（一部の天才は除く）
単純に考えても年数比で差が開くし、
実際のところ複利法の様に差が開くからな。
>285
妄想乙w
OOPを勉強します！
みんなよろしく！
みんなよろしく！
勉強なんかいらねぇよw、OOPなんてなぁ勘でやっとけw
開発、設計のスレなのにOOPって言ってる奴はOOPを理解できないだろうね
>>290
OOA、OODあたりを勉強しないといけないですか？
OOA、OODあたりを勉強しないといけないですか？
スレタイの漢字が読める程度の学習は。
スレタイの漢字が読める程度の学習は。
今から
いちばんやさしいオブジェクト指向の本 井上樹
を読んでみる。
いちばんやさしいオブジェクト指向の本 井上樹
を読んでみる。
＞ ラマヌジャンは多くの定理で誤りを犯したが、それが彼の天才をわずかでも傷つけることはなかった。
＞ しかし多くの人は、自分のアイデアを他の人に伝えようとする冒険の過程で時折間違いを犯すよりも、
＞ 何か自明な正しいことを言ったり、あるいは単に誰にも聞かれないことの方を好むようだ。
＞ しかし多くの人は、自分のアイデアを他の人に伝えようとする冒険の過程で時折間違いを犯すよりも、
＞ 何か自明な正しいことを言ったり、あるいは単に誰にも聞かれないことの方を好むようだ。
299 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/25(日) 00:23:44
こんなことより仕様変更なくしたほうが数倍効率上がるのに
某会社では言語能力に優れている奴は
オブジェクト指向にも対応しやすいとして
積極的に帰国子女を入れているようだけど
どうなんだろうか？
あと、オブジェクト指向を理解するには
一定の知能が必要という考え方も
あるようですが
どうなんでしょうか？
オブジェクト指向にも対応しやすいとして
積極的に帰国子女を入れているようだけど
どうなんだろうか？
あと、オブジェクト指向を理解するには
一定の知能が必要という考え方も
あるようですが
どうなんでしょうか？
>>302 一定の知能が必要
おまえが理解できずに挫折したところをみると必要なんだろ
おまえが理解できずに挫折したところをみると必要なんだろ
>>302
オブジェクト指向は、むしろ馬鹿指向と思われる。
・自販機の内部処理がどうなってるか知っている人間は少ないが、
自販機で買い物出来ない人間はもっと少ない。
・自販機を当たりつき自販機に改造するとき、自販機の内部処理が
どうなっているか知る必要は無い。
オブジェクト指向は、むしろ馬鹿指向と思われる。
・自販機の内部処理がどうなってるか知っている人間は少ないが、
自販機で買い物出来ない人間はもっと少ない。
・自販機を当たりつき自販機に改造するとき、自販機の内部処理が
どうなっているか知る必要は無い。
で？
306 ：仕様書無しさん：2007/02/25(日) 20:05:46
>>304
すまんが何を言いたいのかさっぱり分からん。
すまんが何を言いたいのかさっぱり分からん。
>>307
それはオブジェクト指向的じゃないからダメだな
それはオブジェクト指向的じゃないからダメだな
つまり、馬鹿でも自販機は使えるし、馬鹿でも自販機を当たりつき自販機に改造できる
ということが言いたいんだろ。だから馬鹿指向と。
ということが言いたいんだろ。だから馬鹿指向と。
310 ：仕様書無しさん：2007/02/25(日) 20:42:17
311 ：仕様書無しさん：2007/02/25(日) 20:44:55
馬鹿にも自販機は使えるが、馬鹿が自販機を一から作るのは無理だろ。
313 ：仕様書無しさん：2007/02/25(日) 21:10:30
ぉまぇもなｗ
自販機を例にするなら確実にたとえが馬鹿。
基本の自販機機能に対して何を実現するかが各実装だろ？
ジュースでも切符でも得ろ本でも。
実装は馬鹿でも出来るが、基本のコンポーネントはまた別。
基本の自販機機能に対して何を実現するかが各実装だろ？
ジュースでも切符でも得ろ本でも。
実装は馬鹿でも出来るが、基本のコンポーネントはまた別。
自販機作るなら内部知らんとつくれないな。
っていうか、自販機なら
当たり付きの機能部分の方が
コスト掛かるんじゃないの？
知らんけどw
当たり付きの機能部分の方が
コスト掛かるんじゃないの？
知らんけどw
>>316
内蔵する、クーラやヒータの仕組みまで知る必要はない。
内蔵する、クーラやヒータの仕組みまで知る必要はない。
運用するにはしらないと出来ないな。
おまいら本当にわかってんのかｗ
おまえらが上っ面のコーディングしかしてないことがよくわかった
オブジェクト指向について語るのは無理
オブジェクト指向について語るのは無理
>>324「揉める」＝「判ってない」って思ってるらしいな。
327 ：仕様書無しさん：2007/02/25(日) 23:16:41
俺が結論を言う、金儲けに勤しめ、世の中銭や、銭！
結局、銭指向か...うちの社長と一緒だな。
>>330
どうずれてんのか説明してもらおうじゃない。
どうずれてんのか説明してもらおうじゃない。
333 ：仕様書無しさん：2007/02/26(月) 00:00:22
自販機のシミュレータをオブジェクト指向で作るのって入門者の課題であるだろ
お前ら、社内研修でやらなかったのか？
お前ら、社内研修でやらなかったのか？
OODで説明よろw
つぅかよ、自販機のセッターつったら、商品の補充とつり銭の補充なわけだろ。
しかし、このセッターを使えるのは、商品担当者だけで、購入者にはこのメソッド
を使う権限は与えられてないわけだ。
これって、Javaでどう表現すんのよ。メソッドをpublicにはできんわなぁ。つぅと
protected にして、担当者が自販機を継承すんのか？ そりゃおかしいだろ。
それじゃぁ担当者が商品とつり銭溜め込んじまうわなぁ。さぁ、こまった。どうする？
C++ だとfriend なんつう便利な指定子があるが、Javaにはねぇしなぁ・・・
あぁ！ 自販機のメソッドのアクセスレベルをpackageにして、担当者を同じパッ
ケージにしとけばいいのか・・・すまんかった。出直してくる。
しかし、このセッターを使えるのは、商品担当者だけで、購入者にはこのメソッド
を使う権限は与えられてないわけだ。
これって、Javaでどう表現すんのよ。メソッドをpublicにはできんわなぁ。つぅと
protected にして、担当者が自販機を継承すんのか？ そりゃおかしいだろ。
それじゃぁ担当者が商品とつり銭溜め込んじまうわなぁ。さぁ、こまった。どうする？
C++ だとfriend なんつう便利な指定子があるが、Javaにはねぇしなぁ・・・
あぁ！ 自販機のメソッドのアクセスレベルをpackageにして、担当者を同じパッ
ケージにしとけばいいのか・・・すまんかった。出直してくる。
補充メソッドの引数に担当者インタフェースを取れば問題ないんでわ？
多分>>336みたいな発想が出てこないのって
自販機は人間が使うものっていう固定観念があるからだよねｗ
自販機は人間が使うものっていう固定観念があるからだよねｗ
そうだよ、>>336みたいにすっと、窃盗団が偽担当者を作って悪さしね？
現実モデルに倣うとしたら、やっぱり担当者にアクセスするための鍵を
もたせるべきだろう。つぅかなんでインターフェース？ AOP厨か？
現実モデルに倣うとしたら、やっぱり担当者にアクセスするための鍵を
もたせるべきだろう。つぅかなんでインターフェース？ AOP厨か？
おまえ何の話してんだよｗ
OOなんとかだよ。このスレでよくきくアレだよっ！
オブジェクト指向ってのは、結局現実と仮想の鬩ぎ合いなんだよな。
あまりにも現実的だと、現実がそうであるように複雑系になっていく。
現実からどんだけ妥協できるか、経済性を念頭においてどこに落とし
所をもってくるか、その辺の見極めにセンスが問われるわな。
あまりにも現実的だと、現実がそうであるように複雑系になっていく。
現実からどんだけ妥協できるか、経済性を念頭においてどこに落とし
所をもってくるか、その辺の見極めにセンスが問われるわな。
＞オブジェクト指向ってのは、結局現実と仮想の鬩ぎ合いなんだよな。
誰がそんなこと言ったの
独立性を高め依存性を低くするためのただの方法論だよ
誰がそんなこと言ったの
独立性を高め依存性を低くするためのただの方法論だよ
つまり、
人はひとりでは生きられない
が
オブジェクトは一個でも生きられる
ってこと？
人はひとりでは生きられない
が
オブジェクトは一個でも生きられる
ってこと？
うちの爺ちゃんが言ってたよ、
オブジェクトってのはなぁ、独立心が強いわりには、他のオブジェクトに
依存したがるんだって、私は誰にも染まらないなんていいながら八方美人
なんだって。可笑しいよねっ
オブジェクトってのはなぁ、独立心が強いわりには、他のオブジェクトに
依存したがるんだって、私は誰にも染まらないなんていいながら八方美人
なんだって。可笑しいよねっ
>>344
うまいこと言うじじだなっ。
うまいこと言うじじだなっ。
訂正＞うまいこと言うじじいだなっ。
>>336 だと、担当者インターフェースをどこでも生成できちゃうと
結局、アクセス制限にならないよな。むやみに複雑にしてるだけ
のような気がするが。
やっぱ担当者と自販機を同一パッケージにして、担当者をシン
グルトン、若しくはファクトリメソッドとの併用ってパターンでいいと
思うが・・・
結局、アクセス制限にならないよな。むやみに複雑にしてるだけ
のような気がするが。
やっぱ担当者と自販機を同一パッケージにして、担当者をシン
グルトン、若しくはファクトリメソッドとの併用ってパターンでいいと
思うが・・・
自販機開ける鍵を補充担当者はもっている。
だから自販機のステートチャート書いて、状態が解放中の時だけ補充可能なようにセッターにチェック処理いれとけばよくね？
だから自販機のステートチャート書いて、状態が解放中の時だけ補充可能なようにセッターにチェック処理いれとけばよくね？
自販機のドア開いてない時にセッター呼べばセキュリティ例外だろ。
オブ的にはインタフェースを実装してればいいだろ
セキュリティ云々は別の話
ましてfriendつけたら他クラスに内部構造を滅茶苦茶にされるだろ
セキュリティ云々は別の話
ましてfriendつけたら他クラスに内部構造を滅茶苦茶にされるだろ
そんなに鍵が欲しいなら
補充メソッド内で鍵の確認でも何でもしたらいいよ
アクセス制限を何か勘違いしてる
補充メソッド内で鍵の確認でも何でもしたらいいよ
アクセス制限を何か勘違いしてる
オブジェクト状態も関係ない、ステートレスな自販機作ろうってか(笑)
商品補充しなくても無限にジュースが出てくるんですか？
状態考慮すれば自販機インターフェースの開けるメソッドに鍵渡せば済む話なのに
なんで担当者インターフェースを渡すとかになってるんだ。
商品補充しなくても無限にジュースが出てくるんですか？
状態考慮すれば自販機インターフェースの開けるメソッドに鍵渡せば済む話なのに
なんで担当者インターフェースを渡すとかになってるんだ。
担当者インタフェースを実装するものは誰でも
商品補充のメソッドを実装していることを保証するからだ
商品補充のメソッドを実装していることを保証するからだ
この場合Visitorパターンだよね・・・
>>343
なんでそんなもん保証しなきゃなんねんだよw 目的を見失ってねぇか？
寧ろ担当者に自販機インターフェース渡せよ。
アクセス制限かけたかったら自販機のメソッドの中で instanceof で
確認すればいいだろ。
なんでそんなもん保証しなきゃなんねんだよw 目的を見失ってねぇか？
寧ろ担当者に自販機インターフェース渡せよ。
アクセス制限かけたかったら自販機のメソッドの中で instanceof で
確認すればいいだろ。
どっちにどっちを渡そうが好きにしたらいいよ
bool 補充(IOperator operator)
{
bool 補充(IOperator operator)
{
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を実装するだけで
商品の補充が保証される。
それともいちいち担当者ごとに補充するためのメソッド書くのか？
担当者が変わったらどう実装するの？
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を実装するだけで
商品の補充が保証される。
それともいちいち担当者ごとに補充するためのメソッド書くのか？
担当者が変わったらどう実装するの？
すまん、このパターンで面倒臭さと引き換えに何が解決されているのか
さっぱり分からないんだが。
さっぱり分からないんだが。
俺はどうして判ってもらえないのか理解に苦しむ
担当者のバリエーションが増えた場合に便利なんじゃないの多分。
現在の「スレ違いのレス率」は推定約70%。
・・・って、ｵﾏｲﾗいい加減にしろ
・・・って、ｵﾏｲﾗいい加減にしろ
スレタイにOOPを付けたのがそもそもの間違い。
なくても、プログラムのことしかいわない奴がいるから一緒だが。
なくても、プログラムのことしかいわない奴がいるから一緒だが。
自分なんてプログラミングしないけど、本で得た知識だけでOOP語るもんね。
364 ：仕様書無しさん：2007/02/26(月) 12:52:17
>>362
オブジェクト指向設計についてなんか語ってみてくれよ、語れるもんならw
オブジェクト指向設計についてなんか語ってみてくれよ、語れるもんならw
365 ：仕様書無しさん：2007/02/26(月) 13:06:43
>>364
「何か語ってみてくれよ」って「何かギャグやって」くらいハードル高いムチャ振りだと思う。
「何か語ってみてくれよ」って「何かギャグやって」くらいハードル高いムチャ振りだと思う。
366 ：仕様書無しさん：2007/02/26(月) 13:13:14
ばかやろ、プロならやるんだよ
プロなら無料ではやらないよ
368 ：仕様書無しさん：2007/02/26(月) 18:57:53
オブジェクト指向は銭指向を実現するたねに開発されたソフトウェア産業分野の手法の１つです。
オブジェクト指向を理解するためには銭指向を先ず理解しなければなりません。
ソフトウェア産業分野での銭指向のわかりやすい実例としては、派遣PGがあります。
オブジェクト指向を理解するためには銭指向を先ず理解しなければなりません。
ソフトウェア産業分野での銭指向のわかりやすい実例としては、派遣PGがあります。
勘定指向プログラミング AOP(Account Oriented
Programming)のはじまりであった
Programming)のはじまりであった
370 ：おじゃばさま：2007/02/26(月) 20:45:18
世の中で一番重要なのは銭ではありません。健康です。
健康志向プログラミングの始まりであった。
健康志向プログラミングの始まりであった。
人類の歴史は貧困と病気との闘いの歴史
2chシステムをOOで構築するとオブジェクトは何になるんだ？
板、スレッド、レス辺りかね。
CGIに比べればOOだとレス抽出とかソートとかの拡張が簡単にできそうだな。
板、スレッド、レス辺りかね。
CGIに比べればOOだとレス抽出とかソートとかの拡張が簡単にできそうだな。
datファイルとsubject.txtが無いと専ブラが動かない
このスレを見ている人はこんなスレも見ています。→鉄拳かよ・・・
オブジェクトの永続化先をファイルにすればいいよ
だーかーらあああああ
なぜ流行らないの？
なぜ流行らないの？
設計できる奴を集めれないから
上の奴らは設計者、プログラマを代替可能なリソースとしか見てない。
つまり俺らは人月で計算される個性の無い馬車馬なんだよ。
つまりOOなんて俗人的なオブジェクトでシステム組むなんて夢物語ってことさ。
つまり俺らは人月で計算される個性の無い馬車馬なんだよ。
つまりOOなんて俗人的なオブジェクトでシステム組むなんて夢物語ってことさ。
プログラマ＝コードを書く機械
という認識なら、OOD/OOPよりも従来のウォーターフォール的手法のほうが
やりやすいよ
という認識なら、OOD/OOPよりも従来のウォーターフォール的手法のほうが
やりやすいよ
プログラマ蔑視だな、差別だ、>>379のプログラマはコードを産む機械発言の謝罪と保証を・・・。
個人レベルでの生産性が100倍違うのがザラなのに
「プログラマ＝コードを書く機械という認識なら」
こんな前提を考慮するだけ空しいわ
「プログラマ＝コードを書く機械という認識なら」
こんな前提を考慮するだけ空しいわ
現実、そういう認識で人月単価で人身売買が行われているわけだが。
>>382
それは皆知っているし、それが間違いのもとだということも知っている。
更にいえば、営業的な側面ではウォータフォールにするしかない事も知っているし
>>381の状況下においてはそれが現場でうまく機能しないことも知っている。
それは皆知っているし、それが間違いのもとだということも知っている。
更にいえば、営業的な側面ではウォータフォールにするしかない事も知っているし
>>381の状況下においてはそれが現場でうまく機能しないことも知っている。
それでありながら開発モデルを再検討することは
まったく考慮されない
まったく考慮されない
385 ：仕様書無しさん：2007/02/27(火) 22:51:50
開発プロセスをＸＰに変更したら、大規模開発じゃ嫌でもオブジェクト指向になるだろうよ。
ウォーターフォールでやる場合、ソフトウェアの進化や成長を無視するからオブジェクト指向で開発する意味が無くなるからな。
ウォーターフォールでやる場合、ソフトウェアの進化や成長を無視するからオブジェクト指向で開発する意味が無くなるからな。
プロセスと手法は別に直結せんがね。
>>385は典型的なしったか、覚えた言葉を使いたいだけの猿。
>>385は典型的なしったか、覚えた言葉を使いたいだけの猿。
>>383
ぶっちゃけ、ＰＪの成功失敗って末端のＰＧの個人レベルに思いっきり依存してるよねｗ
ぶっちゃけ、ＰＪの成功失敗って末端のＰＧの個人レベルに思いっきり依存してるよねｗ
Ｘ個人レベル
○個人のスキルレベル
○個人のスキルレベル
で、オブジェクト指向が流行らない理由は？
メーカーでは流行ってる（踊らされてる）けど、
偽装請負PGが（不勉強で）使いこなせてないだけだと思うけどね。
メーカーでは流行ってる（踊らされてる）けど、
偽装請負PGが（不勉強で）使いこなせてないだけだと思うけどね。
つか今現在オブジェクト指向以外で何らかの分析設計手法が既に流行っているってのならともかく、
相対的に見てオブジェクト指向がどうかんがえても一番流行ってるだろ。
相対的に見てオブジェクト指向がどうかんがえても一番流行ってるだろ。
>>394
何を言ってるのかわからないけど
とりあえず、数字で表せないだろ？
オブジェクト指向なら、従来○○ヶ月かかったプロジェクトをＸＸヶ月に短縮できます！
こうやって「バーン！」って出せるもんがねぇじゃん。
何を言ってるのかわからないけど
とりあえず、数字で表せないだろ？
オブジェクト指向なら、従来○○ヶ月かかったプロジェクトをＸＸヶ月に短縮できます！
こうやって「バーン！」って出せるもんがねぇじゃん。
オブジェクト指向という考え方の「存在」は浸透してる。
けど、流行ってない（理解してる奴が少ない）ってことでしょ？
数字で表すとかって、なんか関係あるの？？
けど、流行ってない（理解してる奴が少ない）ってことでしょ？
数字で表すとかって、なんか関係あるの？？
>>396
それって、オブジェクト指向じゃない「何か」ならだせるのか？
それって、オブジェクト指向じゃない「何か」ならだせるのか？
>>397
流行ってないの認識が違うな。
流行ってないの認識が違うな。
400 ：仕様書無しさん：2007/02/28(水) 00:32:56
>>401
おめぇ頭腐ってるだろｗ
おめぇ頭腐ってるだろｗ
>>402
つか、プロジェクト始まる前からそんなガチガチにやり方決まってるものなのか？
PDCAもなにもあったもんじゃない気がするんだけど。
うちなんか完全に担当まかせでやってるから、オブジェクト指向だろうがなんだろうが
やりたきゃやればってなもんだけど。
つか、プロジェクト始まる前からそんなガチガチにやり方決まってるものなのか？
PDCAもなにもあったもんじゃない気がするんだけど。
うちなんか完全に担当まかせでやってるから、オブジェクト指向だろうがなんだろうが
やりたきゃやればってなもんだけど。
こないだの総理大臣（名前忘れた）だな
格差解決の議論をしてる中で「格差があるというならば」とかいいだすアレ。
格差解決の議論をしてる中で「格差があるというならば」とかいいだすアレ。
オブジェクト指向でどんだけ利益を得てるかは具体的にはだせないが、
今さら昔の組み方で作ってくれっていわれても無理だな。
体（頭？）が無理。機能中心で考えようとしてもどうしても、オブジェ
クトを抽出しようとしてしまう。無理だ。ということで、多分やっぱり
物事を整理するのには役立ってんだと思う。
今さら昔の組み方で作ってくれっていわれても無理だな。
体（頭？）が無理。機能中心で考えようとしてもどうしても、オブジェ
クトを抽出しようとしてしまう。無理だ。ということで、多分やっぱり
物事を整理するのには役立ってんだと思う。
>>407
全員でいいんじゃない？
全員でいいんじゃない？
>>410
俺もそうおもう
俺もそうおもう
>>413
それはアーキテクチャと業務を分離できてなかった、昔の話だろ。
それはアーキテクチャと業務を分離できてなかった、昔の話だろ。
そもそも、
オブジェクト指向が流行ってるんなら
こんなスレが立つこともないのか。
「携帯電話がブームです」
って言うことのに違和感があるぐらいオブジェクト指向が浸透すれば評価しようもあるけど、
自分も含めてちゃんと理解できてる奴が少ないから、
ブームに過ぎない（流行ってない）ような気がする。
メリットどうこうを判断するところに達してないし。
オブジェクト指向が流行ってるんなら
こんなスレが立つこともないのか。
「携帯電話がブームです」
って言うことのに違和感があるぐらいオブジェクト指向が浸透すれば評価しようもあるけど、
自分も含めてちゃんと理解できてる奴が少ないから、
ブームに過ぎない（流行ってない）ような気がする。
メリットどうこうを判断するところに達してないし。
>>414
じゃあ、昔のプロジェクトの改修作業でオブジェクト指向は使えないの？
じゃあ、昔のプロジェクトの改修作業でオブジェクト指向は使えないの？
つ リエンジニアリング とか
ま、なんだかんだいっても、本当はみんなオブちゃんのこと好きなくせに。
>>420
俺が教えてほしいぜ＞メリット
俺が教えてほしいぜ＞メリット
品質向上とか期間短縮にしても
それがどういう理由でどうしてそうなるのか？
って説明できなきゃこの技術は金にならずにもうそろそろ消えるなｗ
それがどういう理由でどうしてそうなるのか？
って説明できなきゃこの技術は金にならずにもうそろそろ消えるなｗ
感覚的にオブジェクト指向は浸透するとは思えない。
でも知らないと嫌なので本を読んでみたりしてる。
なので いちばんやさしいオブジェクト指向の本 840円 を読書中。
でも知らないと嫌なので本を読んでみたりしてる。
なので いちばんやさしいオブジェクト指向の本 840円 を読書中。
>>422
オブジェクト指向って何ができるとオブジェクト指向ができたっていうの？
ってのを各社定義しはじめると思うんだ。
作るもんがこうのとき、こういうＵＭＬがかけて、それに基づいてクラス作って・・・とか、
または単純にソースにクラスっぽいのがあればオブジェクト指向ですっていうところもあるかもな。
そういう定義ができてちゃんと個人がそれに対してできるできないって言えるようになったら
流行ってるとも言えるかな・・・。
オブジェクト指向って何ができるとオブジェクト指向ができたっていうの？
ってのを各社定義しはじめると思うんだ。
作るもんがこうのとき、こういうＵＭＬがかけて、それに基づいてクラス作って・・・とか、
または単純にソースにクラスっぽいのがあればオブジェクト指向ですっていうところもあるかもな。
そういう定義ができてちゃんと個人がそれに対してできるできないって言えるようになったら
流行ってるとも言えるかな・・・。
>>424
憂鬱本買えよー
憂鬱本買えよー
オブジェクト指向 なんてわかりにくい名前が足を引っ張ってる
だってわからんもん。 オブジェクト？指向？ ？？？ってな感じで
だってわからんもん。 オブジェクト？指向？ ？？？ってな感じで
>>427
沈めよ。お前。
沈めよ。お前。
結局、向上心やセンスの無い奴にオブジェクト指向導入のメリットを
理解させるには、共産主義国家に資本主義のメリットを説くのに似て、
相応の時間と犠牲が必要なのかもしれない。数十年もすればごく普通
の考え方になってるかもしれないし、或いは別の思想が根付いている
かもしれん。俺自身はオブジェクト指向は好きだが。ただ理解してな
い奴とはあまり一緒に仕事はしたくない。みんなも北朝鮮で仕事はし
たくないだろ？
理解させるには、共産主義国家に資本主義のメリットを説くのに似て、
相応の時間と犠牲が必要なのかもしれない。数十年もすればごく普通
の考え方になってるかもしれないし、或いは別の思想が根付いている
かもしれん。俺自身はオブジェクト指向は好きだが。ただ理解してな
い奴とはあまり一緒に仕事はしたくない。みんなも北朝鮮で仕事はし
たくないだろ？
・・・消えないで欲しいけどね。
憂鬱本ってどこらへんがそんなにいいの？
そこらへんのJavaの入門書に書いてあるオブジェクト指向の解説の域を出てないと思うんだが。
オブジェクト指向入門の方がオブジェクト指向の定義が厳密だし、
オブジェクト指向を導入するまでの論理が明快でわかりやすかったが。
そこらへんのJavaの入門書に書いてあるオブジェクト指向の解説の域を出てないと思うんだが。
オブジェクト指向入門の方がオブジェクト指向の定義が厳密だし、
オブジェクト指向を導入するまでの論理が明快でわかりやすかったが。
オブジェクト指向って、なんか神格化してる人がいてたりすると、
わからんちんの自分はさらに敬遠しちゃう
オブジェクト指向の本を読んでも結局、何を作ればいいの？？ってなる。
やっぱ環境なのかなあ。
わからんちんの自分はさらに敬遠しちゃう
オブジェクト指向の本を読んでも結局、何を作ればいいの？？ってなる。
やっぱ環境なのかなあ。
憂鬱本ってなんですか？
パラダイムにしても開発モデルにしても
旧来の手法/方法で行き詰ってきて、
（現在に至るまでの要求の増大という遷移を勘案すれば）
さらに行き詰ることがはっきりしているから。
新たな手法/方法が幾つも提示されているわけだ。
その先頭に立っているのがOOであるわけだが。
このような認識を持っている人間が現場に少なすぎる。
旧来の手法/方法で行き詰ってきて、
（現在に至るまでの要求の増大という遷移を勘案すれば）
さらに行き詰ることがはっきりしているから。
新たな手法/方法が幾つも提示されているわけだ。
その先頭に立っているのがOOであるわけだが。
このような認識を持っている人間が現場に少なすぎる。
エンドユーザーにUMLを見せても、
「こんなの分かんないので意味ないです」
と言われる官庁系システム。
「こんなの分かんないので意味ないです」
と言われる官庁系システム。
結局はPLが何のために導入するかを説明してないってことでOK？
UMLで描いて満足してるからわかってもらえないんだろ。
だいたいUMLで描いたからどうだって言うんだ？
UMLはただの表記法だって話はもう何度もループしてるぞ。
だいたいUMLで描いたからどうだって言うんだ？
UMLはただの表記法だって話はもう何度もループしてるぞ。
445 ：仕様書無しさん：2007/02/28(水) 01:22:13
神に愛されし者だけがオブシェクト指向を理解できる
ということでおk？
ということでおk？
オブジェクト指向が流行らない一因として、ユースケースから設計・実装への落とし込みが
長い間不透明すぎたってのがあるとおもう。
長い間不透明すぎたってのがあるとおもう。
| ＵＭＬ釣れますか？ ,
＼ ,／ヽ
￣∨￣￣￣￣￣￣￣ ,／ ヽ
∧＿∧ ∧∧ ,／ ヽ
（ ´∀｀） (ﾟДﾟ,,),／ ヽ
（ ） (| つ@ ヽ
｜ ｜ | ＿＿_ 〜| | ヽ
（_＿）＿） |――|. ∪∪ ヽ
￣￣￣￣￣￣￣￣￣￣￣￣| ヽ
／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~
⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡 〜 〜〜 〜〜 〜〜 〜 〜
＼ ,／ヽ
￣∨￣￣￣￣￣￣￣ ,／ ヽ
∧＿∧ ∧∧ ,／ ヽ
（ ´∀｀） (ﾟДﾟ,,),／ ヽ
（ ） (| つ@ ヽ
｜ ｜ | ＿＿_ 〜| | ヽ
（_＿）＿） |――|. ∪∪ ヽ
￣￣￣￣￣￣￣￣￣￣￣￣| ヽ
／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~
⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡 〜 〜〜 〜〜 〜〜 〜 〜
もう流行なくていいよ。理解る奴だけ理解れば。
しょせんゴキブリと人間は仲良くなどできないのだよ。
しょせんゴキブリと人間は仲良くなどできないのだよ。
みんなもう１時すぎだ。
デスマまで体力温存しようぜ
デスマまで体力温存しようぜ
やだぷー
451 ：おじゃばさま：2007/03/01(木) 18:48:56
UMLは基本的に詳細設計レベルなので、客に見せても反応がないのは当然である。
またオブジェクト指向は詳細設計レベルの事に対する物である。
開発方法におけるオブジェクト指向と言っているのは、多くの場合プロトタイプ方式の事であり、
プロトタイプ方式は広く使われている。
つまり、オブジェクト指向開発は流行の時代を越えて、すでに一般的になっている。
またオブジェクト指向は詳細設計レベルの事に対する物である。
開発方法におけるオブジェクト指向と言っているのは、多くの場合プロトタイプ方式の事であり、
プロトタイプ方式は広く使われている。
つまり、オブジェクト指向開発は流行の時代を越えて、すでに一般的になっている。
452 ：仕様書無しさん：2007/03/01(木) 19:00:58
,
,／ヽ
,／ ヽ
∧＿∧ ,／ ヽ
（ ´∀｀）,／ ヽ
（ つつ@ ヽ
＿＿ おじゃば ヽ
|――| （_＿）＿） ヽ
￣￣￣￣￣￣￣￣￣￣￣￣| ヽ
／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~
⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡 〜 〜〜 〜〜 〜〜 〜 〜
,／ヽ
,／ ヽ
∧＿∧ ,／ ヽ
（ ´∀｀）,／ ヽ
（ つつ@ ヽ
＿＿ おじゃば ヽ
|――| （_＿）＿） ヽ
￣￣￣￣￣￣￣￣￣￣￣￣| ヽ
／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~
⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡 〜 〜〜 〜〜 〜〜 〜 〜
おじゃばが酉つけないのは、やっぱ自演が
できなくなるからかな。
できなくなるからかな。
454 ：おじゃばさま：2007/03/01(木) 19:37:14
よく知らないが、つけ方しらないんじゃね？
|
|
＼|／
/⌒ヽ ／￣￣￣￣￣￣￣￣￣￣￣￣
∩＿＿＿∩ | ゜Θ゜） ＜ 開発方法のOOはプロトタイプでし
| ノ＼ ヽ | ∵ つ ＼＿＿＿＿＿＿＿＿＿＿＿＿
/ ●゛ ● | | ∵ |
| ∪ ( _●_) ミ ＼＿／
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
|
＼|／
/⌒ヽ ／￣￣￣￣￣￣￣￣￣￣￣￣
∩＿＿＿∩ | ゜Θ゜） ＜ 開発方法のOOはプロトタイプでし
| ノ＼ ヽ | ∵ つ ＼＿＿＿＿＿＿＿＿＿＿＿＿
/ ●゛ ● | | ∵ |
| ∪ ( _●_) ミ ＼＿／
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
>>434
医療みたいに結果が明確じゃないからかな？
技術者が社長だったり客だったりすれば問題ないんだけどね。
オブジェクト指向導入→開発期間が半分に！
とかだったら喜んで金だしてくれるかもしれないけどそうじゃないでしょ？
自分の技術が何にどう影響するのかわかりやすく出資者（多くの場合素人）にわかって貰う必要があるのさ。
「つっこみ力」って本オススメ。
俺等がいかに無駄なもんに力を注ごうとしてるかよくわかる。
医療みたいに結果が明確じゃないからかな？
技術者が社長だったり客だったりすれば問題ないんだけどね。
オブジェクト指向導入→開発期間が半分に！
とかだったら喜んで金だしてくれるかもしれないけどそうじゃないでしょ？
自分の技術が何にどう影響するのかわかりやすく出資者（多くの場合素人）にわかって貰う必要があるのさ。
「つっこみ力」って本オススメ。
俺等がいかに無駄なもんに力を注ごうとしてるかよくわかる。
Ｘわかりやすく
○をわかりやすく説明して、
○をわかりやすく説明して、
458 ：おじゃば：2007/03/01(木) 21:12:00
トリップの意味を知らない。トリップのとり方を知らない。
その調べ方もわからない。己の文章に責任をとりたくない。
しかし名無しはいやだ。
いずれにしても、おじゃばはただのでしゃばりな能無しだな。
その調べ方もわからない。己の文章に責任をとりたくない。
しかし名無しはいやだ。
いずれにしても、おじゃばはただのでしゃばりな能無しだな。
と、つられてみた
>開発方法におけるオブジェクト指向
同様な表現をしてみようか。
「開発プロセスモデルにおける構造化」
同様な表現をしてみようか。
「開発プロセスモデルにおける構造化」
寧ろ俺は、「開発方法におけないオブジェクト指向」ってものが
どんなものなのか知りたい。 ...とつられたフリをしてみる。
どんなものなのか知りたい。 ...とつられたフリをしてみる。
463 ：おじゃばさま：2007/03/02(金) 08:53:12
>460,462
大自然に感謝しつつ、キャッチ＆リリース。
大自然に感謝しつつ、キャッチ＆リリース。
try-catchでなくcatch-releaseなおじゃばさま
465 ：仕様書無しさん：2007/03/02(金) 09:38:23
自分の不勉強を人のせいにするな
467 ：仕様書無しさん：2007/03/02(金) 10:06:57
別にUMLは設計手法でも何でもないし。
たんなる書式だと何度言えばわかるんだろう。
たんなる書式だと何度言えばわかるんだろう。
>>463
ブルーギルとブラックバスに関しては踏み潰すか土に埋めてくるのが釣り人のマナー
ブルーギルとブラックバスに関しては踏み潰すか土に埋めてくるのが釣り人のマナー
>>467
表現は思考を限定する
表現は思考を限定する
単純に工数を算出できないから流行らないのかな？
いままでやってきたやり方ってなかなか変えたがらんしね。
従来工法で何年かレガシーのお守りやってみれば、OOの利点がよく見えるぞ。
オブジェクト指向でものづくりすると
本当に少人数で効率よく良いもの出来るのだけれど
一般的に行われている
メーカーが受注して、外注を沢山入れて開発する手法には
マッチしていないような気がする
本当に少人数で効率よく良いもの出来るのだけれど
一般的に行われている
メーカーが受注して、外注を沢山入れて開発する手法には
マッチしていないような気がする
476 ：仕様書無しさん：2007/03/03(土) 13:38:19
本当にオブジェクト指向でやらせなたいんだったら、免許制にしないと
ダメだと思う。
現状では、理解してますとか、Java経験あります。C++経験あります。
っていう口頭レベルに近い相手の申告を信用してやってる状況で、実際
ＯＯをどの程度理解してるかってのは、成果物みるまでわからないとい
う、一種の博打にちかい非常にリスクが高い環境なんだよな。その理解
度を定量的に計るものさしが無いから、コーディング規約だとか、テス
ト仕様書だとか、とりあえず目に見える尺度で縛ろうとするんだけど、
これが外面的なものしか抑制できてないから、それほどうまくいってな
い。ま実際は、とりあえず動けばいいってところも多いから、うまくいっなく
もないんだが、のちのちの保守とか機能拡張の段になって支障をきたす
ことになる。
ＯＯの理解度を定量的に測るいいものさしはないものかねぇ。
ダメだと思う。
現状では、理解してますとか、Java経験あります。C++経験あります。
っていう口頭レベルに近い相手の申告を信用してやってる状況で、実際
ＯＯをどの程度理解してるかってのは、成果物みるまでわからないとい
う、一種の博打にちかい非常にリスクが高い環境なんだよな。その理解
度を定量的に計るものさしが無いから、コーディング規約だとか、テス
ト仕様書だとか、とりあえず目に見える尺度で縛ろうとするんだけど、
これが外面的なものしか抑制できてないから、それほどうまくいってな
い。ま実際は、とりあえず動けばいいってところも多いから、うまくいっなく
もないんだが、のちのちの保守とか機能拡張の段になって支障をきたす
ことになる。
ＯＯの理解度を定量的に測るいいものさしはないものかねぇ。
オージス総研が新しい資格作ればいい
>>476 真っ先にお前のような奴が落とされるんだがなｗ
＼ ∩─ｰ､
＼／ ● ､_ ｀ヽ
/ ＼( ● ● |つ
| X_入__ノ ミ 頭が悪そうな文章なんで食いつきたくないんだが、そりゃ落とされる
､ (＿／ﾏｽﾞｯノ かもしらんが、真っ先ってことはないだろいくらなんでも
＼＿＿＿ノﾞ
／ 丶' ⌒ヽ:::
/ ヽ / /:::
/ /へ ヘ/ /:::
/ ＼ ヾミ /|:::
（__／| ＼___ノ/:::
＼／ ● ､_ ｀ヽ
/ ＼( ● ● |つ
| X_入__ノ ミ 頭が悪そうな文章なんで食いつきたくないんだが、そりゃ落とされる
､ (＿／ﾏｽﾞｯノ かもしらんが、真っ先ってことはないだろいくらなんでも
＼＿＿＿ノﾞ
／ 丶' ⌒ヽ:::
/ ヽ / /:::
/ /へ ヘ/ /:::
/ ＼ ヾミ /|:::
（__／| ＼___ノ/:::
480 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/03/03(土) 21:26:01
技術を装った差別思想だから
優性論の「純粋アーリアン民族」と同じ似非科学似非技術
優性論の「純粋アーリアン民族」と同じ似非科学似非技術
瑠璃も玻璃も照らせば解る
オブジェクト指向って、
システムに必要な対象をばらして
それぞれのやりとりを組み立てていくこと、
ってのが理解できたとしても
「じゃあどのフェーズで使うの？」ってなっちゃってんだよな。
システムに必要な対象をばらして
それぞれのやりとりを組み立てていくこと、
ってのが理解できたとしても
「じゃあどのフェーズで使うの？」ってなっちゃってんだよな。
>>482はオブジェクト指向を理解してない
>システムに必要な対象をばらして
>それぞれのやりとりを組み立てていくこと
これが全然違う
問題領域で不変的に存在する要素を発見して定義するのがオブジェクト指向
最後には組み立てるが組み立てる作業はオブジェクト指向でもなんでもないただの作業
>システムに必要な対象をばらして
>それぞれのやりとりを組み立てていくこと
これが全然違う
問題領域で不変的に存在する要素を発見して定義するのがオブジェクト指向
最後には組み立てるが組み立てる作業はオブジェクト指向でもなんでもないただの作業
オブジェクト指向の秘密はオブジェクトとオブジェクトの間にあると思
>>482 であってるだろ
483は話を分かりにくく言ってるだけ
483は話を分かりにくく言ってるだけ
488 ：仕様書無しさん：2007/03/04(日) 02:28:45
あってねーよ
487もオブジェクト指向を理解して無い
483の文じゃモジュールに分解しましたってだけじゃん
487もオブジェクト指向を理解して無い
483の文じゃモジュールに分解しましたってだけじゃん
特化と汎化だけでそんなに熱くなるなよ。おまいら。
で、聞きたいこと。
実際におまいらクラスの汎化ってどの程度まで行うのが妥当だと思う？
派生クラスが２つ位しかないのに無理に汎化ばっかしたがる厨が職場に
いて迷惑なんだ。
で、聞きたいこと。
実際におまいらクラスの汎化ってどの程度まで行うのが妥当だと思う？
派生クラスが２つ位しかないのに無理に汎化ばっかしたがる厨が職場に
いて迷惑なんだ。
491 ：仕様書無しさん：2007/03/04(日) 03:23:07
うっせーぼけっ
>>490
とりあえず自分含めて後で再利用するケースを考えながら作る
でも機能実装の住み分けで迷ったりする、汎化は派生クラスを新規に作りたい時とか
最初からあればそれに越したことは無いが仮想関数とかの使い方が人によって微妙だったり
とりあえず自分含めて後で再利用するケースを考えながら作る
でも機能実装の住み分けで迷ったりする、汎化は派生クラスを新規に作りたい時とか
最初からあればそれに越したことは無いが仮想関数とかの使い方が人によって微妙だったり
>>490
デザインパターンて知ってる？
デザインパターンて知ってる？
496 ：仕様書無しさん：2007/03/04(日) 10:06:11
俺の場合殆ど分かってないけど使えそうな部分は使ってるって感じかな？
>>499
>>490 は永遠の課題、というか、その場その場の状況に合わせ、みんなで合意する
必要があることかな、と言う認識なんだけど、アナリシスパターンで解決する？
なんか資料があれば教えてほしい。
>>490 は永遠の課題、というか、その場その場の状況に合わせ、みんなで合意する
必要があることかな、と言う認識なんだけど、アナリシスパターンで解決する？
なんか資料があれば教えてほしい。
わかっていようがいまいが、巻き込まれるのがオブジェクト指向。
コピペ厨 v.s. 共通化厨
というのは永遠の課題ですな。
というのは永遠の課題ですな。
>>503
一見無駄に見えるクラス分けが将来の仕様変更などで役に立ったりする
一見無駄に見えるクラス分けが将来の仕様変更などで役に立ったりする
>>498はオブジェクト指向も設計と分析の違いもわからんくせに
ユースケース分析とか言い出すなよ
それはそうと、おまえらクラスってのがなんで型として使えるようになってるかわかってないだろ
お前らの言ってる分析や設計、実装ってモジュールとクラスの区別がついてない
ユースケース分析とか言い出すなよ
それはそうと、おまえらクラスってのがなんで型として使えるようになってるかわかってないだろ
お前らの言ってる分析や設計、実装ってモジュールとクラスの区別がついてない
どうせ変更しないんだからと溶接してしまうから後で困ることになる
ボルトとナットで接続しておけばいいのに
ボルトとナットで接続しておけばいいのに
わからないから教えてくれ
わからないくせにオブジェクト指向を理解したって言い張る奴が多すぎる
OOが流行らないのはOOを理解してる奴がほとんどいないからだ
OOが流行らないのはOOを理解してる奴がほとんどいないからだ
>>508
ならお前がオブジェクト指向も設計と分析の違いについて語ってみれ。
どうせ出来やしねえだろうけどな。
ちなみに俺は、分析だろうが設計・実装だろうが
取り扱う対象や適用しやすいパターンが異なるってだけで
大した違いはないと思ってるが。
ならお前がオブジェクト指向も設計と分析の違いについて語ってみれ。
どうせ出来やしねえだろうけどな。
ちなみに俺は、分析だろうが設計・実装だろうが
取り扱う対象や適用しやすいパターンが異なるってだけで
大した違いはないと思ってるが。
> 分析だろうが設計・実装だろうが
> 取り扱う対象や適用しやすいパターンが異なるってだけで
> 大した違いはないと思ってるが。
俺もそう思う。
> 取り扱う対象や適用しやすいパターンが異なるってだけで
> 大した違いはないと思ってるが。
俺もそう思う。
言わんとしてることはわかるが、一面で間違っている。
基本は変わらないよ。
ただ、日曜大工とビル建設じゃ、分析・設計の持つ重要性と意味合いが違うということはあると思う。
基本は変わらないよ。
ただ、日曜大工とビル建設じゃ、分析・設計の持つ重要性と意味合いが違うということはあると思う。
「じゃあお前がやれよ！どうせ出来ないだろうけどなー」
ネットで遊んでるとよく聞くセリフだよな。
ネットで遊んでるとよく聞くセリフだよな。
>>515
何で重要性と意味合いが違うと思うのかとか、重要性が違うから分析の際はXXすべき、
とかそういうの書かなきゃ意味無い。
コーディングできないSEによる、保身のためのレスみたいに見えてしまう。
何で重要性と意味合いが違うと思うのかとか、重要性が違うから分析の際はXXすべき、
とかそういうの書かなきゃ意味無い。
コーディングできないSEによる、保身のためのレスみたいに見えてしまう。
コーディングできない云々を馬鹿にしてる奴ってさ、その程度のSEから仕事請けてる自分も・・・って思えよ。
類は朋を呼ぶ。
コーディングできないSEてもきちんと出来る人は幾らでもいるし、それをなんとも思わずに分業できてる現場はある。
類は朋を呼ぶ。
コーディングできないSEてもきちんと出来る人は幾らでもいるし、それをなんとも思わずに分業できてる現場はある。
どいつもこいつも
「お前は間違ってる」
の応酬で不毛だ
「お前は間違ってる」
の応酬で不毛だ
>>520
このたとえは嫌われるが、こんくりの混ぜ方知らない設計者なんて当然のようにいる。
それを理解できない程度の現場しかやってないんだろ？>>520
犬小屋建てる程度なら、全部できて当然。
ビル建てるのに、現場作業を勉強しないと設計できないなんてことは無い。
まあ、だからあんたのしってる現場とその程度のSEを基準に、常識とか語るなよ。ｗ
このたとえは嫌われるが、こんくりの混ぜ方知らない設計者なんて当然のようにいる。
それを理解できない程度の現場しかやってないんだろ？>>520
犬小屋建てる程度なら、全部できて当然。
ビル建てるのに、現場作業を勉強しないと設計できないなんてことは無い。
まあ、だからあんたのしってる現場とその程度のSEを基準に、常識とか語るなよ。ｗ
開発作業を効率よくラクにするために
オブジェクト指向言語とオブジェクト指向設計手法が生まれてきたはずなのに、
学習方法が確立しとらんって、
ちょっと引くわ
オブジェクト指向言語とオブジェクト指向設計手法が生まれてきたはずなのに、
学習方法が確立しとらんって、
ちょっと引くわ
>>521はビル建築とシステム開発の本質的な違いを理解してないと見える。
設計とコーディングの話はよそでやれ
>>523
いろいろ失敗しながら時間かけていくしかないのかな
いろいろ失敗しながら時間かけていくしかないのかな
設計だけを語って何の意味があるの？
上流の工数が減った分、下流にそのしわ寄せがいくなんて、なんだかなぁ。
上流の工数が減った分、下流にそのしわ寄せがいくなんて、なんだかなぁ。
529 ：仕様書無しさん：2007/03/04(日) 18:08:40
ソフトウェア開発の世界ではコーディングが設計という話はよくきく。
つまり、プログラマーがやってるのは設計の一部で、設計にしたがって
対象物(実行可能なバイナリ)を組み立ててるのがコンパイラーなのだと。
つまり組み立て自体は自動化されているわけだ。コーディングを知らな
い自称設計者はただの企画者だ。企画者が出してくるのは、せいぜい画
面設計書と機能設計書、DB設計書、クラス図ぐらいだ。そして大抵の場
合、その企画書は全体的な整合性が十分に練られていない。企画者の不
備は概してプログラマーがかぶることになる。コーディングを知らずに、
少なくともその特徴や性質を知らずに設計は構造的にありえんよ。
つまり、プログラマーがやってるのは設計の一部で、設計にしたがって
対象物(実行可能なバイナリ)を組み立ててるのがコンパイラーなのだと。
つまり組み立て自体は自動化されているわけだ。コーディングを知らな
い自称設計者はただの企画者だ。企画者が出してくるのは、せいぜい画
面設計書と機能設計書、DB設計書、クラス図ぐらいだ。そして大抵の場
合、その企画書は全体的な整合性が十分に練られていない。企画者の不
備は概してプログラマーがかぶることになる。コーディングを知らずに、
少なくともその特徴や性質を知らずに設計は構造的にありえんよ。
機能要件は仔細もらさず張り切って書いてるくせに、パフォーマンス要件
は一行で済ましちゃってるバカがいる限り、設計とコーディングを切り離
して語ることはできません。
は一行で済ましちゃってるバカがいる限り、設計とコーディングを切り離
して語ることはできません。
成果を見せろよ。しゃべってるだけじゃねーか。
レスポンスやスループットは機能仕様に含まれていると考えるのは古いのかな
この仕事が好きなら、まずコーディングに興味がなくなるってのが信じられん。
海外ではよく４０，５０の親父がばりばりコーディングしてんのにな。
海外ではよく４０，５０の親父がばりばりコーディングしてんのにな。
そもそも人が集まらない
C++やJavaで開発といっても設計するのは何故かコボラーが多いのが現実
C++やJavaで開発といっても設計するのは何故かコボラーが多いのが現実
>>534
OO開発は、人を集めなくていいからいいんじゃないの。
OO開発は、人を集めなくていいからいいんじゃないの。
さあ、低レベルプログラマのデジドカ現場リーダークラスの愚痴スレになってきました。
確かにシステムと建築は違うよ、でも、工業的手法に関しては建築業界より50年遅れてると言われてるのが日本のシステム構築。
確かにシステムと建築は違うよ、でも、工業的手法に関しては建築業界より50年遅れてると言われてるのが日本のシステム構築。
>>533
興味がなくなったわけじゃなくて、最初からやったことないSEが多い。
興味がなくなったわけじゃなくて、最初からやったことないSEが多い。
で、オブジェクト指向の話はどこにいったんだ？
>>540
通説？まずはソース出せよ。
通説？まずはソース出せよ。
>>540
誰が誰だかわからんが、通説なんて無いぞ。
単に出来てない言い訳ならあるけど。
実際、アメリカのインドに対するオフショアの成功をどう見るの？
貴方のいってるように工業的手法が成立しないとしたら、ああいう分業は成立しないのだが。
誰が誰だかわからんが、通説なんて無いぞ。
単に出来てない言い訳ならあるけど。
実際、アメリカのインドに対するオフショアの成功をどう見るの？
貴方のいってるように工業的手法が成立しないとしたら、ああいう分業は成立しないのだが。
なんで建築業界的手法がダメなのか分かるか？
コードの一行まで100%実装可能な設計書が書けないからさ。
建築の設計書は外部設計で建物の基礎、外観をミリ単位で設計。
内部設計でもミリ単位で部屋割りとコンポーネントの配置だ。
あとは施行業者が設計図に従って組むだけ。
ソフトウェアは外部設計がころころ変わり、実装中にも仕様変更が入る。
しかも物理的なものじゃなく論理的なものだから一箇所設計ミスったらシステム全体が動かない。
建物なら数ミリおかしくても無理矢理合わせることができるがソフトウェアじゃそうはいかない。
コードの一行まで100%実装可能な設計書が書けないからさ。
建築の設計書は外部設計で建物の基礎、外観をミリ単位で設計。
内部設計でもミリ単位で部屋割りとコンポーネントの配置だ。
あとは施行業者が設計図に従って組むだけ。
ソフトウェアは外部設計がころころ変わり、実装中にも仕様変更が入る。
しかも物理的なものじゃなく論理的なものだから一箇所設計ミスったらシステム全体が動かない。
建物なら数ミリおかしくても無理矢理合わせることができるがソフトウェアじゃそうはいかない。
インドに投げてる案件はテスト、バグ取りがほとんどなんだけどね。
545 ：仕様書無しさん：2007/03/04(日) 18:56:25
つーかさ、オブジェクト指向じゃない人って何使ってるの？
C言語とかBASICとかってこと？
C言語とかBASICとかってこと？
俺は建築業界的な工業的手法も適用するのが望ましいとは思うけど、
そうすると、設計するには、建築士に相当する免許が必要になるだろ
うし、品質を監査する機関も必要になってくるだろう。ＰＧにも資格
が必要になるかもしれない。上流〜下流の工程も役割がもう少し明確
に細分化されるかもしれない。しかし現実問題として現状では無理だ
な。その方が望ましいとは思うけど。
そうすると、設計するには、建築士に相当する免許が必要になるだろ
うし、品質を監査する機関も必要になってくるだろう。ＰＧにも資格
が必要になるかもしれない。上流〜下流の工程も役割がもう少し明確
に細分化されるかもしれない。しかし現実問題として現状では無理だ
な。その方が望ましいとは思うけど。
>>545 Javaでも、C++でも、OO的でない組み方はできる。
まあ、システムに対してそれほど社会が信頼性を期待してないっていう現実があるからね。
下等に見られてるんだよ、所詮プログラマーの作るものなんて止まって当然って。
姉歯なんてあんだけ極悪人になるけど、大手ベンダーのSEが逮捕されたなんて聞かないし。ｗ
設計が適当、製造も適当、それで言い訳だけは立派。
挙句には手法が確立されていないことを、あたかも自分達の仕事が高級だからみたいな勘違い。
下等に見られてるんだよ、所詮プログラマーの作るものなんて止まって当然って。
姉歯なんてあんだけ極悪人になるけど、大手ベンダーのSEが逮捕されたなんて聞かないし。ｗ
設計が適当、製造も適当、それで言い訳だけは立派。
挙句には手法が確立されていないことを、あたかも自分達の仕事が高級だからみたいな勘違い。
549 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/03/04(日) 19:05:09
２０００年問題詐欺やってた業界といっしょにされてるからねえ
OO言語でも何故か雛形なるものがあってみんなそれに従って組む
>>543
建築業界の者ですが
それ、買いかぶりすぎ。100%実装可能な設計書なんざ、どこの建築現場にもないってば。図面で「収まりは現場合わせ」ってなってることもあるくらい
建築中の仕様変更もしょっちゅうあるし。図面通りに収まらない場合も多々あるし。
デスマーチっぽいことも起こるし。ただ、騒音の問題とか安全性とか、太陽が沈んでいると作業能率が下がることもあって、あんまり無茶はしないけど
建築業界の者ですが
それ、買いかぶりすぎ。100%実装可能な設計書なんざ、どこの建築現場にもないってば。図面で「収まりは現場合わせ」ってなってることもあるくらい
建築中の仕様変更もしょっちゅうあるし。図面通りに収まらない場合も多々あるし。
デスマーチっぽいことも起こるし。ただ、騒音の問題とか安全性とか、太陽が沈んでいると作業能率が下がることもあって、あんまり無茶はしないけど
雛形ってどんなの？
つまり、建築業界も資格制度がなくなっちゃったら、
粗悪な建物が乱立しちゃうよってことか。
粗悪な建物が乱立しちゃうよってことか。
554 ：仕様書無しさん：2007/03/04(日) 19:15:00
外に出すには、関数レベルまで落とさないと収集つかないと思います。
「金払ってんだからやれ」っちゅー基地外的考えは消えて欲しいと思います。
「金払ってんだからやれ」っちゅー基地外的考えは消えて欲しいと思います。
↑その関数レベルまで落とせる設計者がそもそも滅多にいない。絶滅危惧種に指定されそうないきおいだ。
関数レベルまで落とせるならわざわざ外注に頼む必要ないんじゃね？
558 ：仕様書無しさん：2007/03/04(日) 19:24:41
絶滅危惧種
絶滅危惧種
やっぱし...そーでしたか。
絶滅危惧種
やっぱし...そーでしたか。
>>551
それだ
>音の問題とか安全性とか、太陽が沈んでいると作業能率が下がることもあって、あんまり無茶はしないけど
デスマを無くすヒントがこんなところに。
・ＰＣの電源を太陽電池にして昼間じゃないと動かないようにする。
・キーボード叩くたびに大きな音が鳴り響くようにする。
こうすれば夜中まで無茶させられなくなるかも。糞メーカそうしろよ。
それだ
>音の問題とか安全性とか、太陽が沈んでいると作業能率が下がることもあって、あんまり無茶はしないけど
デスマを無くすヒントがこんなところに。
・ＰＣの電源を太陽電池にして昼間じゃないと動かないようにする。
・キーボード叩くたびに大きな音が鳴り響くようにする。
こうすれば夜中まで無茶させられなくなるかも。糞メーカそうしろよ。
言語の知識だけで人が集められ、
PGのSEの切り分けが明確じゃない現状で、
各自やるべきことがやたら多く（要件、仕様、アーキテクチャ、設計、製造、レビュー、設計標準覚え・・）
技術的なレベルもお互いわからず、
・・・
ってこんな状況でオブジェクト指向設計思想なんか・・・（泣
いや、マジで、
「オブジェクト指向で完璧にやれてます！開発が超ラクでうれしいです！」
ってな現場がどれぐらい存在してるのか知りたい
PGのSEの切り分けが明確じゃない現状で、
各自やるべきことがやたら多く（要件、仕様、アーキテクチャ、設計、製造、レビュー、設計標準覚え・・）
技術的なレベルもお互いわからず、
・・・
ってこんな状況でオブジェクト指向設計思想なんか・・・（泣
いや、マジで、
「オブジェクト指向で完璧にやれてます！開発が超ラクでうれしいです！」
ってな現場がどれぐらい存在してるのか知りたい
>>553
>>557
そもそも建築関係の資格って、品質確保のためにあるのは非常に限られてるし。
ほとんどが、安全管理のためのもの。他に重機・機械類の運転があるくらい
>>557
あれで例えば鉄筋屋が「これはおかしい」って仕事断ってたら、凄いと思うよ。バブル期なみに需給が逼迫してたら可能かもしらんけど、そんな時期なら建築主も危ない橋渡らんだろｗ
工期詰まってて手抜きを指示されることはあるかもしらんけど
>>557
そもそも建築関係の資格って、品質確保のためにあるのは非常に限られてるし。
ほとんどが、安全管理のためのもの。他に重機・機械類の運転があるくらい
>>557
あれで例えば鉄筋屋が「これはおかしい」って仕事断ってたら、凄いと思うよ。バブル期なみに需給が逼迫してたら可能かもしらんけど、そんな時期なら建築主も危ない橋渡らんだろｗ
工期詰まってて手抜きを指示されることはあるかもしらんけど
俺なら隠して売るけど
もまぃらもちつけ。
ここは土方本職の話をしてどぅする！？ｗ
ここは土方本職の話をしてどぅする！？ｗ
>>564
すみません、つい反応しちゃいました。
スレ違いなので消えます。
違う業界ながら、いろいろと共通点があるので、この板はずっと興味を持って見てました。
異業種交流スレでも建てようかと思っています。
すみません、つい反応しちゃいました。
スレ違いなので消えます。
違う業界ながら、いろいろと共通点があるので、この板はずっと興味を持って見てました。
異業種交流スレでも建てようかと思っています。
もちつけ俺ｗ
日本語がへんだｗｗｗ
日本語がへんだｗｗｗ
ここは本職土方のためのｵﾌﾞｼﾞｪｸﾄ指向開発講座スレになりました。
>>567
ナレーション乙
ナレーション乙
本職も業界的にきっちりやってるようにみえて、いろいろ大変なんだなぁ。
なんだか潮が引いたようにさぁーっと...浮き沈みの激しいスレだなぁ
いや、もうおねむのじかんでしゅから。
お前らＴＶか、ＴＶ見てんのか、そんなにＯＯよりＴＶが大事か？
よし、わかった。お前らがその気なら、俺もＴＶ見る。
よし、わかった。お前らがその気なら、俺もＴＶ見る。
システム連携の話です。
あるディレクトリを監視して、ファイル（XMLもしくはcsvになる予定）が存在した場合は
そのファイルをこちら側のシステムの仕様にあったXMLに変換して所定の場所に保存
（プラスFTP転送等の処理）します。
一応単独のJavaアプリです。
当方プログラマ4年生、OO勉強中、デザパタは本を読んである程度勉強していますが
時々なんとなく使う程度です。
ちなみに現場では仕様を決める人が別にいて、その後の設計、実装、テストが僕の仕事です。
べたーっと書けばすぐに書けちゃう訳ですが、他のシステムとの連携はいろいろと発生
することが多くて、フレームワーク化とできたらいいな、と思っています。
（ほとんどの場合、ディレクトリ監視→データ変換→その他の処理という流れなのは同じ）
で、いろいろと考えているのですが上手くまとまりません。
ファイルを監視するクラス（インターフェイス）
ファイルを変換するクラス（インターフェイス）
実処理（この場合XMLを所定の場所に置く、FTPするなど）のクラス（インターフェイス）
といった感じで、現状インターフェイスを定義＋それぞれのfactoryクラスという感じで
考えました。
が、これってただの機能分割にしかなってないような気もするし、でも機能を中心に
考えないと上手く設計できないし、といったところで行き詰っています。
どう考えたら上手くいくのでしょうか？
正直、まだまだ若輩者といいますか、3流プログラマな自覚はあるつもりですが、脱3流
したい気持ちは常にあります。
なので煽り覚悟でいつもROMっているこのスレで質問してみることにしました。
お時間に余裕がある方がいらっしゃいましたら、レスいただけないでしょうか？
あるディレクトリを監視して、ファイル（XMLもしくはcsvになる予定）が存在した場合は
そのファイルをこちら側のシステムの仕様にあったXMLに変換して所定の場所に保存
（プラスFTP転送等の処理）します。
一応単独のJavaアプリです。
当方プログラマ4年生、OO勉強中、デザパタは本を読んである程度勉強していますが
時々なんとなく使う程度です。
ちなみに現場では仕様を決める人が別にいて、その後の設計、実装、テストが僕の仕事です。
べたーっと書けばすぐに書けちゃう訳ですが、他のシステムとの連携はいろいろと発生
することが多くて、フレームワーク化とできたらいいな、と思っています。
（ほとんどの場合、ディレクトリ監視→データ変換→その他の処理という流れなのは同じ）
で、いろいろと考えているのですが上手くまとまりません。
ファイルを監視するクラス（インターフェイス）
ファイルを変換するクラス（インターフェイス）
実処理（この場合XMLを所定の場所に置く、FTPするなど）のクラス（インターフェイス）
といった感じで、現状インターフェイスを定義＋それぞれのfactoryクラスという感じで
考えました。
が、これってただの機能分割にしかなってないような気もするし、でも機能を中心に
考えないと上手く設計できないし、といったところで行き詰っています。
どう考えたら上手くいくのでしょうか？
正直、まだまだ若輩者といいますか、3流プログラマな自覚はあるつもりですが、脱3流
したい気持ちは常にあります。
なので煽り覚悟でいつもROMっているこのスレで質問してみることにしました。
お時間に余裕がある方がいらっしゃいましたら、レスいただけないでしょうか？
HULFTじゃダメなのか
>>575
要件定義ぶちこわしだなｗｗｗ
要件定義ぶちこわしだなｗｗｗ
なんでもかんでもＯＯにする必要はない。ＯＯにするのに時間ばっかり
くってあまり役にもたたなかったってんじゃ意味がない。
実際、今でもOSのカーネルとかドライバみたいに性能重視するものとか、
あまり大掛かりでないものとか、意図的にOOにしないで昔ながらの作り
方だったりする。
ＯＯでいくか、いく場合どのパターンにするかとかは、それこそ実践で
何度も試行錯誤して、感覚的に覚えていくしかないと思う。人のやり方が
必ずしも最適でなかったりもするし。自分なりに自分に一番適した手法を
見つけていけばいいんじゃね。本当は考え方を共有できるのが望ましい
んだけど、現状そこまで望むのはよっぽど恵まれた環境じゃないと無理
だと思う。
くってあまり役にもたたなかったってんじゃ意味がない。
実際、今でもOSのカーネルとかドライバみたいに性能重視するものとか、
あまり大掛かりでないものとか、意図的にOOにしないで昔ながらの作り
方だったりする。
ＯＯでいくか、いく場合どのパターンにするかとかは、それこそ実践で
何度も試行錯誤して、感覚的に覚えていくしかないと思う。人のやり方が
必ずしも最適でなかったりもするし。自分なりに自分に一番適した手法を
見つけていけばいいんじゃね。本当は考え方を共有できるのが望ましい
んだけど、現状そこまで望むのはよっぽど恵まれた環境じゃないと無理
だと思う。
別にいいんだけど、Cでやった方がよさそうだな
ファイル転送とちょいぐらいならな
ファイル転送とちょいぐらいならな
皆様、レスありがとうございます、感謝、感謝です。
>>574さん
ありがとうございます。
まずは、ですよね。
やってみて、何が不満なのか自分なりに納得出来るように頑張ってみようとおもいます。
引き続き、あーでもない、こーでもないと考えてみます。
>>575さん、>>576さん
HULFTっていうのは初めて知りました。
どんなものなのか、後で少し勉強しておこうと思います。
>>577さん
確かにその通りだと思っています。
今回の件に関しては、ラッキーなことに比較的時間の余裕もあるので、OO的に考えると
こうなるのかな〜、みたいなことを自分なりに考えてみたいと思っていて。
実践する場所がなかなか無いのが悩みだったのですが、
「自分なりに自分に一番適した手法」
を探す、その第一歩だと思って頑張ろうと思います。
>>578さん
すいません、Cは実務未経験なのです(´･ω･｀)
でも、その発想で、Cの勉強もしていけるのが理想ですよね。
「Cならこう、C++ならこう、Javaならこう、Rubyならこう」みたいに自分なりの選択肢を
増やす努力も続けていきたいと思ってます。
ただ、なかなか時間が取れないですが(´･ω･｀)
皆様、ありがとうございました。
>>574さん
ありがとうございます。
まずは、ですよね。
やってみて、何が不満なのか自分なりに納得出来るように頑張ってみようとおもいます。
引き続き、あーでもない、こーでもないと考えてみます。
>>575さん、>>576さん
HULFTっていうのは初めて知りました。
どんなものなのか、後で少し勉強しておこうと思います。
>>577さん
確かにその通りだと思っています。
今回の件に関しては、ラッキーなことに比較的時間の余裕もあるので、OO的に考えると
こうなるのかな〜、みたいなことを自分なりに考えてみたいと思っていて。
実践する場所がなかなか無いのが悩みだったのですが、
「自分なりに自分に一番適した手法」
を探す、その第一歩だと思って頑張ろうと思います。
>>578さん
すいません、Cは実務未経験なのです(´･ω･｀)
でも、その発想で、Cの勉強もしていけるのが理想ですよね。
「Cならこう、C++ならこう、Javaならこう、Rubyならこう」みたいに自分なりの選択肢を
増やす努力も続けていきたいと思ってます。
ただ、なかなか時間が取れないですが(´･ω･｀)
皆様、ありがとうございました。
>>559
某不治ソフトで常駐していたときを思い出した。
終電まで作業が既定路線にもかかわらず、ISOなんたらのために定時になると空調が切れる。
真夏でも容赦なく。
毎日19時25分きっかりに熱暴走するマシンがあったｗ
夜中まで無茶されられなくなるなんて、幻想。
実際にはそんな状況下でも作業させられる。
某不治ソフトで常駐していたときを思い出した。
終電まで作業が既定路線にもかかわらず、ISOなんたらのために定時になると空調が切れる。
真夏でも容赦なく。
毎日19時25分きっかりに熱暴走するマシンがあったｗ
夜中まで無茶されられなくなるなんて、幻想。
実際にはそんな状況下でも作業させられる。
コードを書けないことと
書けるけど、書かないことは違う。
SEはコードを書かない仕事も多いけど、書けない奴がやるべきではない。
書けるけど、書かないことは違う。
SEはコードを書かない仕事も多いけど、書けない奴がやるべきではない。
同意。
PG「現場を蔑ろにした設計が、受け入れられるわけ無いだろうが！」
SE「そんなつもり無いんだけどなぁ。アハハ」
PG「コード書けない奴が何言っても、説得力無いんだよ！」
SE「アメリカあたりじゃ普通らしいよ。設計オンリーの技術者。」
PG「だから、コード書けない奴を技術者とは呼ばないんだって！」
SE「ねぇねぇ、設計だけに話をフォーカスしない？」
SE「そんなつもり無いんだけどなぁ。アハハ」
PG「コード書けない奴が何言っても、説得力無いんだよ！」
SE「アメリカあたりじゃ普通らしいよ。設計オンリーの技術者。」
PG「だから、コード書けない奴を技術者とは呼ばないんだって！」
SE「ねぇねぇ、設計だけに話をフォーカスしない？」
やっぱりコード書けないと薄っぺらな奴になるのな。
コードを知らずに設計できるその器用さと図太さがある意味羨ましい。
実装方法に対する疑問とか罪悪感とか感じないんだろうか？
実装方法に対する疑問とか罪悪感とか感じないんだろうか？
ギターリストが作るピアノの譜面と同じなんだろうな
それ以前にもまぃらスレ違いな
それ以前にもまぃらスレ違いな
いや、作曲もできない・演奏もできないプロデューサーがコード進行を決めているようなもの。
だからさ、業界に通じる免許制度があればいいんだよな
面接のときだか提案のときだか何でもいいんだけど、
標準化されたスキルチェックシートと免状の提示を
リーダー側、偽装請負側の両方が行う。
これこそ見える化だわ。ってちがっｗｗｗ
でも自分で書いて感心したｗｗ
言語知識の有無だけで参入を決めるようなのおっかねーしｗｗｗ
面接のときだか提案のときだか何でもいいんだけど、
標準化されたスキルチェックシートと免状の提示を
リーダー側、偽装請負側の両方が行う。
これこそ見える化だわ。ってちがっｗｗｗ
でも自分で書いて感心したｗｗ
言語知識の有無だけで参入を決めるようなのおっかねーしｗｗｗ
>>589
それ以前の問題として
早晩、人集めする必要自体が無くなるんじゃねえの？
底辺コーダにまかせられる作業なんて今じゃほとんど自動化できるし。
コード書けない（＝底辺コーダに依存する存在である）底辺SEともども、
今のうちに身の振り方考えておいた方がいいんじゃないか？
それ以前の問題として
早晩、人集めする必要自体が無くなるんじゃねえの？
底辺コーダにまかせられる作業なんて今じゃほとんど自動化できるし。
コード書けない（＝底辺コーダに依存する存在である）底辺SEともども、
今のうちに身の振り方考えておいた方がいいんじゃないか？
>>590
コード書きを自動化できる→底辺コーダに依存する必要はない→底辺SEの将来は安泰！
コード書きを自動化できる→底辺コーダに依存する必要はない→底辺SEの将来は安泰！
Javaと出版業界に躍らせれている限りコーダーは不滅
593 ：おじゃばさま：2007/03/05(月) 08:07:33
コンピュータ業界の機能仕様書は、建築業界の完成予想図です。
コンピュータ業界のソースコードは、建築業界の設計図です。
建築業界の作業者は、コンピュータ業界ではコンパイラになります。
コーディング出来ないSEは、イラストレーターと呼びます。
コンピュータ業界のソースコードは、建築業界の設計図です。
建築業界の作業者は、コンピュータ業界ではコンパイラになります。
コーディング出来ないSEは、イラストレーターと呼びます。
594 ：仕様書無しさん：2007/03/05(月) 08:36:36
オブジェクト指向の話とは全然かけ離れてるな。
とりあえずこれでも読んどけ。
http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html
とりあえずこれでも読んどけ。
http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html
設計図のための設計図はいらないなー
>>596
全体の設計図と詳細な設計図とあるから、不要というわけではないとおもう。
全体の設計図と詳細な設計図とあるから、不要というわけではないとおもう。
ここでミクロを語るPGさんには全体は見えないです。ｗ
設計＝詳細設計だから。
設計＝詳細設計だから。
↑コーディングできない、なんちゃってＳＥさん
600 ：おじゃばさま：2007/03/05(月) 19:20:46
イラストレーターじゃね？
601 ：仕様書無しさん：2007/03/05(月) 19:41:19
>>598
つか今日日、詳細設計ってなんだよ。レトロ過ぎんだろ。
つか今日日、詳細設計ってなんだよ。レトロ過ぎんだろ。
オブジェクト指向の話
↓
たとえ出現
↓
罵り合い
↓
スレ違いトーク
ループしすぎだもまぃら
↓
たとえ出現
↓
罵り合い
↓
スレ違いトーク
ループしすぎだもまぃら
>>603
いいんだよ。2chだから。
いいんだよ。2chだから。
605 ：仕様書無しさん：2007/03/05(月) 23:08:25
わからない人を見ているのって面白いからいいじゃん♪
まあ正直、食傷気味だわな。
クラス設計から入ると荒れるみたいだから、
ユースケースの話してくれ。
クラス設計から入ると荒れるみたいだから、
ユースケースの話してくれ。
>>606
それもっと荒れるし。
それもっと荒れるし。
まずは自動販売機から
あぁデジャブだ
>>607
まじか。じゃあ、アスペクト指向設計の話はどうよ。
まじか。じゃあ、アスペクト指向設計の話はどうよ。
なんかテンプレつくってくれ
なぜ流行らないかの指針がほしい
例
【経験年数】５年
【使用言語】C++, Java, COBOL
【学習場所】家だけ
【学習法】本をひたすら読む
【お勧めの本・URL】オブジェクト指向でなぜつくるのか
【OOP理解度】わかってそうで分かってないような気がする
てきとーすぎるので補完してくれぃ
なぜ流行らないかの指針がほしい
例
【経験年数】５年
【使用言語】C++, Java, COBOL
【学習場所】家だけ
【学習法】本をひたすら読む
【お勧めの本・URL】オブジェクト指向でなぜつくるのか
【OOP理解度】わかってそうで分かってないような気がする
てきとーすぎるので補完してくれぃ
【経験年数】3年
【使用言語】C, C++, C#
【学習場所】家、職場の勉強会
【学習法】本80%、net20%
【お勧めの本・URL】憂鬱
【OOP理解度】まあまあ
【趣味】寸止めオナヌー
【使用言語】C, C++, C#
【学習場所】家、職場の勉強会
【学習法】本80%、net20%
【お勧めの本・URL】憂鬱
【OOP理解度】まあまあ
【趣味】寸止めオナヌー
【経験年数】6年
【使用言語】Z80BASIC, C, C++, PHP
【学習場所】家、専校、会社
【学習法】本読んで組むしかないと思ふ
【お勧めの本・URL】プログラミング講義C++
【OOP理解度】ｿｰｽの使い回しが楽に出来るぐらいしか・・・基本は自動販売機
【使用言語】Z80BASIC, C, C++, PHP
【学習場所】家、専校、会社
【学習法】本読んで組むしかないと思ふ
【お勧めの本・URL】プログラミング講義C++
【OOP理解度】ｿｰｽの使い回しが楽に出来るぐらいしか・・・基本は自動販売機
アジャイル何とか奥義って本と、デザインパターンの本を適当に読んで、
オプソ10個くらいソース読めば、どうやればOOPになるかわかるよ。
オプソ10個くらいソース読めば、どうやればOOPになるかわかるよ。
ま、母国語でまともに自分の考えを表現できないキモオタどもが
OOを使ったからといってまともに自分の考えを表現できるはずが無い
母国語でOOのメリットを他人に納得させられない低脳は
OOを使う必要は無い、一生コーダとして設計には携わらないでくれ
OOを使ったからといってまともに自分の考えを表現できるはずが無い
母国語でOOのメリットを他人に納得させられない低脳は
OOを使う必要は無い、一生コーダとして設計には携わらないでくれ
>>615
はいはいﾊﾞﾛｽﾊﾞﾛｽ
はいはいﾊﾞﾛｽﾊﾞﾛｽ
「憂鬱」や「なぜつくるのか」よりも
「オブジェクト指向入門」や「オブジェクト指向のこころ」
の方がお勧めできるよ。
「オブジェクト指向入門」や「オブジェクト指向のこころ」
の方がお勧めできるよ。
【経験年数】0年
【使用言語】C, Perl
【学習場所】家
【学習法】本と2ch
【お勧めの本・URL】なぜ、あなたはJavaでオブジェクト指向開発ができないのか
【OOP理解度】本で読んだ理解だけ
【使用言語】C, Perl
【学習場所】家
【学習法】本と2ch
【お勧めの本・URL】なぜ、あなたはJavaでオブジェクト指向開発ができないのか
【OOP理解度】本で読んだ理解だけ
619 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/03/06(火) 18:58:35
新興宗教信じてるやつに 「おまいの宗教は間違ってる」といえば怒るだろ。
だからOO厨には関わりになりたがらない。
だからOO厨には関わりになりたがらない。
620 ：仕様書無しさん：2007/03/06(火) 19:11:02
OOPを実践してる人が病気で手術をすることになった場合、医師が直接メスで切り開いて体内へアクセスすることは拒否するものなの？
冷蔵庫とか電子レンジ買ったとき、ファームウェアが一つも入ってなくて
ユーザが自分でインストールしなきゃいけなかったらめんどいじゃん。
OOを実践しないってことはそういうこと。
ユーザが自分でインストールしなきゃいけなかったらめんどいじゃん。
OOを実践しないってことはそういうこと。
>>621
日本語でおｋ
日本語でおｋ
冷蔵庫とか電磁波加熱器買ったとき、固定基盤が一つも入ってなくて
利用者が自分で導入しなきゃいけなかったらめんどいじゃございませんか。
物指向を実践しないってことはそういうこと。
利用者が自分で導入しなきゃいけなかったらめんどいじゃございませんか。
物指向を実践しないってことはそういうこと。
あぁなるほど、ちょっとわかった
ほんとかいな
まあ現代の三大宗教も発生した当初は新興宗教であったわけで。
主流になるか否かはここで決める問題ではない罠
ただ「過半数の人間にとって理解しやすい」
という主流になりうることに必須な長所が欠落しているような
という形でスレタイへの回答をしてみる
主流になるか否かはここで決める問題ではない罠
ただ「過半数の人間にとって理解しやすい」
という主流になりうることに必須な長所が欠落しているような
という形でスレタイへの回答をしてみる
ホストこぼらー女、頭かてえよ；；
@ITで「5分で絶対に分かるオブジェクト指向」ってやってるね
>>626
過半数の人にとって、明らかにわかり易いだろ。
過半数の人にとって、明らかにわかり易いだろ。
シングルスレッドのプログラムばっか書いてるからオブジェクト指向の利点わかんないんじゃね？
マルチスレッドのプログラムを非OOPとOOPで書き比べてみればどうよ？
マルチスレッドのプログラムを非OOPとOOPで書き比べてみればどうよ？
クリティカルセクションの局所化以外にメリットが思い当たらない
632 ：仕様書無しさん：2007/03/06(火) 21:18:47
もう3スレ目も後半だけど、この有様…
流行るはずがないよね
流行るはずがないよね
>>631
そりゃそうだが、その理由はOOPを選択するのに十分すぎるだろ。
そりゃそうだが、その理由はOOPを選択するのに十分すぎるだろ。
既に十分流行ってるっつうの
導入期、成長期を得て今まさに成熟期の真っ最中じゃね？
もう暫くすると衰退期にはいる。
導入期、成長期を得て今まさに成熟期の真っ最中じゃね？
もう暫くすると衰退期にはいる。
無手勝流の開発手法と比べたら、OO開発は流行ってないといえるかも試練が
そんなこといったら今までに流行った開発手法なんて一つもないことになる。
そんなこといったら今までに流行った開発手法なんて一つもないことになる。
>>636
最後のレスだけ見てレスすんなよ、めんどくせえな。。
最後のレスだけ見てレスすんなよ、めんどくせえな。。
オブジェクト指向の存在を知って、
鼻をへし折られたやつ＝もれOo。。。
自分ってアホなんやろかと自問自答しつつ、本を読み漁り、、
本に書いてあることは理解できるんだよね、いやホントに。
でもなんかモヤモヤしちゃんだよね
鼻をへし折られたやつ＝もれOo。。。
自分ってアホなんやろかと自問自答しつつ、本を読み漁り、、
本に書いてあることは理解できるんだよね、いやホントに。
でもなんかモヤモヤしちゃんだよね
>>639
オプソ嫁。実例が山ほどあるのにモヤモヤも糞もねだろ。
オプソ嫁。実例が山ほどあるのにモヤモヤも糞もねだろ。
人海だろ
ちと確認したいが、その目的を達成することによって誰が得をする？
ちと確認したいが、その目的を達成することによって誰が得をする？
デスマの解消
>>643
俺ら以外ぜんぶ
俺ら以外ぜんぶ
>>635
OODは見たことがないのでここにいる。(-_-)
OODは見たことがないのでここにいる。(-_-)
うちのフロア、技術本読んでる奴なんか皆無
漫画とスポーツ新聞読んでる奴ばかり
OO本？UML本？あることはあるけど飾りだな
正月の掃除のときに移動してるだけだわ
で、偽装請負な方々がなんちゃってOODをやってるらしい
って、できてねーよ！
漫画とスポーツ新聞読んでる奴ばかり
OO本？UML本？あることはあるけど飾りだな
正月の掃除のときに移動してるだけだわ
で、偽装請負な方々がなんちゃってOODをやってるらしい
って、できてねーよ！
オブジェクト指向って言語と違って
テクニックみたいなのを周りから聞いたりできないんだよなあ
テクニックみたいなのを周りから聞いたりできないんだよなあ
普通に組めばどーやったってOOD/Pになっていくが、流行ってないってーと
流行っているのは逆にﾅﾆよ？
流行っているのは逆にﾅﾆよ？
■CNNのアンケートで半島からの反撃が始まって、日本謝罪すべしの票が増えてきてます。
投票まだの方はよろしくお願いします。
それと、このレスをそこらへんのスレにコピペして下さると助かります。
http://edition.cnn.com/2007/WORLD/asiapcf/03/04/japan.sexslaves.ap/index.html
Should Japan apologize again for its World War II military brothels?
（日本は、第二次世界大戦時に軍が運営した売春宿の件で再び謝罪するべきですか。）
Noにしていただくと助かります
◆従軍慰安婦証言のウソ（李容洙ーイ・ヨンス氏）
http://karutosouka1.hp.infoseek.co.jp/ianhu.htm
※李容洙さんのコロコロ変る「証言」
http://karutosouka1.hp.infoseek.co.jp/52526825.jpg
投票まだの方はよろしくお願いします。
それと、このレスをそこらへんのスレにコピペして下さると助かります。
http://edition.cnn.com/2007/WORLD/asiapcf/03/04/japan.sexslaves.ap/index.html
Should Japan apologize again for its World War II military brothels?
（日本は、第二次世界大戦時に軍が運営した売春宿の件で再び謝罪するべきですか。）
Noにしていただくと助かります
◆従軍慰安婦証言のウソ（李容洙ーイ・ヨンス氏）
http://karutosouka1.hp.infoseek.co.jp/ianhu.htm
※李容洙さんのコロコロ変る「証言」
http://karutosouka1.hp.infoseek.co.jp/52526825.jpg
それはオブジェクトテクノロジの概念の話でしょ
クラスとか継承とかの
クラスとか継承とかの
OOＰに期待されていた効果の一つに、スパゲッティコードの排除があった。
それなのに、世の多くのプログラマ達はそうした目論見も何処吹く風とばか
りにせっせせっせとスパゲッティを製造し続けている。
プログラマという生き物にはひねくれ物が多く、必ずしも賢者の想定通りに
は動かないものだ。
ＯＯＰ言語であっても、ＯＯＰ的でない組み方ができてしまう。その余地を与え
てしまっている今の言語の未熟さにも問題があるのかもしれない。
それなのに、世の多くのプログラマ達はそうした目論見も何処吹く風とばか
りにせっせせっせとスパゲッティを製造し続けている。
プログラマという生き物にはひねくれ物が多く、必ずしも賢者の想定通りに
は動かないものだ。
ＯＯＰ言語であっても、ＯＯＰ的でない組み方ができてしまう。その余地を与え
てしまっている今の言語の未熟さにも問題があるのかもしれない。
昔に比べればスコープがわかりやすくなったよ
流行ってないっつうか、現場にそこまで流行らせる気がそもそもないんだろ。
つまり現状に対して問題意識がないということじゃね。問題が無いんだから
無理に実践しようとも思わない。そういうことじゃね？
それとも、問題はあるが、OOはわからないから、そのうちドラエモンが発明
されるのを期待して待ってんのかな。
つまり現状に対して問題意識がないということじゃね。問題が無いんだから
無理に実践しようとも思わない。そういうことじゃね？
それとも、問題はあるが、OOはわからないから、そのうちドラエモンが発明
されるのを期待して待ってんのかな。
設計書は業務がわかってればなんとなく設計書にはなる。
コーディングは言語規約がわかってれば一応動くものは作れる。
オブジェクト指向？
デスマ要員にこれ以上何を要求するんですか！もう帰らせてください！
コーディングは言語規約がわかってれば一応動くものは作れる。
オブジェクト指向？
デスマ要員にこれ以上何を要求するんですか！もう帰らせてください！
>>657
切実きわまる答弁だな。ﾖｼﾖｼ(´；ω；｀)ヽ(ﾟДﾟ )
切実きわまる答弁だな。ﾖｼﾖｼ(´；ω；｀)ヽ(ﾟДﾟ )
>>656
いま日本のIT産業に従事してる連中に、問題意識がないってのが問題だよなあ。
周りの奴らと同じようにしてたらこの先生きのこっていけそうもないって、
ちょっと考えたらわかりそうなもんなのに。
メンタリティ低すぎだよな。
いま日本のIT産業に従事してる連中に、問題意識がないってのが問題だよなあ。
周りの奴らと同じようにしてたらこの先生きのこっていけそうもないって、
ちょっと考えたらわかりそうなもんなのに。
メンタリティ低すぎだよな。
効率が良くなったら仕事が無くなるじゃないですかっ！！
>>660
その分さぼればいいだろ
その分さぼればいいだろ
プロパだけで開発してノウハウ貯めようとしないからな・・・ほとんどの会社
この仕事好きなんだけど、
学習に疲れた自分ガイル
学習に疲れた自分ガイル
いくら開発標準なんかでいろいろ定義しても
結局はわからんちんがぶち壊しにしてくれるからな
オブジェクト指向でやろうとしても理解してる身内だけでやらない限りはダメダメだろ
数十人、数百人規模でオブジェクト指向で完遂させるなんて、まず無理
そこまで達観してるのにまだ本を読んでる漏れ・・・
なにやってんだろうな
結局はわからんちんがぶち壊しにしてくれるからな
オブジェクト指向でやろうとしても理解してる身内だけでやらない限りはダメダメだろ
数十人、数百人規模でオブジェクト指向で完遂させるなんて、まず無理
そこまで達観してるのにまだ本を読んでる漏れ・・・
なにやってんだろうな
オブジェクト指向なんてSmalltalkの時代からあった
Lispと同じで哲学や薀蓄を語るための代物であって
現実には役に立たない。
Lispと同じで哲学や薀蓄を語るための代物であって
現実には役に立たない。
まったくだよ、MSだとか、Sunだとか、どうやってんだろ。何十人、何百人
でやってんだろ。やっぱ優秀な奴だけ集まればちゃんとできてんだろうな。
でやってんだろ。やっぱ優秀な奴だけ集まればちゃんとできてんだろうな。
MSなんてVistaが遅れに遅れて未だに月例のパッチを当てないと
すぐに攻撃に晒されるアホOS＆間抜けアプリを量産している糞会社じゃないか
Sunは潰れそうだけどな
すぐに攻撃に晒されるアホOS＆間抜けアプリを量産している糞会社じゃないか
Sunは潰れそうだけどな
現実とか非現実的とか訳かんね
>>673
へえ、そんな考え方もあるんか。
1. ライブラリやフレームワーク自体が有効でない。
2. それらのライブラリやフレームワークは、非OOでつくればもっと早くつくれる。
あんたが主張したいのはどっち？
へえ、そんな考え方もあるんか。
1. ライブラリやフレームワーク自体が有効でない。
2. それらのライブラリやフレームワークは、非OOでつくればもっと早くつくれる。
あんたが主張したいのはどっち？
オブジェクト指向どうこうの前に、
どう考えても無理な納期を厳守したり、
めちゃくちゃなコスト感覚で強行しようとするから、
品質もめちゃくちゃで、
結局はオブジェクト指向なんかの話になれないんだよな
ライブラリやらフレームワークなんて言葉、ここでしか見ねーよ
誰も見ない見える化ボードがあるぐらいだな
どう考えても無理な納期を厳守したり、
めちゃくちゃなコスト感覚で強行しようとするから、
品質もめちゃくちゃで、
結局はオブジェクト指向なんかの話になれないんだよな
ライブラリやらフレームワークなんて言葉、ここでしか見ねーよ
誰も見ない見える化ボードがあるぐらいだな
>ライブラリやらフレームワークなんて言葉、ここでしか見ねーよ
どんな職場だよｗ
どんな職場だよｗ
では、そろそろアンチオブジェクト指向な方々に現実的な解決策を提示していただきましょう。
あ、OO厨こそ現実的ではないって話は無しよ。
あ、OO厨こそ現実的ではないって話は無しよ。
680 ：仕様書無しさん：2007/03/07(水) 01:36:12
プログラミングっていう知的な作業をＩＱ高い奴とＩＱ低い奴が
共同で行わなければならないというところに、開発手法の適用が
うまくいかないジレンマがある。結局広く浸透させるには、ＩＱ
低い奴に合わすしかないからな。そうすると今度はＩＱ高い奴が
ストレス抱えることになり、その横でＩＱ低い奴がニタニタしてる。
共同で行わなければならないというところに、開発手法の適用が
うまくいかないジレンマがある。結局広く浸透させるには、ＩＱ
低い奴に合わすしかないからな。そうすると今度はＩＱ高い奴が
ストレス抱えることになり、その横でＩＱ低い奴がニタニタしてる。
楽園はオープンソースにあるってことだな
>>679
まあフレームワーク必要かどうかは、つくってるモノによりけりだしな。
まあフレームワーク必要かどうかは、つくってるモノによりけりだしな。
>>679 どんな開発してんだよ。
.NET Framework
NUnit
JUnit
Struts
Spring
Ruby On Rails
Mojabi
Catalyst
Atlas
って使ったことないか？
.NET Framework
NUnit
JUnit
Struts
Spring
Ruby On Rails
Mojabi
Catalyst
Atlas
って使ったことないか？
>>680
そのニタニタしてる奴がこのスレに多いのは事実だろう。
>>681
で、おまいはその楽園に本当に行きたいのかと
「馬鹿が多くて困るよな〜」って言葉を飲み込みながら働いてる人達のおかげで成り立ってるような業界だよな、この業界。
そのニタニタしてる奴がこのスレに多いのは事実だろう。
>>681
で、おまいはその楽園に本当に行きたいのかと
「馬鹿が多くて困るよな〜」って言葉を飲み込みながら働いてる人達のおかげで成り立ってるような業界だよな、この業界。
>>683
.NET Framework 聞いたことある
NUnit しらね
JUnit J-Walkなら知ってる
Struts 名前は見たことある
Spring Javaのなんかだよな？
Ruby On Rails 映画のタイトルみたいだな
Mojabi 原住民の名前か！？
Catalyst メダルに彫ってありそうな感じ
Atlas 地図だろ
こんなとこだな
.NET Framework 聞いたことある
NUnit しらね
JUnit J-Walkなら知ってる
Struts 名前は見たことある
Spring Javaのなんかだよな？
Ruby On Rails 映画のタイトルみたいだな
Mojabi 原住民の名前か！？
Catalyst メダルに彫ってありそうな感じ
Atlas 地図だろ
こんなとこだな
>>685
お前はオペレーターかwww
お前はオペレーターかwww
>>679はなにつくってんの？
俺は、Mojabiは知らん。vなら知ってるがｗ
vって何？
>>687
サーバー制御のシステムやってる。
TCPやFTPで〜、って感じのとこ。
あとはOracle周りをちょっと。いちおGold持ってる。
Javaは分かるけど、そのなんだっけ？Springとかは知らない。
サーバー制御のシステムやってる。
TCPやFTPで〜、って感じのとこ。
あとはOracle周りをちょっと。いちおGold持ってる。
Javaは分かるけど、そのなんだっけ？Springとかは知らない。
業務遂行に必要な知識にしか興味がなくても構わないけど
そういう知的好奇心の薄いやつはいずれ淘汰される
TCPとFTPを並べちゃってるところが、ちょっとアレだな。
FTPクラスはTCPクラスに処理を委譲してるってことをいいたい訳だな。
オブジェクト指向はバカから俺のソースを守ってくれる心強い考え方だよっ
俺あんま働きたくないからオブ指やるわｗ
外に晒す関数考えるの面倒なのでとにかく公開クラス削ってる俺。
701 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/03/07(水) 23:19:00
会社の基幹サーバーがこの一年２０回くらい落ちていたんだが
OO厨の担当した部分が原因だったことが判明した。
OO厨の担当した部分が原因だったことが判明した。
誰彼かまわず馬鹿呼ばわりするスレはここですか？
OO厨って全部メモリ上のオブジェクトで処理やろうとするよな。
SQLのが速いんだからつかえよ。
SQLのが速いんだからつかえよ。
オブジェクト指向を分かったフリするスレはここですか？
Springはオブジェクト指向というよりアスペクト指向
つまり、オブジェクト指向的に考えるとpublicなgetter/setterなんて
カプセル化をわざわざ破壊していると思うんだけどな
宣言されていても紳士なので使いませんというなら構造体と変わらん
つまり、オブジェクト指向的に考えるとpublicなgetter/setterなんて
カプセル化をわざわざ破壊していると思うんだけどな
宣言されていても紳士なので使いませんというなら構造体と変わらん
園児に方程式解けるか？ 小学生に相対性理論分かるか？
中学生にタイムマシン作れるか？ 高校生に地球が割れるか？
大学生に銀河を作れるか？ 社会人にビッグバンに匹敵するエネルギーがあるか？
つまり、そういうこと。馬鹿にはオブジェクト指向はわからない。
中学生にタイムマシン作れるか？ 高校生に地球が割れるか？
大学生に銀河を作れるか？ 社会人にビッグバンに匹敵するエネルギーがあるか？
つまり、そういうこと。馬鹿にはオブジェクト指向はわからない。
>>701
OO厨ごときに落とされるそのサーバが糞ということに気づかないお前がココ電球
OO厨ごときに落とされるそのサーバが糞ということに気づかないお前がココ電球
>>700
漢はだまってpublicだろ普通
漢はだまってpublicだろ普通
710 ：仕様書無しさん：2007/03/08(木) 07:39:50
念のために聞くけど、外部コンポーネントに公開するクラスってインタフェースクラスだよな？当たり前だよな？
うちの会社の奴ってみーんな実装クラスを公開するんだ
しかも実装クラスを実装継承して使えとか平気で指定してきやがる
このスレにいるような奴はそんなことしてないよな？
うちの会社の奴ってみーんな実装クラスを公開するんだ
しかも実装クラスを実装継承して使えとか平気で指定してきやがる
このスレにいるような奴はそんなことしてないよな？
つ javax.servlet.http.HttpServlet
つまり、コンビニでの支払いは現金じゃなくて携帯電話使えってこと？
>>707 つまり、そういうこと。プログラマにはオブジェクト指向はわからない。
プログラムを順次、分岐、繰り返しだけだと思ってるプログラマにはOOはまず分からん。
ジャクソン法とワーニエ法を駆使しておりますが、何か？
×順次、分岐、繰り返し
○連接、分岐、反復
○連接、分岐、反復
本当に本当にOOにすると開発生産性が向上すると思っているのか？
720 ：仕様書無しさん：2007/03/08(木) 17:30:08
原子の振る舞いを知っているからといって
世の中の全てを知っていることにはならない
世の中の全てを知っていることにはならない
722 ：おじゃばさま：2007/03/08(木) 18:44:38
>721
いい言葉だな。今度C厨に使ってみよう。
いい言葉だな。今度C厨に使ってみよう。
俺のプロジェクトだといわゆるリッチドメインモデルでシステム作ってて、hibernate使ってるんだが、
一昨日追加で入ってきたjavaができるというコボル親父が
更新ユースケースのソースコード見て、「更新SQL発行してる処理がないんだ！！」って憤慨してた。
あほかと(;´,_ゝ`)
一昨日追加で入ってきたjavaができるというコボル親父が
更新ユースケースのソースコード見て、「更新SQL発行してる処理がないんだ！！」って憤慨してた。
あほかと(;´,_ゝ`)
Javaできる＝hibernateできるじゃねぇだろ
設計時もデータベースに保存アクセスするDAOって名前よりも、
インスタンスを永続化するという意味合いが強いからPersisterという名前にしてるからかDAOやDTOクラスが無いことにも驚いてたな。
インスタンスを永続化するという意味合いが強いからPersisterという名前にしてるからかDAOやDTOクラスが無いことにも驚いてたな。
抽象化の概念がかけてるんだろうね
このスレ、抽象データ型について語ったほうがいい気がしてきた。
業務分析時とか、申請書にいろんな種類があるからってそれぞれ別クラスに設計するのは分かるけど、まとめていろんな種類の申請書に対して同じ処理するなら継承つかうとかさ。
なんか良い例題あるといいけど…。
2chでアナリシスパターン作ってみたら、面白くてくだらなそうだ。
業務分析時とか、申請書にいろんな種類があるからってそれぞれ別クラスに設計するのは分かるけど、まとめていろんな種類の申請書に対して同じ処理するなら継承つかうとかさ。
なんか良い例題あるといいけど…。
2chでアナリシスパターン作ってみたら、面白くてくだらなそうだ。
何？中小デー子型って？
なんか転職板でよく湧いてくる蛆虫？
なんか転職板でよく湧いてくる蛆虫？
>>728
同じような帳票データに同じような処理があって、継承するような構造で作っていたら・・・
帳票画面は200画面以上あったので200クラス以上できた。
それが複雑怪奇な汎用機指向なDBに繋がれていたので、えらい苦労しました。
今は制御系に移って、OOとは無縁の世界におる。上の場合の良い設計パターンってなんだったんだろう。
同じような帳票データに同じような処理があって、継承するような構造で作っていたら・・・
帳票画面は200画面以上あったので200クラス以上できた。
それが複雑怪奇な汎用機指向なDBに繋がれていたので、えらい苦労しました。
今は制御系に移って、OOとは無縁の世界におる。上の場合の良い設計パターンってなんだったんだろう。
733 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/03/08(木) 22:40:32
734 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/03/08(木) 22:41:20
というのは嘘で
べつにバラバラにつくってもよくない？
べつにバラバラにつくってもよくない？
テンプレートメソッドで良かったんじゃね？
>>733、>>735
うむ、まさにテンプレートメソッドのインスタンスクラス量産型。
昔は無理やりOO使っていたが、今はライブラリ開発以外は普通の構造化プログラムで十分。
WindowクラスからUSBPortProxyクラスまで何でもOO化してたなぁ・・・。なつかしす。
うむ、まさにテンプレートメソッドのインスタンスクラス量産型。
昔は無理やりOO使っていたが、今はライブラリ開発以外は普通の構造化プログラムで十分。
WindowクラスからUSBPortProxyクラスまで何でもOO化してたなぁ・・・。なつかしす。
それぞれの画面にはそれぞれ別クラスを用意するのが基本だろう。
ただ、共通化される処理やデータは基底クラスにかけるから、クラス数が多くたって
ソースの見通しは良くなる。
普通はロジック部分は分離するから更にクラス数は増えるし、インターフェイスにすれば、それぞれ実装クラスがあるから更に増える。
が、増えても設計がきちんとしていれば別に混乱もしないし、保守性も上がる。
DB部分はDAOクラスで隠蔽してしまえばいい
ただ、共通化される処理やデータは基底クラスにかけるから、クラス数が多くたって
ソースの見通しは良くなる。
普通はロジック部分は分離するから更にクラス数は増えるし、インターフェイスにすれば、それぞれ実装クラスがあるから更に増える。
が、増えても設計がきちんとしていれば別に混乱もしないし、保守性も上がる。
DB部分はDAOクラスで隠蔽してしまえばいい
>>737
はぁ？全然根拠なーいｗ
クラスが１００個２００個あったらどーすんだよ
こんなんで継承なんて使ってて変更あったら地獄だぞ
つか、間違いなく死ぬ
リストで単純に２００個管理したほうがよっぽどよかったと絶対に後悔する
こんなもん継承使ってツリーになんてするもんじゃない
単純にリストで管理すればどんなに増えても構造は簡単
ツリーは量が増えれば爆発的に複雑になっていく
はぁ？全然根拠なーいｗ
クラスが１００個２００個あったらどーすんだよ
こんなんで継承なんて使ってて変更あったら地獄だぞ
つか、間違いなく死ぬ
リストで単純に２００個管理したほうがよっぽどよかったと絶対に後悔する
こんなもん継承使ってツリーになんてするもんじゃない
単純にリストで管理すればどんなに増えても構造は簡単
ツリーは量が増えれば爆発的に複雑になっていく
前置きもなくJava前提で話をしちゃう奴がどーもな
ビューの部分は分離するに限る
741 ：仕様書無しさん：2007/03/08(木) 23:14:57
>>737
まあ、画面は増えても問題は無かったね。
ロジック部分は、ほとんど帳票データに一緒に記述されてたよ。
コードが増えて無駄があるようでも、あえてそうした。理由は、DBから取って来て
表示するだけのロジックに、クラス設計する手間が惜しかったから。
DAOは無し。頼りになるのはPL/Iで書かれた、過去のソース。
つーかDAOで隠蔽って、DAOは誰が作るんだよ！
２ヶ月で２人＋新人１人でやったプロジェクトだった。
設計１ヶ月、実装は中堅自分らが２人でやって、テストは全部新人。
最終的に新人が一番プロジェクト理解していたがな。
まあ、画面は増えても問題は無かったね。
ロジック部分は、ほとんど帳票データに一緒に記述されてたよ。
コードが増えて無駄があるようでも、あえてそうした。理由は、DBから取って来て
表示するだけのロジックに、クラス設計する手間が惜しかったから。
DAOは無し。頼りになるのはPL/Iで書かれた、過去のソース。
つーかDAOで隠蔽って、DAOは誰が作るんだよ！
２ヶ月で２人＋新人１人でやったプロジェクトだった。
設計１ヶ月、実装は中堅自分らが２人でやって、テストは全部新人。
最終的に新人が一番プロジェクト理解していたがな。
>>737
画面にビジネスロジックが引っ張られるのは本末転倒じゃね
画面にビジネスロジックが引っ張られるのは本末転倒じゃね
ちなみに言語はC#だぞ・・・。理由は携帯端末対応。（←電話じゃないやつ）
その携帯端末はダイナマイトが至近距離で爆発しても壊れない。
その携帯端末はダイナマイトが至近距離で爆発しても壊れない。
>>744
携帯端末が壊れる前に人が壊れるだろｗｗ
携帯端末が壊れる前に人が壊れるだろｗｗ
>>745
代わりはいくらでもいるもの
代わりはいくらでもいるもの
帳票といえばBIRTっていうのを聞いたことがあるな。つかったことないけど。
http://www.eclipse.org/birt/phoenix/
http://www.eclipse.org/birt/phoenix/
オブジェクト指向の話を拒否するスレはここですか？
>>747
デモがScreencast Loading...で止まってしまうのは・・・
デモがScreencast Loading...で止まってしまうのは・・・
で、なぜオブジェクト指向が流行らないの？
って理由は簡単。
開発言語はJavaやC#だけじゃねーんだよ
って理由は簡単。
開発言語はJavaやC#だけじゃねーんだよ
何でもオブジェクトにしようとする奴は
頑なにgotoを使おうとしない馬鹿
多分、10年後は今のコボラー以下の存在
頑なにgotoを使おうとしない馬鹿
多分、10年後は今のコボラー以下の存在
>>751
構造化とオブジェクト指向が混乱しとるぞ
構造化とオブジェクト指向が混乱しとるぞ
OpenSSLなんか見てみればわかると思うけど、ライブラリ作るのには
やっぱりOOPが適してるよな。
やっぱりOOPが適してるよな。
libcryptとlibsslのどっちが？
関数やクラスも 時計の歯車のようなものだ
stateパターンを使ってみたが糞だった
何で状態１つに対して1クラスが必要なんだ？
関数テーブルで良いじゃないか？
状態が100あったらメソッドが1つしかない100個クラス作るのかね？
何でもクラスにしようとする奴は馬鹿だね
何で状態１つに対して1クラスが必要なんだ？
関数テーブルで良いじゃないか？
状態が100あったらメソッドが1つしかない100個クラス作るのかね？
何でもクラスにしようとする奴は馬鹿だね
機能分割とモジュール化は、
どこかでかならずどっちを選択するか考えるときがくる
臨機応変でおｋ
どこかでかならずどっちを選択するか考えるときがくる
臨機応変でおｋ
>>756
糞なのはお前の設計だな
糞なのはお前の設計だな
新卒Javaオンリー君にはちょっと参る
オタクな知識を身に着ける前に
せめて基本情報レベルのことぐらい分かってもらわんと
オタクな知識を身に着ける前に
せめて基本情報レベルのことぐらい分かってもらわんと
>>756
ベタに１００個書かなくても
１０のグループに分けて内部に状態を入れ子にしたり出来るんじゃないか？
それに実際にメソッドを１００書くのもクラスを１００書くのも
コード量的にはそんなに変わらないと思うけどな
ベタに１００個書かなくても
１０のグループに分けて内部に状態を入れ子にしたり出来るんじゃないか？
それに実際にメソッドを１００書くのもクラスを１００書くのも
コード量的にはそんなに変わらないと思うけどな
はいはい、OOにすれば設計は簡素になって皆が幸せになります
幸せになれないのは自分の設計不足だからです
．．．ま、狂信者は多そうだけど流行りそうにない宗教だな
幸せになれないのは自分の設計不足だからです
．．．ま、狂信者は多そうだけど流行りそうにない宗教だな
継承やら多態性なんて言ってるうちは決して普及しねーな
言葉で敬遠するやつがワンサといるだろ
しかも「概念」ときてる
はぁ？？ってのが誰もが最初に思うしな
言葉で敬遠するやつがワンサといるだろ
しかも「概念」ときてる
はぁ？？ってのが誰もが最初に思うしな
>>762
勘弁してくれ
勘弁してくれ
Template Methodや、stateパターンでのインスタンスクラスを量産する
設計は、人海戦術向きと思えてならない。ある意味では有効かも。
んでも、デザパタとOOはイコールではないと思う。
OOは原理主義者っぽく考えると、それはそれで面白い。
でも、自分が本当に欲しいのは、OOじゃなくてここな辺。
・コンテナ
・ジェネレータ
・コルーチン
・C++でいうテンプレート
設計は、人海戦術向きと思えてならない。ある意味では有効かも。
んでも、デザパタとOOはイコールではないと思う。
OOは原理主義者っぽく考えると、それはそれで面白い。
でも、自分が本当に欲しいのは、OOじゃなくてここな辺。
・コンテナ
・ジェネレータ
・コルーチン
・C++でいうテンプレート
stateパターンってGoFの中でも最強のパターンだろ。
これみてピンとこないようじゃどうしようもないな。
これみてピンとこないようじゃどうしようもないな。
とりあえず764や765とは友達になりたくないのは事実だ
>>>>>>768
オブジェクト指向が好きな理由をどうぞ
オブジェクト指向が好きな理由をどうぞ
コードをコントロールする側・される側にキッチリ分解する。
で、コントロールされる側のコードを追加しようが変更しようが
コントロールする側のコードは二度と触らない。
これがバグをいれこまずに機能追加するための大原則で、ここが
わかってなきゃなんでデザインパターンがやくにたつのかわかりっこない。
で、コントロールされる側のコードを追加しようが変更しようが
コントロールする側のコードは二度と触らない。
これがバグをいれこまずに機能追加するための大原則で、ここが
わかってなきゃなんでデザインパターンがやくにたつのかわかりっこない。
>>770
Mediatorのようにお互いに通信する場合は？
Mediatorのようにお互いに通信する場合は？
773 ：仕様書無しさん：2007/03/09(金) 02:18:45
>>773
なんでおまえそんなに必死なんだよ。
なんでおまえそんなに必死なんだよ。
775 ：仕様書無しさん：2007/03/09(金) 02:36:15
必死じゃない、常識を言ってるだけ
OOを使ってデスマーチってのは、本当はOOを使えてないだけ
OOを使ってデスマーチってのは、本当はOOを使えてないだけ
読んでも読まなくてもいいから、OO本は買えるだけ買っとけ。いや、お願いします。
777 ：仕様書無しさん：2007/03/09(金) 02:43:49
何かお奨めある？
OOとデスマーチとは何の関連もないと思うけど。
OOで開発しようがしまいが、
デスマーチになるときはなる。ならないときはならない。
OOで開発しようがしまいが、
デスマーチになるときはなる。ならないときはならない。
デスマーチとコアラのマーチが混在しているスレはここですか？
781 ：おじゃばさま：2007/03/09(金) 09:36:55
俺が言うのもアレだが、StrutsやHibernateは腐ってるよ。
本当は使いたくないんだ。
本当は使いたくないんだ。
strutsはxml地獄。
ハイバネはマッピング地獄でOO思想がないと本格的に使えない。
単純なDTOマッパとして使うならiBATISだな。
ハイバネはマッピング地獄でOO思想がないと本格的に使えない。
単純なDTOマッパとして使うならiBATISだな。
783 ：C爺：2007/03/09(金) 10:06:41
strutsは設計者が「こいつには問題点がある」とのたまってたな。
スレッドセーフじゃない箇所があるんだろう。だめじゃん。
スレッドセーフじゃない箇所があるんだろう。だめじゃん。
>>764
ガッチリした親クラスを先行して作成できること。
ＰＧにそのクラスを継承して作成することを義務付け。
この２つができればかなり有効。
逆に上の２つが満たされないなら、
>>738のリスト型管理の方がマシ。
ガッチリした親クラスを先行して作成できること。
ＰＧにそのクラスを継承して作成することを義務付け。
この２つができればかなり有効。
逆に上の２つが満たされないなら、
>>738のリスト型管理の方がマシ。
ＰＧに俺が作った親クラスの継承を義務付けたんですが、
親クラスの変数やメソッドをことごとく無視しちゃって
くれてるんですが ;_;
親クラスの変数やメソッドをことごとく無視しちゃって
くれてるんですが ;_;
おまえのクラスがダサいからだ
あぁそういうことか、わかりました。
>>742
当然DBマネジャークラスは別にあるんだろ？
DBマネージャーやコントロール用のクラスをどうせ作らなきゃならないんだったら
dao作るのも平行してやりゃいいじゃん
その方が単体テストもやりやすいしinterfaceだけ定義しておけば、外側のロジックの
単体テストはモックの実装クラスを作っておいてやればokだし
当然DBマネジャークラスは別にあるんだろ？
DBマネージャーやコントロール用のクラスをどうせ作らなきゃならないんだったら
dao作るのも平行してやりゃいいじゃん
その方が単体テストもやりやすいしinterfaceだけ定義しておけば、外側のロジックの
単体テストはモックの実装クラスを作っておいてやればokだし
親クラスの継承て本当に必要だろうか
791 ：おじゃばさま：2007/03/09(金) 12:16:52
Struts、たかが検索結果一覧画面作るのに、なんであんな膨大なコードが必要なのかわからん。
タグライブラリ考えた奴なんてもう市ねって感じ。。
多言語対応も意味なしだよな。大体英語になったら、文言の表示位置すら変わるっての。
中途半端な入力チェックもツカエネー。エラーメッセージが「〜が不正です」じゃわからんての。
セッションもページにしないと、アクセス集中で死ぬし。
DBアクセスも一覧次ページ機能も標準にないって、どういうことよ？
無理にオブジェクト指向的にして失敗した典型例だよ。
タグライブラリ考えた奴なんてもう市ねって感じ。。
多言語対応も意味なしだよな。大体英語になったら、文言の表示位置すら変わるっての。
中途半端な入力チェックもツカエネー。エラーメッセージが「〜が不正です」じゃわからんての。
セッションもページにしないと、アクセス集中で死ぬし。
DBアクセスも一覧次ページ機能も標準にないって、どういうことよ？
無理にオブジェクト指向的にして失敗した典型例だよ。
なんだ、もっと的確に欠点を指摘するのかと思ったら、こんなものか。
Strutsはいろいろと問題点ありだが、
見当違い・ズレまくり・使えてないだけのあんたも問題点がかなりあるようだなｗ
市んでいいよ。＞おじゃば
Strutsはいろいろと問題点ありだが、
見当違い・ズレまくり・使えてないだけのあんたも問題点がかなりあるようだなｗ
市んでいいよ。＞おじゃば
つ Struts + Seaser
つ Struts + Velocity
つ Struts + JSF
つ ASP.NET
つ Struts + Velocity
つ Struts + JSF
つ ASP.NET
794 ：仕様書無しさん：2007/03/09(金) 12:31:45
>>791
●ページャタグ程度のものを自作できないおじゃばが馬鹿
●スタイルシートを知らないおじゃばが糞
●エラーメッセージのカスタマイズ方法を知らないおじゃばがクズ
●膨大な情報をセッションに保持するような設計をするおじゃばがハゲ
●ＤＢアクセス用のクラスがStrutsで提供されてると思っていたおじゃばがＤＱＮ
●ページャタグ程度のものを自作できないおじゃばが馬鹿
●スタイルシートを知らないおじゃばが糞
●エラーメッセージのカスタマイズ方法を知らないおじゃばがクズ
●膨大な情報をセッションに保持するような設計をするおじゃばがハゲ
●ＤＢアクセス用のクラスがStrutsで提供されてると思っていたおじゃばがＤＱＮ
おじゃばに、適用コンポートネントの決定権がなさそうだから、
勘弁してやれよ。
勘弁してやれよ。
でもstrutsなんて、マジで意味ない。
俺は絶対使わない。
俺は絶対使わない。
でも、使わされんダロ
かといってJSFは小回りきかないんだよな
JSPとServletで十分
テンプレート覚える暇があったら組んでる
つか、所詮テンプレート
つか、所詮テンプレート
テンプレート組む暇があったら覚えてる
つか、されどテンプレート
つか、されどテンプレート
(( 从 从 )）
. （（*‘ー ‘）） ＜やっぱちまちん語がいちばんね
と＼▽／つ
/二二二ゝ
∪ ∪
. （（*‘ー ‘）） ＜やっぱちまちん語がいちばんね
と＼▽／つ
/二二二ゝ
∪ ∪
804 ：おじゃばさま：2007/03/09(金) 19:47:49
>795
いや、自作やカスタマイズが出来ない訳じゃないんだよ。運用するにはカスタマイズして使うしかないしな。
しかしアクションクラスやフォームビーンは拡張したのに置き換わり、入力チェックのJavaScriptは
原形留めないし、タグライブラリも追加され、ページ制御用のjapやらスタイルシートやらてんこもりに
なる訳だ。で、こんなに変わるなら無理して使う意味もないって思うだろ。
試しに昔にどっかの会社が出した、HTMLにSQLを埋め込めるようなミドルがあって、
それを使うとあっと言う間に作れるんだぜ。
>800
そうそう、JspとBeanだけで簡単に出来るよな実際。
入力チェックと、ボタンやプルダウンや一覧表示用と、SQL実行用のBeanがあればいいんだよな。
つくってみよっと。
いや、自作やカスタマイズが出来ない訳じゃないんだよ。運用するにはカスタマイズして使うしかないしな。
しかしアクションクラスやフォームビーンは拡張したのに置き換わり、入力チェックのJavaScriptは
原形留めないし、タグライブラリも追加され、ページ制御用のjapやらスタイルシートやらてんこもりに
なる訳だ。で、こんなに変わるなら無理して使う意味もないって思うだろ。
試しに昔にどっかの会社が出した、HTMLにSQLを埋め込めるようなミドルがあって、
それを使うとあっと言う間に作れるんだぜ。
>800
そうそう、JspとBeanだけで簡単に出来るよな実際。
入力チェックと、ボタンやプルダウンや一覧表示用と、SQL実行用のBeanがあればいいんだよな。
つくってみよっと。
おじゃばはフレームワークというものを勘違いしているようだな。
おじゃばがとにかくヘタクソなのは分かった。頭悪すぎ。
おじゃばがとにかくヘタクソなのは分かった。頭悪すぎ。
806 ：仕様書無しさん：2007/03/09(金) 20:02:06
悪魔の辞典
用語
【フレームワーク】
ただでさえ回りくどいじゃわぽんがさらにまわりくどくプログラムしようとした結果
発生した屑の集合。
用語
【フレームワーク】
ただでさえ回りくどいじゃわぽんがさらにまわりくどくプログラムしようとした結果
発生した屑の集合。
フレームワーク使わずにMVCパターンを手作りすんのか？
それともMVCも否定すんのか？ 生サーブレットこそ混乱の種だと思うが。
脳みそが少ないと大変だな。
それともMVCも否定すんのか？ 生サーブレットこそ混乱の種だと思うが。
脳みそが少ないと大変だな。
Struts擁護してるやつは社内アプリとかしか作ってないんだろ。
ユーザビリティ無視な。
ユーザビリティ無視な。
Strutsとユーザビリティがなんで関係あんだ？
フレームワークとオブジェクト指向ってどう程度関連があるんだ？
具体的にﾖﾛ。
具体的にﾖﾛ。
交通規則とお巡りさん程度
jspからSQLって…
MVCどころかそもそもロジックをどこが持つのさ…
画面から入れたデータを出し入れするだけならいいかもしらんが
集計とかの計算も全部SQLでやんのか？
DB変わったらどうすんだ？
MVCどころかそもそもロジックをどこが持つのさ…
画面から入れたデータを出し入れするだけならいいかもしらんが
集計とかの計算も全部SQLでやんのか？
DB変わったらどうすんだ？
で、オブジェクト指向がなぜ流行らないのかまとまった？
Javaの話はもういいんで。
Javaの話はもういいんで。
java厨が現れるとせっかくの進展もストップするな。相変わらず。
DBが変わったら画面も変わるだろうよ
そもそもMVCなんてアホだろ
画面とDBは密接に結びついているんだよ
DBが変わったのに画面変更なしなんてシステムなんて作れるわけが無い
ウィンドウシステムとかCADみたいな面倒なシステムならともかく
DBを見たりするだけのシステムに余計な飾りをつける必要性が見えない
そもそもMVCなんてアホだろ
画面とDBは密接に結びついているんだよ
DBが変わったのに画面変更なしなんてシステムなんて作れるわけが無い
ウィンドウシステムとかCADみたいな面倒なシステムならともかく
DBを見たりするだけのシステムに余計な飾りをつける必要性が見えない
薄く小さい作りっぱなしのシステムならそれでもいいけど
むしろServletもいらない。JSPだけでOK
保守があるからこそ薄く作るのがよい
要するに、PHPしたいんだろ。
それだ！
わかった わかった
おまいら無理にOOせんでいい！
おまいら無理にOOせんでいい！
だがOOとStrutsは無関係であった。
とにかく言語に特化しない話をしろよな
つまり汎化だな
言語の親クラスは伝達手段クラスで、兄弟クラスが手話クラスとか
アイコンタクトクラスとか狼煙クラス等になります。
ちなみに、言語は、日本語クラスとか英語クラス等に特化されます。
アイコンタクトクラスとか狼煙クラス等になります。
ちなみに、言語は、日本語クラスとか英語クラス等に特化されます。
＞ちなみに、言語は、日本語クラスとか英語クラス等に特化されます。
おしい。これらはインスタンスだ。
おしい。これらはインスタンスだ。
828 ：仕様書無しさん：2007/03/09(金) 22:34:39
先ずだな、有機体クラスと情報体クラスを作れ
UMLの表記法を覚えるのは
オブジェクト指向の学習の一環だと考えていいのか？
あれこそが混乱の元のような気がするんだが。
オブジェクト指向の学習の一環だと考えていいのか？
あれこそが混乱の元のような気がするんだが。
830 ：仕様書無しさん：2007/03/09(金) 22:52:55
スキンは薄いのがいいよな？
そうか？
ちゃんとOOできてる実装１歩手前のクラス図なんて分かりやすいぞ。
適当に情報名とってクラス化して線引っ張っただけの絵をクラス図。
それをそのままER図として使ってるプロジェクトが多いから糞なだけ。
ちゃんとOOできてる実装１歩手前のクラス図なんて分かりやすいぞ。
適当に情報名とってクラス化して線引っ張っただけの絵をクラス図。
それをそのままER図として使ってるプロジェクトが多いから糞なだけ。
オブジェクト指向とDBは相性が悪い
つか、時代は既にインターフェース指向＆DIな訳だが。。
いつまで、オブオブ言ってるつもりだ？
いつまで、オブオブ言ってるつもりだ？
DB自体がオブジェクト
UMLの有用性はもちろんあるんだが、
多くのやつはクラスやインスタンスや継承といったオブジェクト指向の
テクノロジでとまってて、
UMLの更新なんかとてもじゃないけど頼めない。
書くのがめんどいってのがでかいのかも。
多くのやつはクラスやインスタンスや継承といったオブジェクト指向の
テクノロジでとまってて、
UMLの更新なんかとてもじゃないけど頼めない。
書くのがめんどいってのがでかいのかも。
>>835
DIってなに？
DIってなに？
依存性注入
>>838
Dutchwife Injectionの略
Dutchwife Injectionの略
【2chドメインモデル】
[掲示板]◆-->[板]◆-->[スレッド]◆-->[レス]
単純すぎだな。
この情報がシステムに保存されているとして、スレッドのレス数を取得するとき。
【OOの場合】
//関連ごとごっそりメモリ上に展開
Thread thread = ThreadPersister.load(threadId);
//メモリ上でカウント
int count = thread.countResponse();
【DB中心に考える場合】
//カウント用DAO生成
ResponseCountDAO dao = new ResponseCountDAOImpl();
//カウント結果だけ取得する
int count = dao.countResponse(threadId);
で、DAOの発行する以下のSQLで計算
select count(*) from RESPONSE where RESPONSE.THREAD_ID = XX;
計算方法がちょくちょく変わったりする場合、
どっちが簡単にコードを追えて後々の修正が楽だと思う？
[掲示板]◆-->[板]◆-->[スレッド]◆-->[レス]
単純すぎだな。
この情報がシステムに保存されているとして、スレッドのレス数を取得するとき。
【OOの場合】
//関連ごとごっそりメモリ上に展開
Thread thread = ThreadPersister.load(threadId);
//メモリ上でカウント
int count = thread.countResponse();
【DB中心に考える場合】
//カウント用DAO生成
ResponseCountDAO dao = new ResponseCountDAOImpl();
//カウント結果だけ取得する
int count = dao.countResponse(threadId);
で、DAOの発行する以下のSQLで計算
select count(*) from RESPONSE where RESPONSE.THREAD_ID = XX;
計算方法がちょくちょく変わったりする場合、
どっちが簡単にコードを追えて後々の修正が楽だと思う？
>>842
仕様がちょくちょく変わるような設計を見直すのが早い
仕様がちょくちょく変わるような設計を見直すのが早い
>>844
君が仕様書をよく読まないことはよくわかた
君が仕様書をよく読まないことはよくわかた
848 ：仕様書無しさん：2007/03/10(土) 00:20:15
>>845
詭弁のガイドラインより。
>11：レッテル貼りをする
>「犬が哺乳類だなんて過去の概念にしがみつく右翼はイタイね」
コミュニケーション能力が無いね。PCの前で顔真っ赤にしなくても。
>>835
>時代は既にインターフェース指向＆DIな訳だが。。
インターフェース指向＆DIで複雑なロジック組めるんですか？
DIする実装の実現方法にOOを使うのは全然アリでしょ。
詭弁のガイドラインより。
>11：レッテル貼りをする
>「犬が哺乳類だなんて過去の概念にしがみつく右翼はイタイね」
コミュニケーション能力が無いね。PCの前で顔真っ赤にしなくても。
>>835
>時代は既にインターフェース指向＆DIな訳だが。。
インターフェース指向＆DIで複雑なロジック組めるんですか？
DIする実装の実現方法にOOを使うのは全然アリでしょ。
オブジェクト指向を全く分かってない後輩と１年間ペアプログラミングしたら、
ほっといてもかなり上手にオブジェクト指向を利用したプログラムを書けるようになってくれた。
デザパタも一部ながら使えるようになった。
しばらくすると、「よく分からないんですけど簡単に仕様変更に対応できちゃうんですよ〜」って、
喜んで俺に報告してくるようになった。
まぁ彼もいずれそのうちその理由にも気づくだろう。
仕様変更が全く問題ではなくなるってのはOOのダイゴミだからね。もう病みつきだろ。
ほっといてもかなり上手にオブジェクト指向を利用したプログラムを書けるようになってくれた。
デザパタも一部ながら使えるようになった。
しばらくすると、「よく分からないんですけど簡単に仕様変更に対応できちゃうんですよ〜」って、
喜んで俺に報告してくるようになった。
まぁ彼もいずれそのうちその理由にも気づくだろう。
仕様変更が全く問題ではなくなるってのはOOのダイゴミだからね。もう病みつきだろ。
本当にぜんぜん関係のない話をします。
VisualStudio2005のC++。
リファクタリング機能ねーのかよ・・・ショック。。
C#に実装されてる、ってつかわねーよ！
VisualStudio2005のC++。
リファクタリング機能ねーのかよ・・・ショック。。
C#に実装されてる、ってつかわねーよ！
>>842の説明で、OOがメモリを浪費しネットワーク帯域を圧迫するしろもの
だということが良くわかった。
だということが良くわかった。
848のコミュニケーション能力について
ところで>>840をぐぐっても出てこないんですが。
857 ：仕様書無しさん：2007/03/10(土) 00:30:53
OO妄信者と彼らを卑下するｺﾎﾞﾗが集まるスレはここですか？
ここじゃないです
まああれだ。
オブジェクト指向を神格化しちゃってる文面は引くわな。
オブジェクト指向を神格化しちゃってる文面は引くわな。
>>856
お前がバカ正直で天然って事は痛いほど良く分かった。
お前がバカ正直で天然って事は痛いほど良く分かった。
うちの会社は関連会社も含めて全員C++で開発しているから、
てっきり世の中は全員OOを使っているのかと思ったよ。
てっきり世の中は全員OOを使っているのかと思ったよ。
863 ：仕様書無しさん：2007/03/10(土) 00:35:31
昔はプログラムを、速く動作するように、メモリをあまり消費しないように、ディスクをあまり消費しないようにという考え。悪いことじゃない。
OOの考え方だと、高速化や軽量化よりも、いかに拡張性を確保するか、いかに自然なプログラムにするかということが重要視されている。
って、ここに書いてあったよママ！！
ttp://homepage1.nifty.com/~takaot/oo/index.html
OOの考え方だと、高速化や軽量化よりも、いかに拡張性を確保するか、いかに自然なプログラムにするかということが重要視されている。
って、ここに書いてあったよママ！！
ttp://homepage1.nifty.com/~takaot/oo/index.html
素人さんのＨＰ貼られても．．．
動作周波数33MHz、メインメモリ2MBのプレステでC++を使ってゲームを作っていた俺様からすれば、
OOだから遅くなるってのはコーディングが下手くそなだけ。
OOだから遅くなるってのはコーディングが下手くそなだけ。
フローチャートが最強なんだが
867 ：仕様書無しさん：2007/03/10(土) 00:41:50
メソッド内レベルであればフローチャートもありだが、他クラスとのやりとりをどう書くんだ。
そのフローチャートはグローバル変数でいっぱいだな。
そのフローチャートはグローバル変数でいっぱいだな。
別の紙にしてモジュール化しちゃえばいいじゃん
>>866
メソッド単位だとフローチャート書く程長くなくね？今時。
メソッド単位だとフローチャート書く程長くなくね？今時。
871 ：仕様書無しさん：2007/03/10(土) 01:48:05
C/C++はさコンパイラとOSが全ていい感じにやってくれるんだよ
お前ら、色々わけのわからん図作るの好きだな、Cはフローチャートだけでいいんだよ
シンプル伊豆ベストだよ
お前ら、色々わけのわからん図作るの好きだな、Cはフローチャートだけでいいんだよ
シンプル伊豆ベストだよ
低レベルには低レベルの高レベルには高レベルの考え方がある
873 ：仕様書無しさん：2007/03/10(土) 04:04:43
Javaもいい感じでやってくれるんだってね
んぽぽん、んぽぽん、んぽぽん、いい感じだ
んぽぽん、んぽぽん、んぽぽん、いい感じだ
>>868
言語仕様で何が参照で何が実体なのかを把握してきちんとコーディングすれば
メモリをバカスカ食ったり遅延が発生したりする事はない。
objectはシングルトンでいいのかインスタンスでなければならないのか、呼ばれる機能
はスタティックでOkなのかインスタンス依存なのか。
取りあえずnewしておけ的なコーディングや設計をするやつが問題
言語仕様で何が参照で何が実体なのかを把握してきちんとコーディングすれば
メモリをバカスカ食ったり遅延が発生したりする事はない。
objectはシングルトンでいいのかインスタンスでなければならないのか、呼ばれる機能
はスタティックでOkなのかインスタンス依存なのか。
取りあえずnewしておけ的なコーディングや設計をするやつが問題
ダイナミック インジェクション
言語仕様はスレ違い
☆ ﾁﾝ ﾏﾁｸﾀﾋﾞﾚﾀ〜
ﾏﾁｸﾀﾋﾞﾚﾀ〜
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ 流行らない結論まだ〜？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| ｵﾌﾞｼﾞｪｸﾄ指？ |／
ﾏﾁｸﾀﾋﾞﾚﾀ〜
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ 流行らない結論まだ〜？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| ｵﾌﾞｼﾞｪｸﾄ指？ |／
>>878
別に特別視したり身構えたり神のように崇めたりする必要はないのに、
なぜかそういう人たちがいるから混乱してるように見える、ってだけじゃないの？
さらに一部の人は「あいつらとは目をあわせちゃいけない」とか「あんな奴らと
同じ仲間とは見られたくない」とか考えていたりして、更に混乱に拍車がかかる、と。
冷静にみると浸透し定着してるだろう。「分割統治」の考え方としては。
そっから先のヤクザの縄張り争いみたいな勢力争いの状況はわからん。
別に特別視したり身構えたり神のように崇めたりする必要はないのに、
なぜかそういう人たちがいるから混乱してるように見える、ってだけじゃないの？
さらに一部の人は「あいつらとは目をあわせちゃいけない」とか「あんな奴らと
同じ仲間とは見られたくない」とか考えていたりして、更に混乱に拍車がかかる、と。
冷静にみると浸透し定着してるだろう。「分割統治」の考え方としては。
そっから先のヤクザの縄張り争いみたいな勢力争いの状況はわからん。
「浸透」はしてる。
が、使いこなせていない
が、使いこなせていない
とはいえ、今まで何かを使いこなせたことなどなかった。
プログラミング言語の場合は自分の知識範囲が分かった上で
プロジェクト内で意見交換（知識共有）ができるんだが、
オブジェクト指向はもっさりしてるというかアバウトなイメージが先行し、
知識共有が無理。１００人単位PJなんて無理も無理。
プロジェクト内で意見交換（知識共有）ができるんだが、
オブジェクト指向はもっさりしてるというかアバウトなイメージが先行し、
知識共有が無理。１００人単位PJなんて無理も無理。
ユーザー側の視点から言わせてもらえば、
作り手の理屈や趣味にしか見えないUMLやXPを
声高々上げられて、意味の分からん資料だらけより
ちゃんと分かるものが欲しいわ。
仕様変更が簡単にできますよ、なんて言ってる会社ほど信用できん
作り手の理屈や趣味にしか見えないUMLやXPを
声高々上げられて、意味の分からん資料だらけより
ちゃんと分かるものが欲しいわ。
仕様変更が簡単にできますよ、なんて言ってる会社ほど信用できん
ついでに。
あんたら技術者には関係ないだろうが、
一番金がかかるのは開発段階じゃなくて運用。
バグだらけの最新技術で作ったものより、
安定稼動の過去技術のほうがありがたい。
あんたら技術者には関係ないだろうが、
一番金がかかるのは開発段階じゃなくて運用。
バグだらけの最新技術で作ったものより、
安定稼動の過去技術のほうがありがたい。
システムは運用できて何ぼのもんですからな。
開発屋は自分の技術をひけらかすのに専心する癖が
あるので、実は嫌われているのです。
開発屋は自分の技術をひけらかすのに専心する癖が
あるので、実は嫌われているのです。
仕様を正確にドキュメント上にあらわすと当事者以外には読めない一品ができあがるからな。
おそらくユーザや発注元は、仕様なんて知らなくて良いのだと思う。
おそらくユーザや発注元は、仕様なんて知らなくて良いのだと思う。
>>886
だから、外部仕様と内部仕様を分けろと。
だから、外部仕様と内部仕様を分けろと。
StrutsアプリよりASPアプリのがレスポンスが速い件
Strutsって何か応答が遅くなりそうなことしてたっけ。
してないと思うけど。
してないと思うけど。
890 ：仕様書無しさん：2007/03/10(土) 10:48:43
Strutsのアクションフォームクラスで
68行インポートされている件
68行インポートされている件
>>890
それでなぜ遅くなるのか説明してよ。
それでなぜ遅くなるのか説明してよ。
遅いの早いの、おまいらいつの時代の人間だよｗ
つか何でここ雑談スレなっちゃってんの。
894 ：仕様書無しさん：2007/03/10(土) 11:10:27
>>884
俺の知り合いは枯れて安定したＣＯＢＯＬでバグだらけのソフトを作ってるぜｗ
俺の知り合いは枯れて安定したＣＯＢＯＬでバグだらけのソフトを作ってるぜｗ
>>893 午前中だから
またJava厨があばれとる
設計ってことを考えるときはスコープの合意が出来てないと話が進まない。
よくみるデスマの光景。
言語仕様で、〜ができないという情報は重要だが、
それで〜 これで〜 と、些細なことを持ち出して混乱させるのは
厨房レベルの奴の悪い癖。
そういうんだから、大体大事な話には加えてもらえない。
よくみるデスマの光景。
言語仕様で、〜ができないという情報は重要だが、
それで〜 これで〜 と、些細なことを持ち出して混乱させるのは
厨房レベルの奴の悪い癖。
そういうんだから、大体大事な話には加えてもらえない。
>>883
おまえらが勉強しろやｗ
おまえらが勉強しろやｗ
最終的には全体のレベルが高くならないと駄目だろ
啓蒙が必要ってことだ
啓蒙が必要ってことだ
仕様変更に対応にできるなんてのは言語の恩恵じゃない。
そう作るからだ。つまり、「仕様変更に対応にできる」と
いうのも、そのシステムの仕様として作っているのだ。
オブジェクト指向は十分流行っている。ただその意義がよく
理解されず、皆が使いこなせているわけではないということ。
ということで、次のスレタイは
「ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ理解されないの」とか
「ｵﾌﾞｼﾞｪｸﾄ指向開発をなぜ使いこなせないの」とか
にして欲しい。
そう作るからだ。つまり、「仕様変更に対応にできる」と
いうのも、そのシステムの仕様として作っているのだ。
オブジェクト指向は十分流行っている。ただその意義がよく
理解されず、皆が使いこなせているわけではないということ。
ということで、次のスレタイは
「ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ理解されないの」とか
「ｵﾌﾞｼﾞｪｸﾄ指向開発をなぜ使いこなせないの」とか
にして欲しい。
だから発注する側の担当者もUMLぐらい出来るようにならないとな
>>901
>仕様変更に対応にできるなんてのは言語の恩恵じゃない。
>そう作るからだ。つまり、「仕様変更に対応にできる」と
>いうのも、そのシステムの仕様として作っているのだ。
これは激しく同意。
こんなの仕様変更を先読みしてたまたま読みがあたっただけに過ぎない。
現場で仕事してりゃ予想もしてない客の吃驚発言なんていくらでもあるし
毎回ある程度を予測して余分に汎用性をつけると返ってバグを埋め込む可能性もある。
ただ、インスタンスが３→５になるとかそういうのは考慮して組まなきゃ駄目だと思うが・・・
>仕様変更に対応にできるなんてのは言語の恩恵じゃない。
>そう作るからだ。つまり、「仕様変更に対応にできる」と
>いうのも、そのシステムの仕様として作っているのだ。
これは激しく同意。
こんなの仕様変更を先読みしてたまたま読みがあたっただけに過ぎない。
現場で仕事してりゃ予想もしてない客の吃驚発言なんていくらでもあるし
毎回ある程度を予測して余分に汎用性をつけると返ってバグを埋め込む可能性もある。
ただ、インスタンスが３→５になるとかそういうのは考慮して組まなきゃ駄目だと思うが・・・
次スレタイ
「ｵﾌﾞｼﾞｪｸﾄ指向開発をなぜ使いこなせないの？★4」
「ｵﾌﾞｼﾞｪｸﾄ指向開発をなぜ使いこなせないの？★4」
>>905
日本語でおｋ
日本語でおｋ
UMLが技術者だけのものと思っているような発注者に限って
丸投げするくせに文句・クレームは一人前だったりする。
丸投げするくせに文句・クレームは一人前だったりする。
おまいらカスはOO分かってなくていいよ
分かってる一握りの人間が、OOで設計しておまいらの頭でも分かるように
割り振ってやるから。
分かってる一握りの人間が、OOで設計しておまいらの頭でも分かるように
割り振ってやるから。
宗教じゃなくて現実問題ですよ
実際、ユーザへの説明資料ってどんなのが使われてんの？
今時設計者とプログラマーが別でいいなんて言ってるのは勉強しねー奴だけ
勉強しねー奴は当然オブジェクト指向も勉強しねー
勉強しねー奴は当然オブジェクト指向も勉強しねー
建物を作るとき、設計する建築家さんと、現場で組立作業を行なうドカタさんがおります。
>>915
プログラムを作るとき、設計する技術者さんと、現場でコーディング作業を行なうデジタルドカタさんがおります。
みんな！！！UMLとOOD/A/Pをマスターして、脱デジドカ目指そう！！！(^^)v
>>915
プログラムを作るとき、設計する技術者さんと、現場でコーディング作業を行なうデジタルドカタさんがおります。
みんな！！！UMLとOOD/A/Pをマスターして、脱デジドカ目指そう！！！(^^)v
現場でコーディングする場合でも設計の能力は役に立つわけだが
919 ：仕様書無しさん：2007/03/10(土) 14:47:38
建設とソフト開発は全然違うだろ…常識的に考えて
ユーザを開発現場に引き込むのはアジャイル開発の原則の一つ。
技術者だけで作らせると独りよがりな使えないしろものが出来上がるからな。
技術者だけで作らせると独りよがりな使えないしろものが出来上がるからな。
もまぃらほんとループするの好きだな
ウォーターフォールじゃなくてOOの話だろ
ウォーターフォールじゃなくてOOの話だろ
自分の場合はオブジェクト指向はあるから使ってるって感じだな。
無理矢理使うと手間ばかり増えてロクな事にならん。
継承なんてしても完璧に再利用できるクラスなんてまず無いし、
ポリモフィズムも適用数が多くなければ面倒なだけでメリットなし。
手続き型の分岐処理でも同じ処理のI/Oさえ押さえとけば、分岐数が
多くなって来た時に初めてクラス分けしても遅くは無い。
必要なら使えばいいだけのことだと思うよ。
無理矢理使うと手間ばかり増えてロクな事にならん。
継承なんてしても完璧に再利用できるクラスなんてまず無いし、
ポリモフィズムも適用数が多くなければ面倒なだけでメリットなし。
手続き型の分岐処理でも同じ処理のI/Oさえ押さえとけば、分岐数が
多くなって来た時に初めてクラス分けしても遅くは無い。
必要なら使えばいいだけのことだと思うよ。
次スレタイ
「ｵﾌﾞｼﾞｪｸﾄ指向開発をなぜ使いこなせないの？★4」
「ｵﾌﾞｼﾞｪｸﾄ指向開発をなぜ使いこなせないの？★4」
日本語がヘンなスレタイだな
これならどうだ
「【OO】ｵﾌﾞｼﾞｪｸﾄ指向はなぜ開発現場で使いこなせないの？★4」
「【OO】ｵﾌﾞｼﾞｪｸﾄ指向はなぜ開発現場で使いこなせないの？★4」
クラスは手続き型の時のサブルーチンの延長と思って使えば便利かな。
メンバ隠せたり不用意にデータを操作してしまったりする単純ミス避け
になるのはメリットあるし、最近のIDEは昔のTurboCなんかと比べると
遥かに使いやすい。
コーディングしたことも無いPMが無理して、と言うか変に意識してOOP！OOP!
と主張してるから特別なものと勘違いされて敬遠されてるのかも。
メンバ隠せたり不用意にデータを操作してしまったりする単純ミス避け
になるのはメリットあるし、最近のIDEは昔のTurboCなんかと比べると
遥かに使いやすい。
コーディングしたことも無いPMが無理して、と言うか変に意識してOOP！OOP!
と主張してるから特別なものと勘違いされて敬遠されてるのかも。
何故オブジェクト指向なのか！？★4
オブジェクト指向は単なるカプセル化の道具ではなく
プログラムに動的な構造を持たせるためのものだと思うけど
プログラムに動的な構造を持たせるためのものだと思うけど
>>927
実際にはクラス数＝.cpp/.javaファイル数のような機能分割になってる奴が多い。
クラスの利便性を分かってる奴が作ったものと、
そうでないものの差はあとあと響いてくる。
サブルーチンの延長ってのは言いたいことは分かるが、
オブジェクト指向を無視したクラス設計になりそうで嫌やわ
実際にはクラス数＝.cpp/.javaファイル数のような機能分割になってる奴が多い。
クラスの利便性を分かってる奴が作ったものと、
そうでないものの差はあとあと響いてくる。
サブルーチンの延長ってのは言いたいことは分かるが、
オブジェクト指向を無視したクラス設計になりそうで嫌やわ
寧ろゲームなんかの世界の方がOOPがすんなり受け入れられてそうな
気がする。RPGとか。
現実世界は概念的なオブジェクトが多いから人によって捕らえ方が
違うから、あーだ、こーだ、いらねーえよってなってる気がする。
気がする。RPGとか。
現実世界は概念的なオブジェクトが多いから人によって捕らえ方が
違うから、あーだ、こーだ、いらねーえよってなってる気がする。
>>930
単純なサブルーチンで無いのは判ってるけどね。
まずデータありきで、そのデータに対する操作を一まとめにクラス化
してしまうと不用意なバグが防げるのでその程度で使ってるかな。
クラス数＝機能分割になっちゃってるのは、納期重視で機能別に分割して
マンパワーで分業化しちゃうのが多いからある意味仕方無いのかもしれない。
単純なサブルーチンで無いのは判ってるけどね。
まずデータありきで、そのデータに対する操作を一まとめにクラス化
してしまうと不用意なバグが防げるのでその程度で使ってるかな。
クラス数＝機能分割になっちゃってるのは、納期重視で機能別に分割して
マンパワーで分業化しちゃうのが多いからある意味仕方無いのかもしれない。
オブジェクト指向全滅！！★4
オブジェクト嗜好設計は何故流行らない？★4
流行らない、って言葉は不自然だな
現場にはあるんだから
現場にはあるんだから
_,､,､,､,_
.,イ}:}:}:}:}:}:}:}ｋ、
/:::l´￣`'￣`i:::}
.{:::ﾉ ､＿,.､＿,リ
fV ｀ﾟ 〕〔 ﾟ´ ,} 呼んだ？
ヽﾍ '､二,ヽ ﾉ
＼ ｀´ ／
｀￣
.,イ}:}:}:}:}:}:}:}ｋ、
/:::l´￣`'￣`i:::}
.{:::ﾉ ､＿,.､＿,リ
fV ｀ﾟ 〕〔 ﾟ´ ,} 呼んだ？
ヽﾍ '､二,ヽ ﾉ
＼ ｀´ ／
｀￣
オブジェクト指向ぬるぽ！！★4
938 ：仕様書無しさん：2007/03/10(土) 16:49:39
んぽぽんが語るオブジェクト指向！！★4
【OOP】ｵﾌﾞｼﾞｪｸﾄ指向はなぜ開発現場で使いこなせないの？★4
【コピペとデスマ】わざわざオブジェクト指向を使う必要あるの？★4
いい！
【無謀】ｵﾌﾞｼﾞｪｸﾄ指向を馬鹿に理解らせるには？【ｼﾞﾚﾝﾏ】★4
【んぽぽん】馬鹿に刃物【オブジェクト指向】
【再帰なのになあ】馬鹿をコントールする仕組みにはめられた【ジャワぽん】
945 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/03/10(土) 17:55:46
選民思想
OO厨はよく思い出してほしい。
OO以外を劣等プログラミングと決め付け、年配者を浄化をしようとした自分を覚えているだろう。
その思い上がりが現在の惨状を招いているのだ。
OO厨はよく思い出してほしい。
OO以外を劣等プログラミングと決め付け、年配者を浄化をしようとした自分を覚えているだろう。
その思い上がりが現在の惨状を招いているのだ。
もう
【全面戦争】OO信者(神？) vs. OOアンチ(悪魔？)【勃発】★4
でいいよ。
【全面戦争】OO信者(神？) vs. OOアンチ(悪魔？)【勃発】★4
でいいよ。
OOが良くわからんから糞とか言ってる奴は
ポインタが良くわからんから糞と言ってる奴と同レベルだと言うことを
忘れないで欲しい
ポインタが良くわからんから糞と言ってる奴と同レベルだと言うことを
忘れないで欲しい
いい！
950 ：仕様書無しさん：2007/03/10(土) 18:11:36
>>948
つまり、C++使い以外は糞と言うことですね
つまり、C++使い以外は糞と言うことですね
ぐだぐだ感がいい！
952 ：仕様書無しさん：2007/03/10(土) 20:25:41
誰か次スレよろ
タイトル長すぎると弾かれるのでちょっと省略。
●スレタイ
【OOP/D】ｵﾌﾞｼﾞｪｸﾄ指向を現場で使いこなせない訳★4
●テンプレ
【前スレ】
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3
http://pc11.2ch.net/test/read.cgi/prog/1171808096/
哲学論で否定、肯定はせずに、まずは参考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
さあ、張り切っていきましょう。
タイトル長すぎると弾かれるのでちょっと省略。
●スレタイ
【OOP/D】ｵﾌﾞｼﾞｪｸﾄ指向を現場で使いこなせない訳★4
●テンプレ
【前スレ】
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3
http://pc11.2ch.net/test/read.cgi/prog/1171808096/
哲学論で否定、肯定はせずに、まずは参考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
さあ、張り切っていきましょう。
953 ：仕様書無しさん：2007/03/10(土) 21:24:06
>>953 乙
埋め
【短期&作りっぱなし】オブジェクト指向が流行るわけないじゃん★5
ぬるぽ★5
958 ：仕様書無しさん：2007/03/11(日) 13:27:24
ＯＯ厨 兄w
959 ：仕様書無しさん：2007/03/11(日) 15:03:59
短納期厳守の大規模大人数開発では使えるわけが無い。
ある程度納期を柔軟に決定できるパッケージ開発とか
少数精鋭のプロジェクトにしか使えないよ。
当初の設計どおりになんて『絶対に』作れないんだから
手戻りした場合の影響が激しいOOで大規模開発は無理。
ある程度納期を柔軟に決定できるパッケージ開発とか
少数精鋭のプロジェクトにしか使えないよ。
当初の設計どおりになんて『絶対に』作れないんだから
手戻りした場合の影響が激しいOOで大規模開発は無理。
＞手戻りした場合の影響が激しいOOで
え？
え？
一足お先に>>959の人気に嫉妬。
>>959の設計の悪さに皆突っ込み
しかしオブジェクト指向ってもともと設計を楽するための指向だろ？
設計で多少辛い思いをして後で楽になろう指向
>>964
モジュール化をしやすくするための考え方だと思ってたけど
モジュール化をしやすくするための考え方だと思ってたけど
959のOOってObjectOrientedじゃないらしいな
OODやったことも無く現実を知らないド素人どもが突っ込みまくってるなｗ
少数精鋭でOOで開始されたものに、素人が近寄れないのと、
最初に大人数でOOで開始された（らしい）ものが破綻するのとは、
全然わけが違う
最初に大人数でOOで開始された（らしい）ものが破綻するのとは、
全然わけが違う
その違いも判らん自称OOP使いが下手な突っ込み入れてるんだろうな。
奴らは「OOで開始された（らしい）ものが破綻する」も理解できないだろうし。
こんな事だからOOは誤解されっぱなしなんだろうな･･･
奴らは「OOで開始された（らしい）ものが破綻する」も理解できないだろうし。
こんな事だからOOは誤解されっぱなしなんだろうな･･･
OOが人海戦術に不向きなのは
大きな欠点ではないかと思う今日この頃。
大きな欠点ではないかと思う今日この頃。
人海戦術に使うには、まず少数精鋭でガチガチに固めた雛型
（フレームワーク）用意しないと好き勝手にされちゃうからね。
しかしガチガチに固めると土壇場の仕様変更連発の我侭ユーザ
相手に身動き取れなくなる。
（フレームワーク）用意しないと好き勝手にされちゃうからね。
しかしガチガチに固めると土壇場の仕様変更連発の我侭ユーザ
相手に身動き取れなくなる。
OOが不向きなのではなくて、
OOに不向きな連中が多いだけ。
OOに不向きな連中が多いだけ。
元請の営業系SEから
なぜかおたくに作ってもらうシステムは
ユーザーに評判がよく仕様変更も入らないし
安定してるし不思議ですねーっていわれる。
俺ってどんだけすごいんだよｗ
なぜかおたくに作ってもらうシステムは
ユーザーに評判がよく仕様変更も入らないし
安定してるし不思議ですねーっていわれる。
俺ってどんだけすごいんだよｗ
誤爆だな
>>971
設計がちゃんとしていれば人海戦術でも行ける。
が、逆に言えば設計がちゃんとしてないのに大量に人突っ込まれると破綻する。
柔軟に出来る言語ほど、ガイドラインがないとどんな組み方も出来てしまう分たちが悪いかもしれん。
破綻するかしないかは設計のレベルとフレームワーク次第だと思うんだがな。
設計ダメ、フレームワークなしなんてモノは始まる前から終わってる。
設計がちゃんとしていれば人海戦術でも行ける。
が、逆に言えば設計がちゃんとしてないのに大量に人突っ込まれると破綻する。
柔軟に出来る言語ほど、ガイドラインがないとどんな組み方も出来てしまう分たちが悪いかもしれん。
破綻するかしないかは設計のレベルとフレームワーク次第だと思うんだがな。
設計ダメ、フレームワークなしなんてモノは始まる前から終わってる。
977 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/03/12(月) 05:40:15
UML図ってメンテナンスで使う？
ひょっとして書くだけでまったく使わなかったりしない？
ひょっとして書くだけでまったく使わなかったりしない？
納品物ならメンテナンスするわなぁ。
リバースエンジニアリングでちょちょいと。
リバースエンジニアリングでちょちょいと。
>>974
イヤミだってことに気づけよ
イヤミだってことに気づけよ
>>979
ひがむなよｗ
ひがむなよｗ
982 ：おじゃばさま：2007/03/12(月) 16:36:27
>807
さんざん使ってから言うのもなんだが、MVC否定だよ。
817の言うようにサーブレットもいらねー。Jspだけでいいや。
>812
計算や集計は当然SQLだろ。SQLで出来ない処理はBeanでやる。
DB変わったらどうする？815の言う通り修正するだろう。
と言う訳で、
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
|
＿＿＿＿.＿＿＿＿ |
| | | |
| | ∧＿∧ | |
| |（ ´∀｀）つ ミ |
| |/ ⊃ ﾉ | | [Struts、Hibernate]
￣￣￣￣'￣￣￣￣ |
|
さんざん使ってから言うのもなんだが、MVC否定だよ。
817の言うようにサーブレットもいらねー。Jspだけでいいや。
>812
計算や集計は当然SQLだろ。SQLで出来ない処理はBeanでやる。
DB変わったらどうする？815の言う通り修正するだろう。
と言う訳で、
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
|
＿＿＿＿.＿＿＿＿ |
| | | |
| | ∧＿∧ | |
| |（ ´∀｀）つ ミ |
| |/ ⊃ ﾉ | | [Struts、Hibernate]
￣￣￣￣'￣￣￣￣ |
|
そんなおじゃばにはPHPの方が向いてるかも
>>983
全くその通りだｗ
全くその通りだｗ
おじゃばの主張は、ASP.NETより昔のASPがよかったと言ってるようなもの。
IDEが進化してコンポーネント指向になったら、やっぱこっちとか言い出すんだろ？
IDEが進化してコンポーネント指向になったら、やっぱこっちとか言い出すんだろ？
だからなんでお前らはすぐ言語の話を持ち出すんだ？
何度同じこと繰り返してんだか
何度同じこと繰り返してんだか
言語は大事だろ。>>986はコボラー相手に設計してろよ。
>>987
顔真っ赤だぞ
顔真っ赤だぞ
ここマ板だぞ
991 ：おじゃばさま：2007/03/12(月) 18:52:09
じゃPHPやってみる。
PHPなんてやるよりレガシーCが最強だぞ。なっ。おじゃば。
最強に手間がかかりますがな
Ａｄａでもやっとれ
自己と向き合い自己を見つめ直せ
自己と向き合い自己を見つめ直せ
そして、層化学会に入信して池田先生に帰依しろよ
記念にぬるぽ
記念にガッ！
1000なら次のバッチはJavaで作る
1000ならみんなOOD/Pが理解できるようになる！
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。