|
|
|
VB.NETの配列の書き方 |
■配列の記述の統一をしよう！
VB.NETでは、配列の表現方法が一定でない。
例１ Private apple As Integer()
例２ Private apple() As Integer
これは、同じプロジェクト内で混在するとかっこ悪い。
疲れている時に必要に迫られてメンテしているとイライラするし（笑）
なので、統一した方が良い。
■配列の初期化の方法
なお、配列の初期化は、こんな感じで。
Private apple() As String = New String(2) {"うまい","ふつう","まずい"}
Private apple() As String = {"うまい","ふつう","まずい"}
※Newしなくても、大丈夫です。
■配列の正体と利用例
ついでに、利用例を書いておく。
初心者の為に（＋自分の為に（笑））
VB.NETの配列は、System.Arrayクラスからの派生になるので、
参照型として、インスタンスが出来る。
（だから、正式な記述方法として、Newが必要）
メソッド間での引数の引渡しは、名前のみで渡す。
こんな感じ。
Dim _str1() As String ' １次元配列
Dim _str2(,) As String ' ２次元配列
_str1 = New String(2) {"AAA", "BBB", "CCC"}
_str2 = New String(2, 2) {{"111", "222", "333"}, {"444", "555", "666"}, {"777", "888", "999"}}
TestProc(_str1, _str2)
Private Sub TestProc(ByVal s1() As String, ByVal s2(,) As String)
For Each _s As String In s1
Console.WriteLine(_s)
Next
For Each _s As String In s2
Console.WriteLine(_s)
Next
End Sub
引数として渡す時は、名前のみ（インスタンスを渡すってことですね。）
受け取る時は、配列付きで（型指定で、ってことですね。きっと。）
（実行結果）
AAA
BBB
CCC
111
222
333
444
555
666
777
888
999
お役に立てたら、クリックしてちょ！！
Hamのスピリチュアル日記は、こちら
地球を救え！プレミアム
|
|
Overrides & Overloads |
昨日、クラスを２個作って、
ポリモーフィズムの便利さを実感しようとしたのだが、
どうも、うまくいかなかった。
ぼくの理解では、絶対にうまくいくはずなのに。
なんでだ？
SalesOrderクラスには、
注文受付メソッド （注文受け付けました！とmsgboxが出る。）
注文確認メソッド （注文書ＦＡＸしました！とmsgboxが出る。）
WebSalesOrderクラスには、
SalesOrderクラスを継承して、
注文確認メソッド （注文書メールしました！とmsgboxが出る。）
（SalesOrderクラスの注文確認メソッドをオーバーライド）
こんな感じでクラスを作って、ポリモーフィズムしようとした。
だが、WebSalesOrderクラスのインスタンスを渡しても、
「注文書ＦＡＸしました！」が表示されてしまう。
さて、今日、会社で眠くなって、仕事に飽きた時、眠気覚ましに、
再度、１からコーディングして試してみると、なんとすんなり出来る。
なんで、家でやるとダメなのだ？
と、帰ってきてから、よくよく見たら、
オーバーライド宣言が、オーバーロード宣言になってた（笑）
これ、きっと、笑われるかもしれないけど、
オブジェクト指向初心者には、紛らわしいんですけど。
Visual Basic 言語リファレンスより
Overrides
プロパティまたはプロシージャが、基本クラスから継承された、同じ名前のプロパティまたはプロシージャをオーバーライドすることを指定します。
Overloads
プロパティまたはプロシージャが、1 つ以上の既存のプロパティまたはプロシージャを、同じ名前で再度宣言することを指定します。
お役に立てたら、クリックしてちょ！！
Hamのスピリチュアル日記は、こちら
地球を救え！プレミアム
|
|
オブジェクト指向のメリット（４） ひと休み |
継承の記事を書いたところで、
その先の「ポリモーフィズム」と「インターフェース」についても、
一気にまとめてしまうおうと試みたが、いまいち理解出来ない（笑）
継承とインターフェイス
Microsoft .NET へのアップグレード
http://www.microsoft.com/japan/msdn/net/upgrade/interinher.aspx
さっきから、ずっとこの記事を読んでいるのである。
わかるまで、何度も読むつもりなので、完全に理解した所で、
次の記事につなげる予定。
ちなみに、SalesOrderクラスとWebSalesOrderクラスの
Confirmメソッドの実装は、インターフェースを使った方が、
よりスマートに汎用性が高いことだけは、何となく理解した。
注文形態が増えて、xxxxxOrderクラスが沢山作成されるような時、
前述したSalesOrderクラスとWebSalesOrderクラスでは、
クラスの階層的にも気持ち悪いなあと思っていたので、
早く理解して、すっきりさせたいものだ。
お役に立てたら、クリックしてちょ！！
Hamのスピリチュアル日記は、こちら
地球を救え！プレミアム
|
|
オブジェクト指向のメリット（３） 継承について |
オブジェクト指向に入り、最初に面食らう概念に「継承」がある。
今のぼくは、「継承」の概念は、なんとなく理解出来ているつもり。
そこで、おさらいも兼ねて、まとめてみよう。
継承階層
継承を使用すると、既存の (基本) クラスのバリエーションである新しいクラスを作成し、元の基本クラスが呼び出されていた状況で、新しい派生クラスが呼び出されるようにすることができます。たとえば、SalesOrder というクラスがあった場合、WebSalesOrder という名前の新しい派生クラスを次のようにして作成することができます。
（以上、下記参考１サイトより引用）
上記の例だと、SalesOrderクラスを使って、WebSalesOrderクラスを作成している。
SalesOrderクラス（店頭注文クラス）
WebSalesOrderクラス（ネット注文クラス）
勝手に日本語にしてみました（笑）
既存システムで、店頭注文で利用するSalesOrderクラスが実装されているとする。
そして、新たに、ネットで注文を受け付けることになったとする。
店頭の注文でも、ネットの注文でも、やるべき手続きはほぼ同じ。
違うのは、店頭注文では、顧客に送っていた注文確認書を、
ネットでは、電子メールで送りたい、ということ。
さあ、ソフトウェアの改造。
いろんな方法が考えられる。
■例１ 複製を作る。
SalesOrderクラスをコピーして、WebSalesOrderクラスを作成。
更に、注文確認書の送り先をFAXからメールに変更。
■例２ SalesOrderクラスを改造する。
SalesOrderクラスに、注文方法の区分プロパティを追加。
１なら店頭注文、２ならネット注文、みたいな。
更に、注文確認書の送り先の部分を、１と２について条件判断を加え、
メールでも送れるように改造。
■例３ NewOrderクラスを作成する。
新たに、NewOrderクラスを作成。
仕様は、案２のような注文方法の区分プロパティを追加し、
店頭注文の場合は、SalesOrderクラス、
ネット注文の場合も、SalesOrderクラスを利用するが、
注文確認書の処理だけ、NewOrderクラスに実装。
■例４ SalesOrderクラスを継承して、WebSalesOrderクラスを作る。
外から見ると、案１に似ている。
違うのは、同じコードはSalesOrderクラスのものをそのまま利用し、
注文確認書の送り先の部分だけを、WebSalesOrderクラスに実装。
他にもあるかもしれません。（多分、あるでしょう。）
とりあえず、例としてはこんなところで。
意外に例１を選んでしまう人は多いと思われる。
徹夜明けで、何も考えられない時は、
もっとも安直に思える方法を選んでしまうものだし ^^;
しかし、注文内容の手続きが変わってしまった時、
SalesOrderクラスとWebSalesOrderクラスの双方に変更が発生する。
同じコードが、あちこちに点在するのは、
メンテナンス上、好ましいことではない。
例２の方法は、無闇にクラスを増やしたくない場合、採用するかも。
ただ、元気に動いていたSalesOrderクラスに手を入れるので、
それ相応のテストが必要になる。
例３の方法は、クラスを利用する側にとって便利。
注文の方法だけ、クラスが増えていくと、それだけで気が重いし。
ただ、今まで、SalesOrderクラスを利用していた部分まで、
NewOrderクラスに変更する必要がある為、既存システムの改造としては不適。
そして、例４の方法である。
SalesOrderクラスには一切手を入れずに、
新たな機能だけWebSalesOrderクラスに実装し、
しかも、どちらのクラスでも、SalesOrderクラスの機能を利用出来る。
こんな風に書いていくと、
ああ、継承って、とても便利だな、と思えてくる。
ただ、前にも書いたけど、クラス設計をちゃんとやらないと、
なんとなく継承しているクラスが、どんどん出来てしまいそう。
今回も、店頭注文、ネット注文の他に、別な注文形態が発生した時、
SalesOrderクラスを継承するのか、WebSalesOrderクラスを継承するのか、
プロジェクト内で、意識合わせを行わないと、いびつなクラス階層になりそう。
まあ、通常は、SalesOrderクラスを継承する、とは思うが。
さて、VB.NETにおける継承の記述例である。
SalesOrderクラスが、
Public Class SalesOrder
End Class
と定義されていたとすると、
Public Class WebSalesOrder
Inherits SalesOrder
End Class
みたいな感じで、継承するらしい。
そして、SalesOrderクラスの注文確認書の発行イベントが、
Public Sub Confirm
FAX送信の処理
End Sub
と定義されていたとすると、
WebSalesOrderクラスの中で、
Public Overrides Sub Confirm
電子メールの処理
End Sub
みたいな感じで、定義し直す。
これで、WebSalesOrderクラスを生成してConfirmメソッドを発行すると、
電子メールが送信されるようになる、というわけだ。
もちろん、他のメソッドは、SalesOrderクラスのものと全く同じ動きをしてくれる。
参考１
継承とインターフェイス
Microsoft .NET へのアップグレード
http://www.microsoft.com/japan/msdn/net/upgrade/interinher.aspx
お役に立てたら、クリックしてちょ！！
Hamのスピリチュアル日記は、こちら
地球を救え！プレミアム
|
|
オブジェクト指向のメリット（２） オブジェクト指向におけるカプセル化の実現 |
オブジェクト指向におけるカプセル化の実現方法である。
まず、クラスの概念を整理。
クラスの定義
オブジェクトのプログラミングとは、具体的には、内部データを保持するための変数を宣言し、オブジェクトが持つメソッドやプロパティが呼び出されたときに実行されるコードを記述することです。そして、これらをひとまとまりとして記述した一連のコードは「クラス」あるいは「クラスの定義」と呼ばれます。
（以上、下記参考１サイトより引用）
構造化プログラムでも、
外部モジュールには、内部データ領域と手続きを書くことが出来る。
これを、カプセル化と呼べなくはない、と思える。
だが、ここで大変に大きな違いがあるのだ。
オブジェクト指向におけるカプセル化（クラス）は、それ自体、変数として扱えるのである。
例えば、請求書番号を入力すると、請求書を返す手続きがあったとする。
構造化プログラミングでは、請求書番号をパラメタにセットして、手続きを実行すると、
何らかの構造体のような変数粋に、請求書の内容（データ）がセットされて戻ってくる。
請求書の内容を複写する為の領域は、基本的に固定であり、
双方のインターフェースは、整合性が取れていなければならない。
また、呼び出し側では不要な情報も、変数として用意しておく必要がある。
オブジェクト指向プログラミングでは、請求書番号を使って請求書オブジェクトを生成する。
これは、一つの塊であり、請求書の内容は必要に応じて参照する形になる。
呼び出し側は、自分が必要な情報のみをすれば良い。
また、他の外部手続きが、請求書の内容を必要としている時は、
請求書オブジェクトを、ぽん！と渡すだけで良い。
これは、コードを書く上で、非常に気が楽である。
ということで、うまく書けないが、後に取り上げようと思っている、
継承やインターフェースの概念を知らなくても、
このカプセル化による、コードの省力化？は、非常に強力なものだと感じているし、
実際のところ、これぐらいのことは、ぼくも普段、利用している。
請求書であれば、こんな感じかな。
■請求書の鏡クラス
請求書�發篝禅畧茲鮖�つ。
請求書のテーブルとの読み書きメソッド
請求書の印刷メソッド等
請求書の明細クラスのコレクション（配列）
■請求書の明細クラス
伝票�癲⊆莪�日付、摘要、単価、数量、金額を持つ。
請求書�發鯏呂靴董∪禅畚颪龍瀬�ブジェクトを生成すると、
該当の請求書の情報が全て得られるばかりか、
変更、削除、印刷等もしてくれる。
細かなことを意識せず、請求書としての塊を使いながら、
プログラミング出来るので、安心感が増す。
複数の請求書を保持したい時でも、
請求書オブジェクトを配列かコレクションにぽんと入れるだけ。
本当に楽ちんになります。
これを構造化プログラムで実現しようとすると、出来ないことはないが、
カプセルの外でも、請求書に関する多層のデータの持ち回りが発生するし、
外部手続きの作り方が悪いと、様々な制約に振り回されてしまうことが多い。
これを、実社会に当てはめてみると。
任務）ある請求書を探して、社長に渡してくれ！
【オブジェクト指向の場合】
ある請求書を取り出して、社長に渡す。
（請求書の中身については、見る必要がない。）
【構造化プログラミングの場合】
ある請求書を取り出して、その内容を一つ一つ理解した後、社長に渡す。
（請求書の中身まで、とりあえず、知っておく（定義する）必要がある。）
渡すだけなら、請求書の中身を知る必要は、ないですよね。
このように、オブジェクト指向は、ぽんぽん渡すことが可能になります。
こんな所が、カプセル化と言われる所以であり、
構造化プログラミングでの実装と大きく異なる部分と感じています。
参考１
オブジェクト指向プログラミング超入門
第2回 クラスの定義からプログラム実行まで
http://www.atmarkit.co.jp/fdotnet/basics/oop02/oop02_01.html
お役に立てたら、クリックしてちょ！！
Hamのスピリチュアル日記は、こちら
地球を救え！プレミアム
|
|
