初等的エンジニア

私は元初等的エンジニアであり全く通用せず逃げるようにして退職したのだが、実働数年間は一応はプロとして働いておりその足跡を残すのも良いのかなと思ってこの記事を書く。
故に普段の記事とは違って、書いているのは殆ど当たり前の事かもしれないが、一応本質を見抜く力は高いと自負しているのでその観点から。人によっては意外と参考になるのかもしれないし、ならないのかもしれない。

オブジェクト指向

まず今日日しっかりした設計の元何かのシステムを書くとしたら(手続き指向ではなく)オブジェクト指向プログラミングが採用されるのだが、これがプログラミングにおける一つの奥義である。

オブジェクト指向とは何か？

プログラミング上でサッカーをプレイさせることを考えてみよう(※必要ならサッカーのプレイヤーを何か機能を提供する仕組みと見做す事で案外汎用的なモデルになる)。
まず自陣の動きを昔ながらの手続き指向で書くとしたら、if文が乱立して保守不可能なコードになってしまう。つまり、「キックオフ後、仮にAにボールがあるなら、近い人を探し、仮にBが一番近い時にBにパスする。もし仮にBがボールを受け取ったら、仮に一番近い相手のディフェンスが自分以下だったら、ドリブルで抜く。仮にドリブルを止められたら、そして仮に味方プレイヤーが自分以外近くにいなかったら・・・」というようなプログラミングを書かないといけず、これをif文で表すとしたらネストがあまりに深くなり読み通すことはほぼ不可能になる。
これをオブジェクト指向で書く場合にはそれぞれのプレイヤーの動きのみを設計すれば良い。つまりプレイヤーA、B、C・・・それぞれが仮にボールを受け取った後の動きだけを記述することになる。そしてAからBにボールが移ったらAオブジェクトは一旦その使命を終えることになる。ここでボールはスレッドを表しており、誰かがボールを握っている限り処理が続くことは明らかなので、最初に笛を鳴らす事さえ出来れば問題なく処理は続きそうである。

インターフェース

サッカーの例のシステムの構造におけるプレイヤーに対して、一般システムにおける部品とその動作を対応させることで、モデリングとして案外汎用的なのでこのまま続けていこう。
プレイヤーAを設計する際、まずAの動作としてAは一番近いプレイヤーB、C・・・にパスをする必要がある。パスをする動作、パスを受ける動作に対してA、B、Cの違いは本質的では無く、味方プレイヤーであることが本質的である。つまりインターフェースとは直訳で「接合部」という意味だが、AはBを接合部として見るときに、必ずしもBの全てを以てして見ずに味方プレイヤーなるインターフェースを持ったオブジェクトとして見ることが本質的になる(※あえて抽象化し情報を落とす)。こうすることによりAを設計する上では「パスをする」というメソッドを「味方プレイヤーインターフェース」に対してのみ作成すればよい事になる。同じオブジェクトをコンテキストによって様々なインターフェースを持ったオブジェクトとして見ることがITの奥義である。
注意：ここでの文章における「インターフェース」は何らかの個別具体な言語におけるインターフェースを意味していない。なので次にて「インターフェースでそうさせるのは不可能だ」と言うものが出てくるがそれは違う。つまりインターフェースとは単にクラスを意味しているだけかもしれないし、そうでないかもしれない。

ポリモーフィズム

もう少しだけ深めていこう。ここでは簡略的にAも味方プレイヤーインターフェースを持っているとしておこう。
Aは味方プレイヤーインターフェースを持つオブジェクトに対してパスを出す(※ひとつのメソッドが動く)のだが、その際自身の属性や相手の属性によって実動作が異なるようにする事が出来る。つまりインターフェースによってただ一つだけ作られたメソッドは、味方プレイヤーを実現したプレイヤーAの属性値を参考にする事が出来る。少し具体性を上げよう。例えばプログラミング的には、仮に味方プレイヤーは共通的にキック力属性を必ず持つのならば、その属性の所在の本質的位置はある意味で味方プレイヤーAでは無く、味方プレイヤーなるインターフェース部である。故に実現され得るキック力は分からないものの任意の実現値はそれを持っていると思えるので、実現される前に「パスを出す」メソッド(※これも所在はインターフェースであった)に(実現された後に存在するであろう)属性を参照することを盛り込むことが出来るのである。そして実際のキック力により実際のパススピードが変わってくる。
このようにインターフェースに対しただ１つしか設計していないメソッドが実現値によって実動作が変わる動きをすることをポリモーフィズムという。

ドメインモデル欠乏症に注意

サッカーのモデルを見て分かるように、現実のオブジェクト関係のようにプログラミングをすることが出来るのがオブジェクト指向なのであるが、現実のオブジェクト関係と感覚的に乖離する所があり、そこに気を付けないとプログラマ自身が自己矛盾を感じドメインモデル欠乏症という症状に陥ることになる。
今、モデルを超簡単にし、ビルに入室するシステムモデルを考えよう。つまりオブジェクトとしてはドアと管理人のみ存在する関係になる。さてドアを開けるべきはどちらであろうか？実は「ドアを開ける」メソッドを保持すべきなのは実は基本としては「ドア」にすることが好ましいのである。初見ではこの事実は驚きかもしれないが、そういう意味では管理人などいらず、管理ドアにした方が良いのかもしれない。しかし無機物が動作を持つ奇異性を許容することがドメインモデル欠乏症を防ぐ為に(心的ハードルとしてあるものの超えるべき)重要な事になる。つまりオブジェクト指向プログラミングでは基本的にオブジェクトに対してそれを操作する管理者を作る必要は無く、オブジェクト自体が動作しオブジェクトを管理することになる。

コンテキスト、Static

(作成中)コンテキストという概念を中心にStaticの意味合い、それからインナークラスの重要性について書く予定。

デザインパターン、フレームワーク

(作成中)ライブラリとフレームワークの違いとデザインパターン。thisという観点から。

まとめ

色んな事をまとめて書こうと思いましたが、オブジェクト指向のさわりだけでも言いたい事が多く無理でした・・・。
書きたくなったら別記事で他の話題を書きます。とりあえず明日(2024/1/9)からまた仕事なので、今やる事が・・・orz