クラスとモージュールのガイドラインとは？

Question

 

　皆様お世話になります。

VB2005で開発をしている者です。

最近オブジェクト指向の本を買って勉強中です。

 

さて、クラスとは継承、オーバーロード、カプセル化などなど

使いこなせればよりメンテナンスが行いやすいプログラムが作成

できるということは理解できたのですが、

VBのモジュールはいったい何の為に存在するのでしょうか？

 

個人的にはモジュールのほうが扱いやすくてインスタンス化も

必要なく便利なんで、他に継承などする必要がないメソッドなんかは

モジュールで使用していたりしていますが。

 

とくに私はチームで開発を行ったりしていないので

近くにアドバイスをもらえる人がいなくて・・・。

 

皆様はどんなガイドラインでプログラムを作成しているのでしょうか？

 

 

Answer 1

たぶん、

・あるんだから有効活用すりゃいいじゃん

・使うべきではない

に分かれると思います。

 

まずはMSDNで「Module ステートメント」のページをお読みになることよいです。

そこに書かれていますが、「オブジェクト指向ではありません」と明記されています。

大事なのはインスタンスの概念が無いということで、おのずとその存在価値が明確ですね。

 

オブジェクト指向ではないということはオブジェクト指向に必要ないということですから

習得が目的なら、まずModuleを使用せずにオブジェクト指向に慣れ親しむとよいと思います。

そうすれば「Moduleとは」が見えてくるでしょう。

その上で、「この場合はModuleのほうが楽チンじゃん」というようなときに、言語機能として利用すればいいと思います。

Answer 2

さとさとさん、こんにちは。

 

さとさと さんからの引用

さて、クラスとは継承、オーバーロード、カプセル化などなど 使いこなせればよりメンテナンスが行いやすいプログラムが作成 できるということは理解できたのですが、

オーバーロードは関係ありません。広義のカプセル化もです。
個人的には継承、(広義の) カプセル化もどうでもよくて、インスタンスがあるということが重要です。

個人的にはモジュールのほうが扱いやすくてインスタンス化も 必要なく便利なんで、他に継承などする必要がないメソッドなんかは モジュールで使用していたりしていますが。

 

データ中心で設計を考えると、インスタンスが欲しくなります。

インスタンスを必用としないメソッドは静的メソッドにします。
モジュールはクラス名が省略できるのでわけがわからなくなることが多いです。

Answer 3

さとさと さんからの引用

個人的にはモジュールのほうが扱いやすくてインスタンス化も 必要なく便利なんで、他に継承などする必要がないメソッドなんかは モジュールで使用していたりしていますが。

 

そういう使い方をするためにモジュールが存在します。例えば汎用的に使う関数は、クラス設計においてどのクラスにも属しません。考え方から言えばクラス内に定義する必要が無いのですが、VBもOOPですから、必ず何らかのクラスに属さなければなりません。そこでモジュールという特殊なクラスに属させるのです。

Answer 4

皆様ご回答ありがとうございました。

 

あんまり難しく考えなくて便利だから使用するくらいで

いいのかもしれませんね。。

 

OOPプログラミングを目指すためにクラスを使用するように

します。

 

データ中心で設計・・・どこまで細かく分けていいか

時々迷ってしまいますけれど、これは経験を積んで

いかなくては理解できない領域なんでしょうかね？

 

オブジェクト思考の本だったり、サイトを参考にしていると

よく、人間を例にあげてPersonクラスを作成します

なんて例が載っていますけれど、実際のプログラミングに

置き換えるってことがなかなかできません。

 

例えばSQL Serverからクエリを発行してデータを取得する、

なんて作業は共通作業がかなりあるため

基底クラスに

・SQL Server接続

・SQLを発行(MustOverride)

・結果セット(例えばデータテーブル)を返す

継承クラスに

・SQLを発行(Overrides)

上記のような機能をつけてクラスを作成していたりするのですが

共通作業は基底クラスに、個々の処理は継承クラスで実装

みたいな考え方でコーディングする事はOOPプログラム作成

の入り口としてはいいのでしょうか？

 

なんだか抽象てきな質問になってしまって申し訳ありません。

 

 

 

 

 

Answer 5

さとさと さんからの引用

データ中心で設計・・・どこまで細かく分けていいか 時々迷ってしまいますけれど、これは経験を積んで いかなくては理解できない領域なんでしょうかね？

 

経験上、私はそう思います。以前も書いたかもしれませんが、スポーツに似たところがあって、いくら本で勉強しても体で覚えないきゃ上達しないようなものだと思っています。

さとさと さんからの引用

共通作業は基底クラスに、個々の処理は継承クラスで実装 みたいな考え方でコーディングする事はOOPプログラム作成 の入り口としてはいいのでしょうか？

いいと思います。そうやって抽象化してモデル体系を作っていくのがオブジェクト指向なのですから。
例に挙げられたSQLの話であれば、.NETにおいてSqlDataAdapterがDaTaAdapterを元に派生しているような感じですね。

Answer 6

＞・結果セット(例えばデータテーブル)を返す

 

私の場合　この部分をクラスにしていたりします。

１件だとクラス、複数レコードだとクラスの配列を返す様にしたりしてます。

レコードセットオブジェクト等が使う側に現れずに切り離せるので。

 

dim aaaMethodClass As New AAAMethodClass()

dim aaaClass() As AAAClass = nothing

aaaClass = aaaMethodClass.GetMaster("kye1","key2")

 

私もさとさとさんと同じ様に勉強中で良いか悪いか解らないですが

ご参考までに

 

Moduleはインスタンスの生成不要の静的メソッドのみのクラスは

Moduleでよいと思います。

 

ただ、Moduleを野放しにしてしまうと、VB6からVB.NETに来た人が

言語仕様も読みもしないで、クラスを作って実装すべきメソッドまで

全てModuleに実装した状態の物を目の当たりにしています。

Moduleにはそういった危険性もあります。

 

Answer 7

すでに書かれているように抽象化が最大の設計ポイントです。

経験で成長するのは、その業務なりで一番最適な抽象化レベルを導き出すまでの時間が短くなるということです。

したがって抽象化そのものをある意味正しくおこなえるようにしなくてはなりません。

それができないと、抽象化されているものをさらに抽象化しようとしたりという意味のないことをしてしまいかねません。

 

まずは、データをクラス化する(閉じられた世界を作る)練習がよいと思います。(外の概念を持ち込まないという大前提)

その後に、太郎とポチから生物で抽象化してみよう、というように段階を踏めばよいでしょう。

ただ一般的に正しいかどうかは誰しも自身で判断できませんので、こことかで具体的な質問をしてみればよいと思います。

#やさしいお兄さんたちがいろんな意見を書いてくれるでしょう。

 

あと、なんでもかんでも継承というのは問題がありますので、単に継承という言葉が出てきているなら危険です。

継承とインターフェースの違いを理解して、それぞれを使う場面かどうかの判断と、どちらを使うかの判断が必要になります。