クラスと関数について

Question

おはようございます。

 

いままで、Accessで作成していたものを勉強をかねてVBに移行中なのですが、いろいろな書籍、ネットなどで

「クラス｣といったものをみかけます。

 

おぼろげながら、イメージはわきつつあるのですが、実際に利用しようとすると、どうにも関数との違いがわかりません。

 

たとえば、人事管理を行う場合（ユーザーは1人と仮定）、生年月日や住所などの登録は１つのフォームで行い、

それ以外の場所では登録を行うことはありません。

また、その住所を読み出すのは、登録フォーム上に読み出すか、住所の一覧を印刷用に表示するぐらいです。

（内容の一部ですが）

 

この程度の内容の場合、関数ですべて事足りてしまい、クラスを作成する必要がないように思えるのです。

 

また、複数人での使用を想定する場合にクラスを作ったほうがよいというわけではないですよね。

この場合は、同時に同じデータを読み込む場合や登録時のデータの整合性をチェックすれば事足りる気がします。

 

よく、クラスの説明では、似たような記述を複数回行う場合は、クラスを作成したほうが作業効率が上がるという

記載を見かけるのですが、ほとんど一度きりの記述しかない場合はクラスを使用するメリットはないのでしょうか。

 

それとも、このような1～2名程度の使用しか想定しないアプリケーション、ならびに、同じような内容のプログラムが

ほとんど存在しないような場合であっても、クラスを使うだけの理由があるものなのでしょうか。

 

おそらく、私自身がクラスを使ったことがないので、そのメリットに気づいていないだけだと思うのですが、

クラスと関数の違いがいまいちわかりません。

 

説明しにくい内容なのは承知ですが、どうか皆様、ご教授よろしくお願いします。

Answer 1

構造化プログラミング、手続き、機能、オブジェクト指向、

というあたりのキーワードで調べて、実際にプログラミングして感触を確かめられるのが一番だと思います。

 

私の感触を述べておくと、（例によってつっこみ歓迎！ｗ）

全体が、より広く見渡しやすい。

データの意味がより明確になる。

あたりかなぁ、と。

再利用性うんぬんは副産物。というか、結構難しい。（＾＾；

 

で、なぜ、見やすいプログラムを書くべきか、というのは、

複数人でプログラム開発

１０年後とかに見直してメンテナンス（１０年も寿命があるソフトも少ないかも。）

とかを考えれば納得がいくかと。

 

ずっと一人で開発して、メンテナンスも一人でする。

自分が死んだら、そのソフトの更新は終わりにする。

自分は手続き型のほうが理解するのが容易。

という条件がそろえば、従来の関数を使う方法でＯＫかとおもいます。

 

しかしクラスを使わない、ということはNETを使わないことになるが。ｗｗ

Answer 2

TI-cb400s さんからの引用

よく、クラスの説明では、似たような記述を複数回行う場合は、クラスを作成したほうが作業効率が上がるという 記載を見かけるのですが、ほとんど一度きりの記述しかない場合はクラスを使用するメリットはないのでしょうか。

クラスは何度も同じコードを書かないようにするためのものではありません。結果的にそう見える場合もありますが、それはあくまで副次的なことです。

クラスと関数は同じレベルにあるのではなく、クラスの中でのみ関数は存在できます。

 

昔、私が書いた文章があるので、ご紹介します。関数をサブルーチンに読み替えて下さい。説明しきれていない部分や誤解を与えそうな部分もあり、あまり良い文章とは思いませんが、雰囲気は伝わるのではないかと思います。

 

引用開始 ----------------------------------------------------------

 

もし、何らかの値を算出するサブルーチンがあったとしましょう。その値をプログラムのいろんなところから参照しようと思った場合、どのようにされますか？　VBAではたぶんグローバル変数に突っ込むことになると思います。
しかし、ちょっとプログラムが複雑になってくると、グローバル変数で管理しているとわけがわからなくなってしまいます。じゃぁ、グローバル変数じゃなくて、サブルーチンの中に持って、それをいろんなところから参照できればいいじゃない。ってことになります。そのサブルーチンの中で処理をして値を求めるのであるから、その値もサブルーチンに持っちゃった方がわかりやすいですよね。これがクラスの考え方につながっていきます。よく言われるように、処理中心から値中心の考え方になるわけです。つまり、処理単位でサブルーチンを考えるのでなく、値単位でサブルーチンを考えていきます。値単位でのサブルーチンは一般的にオブジェクト指向言語ではない言語では作れません。そこでクラスが登場してきます。

オブジェクト指向言語であってもクラスではなく、いわゆるサブルーチンというのは定義できます。どちらで作れば良いのか？　迷ったら、上のこともちらっと考えてみてください。

引用終了--------------------------------------------------------------

 

引用元

DataGridViewへ別々に表示させたい。
http://www.microsoft.com/japan/msdn/community/gdn/ShowPost-36798.htm

Answer 3

 

私も、TI-cb400s さんと同じ道を来ました。

おっしゃるように、Accessで開発していた時と同じような感覚で、作れないこともないと思います。

 

ただ、それはオブジェクト指向プログラミングの片隅で出来ているに過ぎません。

 

たとえば、

Form1クラス上で、ゴシゴシ関数などの作ってコーディングを行ったとしても、

それはForm1というクラスの中で出来ることですので、

クラスを使っていないといいつつも、実は使っていることになります。

 

また、テキストボックスなどのコンポーネントも.Netではオブジェクトの１つです。

自動車の部品がいくつも存在するようにイメージすればいいでしょう。

エンジンと呼ぶにも、多数のオブジェクトで出来ていますし、人に寄っては示す範囲が違うものです。

 

私自身もそうですが、.Netの開発環境の中で、

完成のイメージに近づくのに自分の設計をどのように組むかが重要に思います。

そう言った意味で、クラスの概念が固まってきている状態なのだと思います。

 

目的を達するならば良いと思います。

ただ、より効率的な設計やコーディングの在り方を探求することも、結局自分のためになりますし、

いろいろなコードに触れて、自分なりのスタイルを築いていけば良いと思います。

Answer 4

VB2005でごく簡単に言えば、クラスとはLabelやTextBoxまたPictureBoxなど、オブジェクトの雛形です。 VB2005Helpにも次の様に書かれてあります。

「クラスはオブジェクトの構造を表すのに対し、オブジェクトはクラスの使用可能なインスタンスです。」

それで、VB2005でクラスを使うのはごく当然の事で、普段はあまりクラスについて意識しません。 つまりVB2005の開発環境では、Formにそれぞれのオブジェクトを貼り付けるだけですから。

 

ただし、他の言語ではそう簡単でなく、自分でクラスを定義し、モジュールにインスタンスを配置するとなるのでしょう、あまり詳しくないのですが。 つまりVB2005からは、あまり難しい概念を意識する事なくアプリケーション開発できるようにした、とも考えられます。

 

また、文面を拝見しますと、VB6時代の「クラス モジュール」の事を言われているようにも思われますが、それはここで言う「クラス」とは全く別物です。 VB6のクラス モジュールについてはひとまず考えない方が良いと思います。

Answer 5

葉流奈津 さんからの引用

また、文面を拝見しますと、VB6時代の「クラス モジュール」の事を言われているようにも思われますが、それはここで言う「クラス」とは全く別物です。 VB6のクラス モジュールについてはひとまず考えない方が良いと思います。

 

全く別物でしょうか? 概念にしてもできることにしても、まったく別物だとは私は思いません。 私はクラスの肝な部分は VB6 のクラス モジュールさえ理解していれば理解できると思っています。

http://blogs.wankuma.com/jeanne/archive/2006/08/02/34597.aspx

 

もっとも大切なのは 「インスタンス」 という概念を正しく理解することです。 特に 「マルチプル インスタンス」 の部分を理解しないと既定のインスタンスのある Form は良いですが、それ以外のオブジェクトの存在根本を見誤ることになります。 たとえば、解放漏れなどやらかしやすいと考えます。  「別物」 と呼ばれる所以となる部分にクラスを理解するにおいて大切な概念はほとんどないと思います。

Answer 6

じゃんぬさんこんにちは。 あまり論争したくありませんが、またスレッドの主旨からややずれますが、一度だけ。

実は、元々クラスモジュールのようなものに対する質問だったのかな、と後になって気付いたのです。 不得手な分野の為あまり言えませんが、vbsのClass文に関する説明を読んでいて気付いたのでした。

自分にとってVB6のクラスモジュールはAutomationサーバー側のメソッドを提供する為のものとしてしか理解できていません。 つまりアプリ開発上そういう需要があったからです。 それ以上の事はあまり理解できていないようです。

VB.Netについては中々踏み込めなかった方です。 それはやはりクラスとかインスタンスとか分からなかったからです。 継承なんて未だにほとんど分かっていません。 それでも、VB2005になって漸く何とか使う気になりました。 しかし今でも、Dim文にNewが必要か不要か分かっていなくて、サンプル見てそれに合わせているだけです。

これでも一応職業プログラマなんです（そろそろ引退時期です）が、何と言いましょうか、─ ある開発需要があって、それを実現する為に何を利用するか、もうそれしか考えない訳です。 アプリが実現できればそれで一先ずはOKなのです。 とは言っても品質保証は必要ですから、理解した範囲での確認は十分に行います。 一通り動けばよい等とは思っていません。

しかし、コンピュータサイエンスを勉強しようとは思いません。 それを否定しませんし、同僚にそういう人も居ますが、C++系で話がかみ合いません。 VB.Netについて話せる人が居ないのです。 VB系はそんなものではと思いますし、それで飽き足らない人はむしろC#などに転向する方がせいせいするのではありませんか？

Answer 7

お返事が大変遅くなりました。

 

皆様にご提示いただいたキーワードを元にいろいろと資料を読んでいるところです。

 

しかし、なかなか具体的に書かれている記事というものはないのですね。

(どのようにクラスを作成し、どのように実行するかといった点）

 

基本的にはデータベースアプリケーションしか作成をしないのですが、

たとえば、職員の生年月日等を表示、登録、更新、削除などをするフォームが

あったとします。

 

おそらく、以下のような機能が必要になると思います。

１．DBへの接続

２．検索のための主キーのチェック

３．データの取得

４．データの新規登録

５．データの更新

６．データの削除

７．データの取得時以降に、更新をされていないかのチェック

などなど（まだまだ、細かくはいっぱいあるとは思いますが）

 

以上の例の場合、1～7までをＡクラスなどと定義をして、

それぞれの内容を、メソッド（プロパティ？）として、記述をしていくのでしょうか。

 

Answer 8

お使いのVBのバージョンは何でしょうか？

Microsoftの用意したクラスを使うのは抵抗ないですか？

私は、自分でクラスを作るのはあまり多くないほうですが、

モジュールは使いません。

 

Answer 9

TI-cb400s さんからの引用

以上の例の場合、1～7までをＡクラスなどと定義をして、 それぞれの内容を、メソッド（プロパティ？）として、記述をしていくのでしょうか。

 

通常はformにおいてイベントプロシージャで記述していきます。イベントプロシージャはイベントが発生した時に実行されるサブルーチンみたいなものです。この辺りはAccessと同じなのでよくご存じだと思います。
では、１～７を一つのクラスにできないかと言われればできます。一つのクラスにしないかと言えばする時もあります。実際に.NET Frameworkにも存在しており、DataAdapterやTableAdapterなどがそれに当たるでしょう。
では、どのような場合に一つのクラスにまとめるのかというと、それはケースバイケースとしか言いようがありませんし、その判断をするのはある程度の経験が必要です。

 

実際のところ、オブジェクト指向は突然すっきりわかる概念ではなく、徐々にわかっていく概念だと思います。ですから、最初は無理にクラスを定義しようとする必要はありません。
幸いVisual Studioは必要なクラスを自動で作成してくれます。よく、自分はオブジェクト指向のプログラミングをしていないと言われる人がいますが、formを表示するということは、クラスを作成してコードを書くというオブジェクト指向プログラミングを行っていることに他なりません。これを意識させないのがVisual Studioのすごいところだと思いますが、敢えて、自分はクラスを書いてオブジェクト指向プログラミングをしているんだという意識を持った方が上達が速いと思います。

 

ある処理を実現するためにどのようなクラスを定義するかは、データベースにどのようなテーブルを定義するかによく似ています。どのように正規化してどのようなＳＱＬを発行するかを考えるはずです。それと同じでどのようなクラスを定義してどのような機能を持たせてどのように連携させるかを考えなければなりません。

以上を実現するのはコードですが、本当に大事なのはコードの文法の学習ではなく、そういう設計です。コードは道具ですから道具が良いことに越したことはありませんが、設計が悪ければ出来上がるものは悪いに決まっています。
設計の能力は学習で基礎はできますが、応用は訓練でしか得られません。ですから最初に戻りますが、１～７を一つのクラスにするかしないかという問題は、実は難しい問題になる可能性を秘めており、明確にこうだという解答は存在しないでしょう。

Answer 10

葉流奈津さん、スレの趣旨からも違いますし、少しだけ。

 

葉流奈津 さんからの引用

VB系はそんなものではと思いますし、それで飽き足らない人はむしろC#などに転向する方がせいせいするのではありませんか？

 

VBもC#もその点では同じだと思います。Visual Studioによるサポートによってオブジェクト指向プログラミングを始める敷居はずいぶん下げられています。そこはすごいところだと思いますが、反面、自動で生成されたコードの背景やら体系やらを自分で積極的に理解しようとしないとステップアップすることができません。問題は、VBでもC#でも次の一歩を踏む出すかどうかだと思います。次の一歩を踏み出さないということも否定しません。多くの高機能を使わなくとも、品質が良いアプリケーションを作れることを知っているからです。いつの時代もユーザーに満足してもらえるのが一番だと思っています。当たり前なんだけど、当たり前で通らないことも多々あるんですよね・・・

Answer 11

おはようございます。

 

いろいろとご提示のキーワードを元に、資料を読み込んでいるところなのですが、

なかなかイメージがつかみづらいものですね。

 

マルチプルインスタンスに関する資料を読んでいるときに、関数との違いという点で

「何がしかの繰り返し処理をする関数があり、どこまで処理が進んでいるかということを

関数内の変数で持つ場合、異なる箇所で同じ関数を使用した場合、どこまで同じ処理を

しているかという変数を2つの処理で上書きをしてしまい、正確に動作をしないことが

起こる。」(正確に転記はできていないと思います）

 

という記述があり、上記のような点の場合は、クラス化しておき、インスタンスとして

処理を行う場合に、動的に生成をするという方法をとると、データの衝突、上書きといった

事態は避けることができる。という説明がありました。

 

これは非常にわかりやすく、クラスを作るという理由が少しだけわかった気がします。

 

ただ、私の今までのDBアプリケーションの作成方法として、DBからデータを取得し

フォームに表示する場合、取得したすべてのデータをいったんフォーム上に転記して

しまい、DBを更新するときにフォーム上の値を参照するということをしていたので

（非常におかしなやり方かもしれないのですが)

このような部分において、クラスを利用するメリットというものをあまり感じません。

 

別のフォームから、検索用のキーを取得し、元のフォーム上にそのキーを元に取得した

データを取得する（検索フォームで主キーを含むデータを取得し、職員情報を表示する

フォームにデータを展開する場合など）ということをよく行っており、このような場合においても

標準モジュールに処理を記述しておき、展開する対象のフォームを変数に格納しておけば

たいていのことは処理できていましたが、このような点はクラス化すると、どのフォームからの

処理ということを意識せず、職員情報を取得し現在のフォームに表示をするということが

可能になるため、わかりやすくなる機がしますが、このような理解でよろしいのでしょうか。

 

ご回答いただいている皆様、上記内容には間違いが多いと思いますので、どんどんつっこみを

入れて下さい。

 

よろしくお願いします。

Answer 12

TI-cb400s さんからの引用

（非常におかしなやり方かもしれないのですが) このような部分において、クラスを利用するメリットというものをあまり感じません。

 

別段おかしなやり方とは思いません。クラスを利用するメリットがないと感じられることも間違っているとは思いません。クラスを導入するかどうかは、その時々の設計によるのですから。

 

TI-cb400s さんからの引用

このような点はクラス化すると、どのフォームからの 処理ということを意識せず、職員情報を取得し現在のフォームに表示をするということが 可能になるため、わかりやすくなる機がしますが、このような理解でよろしいのでしょうか。

その理解でＯＫです。OOPでないAccessのような構造化プログラミングは、その処理の流れ自体に意味があります。特にグローバルな変数は処理の流れを追わないとどう処理されるのかわかりません。これは非常にわかりにくく、バグを生む原因になります。
構造化プログラミングを経験した人がOOPを始めると、どうしてもサブルーチンや関数の考え方を持ち込みがちです。しかし、考え方をもっと思い切って変える必要があります。処理の流れを制御しながらプログラムが動くのではなく、オブジェクトが連絡しながらプログラムが動くという考え方へです。
ある一部分の処理を考えて、これはクラスにする必要があるのかないのかという考え方ではありません。その考え方ではやはり処理中心の考え方から頭を切り替えられていません。OOPでクラスを使うということは、もっと大局的なことです。例えるならクラスは会社の各部署であり、この組織図を決めること自体に意味があるのです。サブルーチンや関数は各部署が効率よく作業できるようにする仕組みでしかありません。クラスによって会社の組織が設計され、実際の仕事が効率よく行われるように構造化プログラミングがあります。なので、OOPの時代だから構造化プログラミングを勉強しなくて良いということではありません。

Answer 13

皆さま、こんにちは。

 

葉流奈津 さんからの引用

じゃんぬさんこんにちは。 あまり論争したくありませんが、またスレッドの主旨からややずれますが、一度だけ。

 

いえ、私も別に論争をするつもりはないですし、脱線したつもりもありません。 そういう風に見えたのであれば申し訳ありません。 私の知らない何かしろの情報があるなら知りたい、そうでないなら認識が間違っているので指摘した方が閲覧者の誤解がなくて済むのでは、という思いからの投稿でした。(自分も逆の立場であればそうして頂いた方が嬉しいです)

 

実は、元々クラスモジュールのようなものに対する質問だったのかな、と後になって気付いたのです。 不得手な分野の為あまり言えませんが、vbsのClass文に関する説明を読んでいて気付いたのでした。 自分にとってVB6のクラスモジュールはAutomationサーバー側のメソッドを提供する為のものとしてしか理解できていません。 つまりアプリ開発上そういう需要があったからです。 それ以上の事はあまり理解できていないようです。

 

そういうことでしたか。 あまりに断定的だったので個人的な事情でない別の理由があるのかと思っておりました。

 

VB.Netについては中々踏み込めなかった方です。 それはやはりクラスとかインスタンスとか分からなかったからです。 継承なんて未だにほとんど分かっていません。 それでも、VB2005になって漸く何とか使う気になりました。 しかし今でも、Dim文にNewが必要か不要か分かっていなくて、サンプル見てそれに合わせているだけです。 これでも一応職業プログラマなんです（そろそろ引退時期です）が、何と言いましょうか、─ ある開発需要があって、それを実現する為に何を利用するか、もうそれしか考えない訳です。 アプリが実現できればそれで一先ずはOKなのです。 とは言っても品質保証は必要ですから、理解した範囲での確認は十分に行います。 一通り動けばよい等とは思っていません。

 

このあたりは、話のつながりがちょっとわかりませんでした。 ごめんなさい。

しかし、コンピュータサイエンスを勉強しようとは思いません。 それを否定しませんし、同僚にそういう人も居ますが、C++系で話がかみ合いません。 VB.Netについて話せる人が居ないのです。 VB系はそんなものではと思いますし、それで飽き足らない人はむしろC#などに転向する方がせいせいするのではありませんか？

 

なぜ C# に転向というお話が出てきているのでしょうか? 私は C# も VB も両方好きなので転向という概念はないです。 ひょっとしてリンク先の記事への反論... なのでしょうか? もしそうであれば、初めにあります "論争したくありませんが" はこの文章のことだったのでしょうか? だとすると、私の先の投稿が伝わっていないのかもしれません。 引用して明示しているとおりで、

 

また、文面を拝見しますと、VB6時代の「クラス モジュール」の事を言われているようにも思われますが、それはここで言う「クラス」とは全く別物です。 VB6のクラス モジュールについてはひとまず考えない方が良いと思います。

 

私はあくまでも上記の引用部分について、『根本的な概念は同じなので 「クラスモジュールと全く別物」 ではないのでは?』 という投稿をしたに過ぎないです。 もし記事の感想を書いているのであれば、まさに脱線になると思います。 そのあたりは Blog にコメントすれば良いと思います。 と、この私の投稿こそ脱線にあたるわけですが...

と、ここまで書いたものの途中の話がちょっとわからないので、私が読み間違えていないか不安です。