- PR -

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

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»
投稿者投稿内容
とっと
大ベテラン
会議室デビュー日: 2004/03/25
投稿数: 197
投稿日時: 2004-12-15 13:35
こんにちは。

僕の知り合いで今までVB6で随分実績を積んでこれれた方がいらっしゃいまして、この前会った
時に『この度.NETの開発を始める事になって、今は共通部品を作っている』っておっしゃって
ました。やはりその辺りからきっちりされるんだなーって思った反面、何となく違和感を持った
のも事実です。

『共通部品』には変わりないとは思いますが、感覚的にはもっと『オブジェクト指向チック』
なんだよーって言いたいところなんですが・・・。

この間読んだ@ITの記事で面白いものがありました。

.NET開発者のための開発プロセス入門（前編）
アジャイル開発を導入できていない.NET開発者たちへ
http://www.atmarkit.co.jp/fdotnet/devprocess/agileentry01/agileentry01_01.html
JW
常連さん
会議室デビュー日: 2004/01/14
投稿数: 49
投稿日時: 2004-12-15 14:35
引用:

himaninさんの書き込み (2004-12-15 08:31) より:
C/Sの業務アプリで、業務ロジックは全てクライアントのGUI、サーバはDBのみというシステムをVB.NETで行おうとしています。
クラス図書いてさて実装・・と思うと、どうもしっくりしません。

「オブジェクト指向」だと「UMLのクラス図」を書く、と言うあたりは決まり切ったことなのでしょうか。
(Java/ごく小さいシステムですが、)GUIアプリで実際に委託して作ってもらったもののクラス図のできあがりを見たとき「何の役にもたたんなー」と言うのが第一印象でした。画面ごとに、画面においた部品をフィールド、イベントハンドラをメソッドにしただけのクラス図を作っても意味がないのは最初から判っていましたが、実物を見たらやっぱりだめでした。
個人的には、DB触るだけのアプリなら、データをラップしたクラスやDBアクセス周りはクラス図をはじめとしてきちんと作って、GUI部分はクラス図よりもステートチャート図とかアクティビティ図中心にイベントでデータオブジェクトにどう影響を与えるか、と言うあたりを書いてもらえた方がありがたい、とそのときは思ったものです。(UMLで書くなら、と言う前提でです。文章でなら書いてもらったので/と言うか「あんたらこのクラス図だけで何が作れるの?」とかかましてみた…)
普通にプログラミングすれば画面もクラスになりますが、だからといってそれが即クラス図に書かないといけない、だと何が目的なんだか判らなくなる恐れはあると思います。

共通部品と呼ばれるものをどういう設計で作るつもりなのか、次第だと思います。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-12-15 22:25
　オブジェクト指向で何をしようとしているのか、というところに依るのではないでしょうか。

　もし、そのシステムを、今後誰もメンテナンスしない、拡張もない、のであれば、それでいいと思います。しかし、仕様を使う側の立場で見回して、ここに改造が入るかもしれない、ここは使い勝手が悪い、そういえば打ち合わせでここは他にやりたいことがあるけど予算的に縮小しておくと言ってたなぁ…、などということがあるなら、今のうちからそれらの変更も含めて設計しておく方が、後々楽になるでしょう。今回のプロジェクトでも、データとGUIを完全に切り離せば、GUIがWebに移行しても、データ部分はそのまま使えますよね。つまり、IMEの制御はGUIで行うが、入力された文字列の妥当性チェックはGUIから離れたところで行う、ということです。

　また、「共通部品」というのも、一つのオブジェクトです。その共通部品が、他のプロジェクトでも、追加とほんのちょっとの改造ですむような作りになっていれば、「継承」して使い回せますよね。例えば、「数値しか入力出来ないテキストボックス」を作っておけば、後で「正の整数しか入力できないテキストボックス」を作らなければならなくなったとき、チェックルーチンをオーバーライドしてやればできあがります。この、「ちょっとの改造」がミソだと思います。「ちょっとの改造」が出来ないような作りになっていないでしょうか。そうではなく、「部品」であるなら「部品」らしく、プロジェクトに依存しないように作ってあれば、反対に「それがオブジェクト指向じゃないか」と言い返せるのではないでしょうか。

　私はオブジェクト指向でする利点は、今よりも将来にあると思います。

_________________
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2004-12-15 23:34
unibon です。こんにちわ。

引用:

himaninさんの書き込み (2004-12-15 12:58) より:
「そう。面倒なんです。可能な限り共通部品化しておけば、あとはAPの中で業務ロジック書くだけで済むじゃないですか。同じ処理をいたるところで書かなければならないシチュエーションにはなりません。共通部品もちゃんとLow Coupling、High Cohesionで作っておけば何の問題もないでしょ？少なくともGUIベースのクライアントアプリにオブジェクト指向での実装は向かないですよ」by共通部品推進派

ってな感じです。

GUI はオブジェクト指向を使った最たるものだと思います。しかし、標準の Form などはもうすでにそれ自体が継承ツリーの底辺であり、通常の GUI アプリケーションはそれをスクリプトのレベルで使うだけのことが多いです。
したがって、アプリケーションを作るだけの時にオブジェクト指向云々が仰々しく登場したり、Form クラスを継承して MyConcreteKachinkachinForm クラスを作るようなことをするのは、やりすぎのように感じます。普通は集約をする程度のクラスを作るだけで事足りることが多いです。もっとも、多少は継承を使えば、よりスマートにできることもあるでしょう。
ただ、どうなんでしょうね。スクリプトの延長のサブルーチンでできてしまうことならば、それで済ませてしまうのも、プロジェクトマネージメントの観点からすれば優れているかもしれません。
mso
ぬし
会議室デビュー日: 2003/12/04
投稿数: 496
お住まい・勤務地: 宮城
投稿日時: 2004-12-16 00:12
msoです。

オブジェクト指向の再利用性についてはJittaさんがすでに述べられていますが、
その辺りについて追究したりすることが出来ないとか、周りを説得できない
というのであればVB6などの時代と同じようにやっていくのが良いと思います。

個人的な考えなのですが、あとで楽なことが出来るかどか不安であれば
現状維持をして今あるスキルでなんとかやっている方がきっと幸福だと思います。

余計なことをやって変に失敗をするぐらいであれば、
最初から何もやらないことも１つの方法じゃないかって思います。
OOPってのは別に今やらなくてもいいんじゃないでしょうか？
そのうち周りがみんなOOPをやるようになってから追っかけるのも
１つの方法だと思います。
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2004-12-16 04:36
どもでふ。がると申します。
オブジェクト指向の話だったので、ちょいと首を突っ込んでみようかなぁ、と。

ちっと余談から。
引用:

元々プログラミング手法だった『オブジェクト指向』が現在では上流工程まで支配しようと
しています。

んっと。オブジェクト指向自体はプログラミング手法ではなく、もうちょっと広い
概念で扱われてると思います。
プログラミング手法なのは「オブジェクト指向プログラミング」だと思うです。

で。本題です。
引用:

開発メンバーと色々話していくうちに、GUIだけの業務アプリにオブジェクト指向のクラスだ、継承だという手法が合わないのではないか、
共通部品を作ってそれを利用するだけで事足りる、というかそれで何の問題もない、ということに落ち着いてしまいました。

んっと。個人的には「GUIだからこそオブジェクト」って気もするのですが。
とりあえず「共通部品を使う」感覚があるのはとてもよい職場だと思います。
だとすれば、オブジェクト指向を実践さえしちゃえば割りと簡単に浸透しそうに
思うんですが。
比較的正確な発言をすると、作ったクラスのほとんどは、再利用を考える
ことから、やっぱり「共通部品」になるです。
で。
いわゆる「関数の塊としての」共通部品と「クラスとしての」共通部品の
違いは…モノによりけり、ですねぇ。
継承を使わない条件下において、ちゃんと組めば大差ないものを作ることが、
概ねは可能ですし :-P
(後述でもう少し詳しく述べます)

だから、そういう意味において
引用:

「再利用という意味でなら共通部品も一緒です」by共通部品推進派

という発言はとても的をいてるんですよねぇ。

結局のところ、Jittaさんのおっしゃってる
引用:

オブジェクト指向で何をしようとしているのか、というところに依るのではないでしょうか。

が大きいのだろうなぁ、と。
恐らく、上司の方は「いきなり全面的にオブジェクト指向導入」を
狙ってるのだろうと思うのですが、大抵の場合かなり負荷が高いです。

んでまぁ。
オブジェクト指向で色々物を作ってる私的には「徐々にオブジェクトに
スライドさせていく」のを強くお勧めします。
いきなりの転換はしんどいですし :-P
ただ、拡張性能を真剣に考えると、やっぱり関数系共通部品では限界が
きます。クラスのほうが、拡張性能は高くなります。

個人的に、関数系部品と比較してオブジェクト化するメリットは
・継承
・マルチプルインスタンス
の２点だと思ってます。
継承は「気合入れて作れば」関数系でも作れますが、結構面倒な事が
多いですし。
マルチプルインスタンスも「第一引数に常に構造体を渡せば」片付く
のですが、やっぱり面倒ですし :-P
クラスにすると「隠したいパラメタ値を完全に隠蔽できる(private)」
ってのも、個人的には利点だと思うのですがどんなもんでしょう？

あとは、クラス化すると
「名前の競合とか考えなくていいしむやみに長い名前にしなくてもいい」
とかってのも。名前を考えるのが苦手な私にとっては福音です(笑

オブジェクト指向は、個人的には「楽をするための技術」です :-P
無理をせずに、必要なところから導入、でもよいのではないでしょうか？

最後に。手前味噌で恐縮ですが、よかったら。
オブジェクト講座：序文＆１
http://jibun.atmarkit.co.jp/scenter/bbs/viewtopic.php?topic=8769&forum=21
こんなのを前に書いてました。
同じ記事を参照しているスレッド一覧( http://jibun.atmarkit.co.jp/scenter/bbs/viewforum.php?forum=21&861&ref_url=http%3A%2F%2Fjibun.atmarkit.co.jp%2Fscenter%2Fbbs%2Fviewtopic.php%3Ftopic%3D8769%26forum%3D21 )
から、２以降の記事も読んでいただけるかと思います。
実用ベースで書いてあるので……お役にでも立てばよいのですが。
きくちゃん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 854
お住まい・勤務地: 都内某所
投稿日時: 2005-09-13 10:09
Visual Basic 6.0ユーザーはVisual Basic 2005に移行せよ (2/4) … ITmedia より↓。

引用:

つまり、インスタンスを生成する必要がなく、直接、Form2というクラス名からShowメソッドの呼び出しが可能となったのだ。もちろんプロパティへのアクセスも同様に可能。まさにVB 6と同じ記述方法だ。

って、やめようよ、これ…。
別に Shared (static) メソッドが新規インスタンスを返すとかって話でも無いみたいだし、混乱の元になるだけだと思うんだけど…。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2005-09-13 10:24
引用:

きくちゃんさんの書き込み (2005-09-13 10:09) より:
引用:

つまり、インスタンスを生成する必要がなく、直接、Form2というクラス名からShowメソッドの呼び出しが可能となったのだ。もちろんプロパティへのアクセスも同様に可能。まさにVB 6と同じ記述方法だ。

って、やめようよ、これ…。
別に Shared (static) メソッドが新規インスタンスを返すとかって話でも無いみたいだし、混乱の元になるだけだと思うんだけど…。

私もイヤですね... 色んな意味で、ですが。
VB2005 ではフォームをインスタンス化しなくて良い

で、仕掛けはこうみたいですね。
Re: VB2005 ではフォームをインスタンス化しなくて良い


_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

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