共通化の線引がむずかしい
■ このスレッドは過去ログ倉庫に格納されています
0001大根
2006/02/21(火) 23:58:00共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。
処理Ａ、処理Ｂ、処理Ｃがあったとして、この３つは横展開の関係にあります。
３つも実装するのは大変なので、全て共通化して実装した（methodX(A）を読んだら処理Ａを行うイメージ）。
だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。
後々思うことは、
最初から処理Ａ、処理Ｂ、処理Ｃは別々に実装すべきだった。
もちろん共通化すべき部分はあるので、下請け処理の共通部品は必要だが、
大元の処理そのものを共通化したのは失敗だった。
なんで、こんな失敗するんでしょう？
最初からＡ〜Ｃはほとんど同じ実装で済むと思っていたのが、
想定外のバグ、仕様漏れ、仕様変更等により、Ａ〜Ｃが乖離した結果、マカロニ化してしまうんですね。
けれど、「想定外」のことを想定して設計なんてできないんですよ。
皆様、設計時にどこまで共通化すべきかという基準ってありますか？
0002デフォルトの名無しさん
2006/02/22(水) 00:02:43目が痛い
偏頭痛もする
0003デフォルトの名無しさん
2006/02/22(水) 00:08:46そもそも似て非なるものを1つにまとめたらスパゲッティーになるのは当然。
>もちろん共通化すべき部分はあるので、下請け処理の共通部品は必要だが、
>大元の処理そのものを共通化したのは失敗だった。
答えはでてるじゃん。
同じ機能を共通化するのはいいけど、同じ流れで違う機能のものは共通化しちゃだめ。
スーパークラスかインターフェースを統一するのはいいけど、1本のプログラムで色んなことやっちゃだめ。
0004デフォルトの名無しさん
2006/02/22(水) 00:10:24構造化においてもダイヤモンド型の構造は危険。
0005デフォルトの名無しさん
2006/02/22(水) 00:10:36おっかあがいってたよ
0006デフォルトの名無しさん
2006/02/22(水) 01:00:44文脈切り替えが幅広く出来て
部品がきちんと整理されてればいいんですけどね〜
（私は部品に、機能まで入っちゃう）
>>4
それだ！
機能を呼び出している文脈が違ってたりするんですけどね。
0007デフォルトの名無しさん
2006/02/22(水) 01:06:58一言で済ますと、ロジックの共通性は継承を用いて記述してはならない。
ロジックの共通性を括り出す場合は委譲を用いて記述するのが定石。
0008デフォルトの名無しさん
2006/02/22(水) 02:32:30構造化言語使いなら、処理内の機能を更にサブルーチンに切り出し各処理ではサブルーチンの呼び出しの形にする
イメージはこんな感じだ
処理A: 処理A-1、共通処理-1、共通処理-2
処理B: 処理B-1、共通処理-1、処理B-2、共通処理-2
処理C: 処理C-1、共通処理-1、処理C-2
こんな事当たり前すぎてつまらん
クラス図とかの勉強するのは良いが、バッチ処理みたいなものはフローチャートや構造化PADなんかで設計した方が早い
0009デフォルトの名無しさん
2006/02/22(水) 07:51:34>If (処理Ａの時のみ）...のような記述が増え
この記述をした時点で負け。
0010デフォルトの名無しさん
2006/02/22(水) 10:05:02「制御結合」で検索しなさい
0011デフォルトの名無しさん
2006/02/22(水) 10:54:27お前、そのクラスの名前だけど
・○○マネージャ
・××エクゼキュータ
なんて感じで命名されてないですか？
もしそうなら、それは「不吉な匂い」のする設計だ。
設計時点で見直しなされ。
メソッドはメソッドとして扱え。関数とは区別しろ。
共通処理関数はstaticなutilクラスで処理しろ。
言い回しは違うが>>7と同じことを言ってるつもり。
0012デフォルトの名無しさん
2006/02/22(水) 11:04:21OO以前の、
1970年代後半位の頃のモジュラープログラミングの本を
読むことをお勧めします。
0013デフォルトの名無しさん
2006/02/22(水) 11:32:11そういうことだよ。
0014デフォルトの名無しさん
2006/02/22(水) 11:38:58共通化すると
自分勝手に変更できなくなって、しかも他人が使うという観点からも保守が必要になる、
という負の動機付けが多すぎる。
と言うわけで、同じような処理や他人のコードのコピペが蔓延しているのはどうしたものか。
0015デフォルトの名無しさん
2006/02/22(水) 11:44:33＞関数は、１画面に収まるように
宿題ならともかく、無理
１関数数千行、１ファイル数万行が数百ファイルなんてざら
0016デフォルトの名無しさん
2006/02/22(水) 11:47:09なぜ？単に厨PGが多いだけだろ。
いや、自分が書いたんじゃなくてそういうコードの保守をさせられてるのなら苦痛は察するが。
0017デフォルトの名無しさん
2006/02/22(水) 11:52:43xxxx
} else {
xxxx
}
スタイルなら可能だが、
if (xxxx)
{
xxxx
}
else
{
xxxx
}
スタイルでは無理。
0018デフォルトの名無しさん
2006/02/22(水) 11:55:15ホントに全部の関数を１画面内に収まるように書いてるの？尊敬する
最適化とかの都合で分けられなかったりインラインアセンブラとか
が入ってくるとあっちゅう間に膨れ上がるんだよあはははは
0019デフォルトの名無しさん
2006/02/22(水) 12:02:07ドライバとかそう言う世界？そういうのは知らん。俺はお気楽な業務アプリだから。
ちなみに、最適化の都合で関数が分けられないってのはどういう場合だ？
0020デフォルトの名無しさん
2006/02/22(水) 12:13:05それは読むのがウザイだけ。
0021デフォルトの名無しさん
2006/02/22(水) 12:16:55元の文章書いたのとは別人だが自分は関数やらメソッドやらは一画面に入るようにしてる、
まぁ縦に長い画面使ってることもあるけど。
メソッドの場合は長いコードになると意味のまとまりができてくるのでリファクタリング
することできれいになるし。（応答速度がマイクロ秒以内とかを気にしなければいけないリアルタイム組み込み系だと無理だけどさ）
0022デフォルトの名無しさん
2006/02/22(水) 12:36:40これが難しいというか、面倒なんだよ…。
0023デフォルトの名無しさん
2006/02/22(水) 12:55:41メソッド呼び出しのオーバーヘッドすら問題になる分野だろう。
Javaでは制御文の中身をプライベートメソッドへ追い出すから
目安としての1画面というのは多くのPGが持ってる感覚だな。
>>22
メソッドの粒度がクラス内で一定になる様に気をつければいい。
どっちかって言うと命名が下手な奴のコードのが読みにくいな。
まぁ、プライベートメソッドは影響範囲が限定的だから変更す
れば済む話だけど
0024デフォルトの名無しさん
2006/02/22(水) 13:07:09これ。
英語がからっきし駄目な奴って、自分が名前から正しく意味を読み取る習慣がないから、
自分も正しく意味を持った名前を付けるという事自体が理解できない。
こういうＰＧが相当居る以上、日本語プログラム言語って意味あると思う。
0025デフォルトの名無しさん
2006/02/22(水) 13:18:25日本語のブログラミング言語である必要は無いな。
0026デフォルトの名無しさん
2006/02/22(水) 13:38:44＞それなら日本語の識別子
つVC8
0027デフォルトの名無しさん
2006/02/22(水) 13:57:13＞それなら日本語の識別子
つJava
0028デフォルトの名無しさん
2006/02/22(水) 14:08:320029デフォルトの名無しさん
2006/02/22(水) 14:14:46とっくに日本語識別子なんてOKなのに、なんでみんな使わないんだろう。
プログラムが超解りやすくなると思うんだけど。
0030デフォルトの名無しさん
2006/02/22(水) 14:18:36実践UML - パターンによる統一プロセスガイド
http://www.amazon.co.jp/exec/obidos/ASIN/4894713861/
カップリングとコヒージョンをOOPに当て嵌めて合わせたものだから
構造化を勉強した人には何を今更って内容だろうが、構造化を知ら
ないOOP世代には必須。
0031デフォルトの名無しさん
2006/02/22(水) 14:30:02Java意外の言語版Spring Frameworkも出ているので
試してみてはいかが?
0032デフォルトの名無しさん
2006/02/22(水) 14:46:19＞構造化を知らないOOP世代
なんだそれ？ OOPったって記述の末端は構造化プログラムだろ
0033デフォルトの名無しさん
2006/02/22(水) 14:58:32構造化 = レガシー、オブジェクト指向 = モダンという認識の者を
指して、「構造化を知らないOOP世代」と評した。
OOP世代は構造化を知らないとは言っていない点に注意。
0034デフォルトの名無しさん
2006/02/22(水) 15:37:46その時代を知らないの意で使った訳ね？
0035デフォルトの名無しさん
2006/02/22(水) 16:12:481ではないが耳に痛い
ついさっき同じ過ちをして今書き直してる
やっぱシンプルが一番だわ
0036デフォルトの名無しさん
2006/02/22(水) 16:23:02「『構造化を知らないOOP世代』とは言ったが
『OOP世代が構造化を知らない』とは言っていない」
こんなド屁理屈が本気で通ると思っている>>33にカンパイｗ
0037デフォルトの名無しさん
2006/02/22(水) 16:29:39//略
};
class B : public A {
//略
};
class C : public A {
//略
};
と派生すれば良いんじゃね？
0038デフォルトの名無しさん
2006/02/22(水) 17:08:51それだと、Aの一部の機能が、Bでは必要なくなった。
またはそこだけ処理が変更になったときに最悪。
↓がいいと思う。
class ABC {
//ABC共通処理
};
class A {
ABC kyotsu;
//略
};
class B {
ABC kyotsu;
//略
};
class C {
ABC kyotsu;
//略
};
0039デフォルトの名無しさん
2006/02/22(水) 17:38:37むしろそれはオブジェクト指向を知らない
構造化手法オンリー世代にうってつけだと思うが
と思ったがやっぱオブジェクト指向しらないと読みにくそうだから
彼らには難解だろう
0040デフォルトの名無しさん
2006/02/22(水) 17:44:51class BASE {
//略
};
class A : public BASE {
//略
};
class B : public BASE {
//略
};
class C : public BASE {
//略
};
0041デフォルトの名無しさん
2006/02/22(水) 17:54:09それらのやり方だけでどうにかなるケースは
ありうるがどれもこれもそれだけじゃ足りないケースもありうる。
不要になりそうな者が出てくる可能性がある場合は
Adapterパターンでもつかっておけばいいかと思われ。
いろんなデザインパターンを駆使して共通化を図る。
それから文字列リテラルなどは別ファイルにて共通化だ。
0042デフォルトの名無しさん
2006/02/22(水) 18:32:51ないというときは最初は流れも共通で行け。
ただし、惨事を起こす前にやばいと思ったら分離しろ。
この辺の見極めがセンスや経験だな。
ほとんど共通な流れを最初からたくさん持っていると
共通なものを増築する時にうざくなるし。
OOPはある程度部品のセレクトを手助けしてくれるけど、
手間の半分ってのがいいところじゃね？
0043デフォルトの名無しさん
2006/02/22(水) 19:19:00今までのソースを生かそうと苦労しても実りは少ない。
0044デフォルトの名無しさん
2006/02/22(水) 19:22:28>>1はフィギュアでも見てオナっとけ
0045デフォルトの名無しさん
2006/02/22(水) 19:34:29共通化をするためにstaticメソッドのみの共通クラスを作ることがあるのだが、
どんどん膨らんで、収拾がつかなくなりつつあるのだが、どうすればいい？
0046デフォルトの名無しさん
2006/02/22(水) 19:35:52命名が下手な奴が混じってる時点で日本語でもダメ
命名が下手な奴が訳解らん名前付ける位ならむしろ機能ID＋連番でプログラムを作ってもらっても構わない
どうせ、初期化()、初期化前処理()、初期化後処理()とか付けときながら前処理→メイン→後処理の順番で呼ばなかったり
後処理メソッド内に初期化メソッドの呼び出しが入ってきたりする
0047デフォルトの名無しさん
2006/02/22(水) 19:44:27何の為のネームスペースか！
それがカテゴライズに迷うロジックなら、それは
そもそも汎化する必要がないロジックなのだ。
0048デフォルトの名無しさん
2006/02/22(水) 19:50:431つに収めず複数のユーティリティクラスに分割する。この場合、機能単位ってのもありかも。
オブジェクト指向には合わないけど、Mathみたいな感じで。
でも基本的にはインスタンスと結びつかないメソッドが、どんどん増えるって状況が変だと思う。
0049デフォルトの名無しさん
2006/02/22(水) 19:54:48それに加えてだけど、日本語での名前は、大分類‐中分類‐小分類の順に字が並ぶから、
一見して何を表しているのかわかりづらいってのがある。
データベースの表名とか、そうなっちゃうこと多いよね。末尾の1字だけが違う別のものとか。
0050デフォルトの名無しさん
2006/02/22(水) 20:19:50まだ実装を意識すべきでない段階で実装図面を引いたからこうなっちゃったんでしょ。
0051デフォルトの名無しさん
2006/02/22(水) 20:23:400052デフォルトの名無しさん
2006/02/22(水) 20:26:160053デフォルトの名無しさん
2006/02/22(水) 20:27:58kwsk
0054デフォルトの名無しさん
2006/02/22(水) 21:01:33>だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。
本当に共通化されていれば、普通「処理Ａの時のみ」なんて
ベタな分岐がソースコードに埋め込まれるはずが無いんだが・・・
多分、共通化が全然足りてないんだろう。
試しに聞いてみるけど、その「共通」関数って一体「何行」あるの？
0055大根
2006/02/22(水) 21:13:22>ただし、惨事を起こす前にやばいと思ったら分離しろ。
>この辺の見極めがセンスや経験だな。
確かに。諦めて作り直すことも１つの勇気ですね。
分離せずにリリースまでいってしまうと、保守の時に修正時影響範囲に怯えないといけない。
ただし、分離作業＝作り直しであって、これ自体がちょっとした惨事です。
そうなる前に見極めるにはどうしたらいいですか？
0056デフォルトの名無しさん
2006/02/22(水) 21:28:11何か、>>1 の言葉の端々から、腐りきった大規模業務系の
臭いがプンプンするんだが・・・(w
0058デフォルトの名無しさん
2006/02/22(水) 21:35:07マ板逝ったほうが盛り上がりますよ。
0059デフォルトの名無しさん
2006/02/22(水) 21:38:260060デフォルトの名無しさん
2006/02/22(水) 22:26:45話をぶった切らせてもらうが、マカロニとスパゲッティは同じなのか問い詰めたい。
0061デフォルトの名無しさん
2006/02/22(水) 23:02:26> ・○○マネージャ
> ・××エクゼキュータ
> なんて感じで命名されてないですか？
やべー、結構こんな感じの命名あったりするんだが・・
何でもかんでもマネージャに任せないようにしてはいるんだけど。うーん
なんだかんだで、ＸＸManagerってつけちゃったりしないですか？？
0062デフォルトの名無しさん
2006/02/22(水) 23:24:42その共通化した部分にはどういう名前がついてるんだろう？行数よりもそっちの方が気になる
きちんとした名前がつけられてるならまず、その概念を定義したことが間違いであった
とはならないはずだ、作っていったらそんな概念が実際にはなかったことになったとはならないでしょ
for文くらい一般的すぎて取り上げるまでもなかったというなら話は別だけど
そもそも、当初きれいに共通化されていたものが、全体的な仕様がだんだん増していく中で
そうでなくなるというのは当たり前の話であって
そういった事実からその共通化の判断が誤りであったということにはならないのでは？
仕様が流動的に変化するなら、プログラムの全体的な構造も必要に応じて変動して然るべきだと思うが
0063デフォルトの名無しさん
2006/02/22(水) 23:40:330064デフォルトの名無しさん
2006/02/22(水) 23:40:59> ちょっとずれるかも知れないが、
> 共通化をするためにstaticメソッドのみの共通クラスを作ることがあるのだが、
> どんどん膨らんで、収拾がつかなくなりつつあるのだが、どうすればいい？
Facadeパターンを使え。
それからちゃんと分割統治くらい汁
それからちゃんとパッケージ分けはしてるよな。
そもそも、そういうstaticしかないメソッドのために共通クラスなんか作るなアホ。
おめえのソースコードキモイぞ氏ね。
そんなコードのメンテなんかしたくも引き継ぎたくもないわい。
デフォルトコンストラクタをprivateにしてクラスをちゃんとfinalにしておけ
0065デフォルトの名無しさん
2006/02/22(水) 23:46:10機能を追加するたびに
継承していくってことは
あどでどんな大惨事が待っているか
想像がつく。
引き継ぎ人が大変だ。
ってか以前>>37のようなコードを
引き継いでかなーりｳｻﾞｯって思ったことがある。
オブジェクト指向のことわかったつもりになって
やたらと継承しまくって分割統治もせずに
平気で継承するクラス＝バージョンアップされた差分クラス
と勘違いするところがウザイ。
だからクラス名は継承するたびにクラス1,クラス2,クラス3
とかわけのわからんものになる。
しかもメソッドまでmethod1(), method2()とかアフォなネーミングになる。
かなりウザかった。こんなコード書いた奴の会社に
殴り込みに行ってぶっ飛ばしてやろうかと思った。
バージョン違いなんてソースコードの上でやるな馬鹿野郎。
バージョン管理システム使って管理しやがれや。
継承をバージョン管理に使うなアフォ
0066デフォルトの名無しさん
2006/02/22(水) 23:53:12> >>29
> 命名が下手な奴が混じってる時点で日本語でもダメ
> 命名が下手な奴が訳解らん名前付ける位ならむしろ機能ID＋連番でプログラムを作ってもらっても構わない
それじゃCOBOLerの二の舞だぞ。
かなりウザいんだが。
そんな奴、殴ってやりたい。
連番はSubversionが自動的につけてくれるからメソッド名やクラス名にまで
つける必要はない、というかむしろ害悪だ。不要悪だ。
クラス名やオブジェクト名はなるべく名詞形でキャメルケースに
メソッド名はなるべく動詞形で先頭の頭文字だけ小文字にしたキャメルケースに、
そしてメソッド引数は目的語が入り、そのときのメソッド名にはcompateTo(Object)のように
動詞 + 前置詞 + ( + 目的語 + ) のような組み合わせになるようにしろ。
こういう命名規則を守れ。
それがすぐできそうにないとおもったらいきなり連番などせずに
辞書を使え。電子辞書を手元に置いておけ。
もしくは英辞郎かスペースアルクのページを常に開いておけ。
http://www.alc.co.jp/
>
> どうせ、初期化()、初期化前処理()、初期化後処理()とか付けときながら前処理→メイン→後処理の順番で呼ばなかったり
> 後処理メソッド内に初期化メソッドの呼び出しが入ってきたりする
まったく、ネーミングセンスがシステム開発系やデジタル信号処理系の奴に
ありがちなやつだな。入力と出力のことしか考える力がなくクラスにインスタンスフィールドを
おいて値を保持しておくという発想能力に欠ける構造化手法系な奴にありがちだな。
COBOLerみたいなオッサンは迷惑だからこの業界から去るかもっと真面目に勉強するかして
出直してくれ。
0067デフォルトの名無しさん
2006/02/22(水) 23:55:16> >>1
> >だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。
それじゃ真のメンテナンスでもリファクタリングでも無いな。
eXtreme Programingについてもっと勉強してこい。
とりあえずEclipseでメソッド抽出してみろ。
それからStateパターンについて調べてこい。
0068デフォルトの名無しさん
2006/02/23(木) 00:00:27Manager相当クラスが他のクラスにアクセスするための
Facadeになっていればそれでもオッケ。
ただしやたらと多すぎたら考え直せ。
もっと抽象的な名前を考えろ。
これって何？ と聞かれてすぐ答えられるような名前がいい。
何をするかはっきりしていればもっとマシな名前を思いつく。
メール送信ならMailSender,
読み込むだけなら○○Reader
書き込むなら○○Writer
新たにあるインスタンスを生成することをメインとするなら
○○Factory
とりあえずデザインパターンやアジャイルの本を読めば
良い名前を思いつく。
0069デフォルトの名無しさん
2006/02/23(木) 00:40:480070デフォルトの名無しさん
2006/02/23(木) 01:20:53/**
* 麺類売上げ共通処理。売上げデータを整理する。
* @param rmnUriDat ラーメン売上げデータ
* @param ysbUriDat 焼きそば売上げデータ
* @param smnUriDat そーめん売上げデータ
* @param mnmFlg メンマ追加フラグ（ラーメン売上げデータがnullでない場合のみ使用）
* @param sygClr しょうがの色(焼きそば売上げデータがnullでないか、
* ラーメン種別がとんこつの場合のみ使用)
* @param tuyKsa つゆの濃さ(焼きそば売上げデータ以外のデータに使用)
* @param tmg たまご
* @param flwDat 処理後、小麦粉データがここに返ってくる
* @return List 売上げ整理後データ
*/
static public List menUriCmnPrc( （引数とか略だ。うぜぇ） ) throws Exception {
(中身は1000行程度。うぜぇ)
}
・ 名前からして「共通処理」。"CmnPrc"ときた。
・ ラーメン担当チームは、このメソッドにラーメン売上げデータと必要なパラメータを渡す。
そして焼きそば担当チームは焼きそば売上げデータを、そーめん担当は（略）
(それぞれの「売上げデータ」は、共通のスーパークラスを持たない。
コーディング規約上、そういうクラスを作ってはいけない)
・ 焼きそば担当は tuyKsa に null を渡せばよいのかと思えば、そうではなく
空でもいいから HashMap オブジェクトが必要。
・ 引数「たまご」はどこから得るんだ？DBにも入力画面にも、そんな項目はないぞ。
こういう「賢すぎるメソッド」が発生する一番の原因は、やっぱ名前のつけ方だね。
共通処理という名前に疑問を持つ事が出来れば、
このメソッドが無駄に複雑で、要らない事まで共通化しちゃってる事がすぐに分かる。
ちなみに引数の名前の奇妙な略語は、コーディング規約によるもの。
このメソッドはぬるぽ以外の例外は出さないのに、無意味な throws 節もコーディング規約。。。
0071デフォルトの名無しさん
2006/02/23(木) 01:26:10「flour(小麦粉)」はどう略しても flw にはならんジャマイカ。
こんな深夜に何やってんだ orz 死にたい
0072デフォルトの名無しさん
2006/02/23(木) 01:30:37焼きそばは真っ赤なやつでとんこつはピンクのやつとかそんなん？
0073デフォルトの名無しさん
2006/02/23(木) 01:54:340074デフォルトの名無しさん
2006/02/23(木) 01:56:100075デフォルトの名無しさん
2006/02/23(木) 02:09:340076デフォルトの名無しさん
2006/02/23(木) 02:25:56tuyKos か tyuKsa が「正しい」ような気がする
もしかして接頭詞とそうでないのでは省略規則が違うとかなんだろうか
0077デフォルトの名無しさん
2006/02/23(木) 08:50:41というか、引数の意味不明な略語は何だ。そこからしてNG。
0078デフォルトの名無しさん
2006/02/23(木) 08:52:400079デフォルトの名無しさん
2006/02/23(木) 09:24:44こうすれば良いんじゃね？
class Interface {
public:
virtual void Proc()=0; //関数のインターフェースのみ
};
class BASE : public Interface {
public:
virtual void Proc() { Proc_1(); Proc_2(); } //デフォルトの処理
protected
void Proc_1() { ; }
void Proc_2() { ; }
};
class A : public BASE { //デフォルトの処理のまんまでＯｋ
};
class B : public BASE {
public:
virtual void Proc() { BASE:Proc(); Proc_3(); } //デフォルトの処理にプラスアルファ
protected
void Proc_3() { ; }
};
class C : public BASE {
public:
virtual void Proc() { Proc_1(); Proc_3(); } //デフォルトの処理差し替え
};
こういった感じで、インターフェースのみ逝かすならInterfaceクラス使え、
デフォルトの処理ならAクラス、さらにその中の処理を足すならB、処理を差し替えならCのように、のように自己責任でしる！、
とすれば差分コーディングだお。
0080デフォルトの名無しさん
2006/02/23(木) 09:27:290081デフォルトの名無しさん
2006/02/23(木) 10:00:19>>14は、共通化がおかしいって問題じゃなくて、
共通化はちゃんとできるとしても共通化自体をやりたがらないって問題なんだけど。
0082デフォルトの名無しさん
2006/02/23(木) 10:16:57まず、共通化できるから共通化するという動機が変。
0083デフォルトの名無しさん
2006/02/23(木) 10:17:35だって派生元クラスから派生後クラスにメソッドコピペしたら、
さすがに頃されるだろ。
0084デフォルトの名無しさん
2006/02/23(木) 10:19:58細かく部品化すれば、その場その場で異なる挙動に組み立てやすい。
希望の部品がなくても、小さい部品なら自作するのに労力も少ない。
0085デフォルトの名無しさん
2006/02/23(木) 10:45:14言いたいことは解るけどさ、
全体の設計のモデル化とは違うレベルでの共通処理・共通機能ってもんが実際あるでそ？
例えば、どのクラスに所属してもしっくり来ないメソッドをXXXutilクラスのstaticメソッドにしたりするでしょ。
あるいは大規模開発で、
設計レベルのモデルとは別の観点からのちょっとした共通機能とかってのが出てくるでしょ。
そういうの。
>>83
処理の共通化のために継承使うってのは、ほとんどアンチパターンだとおもうが。
0086デフォルトの名無しさん
2006/02/23(木) 10:48:16これって、ＷｉｎＤＮＡ時代のＭ＄の宣伝に騙されただけ。
ふつーに思考してみ。
プログラムとは記述。
記述のために各種文法があり、どの文法を使っては逝けないという決まりは無い。
記述は少ないほうが良い。
継承は文法の１つに過ぎない。
0087デフォルトの名無しさん
2006/02/23(木) 10:48:24それはプログラムの個々の設計をスキルの無いコーダーに任せるからか、その様な設計を行う作業時間をちゃんと取らせないから
008886
2006/02/23(木) 10:52:35そこにメソッド束ねられて読みやすさマンセー、
さらに類似処理で、あ、ここだけ処理差し替えでおｋ、マンセー、と分かるお。
だけど、「ある分野」という言葉はあっても、「ある分野の処理」ってのは現実世界に無い物体なわけだけど。
008988
2006/02/23(木) 10:55:48読みやすさマンセー、で、差分コードで書く量削減で、
アンチパターンんも何も無いだろ。
これでＭ＄の洗脳解けた？
0090デフォルトの名無しさん
2006/02/23(木) 10:56:07＞これって、ＷｉｎＤＮＡ時代のＭ＄の宣伝に騙されただけ。
は？？
＞どの文法を使っては逝けないという決まりは無い。
…唖然。
OOPを勉強した方がよろしいかと…。
>>87
せっかくだが、>>14を読んで言って欲しいんだが…。
0091デフォルトの名無しさん
2006/02/23(木) 10:56:52大事なのはバランス感覚。
0092デフォルトの名無しさん
2006/02/23(木) 10:57:48>>90ではちょっと暴言だったな。詫びる。
しかしだ、
＞「ある分野の処理」ってのをクラス
これはありえんよ。
クラスは、物（の種類）であって、処理ではない。
0093デフォルトの名無しさん
2006/02/23(木) 10:59:220094デフォルトの名無しさん
2006/02/23(木) 10:59:28設計レベルではそうだけど、実装レベルではあるんだよ。
コンパレーターとか、ファンクタというクラス使うことが。
0095デフォルトの名無しさん
2006/02/23(木) 11:00:46>これはありえんよ。 クラスは、物（の種類）であって、処理ではない。
架空のクラスに束ねるという意味だよ。
例えば、ドキュメントクラスなんてまさにそうでしょ？
構造体配列にロード処理とセーブ処理が付いててマンセーだけど、
現実世界にはドキュメントに該当するものが無い。
人の言う事を理解しようとする気が無いなら折角の回答が読めないだけだお。
0096デフォルトの名無しさん
2006/02/23(木) 11:03:36コンバーターなんてまさにそうだおね。
コンバート中のプロパティとメソッドが束ねられてマンセー。
で、ファンクタもそうだおね。
ファンクタってなんだけ？
0097デフォルトの名無しさん
2006/02/23(木) 11:04:47現実世界に対応する「物」とはいってないお。仮想上の「物」。
0098デフォルトの名無しさん
2006/02/23(木) 11:04:570099デフォルトの名無しさん
2006/02/23(木) 11:05:010100デフォルトの名無しさん
2006/02/23(木) 11:05:220101デフォルトの名無しさん
2006/02/23(木) 11:06:56あ、でも、それだよそれ。設計レベルじゃなくて、
その位の実装レベルで立ち現れるクラスとか共通機能とかあるでしょ。
そういうのを、みんな共通化したがらない、というのが>>14。
0102デフォルトの名無しさん
2006/02/23(木) 11:07:20クラスを大局的に書くときのパターンは現実世界に即すというのがパターンかも知れんが、
ミクロ処理を書くときにどの文法使っちゃいけないという決まりが無いことを知らない人間が、
一番ＯＯＰとプログラミングを分かっちゃいない。
0103デフォルトの名無しさん
2006/02/23(木) 11:08:17ヴぁかだにい。
ドキュメントクラスが内部にSTLをhasすれば良いでそ。
0104デフォルトの名無しさん
2006/02/23(木) 11:09:20だからそれもクラスにしちゃえば解決。
0105デフォルトの名無しさん
2006/02/23(木) 11:09:46実際、使いにくい。
いや、ずっとその会社で働いててフレームワークの設計から
携わってきたというような奴なら暗黙で分かるしコード量も
削減できるんだろうけど。
0106デフォルトの名無しさん
2006/02/23(木) 11:10:38クラスが現実世界の物に則すなんて、だれが言ったんだい？
ミクロ処理ではOOPなんか無視してクラスを作れって言いたいのかい？
0107デフォルトの名無しさん
2006/02/23(木) 11:12:01それで、いったいなぜ解決するのか？
0108デフォルトの名無しさん
2006/02/23(木) 11:12:31この言い方で理解出来て無いのがわかるね。
ミクロでオブジェクトが無いレベルなら、今使ってる言語の文法駆使して短く書け（性能はなるべく落とさず）。
これで分からなきゃ、氏ね。
0109デフォルトの名無しさん
2006/02/23(木) 11:12:43コンパイル通るって意味なんじゃないかと推測。
0110デフォルトの名無しさん
2006/02/23(木) 11:13:34大局的にベースクラスを派生したスケルトンコードをさらっと数行書いて渡せば押さえ込めるだろ。
0111デフォルトの名無しさん
2006/02/23(木) 11:15:160112デフォルトの名無しさん
2006/02/23(木) 11:16:10なるほど、アンチOO派でしたか。
それもひとつの解かもしれないけど、OOと非OOの線引きが難しいね。
0113デフォルトの名無しさん
2006/02/23(木) 11:16:18ミクロ処理ではＯＯ無視しても、いーじゃない。
0114デフォルトの名無しさん
2006/02/23(木) 11:17:03つまり最強はテンプレートメソッドパターンでＦＡ
0115デフォルトの名無しさん
2006/02/23(木) 11:17:32アンチＯＯじゃねーよ。
大局的には現実世界に合わせろといってるだろ。
だって、現実世界のモノに即す程素直な記述だお。
0116デフォルトの名無しさん
2006/02/23(木) 11:19:17最悪みんな同じような処理をprivateで書いて他人に使わせないとか、
アクセスできても他人に存在も知らせないしとか、という事を言ってるんだけど。
0117デフォルトの名無しさん
2006/02/23(木) 11:20:08短く書くと、クラスとか導入してる余裕は無いしね。
0118デフォルトの名無しさん
2006/02/23(木) 11:20:45問題があるとは思わないけど。
0119デフォルトの名無しさん
2006/02/23(木) 11:21:03そういう役割する人がいないってことかね。
0120デフォルトの名無しさん
2006/02/23(木) 11:21:11>と言うわけで、同じような処理や他人のコードのコピペが蔓延しているのはどうしたものか。
>>116
>最悪みんな同じような処理をprivateで書いて他人に使わせないとか、
ふつー、privateからprotectedとかに移動するじゃん？
それをコピペできるとはＯＯＰの基礎を勉強すれば良いんじゃね？
0121デフォルトの名無しさん
2006/02/23(木) 11:21:200122デフォルトの名無しさん
2006/02/23(木) 11:22:16クラスを現実世界の物と対応して考えること自体からして、
あんたはOO派ではないよ。
http://www.rubyist.net/~matz/20060127.html#c01
0123デフォルトの名無しさん
2006/02/23(木) 11:22:39>短く書くと、クラスとか導入してる余裕は無いしね。
ﾌﾞﾋﾞﾁｭｳか？
C++ならクラスは、
class A {
};
とふつーに書けるが。
ヘッダーファイルでもソースファイルでもどっちでも書ける。
0124デフォルトの名無しさん
2006/02/23(木) 11:24:34＞ふつー、privateからprotectedとかに移動するじゃん？
そこだよ、そこ。
そのprivateメソッドの作者に断り無く勝手に変えるのか？
0125デフォルトの名無しさん
2006/02/23(木) 11:25:49>クラスを現実世界の物と対応して考えること自体からして、 あんたはOO派ではないよ。
残念でした。あなたは超スペシャルどしろうと。
それを言うなら「OOP派じゃないよ」、ならまだ成り立つ。
そのサイトに書いてあるのはOOPであり、その中のクラスベース。
「OO」は文字通り、「現実世界の物指向」。
OOPのクラスベースが「データ抽象」「多層」「継承」 であるだけ。
0126デフォルトの名無しさん
2006/02/23(木) 11:26:42設計時に立ち現れなかったクラスを、実装時に共通処理だからって
定義して使おうってのはやめたほうがいい。
やりたいのなら、設計時に定義すること。
0127デフォルトの名無しさん
2006/02/23(木) 11:26:44そういう揚げ足とって楽しいお年頃？
0128デフォルトの名無しさん
2006/02/23(木) 11:28:08>そのprivateメソッドの作者に断り無く勝手に変えるのか？
ただの運用の話でそ？
クラスで言うprivateってのはアクセスできないよという記述であり、
アクセスできるおのpublicに移動するのがコーディングだろ。
運用ルールを決めろ。
0129デフォルトの名無しさん
2006/02/23(木) 11:29:11そしたらちょっと香ばしいのが混じってややこしくしてるだけだってわかるから。
0130デフォルトの名無しさん
2006/02/23(木) 11:29:26揚げ足じゃないよ。
学術的には、クラスベースは異端で、オブジェクトベースに逝こうすべき、であり、
クラスベースOOPから外れても、OO派には向かってるお。
0131デフォルトの名無しさん
2006/02/23(木) 11:29:59なんか、それが正論の気がするけど、
おんなじような処理を重複して諸所に書かれてるって気持ち悪いんだけど。
それに、設計時っていつ？
実装レベルのクラスとかメソッドなんて、ほとんど実装フェーズで作るもんでしょ。
0132デフォルトの名無しさん
2006/02/23(木) 11:30:420133デフォルトの名無しさん
2006/02/23(木) 11:33:45>設計時に立ち現れなかったクラスを、実装時に共通処理だからって
>定義して使おうってのはやめたほうがいい。
設計とプログラミングを別々に切り分けるのはウォーターフォールだお。
エリック・レイモンド オープンソースの解剖学四部作
くらい読んで勉強して欲しいお。
ttp://cruel.org/jindex.html
0134デフォルトの名無しさん
2006/02/23(木) 11:33:54だから、最初から運用レベルの問題を聞いてたんだけど>>14は。
みんなどうしてんの？って。
>>130
＞オブジェクトベースに移行すべき
オブジェクトベースってプロトタイプベースのことか？
「OO」がクラスベースではなくプロトタイプベースOOを指すなんて、初耳だね。どこに書かれてる？
つうか、学術的にはプロトタイプベースに移行すべきって、それこそ初耳。
そんなん、どこに書かれてるよｗ ２０年前のSUNの論文とか出してくるなよ？ｗ
0135デフォルトの名無しさん
2006/02/23(木) 11:35:14リファクタリングじゃないけど、定期的に(詳細)設計し直せばいいじゃん。
その都度、クラスとして抜き出すことが出来そうな処理を抜き出すと。
0136デフォルトの名無しさん
2006/02/23(木) 11:35:30>みんなどうしてんの？って。
無言で書き換えて、CVS格納。
0137デフォルトの名無しさん
2006/02/23(木) 11:36:55静的なクラスじゃ、シミュレーションや人工知能で困る事ね？
0138デフォルトの名無しさん
2006/02/23(木) 11:38:49どう困るの？
0139デフォルトの名無しさん
2006/02/23(木) 11:39:36それだよ、それ。
そうやって勝手に人のを使ってたら、
いつの間にか仕様が変わってて…作者「はあ？勝手に使っててそんなん知るかよ！」
0140デフォルトの名無しさん
2006/02/23(木) 11:40:160141デフォルトの名無しさん
2006/02/23(木) 11:42:56なるほどね。
リファクタリングの単位を個人じゃなくてチームに広げるのか。
小さなチーム内ならそれもできるんだけど、
メールでしか知らない人とか沢山いるんだよ…。
>>137
なぜ>>130と全然別のことを言い出すのかな？
それに学術的といいながら、いまさら人工知能ってｗ
0142デフォルトの名無しさん
2006/02/23(木) 11:43:30マは勝手なやつが多いけど自分のクラス使われるのは好きなやつだから、
＞いつの間にか仕様が変わってて…作者「はあ？勝手に使っててそんなん知るかよ！」
これ凄杉。
会社変わると良いかも。
0143デフォルトの名無しさん
2006/02/23(木) 11:44:51>それに学術的といいながら、いまさら人工知能ってｗ
しったか乙。
0144デフォルトの名無しさん
2006/02/23(木) 11:45:25いや、だって作者本人が必要があって仕様変更したんだから、
それを他人のために変えるって、そりゃないでそ…。
0145デフォルトの名無しさん
2006/02/23(木) 11:45:50チームワークの問題。リーダーに統率力が無いんじゃない
0146デフォルトの名無しさん
2006/02/23(木) 11:46:06そんなのどんなに正しい理想があっても、工数とか納期とか保守費用とか、プログラム以外の要因で
いくらでも変わるんだからさ。プログラミングでどうこうする問題じゃないべ。
実際の運営では>>135になると思う。見直しの頻度は工数とか（ｒｙ
0147デフォルトの名無しさん
2006/02/23(木) 11:47:43いや、まったくその通りなんだけど、みんなどうしてるのかなぁって。
0148デフォルトの名無しさん
2006/02/23(木) 11:50:06お互いの利益が合致しない開発では、共通化は難しいってことだね。
合致するように工夫しる。
0149デフォルトの名無しさん
2006/02/23(木) 11:51:37は？
じゃあ、人工知能学会の会員数の推移はどうだい？科研費はどうだい？
0150デフォルトの名無しさん
2006/02/23(木) 11:52:490151デフォルトの名無しさん
2006/02/23(木) 11:54:24リアル人工知能と実用人工知能を混ぜてるとこが厨杉。
画像認識なんかも大きい枠の人工知能。
0152デフォルトの名無しさん
2006/02/23(木) 11:55:23＞難しい
＞工夫しる
…orz
0153デフォルトの名無しさん
2006/02/23(木) 11:55:41消えろ。
0154デフォルトの名無しさん
2006/02/23(木) 11:56:470155デフォルトの名無しさん
2006/02/23(木) 11:57:100156デフォルトの名無しさん
2006/02/23(木) 11:57:41みんな共通に出来そうなのがあったら
もってきてくださいねー。っていえばすむだろ。
0157デフォルトの名無しさん
2006/02/23(木) 11:57:44だって、同じ会社にいながら、
＞いつの間にか仕様が変わってて…作者「はあ？勝手に使っててそんなん知るかよ！」
はﾌﾟﾁｽｺﾞｽ
0158デフォルトの名無しさん
2006/02/23(木) 12:02:04だからそれを言うのって貧乏くじじゃん。誰もやらない。
>>157
いや、実際はそういう言い方はしないけどさ…。
まああと、同じ会社とは限らないんだけどね。
っていうか、こういう風に事前に発覚すればまだいいけど、
そのまま運用に入ったら…。
0159デフォルトの名無しさん
2006/02/23(木) 12:27:03>っていうか、こういう風に事前に発覚すればまだいいけど、
>そのまま運用に入ったら…。
CVSでチェックアウトしなきゃ、該当ソース変わらんだろ？
変わっても変わったソース特定出来るし、ﾔﾊﾞｽなものはリビジョン固定しる！
0160デフォルトの名無しさん
2006/02/23(木) 12:27:48何を勘違いしているのか。それを言い出せる状況に居るのなら
幸せじゃね？
むしろ頭角を現すチャンスと捉えよ。うまく立ち回って結果を示せれば
だんだんと立場も上がるだろう。
今の職場や仕事が心底好きじゃないなら、その他大勢でいるのも
選択肢のうちだけどさ。どうするかは本人しだい。
0161デフォルトの名無しさん
2006/02/23(木) 12:27:49便利だからといって勝手に使うという方が信じられない。
0162デフォルトの名無しさん
2006/02/23(木) 12:31:41C言語ランタイムは？
くま^ー
0163159
2006/02/23(木) 12:41:39>まああと、同じ会社とは限らないんだけどね。
もしかして、ソース管理ツール使ってなくね？
ソース管理ツールなくして共通化はありえん。
つか、使え。
0164デフォルトの名無しさん
2006/02/23(木) 12:45:46公開されているなら使うのは当然。
公開されていないのなら、公開させるかコピーするべき。
#まぁ、非公開APIみたいにこそこそ使うのはリスク覚悟でやるべきだな。
0165デフォルトの名無しさん
2006/02/23(木) 12:51:540167デフォルトの名無しさん
2006/02/23(木) 14:08:56>ライブラリ化せずにバイナリは別にするのか。しかし、名前のバッティングが。
いや、ライブラリといってもバイナリじゃなくてソースだろ？
まさか、バイナリってＣＯＭじゃないだろうね？
ＣＯＭの世界は終焉したお。
0168デフォルトの名無しさん
2006/02/23(木) 14:45:02クラスライブラリでの共通化は上手くいくけど、
ＣＯＭはその辺りが上手く逝かなくてあぼーん、
クラスライブラリベースのドトネッツが出来たわけ。
0169デフォルトの名無しさん
2006/02/23(木) 14:45:09ソースを自分だけはリビジョン固定で使っても、名前が本家とバッティングするじゃんて話。
0170デフォルトの名無しさん
2006/02/23(木) 14:50:02>ソースを自分だけはリビジョン固定で使っても、名前が本家とバッティングするじゃんて話。
全く意味が分からん。
本家のクラスを派生して、
本家のメソッドを変えたいときは、オーバーライドで同じ名前使うし、
新たにメソッド足すときは違う名前にするじゃん？
それが意識せず名前ブツカッたらコンパイルエラーか警告出るだろ？
0171デフォルトの名無しさん
2006/02/23(木) 14:54:28もしかして、リビジョン固定の意味分かってなくない？
本家のリビジョンを固定するんだお。
本家の人がどんどんチェックインしようが、
自分のコンパイル環境では固定されてるリビジョンのソースは変わらないんだお。
どうしても変えたい場合は意識してリビジョンうｐして、
何がどう変わったかは差分ツールで見れば良いじゃん。
0172デフォルトの名無しさん
2006/02/23(木) 14:55:350173デフォルトの名無しさん
2006/02/23(木) 15:00:39そのブランチが気に入れば本家にお願いして最新にマージして貰え。
0174デフォルトの名無しさん
2006/02/23(木) 15:01:400175デフォルトの名無しさん
2006/02/23(木) 15:04:23プロジェクトチームとは別バージョンのプログラム開発すればいいのか。
0176デフォルトの名無しさん
2006/02/23(木) 15:20:300177デフォルトの名無しさん
2006/02/23(木) 16:16:43( ﾟдﾟ)
＿(__つ/￣￣￣/＿
＼/ /
￣￣￣
( ﾟдﾟ )
＿(__つ/￣￣￣/＿
＼/ /
￣￣￣
( ﾟдﾟ)
＿(__つ/￣￣￣/＿
＼/ /
0178デフォルトの名無しさん
2006/02/23(木) 17:18:35こっち見るんじゃないよ
0179デフォルトの名無しさん
2006/02/23(木) 18:01:540180デフォルトの名無しさん
2006/02/23(木) 18:03:28俺は>>175じゃないが。日本人は、こういういちいち小馬鹿にする奴がいるのが駄目だ。
知らない事があっても構わないじゃん。お前には無いのかと。
同じ民族なんだし助け合えやクズどもがコルァ
>>175
そうなのです。Javaの1.4で開発してて、リリース時にはJava1.5にアップグレードするとかないでしょ。
アップグレードしたことによって動作検証とか大変だし。
無理に最新にあわせることはないのです。たとえ社内開発という小さい規模の開発であっても。
0181デフォルトの名無しさん
2006/02/23(木) 18:06:32コンパイルじゃなくて、実行時の話？
JavaとかCOMとかDLLでの開発限定の話か？
0182デフォルトの名無しさん
2006/02/23(木) 18:15:18＞だからそれを言うのって貧乏くじじゃん
ああ、なんかわかるなぁ。
ひとつの共通処理担当になると、いつの間にか全部の共通処理担当になってて、
しかも、自分が元々担当してた業務ロジック部分も当たり前、開発しなくちゃいけなくて、
業務ロジック＋共通処理（仕事増えた）でなんか仕事増えてて、
「共通処理」の部分で不具合とか、仕様改善したくなったら「全部あの人が知ってます」的な事を言われて（略
やっぱ、自ら進んで言いたくない事だよな。うんうん。
0183デフォルトの名無しさん
2006/02/23(木) 18:23:03だね。バグが出るたびにろくに調べもせず「共通処理が…」とか言う馬鹿もいたりするだろうし。
0184デフォルトの名無しさん
2006/02/23(木) 18:33:320185デフォルトの名無しさん
2006/02/23(木) 19:37:41そう。というか普通だと思うが。
ひとりひとり自分のスタティックリンクのexe作るプロジェクトとかあるか？
普通多かれ少なかれ他人と名前空間の空間を共有するだろ。
0186デフォルトの名無しさん
2006/02/23(木) 20:44:03言語の方にNamespaceとかPackageとかあるし
そもそもチームでの開発なら命名規約ってのがあるのが当たり前
0187デフォルトの名無しさん
2006/02/23(木) 21:23:28おまえ、話の流れ全然理解してないだろ
0188デフォルトの名無しさん
2006/02/23(木) 22:10:12実際にシステムの存在そのものの根拠がエンティティの複雑性というかそれぞれがどれだけ
特異であるかという部分にあるのに、実装はいつも未だにユーザーの入力や欲しがってる出力に
主眼をおいてなされるのででてくる問題
システムをあるがまま正確に捉える見方は確かに存在するのにも関わらず
無理やりおかしな断面で切り取ってくるから
まるで木材をわざわざ横向きに年輪に垂直に切ったみたいに
同じような条件分岐がひとつのルーチン内に頻出することになる
0189デフォルトの名無しさん
2006/02/24(金) 00:16:41共通化できるユーティリティはいつの間にか作成
共有化できる処理はテンプレートメソッドパターンでいつの間にかフレームワーク構築
やりたいことがあったら全部その人がFacade・・
同じ処理を書くのはキモイらしい
0190デフォルトの名無しさん
2006/02/24(金) 00:52:25同志よ！そうそう。それそれ。よく言われました。
>>184
おまえ、開発やＳＥでトップとったところで所詮、平社員だぞ？
役職につける奴は、開発技術能力より、人を管理する能力とか、企画力がある人間だよ。
0191デフォルトの名無しさん
2006/02/24(金) 00:57:33えっ、いや。あの。普通か？
「名前空間」なんて言葉使うから、なんの話かわかりにくくて、みんな混乱してるわけで。
最初からＤＬＬでの開発が前提ですとかってことを伝えないと。正直、言葉足らずでございます。
0192デフォルトの名無しさん
2006/02/24(金) 01:18:30業務システムの開発で、
みんな個人個人が自分のstaticリンクexeを作るなんて有り得ませんから。
0193デフォルトの名無しさん
2006/02/24(金) 01:34:19うらやまスィ…。
ただ、それって数人規模だから出来る、とかじゃない？
うち、１００人以上のプロジェクトだから、うちに来たらその神は天に帰ってしまうな…。
0194デフォルトの名無しさん
2006/02/24(金) 02:02:42業務システムの開発で、言語がＣで、かつＤＬＬベースでの開発の仕事なんて最近じゃすくないぞ。普通か？
だから、「名前のバッティング」とか言われたらnamespace使えとかpackage使えっていう話の方向になるわけで。
>>193
１００人規模ですか…。俺なら天に帰るというか、会社から帰れなくなりそうだ…。
0195デフォルトの名無しさん
2006/02/24(金) 04:21:340196デフォルトの名無しさん
2006/02/24(金) 08:35:47>そう。というか普通だと思うが。
普通はＣＯＭなら廃止の方向だが。
0197デフォルトの名無しさん
2006/02/24(金) 08:41:54>開発やＳＥでトップとったところで所詮、平社員
ずいぶんと不憫な会社だな
0198デフォルトの名無しさん
2006/02/24(金) 08:58:09なぜお前らは特定実現技術こだわるのか。
JavaだってPerlだってそうだろ、C系だってDLL使うだろ。
だいたい>>14からの流れで単にnamespace使うのがどうして解になり得るのか小一時間…
0199デフォルトの名無しさん
2006/02/24(金) 09:05:31解になることは決着が付いてる。 >>171-177
0200デフォルトの名無しさん
2006/02/24(金) 09:06:42まだＭ＄の洗脳が解けてないね。
0201デフォルトの名無しさん
2006/02/24(金) 09:14:310202デフォルトの名無しさん
2006/02/24(金) 09:16:49DDE（Win3.1or3.0 1993)
↓
NET DDE (Win3.1 1994)
↓
埋め込みしたいなぁ．．．
↓
OLE1.0（DDE使用）
↓
OLE2.0=COM ただし目的はインプレースドキュメント。しかしその背景には本質としてバイナリオブジェクト標準あんどオブジェクト通信の思想あり。この辺で名慮or迷著 InsideOLEあんどIsideOLE2。死者多数。
部品としてVB用のVBX (VB2.0からVB4.0 1995あたり)
↓
COMを使ったOCX (1996あたり）結局コンポーネントビジネスはやんなかったな...
ゲイツがインターネットに熱上げあんどJAVA Appletはやる (1995）
↓
COMつかってActiveX(1996)
だんだんオブジェクトはやってくる。 （UMLなど1997）オブジェクトもでるとしてCOMの宣伝開始 DCOMなどCORBAとがっぷり。この辺でMTSではじめ
↓
マーケティングてきなWindowsDNA 。MTS2.0それなりに使えそう。つか使った。DCOM糞。(1999)
↓
COM+ （Win2000､2000）In-MemoryDBどこいったゴラァ
COM Runtimeの情報漏れ始め (2000〜)
↓
セキュリティ→ファイアーウォールのためCOM全滅。しばらくしてから.NETとしてCOMじゃないものに．．．
↓
.NET流行らず(〜2006)
↓
WinFX完成(2007)
↓
アプリがオブジェクトベースプログラミングにより、OSのＡＰＩはクラスベースから関数コールに戻る(2008)
WinFX下位互換へ
0203デフォルトの名無しさん
2006/02/24(金) 09:39:220204デフォルトの名無しさん
2006/02/24(金) 10:14:330205デフォルトの名無しさん
2006/02/24(金) 10:29:49アホ。お前の事を言ってんだよ
0206デフォルトの名無しさん
2006/02/24(金) 11:09:470207デフォルトの名無しさん
2006/02/24(金) 11:14:13VB.NETで書けば良いじゃん
0208デフォルトの名無しさん
2006/02/24(金) 11:17:51しかしながら、CLRはクラスライブラリには超珍しいソースを見せないクラスライブラリ。
その点超世界的に使い難い派生し難いMFCにも劣る。
0209デフォルトの名無しさん
2006/02/24(金) 11:19:560210デフォルトの名無しさん
2006/02/24(金) 11:20:360211デフォルトの名無しさん
2006/02/24(金) 11:22:12そのために各言語にdelegate構文が追加されてるんだろ
メンドクサイ所は弄るなよ
プログラムの段階じゃなくて設計の段階で実現できそうに無い事は排除して行かないと
0212デフォルトの名無しさん
2006/02/24(金) 11:24:32CLRのpublic/privateが見えないんだから、何がメンドクサイ部分かも分からない暗闇。
211=暗闇でマンセー
0213デフォルトの名無しさん
2006/02/24(金) 11:28:10∴∴∴∴∴∴
|￣P∴∴∴∴∴∴∴∴
／ ＼
|￣￣￣|
|ﾌﾏｷﾗｰ|
| (,,ﾟДﾟ) ＜ 死ねや。ｺﾞﾗｧ!
| （ﾉ |つ
| M$ |
|＿＿＿|
U"U
＼ ／
＼ ／ ／￣￣￣￣￣￣￣￣￣￣
／￣￣￣(,ﾟДﾟ,) ＜ VBは便利だよ。便利なものは便利につかわせていただく。
~￣>￣>￣> ヽ ＼＿＿＿＿＿＿＿＿＿＿
0214デフォルトの名無しさん
2006/02/24(金) 12:48:02⊂／ ノ ） ／
/ /ノV ｲﾅﾊﾞｳｱｰ
≡≡≡≡し'⌒∪ ＼
'┴┴ ┴┴'
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
／⌒`ヽ
二 と（、Ａ , ） つ ＜ｲﾅﾊﾞｳｱｰ
三 Ｖ￣Ｖﾉ（ ゝ
0215デフォルトの名無しさん
2006/02/24(金) 12:49:26もう目もあてらんない。
0216デフォルトの名無しさん
2006/02/24(金) 21:25:39懐かしいな、マトリクス。
0217デフォルトの名無しさん
2006/02/24(金) 22:20:19みんちーって何だ？
お前が挽肉にでもなったのか？
0218デフォルトの名無しさん
2006/02/24(金) 22:28:30無駄に引数が多すぎ。
そんなことするなら引数はList<専用クラス>ひとつとかにまとめておけよ。
それか
class 何か {
private List<売上げデータ> list;
public void add(売上げデータ data){
this.list.add(data);
}
}
みたいなことしたほうが効率が良い。
0219デフォルトの名無しさん
2006/02/24(金) 23:03:12> >>78
> こうすれば良いんじゃね？
ただのTempate Methodパターンのまがいものにしか見えない部分
があるようだが。
Proc_1()というネーミングがどうも古臭い。
そういうところにアンダースコアを使う必要はない。
メソッドの頭文字をわざわざ大文字に擦る必要もない。むしろしないほうが
読みやすい。無駄にメソッド名に数字を使うのは御法度。
意味のある名前にして場合分けしろ。
しかもメソッドの中身は空っぽ、継承しているクラスAまで空。
あまりにも意味がなさすぎる。
最後の三行から言いたいことがだいたいわかったが、
それにしても
やっていることはただのオブジェクト指向の初歩にすぎないな。
0220デフォルトの名無しさん
2006/02/25(土) 00:12:09まず引数が多すぎるし、ある引数が他の引数に応じていろいろ制約があるのがすでに終わってる。
＞こういう「賢すぎるメソッド」が発生する一番の原因は、やっぱ名前のつけ方だね。
賢すぎないし、むしろアホ。何やってるかわかんないだろ。
大体テストどおすんだよ。テストコードとか作んないのか？
らーめんはらーめんで、焼きそばは焼きそば、そーめんはそーめんで
分割したりしろよ。
0221デフォルトの名無しさん
2006/02/25(土) 00:17:25設計なんて呼べるようなことはしてない可能性も高いが。
0222デフォルトの名無しさん
2006/02/25(土) 00:18:100223デフォルトの名無しさん
2006/02/25(土) 01:59:05「賢すぎるメソッド」とかの話、聞いたことないかい？
つか、確かに、意外とあまり語られないからなあ。。。
要するにまさに >70 のように、一つのメソッドが何でもかんでも抱え込んじゃった
「何でも屋」なメソッドの事。
>218 の指摘の通り、無駄な引数が多くなるのがこの類の失敗の特徴だよね。
>222 の言う通り、この「賢すぎる」は「賢いっつかテメー賢すぎだよバカ」みたいな
逆説的な意味だ。
初学者がよくやらかすんだよな。それで結局破綻して痛い目を見て
共通化や分割統治のバランス感覚をつかむ。
> 大体テストどおすんだよ。テストコードとか作んないのか？
気合だよ！ヽ(｀Д´)ノ 今日、気合でテストデータ全部作ってやったよ！
漏れがんばった！ほめてほめて！！１
つД`･)ﾟ･｡どうして漏れが作んなきゃいけないんだよ！！！！１１２１２１ぬぬ！！
0224デフォルトの名無しさん
2006/02/25(土) 02:00:53無駄に賢すぎるみたいな。>>70みてたらラーメン食べたくなってきた。
って、よく>>70を見てなかったが良く見ると確かに うぜぇ >>70の気持ちわかるわこれ。
さらに追い討ちをかけるような↓このコーディング規約ｶﾜｲｿｽ
＞ (それぞれの「売上げデータ」は、共通のスーパークラスを持たない。
＞ コーディング規約上、そういうクラスを作ってはいけない)
02261しか読まずに
2006/02/25(土) 02:16:49ってのは、そこで前編後編に関数をわけるんだよ。Ifの後も続くなら前中後で３個に。
Public Sub 処理Ａ()
Call 前処理 ' Private
Call 中処理Ａ' Private
Call 後処理' Private
End Sub
Public Sub 処理Ｂ()
Call 前処理 ' Private
Call 中処理Ｂ ' Private
Call 後処理 ' Private
End Sub
このまとまりでクラス1個にして。
入り口1箇所がいいなら
Public Sub 処理(条件)
If 条件="A" Then
Call 処理Ａ ' Private
ElseIf 条件="B" Then
Call 処理Ｂ ' Private
End If
End Sub
とかパターンはいろいろあるだに。条件を引数じゃなくてプロパティにするとか。
02271しか読まずに
2006/02/25(土) 02:20:08Call 前処理 ' Private
If 条件="A" Then
Call 中処理Ａ ' Private
ElseIf 条件="B" Then
Call 中処理Ｂ ' Private
End If
Call 後処理' Private
End Sub
みたいなのでもいいよ。Ifを減らすようにすると原則いいかもしれない。
構造化の範囲で書いてます。継承とかももちろん考えればあるけど
ローテクで済むところは済ますに超したことはない、かもしれない。
0228デフォルトの名無しさん
2006/02/25(土) 15:35:39前中後なんて単純な分け方の問題じゃない。
無理に分けても、さらに条件が出て来て
コピペ地獄へ大ばく進だ。
このメソッドをどうするってばかりに目が行ってるが、本当は引数の方が賢くならなきゃいけない。
0229デフォルトの名無しさん
2006/02/25(土) 17:38:340230デフォルトの名無しさん
2006/02/25(土) 21:12:000231デフォルトの名無しさん
2006/02/25(土) 21:29:47全然違う
もっと勉強せれ
そもそも「前中後」って発想がナンセンス
0232デフォルトの名無しさん
2006/02/25(土) 21:36:59反論するなら中身を書くこと。
おまえのようなレスには、
「おまえの方が間違っている。」で十分だ。
0233デフォルトの名無しさん
2006/02/25(土) 23:25:06我が身見て・・（藁
0234デフォルトの名無しさん
2006/02/25(土) 23:30:170235デフォルトの名無しさん
2006/02/25(土) 23:59:54public hoge(List list) {
//ズラズラとソート処理
//ズラズラと分別処理
//ズラズラと整形処理
}
触りたくないと思わない？
適当な粒度で細分化した方が分かり易いよ。
単純な二分割三分割なら確かに無意味だけど・・・・・・
0236デフォルトの名無しさん
2006/02/26(日) 00:23:41もっと緻密なコードになってるのが普通。
0237デフォルトの名無しさん
2006/02/26(日) 00:25:18というかね、下手に賢すぎるなんて言ったら、お前、
「俺は頭が良いんだ！」「俺は天才なんだ！」「俺は認められたんだ」
「俺は高く評価されているんだ」
と勘違いするバカがいるから気をつけろ。
そのことを>>220は警告してるんじゃないかと思う
0238デフォルトの名無しさん
2006/02/26(日) 00:31:50> 要するにまさに >70 のように、一つのメソッドが何でもかんでも抱え込んじゃった
> 「何でも屋」なメソッドの事。
どこが何でも屋だ。
AV機器の端子に喩えれば
昔の端子だらけのRGBケーブルみたいなもんだ。
今ならD端子一つを刺すだけで完了だが、
昔は何本も刺さなければならなかった。
それを何でも屋と名付けるなんて恥ずかしい。
> 初学者がよくやらかすんだよな。それで結局破綻して痛い目を見て
初学者という寄り、オブジェクト指向を否定するバカが
ああいうことをよくやっていた。システム系、信号処理系の
研究室にいた奴がC/C++でそれをやっていた。
「関数だけで十分だ！」と
言い張ってオブジェクト指向のことをろくに勉強しなかったために
メソッドの引数があんなに増えた。アホにもほどがある。
オブジェクト指向ができなくても、せめて構造体くらい使いやがれと。
> > 大体テストどおすんだよ。テストコードとか作んないのか？
> 気合だよ！ヽ(｀Д´)ノ 今日、気合でテストデータ全部作ってやったよ！
> 漏れがんばった！ほめてほめて！！１
ちゃんとxUnit使ってやってるのか？
先にテストコードを書いて本番コードはスケルトンだけを書いておく
ってことをやるはずだが。「気合い」とか精神論持ち出すやつは
20年前の開発スタイルを押しつけるオッサンと変わらんよ。
こんな奴ばかりいるから日本のソフトウェア開発は後れを取っている。
製造業などのハードウェアだけは進んでおきながらソフトウェアに
関してはいい加減な奴が多い。これもハードウェアが威張って
「ソフトウエアはんて名前の通り柔らかいものだから簡単だろっ！」
とか解ったつもりになっているからいい加減になる。
0239デフォルトの名無しさん
2006/02/26(日) 00:36:19最悪だお前。
まさにブビ忠度炸裂だなw
せめてブビドトネト厨度を炸裂させた方が
高い評価を得られたのに。
それじゃif文が無駄に増えて煩雑になる一方だ。
せめてBefore Afterパターンや
Hook Operatorパターン、Template Methodパターン、
Stateパターンについて勉強して貰いたい。
これらのパターンについて調べれば
お前のやりたいことが叶うかもしれん
0240デフォルトの名無しさん
2006/02/26(日) 00:38:36チームで開発するときは
新たな修正が容易になるという利点がある。
ほかにも、いずれ同じ処理を
また書きそうなところがあると
見たときは分割するのもあり、
分割しておいたおかげでメソッドをコールするだけで
済んだ、と言う可能性もある。
0241デフォルトの名無しさん
2006/02/26(日) 00:41:00分割したくない理由はどうしてもパフォーマンス
やリソース節約を重視したいとき、だろうな。
それ以外に考えられるか？
それらを考えなければ、積極的に分割すべきだと思う。
分割はそう難しくない。言語にも夜だろうけれども。
「分割して統治せよ」はオブジェクト指向設計原則でも有名な話だ。
詳しくは "Design By Contract" についてググってくれ
0242デフォルトの名無しさん
2006/02/26(日) 00:55:19Eiffelみたいなやり方だろ。分割と何の関係があるんだ？
0243デフォルトの名無しさん
2006/02/26(日) 00:56:11複雑で長い処理が出来上がるパターンとして、不具合や仕様変更に対応するために、
本来はそのメソッドに入る前でやるべき処理を全部そこで辻褄合わせ的に行ってる
というの多いわけで。
根本的には、設計を見直して適切な場所で適切な処理を行うように修正するべき。
0244デフォルトの名無しさん
2006/02/26(日) 01:03:09それをプライベートメソッドに押し出してやるだけでも随分すっきりする。
時間は掛からないし、そうできない理由というのも思いつかない。
0245デフォルトの名無しさん
2006/02/26(日) 01:10:39どうしようもないのならとりあえずやってもいいだろうけど。
0246デフォルトの名無しさん
2006/02/26(日) 02:24:14デグレしても、「あらら」で済む世界ならそうだろうね。
0247デフォルトの名無しさん
2006/02/26(日) 04:16:10前処理とかも同じ事だろ。
たとえば、>>235の例のようにさ。
一つの関数で、ソートと分別と整形処理をやっていたら、
普通はソート関数と、分別関数と整形関数に分けるだろ？
それとも、このソート処理はhoge関数でしか使用しないから、
関数にせずにhoge関数にずらずら書くべきと言う人がいるのだろうか？
やっぱり適度な粒度で細分化するべきだよ。
ソート関数（前処理）、分別関数（中処理）、整形関数（後処理）に分けるべきだよ。
0248デフォルトの名無しさん
2006/02/26(日) 04:20:59> できないんじゃなくて、もっとまともな解決方法を考えるべきと言ってるだけなんだけど。
おまえ、会議で何か結論出るたびに、
「もっとまともな解決方法を考えるべき！」と言って、
なにか聞かれたら、「それを考えるのはあなたたちだ！」と言っているだろ？ｗ
その方法使えば、どんなバカでも解決方法が無くても「もっとまともな〜（略」で否定できるなｗ
それじゃ、世の中やっていけないよ。説得力ないし。
自分でもっとまともな方法を提案してこそ意味がある。出直して来い。
0249デフォルトの名無しさん
2006/02/26(日) 04:26:37リファクタリングって知らない？
関数に分割する作業ってのは、リファクタリングの一つだよね。
リファクタリングにも取り上げられているように、これはやるべき作業。
おまえが言っているのは、「デグレが怖いから汚いまま放置するべきだ」と言っているに過ぎん。
俺だったら、そんなマイナス思考じゃなくて、デグレなく作業できる
リファクタリングブラウザがもっと成熟して普及してくれとコメントするよ。
0250デフォルトの名無しさん
2006/02/26(日) 09:16:28言っておくが、完成してるなら触るなよ。くれぐれも触るなよ。
寝た子は起こしちゃいかん
0251デフォルトの名無しさん
2006/02/26(日) 09:21:09自分の意見に合わない提案は目に入らないタイプ？
0252デフォルトの名無しさん
2006/02/26(日) 09:23:19＞それ以外に考えられるか？
分割できないほど、密接に絡み合ってるコード・・・の意味だと思うよ
＞public hoge(List list) {
＞ //ズラズラとソート処理
＞ //ズラズラと分別処理
＞ //ズラズラと整形処理
＞}
こんな、単純な例なら誰も苦労しない
ある条件で、ソート順が変わって、更に加えた条件で分別処理が分岐して・・
とか、大抵は「if]ネストの嵐になってる、そう言った「関数」は
1メソッド＝1責務なんて、最初から頭に無いんだから、そう言うの作る人は
0253デフォルトの名無しさん
2006/02/26(日) 11:24:12完成してテストする前ならある程度改修する必要があると思われ？
0254デフォルトの名無しさん
2006/02/26(日) 12:39:45学生さん？
あんな酷いことになってる関数・クラスに、まともなユニットテストが備わってると思うのかい？
あんな酷いことになってる関数・クラスが、まともにユニットテストが書けるほどTestableになってると思うのかい？
ユニットテストなしにリファクタリング？そりゃ、大層気持ちが良いだろうねぇw
デグレしても、「あらら」で済むんなら。プロではあり得ないけど。
>>253
そういう場合もあるだろうが、
あんな酷いことになってる関数・クラスは、たいてい
デスマでそんな事する余裕なんかカケラも無い状態で生まれると思われ？
0255デフォルトの名無しさん
2006/02/26(日) 12:45:39なにデスマを自慢してるんだよｗ
0256デフォルトの名無しさん
2006/02/26(日) 12:50:59普通に作っているときに、長すぎる関数は一定の機能、
たとえばソート処理や前処理で普通に分割するだろ。
しない奴要るというのなら手を上げて。
0257デフォルトの名無しさん
2006/02/26(日) 13:00:420258デフォルトの名無しさん
2006/02/26(日) 13:02:17そして、こういうものは「しない奴」がいて、「する奴」が後で発見する。
「しない奴」はただ純粋に方法を知らなかったりする。
「しない奴」はこのスレを見ないと思うがどうか？
自分が神経質すぎるのだろうか・・・
0259デフォルトの名無しさん
2006/02/26(日) 13:03:48うん、普通は分割するね。
でも、集団で開発してると、中には分割しない人もいたりするんだ。
そういう人が作った汚いコードをどうしようかという話。
0260デフォルトの名無しさん
2006/02/26(日) 13:22:06そういう話じゃなかったはずだが？
0261デフォルトの名無しさん
2006/02/26(日) 16:37:23原因はいろいろあるけど、ひどいのがプロトタイプを作った奴が
分割してなくそのままコピーして作ると酷いことになることある
実際ソースレビューしてる現場って何%あるんだ？
漏れはその現場に入ったことないな
あとは仕様書通りにメソッド、クラスがないと怒り出し設計者様
１メソッド２０００実ステップは泣けた
0262デフォルトの名無しさん
2006/02/26(日) 17:16:59むしろくそまじめにソースレビューやるようなところのほうが酷い気が。
親会社の社員が作った関数なんで(仕様を満たしてる以上)文句言えなかったり、
関数作るのにも処理フロー書いてSEの許可をもらう必要があったり。
0263デフォルトの名無しさん
2006/02/26(日) 18:30:24そもそも、それだけあったらレビュー前に一言「帰れ」で終了だし。
0264デフォルトの名無しさん
2006/02/26(日) 18:38:320265デフォルトの名無しさん
2006/02/26(日) 18:39:32なにを”
俺はまじめにソースレビューする親会社側だが、
２画面以上のメソッドは書かないし当然俺が入ったレビューではそんなの弾くぞ。
といいつつ、今正しく動くことしか考えてない連中もたしかにいるな…。
0266デフォルトの名無しさん
2006/02/26(日) 18:39:53学生さんですか？
0267デフォルトの名無しさん
2006/02/26(日) 19:44:31お前こそ学生だろｗ
0268デフォルトの名無しさん
2006/02/26(日) 20:34:30ソース見た時点でかなり汚れてて、指摘難しかったりするとき。自分で書き直したくなる。
規約とか綺麗なコードの書き方とか低レベルな指摘するのはメンドイ
今動くしか考えてない人に仕様変更言って見積もりさせると、そんなにかかるの？みたいな
0269デフォルトの名無しさん
2006/02/26(日) 20:53:590270デフォルトの名無しさん
2006/02/26(日) 20:57:57そのうち、どうでもよくなったよ。
いや、全然よくないんだが、動いてるソースをいじることは
出来るだけしない。
はっきりいってリファクタリング出来る内容じゃない。
0271デフォルトの名無しさん
2006/02/26(日) 21:01:33とりあえずパッチ当てまくって動くように修正していくしかないわなぁ。
全体の構造解析してたらそれだけで一ヶ月とかかかっちゃうし。
0272デフォルトの名無しさん
2006/02/26(日) 21:15:27有り難味が解らない人には何を言っても無駄・・
な気がしてきた、最近
疲れたよ・・・
0273デフォルトの名無しさん
2006/02/26(日) 21:55:38大元の仕様が変わっても修正工数が少ないから半端仕事にしかならない。
なのに「動けばいい」プログラムを書く害虫は修正工数分請求してきやがる。
運良く(非常に緩い)コーディング規約を守ってない関数があったから
減額してやったけど。
0274デフォルトの名無しさん
2006/02/26(日) 22:02:43下手に書けば書くほど、修正工数増えて「売上」が上がる
何か世の中間違ってる
0275デフォルトの名無しさん
2006/02/26(日) 22:07:46> 規約とか綺麗なコードの書き方とか低レベルな指摘する
> のはメンドイ
綺麗なコードはいざ知らず、コーディング規則は発注する時
に納入条件として指示するだろ。
指示も無しに、気に入らないから直せと言うのは親会社を傘
に着たわがままだよ。
>>273
「仕様を変えたことで外注さんが修正工数要求したから頭に
きてる。」
おいおい、そりゃ当然だろ。
どんな契約の仕方してるんだよ。
0276デフォルトの名無しさん
2006/02/26(日) 22:12:35行間を読もう。
>268は「指示もなしに直せ」なんて話はしていないし、
>273も請求してくること自体を論っているわけではない。
0277デフォルトの名無しさん
2006/02/26(日) 22:16:13冷静なレス乙
0278デフォルトの名無しさん
2006/02/26(日) 22:16:19そんなくだらないことを理由に減額してたら、
質の悪い害虫しか寄り付かなくなるぞ。
「本質的にコードの質が悪い。動けばいいってもんじゃない」
というのをちゃんと伝えとけ。
0279デフォルトの名無しさん
2006/02/26(日) 22:18:59？？？な奴はどうすればいいか
0280デフォルトの名無しさん
2006/02/26(日) 22:20:550281デフォルトの名無しさん
2006/02/26(日) 23:51:18はっ？ 仕様書の行間を読めって言うエスパーをご所望の
方ですか？
> >268は「指示もなしに直せ」なんて話はしていないし、
>>268 がそういう指示をしてるってこと？
だったら、「低レベルな指摘するのはメンドイ」なんて
ことはないだろ。「納入条件に合うもん持って来い」の
一言で済むと思うけどな。
> >273も請求してくること自体を論っているわけではない。
「害虫は修正工数分請求してきやがる。」って言うのは、
請求自体を ("も" かも知れないけど) を問題にしてるわ
けじゃないと…、なかなか凄い理解力の持ち主ですね。(w
>>278
同意。
ただコードの質と言うものはなかなか規定しづらいので、
>>279 見たいなところがでてくるのは致し方ないのが現実。
>>280 みたいにできればいいけど、なかなか色々な諸事情
で難しいことも多いから、根気良く外注さんと話し合うしか
ないんだよなぁ。
0282デフォルトの名無しさん
2006/02/27(月) 00:04:56ただし、スクラッチ開発以外ではそもそも計測困難という諸刃の剣。
0283デフォルトの名無しさん
2006/02/27(月) 01:18:25いや、うちもメトリックスツールとか静的コードチェッカ
とかの導入を検討してるんだけど、いい (と思える) コー
ドと、ツールが示す結果との相関関係がなかなか見出せな
いんだよね。まあ、こっちも地道にデータを収集しかない
と思う。
0284デフォルトの名無しさん
2006/02/27(月) 01:32:300285デフォルトの名無しさん
2006/02/27(月) 01:59:40そもそも「いいコード」が定義可能ならばそれを規約とか検収条件にすれば良いでそ。
>>283
メトリクスの使い方は正しいとは思うけど。
「相関関係が存在する」という根拠は？
0286デフォルトの名無しさん
2006/02/27(月) 02:04:15「相関関係がない」ってのは、どんな糞コードとどんな美麗コードを比べても、
どちらが良いと判断されるかは完全にランダム、ってことだよ？
そこまで使えないの？
0287デフォルトの名無しさん
2006/02/27(月) 02:05:350288デフォルトの名無しさん
2006/02/27(月) 02:12:11ソースについて測定するメトリクスについての話をしてるんだが。
その数的性質が、目的通りコードの美しさに相関してるかどうかという話をしてるんだが。
0289デフォルトの名無しさん
2006/02/27(月) 02:15:580290デフォルトの名無しさん
2006/02/27(月) 02:42:230291大根
2006/02/27(月) 05:43:15そうですね。
>>1で問題としたのはデグレという概念は知ってるが、リファクタリングという概念は知らないプロジェクトですね。
テストプログラムによる自動テストを導入して、各メソッドはこのテストさえクリアしていればバンバン変更していいという状態なら苦労しないのですが。
ただし、仮にテストプログラムに漏れがあって、想定外の動きをしていて、結果的にシステムが正常に動いていた場合、
その想定外の動きの部分が、メソッド修正により変わってしまい、結果的にシステムに異常が発生してしまう（デグレ）可能性があります。
とはいえ、それは自動テストが導入されていなくて、マカロニ修正を繰り返した場合でもデグレの可能性はあるわけで、、、
うーん、リリース前はどんどんリファクタリングやって、
リリース後は大幅な修正でない限り、マカロニ修正でいいんじゃないかと思う。
あくまで私の経験したプロジェクトでの話しですが、最初から最後までリファクタリングの概念がないことが問題なんだと思います。
それに、本番でデグレを起すと本当に大問題になるプロジェクトか、あららで済むプロジェクトかで
話は変わってくるかもしれません。
0292デフォルトの名無しさん
2006/02/27(月) 09:17:16あんまりツール知らないのでたいしたコメントはできませんけど、相関関係以外に、
「どこまで」を正しいとするか、の判断も難しいと思いますよ。
>>291
リリース後に広範囲に影響するリファクタリングの危険性はわかりますけど、
マカロニ修正を肯定してしまうのも危険かと。どっちが正しいじゃなくて、中間あたりに
落ち着くんじゃないかな。
0293デフォルトの名無しさん
2006/02/27(月) 13:02:520294デフォルトの名無しさん
2006/02/28(火) 00:00:59まあ、落ち着けｗ
取り合えずエスパーじゃない人にも分かる様に
説明できる術を見につけてくれｗｗ
0295デフォルトの名無しさん
2006/02/28(火) 02:20:42＞なのに「動けばいい」プログラムを書く害虫は修正工数分請求してきやがる。
これは、綺麗にコード書いていたら、３日で終わるような改修作業を、
外注さんが汚いコードで書いたが故に１ヶ月も掛かります。とかいう請求してきたことに
腹を立ててるって意味じゃないの？
俺も部外者だから実際はどうだかわからんがな。
0296デフォルトの名無しさん
2006/02/28(火) 02:38:31外注だったら、こういう人は外すしかないだろうね。
プログラマって建築業と似たようなもんだろ。建てればいいってもんじゃない。
地震に対する強度とか、欠陥住宅を建てないようなスキル程度は、
プロとして金もらって働いている以上は必要だと思うからね。
プログラマだったら保守しやすいコードくらい書けないと、働く（金を貰う）資格は無いと思う。
社員だったら教育しなおすか、適正なしとみなして違う部署に飛ばすしか。
まあ、本当に「保守できそうにないコードを書く人」の場合だけど。
0297デフォルトの名無しさん
2006/02/28(火) 12:08:54それ以前に数年前の自分の書いたソースに修正を加えられないとか1行直すだけなのに数ヶ月掛かりますとかアホか
鶏じゃないんだ一度書いたら忘れるな
0298デフォルトの名無しさん
2006/02/28(火) 12:30:060299デフォルトの名無しさん
2006/02/28(火) 12:38:50一行直すだけなら、自分でやればいいのに。
0300デフォルトの名無しさん
2006/02/28(火) 12:41:26＞鶏じゃないんだ一度書いたら忘れるな
神
俺なんか三日前の夕飯も思い出せない。
＞数年前の自分の書いたソースに修正を加えられない
何がおきるかわかんないからね。ソースを書き直すのより
本当はテストの手間を惜しんでるんだと思う。
0301デフォルトの名無しさん
2006/02/28(火) 15:16:17そこは責任範囲とか言う大人の事情って奴ですよ
0302デフォルトの名無しさん
2006/02/28(火) 22:30:18丸一日前のレスにレスするんだから、お前こそ落ち着いて書けよ。
>>295
そこで腹立てるぐらいなら、なんで最初のコードを受け入れる時
に文句を言わないのかと。
まあ、程度問題だからこれ以上は具体的なコードとかがないと何
もわからんけどね。
0303sage
2006/03/01(水) 03:51:07夕飯は忘れても良い。
でも、自分が書いたソースは忘れない。プロならば。
0304デフォルトの名無しさん
2006/03/01(水) 04:37:53それは、そういう規約を作らないとダメ
技術者個人の力量に任せていては保守のしやすいコードにはならない
0305デフォルトの名無しさん
2006/03/01(水) 06:04:57暇なんですね
0306デフォルトの名無しさん
2006/03/01(水) 09:55:28プロは、自分の記憶なんてあてにしない。
0307デフォルトの名無しさん
2006/03/01(水) 12:50:22コメントはそのためにもある。
0308デフォルトの名無しさん
2006/03/01(水) 12:53:21自分の記憶は他人と共有できないしｗ
0309デフォルトの名無しさん
2006/03/01(水) 13:18:01もちろん俺も書かない。
0310デフォルトの名無しさん
2006/03/01(水) 13:26:56コメントを適切に埋めておけばDoxygenが作ってくれるから自分ではドキュメントを書かない。
0311デフォルトの名無しさん
2006/03/01(水) 13:57:02プログラムが、どのような業務・役割を担っているかっていうＳＥレベルの書類は書くけど、
ソースコードがどのような設計になっているかっていうプログラマレベルのはあんまり書かないなぁ。
大体、技術屋だと見てくれないし。まずコードから見やがるし。
共通関数作るとか、ネットワーク処理で独自のプロトコル作るっていうなら書くが。
0312デフォルトの名無しさん
2006/03/01(水) 14:00:32規約つくっても、下手なコード書く奴いるじゃん。
５００行足らずで書けそうなコードを、１０００行とか２０００行とか書く奴。
もう最近はおっさんになったので３００行以上超えるソースは見る気しない。
0313デフォルトの名無しさん
2006/03/01(水) 20:37:130314デフォルトの名無しさん
2006/03/01(水) 20:38:07百イラネ
0315デフォルトの名無しさん
2006/03/01(水) 20:43:340316312
2006/03/01(水) 22:04:50あっ、１ファイル＝３００行っていう意味ね。
ファイル数はいくらあってもいいけど。
最近は関数も４０行超えると見るのだるい。駄目だ俺。
0317デフォルトの名無しさん
2006/03/01(水) 22:28:08メソッド内のロジックを図化する仕掛けはないからな。
関係を理解するのも面倒臭い。
0318デフォルトの名無しさん
2006/03/02(木) 11:45:590319デフォルトの名無しさん
2006/03/02(木) 12:04:15昔見たけど、アレ使えネ
0320デフォルトの名無しさん
2006/03/02(木) 14:58:18を使え
0321デフォルトの名無しさん
2006/03/02(木) 15:23:20書いても自分も含めて誰も読まないし。
最近は成果物にドキュメント不要の会社が増えたような気がするけどどう？
0322デフォルトの名無しさん
2006/03/02(木) 17:06:05PGと対応するドキュメントはソースからの生成で可って会社は増えたね
どうせ顧客側は見ないと言うか、見ても解らないってのが本音だろうが
0323デフォルトの名無しさん
2006/03/02(木) 20:21:07ソースコードから生成すべきである。
ソースコードに対しての補足ドキュメントが必要なら、
それはソースコードに書くべきである。
0324デフォルトの名無しさん
NGNGそれっぽい話があったね。
まさにJavadocやXDocletのことだね。
0325デフォルトの名無しさん
2006/03/03(金) 21:18:27共通化って考え自体が間違っている。
その仕様を明確にして関数なりメソッドなりを書く。呼び出し側の事など気にせずに。コンパクトに。
そしてそれが、再利用されるだけ。
0326大根
2006/03/03(金) 21:19:49リファクタリングうんぬんじゃなくて、共通化の線引きのコツを聞いてるんだった。
”最初”にどうやって設計するかを。
0327デフォルトの名無しさん
2006/03/03(金) 21:29:130328デフォルトの名無しさん
2006/03/03(金) 21:51:16”必要になってから”でも設計変更できるんじゃね？
0329デフォルトの名無しさん
2006/03/03(金) 21:59:26共通処理を書いていて「だるっ」って気分になってきたらたいていやり過ぎ。
そのまま継続してもどうせ無駄なので、すっぱり捨てて観点を変える。
0330デフォルトの名無しさん
2006/03/03(金) 22:18:10初回からまともな設計をするのは困難ゆえ
リファクタリングが発明されたと思う。
0331デフォルトの名無しさん
2006/03/04(土) 00:45:08激しくその通りなんだが、それに付いて来れる人は、多分少数派
最初からカッチリ決まってないと、コード書けない人意外と多い
0332デフォルトの名無しさん
2006/03/04(土) 00:48:27設計意図を守るのが難しくなったら、意図に沿わないコーディング
するんじゃなくて、設計からやり直すこと。
0333デフォルトの名無しさん
2006/03/04(土) 01:00:21ひとりで作っている分にはそれでいい
0334デフォルトの名無しさん
2006/03/04(土) 01:04:29いったことあるな
0335デフォルトの名無しさん
2006/03/04(土) 01:08:32共通化でなくて機能設計
なんでも共通のプログラムにすればいいというものではない
0336デフォルトの名無しさん
2006/03/04(土) 01:13:170337デフォルトの名無しさん
2006/03/04(土) 01:16:52確かにコーディング量は減らせるかもしれないけど、それも最初のうちだけ。
いろんなところで「共通化処理」を行ってるとそれだけ結合が増えるわけで、
修正が難しくなるし。
どちらかというと機能・モジュール間の独立性を高める方向で設計する方が
修正も楽だし、別のプロジェクトでも部品として組み込みやすくなる。
0338デフォルトの名無しさん
2006/03/04(土) 01:22:020339デフォルトの名無しさん
2006/03/04(土) 01:24:15コーディング量を減らすのが目的ではないが、きちんとした機能設計をしてあれば
結果的にコーディング量は減る
0340デフォルトの名無しさん
2006/03/04(土) 01:28:35糞が書くとどうしてもコーディング量が増える
0341デフォルトの名無しさん
2006/03/04(土) 01:42:55すべてをちゃんと把握できれば、きちんとした機能設計が出来る。
0342デフォルトの名無しさん
2006/03/04(土) 01:44:140343デフォルトの名無しさん
2006/03/04(土) 01:46:54最小の労力でシステムが作れる。
0344デフォルトの名無しさん
2006/03/04(土) 12:28:48結果的にコード量は増えることもあるが、トータル労力はたいてい減る。
ただ、例えばデザパタを使ったとき、全く分からない人間というのはいるもので、
そういう人間があとでメンテナンスするときはトータル労力が増えるかもしれない。
要は私にとっては単純に見えることが、
その人にとっては複雑に見えるということだが。
0345デフォルトの名無しさん
2006/03/04(土) 12:48:38初心者の頃に受けた
「できるだけ共通化して作業量を減らし、
不具合の修正も一箇所で済むようにしましょう」
という教育に捕らわれているからでは。
0346デフォルトの名無しさん
2006/03/04(土) 14:45:41捕らわれてるってあーた・・・。
共通化大嫌い、コピペ大好きなやつとは、正直仕事をしたくない。
0347デフォルトの名無しさん
2006/03/04(土) 15:09:47複雑なものはなるべく作らない
0348デフォルトの名無しさん
2006/03/04(土) 16:02:220349デフォルトの名無しさん
2006/03/04(土) 16:46:340350デフォルトの名無しさん
2006/03/04(土) 16:47:350351デフォルトの名無しさん
2006/03/04(土) 18:25:340352デフォルトの名無しさん
2006/03/04(土) 22:18:22ファウラーいうところのトランザクションスクリプトで開発するの止めるか
またはトランザクション毎に担当者をかえるの止めるかすればよくない？
類似ロジックがあるからコピペしたくなるんだろうし。
0353デフォルトの名無しさん
2006/03/05(日) 02:31:29悩むくらいなら、コピペで良いよ
あっという間に生産性が数倍になるし
0354デフォルトの名無しさん
2006/03/05(日) 02:40:26コーディングが終わったらリファクタリングせよ
0355デフォルトの名無しさん
2006/03/05(日) 03:07:13そうしたいのは山々なんだけど
現実的には・・
手間隙掛けてコード綺麗にしても、ステップ数減って
青果物が少なくなって怒られかねない
0356デフォルトの名無しさん
2006/03/05(日) 03:17:17コメント率上げとけ
目標は80％だ
0357デフォルトの名無しさん
2006/03/05(日) 03:22:21その考え方はやばいな。ステップ数＝値段か？あんま仕事したくないタイプだ。
ステップ数で金勘定する依頼主も依頼主だと思うがな。さほどの目的もなく開発依頼だしてそう。
>>356
８０％はすごいな。コメント率３５％以上は超えたことないぞ
0358デフォルトの名無しさん
2006/03/05(日) 03:42:38ステップ数云々の所ならPG設計書が有るだろうからその詳細説明の内容を関数・サブルーチンのヘッダコメントとして貼り付けるんだ
そうすりゃあっという間に８０％
0359デフォルトの名無しさん
2006/03/05(日) 04:01:46必要なのはif (hoge) hage()の撤廃だ
if (hoge)
{
hage();
}
ほら4倍
0360デフォルトの名無しさん
2006/03/05(日) 04:02:57int boke(
int a,
int b,
int c)
{
}
0361デフォルトの名無しさん
2006/03/05(日) 09:24:54その昔ループを展開するツールまであったそうな。
0362デフォルトの名無しさん
2006/03/05(日) 09:36:13ブラッシュアップさせるのは当然だ。
適切に絞られた状態でどれだけステップ数があっても、払うことに
やぶさかではない。
0363デフォルトの名無しさん
2006/03/05(日) 09:41:20俺、ステップ数の数え方すら知らんわ
0364デフォルトの名無しさん
2006/03/05(日) 10:09:45まだ行数で値段を決めてるのか。
そんなんだから舐められるんじゃないか？
0365デフォルトの名無しさん
2006/03/05(日) 12:57:23例えばバグ残数の見積もりとか。
定量的データの１つであることは間違いないんだし。
0366デフォルトの名無しさん
2006/03/05(日) 13:01:270367デフォルトの名無しさん
2006/03/05(日) 13:15:51まあ逆に、そのバグ残数の見積もりと極端に合わなかったときが大変なんだけどね。
バグが少なすぎるとテストケース増やしたりしないといけないからね。
開発者によってバグの発生数なんて変わるんだから、変な平均値に合わされても困るぜよ。
0368デフォルトの名無しさん
2006/03/05(日) 13:20:29たかが一時の１０万円、２０万円のためによくがんばるなぁ。
それで後で保守やバグ対応で、修正に時間かかってたら稼いだ分がチャラになるわけだ。
…あほくさい。
0369デフォルトの名無しさん
2006/03/05(日) 13:29:01「文言がわかりにくい」とか、「ログ出力でスペルミス」とか
プログラム的にはどうでもいいようなことをバグとしてカウントしてたな。
0370デフォルトの名無しさん
2006/03/05(日) 13:38:020371デフォルトの名無しさん
2006/03/05(日) 13:46:20改善点があるということは、自分の評価を上げるチャンスでもあるわけだし。
その会社を見切るという手もあるしな。
まぁうまく立ち回るだわ。
0372デフォルトの名無しさん
2006/03/05(日) 13:47:11似たようなコードがあればそれをコピペと判断し、
コピペ率が〜だと評価を下げる。
0373デフォルトの名無しさん
2006/03/05(日) 13:48:380374デフォルトの名無しさん
2006/03/05(日) 13:49:000375デフォルトの名無しさん
2006/03/05(日) 13:52:310376デフォルトの名無しさん
2006/03/05(日) 13:53:15コンパイラから見れば変数名なんて
なにも意味はありませんよ。
0377デフォルトの名無しさん
2006/03/05(日) 13:55:43そんなことをしてもコード自体は似たようなものになる。
あくまで似たようなものであって、同じものである必要は無い。
0378デフォルトの名無しさん
2006/03/05(日) 13:58:31じゃあ…
・コピペしたコード内からコピペ用ダミー関数（500個くらいある相互に呼び出し合う複雑な関数群）を少なくとも３つは呼び出すこと！
よし、これでばっちりだな。
0379デフォルトの名無しさん
2006/03/05(日) 14:04:57そうか？ 例えば次の２つの関数がどちらも２変数の加算だって判定できるか？
int FUNC_F12345A(int a, double b, int c){
if(double>0) return a+b;
else return a-b;
}
int F123_NO01(struct LIST* head, int length, int index){
struct LIST* p=head;
while(head->next){
if(head->value==index) break;
}
if(head->next) return value+length;
return length;
}
0380デフォルトの名無しさん
2006/03/05(日) 14:10:37今、コピペが悪いという話をしているんだよな？
実際にそれを見て、そのコードがコピペだからやめろというか？
実際にそのコードを”コピペで”作る奴いるか？
0381デフォルトの名無しさん
2006/03/05(日) 14:11:37コピペにそこまで手間をかけることを要求すれば、コピペを自然としなくなるだろｗ
0382デフォルトの名無しさん
2006/03/05(日) 14:14:56doubleって何？
>if(head->next) return value+length;
valueって何？
>判定できるか？
できません
0383デフォルトの名無しさん
2006/03/05(日) 14:18:240384デフォルトの名無しさん
2006/03/05(日) 14:20:280385デフォルトの名無しさん
2006/03/05(日) 14:41:070386デフォルトの名無しさん
2006/03/05(日) 15:25:58コピペチェッカならぬ重複コードチェッカならあるぞ
http://www.redhillconsulting.com.au/products/simian/
0387デフォルトの名無しさん
2006/03/07(火) 21:43:58やり方や状態にもよるが
むしろ、必要になってから変更できることは
最適化のほう。
0388デフォルトの名無しさん
2006/03/07(火) 21:44:53チームで開発するときは勘だけじゃつらいな。
チームがやりそうなことを推測する勘ならわかるが。
それもチームと事前にしっかりとコミュニケをとってくることで
0389デフォルトの名無しさん
2006/03/07(火) 21:48:19> 共通化なんてわざわざ考えない。
> 確かにコーディング量は減らせるかもしれないけど、それも最初のうちだけ。
> いろんなところで「共通化処理」を行ってるとそれだけ結合が増えるわけで、
> 修正が難しくなるし。
ちゃんとオブジェクト指向の真価と特性を生かしてないだけだろ。
入力と出力のことしか考えてないで
データに着目すべきだと思うが。
0390デフォルトの名無しさん
2006/03/07(火) 21:51:36そんなのがあるのか
漏れとしては
CheckStyleやFindBugsに、
コードを綺麗にしてくれる有り難みを感じる。
0391デフォルトの名無しさん
2006/03/07(火) 21:55:23Eclipse のメトリクスプラグイン、
CAP - Code Analysisプラグインを使って
その判定結果で減額の対象にすると面白いだろうな
0392デフォルトの名無しさん
2006/03/09(木) 14:14:000393デフォルトの名無しさん
2006/03/09(木) 14:48:04考えるからそりゃ共通化が難しいだろう。
リソースがたっぷりありゃ
区切りが簡単でどんどん共通化しまくれる。
0394デフォルトの名無しさん
2006/03/09(木) 17:05:49この場合は、当初の共通化の設計自体がまずかったという可能性が高いのかな？
完璧に粉々にプリミティブな共通クラスを作っておけば大丈夫なはず、とか？
0395デフォルトの名無しさん
2006/03/09(木) 23:01:11あとから共通化を簡単に行うことができるケースもある。
0396デフォルトの名無しさん
2006/03/10(金) 02:51:370397デフォルトの名無しさん
2006/03/10(金) 04:57:46インターフェースに変更がなければ大成功
共通化（＝部品化）のメリットのひとつは、仕様変更にともなうプログラムの変更作業を
局所化して全体にその影響を及ばせないことにある。
0398デフォルトの名無しさん
2006/03/10(金) 07:55:16巧く部品化できていれば、違う部品が必要なときにそれだけ作れば済む。
全体を修正する愚を避けられれば上出来。
違う部品が必要なのに、部品化に自信を持ち過ぎてその部品だけで
違いを吸収しようとすると、部品の肥大化、保守効率悪化を招くので注意。
0399デフォルトの名無しさん
2006/03/10(金) 09:46:56厳しいところだと別だが、そのレベルになるとコンパクトになるので
保守性とかあまり関係なくなるしね
まああれだ、大きなシステムなら、アプリケーションの仕様変更
ごときでコンパイルし直しになんかならんように作れ
0400デフォルトの名無しさん
2006/03/10(金) 10:17:10「全体が」とかって言葉が抜けてないか
0401デフォルトの名無しさん
2006/03/10(金) 18:12:580402デフォルトの名無しさん
2006/03/11(土) 00:04:54http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel
サービスレイヤが分厚過ぎるから身動きがとれなくなるのではなかろうか。
サービスも必ずxUnitでテストするルールにしておけば、ある程度レイヤの
厚さは揃うと思う。
0403デフォルトの名無しさん
2006/03/13(月) 02:43:27一年生⇒二年生は少しの経験で上がれるが、二年生⇒三年生に上がるには、自分である程度の設計をやって、失敗し、失敗に学ぶしかない。
一年生コーディング：
・ロジックがシンプルでない
・超ハードコーディング
・同じことを何回も書く
二年生コーディング：
・ロジックがシンプルである
・脱ハードコーディング。
・同じことは共通化する。しかし、同じでないことまで無理に共通化し、結果的にぐちゃぐちゃなプログラムになる。
三年生コーディング：
・ロジックがシンプルである
・脱ハードコーディング。
・同じことは共通化する。同じでないことは個別に分ける。結果としてメンテナンス性の高いプログラムができる。
0404デフォルトの名無しさん
2006/03/13(月) 11:34:41参考URLありがとう。
読んでみたけど、オブジェクト指向のこのような記事って、いつも具体例の提示が無いんだよね。いつも「それは真のオブジェクト指向ではないからだ！真のオブジェクト指向ではそのような問題は起こらないはずだ！」で終わっている。
実際に大規模なシステムをオブジェクト指向設計でこう書き直したらみんなハッピーになった、というような実例が欲しいんだけど、いつも机上の空論にしか見えない。例を出してもちょことちょこととして小規模のものだけだし。
「真のオブジェクト指向ではそのような問題は起こらないはずだ！が、他の問題が起こってくる。そしてあっちを立てればこっちが立たず・・・・」というところが現実なんじゃないかなと思ったりする。
どうよ？
0405デフォルトの名無しさん
2006/03/13(月) 11:49:03真のオブジェクト指向を実現するにはすべての開発者とユーザーがオブジェクト指向を等しく、正しく理解してないとダメなんだろうな
0406デフォルトの名無しさん
2006/03/13(月) 12:12:08なぜユーザーまで？
0407デフォルトの名無しさん
2006/03/13(月) 12:54:44http://ml.seasar.org/archives/seasar-user/
http://ml.seasar.org/archives/seasar-dev/
獄長(Koichi Kobayashi)絡みのとこを中心に追ってみるといい。
http://lists.sourceforge.jp/mailman/archives/seasar-user/2005-June/thread.html
ここのやり取りは獄長とマヤー神という非常に豪華な顔合わせで
俺はもう100回くらい読み返してる。
文頭を1-2行読めば、残りを口調まで含めて暗唱できるくらいｗ
OSSのコミッターが集まるMLは下手な書籍の1M倍参考になるん
でお勧め。
0408デフォルトの名無しさん
2006/03/13(月) 13:05:01悪いが自分の言葉で要約とかできないのか？
seesarってよく知らないけど、Framework？
Frameworkってシステム全体から見たら局所だが、これに引きずられて全体も無難にオブジェクト指向的になるという意図でいいのかな？
.NET Frameworkで書けば、システム全体が.NETの思想で無難に・・・・
とか考えるとありえないし、ここでseesarを持ち出してる意図がわからない。
seesar内部という局所では、美しいオブジェクト指向なのかもしれんけどね。
0409デフォルトの名無しさん
2006/03/13(月) 14:02:34信者が教祖を敬うのは当たり前すぎてまったく参考にならない
日本のOSS文化とかが閉鎖的になりがちなのはすぐに教祖と信者の見たいな関係になるから
言ってる事は判らないでもないが、その関係に巻き込まれたくないってのが回りの見方
0410デフォルトの名無しさん
2006/03/13(月) 22:03:17そうなんだけどある程度時流に乗っていかないと世間で生み出されている
新しいソリューションの恩恵にまったくあずかれないってことになってしまうし。
まあ今考えるとDIコンテナもテストフレームワークもなかった時代の
OOPの生産性が構造化設計のときより高かったかっていうと結構疑問かも。
0411デフォルトの名無しさん
2006/03/13(月) 22:15:14フレームワークっていうもの自体の制約でコードが全体として
美しいオブジェクト指向でなくなることはあっても逆はあまりないんじゃないかな。
ただしDIコンテナはそれ以外のフレームワークよりも、開発者がコードをオブジェクト指向的で
あらしめようとする努力を阻害しないというか、オブジェクト指向の恩恵を受けやすくする。
0412デフォルトの名無しさん
2006/03/14(火) 09:43:30その「新しいソリューション」に本当に価値があるなら良いんだけど、
中身の構造がオブジェクト指向になっただけでできることは同じ、
とかで他との相互接続性のためだけに入れ替える羽目に、
とかだとエンドユーザは浮かばれないよな
恩恵にあずかってるのはシステム刷新でまた金が入るシステム屋だけ、
ってのもどうかと。
だいたい、うたい文句は保守性と再利用が売りのオブジェクト指向のはずなのに、時流が変わったので本の数年で全部入れ替えです、ってどうなのよ？
0413デフォルトの名無しさん
2006/03/14(火) 11:07:08ってのはどっかにスレがあるかもしれんけど。
最初に作るうえでは、
・コンパイルタイムチェックのほとんどが活用できなくなりうざ
・むやみに名前(名前空間)が増えてうざ
他人の作ったものを解析/メンテするときなんて
・オブジェクトの実装がどこにあるのか探すのがうざすぎ
・ひとつのオブジェクトの定義が複数の設定ファイルにちょっとずつ定義されてたりしてうざすぎ
・とにかく設定ファイルばっかし、あほか
・へたくその作った DI 使用のシステムなんか、コーディング/設計の意図が読めなさ過ぎ
普通に型システムを活用して作ってくれてるほうがいい
唯一じゃないかとすら思える利点が
・テストファーストができる
くらいなんだけど…。大規模で未成熟開発者割合が多い場合はまた違った利点があるかもしれんけど、圧倒的な読みにくさ(追いにくさ)はそれに余りある負の要素じゃないかと思うんだが。
どう考えても作者の「こんなことができるかも」「もしかしたら便利かも」という趣味と妄想の賜物だと思う。
趣旨に戻ると、共通化ってのを意識しすぎるやつはだめコードを書く。先にかかれてた二年生かな。
重要なのは部品化、というよりは粒度の小ささと「独立性」。
DI は依存性を減らすために考案されたってことになってるけど、本質的に依存関係にあるものを無理やり設定ファイルから注入するようにしても読みにくくなるだけってな話だ。
0414デフォルトの名無しさん
2006/03/14(火) 12:53:57俺? 俺はもうぐちゃぐちゃ・・
0415デフォルトの名無しさん
2006/03/14(火) 16:06:13なんていっているのは設計が出来ていないだけだ
それにDIの言っている依存性の軽減もはき違えてるしなぁ。
本来、オブジェクト指向での依存といえば、
あるオブジェクト（A)が、他のクラスのサブクラスもしくはサブタイプのオブジェクトを使用する、
これだけだ。
ただ、それを実装に落とすとどうしても、オブジェクトAはどのサブクラス・サブタイプを
インスタンス化すべきかを知らないといけないことになる。
その依存（どのクラスをインスタンスかすべきか）をなくすのがDIだ。
0416デフォルトの名無しさん
2006/03/14(火) 16:06:46この依存をなくすものではないよ。DIは。
0417デフォルトの名無しさん
2006/03/14(火) 17:16:39その通りに書いてあるように見えるが。
0418デフォルトの名無しさん
2006/03/14(火) 17:49:11少なくとも DI フレームワークを使っていて追いやすいものを見た覚えはないよ。
みんな設計できてないんだねぇ。
ってまぁ、たいして見たわけでもないけどさ。今のところ使いたいとは思えないな。
＞あるオブジェクト（A)が、他のクラスのサブクラスもしくはサブタイプのオブジェクトを使用する、
＞これだけだ。
あたりまえ。
＞その依存（どのクラスをインスタンスかすべきか）をなくすのがDIだ。
だから、それを設定ファイルとかに過剰に書くから追いにくいといっている。
もちろん自分だって実装クラス名を設定で与えるような設計をすることはある。
ただし、設定で実装を指定するようなものの数を極力減らすのがよい設計だと思うけどね。
spring とか使ってるプロジェクトの中身を見ると結構悲惨だったよ。
0419デフォルトの名無しさん
2006/03/14(火) 18:08:55インターフェイスの依存が排除できないのは当たり前。
# adapter などのことはより話がややこしくなるので除外
で、実装の依存を排除したいのはわかるが、実装のバリエーションが想定すらされていない段階からそれをやろうとするやつが多くて困るってことさね。
テストファーストのためだけだったりすると萎えまくりだ。
部品単体の中身の見通しがよくなっても流れがわけわかになってる。
ま、大体そういうコードはインターフェイス仕様を決める段階で間違ってんだけどね。
0420デフォルトの名無しさん
2006/03/14(火) 18:36:320421デフォルトの名無しさん
2006/03/14(火) 18:38:15＞インスタンス化すべきかを知らないといけないことになる。
＞その依存（どのクラスをインスタンスかすべきか）をなくすのがDIだ。
お勉強でなぞなぞやってるんじゃないから、なくした場合の成果をまず書くべきだろう。
オブジェクト指向に取り付かれている人は、よく「美しく実装できる」とか、現場が本来求めていない帰結に達するときがあるので、着地点のアピールはきちんとした方が良い。
で、前半部分だが、オブジェクト指向にしたから出てきた問題なんじゃないの？
すまんが、俺理論で作ったら行き詰まったので俺理論・改を考案した！以上の意味には取れなかった。
0422デフォルトの名無しさん
2006/03/14(火) 21:23:42設計のときに書くクラス関係図とコーディングの時に書くnewを
別のConfigファイルに書くもの
みたいな意識しかなかった。
だからクラスの呼び出し先が変わったりしたときにコード部分をいじらなくて済みますよと。
0423デフォルトの名無しさん
2006/03/14(火) 21:50:12Spring- IDEを使え。
っていうかpackageが増えてどういう問題があるのか
0424デフォルトの名無しさん
2006/03/14(火) 23:00:32「名前空間が増える」の意味を勘違いしてないか？
0425デフォルトの名無しさん
2006/03/14(火) 23:05:29クラスの呼び出し先が変わるときは普通コードがかわるっしょ。
呼び出すクラスを変えるとき、だよね？
で、呼び出すクラスを変えることがどの程度の頻度でおきるのか、とね。
ちなみに、運用時でも切り替えられるところを売りにしていたふしもあったように思うけど、
運用時に spring の設定ファイルだけを変えて駆動させるクラスを切り替えるという
需要自体があまりない(*)上に、ほぼ切り替えの対象にならないものまで
いっぺんに書かれた設定ファイルは運用者にはまず理解できまい。
*:ないわけではない。むしろ運用者に切り替えさせることに意味のあるケースも多い。
問題はそういうものとそうでないものをきちんと分けて設計されないケースが
多くなってきていること。
0426デフォルトの名無しさん
2006/03/14(火) 23:15:29よーしらんけど。
あと設定ファイルは分割できんの？
0427デフォルトの名無しさん
2006/03/14(火) 23:37:11どっちかというと下手に使うというか、喜んで過剰に使う人が多いなと思う。
で、>>423 とか >>415 みたいに(テストファースト以外の)具体的な利点を書けない人と
違って >>422 とかはまがりなりにも便利と思った点を書いてくれてるのでそこを意識すると、
「設定ファイルを見ることでクラスの関係がわかる」みたいな話もどっかで見た覚えはあるね。
struts とかかｗ。あれも破綻してたけど。
結局設定ファイルを変えるだけでどうにかなるような修正要求なんてほとんどないでしょ。
それは別の話としても、見通しがいいかというと、設定ファイルに書かれるのは実装クラス
であってインターフェイスではないし、その設定ファイルを書くために必要な情報、つまり
どのインターフェイスの実装クラスを書けばいいのかとかどのプロパティがセット可能なの
かとかが簡単にたどれないという点で大きなロスがあると思うんだがその辺はどうなんだ
ろね。springIDE なるものはそんへん解決してくれてるの？
すでに書かれた設定ファイルを見る/修正するにせよ、新たに設定ファイルを書かなければ
ならない立場にせよ不都合のほうが多いと思うわけよ。
interface なら型保障されてるのに設定ファイルは型保障されてないっしょ。
0428デフォルトの名無しさん
2006/03/14(火) 23:53:18コードの読みにくさは「やりたいこと(設計)」「する必要があること(実装)」が
入り混じることに原因があり、コードの改造に伴い設計が腐っていくのは「する必要が
あること」のコードの変更が「やりたいこと(設計)」のコードに影響を与えることに原因が
あると考えるとDIは設計のコードを実装のコードの分離を促進することから、新規で
コードを書くときも既存のコードを改造するときもメリットがあるとおもうんだが。
0429デフォルトの名無しさん
2006/03/14(火) 23:55:39「美しく実装できる」＝見やすく改造に強いコード
って言う意味であれば、まさに「現場」が求めていることそのものなんじゃなかろうか？
0430デフォルトの名無しさん
2006/03/14(火) 23:59:160431デフォルトの名無しさん
2006/03/15(水) 00:14:25一番腹が立つのは他人の書いた DI 使ったコードの改造だが、それはいったん置いといて。
「やりたいこと(設計)」ってのはなんだか変でないかい？
どこまでを「設計」と呼ぶかの解釈の違いかもしれないけど、
自分はコードに近いところの設計＝クラスの関連とインターフェイス
あたりのレイヤで考えてるが、それって「やりたいこと」じゃないっしょ？
設計ってのは大雑把に言えば役割と責務を決めることっしょ？
さて、「インターフェイスと実装を分けて作るようになることが期待できる」
という意見と解釈したが、それをインターフェイス設計のできない人間に対して
適用しても、いっそうぐちゃぐちゃになると思いませんかい？
インターフェイス設計ができる人間は DI なんぞ使わなくても必要な箇所は
インターフェイスにして不要な箇所は static メソッドなり単体の entity 的な
クラスにするなりできるのよ。
injection に相当する部分は、*それが本当に実装クラス名を埋め込むとまずい
場合に限り*、外部パラメタで実装クラスを切り替える factory なりを経由させるでしょうて。
どんなクラスにも interface が作られている状況って、最近の OO 信仰者にはうれしいんだろうか？
0432デフォルトの名無しさん
2006/03/15(水) 00:21:58springIDEで、bean同士の関連図見たいなものを表示すること、図中のbeanを
クリックすることによるソースコードへのジャンプ、設定ファイルエディタによる
設定可能インタフェース(の実装クラス)やプロパティの候補表示あたりは実現されてる。
0433デフォルトの名無しさん
2006/03/15(水) 00:23:44それと、設定ファイル上のbean参照の型チェックもやってくれる。
0434デフォルトの名無しさん
2006/03/15(水) 00:33:58DI の概念が役に立つケースを上げておくと、既に
>>418 や >>425 >>431 でもさわりを書いたけど、
・多数の振る舞いを区別なく、切り替えやすい形で提供する(メニューリストとか)
・異なる環境で同じ振る舞いを保つために実装を切り替える(データソースとかテストケースとか)
ような場合。
つうかまぁ以前からやっていたそういうことに
DI という名前が付いたものだと思ってるから当たり前だけど。
# 念のため。批判的なのは DIDI と喜んで使いたがる連中に対してさ。
で、意味ねー、ってか害だと思うのは実装が一個しかないことが現時点で確定しているものに
いちいち interface を作って、それだけならたいした問題じゃないが、実装クラスをわざわざ
ぜんぜん違う場所にある設定ファイルに書いて、さらにその初期化にあたるプロパティのセット
まで設定ファイルに書いちゃうという愚行とか。
「分離できたこと自体に意味がある」って、こんなのがずらずら並んでて、初期化が全部そこに
固まってるならともかく、一部クラスはコンストラクタやどこからともなく呼ばれる
init 系メソッドで初期化コードを書いてた、とか、DI じゃなくても解釈が面倒なコードを
いっそう読みにくくされてたら腹も立つって物さ。
なんであれ使う人間の問題なのだが、DI コンテナは使う人間に問題があった場合に
使っていなかった場合以上に修復可能性を減らすとは思っているよ。
0435デフォルトの名無しさん
2006/03/15(水) 00:39:04type属性まで入力すると、子要素のプロパティとして指定できる候補や
各プロパティ値として記述できる reference 名なり実装クラス名の候補が
出せるってことよね？
書く手間に関してはこの辺のインスペクタが充実すればだいぶましになるだろうね。
読む側のサポートは関連図ね。うーん、自分は図よりコードのほうが理解しやすいタチ
だから図の出力にあまり利便は感じないけど、たぶん spring 使うにはほぼ必須ツール
っぽいね。
んじゃそろそろ本題へと…ってだいぶスレ違いだな…
0436デフォルトの名無しさん
2006/03/15(水) 01:16:11だれも突っ込んでないようだが、
DI使うと、型システムのどの辺りが活かせなくなるのか？
まあ、コストが実利に見合うかっていう疑いは大事だけどね。
ただ、それは特定の技術だけではそれは決まらなくて、条件によって大きく変わるわけだ。
実行しなくても自動的にエラーをガンガン見付けてくれる型システムも、
数十行の書き捨てスクリプトではウザイだけ、とかね。
0437デフォルトの名無しさん
2006/03/15(水) 01:52:07# 書きかけが消えたorz 面倒なので本題だけ
クラスの関係が変な設計になっているようなものをリファクタリングするのに
苦労するってのがもともといいたかった一番の問題。
普通に Java コードで閉じていれば相当変な設計のものでもリファクタリング
できる自信があるが、DI のようなものが多用されていると、どこから参照され
ているかを意識しながら変更するのに異常に神経を使う。
バグ混入率高く、発見しにくいだろう。
テストファーストならリファクタリングできるって？
クラスの構造からおかしなものについてテストファーストで書かれてたら
いっそうリファクタリングに苦労しそうだ。
ま、これも「設定ファイル」が Java のコードとシームレスに検証/検索できるよう
になれば変わってくる話だとは思うがそんなんになると重量級IDEでしか開発
できなくなってつまらんなぁ。
0438デフォルトの名無しさん
2006/03/15(水) 02:04:33DI 関係のフレームワークを作っている開発者のことを貶す目的はまったくありません。
賞賛します。
# 煽り口調はここが2chだからということとそのほうが反応がきやすいから、など。
# spring の ActionProxy とかはちょっとなぁとか、細かい点ではいろいろ思うけどね。
自分のやり方を公開する予定も無く、現状コミュニティに入ってまで方向性を
変えさせようという余力のない状態で努力自体を貶したいわけではない。
また、それに乗っかる人自体もOSSが盛り上がるためには必要と思っている。
今日ここに書いたのは、まぁ結局愚痴みたいなものだけど、とりあえず DI も
OO と同じく銀の弾丸では無いんだってことを盲目的な利用者方面に伝えたい、
ってところ。喜んで使うんじゃなくて使う必然性のあるところで使ってくれよ、と。
んじゃ。
0439デフォルトの名無しさん
2006/03/15(水) 09:09:22＞DI コンテナ使うシステムが数十行の書き捨てで作れたらいいのにね。
>>436の答えになってないし、>>436はそんなことひとつも言ってないんだが。
それに、DI使うとリファクタリングがどうやりづらくなるのかが解らん
0440デフォルトの名無しさん
2006/03/15(水) 10:52:400441デフォルトの名無しさん
2006/03/15(水) 13:24:56最近のオブジェクト指向って、設計と実装の間に溝がないかい？
設計だけやってあと知らねーっていう高給取りが増えて、今後もそういう人材が求められてるらしいけど、その手の設計って実装に素直に落ちにくい気がする。
UMLからソースコードジェネレートとかいう話も聞くけど、実際に見込みはあるんかねー。
将来はコンサルタントが要件定義したら後はできあいの部品を繋ぐだけで実装できるようになるから、実装屋はいらない！コンサルタントに上がれない無能は氏んでね！
って話もよく見る。
0442デフォルトの名無しさん
2006/03/15(水) 14:16:10所謂コンサルタントやＩＴ企業の経営者はプロジェクトが動く事により金を得ているのですんなり完成するプロジェクトは悪とみなしている
0443デフォルトの名無しさん
2006/03/15(水) 19:43:58顧客の我慢の限界ぎりぎりのところまで工数を引き伸ばして金を搾り取るのが常套手段。
0444デフォルトの名無しさん
2006/03/15(水) 20:13:560445デフォルトの名無しさん
2006/03/15(水) 20:29:45たいていコーディング・テストのフェーズあたりで実装できる人を
集めるから大変なことになる
0446デフォルトの名無しさん
2006/03/16(木) 05:09:37UML=うそつき丸め込み用ランゲージ
でｵk？
0447http://www.vector.co.jp/soft/win95/util/se072729.html
2006/03/18(土) 19:56:10もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
0448デフォルトの名無しさん
2006/03/21(火) 13:36:34大抵か、そうでもなかったり。
社内に机が汚い香具師がいるが
ソースコードだけは綺麗。
つまり、現実世界では汚いが
コンピュータの中では綺麗。
あてにならないもんだね。
性格がだらしなさそう、面倒くさがり屋な
香具師はたしかにソースコードも汚いし
オブジェクト指向も勉強しようとしない
0449デフォルトの名無しさん
2006/03/22(水) 08:11:580450デフォルトの名無しさん
2006/03/22(水) 08:41:13普通パッケージと言ったら名前空間のことだろ
もう世界の常識
0451デフォルトの名無しさん
2006/03/22(水) 09:19:15名前空間はNamespace
0452デフォルトの名無しさん
2006/03/22(水) 13:26:02あと、日本語で書くのがミソ
0453デフォルトの名無しさん
2006/03/22(水) 15:05:220454デフォルトの名無しさん
2006/03/22(水) 15:10:18UMLでも使われているが
0455デフォルトの名無しさん
2006/03/23(木) 01:44:410456デフォルトの名無しさん
2006/03/23(木) 08:33:460457デフォルトの名無しさん
2006/03/23(木) 10:37:010458デフォルトの名無しさん
2006/03/23(木) 14:12:180459デフォルトの名無しさん
2006/03/23(木) 15:36:370460デフォルトの名無しさん
2006/03/23(木) 20:41:090461デフォルトの名無しさん
2006/03/23(木) 22:52:06C++やC#などとの違いは、一つのファイル無いに複数の名前空間を
定義できないというだけ。
0462デフォルトの名無しさん
2006/03/23(木) 22:53:05ん？実際に作ってるだろ？
作ってアーカイブで隠してるだけのような
0463デフォルトの名無しさん
2006/03/23(木) 23:41:04もちろんつくったほうがクラス名(ファイル名)が被らなくて済む。
パッケージ名は異なるがクラス名は同じというクラスを問題なく
作ることができるから。
0464デフォルトの名無しさん
2006/03/23(木) 23:43:24実際に作るよな？
0465デフォルトの名無しさん
2006/03/23(木) 23:46:45パッケージ／ディレクトリがごっちゃになってるぽ
0466デフォルトの名無しさん
2006/03/24(金) 12:51:20javac以外のコンパイラだとディレクトリ作らなくてもいいやつがあるんじゃね？
0467デフォルトの名無しさん
2006/03/24(金) 13:27:21DOS向けの奴だと、ファイル名＝クラス名である必要は無いな
0468デフォルトの名無しさん
2006/03/26(日) 15:50:24Javaって仕様の塊の事だし。
SunはJavaの仕様に沿った実装を例として配ってるようなもんだし。
0469デフォルトの名無しさん
2006/03/27(月) 13:00:29>Sunが提案した仕様から逸脱したらもうすでにJavaじゃない
「Java」ってのが「Java言語」のことだとしたらそうなんだが
「パケージ⇔ディレクトリ」ってのはSunが提案した「Java言語」の仕様なのか？
もしそうだとしたら，>467の言うようなDOS版は非Javaということになるが
0470デフォルトの名無しさん
2006/03/27(月) 22:13:07「名前空間が増える」だよ。
名前やらパッケージが増えるんじゃなくて。
間接参照が増えるってことよ。あるものを参照するために、
それを指し示す名前(を定義する必要のあるレイヤ)が一段余計に必要になるってこと。
間接参照が多段化すると飛躍的に追いにくくなるでしょ？
0471デフォルトの名無しさん
2006/03/27(月) 22:23:08目先のコードを追っかけるだけじゃ、だめだぞっ。
0472デフォルトの名無しさん
2006/03/28(火) 20:48:08元になるとでも言いたいと？
パッケージの中にパッケージを入れれば
混乱しないわけだが。
『アジャイルソフトウェア開発の奥義』
をみればパッケージ管理も楽になるほうほうが
わかるんでね？
0473デフォルトの名無しさん
2006/03/28(火) 21:56:15そういう考え方する人＝慣れた人が過剰な DI 利用設計をやるんだろうね…。
大体設計フェーズしかできない人間は他人のコードのデバッグも
当然できないからそのときのコスト計算もできないんだろうなぁ。
つうか、それは設計フェーズもできてないってことだけどさ。
あと、ただ理解するという目的であったにせよ、名前空間が
増えているのはやはり本質的によくない。おまけに設定ファイル
ってことで言語まで分かれているわけだし。
まぁ自分は simple 至上主義だから多少偏ってるだろうとは思うが、
DI とか好きな人の中には simple ってキーワードも好きな人が多いだろうに
simple を追求して simple じゃなくしているところが笑える。
(DI の考え方とかじゃなくて喜んで DI フレームワークの機能を無理やり
使おうとするような人のことだよ)
0474デフォルトの名無しさん
2006/03/28(火) 23:13:09コードに埋もれて地虫のごとく這いずり回ってりゃいいだわさ
0475デフォルトの名無しさん
2006/03/29(水) 00:09:33全てのソースコードを1クラスに押し込めれば、名前空間もクラス名もファイルも
1つで済む。だけどそれはsimpleってこととは違う。
simpleを追求すればするほど必要な名前(=概念)や名前空間や設定情報は増えていくよ。
0476デフォルトの名無しさん
2006/03/29(水) 00:29:13> >>473
> 全てのソースコードを1クラスに押し込めれば、名前空間もクラス名もファイルも
> 1つで済む。
トンデモCOBOlerがやったというあのアホ臭い実話か。
今でも似たようなことやる奴がいるからマジでウザイ家ドナ
0477デフォルトの名無しさん
2006/03/29(水) 00:33:05DIフレームワークの機能を使うってところにどうもひっかかりを覚える。
DIが解決するのは仕様とかビジネスルールみたいな厳密な抽象を
コンフィグの取得方法とか永続データのストア方法みたいな曖昧な具象
を分離することじゃなかろか。
要は、なんか即物的なメリットを求めてDIを使うってのは違うような気がするってこと。。
0478デフォルトの名無しさん
2006/03/29(水) 05:12:18それは違うでしょ。もちろん外部から注入されるべき「設定」は増えるが、
simple な「設定構造」にしておかないと現場の普通の人たちがすぐについていけなくなるのさ。
自分が作るなら苦労はしない。本質をよくわかっていない DI 設計厨や、その設計の
おかしさを指摘できるスキルの無いプログラマたちの作ったコードをメンテさせられて
みなって言ってる。
>>477 日本語と用語の意味が取れません。
即物的なメリットを求めないなら、宗教になるよ。
自分はきちんと使うべきところに DI の概念を使うけどね。
0479デフォルトの名無しさん
2006/03/29(水) 06:47:35低脳コーダに囲まれてたいへんれすね！
0480デフォルトの名無しさん
2006/03/29(水) 14:52:37「俺以外のヤツは低脳で使えない」て思ってるやつほど
周りから「あいつは口だけ立派だが仕事をやらせると使えない」
なんて思われてたりしてなｗ
0481デフォルトの名無しさん
2006/04/02(日) 17:01:010482デフォルトの名無しさん
2006/04/07(金) 23:01:12再利用コンポーネントをつくるのはそうでない場合に比べ３倍大変
みたいなことが書いてあった。俺の感触と一緒。
共通化・再利用って言葉は聞いてる分には良く聞こえるけど
ある意味投資だから回収できる見込みがあるか十分検討してからやるべきだと思ふ。
0483デフォルトの名無しさん
2006/04/09(日) 10:45:08多重ループ{
共通処理Ａ
ちょっとだけ違う処理
共通処理Ｂ
}
}
ってあったら皆どうしてる？
状況としては「ちょっとだけ違う処理」のバリエーションを
たくさん作りたい。
多重ループ内で関数呼び出しコストももったいない。
共通処理はそれなりに記述行数はある（インライン
asm含む）
環境はＶＣ６。ぱっと思いつくのは共通処理ＡＢをファイル分けて
includeするくらい。defineしようにもインラインasm含んでると
うまくいかん…。
テンプレートとかでやりようがあるでしょうか？ いまは素直に
たくさんサブルーチンをコピペで作ってますが、メンテがしんどい
0484デフォルトの名無しさん
2006/04/09(日) 11:14:07「ちょっとだけ違う処理」の数だけサブルーチンを作りたいのか?
サブルーチンは一個で「ちょっとだけ違う処理」の数だけ分岐したいのか?
いずれにしても、関数呼び出しコストが問題になるような状況でメンテ云々を言っても意味ないと思うが。
0485デフォルトの名無しさん
2006/04/09(日) 11:22:56は、リーリス版で性能比較した結果を受けての判断だよな？
「ちょっとだけ違う処理」はサブルーチンに入った段階で確定するのか？
それとも共通処理の結果如何で処理内容が変わるのか？
0486デフォルトの名無しさん
2006/04/09(日) 11:23:56○リリース版
なんで変換できちゃうかな。
0487483
2006/04/09(日) 13:31:34共通部分の変更でコピペした奴全部反映させるの、面倒だし
忘れそう。そこのところだけでも何とかなればと。
＞サブルーチンに入った段階で確定
呼ぶ前に確定。なのでテンプレートとか使えないかな、
と考えてるんですが、型で処理を分けてるというのとも違う。
ファイル分けてincludeもスマートからは程遠いし…、似たような
ことしてる人居ませんか？
0488デフォルトの名無しさん
2006/04/09(日) 14:12:59コードジェネレートするのが良いと思う。
0489デフォルトの名無しさん
2006/04/09(日) 14:47:30その構造のままハードコーディングした状態が一番わかりやすい状態かと。
>再利用コンポーネントをつくるのはそうでない場合に比べ３倍大変
>>14で負の動機付けって言われてるけど
コードを共同所有してるって意識で、勝手に変更できて、他人が使ってくれるから自動的にReview状態になる。
ってチーム構成なら楽なんだけど。
0490デフォルトの名無しさん
2006/04/09(日) 15:11:39呼ぶ前に確定なら、>484のいう「ちょっとだけ違う処理」の数だけサブルーチンを作ると言うことだな?
だとしたら「ちょっとだけ違う処理」をdefineマクロで分岐したら?
Ex.
void func() {
前処理;
#if FUNC_TYPE == 1
処理1;
#elif FUNC_TYPE == 2
処理2;
#else
// なにかコンパイル時エラーを出させる
#endif
後処理;
}
void caller() {
...;
#define FUNC_TYPE 1
func();
#undef FUNC_TYPE
...;
#define FUNC_TYPE 2
func()
#undef FUNC_TYPE
...;
}
0491デフォルトの名無しさん
2006/04/09(日) 15:14:13呼ぶほうは
void caller() {
...;
#define FUNC_TYPE 1
#include "func.h"
#undef FUNC_TYPE
...;
以下省略で、
func.hにvoid func()の代わりにコード直書きと。
0493デフォルトの名無しさん
2006/04/09(日) 22:08:47void f(int type)
{
switch(type){
case 1:
多重ループ{
共通処理Ａ
ちょっとだけ違う処理
共通処理Ｂ
}
return;
case 2:
多重ループ{
共通処理Ａ
ちょっとだけ違う処理
共通処理Ｂ
}
return;
：
}
}
でも、局所化はできるし、判定も関数突入時の１回だけだから、性能的にも問題ないんじゃね？
0494483
2006/04/09(日) 23:07:30改変、デバッグ時にコピペは避けたい。４９０の方法は良いと
思うけど、共通処理の部分にブレーク張る時どうなんだろ。
メンテはある程度あきらめるしかなさそうだが…。
話それるけど、こういうケースを効率的に記述できる言語ってある？
関数ネストができて、インライン展開が保障されてて、親関数の
ローカル変数にアクセスできるような言語があればなあ…。
0495デフォルトの名無しさん
2006/04/09(日) 23:56:110496デフォルトの名無しさん
2006/04/10(月) 01:50:59まあどんな環境でも実用的に利用できるとは言いがたいんだけど。
0497デフォルトの名無しさん
2006/04/10(月) 10:13:12共通化ってのはmodeフラグとか受け取って中身でmodeフラグ見て分岐して別処理となってしまう。
部品化ではその別処理の部分を別関数にして実装することになると思う。
共通化で仕様変更があるとmodeフラグが増えて書き直し。
部品化では仕様変更があると部品が増える感じ。
どっちが良いのか？
オブジェクト指向云々では部品化のほうをとるんだろうけど。
0498デフォルトの名無しさん
2006/04/10(月) 10:14:240499デフォルトの名無しさん
2006/04/10(月) 11:17:58#define _MyMacEnd 共通処理Ｂ } }
サブルーチン{
_MyMacStart
ちょっとだけ違う処理
_MyMacEnd
}
0500デフォルトの名無しさん
2006/04/10(月) 11:45:040501デフォルトの名無しさん
2006/04/10(月) 12:01:57#define SYORI(s) 多重ループ{ 共通処理Ａ {s} 共通処理Ｂ }
で充分。
それができんからどうすべかねってわけだ。
template化はInt2Typeとか使えばなんとかなるが、インライン保証との両立が難しいねぇ。
templateはコンパイラに、マクロはプリプロセッサにコードを自動生成させる機能だから、
それで無理なら自分で自動生成させる機能を作成するかだね。
0502499
2006/04/10(月) 12:12:49十分だけど、さすがに
SYORI(
int R=*p++;
int G=*p++;
int B=*p++;
)
みたいに実装部を書くのは格好悪いでしょ
0503483
2006/04/10(月) 13:50:40一応>>483で書いたつもりなんだけど、実際上の問題として、
インラインasmが入ってるとVC6ではそれ出来ない。
アセンブラの改行を要するところ（ラベルとか）とプリプロセッサの
１行にまとめなきゃいけない仕様がどうしても折り合わなかった。
行末に\を付けてもどうにもならん…うまい書き方ないもんか。
なんにせよデバッグ時はスマートにはいかないけど。
0504デフォルトの名無しさん
2006/04/10(月) 13:53:43つ【カスタムビルド】と【外部ツール】
0505499
2006/04/10(月) 14:08:36ラベルが必要って事は分岐命令？ どんなコードを書いてるの？
キャリーで分岐するようなコードなら条件代入とかに置き換えらればその方も速度が上がるけど
0506デフォルトの名無しさん
2006/04/10(月) 14:21:52書けないよ。
（厳密には書けはするけど";"以降はコメント）
0507499
2006/04/10(月) 14:23:28BCBなら
int x;_asm mov eax,xx; _asm lab:;_asm add eax,x;_asm jnc lab;
てな感じで1行に書けるからVCでも試してみて
0508499
2006/04/10(月) 14:27:50そうだっけ？ 確かVCは":"を入れなくても複数行を書けたと思うし ";"セパレータも効いたと記憶してるのだけど
こんなふうに
__asm mov eax,ebx __asm add eax,ecx
0509499
2006/04/10(月) 14:38:16int x;_asm mov eax,xx; _asm lab:;_asm add eax,x;_asm jnc lab;
int x;_asm mov eax,xx; lab: _asm add eax,x;_asm jnc lab;
と C言語側のラベルを使うべきかもしれない
0510デフォルトの名無しさん
2006/04/10(月) 14:55:36だからね、インラインアセンブラで";"はセパレータじゃないんだよ。
";"なしで１行に書くことはできるが、その後ろにＣのコードを記述することはできない。
とりあえずチミは
int i = 0;
__asm MOV EAX, i;
__asm ADD EAX, 1;
__asm MOV i, EAX
cout << i;
と
int i = 0;
__asm MOV EAX, i; __asm ADD EAX, 1; __asm MOV i, EAX
cout << i;
を試してから話しなさい。
0511499
2006/04/10(月) 16:07:211行に書くには __asm そのものをセパレータにしなければならないみたい
int n=1; __asm {mov eax,n __asm lp1: __asm add eax,eax __asm jnc lp1 __asm mov n,eax}
0513499
2006/04/10(月) 16:30:28結局BCB / VC両方で動くようにするには
#ifdef __BORLANDC__
#define _A ;
#else
#define _A __asm
#endif
int n=1; __asm {mov eax,n }lp1:__asm{ add eax,eax _A jnc lp1 _A mov n,eax}
とセパレータを使い別ける事と、ラベルはCのラベルを使うようにする必要があるみたい
0514デフォルトの名無しさん
2006/04/10(月) 17:05:330515デフォルトの名無しさん
2006/04/11(火) 09:39:18仕様変更などでどうしようもなくなったらリファクタリング、でいいんじゃねえの？
0516デフォルトの名無しさん
2006/04/11(火) 09:50:38>>1のような場合には、処理A,B,Cの違いの部分を マクロで表現出来るように作っておくだけ。
0517デフォルトの名無しさん
2006/04/11(火) 10:41:100518デフォルトの名無しさん
2006/04/11(火) 13:33:540519デフォルトの名無しさん
2006/04/11(火) 21:47:17実際に動かしてみないとなんとも・・・
分岐予測が当たってる間は分岐のコストは低いから。
0520デフォルトの名無しさん
2006/04/11(火) 22:08:530521デフォルトの名無しさん
2006/04/12(水) 00:18:200522デフォルトの名無しさん
2006/04/12(水) 23:41:30そっちに労力割いた方が全然いい
■ このスレッドは過去ログ倉庫に格納されています