- PR -

分岐が多数ある機能の実装方法

«前のページへ 1|2|3|4 次のページへ»
投稿者投稿内容
リミット
会議室デビュー日: 2004/02/04
投稿数: 17
投稿日時: 2007-06-19 09:29
引用:

一郎さんの書き込み (2007-06-18 17:33) より:
かなり複雑そうですから、アクティビティ図などでモデリングはしているわけですよね。
こんなソースはどうでしょうか。
・
・
・
並列処理などもなさそうなので、アクションとその後の分岐(Decision Node?)を合わせてひとつのクラス(Action)で表現してみました。
モデルとソースの対応関係がはっきりしていてアクションの追加などもしやすいと思います。


一郎さん、レスポンス及び具体的なソースの提示、有難う御座います。
確かにこの方法でしたら、追加には柔軟に対応できそうですね。
さらに、Action毎に分かれているので管理の面からもよさそうですね。
参考にさせて頂きます。
リミット
会議室デビュー日: 2004/02/04
投稿数: 17
投稿日時: 2007-06-19 10:48
unibonさん、レスポンス有難う御座います。

> プログラムとはそういうものではないでしょうか。
> すなわち、if/switch があるからプログラムなのではないでしょうか。
そう言われるとそうですね。分岐なくして、プログラムは成り立たないですね。
その管理をうまくする(スマートにする)にはどうすればよいのか、というのに
悩んでいます。

> おそらく、データーとプログラムの中間に位置しそうなモノを、
> プラグイン的に差し替えできるような感じで扱われたいのだと思います。
> 本格的なものだと、アプリケーションが自前のスクリプトエンジンを持っていて、
> ユーザーがスクリプト(マクロ)を書くというのになるかもしれません。
スクリプトエンジンのようなものも考えましたが、そこまでするのはおおげさかなと．．．
でも、本格的にするならその方法が良いのかも知れませんね。
リミット
会議室デビュー日: 2004/02/04
投稿数: 17
投稿日時: 2007-06-19 10:51
引用:

無理に簡素化しようとして可読性を損ねたりすると、それこそ、オブジェクト指向の面からして本末転倒であります。

じゃんぬねっとさん、回答有難う御座います。

おっしゃる通りだと思います。かなのコード量が予想されますので、可読性は最重視すべき項目だと
考えております。その上で簡素化できればなぁと今は思っております。
リミット
会議室デビュー日: 2004/02/04
投稿数: 17
投稿日時: 2007-06-19 10:55
引用:

その100もの処理を、ひとつのクラス内で行う必要はあるのでしょうか？
処理をある程度グループ分けできるなら、同じIN/OUTを持つクラスをいくつか並べても良いのでは、
と思いました。

ひとつのクラス内で行う必要は全くありません。言われている通り、ある程度のグループ分けは
行いたいと思います。しかし、クラス分けは本当にその人のセンスが問われますよね．．．
リミット
会議室デビュー日: 2004/02/04
投稿数: 17
投稿日時: 2007-06-19 11:06
引用:

七味唐辛子さんの書き込み (2007-06-18 19:43) より:
あんまり凝ったことすると　メンテナンスが非常に困難な
プログラムになります。

if文とswich文を羅列だとしても　うまくクラス化　関数化　構造化
すれば　それなりにすっきりします。

七味唐辛子さん、レスポンス有難う御座います。
仰るとおりだと思います。実際にコードを書いて色々試している
んですが、凝ったことをすると見にくくなってしまいます。

クラス、関数を適切な構造にすることで対応するのが、最も良いのかと
思っています。
あすか
ぬし
会議室デビュー日: 2006/07/12
投稿数: 309
投稿日時: 2007-06-19 11:16
レスが遅くなりましたが
インターフェースを書いたのは
インターフェースを統一した方がいいから、
という理由です。

以上
Yun
常連さん
会議室デビュー日: 2007/01/25
投稿数: 22
投稿日時: 2007-06-19 20:49
こういうプログラムに、
全然実用方法のわからない、
Workflow Foundation（.NET Framework 3.0）を使って、
実装もメンテもしやすく！なったりしないのでしょうかね。

#ふと思っただけなので、見当違いだったらすみません。
ぼのぼの
ぬし
会議室デビュー日: 2004/09/16
投稿数: 544
投稿日時: 2007-06-19 21:56
こんばんは。

超憶測ですが、簡単に例えるなら、
「自動車保険の保険料を決める処理」みたいな感じでしょうか？
保証内容、車種、等級、家族構成、特約の有無など、
様々な条件によって出力がずんずんかわっていくという、
想像するだけで頭が痛くなりそうなプログラムｗｗｗ

皆さんメンテナンス性、可読性重視でコメントされてますが、この手の複雑な処理では、
「テストのしやすさ」「ロジックが正しいことの検証のしやすさ」
も重要になってくると思うです。

この観点を優先した場合の、極端な一例。

  • まず、全ての入力・分岐・出力を、Excelワークシートの計算式で実装
  • そのワークシートを顧客にレビューしてもらい、正しさを検証してもらう
  • Excelワークシートの１セルを１メソッド（ORプロパティ）としてC#に移植
  • 固定値セルはプロパティにしといてコンストラクタでDBから取得した値を突っ込む
  • 計算式セルはメソッドにする
  • クラス内にテスト用のダンプメソッドを用意しておく。
    このメソッドは、実行すると全ての中間値をワークシートと同じレイアウトの
    タブ区切りテキストに吐き出す。テスト時は、これをExcelワークシートと比較する。

念のため、完全なる「思いつき」です。
ほんとに有効かどうか未検証だし、実績があるわけでもないです。
あくまでご参考ということで。
«前のページへ 1|2|3|4 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）