- - PR -
VB.NETとオブジェクト指向
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-09-17 10:31
テーブルが伝票や帳簿のようだというのは、確かにその通りだと思います。 だからこそデータベースは"従"だと私は考えます。 例えば、秘書が承認のハンコを押しているからといって、秘書クラスを作り秘書に承認の権限は持たせませんよね。 ましてやハンコクラスなんてものは作りません。 テーブルにも"ハンコを押したフラグ"ではなく"承認フラグ"という名前で作るはずです。 それは、ハンコを押したか押さないかということが問題なのではなく、承認されたかされないかということが問題だからです。 現実の世界では、それを書類にハンコが押してあるか押していないかで判断します。ハンコがないと困ります。ですが本質はあくまで承認したかしないかです。 伝票や帳簿はどうでしょう。 帳簿の在庫数"3"を"10000"に書き換えたら在庫が増えますか？ 売上伝票がなくなったら、売り上げたという現実に起こった出来事がなくなってしまいますか？
現物を正しく効率よく処理するために伝票と帳簿を使います。 ですが、存在するのはあくまで現物です。 現物は伝票や帳簿に左右されません。 現物が主、伝票や帳簿が従。 それをコンピューターの世界に持ってくると、 現物の表現がクラス、伝票や帳簿の表現がテーブル。 クラスやテーブルなどの仮想世界は、すでに現実世界の従であるわけですが、クラスとテーブルの関係は逆転することはないと思います。 理想はですよ。 ええ、私も作りますとも。データベースが効率よく動くように。 | ||||||||||||
|
投稿日時: 2005-09-17 11:12
はい、在庫が増えます。現物がどうかは知りませんが業務上は増えたことになりますし、業務担当者はそう信じるのです。実地棚卸で実数確認をするまでのインターバルは、帳簿の数字が業務上の真実なんですから。 でも、そんなに簡単に在庫数を書き換えられたら困りますよね。そこで、システムでラップして保護するわけです。たとえば「在庫を 10000 に設定する」という操作は通常はできません。ふつうは生産入力や発注入力によって発注票を出し、完成入力や仕入(検品)入力などによって在庫数を増加させます。(一応、棚卸入力として在庫数を直接書き換える機能も実装しますけどね。)
いいえ、売上帳簿には「売り上げた」という事実が記載済みなので、売り上げたという現実に起こった出来事は事実として残っています。ですから、単純に売上伝票の再発行をしてください。売上入力で売上帳簿に事実が書き込まれてから、納品書(売上伝票)が発行されます。 これは昔からそうなっています。業務担当者は元帳を信じていて、数字が合わなければ懸命に伝票を探すのです。それに、売り上げたら「商品(インスタンス)」という現物だって手元からはなくなってしまうのですよ？ OOP の現物主義もここで破綻し、売上伝票を現物扱いしないといけなくなるはずです。
出荷した商品は、もう手元に存在しません。現物を確認できないじゃないですか。帳簿と伝票が真実なのです。消費者がいくらゴネても、受領票があれば、それは納品の事実を表すのです。OOP では消費者が商品が届いていないと言ったら、現地確認に行くのですか？ | ||||||||||||
|
投稿日時: 2005-09-17 12:12
一郎さん、こんにちわ。
私の専門は会計ソフトですが、会計ソフトに関してはテーブル（データ）の方が主だと考えます。 具体的には仕訳データが主であって、帳簿、伝票、元帳などは仕訳データを抽出表示するだけなので従となります。 この主従関係が逆転すると、後の転記作業（試算表や決算書の作成）に無駄な労力を発生させることになります。仕訳データは一元的に管理した方が効率的なシステムが構築できます。
業務アプリのモデリングをする上で、対象は現物ではなく帳簿や伝票ではないでしょうか。 実際に業務は、伝票と帳簿を見て動くわけですから。 業務アプリに要求されることは、記帳作業の効率化と、記帳データの分析です。 実際の業務で、既に記帳がなされているなら、それを活用するのが効率的でしょう。 | ||||||||||||
|
投稿日時: 2005-09-17 15:17
私もDBを扱うときは、キイロイトリ様と同じような考えで、システム設計／開発してきました。 （同じC++ユーザーだからかな？  ）
つまり、業務アプリのようなRDB優位な分野に、わざわざOOが乗り込んでいくメリットがあるのかと。 こういうときは、問題領域はRDBにお任せして、OOは脇役に徹しようと。 「２．ドメイン モデル 」のような、O/Rマッピング（R/Oマッピングでもいいですが）して （無理やり）OOで設計／実装しようとするやり方は、非常に困難なうえにメリットが少ないように感じます。 第一、現場で「２．ドメイン モデル」のようなシステムを見たことがないんですよ。（私の経験がまだ少ないのか？） 「２．ドメイン モデル」のようなアプローチでシステム開発に成功したという、のは記事でしか見たことないし、 「そうとう無理して作ったんじゃない？」と想像してしまうのですが・・ 「２．ドメイン モデル」のアプローチでちゃんとシステム開発したよ！って方がいらっしゃったら、 （今後の参考のためにも）是非お知らせください。 どんなシステムを、どんな言語で、具体的にどんな風に開発したのか、も知りたいです。 | ||||||||||||
|
投稿日時: 2005-09-17 23:37
Tdnr_Symさん、こんにちわ。
きっと考え方は同じベクトルだと思いますが、誤解の無いよう申し添えておきます。 私は業務アプリをOOPで組むことには、大いに賛成です。 ですが、教科書通りのOOPじゃ上手くいかないと感じ、試行錯誤の末、 DOAで基本設計を行い、OOPで実装する方法を採った次第です。 もう少し具体的に言及します。 業務内容を分析する際、現実世界をOOPで表現するなんて野望を抱きません。 むしろ、業務内容の記録方法に着目します。 業務内容を効率的にの記録すること、業務内容の集計・分析が容易に行えること、 これらを実現するように、業務内容の記帳方法を検討するわけです。 言い換えれば、モデリングしながらDB設計を行っている感じですね。 上記の作業があらかた終わったところで、OOPでの実装設計に入ります。 私は下記の点を実現するために、OOPを使用します。 ・データを取り扱いやすいようにパッキングする ・フレームワーク側の処理を一元化する データを取り扱いやすいようにパッキングすることとは、 データを格納する構造体に、初期化、大小判定、アクセスメソッドなどを 追加する作業のことです。 フレームワーク側の処理を一元化することとは、 フレームワークから呼ぶためのインターフェースを用意して、 それぞれで詳細な実装をしていくことです。 まー、実際こんな感じでアプリを組んでおります。 教科書通りの手法ではないですが、これが現場仕事だと開き直っております 
[ メッセージ編集済み 編集者: キイロイトリ 編集日時 2005-09-17 23:38 ] | ||||||||||||
|
投稿日時: 2005-09-18 09:10
キイロイトリ様、おはようございます。
私は業務系の経験がほとんどなく業務知識はゼロに等しいのですが、 ＃私はATM機器やカーナビや車載装置などの組み込み／リアルタイムシステム系、 ＃言語処理系・仮想マシンやプレゼンソフトなどのミドルウェア、パッケージ開発に携わってきました。 ＃お手伝い程度であれば、まだいろいろ（医療系システムやらPOP印刷やら）ありますが・・ さかもと様やこのスレ主のhimanin様のような、業務系アプリをOOで組むことにつまづいている人が 知りたいところであると想像しますので、ちょっと頑張って質問してみたいと思います。 ＃私自身も興味がありますので。
”現実世界の表現”であれば、「得意先クラス・仕入先クラス」とか「商品クラス」とか「注文クラス」ってことになりますか？ ”業務内容の記録方法に着目”というのは、「仕訳伝票」とか「元帳」をクラスにするということでしょうか？
すいません。いまいち具体的なところまで想像できませんでしたが（設計書やソースを見れば、分かるのかも知れませんが） 「データの取り扱い」「フレームワーク」でOOPを使用するということは、 やはり、問題領域（システムの核心）にまではOOPできていないと、と受け取っていいのでしょうか？ | ||||||||||||
|
投稿日時: 2005-09-18 10:27
Tdnr_Symさん、こんにちわ。
答えられる範囲でお答えします。
まずは、実際の業務内容を分析した上で、記録しておく必要のある情報は何か、の検討に入ります。 いわゆるDB設計になります。 挙げられた例で言えば、相手先マスタ（得意先、仕入先）、商品マスタを考えます。 そして注文という取引をどのように記録するかを考えます。 次は実装に落とす段階ですが、相手先マスタに絞って考えましょう。 まず、相手先１件分の情報を保存するクラスを設計します。 大体の場合は１テーブル＝１クラスという構成になりますが、 ｎテーブル＝１クラスとなる場合も（相手先の担当者が別テーブルだったりするとか）。 データをOOPで扱いやすいようなカタチにすることが肝です。 そして、相手先クラスには登録、更新、削除などのメソッドを用意‥‥しません。 あくまでも情報の入れ物に徹してもらいます。 登録、更新、削除、クエリなどは、別の専用クラスを用意します。 相手先レコーダークラスとでもしておきましょう。 SQLの記述はレコーダークラス内で行います。O/Rマッピングもここで行います。 続いて、登録、更新の際のサポートとして、妥当性判定クラスを用意します。 相手先バリデーションクラスとでもしますか。 このクラスを用意する目的は、画面からの登録以外に、テキストからの取り込みなどの GUI無しのバッチ登録があることを想定しているからです。 レコーダークラスに含めないのは、複数のレコーダークラスを使って、 妥当性判定を行う場合があることを想定しています。 更に、相手先の一覧を得るためのクラスを用意します。 これは伝票や集計表などで、相手先を選択することを想定しています。 相手先レコーダークラスに対してクエリを依頼したり、 インクリメンタルサーチ等の便利機能もここで行います。 ようやく画面設計です。 得意先マスタ画面クラス、仕入先マスタ画面クラスなどを作ります。 １画面＝１クラスという構成になります。 ここで画面上のフィールドとデータとのマッピングをします。 印刷設計も忘れずに行います。 得意先一覧表クラス、仕入先一覧表クラスなどを用意します。 １印刷帳票＝１クラスとなる場合が多いです。 ここで帳票上のフィールドとデータとのマッピングをします。 長くなりましたが、大体以上のようにしてアプリを組んでます。 稚拙なやり方かもしれないので、お見せするのはお恥ずかしいのですが（汗）。
うーん、ごめんなさい。 「問題領域（システムの核心）」を具体的にイメージできません。 もう少し掘り下げて説明していただけませんか？ | ||||||||||||
|
投稿日時: 2005-09-18 13:02
キイロイトリ様
詳しいご説明で、かなり具体的なイメージが沸きました。 O/Rマッピング（というかR/Oマッピングかな？）された相手先クラスは、 構造体に近い役割ということですね。 DBとのやり取りはレコーダクラスが担当し、 入力チェックなどの妥当性は、バリデーションクラスが担当すると。
えっ！具体的にですか！？ 汗） なんでしょう？例えば会計システムでいえば・・分かりません。 ユーザーさん（クライアント）との打ち合わせで、まとめられた要求仕様を実装する ビジネスロジック部ですしょうか。 たとえば、「月次処理で・・・してほしい」とか、いろいろあると思いますが。 そういう部分（領域）の処理はOOPで組まれているのでしょうか？ それともSQLによる実装となるのでしょうか？ ＃分かりにくくてすいません。なにせ業務知識がなく、具体例が挙げられませんでした。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。