« 2004年12月 | メイン | 2005年02月 »
2005年01月28日
フレームワークは自由を奪わなければならない
フレームワークは自由を奪わなければならない
なんでもできるフレームワークなんて、単なるサブルーチン集。
良いフレームワークは、目的を適切に表現させるために、プログラマーの自由を奪ってくれている。
投稿者 tatsugoro : 11:28 | コメント (1) | トラックバック
2005年01月27日
Webサービスのメソッド呼出間でSessionを維持したいなら
Webサービスのメソッド呼出間でSessionを維持したいなら、CookieContainerを使います。
Webサービスを呼び出す側
ServiceTest oServiceTest = new ServiceTest();
oServiceTest.CookieContainer = new CookieContainer();
txtUserName.Text = oServiceTest.methodUserName();
txtUserAddr.Text = oServiceTest.methodAddr();
Webサービスのメソッド側
[WebMethod(EnableSession = true)]
public string methodName() {
}
[WebMethod(EnableSession = true)]
public string methodAddr() {
}
.NET Framework クラス ライブラリ
HttpWebClientProtocol.CookieContainer プロパティ
cookie のコレクションを取得または設定します。
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemwebservicesprotocolshttpwebclientprotocolclasscookiecontainertopic.asp
.NET Framework クラス ライブラリ
CookieContainer クラス
CookieCollection オブジェクトのコレクション用のコンテナを提供します。
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemnetcookiecontainerclasstopic.asp
実は、私は、検証のためだけにしか使ったことがありません。
某掲示板にこの回答を書いたところうまく言っているとの報告がありました。
その後も数回質問があったため、codeseekのサンプル解説に載せます。
投稿者 tatsugoro : 18:13 | コメント (0) | トラックバック
2005年01月26日
複雑であることに慣れるな
複雑であることに慣れてはいけない。
もっと単純に、もっと楽に作れなければならない。
苦労して書いた複雑なコードは、楽をして書いた単純なコードよりも読みにくい。
楽をして書く方法をみにつけなければ良いコードはかけないと思う。
投稿者 tatsugoro : 17:47 | コメント (1) | トラックバック
2005年01月25日
自分が読むために書け
より良いコードをなぜ書くのか。
それは自分のためだ。
他人のコードはなぜ読みにくいのか。
それは書いた人ですら読めないように書いてあるからだ。
自分が読むために書けば、他人も読める。
自分が一番読みやすいと思う書き方を追求していこう。
他人も少しは理解してくれるだろう。
投稿者 tatsugoro : 15:54 | コメント (1) | トラックバック
2005年01月19日
省略するな。
省略するな。
お願いです。勝手に省略しないでください。
もしも言葉を略すなら、プロジェクトメンバー全員に報告してください。
省略してしまう理由...反論
名前が長すぎる...長くなくても省略してる人がいるよ。
めんどくさい...省略されているものを読むほうがもっとめんどくさい。
画面に収まらない...収まるように書けるはず。大きな画面つかってください。
印刷用紙に収まらない...収まるように書いてください。
iとかjですよ...それは昔の話
スコープが狭いから...ではそのスコープに見合う名前はつけてください。
インテリセンスで判るでしょ...ポイントするまでわかりませんよ
まだありそう。
このなかで一番困ったのが、「キー入力がめんどくさい」でした。
このときばかりは、二度とキーボードに触るな、とすら思いました。
投稿者 tatsugoro : 13:27 | コメント (3) | トラックバック
2005年01月13日
Application Block UIPは面白い
昨日書いた
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/logging-mfs.asp
は、
Multiple Formatter Support for the Logging Application Block
へのリンクでした。
ごめんなさい。
私が説明したかったのは、UIPですんで、こっちです。
User Interface Process (UIP) Application Block - Version 2.0
http://msdn.microsoft.com/library/en-us/dnpag/html/uipab.asp
どちらもApplication Blockの一部なのですが、だんぜんこっちの方がおもしろい挙動をします。
WindowsFormとWebFormの両方に対応可能で、それらのプログラムコードの違いを最小限にしようというものです。
app.configかweb.configに差し替え可能なviewとNavigationGraphを登録しておいて、controllerでそれらを切り替えることで対応しています。
表示のために使うクラスをcontrollerとその作成者は知る必要が無く、実行直前まで差し替えが可能になっています。NavigationGraphはviewを選択するための遷移パターンを記述するものです。この仕組みを使って、コンパイル後に使用するクラスを変更する、という仕組みの実装が可能で、その良い、そしてかなり複雑なサンプルになっています。
投稿者 tatsugoro : 20:54 | コメント (0) | トラックバック
2005年01月12日
Application Blockを知っていますか？
Application Blockを知っていますか？
マイクロソフト社が提供しているアプリケーションフレームワークです。
User Interface Process (UIP) Application Block - Version 2.0
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/logging-mfs.asp
リンク先から、UIPの説明とソースファイル、実行ファイルがダウンロードできます。
UIP Application Blockの一番の特徴は、WebアプリケーションとWindowsアプリケーションをほぼ同じように開発できる点だと思います。
機会を作って、使い方について書きたいと思っています。
まずは、ご紹介。
投稿者 tatsugoro : 15:05 | コメント (0) | トラックバック
2005年01月11日
MSDN Library Onlineの階層構造が変わった
迷子になりました。
投稿者 tatsugoro : 15:34 | コメント (0) | トラックバック
2005年01月07日
ただでめぐんでくれるわけではない
オブジェクト指向は利益を得ることを許してはくれるが、それをただでめぐんでくれるわけではない
(UMLモデリングのエッセンス 第2版 マーチン・ファウラー)
「オブジェクト指向での設計」を発注の条件にする会社が多くあります。オブジェクト指向であれば、あらゆる利点を受け取ることができると思っているようです。
「オブジェクト指向」とはなにかを顧客に理解させることは、非常に困難です。
そもそも、「オブジェクト指向での設計」とだけ言われたのでは、どういう設計のことをさしているのか、私にもさっぱりわかりません。コンサルティングレベルから適用されるのか、UMLを使えば満足してもらえるのか、流行の手法でクラスが分割されていればいいのか．．．
そういうときの説明に、ファウラーのこの言葉を引き合いに出すことにしています。
投稿者 tatsugoro : 14:54 | コメント (0) | トラックバック
2005年01月04日
動作では無く役割から発想せよ
動作からではなく、役割から発想したコードを書くと読みやすくなると思います。
以下のメソッド名、プロパティ名は、テキストファイルからUserNameを取得する動作を行い、外部へ公開するものを想定してつけた名前です。
ReadUserNameFromTextFile()メソッド
ReadUserName()メソッド
GetUserName()メソッド
UserNameプロパティ
私は下に行くほど良いと思います。
このメソッドの動作そのものはコードを読めば判ることです。しかし、メソッドの書かれた目的は人間が表現してあげる必要があります。同じコードでも目的が違うことだってありえるますし、まったく別のコードであっても同じ目的を持つことだってあるからです。
この例の場合UserNameだけが重要な目的になっています。TextFileをReadすることなどこのメソッド以外の場所やコードを読み書きする人が知る必要の無いことです。
外部のコードを書くプログラマーや、将来コードを読むことになった人にとって、ReadとかTextFileなどというものはどうでもいいことであって、UserNameにしか感心がありません。関心の無い、余計な事が書かれているコードは、主目的が追いにくく、読みにくいコードになってしまいます。
役割から発想して目的を簡潔に記述すれば、より読みやすいコードになることでしょう。