【C#】WPFアプリケーション入門 #10 オブジェクト指向

はじめに

いままで扱ってきたクラスやメソッドなどはオブジェクト指向の考え方に沿って動いています。実はオブジェクト指向を調べると、人によって解釈が異なります。最近はオブジェクト指向という考え方は必須ではない傾向にあるので、ぼんやり「こんなもんかな」程度の認識でもいいです。実装中はわざわざオブジェクト指向を考えたりしないと思うので...。

お品書き

今回扱う内容です。

  1. オブジェクト指向
  2. オブジェクト指向の個人的解釈
  3. オブジェクト指向は必要か

1. オブジェクト指向

オブジェクト指向とは次の3要素で構成されるプログラミング手法です。

これを意識してプログラミングするのが重要だという話だったのですが、最近はオブジェクト指向という考え方を否定する人がいます。今となってはどちらが正しいのかは明確ではありませんが、必要だと思えば意識すると良いかもしれません。

1.1 カプセル化

これは #9 の記事に説明があります。ユーザが直接触れられないようにデータを隠す(カプセルに入れて保護する)ことです。アプリの中心はデータを扱うところにありますが、ユーザによって予期せぬデータが操作された場合、アプリが停止する可能性があります。よって、ユーザは間接的に操作できるようにするような仕組みにすれば、中身をいじられることはありません。
また、複雑な処理 (内部処理) を抽象化することで簡単な構造でデータを扱えるようになります。

1.2 継承

扱うデータやメソッドなどの操作系を含めた設計図をクラスといいました。クラスをいくつか作成したとき、そこに共通のデータがある場合は大元のクラスにまとめればいいわけです。これを受け継げば、どのクラスも大元のクラスのデータを利用することができます。
つまり、無駄にいくつも同じデータを用意せずに一か所にまとめて、それを参照できるようにすれば効率的という考え方です。
大元のクラスを基底クラス、基底クラスを参照するクラスを派生クラスといいます。 Java では親クラス子クラスといいます。

1.3 ポリモーフィズム(多様性)

これは一番厄介ですね。多様性といわれてもピンと来ないかもしれません。簡単に言うと、同じメソッド名でも条件によって動作が異なるように動かせることです。
車を例に考えてみます。車にはアクセルとブレーキが付いています。もちろん、アクセルを踏めば加速して、ブレーキを踏めば減速します。すべての車は同じ操作で加減速できるわけですが、車種によって性能が異なります。つまり、大元の操作は同じですが、車種という条件によってデータの扱いが異なります。このようにして共通のメソッドでも条件によってデータの扱いを変えることができます。これが多様性です。

2. オブジェクト指向の個人的解釈

一般に考えるオブジェクト指向が上記の通りですが、私の考えるオブジェクト指向は次の通りです。

2.1 クラスとメソッド

クラスは設計図ですが、メソッドは何かが問題です。メソッドは関数として考えれば、複数の処理をひとまとまりにすることができます。
メソッドは動作でクラスは動作に必要なデータの集合体です。メソッド自体もクラスに含まれるので、集合体の一つとして扱えます。メソッドがメソッドを呼ぶようなイメージです。
そもそも、オブジェクト指向はモノとして扱えるというのが大まかな意味です。なので、UI を配置した時点で UI に関するデータが用意されます。例えば Button を配置するとしましょう。すると、Buttonにはこのようなデータが用意されます。

  • Background (ボタンの背景色)
  • Content (ボタンに表示する文字)
  • Fontsize (ボタンに表示する文字の大きさ)

このほかにもたくさんのパラメータがあります。これらは Button クラスに含まれる、ボタンに関するデータの集合体です。さて、デザインにてボタンをダブルクリックすると、OnClick( ) メソッドが自動で生成されたと思います。これこそがボタンに関する処理です。

このように Button というモノ (UI) にはクラスが用意されており、クリックされたときにどうするかというメソッドを作ることができます。クラスとメソッドがセットになって Button というオブジェクトを作っていると考えると自然でしょう。これが私の考えるオブジェクト指向です。

2.2 継承

継承は 1.2 で説明した通りで、基底クラスでデータを一括でまとめておけば派生クラスから再利用 (何度も参照) できるので、設計図自体をモノ (情報のかたまり) として扱えるという点です。

2.3 インスタンス

クラスを扱うにはインスタンス化が必要です。クラスを用意するだけでは利用できないので、インスタンス化によって実体化させないといけません。実体化したデータ (フィールドやメソッド) はメンバと呼ばれ、外部から使用するためにはアクセシビリティの指定でアクセス許可することも必要です。

2.4 オブジェクト指向はどこからオブジェクトなのか

これも個人的見解です。オブジェクト = モノ ということを考えれば、今まで記述してきたことすべてが当てはまります。つまり、こうです。

f:id:takunology:20190710021608p:plain

ここで、かたまりを考えます。例えば派生クラスは基底クラスから継承されているので、情報のかたまりとしてのオブジェクトです。UI と派生クラス1は UI とそれに関するメソッド、およびクラスを含むのでこのかたまりもオブジェクトです。これらを合わせれば、UI の元をたどれば基底クラスまで含まれるので、アプリ全体は1つのオブジェクトとして考えられますね。
と考えると、継承しているところはすでに1つのモノになるのでこの時点でオブジェクトになるのではないかと...。

3. オブジェクト指向は必要か

大規模なアプリを作る場合はオブジェクト指向を考慮したほうが設計しやすく、共同作業者で情報や考え方を共有できるので必要になると思います。一人で開発するときや、小規模なら深く考えずに実装してもいいと思います。ただし、継承やメソッドなどの関係を考慮するなら必要であると思います。

おわりに

オブジェクト指向を完全に理解するのは難しいです。そもそも概念なので、人によっては解釈が異なることがあります。今回は私の考えるオブジェクト指向も記載しましたが、世間一般のエンジニアの方々から見れば「何言ってるんだ」といわれるでしょう。

オブジェクト指向は本当に難しいです。