いつもお世話になります。
雑談というか相談です。
3つのFormで、同じような処理をする、13行くらいのmethodがあります。
このmethodには11個の引数を渡していて、それを渡せば、共通のmethodにできます。
public void commonMethod(引数11個){
//それぞれの引数に対する処理。
}
ということです。
これって、共通化してsimpleになったと思えますかね?
引数が11個という時点で、simpleとはいいがたい気がして、別々に実装したほうがいいかなと悩んでます。
引数を減らすためにclassを作るのも大げさだし。
こういうときって、みなさまなら、どうします。
雑談モードでお聞かせください。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/11/30 05:58
2015/11/30 06:05
退会済みユーザー
2015/11/30 06:39
回答8件
0
「重複するコードを括り出してはみたが、それを呼び出すコードが同じくらい複雑」現象、と一般化できますか。
一般論でお答えしますと、その現象にぶつかったときは「括り出すべきかどうか」を議論する意味はあまりなくて、もっと全体の処理フローがまずくないか、そちらを見ていく方が正しいアプローチです。
今回の話ですと、13行の処理が11個のパラメータを必要としている時点でデータの凝集度がいまいちで、オブジェクト同士が疎結合になっておらず今後もいろいろな苦しみに遭遇しそうであるなあと感じます。
とは言えあまりプロダクト設計全体の議論もここではできませんからその13行の処理についてもう一回フォーカスしてみますと、ラムダ式を渡す形にすることで引数をシンプルにできたりしませんか?
投稿2015/11/30 03:46
総合スコア5568
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/11/30 04:11
退会済みユーザー
2015/11/30 04:24
退会済みユーザー
2015/11/30 05:07
退会済みユーザー
2015/11/30 05:48
退会済みユーザー
2015/11/30 08:06
2015/11/30 10:50
退会済みユーザー
2015/12/01 00:13
2015/12/01 03:41
0
フォームが異なっても、渡す引数が共通であるなら、シンプルになったんじゃないですか。
フォーム1では1番目から9番目の引数が使われ、フォーム2では1番目から5番目と8番目から11番目の引数が使われ、フォーム3では3番目から9番目の引数が使われる、というように「どのフォームに使うのかを意識して引数を決めなければならない」メソッドであるなら、混乱の種を撒いただけだと思います。
質問に書かれている『同じような処理』は、何が同じで何が異なっているのか次第じゃないですか。
それを、きれいに整理できないのであれば、1つのメソッドにまとめるのは誤りです。
きれいに整理できないという事は、動作の把握が困難なきたないコードを書かざるを得ないという事ですから。
投稿2015/11/30 03:05
総合スコア6915
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/11/30 04:07
退会済みユーザー
2015/11/30 04:22
退会済みユーザー
2015/11/30 05:33
0
「リファクタリング」によれば
既知のオブジェクトに問い合わせることができる場合:「メソッドによる引数の置き換え」
複数の引数が1つのオブジェクトにまとまっていれば:「オブジェクトそのものの受け渡し」
引数をオブジェクトにまとめる:「引数オブジェクトの導入」
コメント欄や追加修正欄でのやりとりを踏まえてですが、
とりあえず画面ありきでプログラミングするのをやめましょう。
(私も昔はそうしていましたし、そう言われてもいまいちよくわかっていませんでしたが。)
画面に何でも実装するのは、「分けて実装するのが基本だが、面倒なので」という上級者向け行為です。
クイズの例で言えば、作りたいのはクイズであって画面ではありません。
クイズの出題/回答をする部品(クラス)を作ってから、それを操作する画面を作りましょう。
番号を順番に並べるクイズの例であれば、順番があっているかどうか判定できればいいのですから、
引数11個も必要なく、そもそもstring1つ(か何か)で済む話です。
これを画面ありきで作ると、
・解答欄がある
・何個あるかは解らない
・じゃあ複数ある場合で共通化しよう
・引数が11個になった
という謎の構造になります。
まずすべきことは問題の出題形式のグループ化です。
(順序を答える、単一の名称を答える、n択問題、可能なかぎり列挙する、などなど)
こういう状態を指して、「もっと全体の処理フローがまずくないか検討した方がいい」
と指摘されていると思います。
例のように、複数のテキストボックスに回答を入力し、複数のチェックボックスで正誤を表示するなら、
画面がテキストボックスの入力状況から回答文字列を生成し、クイズクラスに採点をお願いし、
結果を受け取ってチェックボックスを操作するのが「シンプル」だと思います。
また、現状ですと、例えば3択問題100個つくったら
subformX.cs
をX=1~100
作る気でいるようですが、
クイズクラスを作れば
・3択問題クラス
・3択問題回答用画面クラス
・3択問題を何らかの方法で100個生成するクラス
で済みますね。
投稿2015/11/30 07:29
編集2015/11/30 08:00総合スコア13528
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/11/30 08:00
2015/11/30 08:19 編集
退会済みユーザー
2015/11/30 09:26
0
こんにちは。
程度はあると思いますが、シンプルにはなったと思いますよ。
アプローチの仕方はケースバイケースですが、Formに実装された処理であればインスタンスメソッドでしょうか。
であれば抽象化した上で同じじゃない部分だけオーバーライドさせる方法もありますし。
静的メソッドであれば引数の渡し方は多少改善は出来るかもしれません。
構造体だったりクラスを引数として渡す。処理の内容によってはフォームインスタンスを渡す場合もあると思いますし、特定のインターフェイスを実装した上で引数として扱う場合もあると思います。
全ては共通化したい処理次第です。
でも、少なくとも複雑化はしてないと思いますよ。(同じ「ような」処理ってのが気になりますが…)
投稿2015/11/30 03:11
総合スコア4791
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/11/30 04:17
退会済みユーザー
2015/11/30 04:26
2015/11/30 04:40
退会済みユーザー
2015/11/30 05:26
2015/12/01 03:07
退会済みユーザー
2015/12/07 07:06
0
実務では他人のソフトをメンテナンスすることが(なぜか)多い自分ですが,引数11個,というのは失笑モノ,というレベルですね(残念ながら実装されているケースはあります…).
書き込まれた内容と少しずれますし,今こういうふうに設変かけられるわけじゃないのは承知していますから,ここから先は遊び半分でお読みください.
(ガッツリと問題クラスを実装するほうがメリットが大きい,というのは別として)簡易実装でこんなの考えてみました.
以下の様な構造体
・問題文
・正答(配列1番目)
・誤答(配列2番目以降,たとえば最大5件までで,誤答数は不定,最後は空文字列)
これを構造体配列として問題集を作ります(フォームを表示する前とか,問題集を取り込むタイミングで生成します).フォームへは構造体の1要素を渡し,設問を出す方のフォームで問題文を表示,解答一覧をランダムで散らす,という実装です.
これは正答数が一つの場合ではありますが,言いたいことは**引数のハンドリングは複雑になればなるほどミスしやすくなり,その結果,意図しない動作を引き起こすことにつながる,**ということです.
問題形式が複数あるんだよ,ということですが,この構造体形式が違うようにできればフォームの呼び出しメソッドをオーバーライドすることによって問題形式の多様化にも柔軟に対応できると思います(フォームのデザインはオーバーライドされている個々のメソッドで必要なパネルを引っ張りだしたりする).
とりとめのない文章になってしまって申し訳ないのですが,ニュアンスを汲んでいただけると幸いです.
投稿2015/12/01 13:38
退会済みユーザー
総合スコア0
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/12/08 08:52
退会済みユーザー
2015/12/08 10:27
0
どんな状況下でも
(引数11個)
は、却下ですね。
シンプルになったかどうかの評価は、ハッシュやテーブルを使うなどして 引数が 4個程度になってからです。
投稿2015/11/30 21:16
総合スコア22324
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/12/01 00:12
0
設計を考えずに判断すると、メソッドに切り出し出来るのならした方が良いと思います。
同じコードはないほうがいいからです。
設計的な視点から見ると、そのコードを共通化するメリット・デメリットを挙げてみたらどうでしょうか?
・これから共通コードが再利用される可能性はどの程度あるのか
・以降、共通コードが変更、または増えそうな見通しはあるか
・『単純に同じ処理してるから』で括ってないか? 『たまたま同じ処理』ということはないか?
・今は共通だがもしかしたら共通でなくなる可能性はないか
・13行を共通化するとトータルでコードがどれだけ減るのか(逆に引数11個セットするのにコストかかってないか)
引数が多い問題はクラスで渡すほうがいいと思います。
パラメータークラスを作る手間を惜しんでいる方をたまに見かけるのですが、そのクラスを作るメリット・デメリットを挙げてから判断してみては如何でしょうか?
要はそのクラスを作る、保守するコストに見合ったものが得られるかどうかです。
設計的に見たら、引数が多い問題は見なおしてみたほうが良いと思います。
例えば共通メソッドにせず、クラス化して切り出したらどうでしょうか。
この場合、メソッドの引数には本当にその時必要な引数のみを渡すことが出来ることが多いです。
例えば引数にTextBoxを渡してメソッド内でTextプロパティを変更しているような場合、TextBoxそのものは予めクラスに渡しておけますよね。
投稿2015/11/30 04:20
退会済みユーザー
総合スコア0
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/11/30 04:27
退会済みユーザー
2015/11/30 04:54
退会済みユーザー
2015/11/30 05:04
退会済みユーザー
2015/11/30 05:22
退会済みユーザー
2015/11/30 05:30
退会済みユーザー
2015/11/30 05:54 編集
退会済みユーザー
2015/11/30 06:36
退会済みユーザー
2015/11/30 08:00 編集
退会済みユーザー
2015/11/30 08:04
退会済みユーザー
2015/11/30 08:08
0
提示されれた情報だけではわかりませんが、ひとつのまとまった機能は1ヶ所で定義してそれを共有するのが王道だと思います。システムの調査を依頼されて、大企業でも消費税率をひとつのfunctionを作って共有しようとしないところはびっくりしました。わたしが調査できたのはごく一部でしたが、たぶん作ったサブシステムか個人毎に作っていたのかも?
投稿2015/11/30 03:32
総合スコア16415
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/11/30 04:13
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。