共通化の線引がむずかしい
■ このスレッドは過去ログ倉庫に格納されています
0001大根
2006/02/21(火) 23:58:00共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。
処理Ａ、処理Ｂ、処理Ｃがあったとして、この３つは横展開の関係にあります。
３つも実装するのは大変なので、全て共通化して実装した（methodX(A）を読んだら処理Ａを行うイメージ）。
だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。
後々思うことは、
最初から処理Ａ、処理Ｂ、処理Ｃは別々に実装すべきだった。
もちろん共通化すべき部分はあるので、下請け処理の共通部品は必要だが、
大元の処理そのものを共通化したのは失敗だった。
なんで、こんな失敗するんでしょう？
最初からＡ〜Ｃはほとんど同じ実装で済むと思っていたのが、
想定外のバグ、仕様漏れ、仕様変更等により、Ａ〜Ｃが乖離した結果、マカロニ化してしまうんですね。
けれど、「想定外」のことを想定して設計なんてできないんですよ。
皆様、設計時にどこまで共通化すべきかという基準ってありますか？
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責務なんて、最初から頭に無いんだから、そう言うの作る人は
■ このスレッドは過去ログ倉庫に格納されています