トップページ⇒tech
522コメント208KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001大根2006/02/21(火) 23:58:00
プログラムの共通化は作業軽減＆メンテナンス性向上の為に重要だとは思うんですが、
共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。

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

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

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

皆様、設計時にどこまで共通化すべきかという基準ってありますか？
0002デフォルトの名無しさん2006/02/22(水) 00:02:43
2秒しか読んでないけど
目が痛い
偏頭痛もする
0003デフォルトの名無しさん2006/02/22(水) 00:08:46
>>1
そもそも似て非なるものを1つにまとめたらスパゲッティーになるのは当然。

>もちろん共通化すべき部分はあるので、下請け処理の共通部品は必要だが、
>大元の処理そのものを共通化したのは失敗だった。
答えはでてるじゃん。
同じ機能を共通化するのはいいけど、同じ流れで違う機能のものは共通化しちゃだめ。
スーパークラスかインターフェースを統一するのはいいけど、1本のプログラムで色んなことやっちゃだめ。
0004デフォルトの名無しさん2006/02/22(水) 00:10:24
ダイヤモンド継承が問題をはらむのと同じように
構造化においてもダイヤモンド型の構造は危険。
0005デフォルトの名無しさん2006/02/22(水) 00:10:36
さぶくらすれすぽんすびりてえだって
おっかあがいってたよ
0006デフォルトの名無しさん2006/02/22(水) 01:00:44
>>1
文脈切り替えが幅広く出来て
部品がきちんと整理されてればいいんですけどね〜
（私は部品に、機能まで入っちゃう）

>>4
それだ！

機能を呼び出している文脈が違ってたりするんですけどね。
0007デフォルトの名無しさん2006/02/22(水) 01:06:58
ロジックの共通性とオブジェクトの共通性は別の性質。
一言で済ますと、ロジックの共通性は継承を用いて記述してはならない。
ロジックの共通性を括り出す場合は委譲を用いて記述するのが定石。
0008デフォルトの名無しさん2006/02/22(水) 02:32:30
>>1
構造化言語使いなら、処理内の機能を更にサブルーチンに切り出し各処理ではサブルーチンの呼び出しの形にする

イメージはこんな感じだ
処理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
>>1
>If (処理Ａの時のみ）...のような記述が増え
この記述をした時点で負け。
0010デフォルトの名無しさん2006/02/22(水) 10:05:02
・・・まあいいから騙されたと思って
「制御結合」で検索しなさい
0011デフォルトの名無しさん2006/02/22(水) 10:54:27
>>1
お前、そのクラスの名前だけど
・○○マネージャ
・××エクゼキュータ
なんて感じで命名されてないですか？

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

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

言い回しは違うが>>7と同じことを言ってるつもり。
0012デフォルトの名無しさん2006/02/22(水) 11:04:21
>>1
OO以前の、
1970年代後半位の頃のモジュラープログラミングの本を
読むことをお勧めします。
0013デフォルトの名無しさん2006/02/22(水) 11:32:11
関数は、１画面に収まるように書けって習っただろ？
そういうことだよ。
0014デフォルトの名無しさん2006/02/22(水) 11:38:58
もっとプラグマティックな問題として、
共通化すると
自分勝手に変更できなくなって、しかも他人が使うという観点からも保守が必要になる、
という負の動機付けが多すぎる。

と言うわけで、同じような処理や他人のコードのコピペが蔓延しているのはどうしたものか。
0015デフォルトの名無しさん2006/02/22(水) 11:44:33
>>13
＞関数は、１画面に収まるように
宿題ならともかく、無理

１関数数千行、１ファイル数万行が数百ファイルなんてざら
0016デフォルトの名無しさん2006/02/22(水) 11:47:09
＞宿題ならともかく、無理
なぜ？単に厨PGが多いだけだろ。
いや、自分が書いたんじゃなくてそういうコードの保守をさせられてるのなら苦痛は察するが。
0017デフォルトの名無しさん2006/02/22(水) 11:52:43
if (xxxx) {
　　xxxx
} 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
>>18
元の文章書いたのとは別人だが自分は関数やらメソッドやらは一画面に入るようにしてる、
まぁ縦に長い画面使ってることもあるけど。
メソッドの場合は長いコードになると意味のまとまりができてくるのでリファクタリング
することできれいになるし。（応答速度がマイクロ秒以内とかを気にしなければいけないリアルタイム組み込み系だと無理だけどさ）
0022デフォルトの名無しさん2006/02/22(水) 12:36:40
＞ 考え方や概念の一貫性

これが難しいというか、面倒なんだよ…。
0023デフォルトの名無しさん2006/02/22(水) 12:55:41
>>19
メソッド呼び出しのオーバーヘッドすら問題になる分野だろう。
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
>>24>>25
＞それなら日本語の識別子
つVC8
0027デフォルトの名無しさん2006/02/22(水) 13:57:13
>>24>>25
＞それなら日本語の識別子
つJava
0028デフォルトの名無しさん2006/02/22(水) 14:08:32
仕様を決める時に一人で画面の絵と説明だけ書いて終りにしてるのがいけないんじゃないか?
0029デフォルトの名無しさん2006/02/22(水) 14:14:46
そうだよな。
とっくに日本語識別子なんてOKなのに、なんでみんな使わないんだろう。

プログラムが超解りやすくなると思うんだけど。
0030デフォルトの名無しさん2006/02/22(水) 14:18:36
GRASPパターン
実践UML - パターンによる統一プロセスガイド
http://www.amazon.co.jp/exec/obidos/ASIN/4894713861/

カップリングとコヒージョンをOOPに当て嵌めて合わせたものだから
構造化を勉強した人には何を今更って内容だろうが、構造化を知ら
ないOOP世代には必須。
0031デフォルトの名無しさん2006/02/22(水) 14:30:02
Spring Framework使って見れば共通化も楽になると思う

Java意外の言語版Spring Frameworkも出ているので
試してみてはいかが?
0032デフォルトの名無しさん2006/02/22(水) 14:46:19
>>30
＞構造化を知らないOOP世代
なんだそれ？　OOPったって記述の末端は構造化プログラムだろ
0033デフォルトの名無しさん2006/02/22(水) 14:58:32
>>32
構造化 = レガシー、オブジェクト指向 = モダンという認識の者を
指して、「構造化を知らないOOP世代」と評した。
OOP世代は構造化を知らないとは言っていない点に注意。
0034デフォルトの名無しさん2006/02/22(水) 15:37:46
>>33
その時代を知らないの意で使った訳ね？
0035デフォルトの名無しさん2006/02/22(水) 16:12:48
>>3
1ではないが耳に痛い

ついさっき同じ過ちをして今書き直してる
やっぱシンプルが一番だわ
0036デフォルトの名無しさん2006/02/22(水) 16:23:02
>>33
「『構造化を知らないOOP世代』とは言ったが
『OOP世代が構造化を知らない』とは言っていない」

こんなド屁理屈が本気で通ると思っている>>33にカンパイｗ
0037デフォルトの名無しさん2006/02/22(水) 16:29:39
class A {
　//略
};

class B : public A {
　//略
};

class C : public A {
　//略
};

と派生すれば良いんじゃね？
0038デフォルトの名無しさん2006/02/22(水) 17:08:51
>>37
それだと、Aの一部の機能が、Bでは必要なくなった。
またはそこだけ処理が変更になったときに最悪。
↓がいいと思う。
class ABC {
　//ABC共通処理
};
class A {
　ABC kyotsu;
　//略
};
class B {
　ABC kyotsu;
　//略
};
class C {
　ABC kyotsu;
　//略
};
0039デフォルトの名無しさん2006/02/22(水) 17:38:37
>>30
むしろそれはオブジェクト指向を知らない
構造化手法オンリー世代にうってつけだと思うが

と思ったがやっぱオブジェクト指向しらないと読みにくそうだから
彼らには難解だろう
0040デフォルトの名無しさん2006/02/22(水) 17:44:51
違うだろ。派生だろ。　>>38じゃ死滅したＣＯＭと同じ運命辿るだろ。

class BASE {
　//略
};

class A : public BASE {
　//略
};

class B : public BASE {
　//略
};

class C : public BASE {
　//略
};
0041デフォルトの名無しさん2006/02/22(水) 17:54:09
>>37-38,>>40
それらのやり方だけでどうにかなるケースは
ありうるがどれもこれもそれだけじゃ足りないケースもありうる。
不要になりそうな者が出てくる可能性がある場合は
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
>>29
命名が下手な奴が混じってる時点で日本語でもダメ
命名が下手な奴が訳解らん名前付ける位ならむしろ機能ID＋連番でプログラムを作ってもらっても構わない

どうせ、初期化()、初期化前処理()、初期化後処理()とか付けときながら前処理→メイン→後処理の順番で呼ばなかったり
後処理メソッド内に初期化メソッドの呼び出しが入ってきたりする
0047デフォルトの名無しさん2006/02/22(水) 19:44:27
>>45
何の為のネームスペースか！
それがカテゴライズに迷うロジックなら、それは
そもそも汎化する必要がないロジックなのだ。
0048デフォルトの名無しさん2006/02/22(水) 19:50:43
>>45
1つに収めず複数のユーティリティクラスに分割する。この場合、機能単位ってのもありかも。
オブジェクト指向には合わないけど、Mathみたいな感じで。
でも基本的にはインスタンスと結びつかないメソッドが、どんどん増えるって状況が変だと思う。
0049デフォルトの名無しさん2006/02/22(水) 19:54:48
>>46
それに加えてだけど、日本語での名前は、大分類‐中分類‐小分類の順に字が並ぶから、
一見して何を表しているのかわかりづらいってのがある。
データベースの表名とか、そうなっちゃうこと多いよね。末尾の1字だけが違う別のものとか。
0050デフォルトの名無しさん2006/02/22(水) 20:19:50
小手先のプログラミングの話じゃなくて分析設計の話じゃないのか？

まだ実装を意識すべきでない段階で実装図面を引いたからこうなっちゃったんでしょ。
0051デフォルトの名無しさん2006/02/22(水) 20:23:40
設計の段階で想定外のバグって？
0052デフォルトの名無しさん2006/02/22(水) 20:26:16
構造設計してないだけだろ
0053デフォルトの名無しさん2006/02/22(水) 20:27:58
>>50-52
kwsk
0054デフォルトの名無しさん2006/02/22(水) 21:01:33
>>1
>だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。 

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

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

試しに聞いてみるけど、その「共通」関数って一体「何行」あるの？
0055大根2006/02/22(水) 21:13:22
>>42
>ただし、惨事を起こす前にやばいと思ったら分離しろ。
>この辺の見極めがセンスや経験だな。
確かに。諦めて作り直すことも１つの勇気ですね。
分離せずにリリースまでいってしまうと、保守の時に修正時影響範囲に怯えないといけない。

ただし、分離作業＝作り直しであって、これ自体がちょっとした惨事です。
そうなる前に見極めるにはどうしたらいいですか？
0056デフォルトの名無しさん2006/02/22(水) 21:28:11
>>55
何か、>>1 の言葉の端々から、腐りきった大規模業務系の
臭いがプンプンするんだが・・・(w
0057デフォルトの名無しさん2006/02/22(水) 21:33:31
>>56
おいおい、>>1の能力が不足してるだけの話で業務系とか大規模とか関係ねえぞ
0058デフォルトの名無しさん2006/02/22(水) 21:35:07
ここはひどい雑談スレですね。
マ板逝ったほうが盛り上がりますよ。
0059デフォルトの名無しさん2006/02/22(水) 21:38:26
同じような処理をするから共通化という考えが間違ってるということだ。
0060デフォルトの名無しさん2006/02/22(水) 22:26:45

話をぶった切らせてもらうが、マカロニとスパゲッティは同じなのか問い詰めたい。
0061デフォルトの名無しさん2006/02/22(水) 23:02:26
> お前、そのクラスの名前だけど
> ・○○マネージャ
> ・××エクゼキュータ
> なんて感じで命名されてないですか？

やべー、結構こんな感じの命名あったりするんだが・・
何でもかんでもマネージャに任せないようにしてはいるんだけど。うーん
なんだかんだで、ＸＸManagerってつけちゃったりしないですか？？
0062デフォルトの名無しさん2006/02/22(水) 23:24:42
>>1
その共通化した部分にはどういう名前がついてるんだろう？行数よりもそっちの方が気になる
きちんとした名前がつけられてるならまず、その概念を定義したことが間違いであった
とはならないはずだ、作っていったらそんな概念が実際にはなかったことになったとはならないでしょ
for文くらい一般的すぎて取り上げるまでもなかったというなら話は別だけど

そもそも、当初きれいに共通化されていたものが、全体的な仕様がだんだん増していく中で
そうでなくなるというのは当たり前の話であって
そういった事実からその共通化の判断が誤りであったということにはならないのでは？
仕様が流動的に変化するなら、プログラムの全体的な構造も必要に応じて変動して然るべきだと思うが
0063デフォルトの名無しさん2006/02/22(水) 23:40:33
変化ヲ抱擁セヨだね
0064デフォルトの名無しさん2006/02/22(水) 23:40:59
>>45
> ちょっとずれるかも知れないが、
> 共通化をするためにstaticメソッドのみの共通クラスを作ることがあるのだが、
> どんどん膨らんで、収拾がつかなくなりつつあるのだが、どうすればいい？

Facadeパターンを使え。

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

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

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

0065デフォルトの名無しさん2006/02/22(水) 23:46:10
>>37のようなやり方は最悪だな
機能を追加するたびに
継承していくってことは
あどでどんな大惨事が待っているか
想像がつく。
引き継ぎ人が大変だ。

ってか以前>>37のようなコードを
引き継いでかなーりｳｻﾞｯって思ったことがある。
オブジェクト指向のことわかったつもりになって
やたらと継承しまくって分割統治もせずに
平気で継承するクラス＝バージョンアップされた差分クラス
と勘違いするところがウザイ。
だからクラス名は継承するたびにクラス1,クラス2,クラス3
とかわけのわからんものになる。
しかもメソッドまでmethod1(), method2()とかアフォなネーミングになる。
かなりウザかった。こんなコード書いた奴の会社に
殴り込みに行ってぶっ飛ばしてやろうかと思った。
バージョン違いなんてソースコードの上でやるな馬鹿野郎。
バージョン管理システム使って管理しやがれや。
継承をバージョン管理に使うなアフォ
0066デフォルトの名無しさん2006/02/22(水) 23:53:12
>>46
> >>29
> 命名が下手な奴が混じってる時点で日本語でもダメ
> 命名が下手な奴が訳解らん名前付ける位ならむしろ機能ID＋連番でプログラムを作ってもらっても構わない
それじゃCOBOLerの二の舞だぞ。
かなりウザいんだが。
そんな奴、殴ってやりたい。
連番はSubversionが自動的につけてくれるからメソッド名やクラス名にまで
つける必要はない、というかむしろ害悪だ。不要悪だ。
クラス名やオブジェクト名はなるべく名詞形でキャメルケースに
メソッド名はなるべく動詞形で先頭の頭文字だけ小文字にしたキャメルケースに、
そしてメソッド引数は目的語が入り、そのときのメソッド名にはcompateTo(Object)のように
動詞 + 前置詞 + ( + 目的語 + ) のような組み合わせになるようにしろ。
こういう命名規則を守れ。

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

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

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

0067デフォルトの名無しさん2006/02/22(水) 23:55:16
>>54
> >>1
> >だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。

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

0068デフォルトの名無しさん2006/02/23(木) 00:00:27
>>61
Manager相当クラスが他のクラスにアクセスするための
Facadeになっていればそれでもオッケ。
ただしやたらと多すぎたら考え直せ。
もっと抽象的な名前を考えろ。
これって何？　と聞かれてすぐ答えられるような名前がいい。
何をするかはっきりしていればもっとマシな名前を思いつく。

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



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


とりあえずデザインパターンやアジャイルの本を読めば
良い名前を思いつく。
0069デフォルトの名無しさん2006/02/23(木) 00:40:48
みんちーが来た。このスレももう駄目だなorz
0070デフォルトの名無しさん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:34
卵をtmgはなんかかっこいいな
0074デフォルトの名無しさん2006/02/23(木) 01:56:10
とりあえず腹が減るサンプル禁止
0075デフォルトの名無しさん2006/02/23(木) 02:09:34
>>70のせいでラーメン食いたくなってきた
0076デフォルトの名無しさん2006/02/23(木) 02:25:56
tuyKsa は
tuyKos か tyuKsa が「正しい」ような気がする

もしかして接頭詞とそうでないのでは省略規則が違うとかなんだろうか
0077デフォルトの名無しさん2006/02/23(木) 08:50:41
>>70
というか、引数の意味不明な略語は何だ。そこからしてNG。
0078デフォルトの名無しさん2006/02/23(木) 08:52:40
だれか、>>14 に答えてくれる猛者はおらんかの
0079デフォルトの名無しさん2006/02/23(木) 09:24:44
>>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のように、のように自己責任でしる！、
とすれば差分コーディングだお。
0080デフォルトの名無しさん2006/02/23(木) 09:27:29
誰かに振ったコードの中は見ない。挙動がおかしかったら直せ。以上
0081デフォルトの名無しさん2006/02/23(木) 10:00:19
>>79
>>14は、共通化がおかしいって問題じゃなくて、
共通化はちゃんとできるとしても共通化自体をやりたがらないって問題なんだけど。
0082デフォルトの名無しさん2006/02/23(木) 10:16:57
>>81
まず、共通化できるから共通化するという動機が変。
0083デフォルトの名無しさん2006/02/23(木) 10:17:35
だから、派生を学べばコピペできなくね？

だって派生元クラスから派生後クラスにメソッドコピペしたら、
さすがに頃されるだろ。
0084デフォルトの名無しさん2006/02/23(木) 10:19:58
共有化部分が大きすぎるんだよ。
細かく部品化すれば、その場その場で異なる挙動に組み立てやすい。
希望の部品がなくても、小さい部品なら自作するのに労力も少ない。
0085デフォルトの名無しさん2006/02/23(木) 10:45:14
>>82
言いたいことは解るけどさ、
全体の設計のモデル化とは違うレベルでの共通処理・共通機能ってもんが実際あるでそ？
例えば、どのクラスに所属してもしっくり来ないメソッドをXXXutilクラスのstaticメソッドにしたりするでしょ。
あるいは大規模開発で、
設計レベルのモデルとは別の観点からのちょっとした共通機能とかってのが出てくるでしょ。
そういうの。

>>83
処理の共通化のために継承使うってのは、ほとんどアンチパターンだとおもうが。
0086デフォルトの名無しさん2006/02/23(木) 10:48:16
>処理の共通化のために継承使うってのは、ほとんどアンチパターンだとおもうが。

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

ふつーに思考してみ。

プログラムとは記述。
記述のために各種文法があり、どの文法を使っては逝けないという決まりは無い。
記述は少ないほうが良い。
継承は文法の１つに過ぎない。
0087デフォルトの名無しさん2006/02/23(木) 10:48:24
>>81
それはプログラムの個々の設計をスキルの無いコーダーに任せるからか、その様な設計を行う作業時間をちゃんと取らせないから
0088862006/02/23(木) 10:52:35
試しに、「ある分野の処理」ってのをクラスにすると、
そこにメソッド束ねられて読みやすさマンセー、
さらに類似処理で、あ、ここだけ処理差し替えでおｋ、マンセー、と分かるお。

だけど、「ある分野」という言葉はあっても、「ある分野の処理」ってのは現実世界に無い物体なわけだけど。
0089882006/02/23(木) 10:55:48
もっと言うと、
読みやすさマンセー、で、差分コードで書く量削減で、
アンチパターンんも何も無いだろ。

これでＭ＄の洗脳解けた？
0090デフォルトの名無しさん2006/02/23(木) 10:56:07
>>86
＞これって、ＷｉｎＤＮＡ時代のＭ＄の宣伝に騙されただけ。
は？？
＞どの文法を使っては逝けないという決まりは無い。
…唖然。
OOPを勉強した方がよろしいかと…。


>>87
せっかくだが、>>14を読んで言って欲しいんだが…。
0091デフォルトの名無しさん2006/02/23(木) 10:56:52
差分プログラムは楽だけど、実際の処理の流れが見えにくくなるという問題点がある。
大事なのはバランス感覚。
0092デフォルトの名無しさん2006/02/23(木) 10:57:48
>>86
>>90ではちょっと暴言だったな。詫びる。
しかしだ、
＞「ある分野の処理」ってのをクラス
これはありえんよ。
クラスは、物（の種類）であって、処理ではない。
0093デフォルトの名無しさん2006/02/23(木) 10:59:22
だいたい、OOP以前に、普通に構造体で考えたって、おかしいでしょ。
0094デフォルトの名無しさん2006/02/23(木) 10:59:28
>>92
設計レベルではそうだけど、実装レベルではあるんだよ。
コンパレーターとか、ファンクタというクラス使うことが。
0095デフォルトの名無しさん2006/02/23(木) 11:00:46
>>92
>これはありえんよ。 クラスは、物（の種類）であって、処理ではない。

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

人の言う事を理解しようとする気が無いなら折角の回答が読めないだけだお。
0096デフォルトの名無しさん2006/02/23(木) 11:03:36
>コンパレーターとか、ファンクタというクラス使うことが。

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

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









ファンクタってなんだけ？
0097デフォルトの名無しさん2006/02/23(木) 11:04:47
コンパレータやファンクタは、比較・処理などの機能を持った「物」であって、「処理」じゃないでそ。
現実世界に対応する「物」とはいってないお。仮想上の「物」。
0098デフォルトの名無しさん2006/02/23(木) 11:04:57
架空と現実って言葉に振り回されてるだけ。
0099デフォルトの名無しさん2006/02/23(木) 11:05:01
どーでもいいが、処理の抽象化で出す例は、普通はドキュメントじゃなくてIteratorなわけですが。
0100デフォルトの名無しさん2006/02/23(木) 11:05:22
関数もオブジェクトです。
0101デフォルトの名無しさん2006/02/23(木) 11:06:56
>>94
あ、でも、それだよそれ。設計レベルじゃなくて、
その位の実装レベルで立ち現れるクラスとか共通機能とかあるでしょ。

そういうのを、みんな共通化したがらない、というのが>>14。
■ このスレッドは過去ログ倉庫に格納されています