Home > プログラミング > デザインパターン Archive

デザインパターン Archive

ASP.NETのセッションをタイプセーフに取り扱うクラスの作成・2

  • Posted by:
  • 2007年4月 9日 23:49

セッションを扱うクラスまで、とりあえず完成しました。
あとは、Coockie、QueryString、ViewState用クラスを作ったところで、アップしようと思います。
公開後、特に問題も無いようでしたら、弁慶フレームワークに入れたいなと企んでいたり。

緊張性頭痛が再発してしまったので、ペース落ち気味です。
期待してらっしゃる方がいたら申し訳ありませんが、もう少しお待ちくださいませ。

ASP.NETのセッションをタイプセーフに取り扱うクラスの作成

  • Posted by:
  • 2007年4月 6日 00:19

CodeZineでCool!なエントリを見つけたのでご紹介したいと思います。

[CodeZine]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成
[ひぐたぅん]ASP.NETのセッションをタイプセーフに取り扱うクラスの作成

Sessionを操作するのはHashtableのようにキーを与えてobjectで取得し、型変換処理を行う訳ですが、この方法を使うとインテリセンスが効いてくれるので、大変使いやすくなります。
ラッパークラスで吸収する形なので初心者にも分かりやすいのが素晴らしいと思います。


実は、私も同じようなクラスを作ろうと思っていたところだったのですが、いいラッピングの仕方が思いつかず今に至っておりました。
著者のHigtyさんの許可が頂けたらですが、私のやりたいことを組み合わせたカスタムバージョンを公開したいなあと思いました。

やりたいこと
・staticメソッドではなくて、クラス自体をSingletonにする
・Session、QueryString、Cookie、ViewStateのBaseクラスを作成し、サブクラスはプロパティのみの実装とする
 Sessionをひとまとめではなく、なんらかのグループで纏めたい場合もあるので、サブクラスできるのは便利だと思う
・機能と実装を分離する形で、実際のデータ取得をするクラスに委譲するようにBaseクラスを実装する
 データ取得クラスは実行時に入れ替え可能にする。そうすることでNUnit等からSessionクラスを仮想操作できる
 仮想操作用としては、Hashtableでも使えばよいと思う。

と、いったところでしょうか。
頭の中ではもうできていたりします。

なぜプログラムが追いにくいのか?

ある理由から、意味の分からないソースコード(C#)を読んでいます。
資料はそれなりに揃っているものの、ソースコード上にコメントがほとんど無く、資料と整合性が合っていない場合、なぜ違うのかが全く分からないんですよね。
かなり苦戦している訳ですが、せっかくなので、なぜ読みにくいコードになっているか考えてみようと思います。

簡単に思いつくあたりでは、
・コメントが圧倒的に足りない。というか必要なところになく、役に立たないコメントだけ存在。
・「とりあえず動けばいいや」的な場当たりな作り方。
・間違った共通化。共通ロジックの呼び出し方が暗号みたいな作りになっていた。

と、こういうのは大体どこにでも存在するコード(泣)で、どちからというとマナーみたいなもんなんですが、果たしてこれが解決すると読みやすいか?というと、そうでもない気がしてきました。
根本的な問題があるのはプログラムの構造で、モジュール分割や機能と実装の分離が正しく行われていないことが原因だと思います。


特に重要だと思うのが、機能と実装の分離です。
例えば、機能説明に「検索ボタン押下時に受注情報を取得する」と書いてあるのに、その処理を示すメソッドが「SelectOrder」となっていたとします。
これは最終的な結果から見ると正しい動作になっていますが、構造では欠陥があります。
つまり、「受注情報を取得する」をしたいときに、何故「SelectOrder」なのか関連性が不明だからなんです。
(この例は単純な例なので容易に想像できちゃいますが...)

検索ボタン押下→SelectOrder

ではありません。
この場合は、

検索ボタン押下→Get受注情報→SelectOrder

とすべきです。
なぜなら、機能説明に忠実に作成するなら、検索ボタン押下に要求される機能は「受注情報を取得する」ことだからです。
そして、「受注情報を取得する」ための実装として「SelectOrder」が呼ばれます。
このように、機能と実装を分離すると、もし実装が変わっても(例えばデータベースが変わるとか)、ボタン押下イベント側には影響が出ません。
また逆に、ボタン押下イベント側から利用する際にも、どんな実装をしているかを気にせずに呼び出すことができるようになります。

さらに付け加えると、ボタン押下イベント側から呼ばれるメソッドは、機能を表す名前をつけることが望ましいです。
なので、この例でも「受注情報を取得する」のような機能の場合、動詞を前に出して「Get受注情報」としています。


他に気をつけるべき点として、メソッドを単一機能に限定することが挙げられると思います。
つまり、メソッドの説明をするときに「このメソッドは○○と××をします」のようになってしまうのは問題があります。
正しくは、「○○をする」メソッドと、「××をする」メソッドの2つのメソッドに分割することです。
そうすることにより2つの機能が独立するため、単純な構造になります。


実はこういう事を言うと、「こんなことをしたら、クラスやメソッドがいっぱい増えて、処理が遅くなってしまう」と反論する人がいます。
これはある意味では正しいと言え、実際にクラスやメソッドが増えるし、処理も遅くなります。
しかし、オブジェクト指向言語を選択した時点で、パフォーマンスが最重要課題でない(最重要課題ならC等を選びましょう)ため、例えば0.01秒掛かっていたのが0.02秒になったとしても、実際にほとんど影響が無いと言えます。(それでも早くしたいなら、性能の良い動作環境を買ってもらいましょう)

確かにわずかながらデメリットはありますが、システムの将来を考えると、より可読性の高いコードを生産する方が価値が大きいのではないでしょうか。

デザインパターンは始まりだった

真面目な話です。

デザインパターンに初めて触れたのは4年ほど前の事。
Javaの仕事をしていたので、きちんとUMLを理解しようと思ったのがきっかけでした。
当時はまだデザインパターンという言葉もあまり浸透しておらず、オージス総研のUML認定試験で初めて知りました。
そのUML認定試験のゴールドレベルの分野がデザインパターンだったことから、デザインパターンの書籍を買った訳ですが、かなりの衝撃を受けたことを記憶しています。
問題の論理的な分析と、その解決方法のエレガントさ、そして実際のコード。
それからというもの、まさにデザインパターン漬けになったわけですが...

最近はその延長上として、J2EEパターンだとか、ソフトウェアアーキテクチャといったものまで研究しています。
すると、今までコーディングベースでやってきたため気付かなかった部分が見えてきました。
アーキテクチャの部分、言い換えると思想的な部分とでも言いましょうか。
問題領域に対する考え方とか動き方とか。これって凄く大事なことで、システム開発の中枢と言えると思います。

過去の奈落プロジェクトを振り返ると、ほとんどがプロマネの能力不足だとか、中国へ出したせいだとか言われる訳で、それは実際に半分当たってたりしますが、「アーキテクチャが不在」だとか「アーキテクチャが間違っていた」という点を見落としていました。
「アンチパターン ソフトウェア危篤患者の救出」という本の中に「肥満児」とか「溶岩流」なんてアンチパターンがあって、この中でまさにアーキテクチャの軽視が原因とされているのですが、最近になってようやく意味が理解できた部分だったりします。

システム開発の世界は奥が深いですね。
今にして思うと、デザインパターンは始まりだった気がします。

Continue reading

DAOパターン

  • Posted by:
  • 2006年10月26日 12:17

フレームワークのデータベースアクセス部分だが、J2EEパターンで出てくる「DAOパターン」を採用することとした。

データベース操作については、特にコーディングをしないでも、テーブル構造合わせて自動的に処理させようと企んでいたのですが、どうやら破綻してしまったようだ。
SQLが固定でパラメータクエリで実現可能な一般的な操作(PKに対する検索、全件取得、追加、更新、削除)は普通に実装できたのだが、問題は動的にSQLが生成されるようなときに自動化はちと難しいのです。

解決策として最初に考えたのは、条件部分をDecoratorクラスで実装する案。
実はこれは上手くいったのですが、どうも美しくない。
複数クラス間にSQLが分散されているため、メンテナンスが容易にできないだろうと。

そこで、自動生成そのものを見直すことにしました。
今まではオブジェクト生成時に自動生成していたため、生成されたSQLに手を入れることはできず、実行直前に文字列の置き換え処理で対応していた。(置き換え処理はIn句対応で実装済みだったが、本来の意図とは違います)
これを、実行する直前まで遅らせることで、条件にしたがってSQLを自由に構成できるようになった。
同じSQLを実行する際に毎回SQLを生成するようになってしまったが、気が付かなかったことにしようっと。

Singletonパターンを使ったファイル変更監視

  • Posted by:
  • 2006年8月 8日 17:03

アプリケーション起動中、常にファイル監視をする要件があったとします。
具体的に言うと、あるファイルを常に監視し、ファイルが変更されたときに再読み込みをする等のイベントを処理させます。
実装例としては、自前で用意した環境ファイルのデータを保持するといったようなものが考えられると思います。

ファイルの監視方法ですが、FileSystemWatcherで監視するファイルを設定し、FileSystemEventHandlerでイベントハンドリングを行えばよさそうです。
こういう仕組みが備わっているのが.NETの良さですね~

FileSystemWatcher watcher = new FileSystemWatcher(ファイルパス, ファイル名);
watcher.Changed += new FileSystemEventHandler(処理したいメソッド名);

のようにすればOKです。
常時監視ということなので、監視モジュールが常にメモリにロードされている必要があります。
常時ロードとなると、ASP.NETの場合、Application_Startに記述してしまえばいいのですが、そのロジックをWindowsアプリでも汎用的に使うことはできません。

そこで、ASP.NETでも常にメモリにロードされているということで、Singleton実装にしてみました。
Singletonのそもそもの目的は、アプリケーション内で唯一存在するオブジェクトを作成するためなのですが、唯一存在させるためにインスタンスをstaticで保持しています。
そのため、Singletonのコンストラクタで上記の監視ロジックを入れておけば、常にメモリに存在することとなり、どのプログラムを実行していてもイベントが発生します。
問題点は、Singletonなので複数のファイルを監視できないことですが、そのような場合はGetInstanceの仕組みを変えてあげることで対処できそうです。

【デザインパターン】C#でのシングルトンの実装

  • Posted by:
  • 2006年7月19日 13:30

システム内部で唯一のインスタンスがほしいときは、Singletonパターンが有効的な手段になります。
具体的な利用例としては、共通変数の管理や滅多に変更されないコードと名称の組み合わせを持っておく等が考えられると思います。

私はJavaでデザインパターンを覚えたこともあって、インスタンス取得のために GetInstance のようなメソッドを用意したいたのですが、もっと画期的な方法がありましたので紹介したいと思います。
C# でのシングルトンの実装
画期的と言っても、実装方法はほとんど変わらず、プロパティを利用しただけなのですが、コードはとてもすっきり見やすくなっています。
応用例としてマルチスレッド対応のシングルトンや静的な初期化も説明が載っています。

Index of all entries

Home > プログラミング > デザインパターン Archive

Search
Feeds
Tag Cloud
Recommend

SQLパズル 第2版 プログラミングが変わる書き方/考え方
SQLパズル 第2版 プログラミングが変わる書き方/考え方

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

ITアーキテクト vol.1
ITアーキテクト vol.1

オブジェクト指向における再利用のためのデザインパターン
オブジェクト指向における再利用のためのデザインパターン

増補改訂版 Java言語で学ぶデザインパターン入門
増補改訂版 Java言語で学ぶデザインパターン入門

増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編
増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編

J2EEデザインパターン
J2EEデザインパターン

アンチパターン―ソフトウェア危篤患者の救出
アンチパターン―ソフトウェア危篤患者の救出

世界でいちばん簡単なネットワークのe本―ネットワークとTCP/IPの基本と考え方がわかる本
世界でいちばん簡単なネットワークのe本―ネットワークとTCP/IPの基本と考え方がわかる本

Return to page top