- PR -

VB.NETとオブジェクト指向

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»
投稿者投稿内容
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-09-16 10:59
どもです。がるです。
引用:

現場の技術者は理屈どうのこうのよりも、「実際に動くもの」を、
限られたリソース（人的・金銭的・納期…）で作らなければいけない。
そういうことは重々承知しております。
なので、がるがる様のとっておられるスタンスを批判するつもりは、
全くありません。

むぅ申し訳ない。特に「批判されている」って感じてるわけでは
ないです(苦笑
批判云々を書いたのは、稀に「学校でOOやってそれだけ」って
タイプの方がそういう話をするので(実体験あり)軽いジャブ的に
書いてただけです(苦笑

引用:

私が「違和感」や「妥協」を感じているのは、
たとえば、先ほどの「支店」と「社員」の例で言いますと、
OOでは、支店クラスと社員クラスの間には、「所属する」という『関連』が
あるというのが通常だと思いますが、
がるがる様の実装例では、支店インスタンスと社員インスタンスの間には、
それがないですよね。
このことは、つまり、支店インスタンスと社員インスタンスとの間で
『メッセージ』のやり取りがない、あるいはできない、ということを意味していませんか？
別に、この二つのインスタンスの間で『メッセージ』のやり取りが必要ないのであれば構いませんけれども・・

ふむり。確かに、いわゆる「OOのメッセージのやり取り」という観点に
根ざした状態で、あの二つのクラス間には「関連がない」です。
ただ、ちょっと冷静に設計を考えてみたのですが。
支店と社員の間には元々「メッセージをやり取りするという意味合いにおける」
関連ってあんまりないんじゃないかなぁと思うのですがどうでしょうか？

例えば、ケースとして「A支店の全員の**ステータスをインクリメントする」
とかいう業務要求があれば、コードとして当然
コード:
  支店インスタンス->status_inc(A);

とかいうメソッドが存在し、恐らくは内部において

コード:
  社員インスタンス配列 = this->get_all社員(this->支店ID);
  Loop 社員インスタンス配列 => 社員インスタンス
    社員インスタンス->status_inc();
  pool

とかいう処理が走るんでしょうが…これをもって「メッセージをやり取りしてる」
とか「関連がある」とか言われると、OO的には確かに違和感だろうなぁと
思うです(笑

そういう意味では「「支店マスタ」「社員マスタ」の間にリレーションシップが張られている」
こと自体が「リレーションのためにやむをえない実装として」なのかなぁ、と。

引用:

いずれにせよ私的には、さまざまな点で「インピーダンス・ミスマッチ」という、
オブジェクト技術とリレーショナル技術の構造に根ざした深い「溝」を無視することはできません。

なるほど。おっしゃってる内容は納得です。
ただまぁ、そういった溝を「上から塗りつぶせる」のもまた、実装的OOの
便利な特徴なのかなぁと(笑

…お気楽に考えすぎかなぁ？ ＜ おいら
一郎
ぬし
会議室デビュー日: 2002/10/11
投稿数: 1081
投稿日時: 2005-09-16 14:20
引用:

Tdnr_Symさんの書き込み (2005-09-15 21:46) より:
たとえば在庫管理における処理というのは、
・商品の入出荷の管理（入出荷台帳テーブルへの追記）
・商品在庫の照会（入荷・出荷の個数から集計）
・・・
であり、結局「データベースのクエリ・更新」になると思います。

そう、結局データベースを更新しなければならないし、更新すればそれで良いわけですからわざわざ一旦メモリ上にオブジェクトを作らなくても、
"SQL文をポ〜ンと実行"
すれば良いと考えてしまうわけですよね。

>そこに、商品クラスというのはどんな『振る舞い』があるでしょうか？

商品というのが商品仕様（商品の種類）でなく、実際のモノだとすれば、
get格納してある倉庫()
とか
小分け()
なんてのがあるかもしれませんが、特になくても問題ありません。
分析された業務の問題領域が表現できていることが重要なのです。
そうなっていればどこで何をしているかが分かりやすくなり、変更などにも強いプログラムができるのではないでしょうか。
それはコンピュータから見れば非効率なことは間違いありません。コンピュータから離れ、人間に近い位置でプログラムを作るということですからね。

データベースは業務の問題領域をアプリケーションとして働かせるための一補助部品以上のものではありません。
・・・・・という理想


引用:

Jittaさんの書き込み (2005-09-15 22:04) より:
　'return' が無くても暗黙的にその値が返ってしまうのはアレなんですが、

アレですよ、ほんとに。
VB.NETって、コードを書く時にC#よりも知識や神経を使うんですけど。

フォームクラス.Show()って・・・・
MicrosoftはVB.NETユーザーに恨みでもあるのかな。わざわざオブジェクト指向的な考えを得る機会を失わせるような作りをして。
いげ太
常連さん
会議室デビュー日: 2004/10/27
投稿数: 32
投稿日時: 2005-09-16 15:56
勉強不足＠いげ太です。

そうかっ！こういう事を言ってたのか！！
非常によくまとめられた記事をおぎわらさんの Blog で発見したので貼っておきます。

.NETでＤＢを扱う場合の考え方
Tdnr_Sym
ぬし
会議室デビュー日: 2005/09/13
投稿数: 464
お住まい・勤務地: 明石・神戸
投稿日時: 2005-09-16 16:59
引用:

いげ太さんの書き込み (2005-09-16 15:56) より:

非常によくまとめられた記事をおぎわらさんの Blog で発見したので貼っておきます。

.NETでＤＢを扱う場合の考え方


いげ太様、たしかにこの記事は分かりやすくまとめられていますね。

この「ＴｅｃｈＥＤフォローアップセミナー」とかいうセミナーの分類によると

１．トランザクション スクリプト
２．ドメイン モデル
３．テーブル モジュール

私が今まで設計／開発してきたアプローチ方法（このスレでも書き込んでますが）は
「３．テーブル モジュール 」のパターンに当てはまりますね。

囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2005-09-16 22:01
こんにちわ。

お勧め書籍。
マーチン・ファウラー 著「エンタープライズ アプリケーションアーキテクチャパターン」
#もうスレッド中に紹介されたかな

とりあえず、ドメインモデルから入ってしまう…。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2005-09-16 23:09
引用:

さかもとさんの書き込み（2005-09-15 22:45）より：

>そういえば出てきていないようですが、VB6 以前や VBA をさわっていて、「いいなぁ」と思ったこと。
という視点でのご意見も是非と拝聴させて頂ければと思います。

　ん〜、、、それ以外、無いです（苦笑）

　私は、Nxx-BASCI, Z80, FORTRAN, COBOL, ANSI C, Borland C++, VBA, VB6, C++.NET, VB.NET, C# とさわってきたのですが（研修だけ、実験的使用含む）、VBA, VB.NET は、使いにくいです。
# ANSI C は、MS-C と区別するため
# Borland C++ は、Visual C++ と区別するため
　何が使いにくいって、やはり、Nxx-BASIC と同じようにできるところです。
　プログラミング初心者にとって、「何でもあり」的なところは入りやすい部分ではありますが、システム開発の業務では、あまり使いたくありません。バグを作り込む要素が多すぎます。


一郎さん：
> アレですよ、ほんとに。
> VB.NETって、コードを書く時にC#よりも知識や神経を使うんですけど。
わはは。
　だから、開発者が VB を使うのが、間違っていると思います。
　適材適所、っていうじゃないですか。
　「適所」を考えたときに、objectさんのおっしゃることも、クリアされるかと。VB.NET は、オブジェクト指向を完全にサポートする（準拠する、かな？）ことを目標とはしていない。それは、「オブジェクト指向」を知らない人、開発が業務というわけではない人、初めてプログラミングにふれる人、趣味でプログラミングを始めてみようという人、etc...言語というものを知らなくても、プログラムしている感じが味わえればいい人たち（すみません、ちっと言いすぎです）が、販売対象として存在していると考えると、"無理して"オブジェクト指向に沿った言語仕様にする必要はない、と思います。

# C#3.0 の、ローカル変数の宣言が型を指定しなくてよくなる、というのが、気になる

[ メッセージ編集済み 編集者: Jitta 編集日時 2005-09-16 23:10 ]
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-09-17 01:55
引用:
"テーブルをクラスとして実装する"というのは主従が逆だと思います。クラスが存在し、それをデータベースに格納するためにテーブルを作るわけで。

なぜ主従が勝手に決まるのでしょう？ お客さんがしたいのは"在庫管理"でしょう。テーブルを作りたいわけでも、クラスが使いたいわけでもないのだから、クラスが主、テーブルが従とは言えません。

クラス(オブジェクト)は、実際のモノを表現しているので「主(根源)」だと考えるかもしれませんが、テーブルというのも業務で使われる帳簿やリストに似ていて扱いやすく十分に「主(原本)」と言えます。たとえば出荷指示なんてものは倉庫で現物見てやるわけじゃなく、倉庫とは別の部屋で受注票と在庫表を見ながら出荷伝票書いて在庫表を減じたりするわけです。この在庫表を減じるという操作がテーブルを更新することと直感的に結び付く顧客が多いのです。

引用:
もしも対障害など諸々を考慮しなくてよいならばデータベースなんて面倒な物わざわざ使わないわけで。

最近こういう人多いですね。データベースを永続化ストレージとしてしか捉えていないという。OO至上主義、とくに O/R マッピング崇拝の弊害だと私は思っています。

そもそも言語の分類が違うんじゃないですか。OOP と SQL では。OOP とはいっても従来の多くのプログラミング言語と同じく「手続き型」言語なんですよね。問題の解法(アルゴリズム)を記述して答えを出す。それに対し、SQL は問題の解法を記述するのではなく、問題自体を定義すれば答えが出る。「定義型」とか「関数型」と呼ばれる言語に近いのではないかと思います。

この全く異なる言語 OOP と SQL の違いを意識させずに透過的に扱えるようにしよう、という発想自体がナンセンス。インピーダンスミスマッチが起こって当たり前。なんで、O/R マッピングなんてものが流行っているのか全く理解できません。

引用:
分析された業務の問題領域が表現できていることが重要なのです。そうなっていればどこで何をしているかが分かりやすくなり、変更などにも強いプログラムができるのではないでしょうか。それはコンピュータから見れば非効率なことは間違いありません。コンピュータから離れ、人間に近い位置でプログラムを作るということですからね。

コンピュータの実行効率の問題だけでなく、SQL のような定義型の言語の方が人間に近い位置でプログラムを作れることも多いのです。実際、顧客の要求自体が SQL になっていることさえあるのです。

「2ヶ月連続で自振引き落しできなかった顧客のリストを作れないか？」

こんなのは、そのまま SQL に翻訳して問題として定義できるわけです。とても人間に近い位置でプログラムが作れます。それに対して手続き型言語(OOPでさえも!)の場合は、コンピュータよりの立場でアルゴリズムに書き下していかなければならないはずです。

そもそも、OO は現実世界を表現するというのが理想論・・・というかズレている。多くの業務は現物主義ではないのです。実際の業務は現物とは関係なく伝票と帳簿で進んでいきます。商品入り数を確認するのに、その商品の梱包ケースを見にいくと本当に思いますか？ コンピュータシステム化する前の時代から、そのようなものは帳簿にまとめられていて机上ですばやく調べられるようになっているのです。業務を進める上での現物は帳簿や伝票、つまりテーブルの方が現実に近いわけですね。

OOP が必ずしも人間に近い位置でプログラムを記述できる言語だとは言えません。データベースを永続化ストレージとしてしか使っていないプログラマはこの事実に気づかないかもしれませんけどね。
キイロイトリ
会議室デビュー日: 2005/01/22
投稿数: 10
投稿日時: 2005-09-17 09:34
こんにちわ。
C++で業務アプリを開発者として、思っていたことをいくつか述べさせていただきます。

業務アプリは、確実かつ軽快に動くことが最重視されます。
これを実現するためには、重要な要素がいくつかあるのですが、DBのパフォーマンスは重要トピックの一つです。

OOPを使ってDBの存在を隠蔽することは可能ですが、パフォーマンスの低下も隠蔽されがちです。
むしろ、DBの存在をハッキリ意識した上で、アプリを組むことが重要だと考えます。

ですので私は、DOA(データ中心アプローチ)を基本として設計し、OOPはツールとして利用するスタンスを取っています。
「３．テーブル モジュール 」のパターンに当てはまりますね。
イロイロ試行錯誤した結果、安定堅牢な業務アプリを開発する上では、この方法が最適だと判断しています。

まあ、学術分野でのOOPからみたら、かなり汚くて邪道な使い方かもしれませんが。
«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

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