CSharp_other


※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

オブジェクト指向言語のよく使う機能


どうせ音のデータは生産した後に書き換えない(コンストラクタ)

サウンドロップは音を書き換えることができません。書き換えるのは生産するときで十分でしょう。オブジェクトを作る時には

Soundrop sd = new Soundrop();

とやっていましたが、Soundrop();なんて関数いつ定義したんでしょうか。
実は勝手に定義されています。この関数はコンストラクタという関数で、 Soundrop.Soundrop();としてSoundropクラスで自動で定義されます。
この中身を書き換えることで、呼び出しの時に自分の意図した処理を行うことができます。
引数もとることができ、ここにsetFileNameの機能も足してしまいましょう。

ということでSoundrop()という同じ名前の関数が二個できてしまいました。これっていいのか?というとイインデス。
Soundrop();の時は引数の無い関数が、Soundrop("hoge.wav");の時はstringを設定してある関数が呼ばれます。
この同じ名前の関数を複数定義して、引数によって処理を変えるということを関数のoverload(オーバーロード)といいます。便利ですな。

thisとかbaseとか。

同じクラスの中にある関数を呼び出すときはinstance.function();としなくても、function()とするだけで呼び出すことが可能でした。
しかしながらfunctionの前にはきちんと文字が省略されています。
え、でもstaticで宣言されてるならclassName.functionでclassはプログラム中には1こしかないから呼び出すことができるけど、
instanceはプログラム中に何個も生成されるから、どれがどれかなんてわからんでしょ。
と、なってしまうのですがそんなことは無く、クラス内は閉じられてるので、用は自分自身だけわかればOKっす。
ということで自分自身をあらわす単語はthisです。自分自身の参照を渡したい時もthisを利用します。また、スーパークラスはbaseを利用して参照することができます。

C#のアクセサメソッド(ゲッター系・セッター系)はもっとスマートに書ける(プロパティの代入、値の取得)

C#はオブジェクト指向の言語の中でも後発で、他の言語を見てきただけあって書き方が洗練されています。
SetSoundNameはこんなまどろっこしい書き方をしなくても次のように書くことができます。

ソース

このクラスのsoudFileNameのようなにクラスに属する変数をプロパティと呼びます。
先ほどのオブジェクトで言うところの「状態を保持する」機能を提供しています。
言語によってはフィールドやメンバ変数とも呼ばれるのですが、それに値を定義する関数をセッター、
値を取得する関数をゲッターなどと呼びます。これをつけすぎると、
カプセル化の意味が成されなくなる場合があるので、全部のプロパティに対してゲッター、セッターを付けるのではなく、
必要なものを記述するようにしたほうがいいです。

その他


オブジェクトがオブジェクトを使う!

このホルダークラスの関数、pushAllではホルダークラスの中に入っているサウンドロップオブジェクトを次々にプッシュしていっています。もちろん記述は
for(obj in Array){
 obj.push();
}

となるわけですが、関数の記述にsoundropオブジェクトが登場しています。
ということはホルダークラスは、soundropオブジェクトを使って処理を行っている分けです。
このように、オブジェクトが他のオブジェクトを利用して、プログラムが進んでいきます。
ある程度大きなコーディングにならないと、このオブジェクト同士が通信を行っている実感はわかないと思います。
しかしながら、どのオブジェクトと、どのオブジェクトが関係しているかという、
オブジェクト間の通信というのが設計のメインになってきまして、この関係を明確にしておかないと、
最終的に突っかかることになります。(・・・この関係を再度絞り込めるようにオブジェクトを設計することも大切ですけど。)

UnifiedModelLanguage...略してUML

UMLとはオブジェクトを図に書き表して、他の人と設計を共有しよう!と定められた言語です。
というか図です。12種類ぐらいあって、それぞれ意味が異なります。
オブジェクト指向言語の仕様がわかったなら次はこれを学ぶと良いとされております。
分析->設計->実装の流れをオブジェクト指向は踏むのですが、分析段階で書き起こす図と設計段階で書き起こす図と、
そういう細かいところまで研究され尽くしています。詳しくはUMLの書籍を漁っていただきたい。
UMLはプロジェクトチームで有効なはず!=これTNPで覚えれば実践できんじゃね?!と思って早3年。
未だに使うのはクラス図とオブジェクト図、シーケンス図程度というオチでした。
しかもみんな覚えないと使い物にならんから敷居が高いのなんのって!とりあえずオブジェクトやらインスタンスやらがカッチリ入った上でしかこれは入ってこないので、
あせらずこういうもんがあるんだよという事だけでOKです。1年後ぐらいを目安にボチボチやっていきましょう。

ポインタはあるのか?

ポインタはありません。関数の参照渡しを行う場合は「参照」という機能を利用します。基本的にプリミティブ型のオブジェクト以外を引数に取った場合は自動的にポインタになります。逆にプリミティブ型のオブジェクトを引数にとった場合は値渡しとなります。意図的に参照渡しを行いたいときには

void huga(ref int hoge);

として関数の引数に定義します。refです。referenceのref。
また関数をコールバックとして渡す場合は、デリゲートという仕組みを用います。

デザインパターン

デザインパターンとはオブジェクト指向でよくおこりうるオブジェクトの組み合わせを列挙してパターン化したものです。
このように設計はある程度セオリーとして確立されていますが、はじめのうちは自分で考えたりするのが面白いです。
そもそも、アブストラクトファクトリとかを丸々暗記しても何のこと言ってるかまったくわかりません。
実際に自分で考えて運用して、あとからデザインパターンで確認して、ああ、それ俺もやってたわ、
と納得したりするタイプのモンらしいのであせらなくていいと思います。
そもそもクラスとインスタンスの役割や、継承などの機能がはっきりしないとデザインパターンの意味を把握できませんし。