オブジェクト指向の要素
- オブジェクト
- 手続き関数
- 手続き処理開始関数(main関数、イベント)
オブジェクト
- データ
- データに対しての処理
を一つの塊として定義したもの。(いわゆる『カプセル化』である。)
故に、『オブジェクト=カプセル化』であり、『オブジェクト指向＝カプセル化指向』と言ってもいい。
(オブジェクトなんて造語を作らず最初から『カプセル化指向』って言って欲しかった。)
上記から分かる通り、オブジェクト指向でオブジェクトは**『データと処理は１セット』**だ。
したがってオブジェクトとして作られたクラスは
- 必ずデータと処理が存在
- 処理はクラス内のデータに対して何かする形になる
という性質を持つ。
手続き関数
オブジェクトと別の手続き関数を一定の手順に従って呼び出す関数。
なお、再帰などをする場合は自分自身を呼び出すこともある。
例：顧客情報画面で入力したデータを登録する。(『』：オブジェクト、【】：手続き関数)
１．『画面デザイン』から『顧客情報』を受け取る
２．【顧客情報の登録前チェック処理】に『顧客情報』を渡す。(異常なら終了)
３・『顧客情報』を【DB登録処理】へ渡す
４．【DB登録処理】から『DB登録結果』を受け取る
５．【登録結果メッセージ表示処理】に『DB登録結果』を渡す
手続き関数は
- クラス内にデータを持たない。
- オブジェクトではないので継承できない。(してはならない)
という性質を持つ。
上記の定義を見るとわかるが、手続き関数はクラス内にデータを持たない。
つまり手続き関数はオブジェクトではない。
オブジェクトではないから、『継承』とか『カプセル化』のような概念はない。(そもそも継承、カプセル化できるものがない。)
そのため、手続き関数を継承してはならない。
手続き関数の開始関数(main関数、イベント)
処理を開始する起点となる関数。main処理、イベントなど
この関数は起点だけの為、手続き処理を１つ呼び出すだけの動作と例外処理のような呼び出し元で書く必要がある処理のみを記載するようにする。
俺の知ってるオブジェクト指向の要素と違うんだけど？
多分これの事かな？
- カプセル化
- インタフェース(ポリモーフィズム、多態性)
- 継承
上記は、『オブジェクト』の３大要素だ。そのため、
- オブジェクト
- 手続き関数
- 手続き関数の開始関数
のうち、『オブジェクト』のみに該当する内容だ。
逆に言えば、手続き関数、手続き関数の開始関数に対しては該当しない。
オブジェクト指向のコードと『共通化』『再利用性』『保守性』の関係
まず、
「オブジェクト指向で書かれたコードは、『共通化』『再利用性』『保守性』が高いコードになる。」
これは間違っていない。
しかし、この現象は『コードがオブジェクト指向で書かれている』ことが重要なんだ。
『コードがオブジェクト指向で書かれている』から結果的に『共通化』『再利用性』『保守性』を生み出している。
だから考えるべきは『オブジェクト指向のコード』であって『共通化』『再利用性』『保守性』の高いコードではないんだ。
だけど現場では上から下まで「『共通化』『再利用性』『保守性』の高いコードを書くべきだ！」と主張する。
そして皆がその声に従い、『共通化』『再利用性』『保守性』を考えてコードを書こうとしてしまう。
だけど『オブジェクト指向のコード』に対し『共通化』『再利用性』『保守性』の観点で書いたコードを入れれば、そのコードはオブジェクト指向ではなくなり、結果的に『共通化』『再利用性』『保守性』が失われてしまう。
例えば、下記のようなコードのことだ。
- 神フォームクラス
『共通化』したいコードをまとめまくり、巨大化したフォームクラス。
その下には小神フォームクラス、小々神フォームクラスと続き、人間がいかに矮小か思い知らされる。(そして神の考えは理解できない。)
え！？画面表示しないコンソールアプリケーションでも神フォームクラスが要るんですか！？流石神パネェっす！
- 巨大なユーティリティライブラリ
複数プロジェクトで『再利用』して使用したいコードをまとめた結果、どこに何があるのか分からないライブラリ。
ライブラリ内には同じ、または似ているが違う処理が複数存在し、更にプロジェクトメンバー全員が違う使い方をしている。
「みんなちがってみんないい」かな？ただし使わないという選択は怒られる模様。
オブジェクト指向を採用した場合、『コードがオブジェクト指向で書かれている』事だけを重要視しなければならない。
そうではないコードを書くなら必ず理由が必要であり、理由が説明できないなら間違っているということだ。