メシのタネ

めしのたねになるIT情報配信サイト


魔王と行く! / Interface / Polymorphism / Ontology 深淵ガイド

,

  1. Webプログラム
  2. PHP
  3. 魔王と行く! / Interface / Polymorphism / Ontology 深淵ガイド

よく来たな。勇者よ──この書は、お前の“理解”を試すためにある。
構文に意味を与えるとは何か。その契約に己が意志を焼き付けた者だけが、その力を振るう資格を得るのだ。

これは Interface の書。しかし、その扉を開き、語る声は魔王のものだ。――学舎の静寂に轟く咆哮、抽象の深奥より響く宣誓。

構文を追う勇者よ、今こそ“形”の向こう側へ踏み込め。多態 (Polymorphism) の真髄、Ontology の地図、そして Interface = 契約 が孕む世界生成。
目を逸らすな。世界は、コンパイルされるたび書き換わる。

第一試練 ── 構文の石碑 (Interface の契約)

これは契約の礎。我が名を知れ、そして恐れよ、勇者。符号の影で眠る意志を解き放て。ひとたび刻めば、汝の思想は剣となり、戻る道は閉ざされる。

契約は血の印、逃れられぬ誓いだ。

今この瞬間、お前のコードは宇宙に震紋を刻む。
覚悟を定めよ。その一行が、世界を裂く刃となる。
問い: 汝は、どの行に己の意志を刻むのか?

📘 この試練で得られること

  • Interface を“契約”として捉える視点
  • 実装クラスが従うべき行動仕様の明確化
  • 契約不履行がバグを生むメカニズムの体感
interface MythicSorcery {          // 抽象:呪文を放つという契約のみ定義
    public function cast(): void;
}

class LethalExplosion implements MythicSorcery { // 具象:契約を履行する具体的呪文
    public function cast(): void {
        echo 'Target vaporized. Exit confirmed.' . PHP_EOL;
    }
}

解説: MythicSorcery は「cast() を持つ」という 意図 だけを規定する。LethalExplosion はその契約に従い、具体的な爆発ロジックを実装することで多様な呪文を許容する足場を築く。

第二試練 ── 継承の迷宮 (LSP と意図の継承)

継承とは血脈、そして呪い。王家の系譜を辿るたび、真実は薄皮のごとく剥がれ落ちる。誤れば玉座は瓦礫と化し、世界は崩れ去る。

だからこそ慎重に進め、勇者よ。血の滴る階段を踏みしめ、その先に在る“置換可能性”を見極めよ。
LSP を破る者は、王冠を被っても王にはなれぬ。

問い: お前の継承は、王家の名を辱めていないか?

📘 この試練で得られること

  • Liskov Substitution Principle(SOLID5原則: リスコフの置換原則) の実感
  • 意図(契約)と実装の継承の違い
  • 継承設計で起こりうる罠の発見
classDiagram
interface MythicSorcery
class LethalExplosion
class NuclearRequiem
MythicSorcery <|.. LethalExplosion
LethalExplosion <|-- NuclearRequiem

解説: Mermaid 図は 「MythicSorcery → LethalExplosion → NuclearRequiem」 の血統を示す。どの階層でも cast() 契約を毀損しない限り、上位型として扱える――これが LSP。

class NuclearRequiem extends LethalExplosion {
    public function cast(): void {
        echo 'World‑ending chorus initiated.' . PHP_EOL;
    }
}

function execute(MythicSorcery $magic): void {
    $magic->cast();            // 期待どおり安全に呼べる
}

$spell = new NuclearRequiem(); // 下位型を上位型に置換
execute($spell);               // 問題なく動作

コード補足: executeMythicSorcery という抽象にしか依存しないため、LethalExplosion でも NuclearRequiem でも安全に置換できる。これが Substitution が守られている状態であり、契約を破らない継承の基本形だ。

第三試練 ── 具象の影を斬れ (Dependency Inversion)

「刀を抜き、影を斬れ。具象という錆を払い、抽象の輝きを露わにせよ。依存の鎖を断ち切るたび、汝の設計は星を航る帆となる。
世界を反転させる魔術を恐れるな。深淵の果てでこそ、真理は光る。
問い: その依存、逆転させる覚悟はあるか?

📘 この試練で得られること

  • DIP (依存性逆転) のコアアイデア
  • 実務フレームワークにおける Interface 注入パターン
  • 抽象を起点にしたテスト容易性
interface Weapon {
    public function swing(): Damage; // 契約だけ
}

class Sword implements Weapon {
    public function swing(): Damage { return new Damage(50, 'slash'); }
}

class Warrior {
    public function __construct(private Weapon $weapon) {}
    public function attack(): Damage { return $this->weapon->swing(); }
}

解説: Weapon が変わっても Warrior は変わらない。抽象レイヤが未来の武器(Bow, LaserGun)を受け入れる余白を作る。

第四試練 ── オントロジーの祭壇 (DDD と Repository Pattern)

祭壇に降り立て。存在を記す石板に、汝のドメインを刻め。ここでは嘘も偶然も許されぬ。
法(ロゴス)を書き間違えれば、神々は階を降りてその愚かさを嘲笑うだろう。
深淵を覗き返す覚悟で、公理を彫り込め。
問い: お前のドメインは、不変の真理を抱いているか?

📘 この試練で得られること

  • Interface が永続層を抽象化する意義
  • ドメインとインフラの分離方法
  • 公理 (ルール) をコードに刻む設計の勘所
役割Interface が担う象徴
Domain Serviceルール (Should)公理 (Truth Axiom)
Repository永続 (Is)存在を追跡する門
Applicationシナリオ (Do)意図のオーケストレーション
interface SpellRepository {                   // 呪文と記憶の媒介 — 永続と再召喚の契約
    public function seal(Spell $spell): Sigil;      // 呪文を封印し、印を返す
    public function recall(Sigil $sigil): ?Spell;   // 封印された呪文を呼び戻す
}

class DoctrineSpellRepository implements SpellRepository {
    public function seal(Spell $spell): Sigil {
        // 呪文の本質から封印を生成し、記憶の地層へと埋め込む
        $inscription = $spell->inscription(); // ← uuidの詩的ラッパー
        $this->memoryGate->persist($spell);
        return new Sigil($inscription);
    }

    public function recall(Sigil $sigil): ?Spell {
        // 封印の刻印から記憶の中の呪文を解き放つ
        return $this->memoryGate->find(Spell::class, $sigil->inscription());
    }
}

解説: SpellRepository があれば、RDB でも EventStore でも CosmosDB でも実装可能。ドメインは“呪文が永続できる”という事実だけを信仰すればよい。

第五試練 ── 多態の竜を飼いならせ (Polymorphism)

竜を恐れるな。その炎こそ多態の祝福。律を守る者には翼を、背く者には骨を焼く灼熱を授ける。
竜を従える鍵は 共通の契約。余計な鎖を付ければ群れは暴走し、空は灰に染まる。
飼いならし、群れを率いよ。世界を旋回させる手綱は今、汝の掌にある。
問い: 契約一つで多元宇宙を制御できると、証明してみせるか?

📘 この試練で得られること

  • Polymorphism のランタイム分岐を体感
  • Interface に共通契約を載せるコツ
  • 型を超えた振る舞い拡張の実務イメージ
interface MythicSpell {             // Interface 的役割
    public function cast(): void;
}

class CataclysmicMeteor implements MythicSpell { // 具象1
    public function cast(): void {
        echo "☄️  Armageddon ignites: A meteor sunders the skies!" . PHP_EOL;
    }
}

class EternityRewind implements MythicSpell {     // 具象2
    public function cast(): void {
        echo "⏳  Chronos bends: Reality rewinds twelve heartbeats." . PHP_EOL;
    }
}

function macro(MythicSpell $spell): void {        // 契約に従って実行
    $spell->cast();
}

// 使用例 — 竜を呼び寄せるほどの呪文たち
$ultima = new CataclysmicMeteor();
$reset  = new EternityRewind();

macro($ultima); // 多態とは、異なる実装が同一の契約に応答すること
macro($reset);  // 共通の契約により型を意識せず振る舞いを切り替える

macro(Spell) は Spell を受け取るだけで具体型を意識しない。契約が統一 API を保証するのだ。

解説: SpellRepository があれば、RDB でも EventStore でも CosmosDB でも実装可能。ドメインは呪文が永続できるという事実だけを信仰すればよい。

終章 ── 魔王の玉座で振り返る五つの石碑

  1. Interface = 契約 — 存在の輪郭を決める術。
  2. Ontology = 意味の地図 — 抽象を扱う者は世界像を表明する義務がある。
  3. Polymorphism = 現象の多重写像 — 契約の上で展開する多元宇宙を恐れるな。
  4. 設計とは意図の編集 — コードは記号列ではなく宣誓。

最後の言葉
Interface を定義するたび、汝は新たな宇宙を生成する。
オントロジーを意識せよ。そこに“魔王”すら跪く論理的必然がある。

参考文献

  • Robert C. MartinCLEAN Code (Prentice Hall, 2008)… SOLID 原則と依存性逆転の実践的バイブル。
  • Robert C. MartinAgile Software Development, Principles, Patterns, and Practices (Prentice‑Hall, 2002)… Interface 抽象化と設計原則の長編教典。
  • Evans, E. & Vernon, V.Domain‑Driven Design Distilled (Addison‑Wesley, 2016)… 祭壇パートを短時間で補強したい勇者向けの新書。
  • Bloch, J.Effective Java (Addison‑Wesley, 3rd ed., 2018)… 言語は異なれど、不変条件と API 設計の神髄を学べる湧水のような一冊。


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

This site uses Akismet to reduce spam. Learn how your comment data is processed.

若い頃、「仕事中にハマったこと」や「誰かに共有したい技術的な気づき」をアウトプットしたくてブログを始めましたが、勢い任せでよく分からない記事を大量生産し、あえなく飽きて終了。

改めて今、キャリア15年分の経験や知識が、これからITエンジニアを目指す方や、同じような課題で悩んでいる現役エンジニアの「メシのタネ」になるような記事を残したいと思っています。
※過去の記事は見ると精神が崩壊するため、そっとしておいてください。

🛠 経歴という名の珍道中:
文系Fラン → 広告営業 → Web営業 → 通信営業 → Web進行 → 出版 → Web媒体運用 → ソフトウェアハウス → SES → フリーランス

専門教育も受けず、転職歴も多数。履歴書はまるで時系列の事故記録のようですが、試行錯誤を重ね、なんとかエンジニアとして食べています。

このブログでは、そんな「履歴書クラッシャー型エンジニア」が送る、
名古屋一敷居の低い、実務に役立つ技術ブログを目指します。

PHP
魔王と行く! / Interface / Polymorphism / Ontology 深淵ガイドNew!!
Laravel
Laravel 12、「コード 1 行も書き換えず未来へ」──静かな革命の手順書New!!
Laravel
LaravelのMiddlewareって意味あるの?仕組み・使いどころ・やらかしまで整理してみたNew!!
Laravel
ServiceProviderって何してるの?DIの背後で動いてるやつの正体New!!
Laravel
LaravelのサービスコンテナとDI、「書いてるだけで動く」コードの正体New!!
Laravel
Laravelのアーキテクチャ、実は誰もわかってない説