SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

イベントレポート

現在地からオブジェクト指向プログラミングを捉えなおす、リ・オリエンテーション【OCC2024基調講演レポート】

  • X ポスト
  • このエントリーをはてなブックマークに追加

オブジェクト指向プログラミングの5段階

 続いて、オブジェクト指向プログラミングを適切に捉えるために、羽生田氏はOOPの5段階を以下のように示した。

OOPの段階論
OOPの段階論

 第1段階はAlan Kayが提唱した「オブジェクト指向ミニマム」だ。「1個1個のオブジェクトを一種のオートマトンとみなし、オブジェクト同士は、イベントないしはメッセージを介して相互作用する」という考え方だ。これはモダンなチューリングマシンという見方もできる。

 第2段階は責務の観点を取り入れて、高凝集度やSRP(Single Responsibility Principle)の原則が関わってくる。「責務(リスポンシビリティ)をオブジェクトに割り当てて、役割を果たさせましょう」と羽生田氏。責務は英語で“Responsibility”であり、Response(応答)するAbility(能力)を意味する。つまり、オブジェクトは外から飛んできたメッセージに対して反応して、責任を果たさなければいけない。これがSRPの肝にある考え方だ。

 第3段階は、教科書的にもよく言われている「クラス」「継承」「ポリモルフィズム」の3要素だ。ただし羽生田氏は「これは単なる形式的な表層の定義に過ぎません」と警鐘を鳴らす。「クラスを宣言したからといって抽象データ型とは言えない。『業務との対応など考えずにとりあえず処理をメソッドとして並べておけばいい、そして必要に応じてデータは勝手にgetter/setterで出し入れすればいい』といった幼稚な考え方はやめてください。これではカプセル化の意味がないです。ということで、第3段階は早く通過しましょう」と強調した。

 第4段階は、構造主義的なオブジェクト指向で、SOLID原則を守ることである。第4段階に到達するために前提となるのが「契約による設計(Design By Contract、DbC)」の考え方だ。DbCは、クライアントオブジェクトとサプライヤ、それぞれのオブジェクト同士がメッセージをやり取りするときの取り決めだ。「もし、私が宣言した事前条件を満足する形でクライアントオブジェクトがメッセージを送ってくれたなら、私は事後条件を満たした形でお返しします」という約束事である。リスコフの置換原則においては、スーパークラスで定義されたメソッドを守って答えるために、サブクラスのメソッドも、それと同じ事前条件と事後条件を満たす必要がある。

 「これに反するようなオーバーライドをしてしまったら、それはもうサブタイピングとしての契約を守った継承ではない。継承はいくらでもできますが、サブタイピングの意味でスーパークラスに対してサブクラスを宣言したことにはなりません。継承というのはサブタイピングという強い型付けを意識して使うのがいいと思います」

 また、第4段階では開放閉鎖原則(OCP、Open Closed Principle)を守っていることも重要となる。OCPにおいては、利用側のクラスに対してサプライヤ側はカプセル化されている必要がある。これは「インターフェースがクライアント側にちゃんと理解されていて、それを守った形でメッセージを送ってもらえる状態」だ。一方で実装側はオープンになっているので、リスコフの置換原則を守っている限り、サブクラスを追加して抽象クラスの実装を発展させることができる。「Open for ExtensionとClosed for Use」の考え方だ。

 ちなみに、クラス設計の原則を「SOLID」で覚えるのはよいが、「順番がよくない」と羽生田氏は言う。

 「凝集度に関する原則がSRPで、クラス同士の結合度を下げる観点がDIP(依存性逆転の原則)とISP(インターフェース分離の原則)。両方に関連しているのが、OCPとLSPといったように、きちんと設計上の意味にもとづいてカテゴリを捉え直した方がいい。SOLID原則を理解しようとする人は、凝集度と結合度を組み合わせて理解を進めてください」

 加えて羽生田氏は、DIPの重要性も強調した。この原理を貫徹するためにDDDのさまざまなアーキテクチャパターンがあると言える。「DDDは難しすぎて、もっとシンプルにしないと一般には普及しないと思うが、その手始めはDIP」と羽生田氏。

 手続き型のスタイルでは、メインのルーティンからサブルーチンを呼び出す形でしか構造化ができない。しかしオブジェクト指向の原則では、抽象に対して具体的なクラス名にモジュールが依存する。そして「抽象的なモジュールは他のどこのモジュールにも依存しない」という考え方に基づくのがオブジェクト指向であり、DDDのアーキテクチャにも通じているのだ。

 ここまでの第4段階を理解して初めて、第5段階のドメイン駆動設計(DDD)の導入に至る。レイヤー化やモジュール同士の依存関係について扱うことができるのだ。羽生田氏は「DDDは第4段階を通過してから始めるので十分。まずはオブジェクト指向のSOLID原則を理解しましょう」と強調した。

次のページ
モデリングの5段階

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
イベントレポート連載記事一覧

もっと読む

この記事の著者

岡田 果子(オカダ カコ)

 IT系編集者、ライター。趣味・実用書の編集を経てWebメディアへ。その後キャリアインタビューなどのライティング業務を開始。執筆可能ジャンルは、開発手法・組織、プロダクト作り、教育ICT、その他ビジネス。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

大河原 由貴(編集部)(オオガワラ ユキ)

 2023年に新卒で翔泳社へ入社し、CodeZine編集部に配属。筑波大学生命環境学群生物学類卒。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/19450 2024/06/11 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング