- - PR -
VB.NETとオブジェクト指向
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-09-15 11:31
objectです。
=========================== >じゃんぬねっとさん >>#結局、全言語ユーザーに、「VB」のお守りをしろって事かな？ >あまり、過激な発言は... お願いします。(*_ _) 少し、表現がまずかったですかね？ でも、この表現は、感じた事を素直に書いてるだけなんですよ？ もう少し適切に修正すれば、 #結局、全言語ユーザーに、「VB」のお守りをしろって事「なの」かな？ でした。 #申し訳ない！<(_ _)> でも、「VB2005」に於いて、「？」が付く「FCL」に関わる変更に関しては、 複数の言語を用いて開発を行っている場合、実際的にその様な状況になるのではないでしょうか？ #もし、私の発言が過激に映る様でしたら、それは「MSが実は過激な変更」を行っているのでは？ =========================== >きくちゃんさん >…どうなんでしょう。 >異なる言語同士で、文法上での（？）一貫性が必要かどうかは私には判りません。 --------------------------- >じゃんぬねっとさん >そういえば、こんなこともできますよね。 これもどんな表現したら誤解を少しでも防止出来るかと悩んだんですが、 矢張り、誤解をさせてしまいました。 要するに、言いたかった事は、 「プロパティ」は C# -> property VB -> Property プロシージャ なんですよね。 でも、継承(類別)を支えている「class、Interface」の共通要素をみれば判断出来る様に、 「プロパティ」は、言語を超えたオブジェクト指向に於ける本質的な概念だと思います。 =========================== >この 3 つは横に並べれないんじゃないですか? >Integer.Parse(), CInt, CType, DirectCast は。 >Int32.Parse() は Framework だから仕方がないし、 >CInt は VB6 から引き継いでるもので仕方がないし... >って、C# みたいに ([型])[value] でいいじゃんってことですか? >キーワードを増やすのは、文字を青くして強調して見やすくするためじゃないかなぁ。 これも、表現に迷いました。 #兎に角、VBの場合は簡単な言葉で表現出来ない「曖昧さ」を生じさせてしまいます。 キャスト自体、単純(単一の概念)では無いですから、そう簡単では無いですよね。 でも、重要なのは、 変換自体は、 「言語が主導する」 のではなく、 「型自体が主導する」 という表現ではないでしょうか？ #勿論、言語が係わらないと何も出来ない訳ですが… VBの場合、勿論、今迄の経緯はありますが、 オブジェクト指向になった限りに於いては、ある意味で「パラダイムシフト」を言語自体が実践する必要はないでしょうか？ #プリミティブさえライブラリになって外部に出たんですから。 [ メッセージ編集済み 編集者: object 編集日時 2005-09-15 11:38 ] | ||||||||||||||||||||
|
投稿日時: 2005-09-15 11:59
どもでふ。がると申します。
んっと、私は ・VBは割合にジャンル外 ・オブジェクトには慣れている って感じです(メイン言語はC、C++、Java、Perl、PHPあたり)。 なので、そんな感じを前提に軽く読み流していただければ。
んっと。社員クラスについてはまぁ「１社員のデータ各種」って 感じになると思うですが。 支店クラスは、私の場合「ユーティリティ的クラス」にする です。 具体的には…例えば
こんな感じで使うです。で、実装的には、単純に中でSQL使って 「SELECT 社員ID FROM 社員テーブル WHERE 所属支店='支店名';」って感じ でやるです。 で。
これは「支社の統廃合」とかそんなイメージでしょうか？ (「A,B両支店の社員の数だけUPDATE文が実行」ってあたりからの推測) 単純に「特定の社員複数が移動」なら、ひとりづつUpdateでもよいのでは と思ってます。 で、統廃合あたりは…いやぁ「頻繁にある」なら何か作るですが :-P ない場合、やっぱり「一人づつ」やっちゃいますかね？
んっと。まぁタイミングは見計らいますが。基本的には「メモリ上に展開」 しちゃってます。 １レコード＝１オブジェクトも、よくやる設計ですが特に違和感なく できます。 そうですねぇ。イメージとしては。 まず「１物理テーブル ＝ １クラス」で「１レコード ＝ １インスタンス」。 次に「１仮想テーブル(view) ＝ １クラス」。ただしこのクラスではSQLは 発行せずに「物理テーブルと直結してるクラスのインスタンスを保持」。 こんな風にすると、案外RDBと違和感なくクラスが直結していくです。 で。
この場合「SQLがプログラムに散らかる」可能性が一番怖いです(もちろん きちんと設計して一箇所に集約する方もいらっしゃいますが)。 オブジェクトにすると、取り合えず意識して設計すれば「SQLを一箇所に集約」 できるので、結果として「変更に対して丈夫に」なるです。 多分、そのあたりが「オブジェクトの利点」なのかなぁ、と。 …なんか脱線してるような(苦笑 | ||||||||||||||||||||
|
投稿日時: 2005-09-15 12:16
こんにちは,全言語ユーザの皆々様のお手を煩わせて｢お守り｣をしていただいておりますVBユーザの端くれです 
#本題って何でしたっけ？ #各々の基準で他の言語を扱き下ろすこと? _________________ # Future Is On Fire ! | ||||||||||||||||||||
|
投稿日時: 2005-09-15 14:16
いげ太様
> 一介のプログラマには、『インピーダンス・ミスマッチ』は > 『オブジェクト技術とリレーショナル技術の不整合』ぐらいにしか > 理解できなかったのですが。。。 まさにその『オブジェクト技術とリレーショナル技術の不整合』が、致命的なギャップですね。 つまりRDBを用いると、問題領域(problem domain)・・つまりシステムの中核の部分が OOで記述できない、あるいは、ものすごく制約を受けてしまうということになります。 たとえ、O/R マッピングツール／フレームワークをもちいても同じことでしょう（たぶん）。 OOの「継承」とか例えば「ツリー構造」のような一般的なモデルを、RDBでは表現することはできないですし、 OOの関連(association)と、RDBのリレーションシップとは、似て非なるものです。 一郎様 > 「オブジェクトとか面倒な物作ってないでSQL文をポ〜ンと実行すれば済むんじゃね？」 まさに、一郎様の例は良い例だと思います。 RDBではUPDATE文１回で1000件更新できるはずの処理を、 OOでは１レコードずつ更新する・・なんてパフォーマンスの悪い非実用的なことになりかねません。 | ||||||||||||||||||||
|
投稿日時: 2005-09-15 15:29
objectさん、こんにちは。
勿論、そうだと思います。というか、VB.NET（2002） の登場がそうだったと思ってましたが、違ったんでしょうか…？ 2005 での復古は、そんときの振幅が大きかった為の揺り返しなんじゃないかと思えます。 | ||||||||||||||||||||
|
投稿日時: 2005-09-15 17:02
objectです。
========================== >117さん >こんにちは,全言語ユーザの皆々様のお手を煩わせて｢お守り｣をしていただ>いておりますVBユーザの端くれです 実は、私も 「VBユーザの端くれ」 なんですよ？ 最初は「C#」でスタートしましたが、勿論「VB.NET」も始め 今年からは、頼まれて「VB.NET」を教えたりもしています。 ｢お守り｣にかなり反応された様ですね。 レスの文脈から理解頂けると思いますが、私が想定しているのは 「お守りの対象」=「VB2005でのVB.NETのソース(リソース)」 です。 いい加減な発言をしてる訳では無いので、それだけは、理解して下さい。 私のレス (投稿日時: 2005-09-14 12:50)での >「知りたいのは、考え方では無く、作り方だ！」 も、実は「VB.NET」では見えない部分の説明をした時の言葉(反発)です。 私は 「せめて、聞く耳だけは持って欲しい」 という思いを秘めて取り上げました。 #私は、「.NET」を少しでもより良く理解し、またそれを伝えたいと思っています。 >#本題って何でしたっけ？ >#各々の基準で他の言語を扱き下ろすこと? 私のレスを「各々の基準で他の言語を扱き下ろす」と理解されたのでしたら、誤解だと思います。 言葉としては、厳しい(キツイ)かもしれませんが、 「問題を曖昧にしない事」 を優先して書いています。 #感情的にも書いて無いつもりです。 ========================== きくちゃんさん、こんにちは。 >勿論、そうだと思います。というか、VB.NET（2002） の登場がそうだったと思ってましたが、違ったんでしょうか…？ >2005 での復古は、そんときの振幅が大きかった為の揺り返しなんじゃないかと思えます。 ええ、私もVB.NET（2002）は、頑張っていると思っています。 #でも、決して十分では無いですよね？ #イベントハンドラの処理がVB2005迄、プロパティページで出来ないのも不思議でした また、「VB.NET」の内輪事情も否定するつもりもありません。 お言葉を借りて言えば、 でも、「返ったら駄目な部分」もありますよね？ 私が心配しているのは、 「VB2005 ではフォームをインスタンス化しなくて良い 」、「My」 等の裏に潜む問題です。 ここの辺の動きを見てると、「オフィス12」との連携にも同じ問題が起きるのではないでしょうか？ 私はただただ、手遅れにならない事を祈ります。 #そして、「VBチーム」が単独・独自の判断で動いていない事も | ||||||||||||||||||||
|
投稿日時: 2005-09-15 20:43
やっと引用の仕方がわかりました（独り言です）
私の場合、RDBは単にデータの集まりとして捕らえてしまう派ですが、 （つまり、支店テーブルも社員テーブルもクラスとして実装する対象とはせず、 すべてのテーブルをデータ群とみなしてひと括りにし、 いかにこのデータ群を操作していくかというところをOOで設計／実装します。 以前のレスでも書きましたが、「データ・バインディング」に重点をおきます。） がるがる様の上記のようなやり方も”アリ”だなぁと感じました。 ・・というか、私のやり方より正攻法な気がします。 でも純粋なOO的見地からみると、なにか違和感を感じます。 一見OOっぽく作ってあるけど、メソッド内部の実装をSQLである点なんか 「ちょっと無理して作っているなぁと」 やっぱり、OO側が妥協してRDBに合わせてあげないといけないんですよね。 （逆にRDB側がOOに合わす方法は、全く浮かびません） | ||||||||||||||||||||
|
投稿日時: 2005-09-15 21:24
"テーブルをクラスとして実装する"というのは主従が逆だと思います。 クラスが存在し、それをデータベースに格納するためにテーブルを作るわけで。 お客さんがしたいのは"(例えば)在庫管理"であって、"データベースの更新"ではありません。 もしも対障害など諸々を考慮しなくてよいならばデータベースなんて面倒な物わざわざ使わないわけで。 ま、"データベースを更新するため"に作られた様なプログラムってのを多く見てますよ。 それは「オブジェクト指向で開発した」のではなくて「オブジェクト指向言語を用いた」だけの話ですよね。 /* それより、クラス図もないのにオブジェクト指向開発というのはどういうことだぁ？ */ | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。