オブジェクト指向ってどうよ？
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
NGNG増えてる気がするんだけど？
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNG> なんかさ、コーディングはラクになったけど実行速度とメモリ使用量が
> 増えてる気がするんだけど？
そりゃ多少は増えるだろ。
0004デフォルトの名無しさん
NGNG実行時間のことだろ。
くだらん揚げ足取るな。
0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNG0007デフォルトの名無しさん
NGNGなるでしょ？
0008デフォルトの名無しさん
NGNG楽にならなきゃ、設計が悪いだの、理解してないだのと、
王様は裸だと言いにくい状況。
そりゃ出来合いのクラスライブラリを使うだけなら楽かもしれないけど。
それなら関数ライブラリ使うのだっておんなじだ。
継承？予測可能で限定的な拡張しかできない。
柔軟なスパイラル開発なんて絵に書いた餅。
保守しやすい？継承ツリーのおかげで、ソース読むのが大変。
デバッグしにくくてたまんねー。
0009デフォルトの名無しさん
NGNGいや、それは君の設計が…（藁
0010デフォルトの名無しさん
NGNG8の長文ぶりをみれば、そうだろうな。
0011デフォルトの名無しさん
NGNG手続き型のフローから、UMLっぽいのに変わった(藁
0012吉田弘一郎
NGNG0013デフォルトの名無しさん
NGNGやりにくくない？
設計も実装も同時に柔軟に改良していける方が
いいような気がする。
オブジェクト指向でそういうやり方できないかな？
0014デフォルトの名無しさん
NGNGその調子で手続き型も構造化も否定してろ。
少なくとも(マスメディアに自分で露出してる分の)奴は
技術者じゃないな。業界動向watch(しそこね)野郎だ。
>>8
ええとなあ。「ライブラリ(毎回使いまわす奴というほど
強い意味じゃなくてもよくて、案件ごとに使い捨てる奴も含む)を
作る」のが楽になるぞ。データの寿命とかを明示的に考える、
つまり考慮するのを忘れることが無くなる(笑)んで、
そういう面では信頼性の高いライブラリを書ける。
状態を持たないライブラリならまだしも、状態を持つなら
絶対OOPでライブラリ書きたいものだよ。
あと、周知の事実だけど、そういうライブラリを使う側も
楽だしさ。
全体の工数は上がるかも知れないが、
各個撃破という感じはする。つまりサブとメインを個別に
従来よりしっかりと、作ることができる(しやすい)という。
設計うんざりという話については、
Object(の元であるClass)を「小粒に」作るのが善だと思う。
設計より集約っていうのは或る程度真実を言い当てているようで、
ならば集約「で」プログラムを作りやすいように考えとく必要があるね。
大粒な奴じゃあ集約のしようが無いから、むしろ
「なんでこんな小さくて下らないものまで？」
というような小さなクラスを作って、それを組み合わせる
(組み合わせそのものが楽なのは周知)ことで、次の
やや大きめの部品を作り、更にそれを…
という感じが、良いようである。
OOPって結局は、今まで巨大な1つのアプリだったものを
分割して小アプリ(の組み合わせ)にしようっていうものだから、
クラスは小さくすると結構嬉しいぞ。
勿論、小さいのを集約して出来た中規模部品もまた、
仕様という意味では「小さい」んだよ。
細かい部分は小部品に隠蔽されてるから、
中部品そのものが責任を受け持つ「仕様」は
大きくなる必要がないし、なるべきでもない。
なにごとも、「わかんなくなるほどでかく」するのはまずい、ってことさ。
0015デフォルトの名無しさん
NGNGおまえの文章むかむかする。
0016デフォルトの名無しさん
NGNG牢害発見
0017デフォルトの名無しさん
NGNGいまごろ実装継承の問題点を指摘されても……。それは設計が悪い
としか言えませんな。
0018デフォルトの名無しさん
NGNGUMLもトップダウンの考え方が柱にあるから、設計と実装を柔軟にやろうとすると、
かえって破綻を招きやすいような気がする。
設計のボリュ−ムは膨れ上がるけどね。
0019デフォルトの名無しさん
NGNG>ＯＯって欧米的合理性の固まりだよね。
少なくともこの行は同意。
OOを東洋思想と重ねて考えるのはドキュだろ。
(Smalltalkのあの人も含めて)
ただ、当初はともかく、最近は柔らかい方向も
取り入れられてきてるぞ。
フランス料理で油使わない人が
出てきてるのと似たようなものか。
継承より集約！ってのもその流れの1つだし。
で、その流れにイマイチついて来れていないのがUML(藁
固い方向性のJavaなんかに焦点合わせるから痛いことになる。
むしろ(ちょっと畑が違うが)XPのほうが有望…か？
あそこまでコーディング主義なのは行き過ぎだとは思うが、
設計原理主義よりはマシ。安全だし人間にも把握しやすい。
0020デフォルトの名無しさん
NGNG∧＿∧ ／￣￣￣￣￣￣￣￣￣
（ ＾∀＾）＜ あほか
（ つ ⊂ ） ＼＿＿＿＿＿＿＿＿＿
.） ） ）
（_＿）＿） （＾∀＾）ｹﾞﾗｹﾞﾗ ｷｴﾛ ｶｲｾﾝｷｯﾃｸﾋﾞﾓｷﾚ ｹﾗ
0021デフォルトの名無しさん
NGNG継承は知ってるけど。
0022デフォルトの名無しさん
NGNG> OOPって結局は、今まで巨大な1つのアプリだったものを
> 分割して小アプリ(の組み合わせ)にしようっていうものだから、
そうだったのですか？
0023デフォルトの名無しさん
NGNGそう思ったときは0.00001秒でGoogleにアクセスして
「集約 継承」で検索かけるのが検索の達人。
0024デフォルトの名無しさん
NGNG0025デフォルトの名無しさん
NGNG煽りAAのトレンド？
0027デフォルトの名無しさん
NGNGデザインパターンを勉強しよう。
0028デフォルトの名無しさん
NGNG0029デフォルトの名無しさん
NGNGモデリング言語としても固すぎなんだよ、UML。
Rubyなプログラムを描くとき相当苦労してるそうぢゃないか。
0030デフォルトの名無しさん
NGNGinheritanceも重要だと思うのだが･･･。
0031デフォルトの名無しさん
NGNGhttp://piza.2ch.net/test/read.cgi?bbs=tech&key=980236172
個人的には、「UMLで設計して、それを元にコーディング」というのは効率よくないとおもう。
ソースコードをUMLで視覚化して、それを手がかりに現況を把握しながらコード書いたりリファクタしたりするのが良い。
0032デフォルトの名無しさん
NGNGそういうのを聞くとつい考えてしまうのが、
「絵の差分」という話題なんだが、
どれくらい世の中は進んでいるんでしょうか？
ソースは一応差分とれるわけだよね。
それに匹敵するUML差分を取り扱えてはじめて
SourceFirstは旨くいくんじゃないかと。
あ。もちろん、そうでなくても差分は熱烈に欲しいのだけど。
0033デフォルトの名無しさん
NGNGMOF XMI で検索してみよう。
0034デフォルトの名無しさん
NGNG作り直していけるようなシステムが良い。
そうでなければ、OOPって、不便だと思う。
「設計が悪い」で済まされてしまう場合、設計に時間がかかったり、経験を必要としたり、
設計段階でのミスが許されなかったりしてしまう。そういうのはちょっと･･･
0035デフォルトの名無しさん
NGNG0036デフォルトの名無しさん
NGNGそういう作業者のレベル(御免)でしか考えないのならば、
OOPでなくても破綻しやすかったりしないかな？
半分煽りにしか聞こえないコメントはさておき、
そういう場合にこそ「スパイラル開発」という
キーワードが役立つわけじゃん。
駄目出ししたら次の一周に突入すりゃいい。
0037デフォルトの名無しさん
NGNG勉強してみたいので評判の悪い本、地雷本は避けたいんですが…。
0038デフォルトの名無しさん
NGNGGoF(softbankのやつ)買えばいいじゃん。
0039デフォルトの名無しさん
NGNGしまった
つまりＯＯＰは一箇所でも間違うとトンデモになるということです。
0040デフォルトの名無しさん
NGNGソフトウェアの設計図をちゃんと書く手段って、UMLしかないでしょ。
UMLで表現したソフトウェアを、作るには、OOPやるでしょ。
建物を建てるときに、昔の大工がつかってた設計図と、今のビルの設計図
ってちがうでしょ。
いつまでも、大工仕事程度のソフトウェア開発つづけるつもり?
そりゃ、少人数で、棟梁の一存でやってりゃ変更もなんも容易だわな。
0041デフォルトの名無しさん
NGNG多態(嘘)により差分を吸収しちゃろう。
Object Oriented Programming System。
いや、ネタじゃなくて、昔から言われているぜ。
最近は嫌われちまったのか滅多に聞かなくなったが、
10年くらい前はそう呼ぶほうがむしろメジャーだったかな。
Systemってナニよ？っていうと、
やっぱりSmalltalkみたいなのを最終形態として
とらえた言い方なんだろうな。Language単体じゃなく
全体的にOOを適用しようっていう奴。
004234
NGNGスパイラル開発か。それは知らなかったから調べてみるよ。
>>40
ビルたてるのと、プログラム作るのは違うよ。
プログラムはどんどん改良されるものだし、試行錯誤しながら何度も細かい
ところを作り直して作っていくものだし、間違えずに前もって設計
するなんて、ほとんど不可能だと思うんだよ。
だって、ほとんどの場合、作り始める途中でいろいろとうまいやり方が
わかってくるものじゃない?
0043デフォルトの名無しさん
NGNGたまにすごく気持ち悪いと思う時があるよ。
subClassResponsibility
とか。
美しいともいえるけど、気持ち悪いとも言える。
そういうわけで最近は関数型言語をマスターしようかと頑張っています。
0044デフォルトの名無しさん
NGNGそのたとえは非常に間違っているのです。４００年前の建物が現存
するなか、４０年で利用できなくなる建築物があります。
状況に応じて必要なことを行うのと、最新技術こそ最高技術である
と考えるのは違いますよ。
将来的にはインタプリタ言語に収束すると思ってるし。１０００年後
かもしれんけど。
どうでもいい横槍なのでsage.
0045デフォルトの名無しさん
NGNG>いつまでも、大工仕事程度のソフトウェア開発つづけるつもり?
>そりゃ、少人数で、棟梁の一存でやってりゃ変更もなんも容易だわな。
きみ、そりゃ激しく認識不足だよ。
彼らのスケジューリング能力は目を見張るものがあるよ。
0046デフォルトの名無しさん
NGNGとにかく、オブジェクト指向は良い。やるべきだ。
でも、効率の高い構造化、または過去の技術もしっかり勉強しよう。
片方しかやってない奴は、実践で大して役に立たないンだよ。
時々、片方だけ出来て自慢げな奴がいるけど、
俺の手下だったらひっぱたくね。
両方知れば 40 のような事は口に出せない。
要求は「大工」であり「設計技師」であり「頭領」であり、その他沢山ある。
ひとつだけ出来れば良いわけじゃない。
0047デフォルトの名無しさん
NGNGなったので、試しに一本ツールを作ってみたのですが…。
関連を増やすことを恐れるあまり、部分部分を繋ぐ部分がどうしても
MediatorかObserverっぽくなっちゃいます。つまりものすごく多くの
クラスと関連を持つ頭でっかちな中心クラスが一つ出来てしまうんです。
部分の再利用性は抜群ですが、中心クラスはそりゃもーむごいもんです。
この、設計の最終段階を解説してくれてるような良書ってありますか？
GoF本の２章も仕上げの部分が省略されてていまいちでして。
0048デフォルトの名無しさん
NGNGＣ＋＋だと楽とも言えない。Javaは少し楽なくらいかな。
0049デフォルトの名無しさん
NGNGうまいこと進んでいる。
0050デフォルトの名無しさん
NGNGttp://member.nifty.ne.jp/masarl/
>>47
「中心」なんてものを出来るだけ無くすようにするのが吉。
芝居だって主人公が(あなたが言う意味の)「中心」である
わけじゃないでしょ？
注：OOPの古典的理論に「アクター(俳優?)理論」ってのが有るらしく。
つまり、
>MediatorかObserverっぽくなっちゃいます。つまりものすごく多く
この部分に「つまり」という単語が出るところが敗因。
もしかしてMediatorやObserverを中心に据えようと
していないっすか？
駄目っすよそのスタイルは。VB/Delを厨房がいじるのと
同じなんだから。(ナニも考えずにあの手のRADを使うと
Formに書く処理が爆発的に多くなる)
0051プログラマー暦１５年のヘタレ
NGNG近年オブジェクト指向が使えなくなってきていると感じます。
かつて使えたが、今まさに使えなくなりつつあると感じます。
なんじゃそりゃって話になると思われると思いますが。
最近オブジェクト指向を駆使してではなく、オブジェクトに襲われていると感じるわけです。
まず、代表格として
１．質の悪いライブラリを使わざるを得ない状況がある事がある。
２．ハードウエアやネットワークの立地条件等の都合で、変なオブジェクトの分割を要求されることがある。
等です。
元来オブジェクト指向が機能させる為には、オブジェクト間のメッセージとかリンクとかを最小限にする必要がある訳ですが。
そのためには、オブジェクトの分割の仕方を、それを書くプログラマが握っていなければなりません。
ところが、最近外部の都合でオブジェクトの分割が決まってくるわけです。
プログラマが今まで握っていた主導権は外部の都合に奪われた訳です。
結果オブジェクト間でグチャグチャなメッセージの飛ばし方や、変なリンク、エグイ物をいれたコンテナ等がわらわらと登場してきます。
こうなるとオブジェクト指向が機能するはずもなくなります。
オブジェクト試行の大様は身包み剥がされつつあるような気がする。
どう考えられます、みなさん。
初カキコでクソ長文すみません。
いま、変な言語作ってて、文法作成に行き詰まってるんです。(^^;
＃実は継承やコンストラクタ・デストラクタ、
＃C++については、キャストのオーバーロードにも
＃いや〜な感じになりつつあるなぁと思ってます。
＃それはまた後日機会があれば。
0052デフォルトの名無しさん
NGNG>「中心」なんてものを出来るだけ無くすようにするのが吉。
胸に響くね、この一文。
0053デフォルトの名無しさん
NGNGラッパーオブジェクトを書くってのが
定番/正義な解決策じゃないの？
それじゃ駄目ななにかがあるの？
>>52
よく知らないけど、階層モデルよりネットワークモデル、
ってことなんじゃないの？
ある瞬間にある点を中心にして物を見て、
別の瞬間にはまた違う点を中心だと見る。
0054デフォルトの名無しさん
NGNGできればラッパーなぞ書きたくないだろ。
というか、あれだけ話し合って結局ラッパー書いてる俺って何者？鬱だ．．．。
0055sage
NGNG誰かが後でメンテしようと思って覗いたときに、
元オブジェクトの把握->俺様ラッパーオブジェクトの把握の手間が増えるんで注意。
でも、やっぱ、どうしても見苦しい＆しょぼいのはwrapするしかないことあるよなあ。
0056デフォルトの名無しさん
NGNGキャストのオーバーロードは、MFCのCRectみたいな本当に小さい構造体のラッパーにしか使わないっす。僕は。
getterメソッド書いた方が、結局読みやすくなってしまう。
0057saga
NGNGでも、ラッパーすら書かないよりは、絶対に
事態をマシな方向へ導くと思うぜ。
ラッパー書かないと全員が似たようなアクセスコードを書く、
いわゆる「配管工事アンチパターン」に突入しちまう。
>>55
DOCUMENT書くとか、XPかぶれ的に言うならば全員にきちんと知らせるとか、かな？
えと。全員が「既に書かれたコードはだいたいどんなClassが有るか」を
把握してないとしょーがないんだよねたしかXPって？
そうでないと「全員がどのソースをいついじっても許可
(その代わりバージョン管理は厳格にな)」という状況には
なり得ないはずなんで。
0058プログラマー暦１５年のヘタレ
NGNGラッパーすると帰って最悪の事態を招くケースです。
自分はとあるモジュールをオブジェクトＡとオブジェクトＢに分割
する必要があるとする、それは別々のコンテナに入れたいからである。
ところが、初期化、破壊はオブジェクトＡとオブジェクトＢ共通なので
ある（元システムの都合ですね）
そうすると、このオブジェクトはモジュール全体で一つのオブジェクト
とした方が結果的に記述しやすい状態にもかかわらず、
自分の目的どおりの分割はそうなっていないのです。
最もラッパーしにくいタイプの物です。
こういうものについて皆さんはどうしてますか？
言語機構にこんなの有れば解決早いとかあったら、是非聞きたいです。
0059プログラマー暦１５年のヘタレ
NGNGこの問題ですが、簡単じゃないんです、そのライブラリ作ってる人にとっては
その分割が最適解であれば、全員正当なんです。
0060デフォルトの名無しさん
NGNG0061sage
NGNG初期化・破壊を仮想化して、継承した方のクラスで別個に処理する
べきだと思うが、
どんなにがんばって仕様を分析しても
両方同時に初期化・破壊しなければおかしくなる場合、
両方同時に初期化・破壊したほうが論理的にすっきりしている場合
は、そもそも、分割する必要はないオブジェクトだと思われる。
>>58-59 参照
006247
NGNG> MediatorやObserverを中心に据えようと していないっすか？
まさにその通りでした。一応振る舞いを状態分けしたstateパターンクラスを
中心のクラスに持たせてある程度責任を散らしてはいたのですが（でも適当です）
「どこかに処理の流れはまとめておきたい」という思いが私の場合
強すぎるようですここから飛躍するには相当の勇気がいるようです。
紹介いただいたページを熟読する所からはじめたいと思います。
的確な助言ありがとうございました。
0063デフォルトの名無しさん
NGNGオブジェクト指向を使うと、凄く楽になったという実感があるよ。
ただ工数が減ったかといわれると微妙。
速く作れるようになったと言うより、
確実性が増したと言うべきか。
例えば、「こりゃ複雑すぎてメンテできん、
手も足も出ない」っていう状況はほぼなくなりました。
ドキュメントが無い状態でも、クラスを見れば、
おおよその働きは理解できます。
危険な操作はできないように隠蔽できるので、
アクセスのエラーが出たら、
何かしてはいけないことをしたのだという目安になります。
もちろん、51さんのいうように、きちんとしたクラスライブラリ
であるという前提がありますが……。
下手なライブラリを使うと、スパゲティになるというのは同感です。
でもそれは、オブジェクト指向が悪いのではなく、
オブジェクト指向として成り立っていないのが悪いのだと思いますよ。
0064デフォルトの名無しさん
NGNG言語は、何と何を比較してるんですか？
0065デフォルトの名無しさん
NGNG63じゃないけど
CからC++に移ってからは、コードの品質が向上したと思うよ。
正確に言うと、品質の高い部品を流用しやすくなった。
コードを書いたり見直したりする時間も減ってるので、
仕様設計と品質検査に十分な時間がとれるのがいい感じ。
>>8のようなのは、きっと、勘違いしたC++プログラマのいる
職場の話だと思う。
そういうのがいると、別にC++じゃなくてもろくなことにならないでしょ？
0066デフォルトの名無しさん
NGNG同意。
C++が読みにくいって言ってるのは多分カプセル化されたソースが
あまり読めていないか、そもそもカプセル化されていないかのどっちか。
まえから思ってたけど、オブジェクト指向言語のソースはCのソースと
同じような感じで読んじゃダメだなと。そんな読み方するから、
カプセル化もされていないようなソースが出て来るんだと思う。
ちなみに他人のソース、読まない人は論外。
0067デフォルトの名無しさん
NGNGええと。まずお願いなんだが、モジュールとObjectを
並べて語らないでくれー。
モジュールとClassを並べるならばまだヨイんだが、
コンテナ云々の問題が出ているってことは
ClassじゃなくてObjectが問題になってるんだろうし。
ええとええと。元モジュールにClass Cがあって、
それをClass AとClass Bに分割したい、
あと Container < A > とContainer < B > もあるぞ、
という話ですよねそれ？
まぁそれはAとBの設計を頑張ってくれとしか
言い様がないなあ。
ところで、コンテナって言ってるけど、「参照の」コンテナですよね？
「実体の」コンテナ(これができる言語はメジャーな奴ではC++だけだが)
だと、色々問題がややこしくなるんでアレですね。
参照のコンテナなら、参照係数でも管理しとけば
そもそもAとBに分割する必要すらなくなるかも知れません。
検討に値すると思います。そちらの状況ではどうでしょうか？
>>62
OO的にすっきりしたシステムを作るための肝の1つとして、
「流れ」を出来るだけ作らない、ってのが有るように思う。
もちろんゼロには出来ないけど、出来るだけ減らす。
0068デフォルトの名無しさん
NGNG>正確に言うと、品質の高い部品を流用しやすくなった。
ＭＦＣなんか信用できないんですけど・・・
0069デフォルトの名無しさん
NGNGどの辺りが？
0070デフォルトの名無しさん
NGNG使ってない人には、分からないよ。
0071デフォルトの名無しさん
NGNGPGサイズで、6割
実行時間で、1割
増えるち
0072デフォルトの名無しさん
NGNGその分品質アップしたな。
実行速度とメモリ使用量は確かにあるが、それを気にしなければ
ならないほどの環境での作業はない。
ただ、ユーザーが理解できんと言ってくるのはうざい。
0073デフォルトの名無しさん
NGNG>C++になって理解しないやつはコーディングさせなくなったので、
>その分品質アップしたな。
これって、プログラミングが高度になって、その分、優秀な
プログラマーを雇っただけという意味なら、オブジェクト指向で
品質アップは、へ理屈だね。
0074プログラマー暦１５年のヘタレ
NGNGレス見落としてました、遅レスすみません。
キャストなんですが、やはりそうされますか？
私も現状ほとんどそうしてます。
このキャストというのはコピーコンストラクタとセットで、よく悪さします。
最近テンプレート関数も悪さしませんか？
結局 string クラスなどは c_str() などというメソッドを搭載しています。
テンプレート関数ははっきり分かる関数名にするべく長めにしてます。
しかしまあ、そんなメソッド名や長いテンプレート関数名は書くほうとしては、
面倒極まりない。
両立できないかと考えてみていたわけです。
そうこうしている内に問題点が見えてきたわけですが、要するに
オーバーロードやコピーコンストラクタはメンバ関数であるべきじゃ無いと考えました。
これは、int b を double a に代入するときに、自動的に
a = b を a = (double)b に、変換するわけですが、これは常識を使った省略形の書き方なんだと感じました。
コンピュータ言語には常識が無いから、全部１から１０まで全部指定する必要が出て来るわけです。
これを巧く解決した一つとして、ネームスペースがあると思ったのです。
これは、ここではこのライブラリを使うよという常識の指示であり、これはまあ、何とか成功していると思っています。
キャストもあるべき姿はメンバ関数ではなく、ネームスペースのような形だと考えています。
同じ要領で、ここらの問題も巧くいかないかなとか考えてます。
常識を使う場所で切り替えられると便利だと感じてます。
ところで、この種のコンセプトをやっている言語とか知りませんか？
もし有ったら一度見てみたいんですけど。
＃これはオブジェクト指向とは関係ないですね。
0075プログラマー暦１５年のヘタレ
NGNGすみません、余計な事書くと混乱起こすばかりですね。
問題点の要点だけを書きましょう。
要するに、最適なオブジェクトの分割は「使う側に対して相対的である」
と言いたいのです。
これが最適という分割方法はなく、まれにどこかで最適な分割方法は、
どこかで最悪の分割方法になっている事があるという事なんです。
質の悪いライブラリは、まあ作り直せばよいではないかという話でおそらく
全員一致すると思うのですが、質の良いライブラリーでそれが起こり始めると
かなり悩ましい問題になってきます。
１０年近くＣ＋＋のライブラリを作りつづけて、ライブラリが巨大化するにつれ、
自分で使う自分専用ライブラリでも起こり始めていて
ちょっと考えないといけないなと思っている訳です。
ちなみに私の方は、まずそのオブジェクトは単体で生成しておいて
それをアクセスするオブジェクトを使っています。
mondai_class m ; // 問題のクラス
// 内部メンバ変数は最小限の c をアクセスするクラス
class_a
{
mondai_class * m ; // ポインタで問題クラスを参照している
class_a( mondai_class & m ) ;
}
// 内部メンバ変数は最小限の c をアクセスするクラス
class_b
{
class_a 同様
}
// 問題オブジェクトの管理クラス
// c の生成、消滅の管理をする。
class kanri
{
mondai_class c ;
class_a object_a ;
class_b object_b ;
...
} ;
// 使うところ
container< class_a > container_class_a hoge1 ;
container< class_b > container_class_a hoge2 ;
このような事態が起こるのは、ヘボライブラリだけではなく、Ｉ／Ｏ絡み
の処理ではハードウエアの制約から避けて通れなくなることが多々あります。
作っていて、なんのなめにオブジェクト指向してるのか分からなくなってくる瞬間です。
ラッパーの自動生成機構とか考えてるんですけど、エレガントな
解法じゃないなぁと思いつつ・・・悩んでます。
0076プログラマー暦１５年のヘタレ
NGNGうーん、説明自分でみてても訳わかんないな(^^;
要するに、ライブラリ側のオブジェクトに
大して管理用オブジェクトを作って、これで管理する。
それを参照する事により、オブジェクトを二つに分割しています。
この管理オブジェクトがバグの巣窟、クセモノになりやすい。
0077デフォルトの名無しさん
NGNG何を問題にしているのか、やっぱり良くわからないわ。
ここで提供されている情報だけからすると、やっぱりclass_a,class_bは分割する必要がないように
思えるの。でも75氏は分割しなくてはならないと思っているのよね？その根拠を示していただけない
かしら。
もう少し具体的に問題を書いていただかないと、議論になりにくい気がするわ。ご一考ください。
0078：プログラマー暦１５年のヘタレ
NGNGうーん具体例ですか、
例えば抽象アルゴリズムにかけるときに絶対に必要になります。
テンプレート関数でソートしたい場合等を考えてみてください。
class_a class_b で、それぞれ別の基準でソートしたい場合にそれが必要になります。
しかしながら、それは本質ではありません。
分割が必要かどうかは、「使う側の人が決定すること」であって、「ライブラリの設計者ではない」のです、ここに注意してください。
ライブラリはあくまで一般化を目的にしますから、特定用途にはしにくいのです。
しかし使う側は特化する必要があるわけです。
＃こういう指摘は助かります、この問題自分でもどう説明してよいか中々悩むので・・・
0079プログラマー暦１５年のヘタレ
NGNGこのラッパーがまたバグの元になるのです。
＃ラッパーした時点ですでに設計として敗北という気はしますが・・・(^^;
0080ミトコンドリ子
NGNG>>75 でのmondai_classはライブラリ側、class_a,class_b,kanriはクライアント側のコードで、
mondai_class側のパッケージと、class_a側のパッケージでは使いやすいオブジェクトの粒度が異なる、
という設定でよろしいかしら？
おっしゃるとおり、どんなクライアントにも最適なオブジェクトの粒度を提供するのは困難だと思うわ。
そうなると、ライブラリ提供側でいくつかの粒度のクラス群を公開するのが良い解決なんじゃない
かしら。
例示しているように、ライブラリ側の粒度を荒くクライアント側を細かくするより、ライブラリ側を
細かくするほうが設計上無理が生じにくいと思うからよ。
たとえばGoFのFacadeパターンなんかでは解決できないのかしら。
蛇足ながら説明すると、mondai_classの機能を構成するサブクラス群もクライアント側に公開して、
クライアント側はmondai_classを使うのでも、サブクラス群を使うのでも、どっちでも選べるように
するパターンね。
それから抽象アルゴリズムに通す必要があることはクラスを分解する理由にはなりにくいと思うわ。
ソーティングの例ならmondai_classを引数にとる比較オブジェクトを導入するだけで解決するんじゃ
ないかしら？まぁこれも一種のラッパーという見方もできなくはないと思うけど。
0081sage
NGNG65なんだけど、MBCS版の
CString::Remove(TCHAR)
バグってるよね。うん。
でもこういうときとっととUnicodeの世界にいけるのは
C++のありがたさかも。
MFCのバグだったら、自分でなおしなよ。
008263
NGNGFactoryMethod、Bridge、Proxyといったパターンで綺麗に解決できそうですよね。
つーか、FactoryMethodなんか、モロにそれを解決する手段なのではないでしょうか。
デザインパターンは全てを解決する万能薬ではありませんが、
デザインパターンを知っていればこのような問題は起こらないのではないかと思います。
車輪の再発明で悩むのはやめたほうがいいですよ。
0083デフォルトの名無しさん
NGNG25歳以下ならひーこらやるべし。
0084デフォルトの名無しさん
NGNG>ソーティングの例ならmondai_classを引数にとる比較オブジェクトを導入するだけで解決
なんだっけ?
Commandパターンだっけ?Visitorパターンだっけ?
Strategyパターンはどうかな?関係ないか…
色々入ってるよね、あの道具箱には。
とりあえずなにが入っているか一通り見ておくと
大工として幸せになれるかもね。
あるいはクッキー型が色々入った箱かも知れない。
0085デフォルトの名無しさん
NGNGＭＦＣを解析して直すより、必要なクラスだけ自分で作ったほうが
早いことが多い。
これって、オブジェクト指向の部品の流用に逆行してる？
0086デフォルトの名無しさん
NGNG所詮は日本のアホ掲示板などこの程度か。
ちょっとがっかりだな。
0087デフォルトの名無しさん
NGNG無料で読める掲示板に期待して、がっかりするほうがアホ。
0088プログラマー暦１５年のヘタレ
NGNG> mondai_class側のパッケージと、class_a側のパッケージでは使いやすいオブジェクトの粒度が異なる、
> という設定でよろしいかしら？
ちょっと違います、私は粒度を「自分からは設定できない」という想定をしています。
メチャメチャの粒度のオブジェクトが、すでに存在していると仮定しています。
そして、巨大アプリ・特殊ハード・古い巨大なライブラリ等で、
それが現実になりつつあると感じています。
焦点は、このすでにゲロ吐きそうなそれを、いかにして効率的に結びつけてアプリケーション化するかです。
諦めるか、ラッパーするか、選択肢はそれ以外ないとしています。
また、ラッパー作成が３割を超えるようなものは、私とししては美しくない方法であると考えています。
0089プログラマー暦１５年のヘタレ
NGNGなんか攻撃的ですね、別に私はオブジェクト指向を否定している訳ではないですよ。
現在でもメソッド記述するのに構造化プログラミングは使うでしょう。
ただ、例えばＣで仮想テーブル作るのが効率がいいと思いますかと問うてみたいわけです。
0090デフォルトの名無しさん
NGNG馬鹿ばっかり。
0091デフォルトの名無しさん
NGNG0092デフォルトの名無しさん
NGNG0093プログラマー暦１５年のヘタレ
NGNGいますよ、知り合いに。
やって出来ないことはないって感じです、執念です。
malloc が使えない都合です。
0094デフォルトの名無しさん
NGNG0095デフォルトの名無しさん
NGNGやだねったら、やだね。
もしかして構造体の中にメソッドを入れるんですか？
0096デフォルトの名無しさん
NGNG0097デフォルトの名無しさん
NGNGたしかにCだけでOOPできれば、真にOOを理解していると言えるな。
ある意味実装系を自作する事になると思うが。
0098デフォルトの名無しさん
NGNG昔してました。が、今やるとしてもまじめにやらないと思います。
(疲れるだけなんで。)
それなりの成果はありましたが。
>>95
多態表現を行なう場合、関数テーブルへのポインタはインスタンス
毎に必要だと思います。関数テーブル自体はstaticに置くとか。
普段は
result_t class_method(obj_t this, param_t param);
の形式でいいかと。
0099デフォルトの名無しさん
NGNG十年前には、Ｃでやってた。ＣＯＢＯＬもあったよ。
0100デフォルトの名無しさん
NGNG0101ミトコンドリ子
NGNG>>88
ええと、88氏はもうすでに納得されているかもしれないことでも、初見のアタシ(たち)はまだ納得して
いないこともあると思うのね。
アナタがなぜその結論に達したのかを示してくださらないと、一方的な意見の言い合いになって議論に
ならないと思います。
抽象的な課題は、構築しようとしているアプリケーションとは異なる粒度で構成された既存ライブラリ
をいかに効率的に結びつけてアプリケーションを構築するべきか、なのね？
ただ、こういう場で抽象的な話をすると一方的な言い合いの傾向が強まると思うので、アタシはなるべく
具体的な話をしたいと思うのだけどいかがかしら？同意いただけなければ、以降はつきあって頂か
なくても結構よ。
で、その一例が75に示されていて、mondai_classはライブラリ側、class_a,class_b,kanriは構築しようと
しているアプリ側のコードで、 mondai_class側のパッケージと、class_a側のパッケージでは使い
やすいオブジェクトの粒度が異なり、ライブラリ側の変更の権限は与えられていない、でいいのよね。
ライブラリ側の変更権限がなければ、アプリケーション側の構造をライブラリに合わせて決めるか、
ラップするくらいしか思いつかないわね。ただ「選択肢はそれ以外ない」と言い切れるほどの確証は
アタシにはないわ。
88氏がこの確証を得た経緯を教えていただけないかしら。
とはいえ他の選択肢はすぐには思いつかないので、ラップするとして話を進めるわ。
ラップするとしたときの設計上の提案がすでにいくつかあるわよね。
>>82氏が指摘しているとおり、FactoryMethod,Bridge,Proxyパターンが有効だとアタシも思うし、
アタシなら75の設定にはProxy,参照数計測,FactoryMethod で抽象層を構築しようとするわ。
>>76で「管理オブジェクトがバグの巣窟」>>79で「ラッパーがバグの元」とおっしゃっているけど、
88氏は設計または実装上でどんな困難があると感じているのかしら？
初期化、破壊に問題があるのだとしたら、その問題をもう少し具体的に示してください。さらに
FactoryMethod,Bridgeなどの手法をなぜうまく適用できないと考えるのかを教えていただければ
と思います。
ライブラリ側の変更権限がある場合に対する意見は、>>80に書いたとおりです。
おもしろい話題になるかもしれないと思うので、ちょっと細かくつっこんでみたわ。
わかってらっしゃると思うけど、建設的な議論をしたいだけで攻撃の意図はないわよ。長文失礼。
0102デフォルトの名無しさん
NGNG粘着なオカマってもてないと思いますよ。
0103プログラマー暦１５年のヘタレ
NGNG長文返しみたいになってすみません。
>抽象的な課題は、構築しようとしているアプリケーションとは異なる
>粒度で構成された既存ライブラリ
>をいかに効率的に結びつけてアプリケーションを構築するべきか、なのね？
>やすいオブジェクトの粒度が異なり、ライブラリ側の変更の
>権限は与えられていない、でいいのよね。
それでよろしいかと思います、あとまともにOOPしていないライブラリの
事も考えていただければ結構です。
オブジェクトの中に無意味なものが入っているのです。
>ただ「選択肢はそれ以外ない」と言い切れるほどの確証は アタシにはないわ。
随分厳密ですね、数学科出身の方ですか？（笑）
論理的に言えば、存在するかしないかは不明てす。すみません、嘘です。
>ラッパーがバグの元
コードがあればバグが存在する可能性が存在します。
ラッパーはプログラムコードです。
ゆえに、ラッパーにはバグが存在する可能性が存在します。
（あたりまえ）
実装上・設計上の困難とは、
１．設計の困難
２．デバッグの困難
３．人材難
その他もろもろと考えています。
したがって、バグが増えれば、設計または実装上でどんな困難と結論します。
巨大ライブラリでは、全体像がだんだん見えにくくなってきます。
ラッパーにラッパーを重ねてゆくと、少なくとも直列に並べれば
バグの確率は増す事があります。
>なぜうまく適用できないと考えるのかを教えていただければ と思います。
適用できないとはいっておりません。
そこでコードを書くことが問題といっております。
言語を作ろうとしてますので、それでどう省略してどう自動生成するかを
のヒントを得るべくここにきております。
ぶっちゃけた話、私がここにきている目的は >>51 の最後の
>いま、変な言語作ってて、文法作成に行き詰まってるんです。(^^;
なんです。
＃ちなみに私は偏差値３０の高卒ドキュソです、
＃高校で九九と分数の割り算やってるようなところです、お手柔らかに。(^^;
＃尚、デザインパターンは全く知りません、
＃もしよければ、細かい定義は教えてもらえると有り難いです。
＃オブジェクト指向論法OMTで初めて知ったとき、
＃綺麗なフログラムとはすなわち対象性ですとかかれていたのに対して、
＃確かにそれが全てだと思ってますとか思ってます。
＃（おっと厳密じゃないってゆう突っ込み厳禁ね）
＃不明な点があればまたよろしくお願いします。
＃明日があるので今日はもう寝ます。
0104ミトコンドリ子
NGNGご丁寧にどうもありがとう。
経験の少ないオカマが業界の先輩に向かって言うことじゃないけど、独自の言語を開発する
まえにもう少し知るべきことがあるように思うわ。
>コードがあればバグが存在する可能性が存在します。
おっしゃることは全くそのとおりなんだけど、必要な機能を実現するための方法がコーディング
しかないなら、バグを避けつつコーディングするしかないわよね。
新しい言語も、ものすごくおおざっぱに言えばコードの自動切り張りなんだから、一種の
コーディングよね。手動で良いコードが書けなければ、良い言語も設計できないと思うの。
より少ないコードでいかに堅牢で保守性が高く実行効率の良いコードを書くかが、設計,実装の
問題だと思っているわ。
そしてそのノウハウ集のひとつが何度か話題に出ている「デザインパターン」よ。
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/249-1980825-4075511
ぜひ通読されることをお勧めするわ。
世界中の少なくともアタシよりはるかに頭のイイ人たちが長い時間をかけて似た問題を考えて
達した結論よりも良いものを、自分の考えといくつかの掲示板での議論で得られるとはアタシには
思えないのよ。
わかってらっしゃると思うけど、103氏個人に限らずアタシも含め一般に言えることよね。
正論は言うのはカンタンだけど実践は難しいわー。アタシも先輩の仕事ぶりや雑誌を見るたびに
勉強不足を痛感するもの。
お互い、満足できる良い仕事ができるといいわね。ごきげんよう。
0105デフォルトの名無しさん
NGNG誰か要約お願いします
0106デフォルトの名無しさん
NGNG0107デフォルトの名無しさん
NGNG0108デフォルトの名無しさん
NGNG>随分厳密ですね、数学科出身の方ですか？（笑）
ん？プログラマなら(数学科じゃなくても)それくらい出来ないと鬱だぞ？
>いま、変な言語作ってて、文法作成に行き詰まってるんです。(^^;
…思うんだが、言語作る「のが」目的だというなら、
いっそその既存くずライブラリを全部捨てるってのは、どうだろ？
どうせ役立たない(つまりメリットよりデメリットのほうが大きい)
と思われるんでしょ？
言語作るのは案外簡単だよ。処理効率まで高いものを作ろうともくろむなら
大変な仕事になるけど、そうでなくて自分が意図した文法の言語が一応動けばいい、
という要求レベルならば、足回りから淡々と作れば結構できるもんだよ。
俺もこないだ初めてやってみたが、俺程度でも1ヶ月くらいで出来たのは驚きだった。
ただし！
計算機言語ってやつぁ、その言語に「自己矛盾」があるような
馬鹿文法を作ろうとすると、そんなのは絶対に「作れない」(藁
結局、大事なのは、きちんとした設計、だな。
0109デフォルトの名無しさん
NGNGはぁ？
0110プログラマー暦１５年のヘタレ
NGNG書籍の紹介ありがとう御座います。
オブジェクト指向開発論法いつの頃からか現実無視の屁理屈論法ばかりに
なってしまっていたので、すっかり見る気か失せていました。
それで、私が最後見たのはオブジェクト指向論法ＯＭＴが最後です。
近年のものは見ていませんでした、良いものであれば、是非そうさせていただきます。
>正論は言うのはカンタンだけど実践は難しいわー。アタシも先輩の仕事ぶりや雑誌を見るたびに
>勉強不足を痛感するもの。
>お互い、満足できる良い仕事ができるといいわね。ごきげんよう。
理屈と実戦は違います、これは私も痛感するところ。
お互い、満足できる良い仕事ができるといいですね。
＃ただ、ネカマはやめたほうがいいと思いますよ。(^^;
>>108
>俺もこないだ初めてやってみたが、俺程度でも1ヶ月くらいで出来たのは驚きだった。
すごいですね、私なんかもう４個も作ってるのに、たかがインタプリタに３ヶ月も未だに掛ります、羨ましい限りです。
0111デフォルトの名無しさん
NGNG0112ミトコンドリ子
NGNGそれから世の中には生物学的な性別と精神的な性別が一致しない人間も多く
いることを忘れないでね。
アタシにとっては日常生活でオトココトバ話しているほうが不自然で
つかれるのよ。
0113デフォルトの名無しさん
NGNG0114デフォルトの名無しさん
NGNGでもよー、デザインパターンって覚える優先順位って意外と低くならない？
言語のルールとか、そのあたりを知らないと絶対に仕事できないけど、デザインパターンは知らなくても何とかなるし。
頑張って覚えて欲しいんだけど、なかなか・・・
0115デフォルトの名無しさん
NGNG一緒にﾊｧﾊｧしようぜ！
0116デフォルトの名無しさん
NGNG覚えるってーかさ、
あーいうものは、言語の文法とかもまぁ同じだけど、
「名前だけ知ってる」のが結構重要だったりしない？
で、そういやあんなものもあるらしいよな、と記憶の片隅にあるんで、
いざとなったら教科書を参照してめでためしめでたし、って奴。
デザパタについては、いわゆるGoFのオーソドックスな奴は
ttp://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/patternIndex.html
とかでも見て名前一通り記憶にひっかけとく、くらいで
まぁいいかもな。最悪ケースとしては。
>知らなくても何とかなる
ただし腐敗しやすいコードになるぞ。
XPやってるとかなら話は別らしいが、それでも
パターンで謳われてる奴がまさに必要に迫られたときに
なおパターン(と実質同じもの)を書かないってのは、
すすんで劣等コードを書いていることになるわけだから。
0117デフォルトの名無しさん
NGNGデザインパターン知らなければ一生「それなり」からは抜け出せないだろうね。
凡人には今あるようなデザインパターンを自力で作り出すことは不可能ですから。
0118デフォルトの名無しさん
NGNGそーなんだよー。なまじ動くものが出来てしまうだけに、デザインパターン？ナニソレ？
んなもん勉強してる時間があったらコード書けよ、という人さえ周りにいる始末。車輪の大生産してますわ。
0119デフォルトの名無しさん
NGNG自分はへたれなんで、デザパタの本とか読んでもかなり抽象的で
実際にどうやって利用していけばよいのかよく分かりません。
なんか具体的かつ実用的な実装方法をサンプルに学習できるような
良い本などはないでしょうか。
一応、↓は読んでみたのですが…
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/ref=pd_sbs__1/249-3162162-8944327
0120デフォルトの名無しさん
NGNG結城氏の「Java言語によるデザインパターン入門」はわかりやすいのでお勧め。
0121デフォルトの名無しさん
NGNGの２冊がお勧め
中川氏の本は使わないばあいの無策なコードと
つかったあとのよい設計が対比されていてよい
0122デフォルトの名無しさん
NGNGサンプルいっぱいついてくるし。。。
0123デフォルトの名無しさん
NGNG>自分はへたれなんで、デザパタの本とか読んでもかなり抽象的で
>なんか具体的かつ実用的な実装方法をサンプルに学習できるような
ちなみにクヌース大先生によれば、プログラマに必要な資質とは、
抽象的な話と具体的な話を自在に行き来(翻訳とも言う？)する能力
なのだそうだ。
具体的実用的なところに拘ることでしか思考できない
という人は、必死になって抽象思考をも鍛えとくのがお勧め。
そしてもちろん、ばらばらに理解してもしょーがないんで、
両者の”繋がり”をすばやく理解する能力もな。
自分の今までの経験の中で「ああそういやデザパタのこれって
俺がやったあれと似てるよな」とか言う風に繋げて考える
ことが出来ればしめたもの。というか、そういう感じに、
「具体例」はどっちかってーとキミ(誰でも)の心の中
に有ったりするのな。多少なりとも「プログラムの経験」が
有る人間なら、「あぁ有る有る」って感じで色々思い当たると思われ。
0124デフォルトの名無しさん
NGNGGoFで十分。抽象的なことでも何度か読めば分かるって。>>119
おれは通して5，6回ぐらいよんでやっと分かった｡｡｡へたれだなぁｗ
0125デフォルトの名無しさん
NGNGGoF のパターンしか知らないのもどうかと思うよ。
#話題になってるのは入門書の話なのはわかってる。
#だたの煽りです。
0126デフォルトの名無しさん
NGNG> GoF のパターンしか知らないのもどうかと思うよ。
マイナーなパターンでは会話が成立しないのでは？
0127デフォルトの名無しさん
NGNG俺パターンを作ったから使ってみれとか言われるのはちと困るけど。
012840
NGNG大工仕事->小規模で、１人の頭に全体像が入り切る程度の仕事
ビル->１人じゃ設計すらできない大規模な仕事
で、オブジェクト指向ってのは、大規模なモノを考えられる程度の規模に分割できるところに最大の価値があると思うのです。
オブジェクト指向が使えないってのは、１人から数人月程度の作業規模に適用しようとした場合のことのような気がします。
別の例だと、電子回路の設計図との対比ってのがあって、
従来手法の設計-> 実体図
回路図-> UML
IC -> ライブラリ
電子回路には、いろんなデザインパターンがあります。SEPPとかSRPPとか名前もついてる。
0129デフォルトの名無しさん
NGNG>マイナーなパターンでは会話が成立しないのでは？
まぁ、パターンってのは、新しいのを考えるPhaseと
既知な奴を皆に知らしめる(布教?)Phaseの
両方が有るから…。
名前空間と考えるとすっきりするかもだな。
「GoFの」という名前空間に、例の数十個のパターンは
入っているわけだ。
んでimport GoFとか予め宣言すると(というか現代のデフォはたぶんこれ)
会話はすっきりすると思われ。
って、日本語の中でimportなんてつぶやくなよ(藁
>>128
>オブジェクト指向が使えないってのは、１人から数人月程度の作業規模に適用しよ
>うとした場合のことのような気がします。
うーん。3人日(笑)くらいでも十分OOPは役立つと(俺は)思う。
日曜大工でもプロ仕事でも、たとえば
「簡単なもの」だからってネジ一本を自作したりはしないわけで、
そういう感じでは？
まぁ、案件の工数と、案件の「OOPが似合う」度とは
必ずしも一致しない、とは思うけど。
一直線疾走型(?)の処理なら喩え長くてもOOPの出番少ないかもだし。
＃でもあんまりやってると付き合いきれなくなるがな。1000行以上の関数なんて鬱。
0130デフォルトの名無しさん
NGNG結局のところどれも主流になりきれてないというか、
絵に描いた餅な気がします。
なにかお気に入りとよさげなのありますか？
http://www.joopmag.com/html/from_pages/article.asp?id=3666&mon=6&yr=2001
0131デフォルトの名無しさん
NGNG増えそうな気がする．．．．
0132デフォルトの名無しさん
NGNG0133プログラマー暦１５年のヘタレ
NGNGもし、知らなかったら、見ておくことをお勧めします。
特に共通語を持つことができるというのは大きいと感じます。
>>132
現実の開発でコーディングが始まる前に、設計が完了なんて事はありえませんよ。
自分ひとりだけで開発しているならともかく・・・
とりあえず、煽るのはやめたほうがいい。
0134デフォルトの名無しさん
NGNGいっそXPはどうよ？
OOPの方法論を、取り入れているようないないような、
微妙に距離おいた感じで、やってる。
真心の現場主義な人(藁)には特に受けがよいようだ。
ま、プログラムっていう分野は、理屈ゼロな
肉体派(?)な奴も、それはそれで痛いわけだが。
>>133
>完了なんて事はありえません
全くです。ヨイ意味(どんどん進歩してく)でも
悪い意味(収拾つける能力無いんじゃねーの?)でも
「終わらない」ですよね。
建築とかとの対比で最大の相違点となるのが
この「終わらない、いつまでもだらだら開発が続く」
という性質らしい。建築だったら終わらないなんてのは
一部の宗教建築(ぉ)でないと許されないもんな。
verXXXの建物なんて有ったら詩ぬっす。
まぁ、有形物とそうでないものの本質的差だわな。
無形物が相手だと人間が改良の欲望を抑える理由がなくなるから。
だからこそ我々(もとい偉大な人々)は、
終わらなくてもどうにか破綻せずにすむ方法を
探そうと必死になってるわけで。
0135デフォルトの名無しさん
NGNGXPいいですね。
SmallTalkerたちが主張してるだけにOOPとの相性もよさげですし。
コーディングよりもうちょっと上の段階、
クラスを切り出すあたりのノウハウでよいのがないかなーと思ってます。
http://www.joopmag.com/html/from_pages/article.asp?id=3666&mon=6&yr=2001
の手法だと、
ユースケース図→各ユースケースのアクティビティー図
アクティビティ図の各ファンクション（？）で必要な・使用する属性を記述
上記で抜き出した属性たちをツリー化
ツリー構造をもとにクラス図作成
って感じです
いままでユースケースからクラスを抽出する方法がもやもやっとしてたので、
なかなかよさげなきがします。
ちょっと亜流かなってきがしないかもしれませんが。
0136デフォルトの名無しさん
NGNGユースケース図って、クラス図とかの
「ある面」なのだよねえ？
クラス図が全身像だとすると、個々のユースケースは
盲人の象撫でのノリでいうところの一人の盲人が
「象は長い(鼻か牙を触ったらしい)」とか言うのと
似たようなものなのかなと。
0137１３２
NGNG0138デフォルトの名無しさん
NGNGUMLとかそういう設計に関わる技術は、発注受けて、設計して、実装して・・・みたいな作業を複数人で行う場面で有効なものであって、
一人でフリー/シェアウェア作るんならあまり恩恵を受けないと思う。
といいますか、そういう身の上で
＞設計が完了したあとのコーディングほど楽なものは無い。設計しないでやる奴はアホ。氏んだほうがＥ。
とか書くのはほんのちょっと恥ずかしいかも知れないかも。知れなくないかも。
0139１３２
NGNG0140デフォルトの名無しさん
NGNG普通に仕事で開発しているといろいろな面が、ケタ違いに困難になるのさ。
で、小規模な例しか経験がないのに、引用されたような発言をするのは「恥ずかしい」
んじゃないの？って指摘だよ。
小学生が「オレもうどんなオンナでも落とせるゼ！クラスの女子はみんなオレの
ガールフレンドさ！」とか言っているような感じ。
傲慢さと謙虚さのバランスを身につけてちょうだいな。
0141デフォルトの名無しさん
NGNG人によって受ける恩赦は違うのさ。
139が設計したと言ってる内容を、頭の中だけできれいに整理
できる人もいる。
もともとツールってーのは人間が楽する為に作られている、ツ
ール使っても楽じゃないなら使わないだけ。
やはり一般的には大規模(30k以上)で多人数のプロジェクトで
効果が出ると言われているようだ。
0142趣味プログラマ
NGNGひとつ職業プログラマの心得をこちらで語っていただけませんか？興味あるので
http://piza.2ch.net/test/read.cgi?bbs=tech&key=981331412
0143１３２
NGNGラジャ。精進します。
0144デフォルトの名無しさん
NGNGユースケース図にはすべてのユースケースが書いてあるので、
低い粒度で、クラス図全体と同じものが表現されているのではないかと。
そして、すべてのユースケース詳細をあわせたものとクラス図はおなじものの
違う表現でないかと。(クラス図のほうが小さければ実装漏れ、ユースケース
詳細のほうが小さければ仕様漏れか「真田さんパターン」かのどちらか)
0145デフォルトの名無しさん
NGNG0146デフォルトの名無しさん
NGNGユースケースは全部網羅することに意味があるけど、クラス図は
ごていねいに全部書かなくてもいいんじゃない？
入り組んだクラス関係だけクラス図にしたほうがいいと思うけど。
0147デフォルトの名無しさん
NGNG盲人がどっかを触ったらしい。
0148144
NGNG＞クラス図は ごていねいに全部書かなくてもいいんじゃない？
＞入り組んだクラス関係だけクラス図にしたほうがいいと思うけど。
そうか。漏れは何やかやで静的概念図を全部書く羽目になったから、
最初から全部書くということを心に決めたのだが…
ていうか、アクティビティ図にあって静的概念図に無い物があるって、
気持ち悪くない？
0149デフォルトの名無しさん
NGNGぜんぶをいっぺん(1枚の図)に描くってことは、
ないんじゃないか？
つまり、「最初から」全部書くことはなく、
時間や場所を分けるほうが楽。
俺はそれを一人時間差攻撃と呼んでいる(ぷ
分割統治だよ。大局的に見たらどうでも良いクラスなら
大局な図には登場せず、局所的図に登場すれば良い。
そういう意味でのZoomIn/Outをサポートしてる
図(今だとUML)ツールはぜひ欲しいね。
今どうでもいいと思っているClassはHideしておけるような。
ZoomOutすると、どうでもいいClassは「小さすぎて見えなく」なるわけね。
ついでにShow/Hideをグループ化(そしてグループに名前をつける)機能は欲しい。
そうすりゃ分割したときに「同じようなクラスを複数の図に再び描く」
という無駄(と管理漏れの危険)を排除できる。
■ このスレッドは過去ログ倉庫に格納されています