開発環境：WinXP (SP3) ,VB2005 Express ,Oracle9i
標準モジュールを「既存の項目の追加→リンクとして追加」
にするかクラス化するか迷っています。
どちらの方がよいのでしょうか？
メリット、デメリット等ご教授お願いします。
-- 背景 --
vb6 でマスターからデータを取得する処理を
マスター毎に標準モジュールを作成してプロジェクトに
追加して使用していました。
そして、vb2005に変えるにあたり
クラス化が良いみたいなのですが、クラス化すると
標準モジュールの管理(プロジェクト)と異なる為
管理方法を変更してまでクラス化するメリットを
上司に説明したいのです。
> 標準モジュールを「既存の項目の追加→リンクとして追加」
> にするかクラス化するか迷っています。
管理方法に対する相談なのか、Class と Module の使い分けなのか
質問内容がはっきりしていないように感じますが、とりあえず
クラスであっても、リンクとして追加する事はできますし、
標準モジュールであっても DLL 等にすることはできるでしょう。
このあたりは、VB6 とは事情が異なるところですね。
> そして、vb2005に変えるにあたり
2010 では無く?
VB/VS 2005 の標準サポートは今年度までとなっています。ご注意あれ。
正確にいえば、2011/04/12 に VB2005 のメインストリーム サポートが
終了するという事です。延長サポートはまだ続きますけれどね。
> クラス化が良いみたいなのですが
何が良いのか、その具体的な理由を調査・検証された上での悩みでしょうか?
VB6 時代にクラスを使わず、標準モジュールを使っていた理由は何でしょうか。
モジュールの方にメリットを感じていた(またはクラスでは都合が悪かった)なら、
それを今回、改善できるかどうかを調べておく必要があるかと思います。
たとえば、開発メンバーの知識やスキル等が不足していたからというのが
クラスを採用していなかった理由なのであれば、上司に説明する際には、
その対応策を考えておかなければなりませんよね。
> メリット、デメリット等ご教授お願いします。
教授→教示のツッコミはさておき、今回の質問というのは、
ソースをリンクするべきか、ソースをコピー利用するべきか、
DLL にしてプロジェクトに含めるべきか、GAC 登録すべきかという
視点ではなく、標準モジュールの是非に関してでしょうか。
言語的な機能だけで見るならば、2008 未満のバージョンでは、
「標準モジュールが無いと困る」というケースは無いはずです。
極端な話、シングルトンにしたり、Shared メンバーを使ったりすれば、
標準モジュールの機能をそのまま踏襲させることはできるわけですから、
その意味においては、クラスを使えば事足りると言う事ができるでしょう。
もっとも、そのような実装方法が良いことかどうかは別の話ですが。
> 管理方法を変更してまでクラス化するメリットを
たとえば「インスタンス」「インターフェイスの実装」などは、
標準モジュールでは表現できません。デザインパターンを意識した開発が
出来る場合には、クラスの方が便利な事が多いと思います。
しかし、正しいクラス設計をするには、ある程度の力量が必要になってきます。
(もっとも、それは Form 等に対しても言える事なのですが)
元の *.bas が、カプセル化を意識して作成されたコードであるならば
さほど問題ありませんが、単に Public/Global なメンバーを並べただけの
物であるならば、それをただ Class に置き換えただけでは、むしろ
手順が煩雑化する分、デメリットの方が増大する可能性もありえます。
# 移植元の標準モジュールの内容を知らないので、この場では判断できませんが。
魔界の仮面弁士さんお返事ありがとうございます。
>管理方法に対する相談なのか、Class と Module の使い分けなのか
>質問内容がはっきりしていないように感じますが、とりあえず
説明不足でした。すみません。
Class と Module の使い分けです。
>2010 では無く?
>VB/VS 2005 の標準サポートは今年度までとなっています。ご注意あれ。
諸事情で vb2005 を使用しています。
サポートの方は注意しておきます。
>何が良いのか、その具体的な理由を調査・検証された上での悩みでしょうか?
自分なりに調査・検証はしました
調査結果：
①標準モジュールと比べて可搬性が高い。
②イベントを実装でき、ユーザー操作に対し柔軟なコードを書く事ができる。
③機能の拡張が安易である。
④メンテナンスしやすい。
参考URL
http://www31.ocn.ne.jp/~heropa/vb09.htm
⑤下記サイトでモジュールはクラス化するのが通常のやり方と記述されていた
http://okwave.jp/qa/q3103573.html
⑥下記サイトで「アセンブリが太るのでリンクの追加はお勧めしません...」
との記述があったのですが、「アセンブリが太る」の意味が理解できず
ググったり発言者に質問したのですが、解決には至っていません。
アセンブリが太ると起動速度・処理速度に影響があるのでしょうか？
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=30128&forum=7&start=8
検証結果
一部のモジュールをクラス化して使用してみた結果
プロパティの有効活用はまだできていませんが、
メソッドがあるのでクラス内にどんなメソッドを
実装したかクラスのプロジェクトを見ずにある程度
分かるのは便利と感じました。
>VB6 時代にクラスを使わず、標準モジュールを使っていた理由は何でしょうか。
理由：
一つのフォルダで標準モジュールを管理出来て複数のプロジェクト
で使用出来るからです
自分の場合先任者からの引継ぎでそのまま標準モジュールを使用していて
標準モジュールに不都合は感じていませんでしたが、
調査結果の⑥の「アセンブリが太る」が気になっています。
もしクラス化した方が処理速度・管理・メンテナンス等において
良いならクラス化しようと思った次第です。
(全てのモジュールが当てはまるとは無いでしょうが(^^; )
元の *.bas はカプセル化を意識して作成されていると思っています。
内容は Select,Update,Delete,Insertのプロシージャを作成しています。
(引数にSQL実行結果のエラーコードやSelectする列を指定した変数や、
Where句、Order By句等を実装しています）
標準モジュールをリンクで使用して特にデメリットが
ないのであれば標準モジュールを使用した方が良い と
思ったりこれから先のこと(vb2010等vbのバージョンアップ)
を考えるとこの機会にクラス化した方が良い とも思い
ソースをリンクするべきか、DLL にしてプロジェクトに含めるべきか
を迷っています。
まとまりの無い説明で申し訳ないのですが
宜しくお願いします。
> ソースをリンクするべきか、DLL にしてプロジェクトに含めるべきかを迷っています。
ソースをリンクすると、バージョン管理システムと連携しにくいこともあるので、
個人的には、ソースリンクは使っていません。
私の場合、VB6 ではソースファイルをプロジェクトごとにコピー利用、.NET では DLL 派ですし、
クラスかモジュールかというなら、.NET では基本的にはクラス派、VB6 では混在利用しています。
ただ、プロジェクトの作り方にもよると思いますので、こうするべきだといった
明確な回答は私も持ち合わせていません。
>>> どちらの方がよいのでしょうか？
個人的には、「どちらでも良い」です。
当方の場合でいえば、VB チームと C# チームを有するという事情があるが故に、
共通機能については、クラスを使って DLL 化する可能性が非常に高いのですが、
最終的にチーム内でコーディングルールが取れており、かつ、その仕様が開発上において
大きな問題を伴わないなら、モジュールだろうとクラスだろうと構わないと思います。
> 自分なりに調査・検証はしました
> 調査結果：
検証はしたものの、「クラスにするべき／モジュールのままで充分／併用すべき」の
いずれの結論に達しなかった、という事かと思いますが、結論が出ないなら、
それぞれ扱い方が違うだけで、機能面では大差無いという見方もできますね。
> 参考URL
> http://www31.ocn.ne.jp/~heropa/vb09.htm
Label を機能拡張して、VB.NET でいうところの LinkLabelコントロール相当の機能を
作っているようですね。GoF で言えばデコレーションパターンでしょうか。
で、上記は VB6 の実装ですよね。
本題である『管理方法を変更してまでクラス化するメリット』を説明する役に立つとは思います。されど
それはどちらかといえば、「VB6 時代のコードでもクラスを使うべき箇所があった」という話であって、
「VB6 では Module を使っていたが、2005 開発では Class に変更すべき」と提案するために使うには、
ややベクトルが異なるかも知れません。
なお、フォーム上の Label に対して機能拡張を行う場合には、
(1) 上記のように、デコレーションクラスを用意する。
(2) それぞれのイベント等に処理コードを個別に書く。
(3) 拡張プロバイダを利用する(IExtenderProvider を実装する)。
(4) コントロール自体を継承して、機能を追加する。
(5) 複数のコントロールを内包した UserControl を作成する。
などなど、複数の実装パターンがあります。必ずしも、どれか一つに絞らなければ
ならないと言う事は無いと思いますので、全てを クラス or モジュールといった枠で
ひとくくりにするのではなく、それぞれを使い分けるというのも一つの選択肢かと。
> 標準モジュールと比べて可搬性が高い。
> 機能の拡張が安易である。
> メンテナンスしやすい。
具体的にどのような点において、可搬性、拡張性、メンテナンス性の向上を
見込めると感じているのか、具体的な例を用意した方が、上司にも
説明しやすいであろうかと思います。
# 技術系の上司なのか管理系の上司なのかによって、
# 説明の仕方を変える必要はあるでしょうけれども。
> イベントを実装でき、ユーザー操作に対し柔軟なコードを書く事ができる。
Module であっても、イベントを定義することや利用することは可能です。
VB6 では無理だったのですけれどね。
Public Module Module1
Public Sub Main()
AddHandler Module2.Sample, AddressOf SampleCallback
Fire()
Console.ReadLine()
End Sub
Private Sub SampleCallback(ByVal sender As Object, ByVal e As EventArgs)
Console.WriteLine("イベント発生")
End Sub
End Module
Public Module Module2
Public Event Sample As EventHandler
Public Sub Fire()
RaiseEvent Sample(Nothing, EventArgs.Empty)
End Sub
End Module
> 下記サイトでモジュールはクラス化するのが通常のやり方と記述されていた
> http://okwave.jp/qa/q3103573.html
クラス化することが一般的かどうかについての言及は避けますが(統計を取ったことが無いので)、
標準モジュールよりもクラスの方が、.NET 的には自然であるように思えます。
そもそも .NET Framework (≠VB.NET) の視点から見た場合、VB2005 のモジュールとは
「共有メンバーのみを有するクラスに、StandardModule 属性が付与されたもの」
に過ぎないからです。
VB の言語仕様上、利用時に名前空間やモジュール名を省略できるとか、
あるいは(2008 以降で)拡張メソッドを定義できるといった違いはありますけれども。
> 下記サイトで「アセンブリが太るのでリンクの追加はお勧めしません...」
> との記述があったのですが、「アセンブリが太る」の意味が理解できず
投稿者本人の発言では無いようですが、その後の 2006-04-24 22:12 の投稿に、
》 DLL は、必要になるまでロードされません。よって、消費するメモリ量を
》 減らすという点でも、DLL 化する方がいいと思います。
》 # じゃんぬさんの「アセンブリが太る」
という書き込みがありますね。
話の流れでは、ソースのリンク、ソースのコピー、DLL 参照設定のパターンがあるようですが、
どれとどれを比較しての「太る」なのか、正確なところは私も読み解けませんでした。
VB6 当時で言うと、アプリケーションの機能案件が膨らんできて、最終的に
「巨大な単一の EXE」
「そこそこのサイズの EXE と DLL が沢山」
「そこそこのサイズの EXE が沢山」
のいずれが良いのか…という話がありましたが、そういう話ともちょっと違うのかな?
> アセンブリが太ると起動速度・処理速度に影響があるのでしょうか？
ファイルサイズのことを指しているのだとすれば、ケースバイケースなので、
私からは何とも言えません。機能の分割単位にもよりますし。
> メソッドがあるのでクラス内にどんなメソッドを
> 実装したかクラスのプロジェクトを見ずにある程度
> 分かるのは便利と感じました。
標準モジュールのメンバーも、"モジュール名." まで打てば、
メンバーの一覧が IntelliSense で表示されますよ。(VB6 でも)
IntelliSense のために、XML ドキュメント コメントを付与しておくと、より便利かも。
http://dobon.net/vb/dotnet/programing/xmldocument.html
http://homepage1.nifty.com/rucio/main/dotnet/shokyu/standard43.htm
> 元の *.bas はカプセル化を意識して作成されていると思っています。
カプセル化されているなら、その内容を Module のまま DLL 化するのも
選択肢の一つです。共通機能部分に手を加える頻度にもよりますが。
> 内容は Select,Update,Delete,Insertのプロシージャを作成しています。
ちなみに当方だと、VB2005 の TableAdapter (とストアドプロシージャ)で
管理することが多いので、データベース操作用のクラスは特に用意していません。
データ操作補助のためのヘルパーメソッドは幾つか作っていますけれどね。
魔界の仮面弁士さんいろいろありがとうございます。
結論：とりあえず標準モジュールでいこうと思います。
理由：①現状でクラス化する具体的なメリットが見出せない為。
②クラス作成やメソッド・プロパティ作成をもっと勉強して
クラス化でのメリットを具体的に見出せるように
なってからでも遅くないと感じました。
(今のスキルでもクラス化した方が良いと思うものに関しては
クラス化していきたいと思っております。)
>> アセンブリが太ると起動速度・処理速度に影響があるのでしょうか？
>ファイルサイズのことを指しているのだとすれば、ケースバイケースなので、
>私からは何とも言えません。機能の分割単位にもよりますし。
リンクで処理速度に大きな影響を及ぼすことがなさそうで安心しました。
アプリケーション自体が重いとクラス・モジュールのどちらでも
速度自体はそんなに変わらないと認識しても大丈夫ですよね？
>標準モジュールのメンバーも、"モジュール名." まで打てば、
>メンバーの一覧が IntelliSense で表示されますよ。(VB6 でも)
>IntelliSense のために、XML ドキュメント コメントを付与しておくと、より便利かも。
そのようなことが出来るのは知りませんでした。
今までは Call プロシージャ名 で使用していました。
その辺りの使用方法も今後考えていきたいと思います。
いろいろアドバイスありがとうございました。
まだまだ勉強不足で幼稚な質問もあるとは思いますが
宜しくお願いします。