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

名前

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

本文

> ソースをリンクするべきか、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 (とストアドプロシージャ)で
管理することが多いので、データベース操作用のクラスは特に用意していません。
データ操作補助のためのヘルパーメソッドは幾つか作っていますけれどね。

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

戻る