|
私も WPF は初心者なので、さしずめ
といったところでしょうか。 WPF は興味あるけどどこから始めればいいのか判らない、という方のお役に少しでも立てれば幸いです。
|

- >
- コンピュータとインターネット
- >
- コンピュータ
- >
- ソフトウェア
こんにちは、ゲストさん
[ リスト | 詳細 ]
|
私も WPF は初心者なので、さしずめ
といったところでしょうか。 WPF は興味あるけどどこから始めればいいのか判らない、という方のお役に少しでも立てれば幸いです。
|
|
新しいコンテンツを着々公開しはじめております。暇があったらぜひどうぞ。 Hatena 使ってて思ったんだけど、開発関係のブログは Hatena の方が圧倒的に使いやすいですね!
|
|
VB.NET 版 CheckedComboBox のはてなのエントリーに公開しました。
Yahoo! ブログは結構制約が多いので、今後プログラミング関係ははてなの方にかくかも (´∀`;
|
|
しかしその後の懇親会では、何人かの方にプレゼン資料を見せていろいろ話すことが出来ましたが、今回はこのネタを使って「オブジェクト指向」について考えてみたいと思います。 さてネタにした「某バイク便システム」の開発事例についてですが・・・ 1.まず「仕様書」などという大層なものは、初めから存在しない。
2.仕様は常に変わる・・・というか、動かしてみて初めて判る仕様です。 3.開発途中でコンセプトが「バイク便システム」から「総合物流システム」 に大変貌を遂げる!!!! 販売ターゲットとする業種が拡大したため、仕様も途中から大規模に変わった。 4.エンドユーザーにはとことん易しく、60代〜70代のおじいちゃんや、 こないだまでキャバ嬢だったオネエちゃん、 パソコンを触ったことのないおばちゃん達にも扱えるよう 超ユーザビリティなインターフェイスに!! 5.デザインも堅苦しくなく、見た目に易しいデザインでよろしくネ!! 6.予算は抑えて開発は速く、しかもチームは2・3人のみ!! 7.ちなみに現場は21:00で建物が締まるため、21:00以降の残業はできません。強制退社!! というもの。まさにある種のアジャイル開発!! このシステムの最大のヤマが 「受注画面」 なるものだが、これがまた凄い仕様である!!! まず起動時の画面である。 次に伝票登録用の状態に遷移する。 この画面では表示されていないが、「依頼主」を登録すると、過去履歴の一覧が自動表示される。 中継地点も登録可能。「請求先」もユーザーが自由に編集できる。 地図を使って料金を自動計算。高速料金も自動算出する。直線・エリア・時間による料金計算も可能! 登録済みの伝票を表示する。フッターのボタンの機能が変わっていることに注目!! 登録済みの伝票も変更できる。ここでもフッターのボタンの機能が変わっていることに注意!! これ、すべて一つの画面の機能である・・・ この画面、単発の伝票だけでなく、定期配達便やキャンセル伝票、さらに赤伝すらも扱えるという代物である! そのうえ中継地点のドラッグ&ドロップによる入れ替えも可能、 各コントロールも読み取り専用〜編集可能〜に状況に応じて小まめに変化する なかなかも気の利いたインターフェイスになっている。 自慢ではないが、このシステムのプロトタイプを見に来た新聞・雑誌の編集者たちが皆
さて、この画面、極めて膨大な行数になってしまったことは想像に難くない。 2010年3月8日現在、この画面の行数であるが
ついでにこの画面の開発期間は三人月、
しかも今回初めて使った未知の地図コントロールを二つも使い倒しながらであり さらに最初搭載していた地図コントロールは、諸般の事情により、 途中で全く別のコントロールに換装したというオマケ付きである。 どうすればこのようなことが出来るのか、仕掛けは簡単、画面では実装を極力減らし、画面を構成する各コントロールや、さらに機能や概念に細分化した各クラスに、処理を委譲しまくっているからである。 前の記事では「クラスは責務を持つ実体」と書いたが、クラスを機能や概念ごとにどんどん分割し、ひとつのクラスが一つの責任しか持たないようにしてしまう。あとで知ったが、これがどうやら
というものらしい。よってこのプロジェクト内では、VisualStudio が自動生成するファイル以外、2000行を超すクラスは一つもなく、また 100 行を超すメソッドもほとんど皆無という状況になってしまった。その後ヤマのようにバグ修正や仕様変更が発生したのだが、殆ど苦もなく修正できてしまったのである。 一年近くやって徹夜が一回もない案件は今回が初めてだが、OOP の真髄を一分なりともマスターすると、ここまで楽になれるものなのかと、つくづく思い知らされたのであった。 ・・・以下、疲れたので続きは今度。もう寝よう。
|
|
ここ最近 「オブジェクト指向のこころ」 を読み返しているのだが、読めば読むほど実に素晴らしい本だと思わずにいられない。当面この本を読んで気が付いたことを、メモ書き的に簡単に書いていこうと思う。
昔、まだプログラミングを習いたてのころは、「車」や「人」になぞらえてクラスやオブジェクトの説明をされたのを覚えている。現実世界の「モノ」をオブジェクトとし、それをそのままモデリングするという話だ。 ある特定の「モノ」とそれに関わる「属性」を取り上げ、「モノ」がオブジェクトであり「属性」がオブジェクトのプロパティやフィールド等のデータ、「モノ」が行う操作をメソッドとして捉え、クラスにするという話である。 例えば 「人」 であれば、名前や年齢をフィールドして扱い、歩いたり話したり等の動作をメソッドとして扱う等の話は、10年くらい前の本にはよく載っていたものだった。 しかし、当時はなんとなくそうなのかと思って鵜呑みにしていたものの、ここ数年「オブジェクト」とはそうではないことに気が付いてきた。 例えば数値・・・これは決してモノとは言えないが、言語によっては立派な「オブジェクト」である。 また Strategy パターンの Strategy クラス。これは「モノ」というより「戦略」という概念そのものをクラス化したものだ。また同様に Command パターンにおける Command クラス、これは「動作」や「処理」という概念をクラスしたものである。 こうなってくると
現実世界をそのまま写像できるという考え方は・・・シミュレーション用言語である Simula に触発されて生み出されたことと無関係ではありません。しかし、現実世界をそのままコンピュータ上に実装するなどできない相談なのです。
・・・中略・・・ 現実世界のものごとにはさまざまな性質、特徴が存在しています。そして、抽象化とはそういったものの一面だけを抜き出し、残りの面をすべて排除してしまう行為なのです。つまり現実世界のものごとに10個の側面があった場合、抽象化によって9個の側面が捨てられてしまうわけです。・・・ ・・・中略・・・ このため、「現実世界をそのままの形でクラスにできる」という宣伝文句も、最近では少しずつ目にする機会が減ってきています。 また、以前会社に来たあるコンサルタントはこういっていた。 オブジェクトとは決して難しい概念ではない。データにメソッドを持たせたものがオブジェクトである。
当時はこの言葉を鵜呑みにし、納得していたつもりだったが、今となってはそうは思えない。この書のなかでもこうバッサリ切り捨てている。 これはあまりにも単純で安直なものの考え方と言えるでしょう。なぜなら、オブジェクトというものを実装という観点からしか見ていないからです。
では「オブジェクト」とはいったいなんだろうか?「オブジェクト指向のこころ」の P104 で著者はこう言っている。
難しい言い回しだが、なかなか核心を突いた考えだと思う。この観点からオブジェクトというものを見ていけば、モノではない「処理」とか「動作」、「概念」すらも充分オブジェクトやクラスとして扱うことができる。 実際今の現場でもそうだが、消費税・料金・計算ロジック・支払方法・データ更新・請求etc・・・これらもモノとは言えないけど確かにオブジェクトとして扱っている。そう考えるとオブジェクトを「メソッドを持つデータ」とか「現実世界をそのままモデリングしたものがオブジェクトである」という従来の議論は誤りだといわざるを得ないだろう。 ありゃ?簡単に書くつもりが段々長くなってきたwww とりあえず今日はここまでにして寝よう。・・・と思っていたら寝付けないので編集しなおした。 #2/24 ちょっと修正した。
|
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
[PR]お得情報