標準モジュールとクラスについて (ID:147003)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文

> 標準モジュールを「既存の項目の追加→リンクとして追加」
> にするかクラス化するか迷っています。
管理方法に対する相談なのか、Class と Module の使い分けなのか
質問内容がはっきりしていないように感じますが、とりあえず
クラスであっても、リンクとして追加する事はできますし、
標準モジュールであっても DLL 等にすることはできるでしょう。

このあたりは、VB6 とは事情が異なるところですね。

> そして、vb2005に変えるにあたり
2010 では無く?
VB/VS 2005 の標準サポートは今年度までとなっています。ご注意あれ。

正確にいえば、2011/04/12 に VB2005 のメインストリーム サポートが
終了するという事です。延長サポートはまだ続きますけれどね。

> クラス化が良いみたいなのですが
何が良いのか、その具体的な理由を調査・検証された上での悩みでしょうか?

VB6 時代にクラスを使わず、標準モジュールを使っていた理由は何でしょうか。
モジュールの方にメリットを感じていた(またはクラスでは都合が悪かった)なら、
それを今回、改善できるかどうかを調べておく必要があるかと思います。

たとえば、開発メンバーの知識やスキル等が不足していたからというのが
クラスを採用していなかった理由なのであれば、上司に説明する際には、
その対応策を考えておかなければなりませんよね。

> メリット、デメリット等ご教授お願いします。
教授→教示のツッコミはさておき、今回の質問というのは、
ソースをリンクするべきか、ソースをコピー利用するべきか、
DLL にしてプロジェクトに含めるべきか、GAC 登録すべきかという
視点ではなく、標準モジュールの是非に関してでしょうか。

言語的な機能だけで見るならば、2008 未満のバージョンでは、
「標準モジュールが無いと困る」というケースは無いはずです。

極端な話、シングルトンにしたり、Shared メンバーを使ったりすれば、
標準モジュールの機能をそのまま踏襲させることはできるわけですから、
その意味においては、クラスを使えば事足りると言う事ができるでしょう。

もっとも、そのような実装方法が良いことかどうかは別の話ですが。

> 管理方法を変更してまでクラス化するメリットを
たとえば「インスタンス」「インターフェイスの実装」などは、
標準モジュールでは表現できません。デザインパターンを意識した開発が
出来る場合には、クラスの方が便利な事が多いと思います。

しかし、正しいクラス設計をするには、ある程度の力量が必要になってきます。
(もっとも、それは Form 等に対しても言える事なのですが)

元の *.bas が、カプセル化を意識して作成されたコードであるならば
さほど問題ありませんが、単に Public/Global なメンバーを並べただけの
物であるならば、それをただ Class に置き換えただけでは、むしろ
手順が煩雑化する分、デメリットの方が増大する可能性もありえます。

# 移植元の標準モジュールの内容を知らないので、この場では判断できませんが。

←解決時は質問者本人がここをチェックしてください。

戻る