共通化の線引がむずかしい

プログラムの共通化は作業軽減＆メンテナンス性向上の為に重要だとは思うんですが、
共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。

処理Ａ、処理Ｂ、処理Ｃがあったとして、この３つは横展開の関係にあります。
３つも実装するのは大変なので、全て共通化して実装した（methodX(A）を読んだら処理Ａを行うイメージ）。
だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。

後々思うことは、
最初から処理Ａ、処理Ｂ、処理Ｃは別々に実装すべきだった。
もちろん共通化すべき部分はあるので、下請け処理の共通部品は必要だが、
大元の処理そのものを共通化したのは失敗だった。

なんで、こんな失敗するんでしょう？
最初からＡ〜Ｃはほとんど同じ実装で済むと思っていたのが、
想定外のバグ、仕様漏れ、仕様変更等により、Ａ〜Ｃが乖離した結果、マカロニ化してしまうんですね。
けれど、「想定外」のことを想定して設計なんてできないんですよ。

皆様、設計時にどこまで共通化すべきかという基準ってありますか？

2秒しか読んでないけど
目が痛い
偏頭痛もする

>>1
そもそも似て非なるものを1つにまとめたらスパゲッティーになるのは当然。

>もちろん共通化すべき部分はあるので、下請け処理の共通部品は必要だが、
>大元の処理そのものを共通化したのは失敗だった。
答えはでてるじゃん。
同じ機能を共通化するのはいいけど、同じ流れで違う機能のものは共通化しちゃだめ。
スーパークラスかインターフェースを統一するのはいいけど、1本のプログラムで色んなことやっちゃだめ。

ダイヤモンド継承が問題をはらむのと同じように
構造化においてもダイヤモンド型の構造は危険。

さぶくらすれすぽんすびりてえだって
おっかあがいってたよ

>>1
文脈切り替えが幅広く出来て
部品がきちんと整理されてればいいんですけどね〜
（私は部品に、機能まで入っちゃう）

>>4
それだ！

機能を呼び出している文脈が違ってたりするんですけどね。

ロジックの共通性とオブジェクトの共通性は別の性質。
一言で済ますと、ロジックの共通性は継承を用いて記述してはならない。
ロジックの共通性を括り出す場合は委譲を用いて記述するのが定石。

>>1
構造化言語使いなら、処理内の機能を更にサブルーチンに切り出し各処理ではサブルーチンの呼び出しの形にする

イメージはこんな感じだ
処理A: 処理A-1、共通処理-1、共通処理-2
処理B: 処理B-1、共通処理-1、処理B-2、共通処理-2
処理C: 処理C-1、共通処理-1、処理C-2

こんな事当たり前すぎてつまらん
クラス図とかの勉強するのは良いが、バッチ処理みたいなものはフローチャートや構造化PADなんかで設計した方が早い

>>1
>If (処理Ａの時のみ）...のような記述が増え
この記述をした時点で負け。

・・・まあいいから騙されたと思って
「制御結合」で検索しなさい

>>1
お前、そのクラスの名前だけど
・○○マネージャ
・××エクゼキュータ
なんて感じで命名されてないですか？

もしそうなら、それは「不吉な匂い」のする設計だ。
設計時点で見直しなされ。

メソッドはメソッドとして扱え。関数とは区別しろ。
共通処理関数はstaticなutilクラスで処理しろ。

言い回しは違うが>>7と同じことを言ってるつもり。

>>1
OO以前の、
1970年代後半位の頃のモジュラープログラミングの本を
読むことをお勧めします。

関数は、１画面に収まるように書けって習っただろ？
そういうことだよ。

もっとプラグマティックな問題として、
共通化すると
自分勝手に変更できなくなって、しかも他人が使うという観点からも保守が必要になる、
という負の動機付けが多すぎる。

と言うわけで、同じような処理や他人のコードのコピペが蔓延しているのはどうしたものか。

>>13
＞関数は、１画面に収まるように
宿題ならともかく、無理

１関数数千行、１ファイル数万行が数百ファイルなんてざら

＞宿題ならともかく、無理
なぜ？単に厨PGが多いだけだろ。
いや、自分が書いたんじゃなくてそういうコードの保守をさせられてるのなら苦痛は察するが。

if (xxxx) {
　　xxxx
} else {
　　xxxx
}
スタイルなら可能だが、
if (xxxx)
{
　　xxxx
}
else
{
　　xxxx
}
スタイルでは無理。

ごめん自分で書いてる。
ホントに全部の関数を１画面内に収まるように書いてるの？尊敬する

最適化とかの都合で分けられなかったりインラインアセンブラとか
が入ってくるとあっちゅう間に膨れ上がるんだよあはははは

＞最適化とかの都合で分けられなかったりインラインアセンブラとか
ドライバとかそう言う世界？そういうのは知らん。俺はお気楽な業務アプリだから。

ちなみに、最適化の都合で関数が分けられないってのはどういう場合だ？

考え方や概念の一貫性なしに、ただブチブチ関数に切り出しても、
それは読むのがウザイだけ。

>>18
元の文章書いたのとは別人だが自分は関数やらメソッドやらは一画面に入るようにしてる、
まぁ縦に長い画面使ってることもあるけど。
メソッドの場合は長いコードになると意味のまとまりができてくるのでリファクタリング
することできれいになるし。（応答速度がマイクロ秒以内とかを気にしなければいけないリアルタイム組み込み系だと無理だけどさ）

＞ 考え方や概念の一貫性

これが難しいというか、面倒なんだよ…。

>>19
メソッド呼び出しのオーバーヘッドすら問題になる分野だろう。
Javaでは制御文の中身をプライベートメソッドへ追い出すから
目安としての1画面というのは多くのPGが持ってる感覚だな。

>>22
メソッドの粒度がクラス内で一定になる様に気をつければいい。
どっちかって言うと命名が下手な奴のコードのが読みにくいな。
まぁ、プライベートメソッドは影響範囲が限定的だから変更す
れば済む話だけど

>命名が下手な奴

これ。
英語がからっきし駄目な奴って、自分が名前から正しく意味を読み取る習慣がないから、
自分も正しく意味を持った名前を付けるという事自体が理解できない。
こういうＰＧが相当居る以上、日本語プログラム言語って意味あると思う。

それなら日本語の識別子が使えればよいだけであって、
日本語のブログラミング言語である必要は無いな。

>>24>>25
＞それなら日本語の識別子
つVC8

>>24>>25
＞それなら日本語の識別子
つJava

仕様を決める時に一人で画面の絵と説明だけ書いて終りにしてるのがいけないんじゃないか?

そうだよな。
とっくに日本語識別子なんてOKなのに、なんでみんな使わないんだろう。

プログラムが超解りやすくなると思うんだけど。

GRASPパターン
実践UML - パターンによる統一プロセスガイド
http://www.amazon.co.jp/exec/obidos/ASIN/4894713861/

カップリングとコヒージョンをOOPに当て嵌めて合わせたものだから
構造化を勉強した人には何を今更って内容だろうが、構造化を知ら
ないOOP世代には必須。

Spring Framework使って見れば共通化も楽になると思う

Java意外の言語版Spring Frameworkも出ているので
試してみてはいかが?

>>30
＞構造化を知らないOOP世代
なんだそれ？　OOPったって記述の末端は構造化プログラムだろ

>>32
構造化 = レガシー、オブジェクト指向 = モダンという認識の者を
指して、「構造化を知らないOOP世代」と評した。
OOP世代は構造化を知らないとは言っていない点に注意。

>>33
その時代を知らないの意で使った訳ね？

>>3
1ではないが耳に痛い

ついさっき同じ過ちをして今書き直してる
やっぱシンプルが一番だわ

>>33
「『構造化を知らないOOP世代』とは言ったが
『OOP世代が構造化を知らない』とは言っていない」

こんなド屁理屈が本気で通ると思っている>>33にカンパイｗ

class A {
　//略
};

class B : public A {
　//略
};

class C : public A {
　//略
};

と派生すれば良いんじゃね？

>>37
それだと、Aの一部の機能が、Bでは必要なくなった。
またはそこだけ処理が変更になったときに最悪。
↓がいいと思う。
class ABC {
　//ABC共通処理
};
class A {
　ABC kyotsu;
　//略
};
class B {
　ABC kyotsu;
　//略
};
class C {
　ABC kyotsu;
　//略
};

>>30
むしろそれはオブジェクト指向を知らない
構造化手法オンリー世代にうってつけだと思うが

と思ったがやっぱオブジェクト指向しらないと読みにくそうだから
彼らには難解だろう

違うだろ。派生だろ。　>>38じゃ死滅したＣＯＭと同じ運命辿るだろ。

class BASE {
　//略
};

class A : public BASE {
　//略
};

class B : public BASE {
　//略
};

class C : public BASE {
　//略
};

>>37-38,>>40
それらのやり方だけでどうにかなるケースは
ありうるがどれもこれもそれだけじゃ足りないケースもありうる。
不要になりそうな者が出てくる可能性がある場合は
Adapterパターンでもつかっておけばいいかと思われ。
いろんなデザインパターンを駆使して共通化を図る。
それから文字列リテラルなどは別ファイルにて共通化だ。

流れ（大本）が共通で部品が所々違うのなら、特にポリシーが
ないというときは最初は流れも共通で行け。

ただし、惨事を起こす前にやばいと思ったら分離しろ。
この辺の見極めがセンスや経験だな。

ほとんど共通な流れを最初からたくさん持っていると
共通なものを増築する時にうざくなるし。

OOPはある程度部品のセレクトを手助けしてくれるけど、
手間の半分ってのがいいところじゃね？

マカロニになりそうな時点で、ざっくりと構造を変えてしまうのが吉。
今までのソースを生かそうと苦労しても実りは少ない。

相変わらず単発うんこスレ立ちまくりだな
>>1はフィギュアでも見てオナっとけ

ちょっとずれるかも知れないが、
共通化をするためにstaticメソッドのみの共通クラスを作ることがあるのだが、
どんどん膨らんで、収拾がつかなくなりつつあるのだが、どうすればいい？

>>29
命名が下手な奴が混じってる時点で日本語でもダメ
命名が下手な奴が訳解らん名前付ける位ならむしろ機能ID＋連番でプログラムを作ってもらっても構わない

どうせ、初期化()、初期化前処理()、初期化後処理()とか付けときながら前処理→メイン→後処理の順番で呼ばなかったり
後処理メソッド内に初期化メソッドの呼び出しが入ってきたりする

>>45
何の為のネームスペースか！
それがカテゴライズに迷うロジックなら、それは
そもそも汎化する必要がないロジックなのだ。

>>45
1つに収めず複数のユーティリティクラスに分割する。この場合、機能単位ってのもありかも。
オブジェクト指向には合わないけど、Mathみたいな感じで。
でも基本的にはインスタンスと結びつかないメソッドが、どんどん増えるって状況が変だと思う。

>>46
それに加えてだけど、日本語での名前は、大分類‐中分類‐小分類の順に字が並ぶから、
一見して何を表しているのかわかりづらいってのがある。
データベースの表名とか、そうなっちゃうこと多いよね。末尾の1字だけが違う別のものとか。

小手先のプログラミングの話じゃなくて分析設計の話じゃないのか？

まだ実装を意識すべきでない段階で実装図面を引いたからこうなっちゃったんでしょ。

設計の段階で想定外のバグって？

構造設計してないだけだろ

>>50-52
kwsk

>>1
>だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。 

本当に共通化されていれば、普通「処理Ａの時のみ」なんて
ベタな分岐がソースコードに埋め込まれるはずが無いんだが・・・

多分、共通化が全然足りてないんだろう。

試しに聞いてみるけど、その「共通」関数って一体「何行」あるの？

>>42
>ただし、惨事を起こす前にやばいと思ったら分離しろ。
>この辺の見極めがセンスや経験だな。
確かに。諦めて作り直すことも１つの勇気ですね。
分離せずにリリースまでいってしまうと、保守の時に修正時影響範囲に怯えないといけない。

ただし、分離作業＝作り直しであって、これ自体がちょっとした惨事です。
そうなる前に見極めるにはどうしたらいいですか？

>>55
何か、>>1 の言葉の端々から、腐りきった大規模業務系の
臭いがプンプンするんだが・・・(w

>>56
おいおい、>>1の能力が不足してるだけの話で業務系とか大規模とか関係ねえぞ

ここはひどい雑談スレですね。
マ板逝ったほうが盛り上がりますよ。

同じような処理をするから共通化という考えが間違ってるということだ。

話をぶった切らせてもらうが、マカロニとスパゲッティは同じなのか問い詰めたい。

> お前、そのクラスの名前だけど
> ・○○マネージャ
> ・××エクゼキュータ
> なんて感じで命名されてないですか？

やべー、結構こんな感じの命名あったりするんだが・・
何でもかんでもマネージャに任せないようにしてはいるんだけど。うーん
なんだかんだで、ＸＸManagerってつけちゃったりしないですか？？

>>1
その共通化した部分にはどういう名前がついてるんだろう？行数よりもそっちの方が気になる
きちんとした名前がつけられてるならまず、その概念を定義したことが間違いであった
とはならないはずだ、作っていったらそんな概念が実際にはなかったことになったとはならないでしょ
for文くらい一般的すぎて取り上げるまでもなかったというなら話は別だけど

そもそも、当初きれいに共通化されていたものが、全体的な仕様がだんだん増していく中で
そうでなくなるというのは当たり前の話であって
そういった事実からその共通化の判断が誤りであったということにはならないのでは？
仕様が流動的に変化するなら、プログラムの全体的な構造も必要に応じて変動して然るべきだと思うが

変化ヲ抱擁セヨだね

>>45
> ちょっとずれるかも知れないが、
> 共通化をするためにstaticメソッドのみの共通クラスを作ることがあるのだが、
> どんどん膨らんで、収拾がつかなくなりつつあるのだが、どうすればいい？

Facadeパターンを使え。

それからちゃんと分割統治くらい汁
それからちゃんとパッケージ分けはしてるよな。

そもそも、そういうstaticしかないメソッドのために共通クラスなんか作るなアホ。
おめえのソースコードキモイぞ氏ね。
そんなコードのメンテなんかしたくも引き継ぎたくもないわい。

デフォルトコンストラクタをprivateにしてクラスをちゃんとfinalにしておけ

>>37のようなやり方は最悪だな
機能を追加するたびに
継承していくってことは
あどでどんな大惨事が待っているか
想像がつく。
引き継ぎ人が大変だ。

ってか以前>>37のようなコードを
引き継いでかなーりｳｻﾞｯって思ったことがある。
オブジェクト指向のことわかったつもりになって
やたらと継承しまくって分割統治もせずに
平気で継承するクラス＝バージョンアップされた差分クラス
と勘違いするところがウザイ。
だからクラス名は継承するたびにクラス1,クラス2,クラス3
とかわけのわからんものになる。
しかもメソッドまでmethod1(), method2()とかアフォなネーミングになる。
かなりウザかった。こんなコード書いた奴の会社に
殴り込みに行ってぶっ飛ばしてやろうかと思った。
バージョン違いなんてソースコードの上でやるな馬鹿野郎。
バージョン管理システム使って管理しやがれや。
継承をバージョン管理に使うなアフォ

>>46
> >>29
> 命名が下手な奴が混じってる時点で日本語でもダメ
> 命名が下手な奴が訳解らん名前付ける位ならむしろ機能ID＋連番でプログラムを作ってもらっても構わない
それじゃCOBOLerの二の舞だぞ。
かなりウザいんだが。
そんな奴、殴ってやりたい。
連番はSubversionが自動的につけてくれるからメソッド名やクラス名にまで
つける必要はない、というかむしろ害悪だ。不要悪だ。
クラス名やオブジェクト名はなるべく名詞形でキャメルケースに
メソッド名はなるべく動詞形で先頭の頭文字だけ小文字にしたキャメルケースに、
そしてメソッド引数は目的語が入り、そのときのメソッド名にはcompateTo(Object)のように
動詞 + 前置詞 + ( + 目的語 + ) のような組み合わせになるようにしろ。
こういう命名規則を守れ。

それがすぐできそうにないとおもったらいきなり連番などせずに
辞書を使え。電子辞書を手元に置いておけ。
もしくは英辞郎かスペースアルクのページを常に開いておけ。
http://www.alc.co.jp/

>
> どうせ、初期化()、初期化前処理()、初期化後処理()とか付けときながら前処理→メイン→後処理の順番で呼ばなかったり
> 後処理メソッド内に初期化メソッドの呼び出しが入ってきたりする

まったく、ネーミングセンスがシステム開発系やデジタル信号処理系の奴に
ありがちなやつだな。入力と出力のことしか考える力がなくクラスにインスタンスフィールドを
おいて値を保持しておくという発想能力に欠ける構造化手法系な奴にありがちだな。
COBOLerみたいなオッサンは迷惑だからこの業界から去るかもっと真面目に勉強するかして
出直してくれ。

>>54
> >>1
> >だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。

それじゃ真のメンテナンスでもリファクタリングでも無いな。
eXtreme Programingについてもっと勉強してこい。
とりあえずEclipseでメソッド抽出してみろ。
それからStateパターンについて調べてこい。

>>61
Manager相当クラスが他のクラスにアクセスするための
Facadeになっていればそれでもオッケ。
ただしやたらと多すぎたら考え直せ。
もっと抽象的な名前を考えろ。
これって何？　と聞かれてすぐ答えられるような名前がいい。
何をするかはっきりしていればもっとマシな名前を思いつく。

メール送信ならMailSender,
読み込むだけなら○○Reader
書き込むなら○○Writer



新たにあるインスタンスを生成することをメインとするなら
○○Factory


とりあえずデザインパターンやアジャイルの本を読めば
良い名前を思いつく。

みんちーが来た。このスレももう駄目だなorz

実際に今漏れが格闘している失敗形。
　/**
　 * 麺類売上げ共通処理。売上げデータを整理する。
　 * @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 節もコーディング規約。。。

ちょっと待て俺漏れ。
「flour(小麦粉)」はどう略しても flw にはならんジャマイカ。

こんな深夜に何やってんだ　orz　死にたい

しょうがの色って…

焼きそばは真っ赤なやつでとんこつはピンクのやつとかそんなん？

卵をtmgはなんかかっこいいな

とりあえず腹が減るサンプル禁止

>>70のせいでラーメン食いたくなってきた

tuyKsa は
tuyKos か tyuKsa が「正しい」ような気がする

もしかして接頭詞とそうでないのでは省略規則が違うとかなんだろうか

>>70
というか、引数の意味不明な略語は何だ。そこからしてNG。

だれか、>>14 に答えてくれる猛者はおらんかの

>>78
こうすれば良いんじゃね？

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のように、のように自己責任でしる！、
とすれば差分コーディングだお。

誰かに振ったコードの中は見ない。挙動がおかしかったら直せ。以上

>>79
>>14は、共通化がおかしいって問題じゃなくて、
共通化はちゃんとできるとしても共通化自体をやりたがらないって問題なんだけど。

>>81
まず、共通化できるから共通化するという動機が変。

だから、派生を学べばコピペできなくね？

だって派生元クラスから派生後クラスにメソッドコピペしたら、
さすがに頃されるだろ。

共有化部分が大きすぎるんだよ。
細かく部品化すれば、その場その場で異なる挙動に組み立てやすい。
希望の部品がなくても、小さい部品なら自作するのに労力も少ない。

>>82
言いたいことは解るけどさ、
全体の設計のモデル化とは違うレベルでの共通処理・共通機能ってもんが実際あるでそ？
例えば、どのクラスに所属してもしっくり来ないメソッドをXXXutilクラスのstaticメソッドにしたりするでしょ。
あるいは大規模開発で、
設計レベルのモデルとは別の観点からのちょっとした共通機能とかってのが出てくるでしょ。
そういうの。

>>83
処理の共通化のために継承使うってのは、ほとんどアンチパターンだとおもうが。

>処理の共通化のために継承使うってのは、ほとんどアンチパターンだとおもうが。

これって、ＷｉｎＤＮＡ時代のＭ＄の宣伝に騙されただけ。

ふつーに思考してみ。

プログラムとは記述。
記述のために各種文法があり、どの文法を使っては逝けないという決まりは無い。
記述は少ないほうが良い。
継承は文法の１つに過ぎない。

>>81
それはプログラムの個々の設計をスキルの無いコーダーに任せるからか、その様な設計を行う作業時間をちゃんと取らせないから

試しに、「ある分野の処理」ってのをクラスにすると、
そこにメソッド束ねられて読みやすさマンセー、
さらに類似処理で、あ、ここだけ処理差し替えでおｋ、マンセー、と分かるお。

だけど、「ある分野」という言葉はあっても、「ある分野の処理」ってのは現実世界に無い物体なわけだけど。

もっと言うと、
読みやすさマンセー、で、差分コードで書く量削減で、
アンチパターンんも何も無いだろ。

これでＭ＄の洗脳解けた？

>>86
＞これって、ＷｉｎＤＮＡ時代のＭ＄の宣伝に騙されただけ。
は？？
＞どの文法を使っては逝けないという決まりは無い。
…唖然。
OOPを勉強した方がよろしいかと…。


>>87
せっかくだが、>>14を読んで言って欲しいんだが…。

差分プログラムは楽だけど、実際の処理の流れが見えにくくなるという問題点がある。
大事なのはバランス感覚。

>>86
>>90ではちょっと暴言だったな。詫びる。
しかしだ、
＞「ある分野の処理」ってのをクラス
これはありえんよ。
クラスは、物（の種類）であって、処理ではない。

だいたい、OOP以前に、普通に構造体で考えたって、おかしいでしょ。

>>92
設計レベルではそうだけど、実装レベルではあるんだよ。
コンパレーターとか、ファンクタというクラス使うことが。

>>92
>これはありえんよ。 クラスは、物（の種類）であって、処理ではない。

架空のクラスに束ねるという意味だよ。
例えば、ドキュメントクラスなんてまさにそうでしょ？
構造体配列にロード処理とセーブ処理が付いててマンセーだけど、
現実世界にはドキュメントに該当するものが無い。

人の言う事を理解しようとする気が無いなら折角の回答が読めないだけだお。

>コンパレーターとか、ファンクタというクラス使うことが。

コンバーターなんてまさにそうだおね。
コンバート中のプロパティとメソッドが束ねられてマンセー。

で、ファンクタもそうだおね。









ファンクタってなんだけ？

コンパレータやファンクタは、比較・処理などの機能を持った「物」であって、「処理」じゃないでそ。
現実世界に対応する「物」とはいってないお。仮想上の「物」。

架空と現実って言葉に振り回されてるだけ。

どーでもいいが、処理の抽象化で出す例は、普通はドキュメントじゃなくてIteratorなわけですが。

関数もオブジェクトです。

>>94
あ、でも、それだよそれ。設計レベルじゃなくて、
その位の実装レベルで立ち現れるクラスとか共通機能とかあるでしょ。

そういうのを、みんな共通化したがらない、というのが>>14。

つまりだ。

クラスを大局的に書くときのパターンは現実世界に即すというのがパターンかも知れんが、
ミクロ処理を書くときにどの文法使っちゃいけないという決まりが無いことを知らない人間が、
一番ＯＯＰとプログラミングを分かっちゃいない。

>>99
ヴぁかだにい。

ドキュメントクラスが内部にSTLをhasすれば良いでそ。

>>101
だからそれもクラスにしちゃえば解決。

>>101
実際、使いにくい。
いや、ずっとその会社で働いててフレームワークの設計から
携わってきたというような奴なら暗黙で分かるしコード量も
削減できるんだろうけど。

>>102
クラスが現実世界の物に則すなんて、だれが言ったんだい？
ミクロ処理ではOOPなんか無視してクラスを作れって言いたいのかい？

>>104
それで、いったいなぜ解決するのか？

＞ミクロ処理ではOOPなんか無視してクラスを作れって言いたいのかい？

この言い方で理解出来て無いのがわかるね。
ミクロでオブジェクトが無いレベルなら、今使ってる言語の文法駆使して短く書け（性能はなるべく落とさず）。

これで分からなきゃ、氏ね。

>>107
コンパイル通るって意味なんじゃないかと推測。

>>104
大局的にベースクラスを派生したスケルトンコードをさらっと数行書いて渡せば押さえ込めるだろ。

「そんなことはやるな」と言えば全部解決じゃないｗ

>>108
なるほど、アンチOO派でしたか。
それもひとつの解かもしれないけど、OOと非OOの線引きが難しいね。

素粒子レベルでは相対性理論も通用しないんだから、
ミクロ処理ではＯＯ無視しても、いーじゃない。

つまり最強はテンプレートメソッドパターンでＦＡ

>>112
アンチＯＯじゃねーよ。

大局的には現実世界に合わせろといってるだろ。
だって、現実世界のモノに即す程素直な記述だお。

だから、>>14は、
最悪みんな同じような処理をprivateで書いて他人に使わせないとか、
アクセスできても他人に存在も知らせないしとか、という事を言ってるんだけど。

>>108
短く書くと、クラスとか導入してる余裕は無いしね。

>>116
問題があるとは思わないけど。

そーいや大昔には、ある程度の規模のプロジェクトなら、ライブラリアンってのがいたね。
そういう役割する人がいないってことかね。

>>14
>と言うわけで、同じような処理や他人のコードのコピペが蔓延しているのはどうしたものか。

>>116
>最悪みんな同じような処理をprivateで書いて他人に使わせないとか、

ふつー、privateからprotectedとかに移動するじゃん？
それをコピペできるとはＯＯＰの基礎を勉強すれば良いんじゃね？

そのコードを引き継ぎさせられる人間以外にはなｗ

>>115
クラスを現実世界の物と対応して考えること自体からして、
あんたはOO派ではないよ。
http://www.rubyist.net/~matz/20060127.html#c01

>>117
>短く書くと、クラスとか導入してる余裕は無いしね。

ﾌﾞﾋﾞﾁｭｳか？

C++ならクラスは、
class A {
};
とふつーに書けるが。
ヘッダーファイルでもソースファイルでもどっちでも書ける。

>>120
＞ふつー、privateからprotectedとかに移動するじゃん？

そこだよ、そこ。
そのprivateメソッドの作者に断り無く勝手に変えるのか？

>>122
>クラスを現実世界の物と対応して考えること自体からして、 あんたはOO派ではないよ。

残念でした。あなたは超スペシャルどしろうと。
それを言うなら「OOP派じゃないよ」、ならまだ成り立つ。

そのサイトに書いてあるのはOOPであり、その中のクラスベース。

「OO」は文字通り、「現実世界の物指向」。
OOPのクラスベースが「データ抽象」「多層」「継承」 であるだけ。

>>116
設計時に立ち現れなかったクラスを、実装時に共通処理だからって
定義して使おうってのはやめたほうがいい。
やりたいのなら、設計時に定義すること。

>>125
そういう揚げ足とって楽しいお年頃？

>>124
>そのprivateメソッドの作者に断り無く勝手に変えるのか？

ただの運用の話でそ？

クラスで言うprivateってのはアクセスできないよという記述であり、
アクセスできるおのpublicに移動するのがコーディングだろ。

運用ルールを決めろ。

なんか急に伸びてると思ったら。まあ、お前らﾓﾁﾁｭｹ
そしたらちょっと香ばしいのが混じってややこしくしてるだけだってわかるから。

>>127
揚げ足じゃないよ。

学術的には、クラスベースは異端で、オブジェクトベースに逝こうすべき、であり、
クラスベースOOPから外れても、OO派には向かってるお。

>>126
なんか、それが正論の気がするけど、
おんなじような処理を重複して諸所に書かれてるって気持ち悪いんだけど。
それに、設計時っていつ？
実装レベルのクラスとかメソッドなんて、ほとんど実装フェーズで作るもんでしょ。

よし、一抜けた。

>>126
>設計時に立ち現れなかったクラスを、実装時に共通処理だからって
>定義して使おうってのはやめたほうがいい。

設計とプログラミングを別々に切り分けるのはウォーターフォールだお。

エリック・レイモンド　オープンソースの解剖学四部作
くらい読んで勉強して欲しいお。

ttp://cruel.org/jindex.html

>>128
だから、最初から運用レベルの問題を聞いてたんだけど>>14は。
みんなどうしてんの？って。

>>130
＞オブジェクトベースに移行すべき
オブジェクトベースってプロトタイプベースのことか？
「OO」がクラスベースではなくプロトタイプベースOOを指すなんて、初耳だね。どこに書かれてる？
つうか、学術的にはプロトタイプベースに移行すべきって、それこそ初耳。
そんなん、どこに書かれてるよｗ　２０年前のSUNの論文とか出してくるなよ？ｗ

>>131
リファクタリングじゃないけど、定期的に(詳細)設計し直せばいいじゃん。
その都度、クラスとして抜き出すことが出来そうな処理を抜き出すと。

>>134
>みんなどうしてんの？って。
無言で書き換えて、CVS格納。

>>134
静的なクラスじゃ、シミュレーションや人工知能で困る事ね？

>>137
どう困るの？

>>136
それだよ、それ。
そうやって勝手に人のを使ってたら、
いつの間にか仕様が変わってて…作者「はあ？勝手に使っててそんなん知るかよ！」

ここから型つき言語とか展開する悪寒

>>135
なるほどね。
リファクタリングの単位を個人じゃなくてチームに広げるのか。
小さなチーム内ならそれもできるんだけど、
メールでしか知らない人とか沢山いるんだよ…。

>>137
なぜ>>130と全然別のことを言い出すのかな？
それに学術的といいながら、いまさら人工知能ってｗ

>>139
マは勝手なやつが多いけど自分のクラス使われるのは好きなやつだから、
＞いつの間にか仕様が変わってて…作者「はあ？勝手に使っててそんなん知るかよ！」
これ凄杉。

会社変わると良いかも。

>>141
>それに学術的といいながら、いまさら人工知能ってｗ

しったか乙。

>>142
いや、だって作者本人が必要があって仕様変更したんだから、
それを他人のために変えるって、そりゃないでそ…。

もはや言語やプログラミングスタイルではなく、組織体制や
チームワークの問題。リーダーに統率力が無いんじゃない

なんか、プロジェクトの運営の話になってるね。
そんなのどんなに正しい理想があっても、工数とか納期とか保守費用とか、プログラム以外の要因で
いくらでも変わるんだからさ。プログラミングでどうこうする問題じゃないべ。
実際の運営では>>135になると思う。見直しの頻度は工数とか（ｒｙ

>>145
いや、まったくその通りなんだけど、みんなどうしてるのかなぁって。

>>147
お互いの利益が合致しない開発では、共通化は難しいってことだね。

合致するように工夫しる。

>>143
は？
じゃあ、人工知能学会の会員数の推移はどうだい？科研費はどうだい？

一人頭がおかしいやつがいるな。

>>149
リアル人工知能と実用人工知能を混ぜてるとこが厨杉。
画像認識なんかも大きい枠の人工知能。

>>148
＞難しい
＞工夫しる
…orz

人工知能なんて関係ないだろ。
消えろ。

消えるべきは>>141とか>>149の嵐。

<でかくて赤い字>おい、チャットかよ？少し頭冷やせ！</でかくて赤い字>

共通化なんて、俺が共通化しますよー。
みんな共通に出来そうなのがあったら
もってきてくださいねー。っていえばすむだろ。

>>152
だって、同じ会社にいながら、
＞いつの間にか仕様が変わってて…作者「はあ？勝手に使っててそんなん知るかよ！」
はﾌﾟﾁｽｺﾞｽ

>>156
だからそれを言うのって貧乏くじじゃん。誰もやらない。

>>157
いや、実際はそういう言い方はしないけどさ…。
まああと、同じ会社とは限らないんだけどね。

っていうか、こういう風に事前に発覚すればまだいいけど、
そのまま運用に入ったら…。

>>158
>っていうか、こういう風に事前に発覚すればまだいいけど、
>そのまま運用に入ったら…。

CVSでチェックアウトしなきゃ、該当ソース変わらんだろ？
変わっても変わったソース特定出来るし、ﾔﾊﾞｽなものはリビジョン固定しる！

＞だからそれを言うのって貧乏くじじゃん

何を勘違いしているのか。それを言い出せる状況に居るのなら
幸せじゃね？

むしろ頭角を現すチャンスと捉えよ。うまく立ち回って結果を示せれば
だんだんと立場も上がるだろう。

今の職場や仕事が心底好きじゃないなら、その他大勢でいるのも
選択肢のうちだけどさ。どうするかは本人しだい。

同じプロジェクト内の別チームが作った関数を
便利だからといって勝手に使うという方が信じられない。

>便利だからといって勝手に使うという方が信じられない。

C言語ランタイムは？

くま^ー

>>158
>まああと、同じ会社とは限らないんだけどね。

もしかして、ソース管理ツール使ってなくね？
ソース管理ツールなくして共通化はありえん。
つか、使え。

>>162
公開されているなら使うのは当然。
公開されていないのなら、公開させるかコピーするべき。
#まぁ、非公開APIみたいにこそこそ使うのはリスク覚悟でやるべきだな。

上司と相談して開発プロセスにリファクタリングを組み込め。

>>159
ライブラリ化せずにバイナリは別にするのか。しかし、名前のバッティングが。

>>163
使ってる

>>166
>ライブラリ化せずにバイナリは別にするのか。しかし、名前のバッティングが。

いや、ライブラリといってもバイナリじゃなくてソースだろ？
まさか、バイナリってＣＯＭじゃないだろうね？
ＣＯＭの世界は終焉したお。

>>166
クラスライブラリでの共通化は上手くいくけど、
ＣＯＭはその辺りが上手く逝かなくてあぼーん、
クラスライブラリベースのドトネッツが出来たわけ。

COMとかどうでもいいです。
ソースを自分だけはリビジョン固定で使っても、名前が本家とバッティングするじゃんて話。

>>169
>ソースを自分だけはリビジョン固定で使っても、名前が本家とバッティングするじゃんて話。

全く意味が分からん。
本家のクラスを派生して、
本家のメソッドを変えたいときは、オーバーライドで同じ名前使うし、
新たにメソッド足すときは違う名前にするじゃん？
それが意識せず名前ブツカッたらコンパイルエラーか警告出るだろ？

>ソースを自分だけはリビジョン固定で使っても、名前が本家とバッティングするじゃんて話。

もしかして、リビジョン固定の意味分かってなくない？

本家のリビジョンを固定するんだお。
本家の人がどんどんチェックインしようが、
自分のコンパイル環境では固定されてるリビジョンのソースは変わらないんだお。
どうしても変えたい場合は意識してリビジョンうｐして、
何がどう変わったかは差分ツールで見れば良いじゃん。

自分はチェックインしないのか。

リビジョンからブランチ作ってチェックイン出来るでそ？

そのブランチが気に入れば本家にお願いして最新にマージして貰え。

まさか、Ｖ＄＄とかいうクソツール使ってんじゃねーだろーな？

そうか。
プロジェクトチームとは別バージョンのプログラム開発すればいいのか。

( ﾟдﾟ)ﾎﾟｶｰﾝ

>>175
　　(　ﾟдﾟ)
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣

　　( ﾟдﾟ )
＿(__つ/￣￣￣/＿
　　＼/　　　　/
　　　　￣￣￣

　　(　ﾟдﾟ)
＿(__つ/￣￣￣/＿
　　＼/　　　　/

>>177
こっち見るんじゃないよ

名前のバッティングは、コンパイル時じゃ実行時の話なんだが

>>176-177
俺は>>175じゃないが。日本人は、こういういちいち小馬鹿にする奴がいるのが駄目だ。
知らない事があっても構わないじゃん。お前には無いのかと。
同じ民族なんだし助け合えやクズどもがコルァ

>>175
そうなのです。Javaの1.4で開発してて、リリース時にはJava1.5にアップグレードするとかないでしょ。
アップグレードしたことによって動作検証とか大変だし。
無理に最新にあわせることはないのです。たとえ社内開発という小さい規模の開発であっても。

>>179
コンパイルじゃなくて、実行時の話？
JavaとかCOMとかDLLでの開発限定の話か？

>>158
＞だからそれを言うのって貧乏くじじゃん

ああ、なんかわかるなぁ。
ひとつの共通処理担当になると、いつの間にか全部の共通処理担当になってて、
しかも、自分が元々担当してた業務ロジック部分も当たり前、開発しなくちゃいけなくて、
業務ロジック＋共通処理（仕事増えた）でなんか仕事増えてて、
「共通処理」の部分で不具合とか、仕様改善したくなったら「全部あの人が知ってます」的な事を言われて（略


やっぱ、自ら進んで言いたくない事だよな。うんうん。

>>182
だね。バグが出るたびにろくに調べもせず「共通処理が…」とか言う馬鹿もいたりするだろうし。

お前ら一生平社員

>>181
そう。というか普通だと思うが。
ひとりひとり自分のスタティックリンクのexe作るプロジェクトとかあるか？
普通多かれ少なかれ他人と名前空間の空間を共有するだろ。

>>185
言語の方にNamespaceとかPackageとかあるし
そもそもチームでの開発なら命名規約ってのがあるのが当たり前

>>186
おまえ、話の流れ全然理解してないだろ

>>70のラーメンにしても>>1の話にしても
実際にシステムの存在そのものの根拠がエンティティの複雑性というかそれぞれがどれだけ
特異であるかという部分にあるのに、実装はいつも未だにユーザーの入力や欲しがってる出力に
主眼をおいてなされるのででてくる問題

システムをあるがまま正確に捉える見方は確かに存在するのにも関わらず
無理やりおかしな断面で切り取ってくるから
まるで木材をわざわざ横向きに年輪に垂直に切ったみたいに
同じような条件分岐がひとつのルーチン内に頻出することになる

うちのプロジェクトでは神が
共通化できるユーティリティはいつの間にか作成
共有化できる処理はテンプレートメソッドパターンでいつの間にかフレームワーク構築
やりたいことがあったら全部その人がFacade・・
同じ処理を書くのはキモイらしい

>>183
同志よ！そうそう。それそれ。よく言われました。

>>184
おまえ、開発やＳＥでトップとったところで所詮、平社員だぞ？
役職につける奴は、開発技術能力より、人を管理する能力とか、企画力がある人間だよ。

>>185
えっ、いや。あの。普通か？
「名前空間」なんて言葉使うから、なんの話かわかりにくくて、みんな混乱してるわけで。
最初からＤＬＬでの開発が前提ですとかってことを伝えないと。正直、言葉足らずでございます。

>>191
業務システムの開発で、
みんな個人個人が自分のstaticリンクexeを作るなんて有り得ませんから。

>>189
うらやまスィ…。
ただ、それって数人規模だから出来る、とかじゃない？
うち、１００人以上のプロジェクトだから、うちに来たらその神は天に帰ってしまうな…。

>>192
業務システムの開発で、言語がＣで、かつＤＬＬベースでの開発の仕事なんて最近じゃすくないぞ。普通か？
だから、「名前のバッティング」とか言われたらnamespace使えとかpackage使えっていう話の方向になるわけで。

>>193
１００人規模ですか…。俺なら天に帰るというか、会社から帰れなくなりそうだ…。

数人規模だが既に帰れない漏れガイル。

>>185
>そう。というか普通だと思うが。

普通はＣＯＭなら廃止の方向だが。

>>190
>開発やＳＥでトップとったところで所詮、平社員
ずいぶんと不憫な会社だな

>>193>>196
なぜお前らは特定実現技術こだわるのか。
JavaだってPerlだってそうだろ、C系だってDLL使うだろ。
だいたい>>14からの流れで単にnamespace使うのがどうして解になり得るのか小一時間…

１９８＝ＣＯＭ脳

解になることは決着が付いてる。 >>171-177

なぜＭ＄が丸々ＣＯＭを捨てたのか理解出来て無い香具師が炒るとは。

まだＭ＄の洗脳が解けてないね。

このスレは、Microsoftな環境でしか開発したこと無い奴ばかりなのか。

こんな感じ？

DDE（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下位互換へ

知的障害のMS厨が暴れるな。COMでトラウマでも受けのか？それでもMSの狭い檻の外には目を向けないという…

ＣＯＭ脳も問題だけどﾌﾞﾋﾞ脳はヒドイ。

>>204
アホ。お前の事を言ってんだよ

共通化の核となるベースクラス宣言をclass A {} ; とサラサラっと数行で書けないＣＯＭが諸悪の根源であることは間違い無いな。

>>206
VB.NETで書けば良いじゃん

クラスベース開発の隠蔽は、ソースコード上でpublic/privateを丸々見せながらの論理上の隠蔽。
しかしながら、CLRはクラスライブラリには超珍しいソースを見せないクラスライブラリ。
その点超世界的に使い難い派生し難いMFCにも劣る。

207=ＣＯＭ脳によるバ●の壁

劣るのかよ

>>208
そのために各言語にdelegate構文が追加されてるんだろ
メンドクサイ所は弄るなよ

プログラムの段階じゃなくて設計の段階で実現できそうに無い事は排除して行かないと

>メンドクサイ所は弄るなよ

CLRのpublic/privateが見えないんだから、何がメンドクサイ部分かも分からない暗闇。

211=暗闇でマンセー

　　　　　　　　　　　　　　　∴∴∴∴　
　　　　　　　　　　　　∴∴∴∴∴∴
　　　　　　　|￣P∴∴∴∴∴∴∴∴
　 　 　 　 ／　 ＼
　　　　　 |￣￣￣|
　　　　　 |ﾌﾏｷﾗｰ|
　　　　　 |　 (,,ﾟДﾟ)　　＜ 死ねや。ｺﾞﾗｧ!
　　　　　 |　（ﾉ 　 |つ
　　　　　 |　M$　　 |　
　　　　　 |＿＿＿|　
　　　　　　　U"U　　
　　 　　　　　　　＼　　　　／
　　 　　　　　　　 　＼　／ 　　／￣￣￣￣￣￣￣￣￣￣
　　　　　／￣￣￣(,ﾟДﾟ,) ＜　　VBは便利だよ。便利なものは便利につかわせていただく。
　 　　　~￣>￣>￣> 　 ヽ 　　＼＿＿＿＿＿＿＿＿＿＿

　　　　　　　　 ＿ ∩
　　　　　 ⊂／　　ノ　） ／
　　　　　　/　　　/ノV　 　ｲﾅﾊﾞｳｱｰ
≡≡≡≡し'⌒∪ 　　　＼
　　　　 '┴┴ ┴┴'
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　 ／⌒`ヽ
　　二　と（、Ａ　, ） つ　　＜ｲﾅﾊﾞｳｱｰ
　三　　　　Ｖ￣Ｖﾉ（　ゝ

MS厨がいかにゴミグラマであるかよく分かるスレッドですね
もう目もあてらんない。

>>214
懐かしいな、マトリクス。

>>69
みんちーって何だ？
お前が挽肉にでもなったのか？

>>70
無駄に引数が多すぎ。
そんなことするなら引数はList<専用クラス>ひとつとかにまとめておけよ。
それか
class 何か {
　private List<売上げデータ> list;
　public void add(売上げデータ data){
　　this.list.add(data);
　}
}

みたいなことしたほうが効率が良い。

>>79
> >>78
> こうすれば良いんじゃね？

ただのTempate Methodパターンのまがいものにしか見えない部分
があるようだが。

Proc_1()というネーミングがどうも古臭い。
そういうところにアンダースコアを使う必要はない。
メソッドの頭文字をわざわざ大文字に擦る必要もない。むしろしないほうが
読みやすい。無駄にメソッド名に数字を使うのは御法度。
意味のある名前にして場合分けしろ。
しかもメソッドの中身は空っぽ、継承しているクラスAまで空。
あまりにも意味がなさすぎる。

最後の三行から言いたいことがだいたいわかったが、
それにしても
やっていることはただのオブジェクト指向の初歩にすぎないな。

>>70ってどうやったらこんな設計になるんだろう…。
まず引数が多すぎるし、ある引数が他の引数に応じていろいろ制約があるのがすでに終わってる。

＞こういう「賢すぎるメソッド」が発生する一番の原因は、やっぱ名前のつけ方だね。
賢すぎないし、むしろアホ。何やってるかわかんないだろ。
大体テストどおすんだよ。テストコードとか作んないのか？

らーめんはらーめんで、焼きそばは焼きそば、そーめんはそーめんで
分割したりしろよ。

プログラム設計に馴れてないやつが作ったんだろ。
設計なんて呼べるようなことはしてない可能性も高いが。

あと、「賢すぎる」の意味は字面どおりにとっちゃアカンとおもうよ、この場合。

>220
「賢すぎるメソッド」とかの話、聞いたことないかい？
つか、確かに、意外とあまり語られないからなあ。。。

要するにまさに >70 のように、一つのメソッドが何でもかんでも抱え込んじゃった
「何でも屋」なメソッドの事。
>218 の指摘の通り、無駄な引数が多くなるのがこの類の失敗の特徴だよね。
>222 の言う通り、この「賢すぎる」は「賢いっつかテメー賢すぎだよバカ」みたいな
逆説的な意味だ。

初学者がよくやらかすんだよな。それで結局破綻して痛い目を見て
共通化や分割統治のバランス感覚をつかむ。



> 大体テストどおすんだよ。テストコードとか作んないのか？

気合だよ！ヽ(｀Д´)ノ 今日、気合でテストデータ全部作ってやったよ！
漏れがんばった！ほめてほめて！！１

つД`･)ﾟ･｡どうして漏れが作んなきゃいけないんだよ！！！！１１２１２１ぬぬ！！

「賢すぎる」って余計なことをしすぎテルみたいなニュアンスで使ったんだろ。
無駄に賢すぎるみたいな。>>70みてたらラーメン食べたくなってきた。

って、よく>>70を見てなかったが良く見ると確かに うぜぇ >>70の気持ちわかるわこれ。
さらに追い討ちをかけるような↓このコーディング規約ｶﾜｲｿｽ
＞　(それぞれの「売上げデータ」は、共通のスーパークラスを持たない。
＞　　コーディング規約上、そういうクラスを作ってはいけない)

>>223
あっ、本人登場？しかも、このコードのテストコードか・・・。
生暖かく見守るくらいしかしてやれんが頑張れぇぇぇぇぇ！

If (処理Ａの時のみ）...

ってのは、そこで前編後編に関数をわけるんだよ。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

とかパターンはいろいろあるだに。条件を引数じゃなくてプロパティにするとか。

Public Sub 処理(条件)
　Call 前処理 ' Private
　If 条件="A" Then
　　Call 中処理Ａ ' Private
　ElseIf 条件="B" Then
　　Call 中処理Ｂ ' Private
　End If
　Call 後処理' Private
End Sub

みたいなのでもいいよ。Ifを減らすようにすると原則いいかもしれない。
構造化の範囲で書いてます。継承とかももちろん考えればあるけど
ローテクで済むところは済ますに超したことはない、かもしれない。

悪いがお前、ブビ厨度炸裂してるよ
前中後なんて単純な分け方の問題じゃない。
無理に分けても、さらに条件が出て来て
コピペ地獄へ大ばく進だ。
このメソッドをどうするってばかりに目が行ってるが、本当は引数の方が賢くならなきゃいけない。

ヒント：インターフェースに対して実装するべし

前中後ってのは、長すぎる関数の分割というリファクタリングと同じだと思うけどな。

>>230
全然違う
もっと勉強せれ
そもそも「前中後」って発想がナンセンス

>>231
反論するなら中身を書くこと。

おまえのようなレスには、
「おまえの方が間違っている。」で十分だ。

>>232
我が身見て・・（藁

ところで、長い関数を分割するのって、ただの応急処置に過ぎないと思うんだが。

>>234
public hoge(List list) {
　//ズラズラとソート処理
　//ズラズラと分別処理
　//ズラズラと整形処理
}
触りたくないと思わない？
適当な粒度で細分化した方が分かり易いよ。
単純な二分割三分割なら確かに無意味だけど・・・・・・

一関数が長い奴のコードは、そんな簡単に分割できるような処理になってないな。
もっと緻密なコードになってるのが普通。

>>223
というかね、下手に賢すぎるなんて言ったら、お前、
「俺は頭が良いんだ！」「俺は天才なんだ！」「俺は認められたんだ」
「俺は高く評価されているんだ」
と勘違いするバカがいるから気をつけろ。
そのことを>>220は警告してるんじゃないかと思う

>>223
> 要するにまさに >70 のように、一つのメソッドが何でもかんでも抱え込んじゃった
> 「何でも屋」なメソッドの事。
どこが何でも屋だ。

AV機器の端子に喩えれば
昔の端子だらけのRGBケーブルみたいなもんだ。
今ならD端子一つを刺すだけで完了だが、
昔は何本も刺さなければならなかった。
それを何でも屋と名付けるなんて恥ずかしい。

> 初学者がよくやらかすんだよな。それで結局破綻して痛い目を見て
初学者という寄り、オブジェクト指向を否定するバカが
ああいうことをよくやっていた。システム系、信号処理系の
研究室にいた奴がC/C++でそれをやっていた。
「関数だけで十分だ！」と
言い張ってオブジェクト指向のことをろくに勉強しなかったために
メソッドの引数があんなに増えた。アホにもほどがある。
オブジェクト指向ができなくても、せめて構造体くらい使いやがれと。

> > 大体テストどおすんだよ。テストコードとか作んないのか？
> 気合だよ！ヽ(｀Д´)ノ 今日、気合でテストデータ全部作ってやったよ！
> 漏れがんばった！ほめてほめて！！１
ちゃんとxUnit使ってやってるのか？
先にテストコードを書いて本番コードはスケルトンだけを書いておく
ってことをやるはずだが。「気合い」とか精神論持ち出すやつは
20年前の開発スタイルを押しつけるオッサンと変わらんよ。
こんな奴ばかりいるから日本のソフトウェア開発は後れを取っている。
製造業などのハードウェアだけは進んでおきながらソフトウェアに
関してはいい加減な奴が多い。これもハードウェアが威張って
「ソフトウエアはんて名前の通り柔らかいものだから簡単だろっ！」
とか解ったつもりになっているからいい加減になる。

>>226-227
最悪だお前。
まさにブビ忠度炸裂だなw
せめてブビドトネト厨度を炸裂させた方が
高い評価を得られたのに。

それじゃif文が無駄に増えて煩雑になる一方だ。
せめてBefore Afterパターンや
Hook Operatorパターン、Template Methodパターン、
Stateパターンについて勉強して貰いたい。

これらのパターンについて調べれば
お前のやりたいことが叶うかもしれん

>>234
チームで開発するときは
新たな修正が容易になるという利点がある。
ほかにも、いずれ同じ処理を
また書きそうなところがあると
見たときは分割するのもあり、
分割しておいたおかげでメソッドをコールするだけで
済んだ、と言う可能性もある。

>>236
分割したくない理由はどうしてもパフォーマンス
やリソース節約を重視したいとき、だろうな。

それ以外に考えられるか？
それらを考えなければ、積極的に分割すべきだと思う。
分割はそう難しくない。言語にも夜だろうけれども。
「分割して統治せよ」はオブジェクト指向設計原則でも有名な話だ。
詳しくは "Design By Contract" についてググってくれ

DBCって事前条件や事後条件を決めてカッチリとしたコードを組んでいく
Eiffelみたいなやり方だろ。分割と何の関係があるんだ？

>>241
複雑で長い処理が出来上がるパターンとして、不具合や仕様変更に対応するために、
本来はそのメソッドに入る前でやるべき処理を全部そこで辻褄合わせ的に行ってる
というの多いわけで。
根本的には、設計を見直して適切な場所で適切な処理を行うように修正するべき。

>>243
それをプライベートメソッドに押し出してやるだけでも随分すっきりする。
時間は掛からないし、そうできない理由というのも思いつかない。

できないんじゃなくて、もっとまともな解決方法を考えるべきと言ってるだけなんだけど。
どうしようもないのならとりあえずやってもいいだろうけど。

>>244
デグレしても、「あらら」で済む世界ならそうだろうね。

結局長い関数は、機能ごとに適度に分割しろってことじゃん。
前処理とかも同じ事だろ。

たとえば、>>235の例のようにさ。
一つの関数で、ソートと分別と整形処理をやっていたら、
普通はソート関数と、分別関数と整形関数に分けるだろ？

それとも、このソート処理はhoge関数でしか使用しないから、
関数にせずにhoge関数にずらずら書くべきと言う人がいるのだろうか？

やっぱり適度な粒度で細分化するべきだよ。
ソート関数（前処理）、分別関数（中処理）、整形関数（後処理）に分けるべきだよ。

>>245
> できないんじゃなくて、もっとまともな解決方法を考えるべきと言ってるだけなんだけど。
おまえ、会議で何か結論出るたびに、
「もっとまともな解決方法を考えるべき！」と言って、
なにか聞かれたら、「それを考えるのはあなたたちだ！」と言っているだろ？ｗ

その方法使えば、どんなバカでも解決方法が無くても「もっとまともな〜（略」で否定できるなｗ
それじゃ、世の中やっていけないよ。説得力ないし。
自分でもっとまともな方法を提案してこそ意味がある。出直して来い。

>>246
リファクタリングって知らない？
関数に分割する作業ってのは、リファクタリングの一つだよね。

リファクタリングにも取り上げられているように、これはやるべき作業。
おまえが言っているのは、「デグレが怖いから汚いまま放置するべきだ」と言っているに過ぎん。

俺だったら、そんなマイナス思考じゃなくて、デグレなく作業できる
リファクタリングブラウザがもっと成熟して普及してくれとコメントするよ。

＞「デグレが怖いから汚いまま放置するべきだ」
言っておくが、完成してるなら触るなよ。くれぐれも触るなよ。
寝た子は起こしちゃいかん

>>248
自分の意見に合わない提案は目に入らないタイプ？

>>241
＞それ以外に考えられるか？
分割できないほど、密接に絡み合ってるコード・・・の意味だと思うよ

＞public hoge(List list) {
＞　//ズラズラとソート処理
＞　//ズラズラと分別処理
＞　//ズラズラと整形処理
＞}
こんな、単純な例なら誰も苦労しない
ある条件で、ソート順が変わって、更に加えた条件で分別処理が分岐して・・
とか、大抵は「if]ネストの嵐になってる、そう言った「関数」は
1メソッド＝1責務なんて、最初から頭に無いんだから、そう言うの作る人は

＞「デグレが怖いから汚いまま放置するべきだ」
完成してテストする前ならある程度改修する必要があると思われ？

>>248 >>249
学生さん？
あんな酷いことになってる関数・クラスに、まともなユニットテストが備わってると思うのかい？
あんな酷いことになってる関数・クラスが、まともにユニットテストが書けるほどTestableになってると思うのかい？
ユニットテストなしにリファクタリング？そりゃ、大層気持ちが良いだろうねぇw
デグレしても、「あらら」で済むんなら。プロではあり得ないけど。

>>253
そういう場合もあるだろうが、
あんな酷いことになってる関数・クラスは、たいてい
デスマでそんな事する余裕なんかカケラも無い状態で生まれると思われ？

なに醜いクラスを自慢しているんだよｗ
なにデスマを自慢してるんだよｗ

なんで完成してから修正の話になっているんだ？
普通に作っているときに、長すぎる関数は一定の機能、
たとえばソート処理や前処理で普通に分割するだろ。

しない奴要るというのなら手を上げて。

>>1の時点でメンテナンスフェーズでの問題なわけだが。

幸いデスマというわけじゃない。がこのまま放置するともっと悪くなるみたいな予感
そして、こういうものは「しない奴」がいて、「する奴」が後で発見する。
「しない奴」はただ純粋に方法を知らなかったりする。
「しない奴」はこのスレを見ないと思うがどうか？
自分が神経質すぎるのだろうか・・・

>>256
うん、普通は分割するね。
でも、集団で開発してると、中には分割しない人もいたりするんだ。
そういう人が作った汚いコードをどうしようかという話。

> そういう人が作った汚いコードをどうしようかという話。
そういう話じゃなかったはずだが？

まあ、しない奴も多いわけで
原因はいろいろあるけど、ひどいのがプロトタイプを作った奴が
分割してなくそのままコピーして作ると酷いことになることある
実際ソースレビューしてる現場って何%あるんだ？
漏れはその現場に入ったことないな
あとは仕様書通りにメソッド、クラスがないと怒り出し設計者様

１メソッド２０００実ステップは泣けた

ソースレビューやってても、２０００ステップ関数なんてざらにあったりするわけだが。
むしろくそまじめにソースレビューやるようなところのほうが酷い気が。

親会社の社員が作った関数なんで(仕様を満たしてる以上)文句言えなかったり、
関数作るのにも処理フロー書いてSEの許可をもらう必要があったり。

うちはソースレビューするけど2000行はないなぁ。
そもそも、それだけあったらレビュー前に一言「帰れ」で終了だし。

お前らソースレビューなんてやってんの？

>>262
なにを”
俺はまじめにソースレビューする親会社側だが、
２画面以上のメソッドは書かないし当然俺が入ったレビューではそんなの弾くぞ。


といいつつ、今正しく動くことしか考えてない連中もたしかにいるな…。

>>262
学生さんですか？

>>266
お前こそ学生だろｗ

親会社側だが、弾かれた側ってどう思ってるんかね
ソース見た時点でかなり汚れてて、指摘難しかったりするとき。自分で書き直したくなる。
規約とか綺麗なコードの書き方とか低レベルな指摘するのはメンドイ

今動くしか考えてない人に仕様変更言って見積もりさせると、そんなにかかるの？みたいな

指摘しても絶対に直らないって分かる時はどうすればいいの？

俺も入社間もなくは直したいタイプだったが、
そのうち、どうでもよくなったよ。
いや、全然よくないんだが、動いてるソースをいじることは
出来るだけしない。

はっきりいってリファクタリング出来る内容じゃない。

とにかく動くようにしてという依頼受けたら、
とりあえずパッチ当てまくって動くように修正していくしかないわなぁ。
全体の構造解析してたらそれだけで一ヶ月とかかかっちゃうし。

と言うかね、「綺麗なソース」に価値を見出せない
有り難味が解らない人には何を言っても無駄・・
な気がしてきた、最近
疲れたよ・・・

頭にくるんだよね。こっちの分は最初から保守性重視で書いているから
大元の仕様が変わっても修正工数が少ないから半端仕事にしかならない。
なのに「動けばいい」プログラムを書く害虫は修正工数分請求してきやがる。
運良く(非常に緩い)コーディング規約を守ってない関数があったから
減額してやったけど。

そうなんだよね
下手に書けば書くほど、修正工数増えて「売上」が上がる
何か世の中間違ってる

>>268
> 規約とか綺麗なコードの書き方とか低レベルな指摘する
> のはメンドイ

綺麗なコードはいざ知らず、コーディング規則は発注する時
に納入条件として指示するだろ。

指示も無しに、気に入らないから直せと言うのは親会社を傘
に着たわがままだよ。

>>273
「仕様を変えたことで外注さんが修正工数要求したから頭に
きてる。」

おいおい、そりゃ当然だろ。
どんな契約の仕方してるんだよ。

>>275
行間を読もう。

>268は「指示もなしに直せ」なんて話はしていないし、
>273も請求してくること自体を論っているわけではない。

>>276
冷静なレス乙

>>273
そんなくだらないことを理由に減額してたら、
質の悪い害虫しか寄り付かなくなるぞ。
「本質的にコードの質が悪い。動けばいいってもんじゃない」
というのをちゃんと伝えとけ。

保守のしやすいコードを書けって言われても
？？？な奴はどうすればいいか

開発から外せば？

>>276
はっ？ 仕様書の行間を読めって言うエスパーをご所望の
方ですか？

> >268は「指示もなしに直せ」なんて話はしていないし、

>>268 がそういう指示をしてるってこと？
だったら、「低レベルな指摘するのはメンドイ」なんて
ことはないだろ。「納入条件に合うもん持って来い」の
一言で済むと思うけどな。

> >273も請求してくること自体を論っているわけではない。

「害虫は修正工数分請求してきやがる。」って言うのは、
請求自体を ("も" かも知れないけど) を問題にしてるわ
けじゃないと…、なかなか凄い理解力の持ち主ですね。(w

>>278
同意。
ただコードの質と言うものはなかなか規定しづらいので、
>>279 見たいなところがでてくるのは致し方ないのが現実。
>>280 みたいにできればいいけど、なかなか色々な諸事情
で難しいことも多いから、根気良く外注さんと話し合うしか
ないんだよなぁ。

そこでメトリクスツールの出番ですよ。
ただし、スクラッチ開発以外ではそもそも計測困難という諸刃の剣。

>>282
いや、うちもメトリックスツールとか静的コードチェッカ
とかの導入を検討してるんだけど、いい (と思える) コー
ドと、ツールが示す結果との相関関係がなかなか見出せな
いんだよね。まあ、こっちも地道にデータを収集しかない
と思う。

例外が多いとかじゃなくて、相関関係すら見いだせないのか？

ツールはツールに過ぎない。
そもそも「いいコード」が定義可能ならばそれを規約とか検収条件にすれば良いでそ。
>>283
メトリクスの使い方は正しいとは思うけど。
「相関関係が存在する」という根拠は？

導入したことがないから訊いてるんだが、
「相関関係がない」ってのは、どんな糞コードとどんな美麗コードを比べても、
どちらが良いと判断されるかは完全にランダム、ってことだよ？
そこまで使えないの？

いつからコンピュータに美的感覚が判断出来るようになったんだ？

ちゃんとしていて美しいコードに共通する数的性質を、
ソースについて測定するメトリクスについての話をしてるんだが。
その数的性質が、目的通りコードの美しさに相関してるかどうかという話をしてるんだが。

ちゃんとしていて　とか、　美しい　とか、定義が曖昧過ぎて数値化して扱えないのでは？

まず、メトリックスについてググって言おうね。

>>249
そうですね。
>>1で問題としたのはデグレという概念は知ってるが、リファクタリングという概念は知らないプロジェクトですね。
テストプログラムによる自動テストを導入して、各メソッドはこのテストさえクリアしていればバンバン変更していいという状態なら苦労しないのですが。

ただし、仮にテストプログラムに漏れがあって、想定外の動きをしていて、結果的にシステムが正常に動いていた場合、
その想定外の動きの部分が、メソッド修正により変わってしまい、結果的にシステムに異常が発生してしまう（デグレ）可能性があります。
とはいえ、それは自動テストが導入されていなくて、マカロニ修正を繰り返した場合でもデグレの可能性はあるわけで、、、

うーん、リリース前はどんどんリファクタリングやって、
リリース後は大幅な修正でない限り、マカロニ修正でいいんじゃないかと思う。

あくまで私の経験したプロジェクトでの話しですが、最初から最後までリファクタリングの概念がないことが問題なんだと思います。
それに、本番でデグレを起すと本当に大問題になるプロジェクトか、あららで済むプロジェクトかで
話は変わってくるかもしれません。

休み明けに見にきたら、ついにメトリクスにまで踏み込んでましたか。
あんまりツール知らないのでたいしたコメントはできませんけど、相関関係以外に、
「どこまで」を正しいとするか、の判断も難しいと思いますよ。

>>291
リリース後に広範囲に影響するリファクタリングの危険性はわかりますけど、
マカロニ修正を肯定してしまうのも危険かと。どっちが正しいじゃなくて、中間あたりに
落ち着くんじゃないかな。

ttp://www.google.co.jp/search?hl=ja&ie=Shift_JIS&oe=Shift_JIS&q=%83%7D%83J%83%8D%83j%8FC%90%B3&btnG=Google+%8C%9F%8D%F5&lr=lang_ja

>>281
まあ、落ち着けｗ
取り合えずエスパーじゃない人にも分かる様に
説明できる術を見につけてくれｗｗ

>>281
＞なのに「動けばいい」プログラムを書く害虫は修正工数分請求してきやがる。

これは、綺麗にコード書いていたら、３日で終わるような改修作業を、
外注さんが汚いコードで書いたが故に１ヶ月も掛かります。とかいう請求してきたことに
腹を立ててるって意味じゃないの？

俺も部外者だから実際はどうだかわからんがな。

>>279
外注だったら、こういう人は外すしかないだろうね。

プログラマって建築業と似たようなもんだろ。建てればいいってもんじゃない。
地震に対する強度とか、欠陥住宅を建てないようなスキル程度は、
プロとして金もらって働いている以上は必要だと思うからね。

プログラマだったら保守しやすいコードくらい書けないと、働く（金を貰う）資格は無いと思う。
社員だったら教育しなおすか、適正なしとみなして違う部署に飛ばすしか。

まあ、本当に「保守できそうにないコードを書く人」の場合だけど。

>>296
それ以前に数年前の自分の書いたソースに修正を加えられないとか1行直すだけなのに数ヶ月掛かりますとかアホか
鶏じゃないんだ一度書いたら忘れるな

十代の頃とは違って三ヶ月前の自分は他人

>>297
一行直すだけなら、自分でやればいいのに。

>>297
＞鶏じゃないんだ一度書いたら忘れるな
神

俺なんか三日前の夕飯も思い出せない。

＞数年前の自分の書いたソースに修正を加えられない

何がおきるかわかんないからね。ソースを書き直すのより
本当はテストの手間を惜しんでるんだと思う。

>>299
そこは責任範囲とか言う大人の事情って奴ですよ

>>294
丸一日前のレスにレスするんだから、お前こそ落ち着いて書けよ。

>>295
そこで腹立てるぐらいなら、なんで最初のコードを受け入れる時
に文句を言わないのかと。

まあ、程度問題だからこれ以上は具体的なコードとかがないと何
もわからんけどね。

>>300
夕飯は忘れても良い。
でも、自分が書いたソースは忘れない。プロならば。

>>296
それは、そういう規約を作らないとダメ
技術者個人の力量に任せていては保守のしやすいコードにはならない

>>303
暇なんですね

>>303
プロは、自分の記憶なんてあてにしない。

いかに覚えておくかではなく、いかに思い出せるかがプロ。
コメントはそのためにもある。

覚えておかなくても理解できるコードが理想だけどな。
自分の記憶は他人と共有できないしｗ

誰もドキュメントを書くと言わないところが素晴らしい。
もちろん俺も書かない。

>>309
コメントを適切に埋めておけばDoxygenが作ってくれるから自分ではドキュメントを書かない。

>>309
プログラムが、どのような業務・役割を担っているかっていうＳＥレベルの書類は書くけど、

ソースコードがどのような設計になっているかっていうプログラマレベルのはあんまり書かないなぁ。
大体、技術屋だと見てくれないし。まずコードから見やがるし。

共通関数作るとか、ネットワーク処理で独自のプロトコル作るっていうなら書くが。

>>304
規約つくっても、下手なコード書く奴いるじゃん。
５００行足らずで書けそうなコードを、１０００行とか２０００行とか書く奴。

もう最近はおっさんになったので３００行以上超えるソースは見る気しない。

300百行で何が実現できる

>>313
百イラネ

50行以内を目安に書いてるけど、どうしようもない場合は80行以内には抑えてるな

>>313
あっ、１ファイル＝３００行っていう意味ね。
ファイル数はいくらあってもいいけど。

最近は関数も４０行超えると見るのだるい。駄目だ俺。

いや、分かる気がする。
メソッド内のロジックを図化する仕掛けはないからな。
関係を理解するのも面倒臭い。

PADの自動生成ツールってないかね

>>318
昔見たけど、アレ使えネ

自動生成にはXDocletやEclipseのSimteecぷらぐいん
を使え

ドキュメント書かなくなったな〜。
書いても自分も含めて誰も読まないし。
最近は成果物にドキュメント不要の会社が増えたような気がするけどどう？

>>321
PGと対応するドキュメントはソースからの生成で可って会社は増えたね
どうせ顧客側は見ないと言うか、見ても解らないってのが本音だろうが

ソースコードから生成できるドキュメントは
ソースコードから生成すべきである。

ソースコードに対しての補足ドキュメントが必要なら、
それはソースコードに書くべきである。

アジャイルソフトウェア開発の奥義だったか忘れたけど
それっぽい話があったね。

まさにJavadocやXDocletのことだね。

>>1は何か勘違いしてないか？
共通化って考え自体が間違っている。
その仕様を明確にして関数なりメソッドなりを書く。呼び出し側の事など気にせずに。コンパクトに。
そしてそれが、再利用されるだけ。

趣旨がずれてきている。
リファクタリングうんぬんじゃなくて、共通化の線引きのコツを聞いてるんだった。
”最初”にどうやって設計するかを。

同じことを3回やってるなと思ったとき。

テンプレートメソッドパターンとかストラテジパターンとか、
”必要になってから”でも設計変更できるんじゃね？

カン…？

共通処理を書いていて「だるっ」って気分になってきたらたいていやり過ぎ。
そのまま継続してもどうせ無駄なので、すっぱり捨てて観点を変える。

共通化なんて最初から考えなくて良くないか？

初回からまともな設計をするのは困難ゆえ
リファクタリングが発明されたと思う。

>>330
激しくその通りなんだが、それに付いて来れる人は、多分少数派
最初からカッチリ決まってないと、コード書けない人意外と多い

最初に設計したら、その設計意図を守ってコーディングすること。
設計意図を守るのが難しくなったら、意図に沿わないコーディング
するんじゃなくて、設計からやり直すこと。

>>330
ひとりで作っている分にはそれでいい

あまりになんでも１つの共通メソッドでやりすぎてメンテで大変な目にあった現場に
いったことあるな

>>334
共通化でなくて機能設計
なんでも共通のプログラムにすればいいというものではない

なんでみんなあんなに共通化が好きなんだろう…

共通化なんてわざわざ考えない。
確かにコーディング量は減らせるかもしれないけど、それも最初のうちだけ。
いろんなところで「共通化処理」を行ってるとそれだけ結合が増えるわけで、
修正が難しくなるし。
どちらかというと機能・モジュール間の独立性を高める方向で設計する方が
修正も楽だし、別のプロジェクトでも部品として組み込みやすくなる。

コーディング量を減らすのが目的じゃないしな

>>338
コーディング量を減らすのが目的ではないが、きちんとした機能設計をしてあれば
結果的にコーディング量は減る

>>339
糞が書くとどうしてもコーディング量が増える

きちんとした機能設計をするのが目的ではないが、ユーザーの要求をちゃんと理解し、
すべてをちゃんと把握できれば、きちんとした機能設計が出来る。

糞でも意味がわかる、つまりミスリードしないで読めるコーディングにすると、どうしても増える。

システムの上流から、下流までをすべて把握していれば
最小の労力でシステムが作れる。

複雑度を減らすように心がけている。
結果的にコード量は増えることもあるが、トータル労力はたいてい減る。
ただ、例えばデザパタを使ったとき、全く分からない人間というのはいるもので、
そういう人間があとでメンテナンスするときはトータル労力が増えるかもしれない。
要は私にとっては単純に見えることが、
その人にとっては複雑に見えるということだが。

>>336
初心者の頃に受けた
「できるだけ共通化して作業量を減らし、
　不具合の修正も一箇所で済むようにしましょう」
という教育に捕らわれているからでは。

>>345
捕らわれてるってあーた・・・。

共通化大嫌い、コピペ大好きなやつとは、正直仕事をしたくない。

共通化する内容はなるべく単純にするようにはしてるけどな
複雑なものはなるべく作らない

そんなことで悩んでるお前らレベルﾋｸｽ

共通化が好きで、コピペ大好きな奴が多すぎ。

悩まずにコピペでつか

誰もなんでもコピペがいいなんて言っとらん

コピペを排除するには、
ファウラーいうところのトランザクションスクリプトで開発するの止めるか
またはトランザクション毎に担当者をかえるの止めるかすればよくない？
類似ロジックがあるからコピペしたくなるんだろうし。

「共通化」ってのは「結果」な気もするけど
悩むくらいなら、コピペで良いよ
あっという間に生産性が数倍になるし

>>353
コーディングが終わったらリファクタリングせよ

>>354
そうしたいのは山々なんだけど
現実的には・・
手間隙掛けてコード綺麗にしても、ステップ数減って
青果物が少なくなって怒られかねない

>>355
コメント率上げとけ
目標は80％だ

>>355
その考え方はやばいな。ステップ数＝値段か？あんま仕事したくないタイプだ。
ステップ数で金勘定する依頼主も依頼主だと思うがな。さほどの目的もなく開発依頼だしてそう。

>>356
８０％はすごいな。コメント率３５％以上は超えたことないぞ

>>357
ステップ数云々の所ならPG設計書が有るだろうからその詳細説明の内容を関数・サブルーチンのヘッダコメントとして貼り付けるんだ
そうすりゃあっという間に８０％

コメントどれだけ付けてもステップ数はふえんだろ
必要なのはif (hoge) hage()の撤廃だ

if (hoge)
{
hage();
}
ほら4倍

引数の指定ももちろんこうするんだ
int boke(
int a,
int b,
int c)
{
}

コボラのおっさん曰く、
その昔ループを展開するツールまであったそうな。

使う側からすれば、10行で済むところに20行も30行も書いていたら
ブラッシュアップさせるのは当然だ。

適切に絞られた状態でどれだけステップ数があっても、払うことに
やぶさかではない。

ステップ数とか今でも生きてんの？
俺、ステップ数の数え方すら知らんわ

>>362
まだ行数で値段を決めてるのか。
そんなんだから舐められるんじゃないか？

ステップ数は使い方さえ誤らなければ使えると思うよ。
例えばバグ残数の見積もりとか。
定量的データの１つであることは間違いないんだし。

それは、誤った使い方だろう。

>>365
まあ逆に、そのバグ残数の見積もりと極端に合わなかったときが大変なんだけどね。
バグが少なすぎるとテストケース増やしたりしないといけないからね。

開発者によってバグの発生数なんて変わるんだから、変な平均値に合わされても困るぜよ。

>>359-361
たかが一時の１０万円、２０万円のためによくがんばるなぁ。
それで後で保守やバグ対応で、修正に時間かかってたら稼いだ分がチャラになるわけだ。

…あほくさい。

昔、バグ件数が決ってるところの仕事してた時には
「文言がわかりにくい」とか、「ログ出力でスペルミス」とか
プログラム的にはどうでもいいようなことをバグとしてカウントしてたな。

ステップ数が多いと減額の対象にするとおもろいかもな。

それが腐ったやり方だってことを忘れずに仕事は仕事と割り切ってやればいいと思うけどな。
改善点があるということは、自分の評価を上げるチャンスでもあるわけだし。
その会社を見切るという手もあるしな。
まぁうまく立ち回るだわ。

コピペ率を表示すればいいんだよ。
似たようなコードがあればそれをコピペと判断し、
コピペ率が〜だと評価を下げる。

スパゲッティなコードが量産されそうだ。

・コピペするときは変数名を変えること！

・コピペした関数にはダミー引数を与え条件判定で使うこと！

>>374
コンパイラから見れば変数名なんて
なにも意味はありませんよ。

>>375
そんなことをしてもコード自体は似たようなものになる。
あくまで似たようなものであって、同じものである必要は無い。

オブジェクトコードでコピペ率測るんかよ。
じゃあ…
・コピペしたコード内からコピペ用ダミー関数（500個くらいある相互に呼び出し合う複雑な関数群）を少なくとも３つは呼び出すこと！
よし、これでばっちりだな。

>>377
そうか？　例えば次の２つの関数がどちらも２変数の加算だって判定できるか？

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;
}

>>379
今、コピペが悪いという話をしているんだよな？

実際にそれを見て、そのコードがコピペだからやめろというか？
実際にそのコードを”コピペで”作る奴いるか？

>>378
コピペにそこまで手間をかけることを要求すれば、コピペを自然としなくなるだろｗ

>if(double>0) return a+b;
doubleって何？

>if(head->next) return value+length;
valueって何？

>判定できるか？
できません

コピペを禁止するために開発マシンにはクリップボード監視ツールをインストールして強制クリア

コピペ上級者は手打ちを行うから。

じゃあコピペの話はこれで手打ちということで

ここで書き込むのは気が引けるんだが・・・
コピペチェッカならぬ重複コードチェッカならあるぞ
http://www.redhillconsulting.com.au/products/simian/

>>328
やり方や状態にもよるが

むしろ、必要になってから変更できることは
最適化のほう。

>>329
チームで開発するときは勘だけじゃつらいな。
チームがやりそうなことを推測する勘ならわかるが。
それもチームと事前にしっかりとコミュニケをとってくることで

>>337
> 共通化なんてわざわざ考えない。
> 確かにコーディング量は減らせるかもしれないけど、それも最初のうちだけ。
> いろんなところで「共通化処理」を行ってるとそれだけ結合が増えるわけで、
> 修正が難しくなるし。

ちゃんとオブジェクト指向の真価と特性を生かしてないだけだろ。

入力と出力のことしか考えてないで
データに着目すべきだと思うが。

>>386
そんなのがあるのか

漏れとしては
CheckStyleやFindBugsに、
コードを綺麗にしてくれる有り難みを感じる。

>>370
Eclipse のメトリクスプラグイン、
CAP - Code Analysisプラグインを使って
その判定結果で減額の対象にすると面白いだろうな

共通化って本当に可能なのかと思ってる俺ガイル

組み込み系はメモリのことばかり
考えるからそりゃ共通化が難しいだろう。

リソースがたっぷりありゃ
区切りが簡単でどんどん共通化しまくれる。

例えば、業務系でも、共通部分を作っといたとして、仕様変更により、一見、微妙に違う共通部分を作らなければならない状況になったとする。
この場合は、当初の共通化の設計自体がまずかったという可能性が高いのかな？
完璧に粉々にプリミティブな共通クラスを作っておけば大丈夫なはず、とか？

Eclipseのリファクタリングを使うだけで
あとから共通化を簡単に行うことができるケースもある。

できないケースもある。

>>394
インターフェースに変更がなければ大成功

共通化（＝部品化）のメリットのひとつは、仕様変更にともなうプログラムの変更作業を
局所化して全体にその影響を及ばせないことにある。

>>394
巧く部品化できていれば、違う部品が必要なときにそれだけ作れば済む。
全体を修正する愚を避けられれば上出来。

違う部品が必要なのに、部品化に自信を持ち過ぎてその部品だけで
違いを吸収しようとすると、部品の肥大化、保守効率悪化を招くので注意。

部品化、共通化とかで悩んだことなんか無いよ。よっぽどメモリの
厳しいところだと別だが、そのレベルになるとコンパクトになるので
保守性とかあまり関係なくなるしね

まああれだ、大きなシステムなら、アプリケーションの仕様変更
ごときでコンパイルし直しになんかならんように作れ

>>399
「全体が」とかって言葉が抜けてないか

今時はビジネスロジックはXMLで実装するんかな

>>394
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel
サービスレイヤが分厚過ぎるから身動きがとれなくなるのではなかろうか。
サービスも必ずxUnitでテストするルールにしておけば、ある程度レイヤの
厚さは揃うと思う。

経験則ですが、こんなことがあります。
一年生⇒二年生は少しの経験で上がれるが、二年生⇒三年生に上がるには、自分である程度の設計をやって、失敗し、失敗に学ぶしかない。

一年生コーディング：
・ロジックがシンプルでない
・超ハードコーディング
・同じことを何回も書く
二年生コーディング：
・ロジックがシンプルである
・脱ハードコーディング。
・同じことは共通化する。しかし、同じでないことまで無理に共通化し、結果的にぐちゃぐちゃなプログラムになる。
三年生コーディング：
・ロジックがシンプルである
・脱ハードコーディング。
・同じことは共通化する。同じでないことは個別に分ける。結果としてメンテナンス性の高いプログラムができる。

>>402
参考URLありがとう。

読んでみたけど、オブジェクト指向のこのような記事って、いつも具体例の提示が無いんだよね。いつも「それは真のオブジェクト指向ではないからだ！真のオブジェクト指向ではそのような問題は起こらないはずだ！」で終わっている。

実際に大規模なシステムをオブジェクト指向設計でこう書き直したらみんなハッピーになった、というような実例が欲しいんだけど、いつも机上の空論にしか見えない。例を出してもちょことちょこととして小規模のものだけだし。

「真のオブジェクト指向ではそのような問題は起こらないはずだ！が、他の問題が起こってくる。そしてあっちを立てればこっちが立たず・・・・」というところが現実なんじゃないかなと思ったりする。

どうよ？

>>404
真のオブジェクト指向を実現するにはすべての開発者とユーザーがオブジェクト指向を等しく、正しく理解してないとダメなんだろうな

>405
なぜユーザーまで？

>>404
http://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倍参考になるん
でお勧め。

>>407
悪いが自分の言葉で要約とかできないのか？

seesarってよく知らないけど、Framework？
Frameworkってシステム全体から見たら局所だが、これに引きずられて全体も無難にオブジェクト指向的になるという意図でいいのかな？

.NET Frameworkで書けば、システム全体が.NETの思想で無難に・・・・
とか考えるとありえないし、ここでseesarを持ち出してる意図がわからない。

seesar内部という局所では、美しいオブジェクト指向なのかもしれんけどね。

>>408
信者が教祖を敬うのは当たり前すぎてまったく参考にならない
日本のOSS文化とかが閉鎖的になりがちなのはすぐに教祖と信者の見たいな関係になるから
言ってる事は判らないでもないが、その関係に巻き込まれたくないってのが回りの見方

>>404
そうなんだけどある程度時流に乗っていかないと世間で生み出されている
新しいソリューションの恩恵にまったくあずかれないってことになってしまうし。

まあ今考えるとDIコンテナもテストフレームワークもなかった時代の
OOPの生産性が構造化設計のときより高かったかっていうと結構疑問かも。

seasarはDIコンテナっていう、フレームワークの一種。
フレームワークっていうもの自体の制約でコードが全体として
美しいオブジェクト指向でなくなることはあっても逆はあまりないんじゃないかな。
ただしDIコンテナはそれ以外のフレームワークよりも、開発者がコードをオブジェクト指向的で
あらしめようとする努力を阻害しないというか、オブジェクト指向の恩恵を受けやすくする。

>>410
その「新しいソリューション」に本当に価値があるなら良いんだけど、
中身の構造がオブジェクト指向になっただけでできることは同じ、
とかで他との相互接続性のためだけに入れ替える羽目に、
とかだとエンドユーザは浮かばれないよな

恩恵にあずかってるのはシステム刷新でまた金が入るシステム屋だけ、
ってのもどうかと。

だいたい、うたい文句は保守性と再利用が売りのオブジェクト指向のはずなのに、時流が変わったので本の数年で全部入れ替えです、ってどうなのよ？

正直言って DI なんて 百害一利くらいだと思うんだけど何で流行ってるんだろ…？
ってのはどっかにスレがあるかもしれんけど。
最初に作るうえでは、
・コンパイルタイムチェックのほとんどが活用できなくなりうざ
・むやみに名前(名前空間)が増えてうざ

他人の作ったものを解析/メンテするときなんて
・オブジェクトの実装がどこにあるのか探すのがうざすぎ
・ひとつのオブジェクトの定義が複数の設定ファイルにちょっとずつ定義されてたりしてうざすぎ
・とにかく設定ファイルばっかし、あほか
・へたくその作った DI 使用のシステムなんか、コーディング/設計の意図が読めなさ過ぎ
普通に型システムを活用して作ってくれてるほうがいい

唯一じゃないかとすら思える利点が
・テストファーストができる
くらいなんだけど…。大規模で未成熟開発者割合が多い場合はまた違った利点があるかもしれんけど、圧倒的な読みにくさ(追いにくさ)はそれに余りある負の要素じゃないかと思うんだが。

どう考えても作者の「こんなことができるかも」「もしかしたら便利かも」という趣味と妄想の賜物だと思う。

趣旨に戻ると、共通化ってのを意識しすぎるやつはだめコードを書く。先にかかれてた二年生かな。
重要なのは部品化、というよりは粒度の小ささと「独立性」。
DI は依存性を減らすために考案されたってことになってるけど、本質的に依存関係にあるものを無理やり設定ファイルから注入するようにしても読みにくくなるだけってな話だ。

自分の机や部屋が散らかってる奴は大抵プログラムも汚い。整理整頓を心がけよう。
俺? 俺はもうぐちゃぐちゃ・・

追いにくい、コンパイル時のチェック機構を・・・
なんていっているのは設計が出来ていないだけだ

それにDIの言っている依存性の軽減もはき違えてるしなぁ。

本来、オブジェクト指向での依存といえば、
あるオブジェクト（A)が、他のクラスのサブクラスもしくはサブタイプのオブジェクトを使用する、
これだけだ。

ただ、それを実装に落とすとどうしても、オブジェクトAはどのサブクラス・サブタイプを
インスタンス化すべきかを知らないといけないことになる。

その依存（どのクラスをインスタンスかすべきか）をなくすのがDIだ。

オブジェクト（A)が、他のクラスのサブクラスもしくはサブタイプのオブジェクトを使用する

この依存をなくすものではないよ。DIは。

>>416
その通りに書いてあるように見えるが。

>>415
少なくとも DI フレームワークを使っていて追いやすいものを見た覚えはないよ。
みんな設計できてないんだねぇ。
ってまぁ、たいして見たわけでもないけどさ。今のところ使いたいとは思えないな。

＞あるオブジェクト（A)が、他のクラスのサブクラスもしくはサブタイプのオブジェクトを使用する、
＞これだけだ。
あたりまえ。

＞その依存（どのクラスをインスタンスかすべきか）をなくすのがDIだ。
だから、それを設定ファイルとかに過剰に書くから追いにくいといっている。

もちろん自分だって実装クラス名を設定で与えるような設計をすることはある。
ただし、設定で実装を指定するようなものの数を極力減らすのがよい設計だと思うけどね。
spring とか使ってるプロジェクトの中身を見ると結構悲惨だったよ。

解りやすいように補足。
インターフェイスの依存が排除できないのは当たり前。
# adapter などのことはより話がややこしくなるので除外
で、実装の依存を排除したいのはわかるが、実装のバリエーションが想定すらされていない段階からそれをやろうとするやつが多くて困るってことさね。
テストファーストのためだけだったりすると萎えまくりだ。
部品単体の中身の見通しがよくなっても流れがわけわかになってる。
ま、大体そういうコードはインターフェイス仕様を決める段階で間違ってんだけどね。

sage

＞ただ、それを実装に落とすとどうしても、オブジェクトAはどのサブクラス・サブタイプを
＞インスタンス化すべきかを知らないといけないことになる。
＞その依存（どのクラスをインスタンスかすべきか）をなくすのがDIだ。

お勉強でなぞなぞやってるんじゃないから、なくした場合の成果をまず書くべきだろう。
オブジェクト指向に取り付かれている人は、よく「美しく実装できる」とか、現場が本来求めていない帰結に達するときがあるので、着地点のアピールはきちんとした方が良い。

で、前半部分だが、オブジェクト指向にしたから出てきた問題なんじゃないの？

すまんが、俺理論で作ったら行き詰まったので俺理論・改を考案した！以上の意味には取れなかった。

俺、DIって

設計のときに書くクラス関係図とコーディングの時に書くnewを
別のConfigファイルに書くもの

みたいな意識しかなかった。
だからクラスの呼び出し先が変わったりしたときにコード部分をいじらなくて済みますよと。

>>413
Spring- IDEを使え。

っていうかpackageが増えてどういう問題があるのか

どこに package が増えて問題があるなんて書いてある？
「名前空間が増える」の意味を勘違いしてないか？

>>422
クラスの呼び出し先が変わるときは普通コードがかわるっしょ。
呼び出すクラスを変えるとき、だよね？
で、呼び出すクラスを変えることがどの程度の頻度でおきるのか、とね。

ちなみに、運用時でも切り替えられるところを売りにしていたふしもあったように思うけど、
運用時に spring の設定ファイルだけを変えて駆動させるクラスを切り替えるという
需要自体があまりない(*)上に、ほぼ切り替えの対象にならないものまで
いっぺんに書かれた設定ファイルは運用者にはまず理解できまい。

*:ないわけではない。むしろ運用者に切り替えさせることに意味のあるケースも多い。
問題はそういうものとそうでないものをきちんと分けて設計されないケースが
多くなってきていること。

うまく使うと「フロントエンド」＋「ビジネスロジックplug-in」＋「データマッピング」になったりはせんの？
よーしらんけど。
あと設定ファイルは分割できんの？

うまく使える人が多いといいんだろうけどねー。
どっちかというと下手に使うというか、喜んで過剰に使う人が多いなと思う。
で、>>423 とか >>415 みたいに(テストファースト以外の)具体的な利点を書けない人と
違って >>422 とかはまがりなりにも便利と思った点を書いてくれてるのでそこを意識すると、

「設定ファイルを見ることでクラスの関係がわかる」みたいな話もどっかで見た覚えはあるね。
struts とかかｗ。あれも破綻してたけど。
結局設定ファイルを変えるだけでどうにかなるような修正要求なんてほとんどないでしょ。
それは別の話としても、見通しがいいかというと、設定ファイルに書かれるのは実装クラス
であってインターフェイスではないし、その設定ファイルを書くために必要な情報、つまり
どのインターフェイスの実装クラスを書けばいいのかとかどのプロパティがセット可能なの
かとかが簡単にたどれないという点で大きなロスがあると思うんだがその辺はどうなんだ
ろね。springIDE なるものはそんへん解決してくれてるの？

すでに書かれた設定ファイルを見る/修正するにせよ、新たに設定ファイルを書かなければ
ならない立場にせよ不都合のほうが多いと思うわけよ。
interface なら型保障されてるのに設定ファイルは型保障されてないっしょ。

DIに否定的な意見があることに驚いた。

コードの読みにくさは「やりたいこと(設計)」「する必要があること(実装)」が
入り混じることに原因があり、コードの改造に伴い設計が腐っていくのは「する必要が
あること」のコードの変更が「やりたいこと(設計)」のコードに影響を与えることに原因が
あると考えるとDIは設計のコードを実装のコードの分離を促進することから、新規で
コードを書くときも既存のコードを改造するときもメリットがあるとおもうんだが。

>>421
「美しく実装できる」＝見やすく改造に強いコード
って言う意味であれば、まさに「現場」が求めていることそのものなんじゃなかろうか？

上流工程にCOBOLの呪縛から逃れられてない何かがあるからDIが使いづらいんじゃないの？

驚いてほしくて書いてんのさ:)
一番腹が立つのは他人の書いた DI 使ったコードの改造だが、それはいったん置いといて。

「やりたいこと(設計)」ってのはなんだか変でないかい？
どこまでを「設計」と呼ぶかの解釈の違いかもしれないけど、
自分はコードに近いところの設計＝クラスの関連とインターフェイス
あたりのレイヤで考えてるが、それって「やりたいこと」じゃないっしょ？
設計ってのは大雑把に言えば役割と責務を決めることっしょ？

さて、「インターフェイスと実装を分けて作るようになることが期待できる」
という意見と解釈したが、それをインターフェイス設計のできない人間に対して
適用しても、いっそうぐちゃぐちゃになると思いませんかい？

インターフェイス設計ができる人間は DI なんぞ使わなくても必要な箇所は
インターフェイスにして不要な箇所は static メソッドなり単体の entity 的な
クラスにするなりできるのよ。

injection に相当する部分は、*それが本当に実装クラス名を埋め込むとまずい
場合に限り*、外部パラメタで実装クラスを切り替える factory なりを経由させるでしょうて。

どんなクラスにも interface が作られている状況って、最近の OO 信仰者にはうれしいんだろうか？

>>427
springIDEで、bean同士の関連図見たいなものを表示すること、図中のbeanを
クリックすることによるソースコードへのジャンプ、設定ファイルエディタによる
設定可能インタフェース(の実装クラス)やプロパティの候補表示あたりは実現されてる。

(続き)
それと、設定ファイル上のbean参照の型チェックもやってくれる。

続きだけど。

DI の概念が役に立つケースを上げておくと、既に
>>418 や >>425 >>431 でもさわりを書いたけど、
・多数の振る舞いを区別なく、切り替えやすい形で提供する(メニューリストとか)
・異なる環境で同じ振る舞いを保つために実装を切り替える(データソースとかテストケースとか)
ような場合。

つうかまぁ以前からやっていたそういうことに
DI という名前が付いたものだと思ってるから当たり前だけど。
# 念のため。批判的なのは DIDI と喜んで使いたがる連中に対してさ。

で、意味ねー、ってか害だと思うのは実装が一個しかないことが現時点で確定しているものに
いちいち interface を作って、それだけならたいした問題じゃないが、実装クラスをわざわざ
ぜんぜん違う場所にある設定ファイルに書いて、さらにその初期化にあたるプロパティのセット
まで設定ファイルに書いちゃうという愚行とか。

「分離できたこと自体に意味がある」って、こんなのがずらずら並んでて、初期化が全部そこに
固まってるならともかく、一部クラスはコンストラクタやどこからともなく呼ばれる
init 系メソッドで初期化コードを書いてた、とか、DI じゃなくても解釈が面倒なコードを
いっそう読みにくくされてたら腹も立つって物さ。

なんであれ使う人間の問題なのだが、DI コンテナは使う人間に問題があった場合に
使っていなかった場合以上に修復可能性を減らすとは思っているよ。

>>432
type属性まで入力すると、子要素のプロパティとして指定できる候補や
各プロパティ値として記述できる reference 名なり実装クラス名の候補が
出せるってことよね？
書く手間に関してはこの辺のインスペクタが充実すればだいぶましになるだろうね。
読む側のサポートは関連図ね。うーん、自分は図よりコードのほうが理解しやすいタチ
だから図の出力にあまり利便は感じないけど、たぶん spring 使うにはほぼ必須ツール
っぽいね。

んじゃそろそろ本題へと…ってだいぶスレ違いだな…

>>413
だれも突っ込んでないようだが、
DI使うと、型システムのどの辺りが活かせなくなるのか？

まあ、コストが実利に見合うかっていう疑いは大事だけどね。
ただ、それは特定の技術だけではそれは決まらなくて、条件によって大きく変わるわけだ。

実行しなくても自動的にエラーをガンガン見付けてくれる型システムも、
数十行の書き捨てスクリプトではウザイだけ、とかね。

DI コンテナ使うシステムが数十行の書き捨てで作れたらいいのにね。

# 書きかけが消えたorz 面倒なので本題だけ
クラスの関係が変な設計になっているようなものをリファクタリングするのに
苦労するってのがもともといいたかった一番の問題。
普通に Java コードで閉じていれば相当変な設計のものでもリファクタリング
できる自信があるが、DI のようなものが多用されていると、どこから参照され
ているかを意識しながら変更するのに異常に神経を使う。
バグ混入率高く、発見しにくいだろう。
テストファーストならリファクタリングできるって？
クラスの構造からおかしなものについてテストファーストで書かれてたら
いっそうリファクタリングに苦労しそうだ。

ま、これも「設定ファイル」が Java のコードとシームレスに検証/検索できるよう
になれば変わってくる話だとは思うがそんなんになると重量級IDEでしか開発
できなくなってつまらんなぁ。

寝る前にちょっと補足を。
DI 関係のフレームワークを作っている開発者のことを貶す目的はまったくありません。
賞賛します。
# 煽り口調はここが2chだからということとそのほうが反応がきやすいから、など。
# spring の ActionProxy とかはちょっとなぁとか、細かい点ではいろいろ思うけどね。
自分のやり方を公開する予定も無く、現状コミュニティに入ってまで方向性を
変えさせようという余力のない状態で努力自体を貶したいわけではない。

また、それに乗っかる人自体もOSSが盛り上がるためには必要と思っている。
今日ここに書いたのは、まぁ結局愚痴みたいなものだけど、とりあえず DI も
OO と同じく銀の弾丸では無いんだってことを盲目的な利用者方面に伝えたい、
ってところ。喜んで使うんじゃなくて使う必然性のあるところで使ってくれよ、と。
んじゃ。

>>437
＞DI コンテナ使うシステムが数十行の書き捨てで作れたらいいのにね。
>>436の答えになってないし、>>436はそんなことひとつも言ってないんだが。

それに、DI使うとリファクタリングがどうやりづらくなるのかが解らん

DIってメニューレベルの機能選択とか、EDIなんかの連携先変更とかに使う物だろ

設計と言われて思い出したんだけど、
最近のオブジェクト指向って、設計と実装の間に溝がないかい？

設計だけやってあと知らねーっていう高給取りが増えて、今後もそういう人材が求められてるらしいけど、その手の設計って実装に素直に落ちにくい気がする。

UMLからソースコードジェネレートとかいう話も聞くけど、実際に見込みはあるんかねー。

将来はコンサルタントが要件定義したら後はできあいの部品を繋ぐだけで実装できるようになるから、実装屋はいらない！コンサルタントに上がれない無能は氏んでね！
って話もよく見る。

実装と設計に乖離がなくてすんなり完成するシステムは金を生まないのでプロジェクトとしては失敗である
所謂コンサルタントやＩＴ企業の経営者はプロジェクトが動く事により金を得ているのですんなり完成するプロジェクトは悪とみなしている

プロジェクトが早く終わったからって次の仕事があるわけじゃなし、どうせ支払は工数ベースだしな。
顧客の我慢の限界ぎりぎりのところまで工数を引き伸ばして金を搾り取るのが常套手段。

工数なんて水増しが当たり前だと思ってたけど、違うの？

基本設計のフェーズで実装までできるやつはほとんどいない
たいていコーディング・テストのフェーズあたりで実装できる人を
集めるから大変なことになる

>>441
UML=うそつき丸め込み用ランゲージ
でｵk？

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

>>414
大抵か、そうでもなかったり。
社内に机が汚い香具師がいるが
ソースコードだけは綺麗。

つまり、現実世界では汚いが
コンピュータの中では綺麗。

あてにならないもんだね。
性格がだらしなさそう、面倒くさがり屋な
香具師はたしかにソースコードも汚いし
オブジェクト指向も勉強しようとしない

俺は性格だらしなくて面倒くさがり屋だけど、ソースは綺麗に書くぞ

>>424
普通パッケージと言ったら名前空間のことだろ
もう世界の常識

Javaだけの話だろ
名前空間はNamespace

普通の感覚なら"パッケージや名前空間"と表現すると思うがな
あと、日本語で書くのがミソ

Perlもpackageだな。

>>451
UMLでも使われているが

いやむしろjavaがパッケージにしたせいでそれにあわされてるとか。

Javaは名前空間とパッケージはひょっとして分離できないのか？

なにが言いたいんだ

日本語でおｋ

javaでは名前空間のことをパッケージという。

ディレクトリ構造がなぁ〜ってことでぶぅ

Javaではディレクトリ作らなくてもパッケージを作ることができる。
C++やC#などとの違いは、一つのファイル無いに複数の名前空間を
定義できないというだけ。

>>461
ん？実際に作ってるだろ？
作ってアーカイブで隠してるだけのような

作っても作らなくてもｲｲだけなんだが。
もちろんつくったほうがクラス名(ファイル名)が被らなくて済む。
パッケージ名は異なるがクラス名は同じというクラスを問題なく
作ることができるから。

> Javaではディレクトリ作らなくてもパッケージを作ることができる。
実際に作るよな？

なんか、ソースファイルのパッケージ／ディレクトリとクラスファイルの
パッケージ／ディレクトリがごっちゃになってるぽ

ディレクトリを作らなきゃいけないのはSunのjavacの仕様だろ
javac以外のコンパイラだとディレクトリ作らなくてもいいやつがあるんじゃね？

>>466
DOS向けの奴だと、ファイル名＝クラス名である必要は無いな

Sunのjavacの仕様っていうか、Sunが提案した仕様から逸脱したらもうすでにJavaじゃないと思う。

Javaって仕様の塊の事だし。
SunはJavaの仕様に沿った実装を例として配ってるようなもんだし。

>468
>Sunが提案した仕様から逸脱したらもうすでにJavaじゃない
「Java」ってのが「Java言語」のことだとしたらそうなんだが
「パケージ⇔ディレクトリ」ってのはSunが提案した「Java言語」の仕様なのか？
もしそうだとしたら，>467の言うようなDOS版は非Javaということになるが

なんか450から下誰にも通じてなかったみたいね…
「名前空間が増える」だよ。
名前やらパッケージが増えるんじゃなくて。

間接参照が増えるってことよ。あるものを参照するために、
それを指し示す名前(を定義する必要のあるレイヤ)が一段余計に必要になるってこと。

間接参照が多段化すると飛躍的に追いにくくなるでしょ？

トップダウンで理解してればわりかしそんなこともないぞ。
目先のコードを追っかけるだけじゃ、だめだぞっ。

ん？ >>470はパッケージが増えることが混乱の
元になるとでも言いたいと？

パッケージの中にパッケージを入れれば
混乱しないわけだが。

『アジャイルソフトウェア開発の奥義』
をみればパッケージ管理も楽になるほうほうが
わかるんでね？

>>471 慣れはあるとは思うが…。
そういう考え方する人＝慣れた人が過剰な DI 利用設計をやるんだろうね…。

大体設計フェーズしかできない人間は他人のコードのデバッグも
当然できないからそのときのコスト計算もできないんだろうなぁ。
つうか、それは設計フェーズもできてないってことだけどさ。

あと、ただ理解するという目的であったにせよ、名前空間が
増えているのはやはり本質的によくない。おまけに設定ファイル
ってことで言語まで分かれているわけだし。
まぁ自分は simple 至上主義だから多少偏ってるだろうとは思うが、
DI とか好きな人の中には simple ってキーワードも好きな人が多いだろうに
simple を追求して simple じゃなくしているところが笑える。
(DI の考え方とかじゃなくて喜んで DI フレームワークの機能を無理やり
使おうとするような人のことだよ)

「simple」なお脳しかなく範疇化もできないおぽんちさんは
コードに埋もれて地虫のごとく這いずり回ってりゃいいだわさ

>>473
全てのソースコードを1クラスに押し込めれば、名前空間もクラス名もファイルも
1つで済む。だけどそれはsimpleってこととは違う。
simpleを追求すればするほど必要な名前(=概念)や名前空間や設定情報は増えていくよ。

>>475
> >>473
> 全てのソースコードを1クラスに押し込めれば、名前空間もクラス名もファイルも
> 1つで済む。
トンデモCOBOlerがやったというあのアホ臭い実話か。
今でも似たようなことやる奴がいるからマジでウザイ家ドナ

>>473
DIフレームワークの機能を使うってところにどうもひっかかりを覚える。
DIが解決するのは仕様とかビジネスルールみたいな厳密な抽象を
コンフィグの取得方法とか永続データのストア方法みたいな曖昧な具象
を分離することじゃなかろか。
要は、なんか即物的なメリットを求めてDIを使うってのは違うような気がするってこと。。

>>473
それは違うでしょ。もちろん外部から注入されるべき「設定」は増えるが、
simple な「設定構造」にしておかないと現場の普通の人たちがすぐについていけなくなるのさ。
自分が作るなら苦労はしない。本質をよくわかっていない DI 設計厨や、その設計の
おかしさを指摘できるスキルの無いプログラマたちの作ったコードをメンテさせられて
みなって言ってる。

>>477 日本語と用語の意味が取れません。
即物的なメリットを求めないなら、宗教になるよ。
自分はきちんと使うべきところに DI の概念を使うけどね。

>>478
低脳コーダに囲まれてたいへんれすね！

>>479
「俺以外のヤツは低脳で使えない」て思ってるやつほど
周りから「あいつは口だけ立派だが仕事をやらせると使えない」
なんて思われてたりしてなｗ

これは勉強になるスレですね。

何かの本に
再利用コンポーネントをつくるのはそうでない場合に比べ３倍大変
みたいなことが書いてあった。俺の感触と一緒。

共通化・再利用って言葉は聞いてる分には良く聞こえるけど
ある意味投資だから回収できる見込みがあるか十分検討してからやるべきだと思ふ。

サブルーチン{
　多重ループ{
　　共通処理Ａ
　　ちょっとだけ違う処理
　　共通処理Ｂ
　}
}
ってあったら皆どうしてる？

状況としては「ちょっとだけ違う処理」のバリエーションを
たくさん作りたい。

多重ループ内で関数呼び出しコストももったいない。
共通処理はそれなりに記述行数はある（インライン
asm含む）

環境はＶＣ６。ぱっと思いつくのは共通処理ＡＢをファイル分けて
includeするくらい。defineしようにもインラインasm含んでると
うまくいかん…。

テンプレートとかでやりようがあるでしょうか？　いまは素直に
たくさんサブルーチンをコピペで作ってますが、メンテがしんどい

>>483
「ちょっとだけ違う処理」の数だけサブルーチンを作りたいのか?
サブルーチンは一個で「ちょっとだけ違う処理」の数だけ分岐したいのか?
いずれにしても、関数呼び出しコストが問題になるような状況でメンテ云々を言っても意味ないと思うが。

> 多重ループ内で関数呼び出しコストももったいない。
は、リーリス版で性能比較した結果を受けての判断だよな？

「ちょっとだけ違う処理」はサブルーチンに入った段階で確定するのか？
それとも共通処理の結果如何で処理内容が変わるのか？

×リーリス版
○リリース版

なんで変換できちゃうかな。

＞関数呼び出しコストが問題になるような状況でメンテ云々
共通部分の変更でコピペした奴全部反映させるの、面倒だし
忘れそう。そこのところだけでも何とかなればと。

＞サブルーチンに入った段階で確定
呼ぶ前に確定。なのでテンプレートとか使えないかな、
と考えてるんですが、型で処理を分けてるというのとも違う。

ファイル分けてincludeもスマートからは程遠いし…、似たような
ことしてる人居ませんか？

インライン関数を持つ関数オブジェクトを使うか、
コードジェネレートするのが良いと思う。

設定が局所的に意味あるカテゴリにまとまってるって、それだけSimpleな構成だと思う
その構造のままハードコーディングした状態が一番わかりやすい状態かと。

>再利用コンポーネントをつくるのはそうでない場合に比べ３倍大変
>>14で負の動機付けって言われてるけど
コードを共同所有してるって意識で、勝手に変更できて、他人が使ってくれるから自動的にReview状態になる。
ってチーム構成なら楽なんだけど。

>>487
呼ぶ前に確定なら、>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
...;
}

あーいけね、ボケてら。
呼ぶほうは
void caller() {
...;
#define FUNC_TYPE 1
#include "func.h"
#undef FUNC_TYPE
...;
以下省略で、
func.hにvoid func()の代わりにコード直書きと。

>>490
ども

泥臭いけど
void f(int type)
{
　switch(type){
　case 1:
　　多重ループ{
　　　共通処理Ａ
　　　ちょっとだけ違う処理
　　　共通処理Ｂ
　　}
　　return;

　case 2:
　　多重ループ{
　　　共通処理Ａ
　　　ちょっとだけ違う処理
　　　共通処理Ｂ
　　}
　　return;

　　　：
　}
}
でも、局所化はできるし、判定も関数突入時の１回だけだから、性能的にも問題ないんじゃね？

共通処理ＡＢを如何にまとめるかを考えてるところ。

改変、デバッグ時にコピペは避けたい。４９０の方法は良いと
思うけど、共通処理の部分にブレーク張る時どうなんだろ。
メンテはある程度あきらめるしかなさそうだが…。

話それるけど、こういうケースを効率的に記述できる言語ってある？

関数ネストができて、インライン展開が保障されてて、親関数の
ローカル変数にアクセスできるような言語があればなあ…。

つ[アセンブラ]

ちょっとした処理の前後の共通処理に、アスペクトと言い出す奴はまだいないか？
まあどんな環境でも実用的に利用できるとは言いがたいんだけど。

共通化と部品化は違うよな？

共通化ってのはmodeフラグとか受け取って中身でmodeフラグ見て分岐して別処理となってしまう。
部品化ではその別処理の部分を別関数にして実装することになると思う。

共通化で仕様変更があるとmodeフラグが増えて書き直し。
部品化では仕様変更があると部品が増える感じ。

どっちが良いのか？

オブジェクト指向云々では部品化のほうをとるんだろうけど。

そしてポリモー じゃない？

#define _MyMacStart 　多重ループ{ 　　共通処理Ａ
#define _MyMacEnd 　 　共通処理Ｂ 　} }



サブルーチン{
_MyMacStart
ちょっとだけ違う処理
_MyMacEnd
}

一人文盲が混じっているらしい。

>>499が受理されるなら
#define SYORI(s) 多重ループ{ 共通処理Ａ {s} 共通処理Ｂ }
で充分。
それができんからどうすべかねってわけだ。

template化はInt2Typeとか使えばなんとかなるが、インライン保証との両立が難しいねぇ。
templateはコンパイラに、マクロはプリプロセッサにコードを自動生成させる機能だから、
それで無理なら自分で自動生成させる機能を作成するかだね。

>>501
十分だけど、さすがに
SYORI(
int R=*p++;
int G=*p++;
int B=*p++;
)
みたいに実装部を書くのは格好悪いでしょ

>>499
一応>>483で書いたつもりなんだけど、実際上の問題として、
インラインasmが入ってるとVC6ではそれ出来ない。

アセンブラの改行を要するところ（ラベルとか）とプリプロセッサの
１行にまとめなきゃいけない仕様がどうしても折り合わなかった。

行末に\を付けてもどうにもならん…うまい書き方ないもんか。
なんにせよデバッグ時はスマートにはいかないけど。

>>503
つ【カスタムビルド】と【外部ツール】

>>503　ラベルを使ってなければ _asm mov eax,x;_asm mov eax,edx; みたいに複数を書ける訳だよね？

ラベルが必要って事は分岐命令？　どんなコードを書いてるの？
キャリーで分岐するようなコードなら条件代入とかに置き換えらればその方も速度が上がるけど

>>505
書けないよ。
（厳密には書けはするけど";"以降はコメント）

あと、普段アセンブラ含むようなのはBCBでしか書いた事が無いからアレなんだけど

BCBなら
int x;_asm mov eax,xx; _asm lab:;_asm add eax,x;_asm jnc lab;
てな感じで1行に書けるからVCでも試してみて

>>506
そうだっけ？　確かVCは":"を入れなくても複数行を書けたと思うし ";"セパレータも効いたと記憶してるのだけど

こんなふうに
__asm mov eax,ebx 　__asm add eax,ecx

507は　

int 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言語側のラベルを使うべきかもしれない

>>508
だからね、インラインアセンブラで";"はセパレータじゃないんだよ。
";"なしで１行に書くことはできるが、その後ろにＣのコードを記述することはできない。

とりあえずチミは
　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;
を試してから話しなさい。

>>510　ホントだ BCBとだいぶ違うんだね

1行に書くには __asm そのものをセパレータにしなければならないみたい

int n=1; __asm {mov eax,n __asm lp1: __asm add eax,eax __asm jnc lp1 __asm mov n,eax}

>>511
その書き方は試してなかった。それで１行にかけるんなら情報ｻﾝｸｽ

BCBでは >>511の書き方は出来ないみたい

結局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のラベルを使うようにする必要があるみたい

CMOVを使えるなら、多少長くなっても分岐より高速だね

ある程度設計した上でコーディング進めて、
仕様変更などでどうしようもなくなったらリファクタリング、でいいんじゃねえの？

マクロを作るのも共通化にはいい方法だよ。
>>1のような場合には、処理A,B,Cの違いの部分を　マクロで表現出来るように作っておくだけ。

アセンブリ言語の記述でポータビリティが欲しいならアセンブリのソースは外出しにしろ

いやだ。中出しがいい。

>>514
実際に動かしてみないとなんとも・・・
分岐予測が当たってる間は分岐のコストは低いから。

そうかな。無条件分岐でも単純演算に比べたら結構コスト高くないかい？

さて、それはどうかな…

CMOVってはっきり言って微妙。同時期にMMXも使えるようになってるから
そっちに労力割いた方が全然いい