【C++】【ゲーム開発】依存性逆転の原則～Factory Methodパターン導入

C++でゲーム開発を進めるプロジェクトで、今度はまた別のデザインパターンを導入してみました。

前回はStateパターンでシーンの切り替えを実装してみましたが、今回はFactory Methodパターンを使ってみようと思います。

場面の切り替えではインターフェースを使うと便利だよと前回のエントリーで書きましたが、今回もこのインターフェース(C++では一般的に仮想関数)を使っていきます。

つまるところオブジェクト指向プログラミングにおいて、データを感覚的につかみ取ってそれをコード化するのは常人にはできない事です😥

いきなり詰んだような言い草になってしまいましたが、モダン・プログラミングの至高はあくまでオブジェクト指向プログラミング(OOP)です。

オブジェクト指向がなかった昔はCやCOBOLなど手続き型言語なんて呼ばれていましたが、そんな話ではもう到底扱いきれない膨大なデータやオブジェクト群を取り扱うようになって、時代がOOPを必要とするように変わったのです。
これは意図的ではなく、必然的な事でしょう。

しかしながら、私もOOP的な思考は持っておらず、何が何やらでさっぱりなのが現状ですね😅

そんな中、複雑化する現代のプログラミング技術に対処するべく、デザインパターンが提唱されました。

この中でも知名度が高い存在なのが、Factory Methodパターン(ファクトリーメソッドパターン)です。

これはオブジェクト指向プログラミングにおけるセオリー（というか概念？）である依存性逆転の原則(D.I.P.)を忠実に則った仕組みが採用されていて、実際にはこの仕組みを取り入れて初めてオブジェクト指向の恩恵を受けられる、そんな感じもします。

図解

とりあえず雰囲気、クラス図です。

Product(製品)を作り出すFactory(工場)があって、それを経由してオブジェクトをインスタンス化したりしましょう、といったもの。

これだと分かりづらいですが、ConcreteFactory、ConcreteProductがFactory、Productをそれぞれ継承していますね。

最終的にインスタンス化されるのはProductであって、ConcreteProductではありません。

つまりインスタンスが具象クラスの中で作られているのではなく、抽象クラスで作られている。
言い換えれば抽象クラスに依存している、と考える事ができます。

でもそれって何のため？と疑問にお思いかもしれませんが、プログラミングにおいてインスタンスが単一のソフトウェアなんてまず無いですから、複数のインスタンスが具象クラスの中に大量に敷き詰められていたらどうですか？

覚えておけばいい、というそういう問題ではなく、問題はメンテナンス性です。

これはオブジェクト指向に限らず、プログラミングにおいて重大な問題です。

メンテ効率の悪いプログラムはいずれ削除され、新しいコードに書き直しされる運命にあります。

そんなソースコードにしないためには、メンテナンスが発生しうる箇所を予め抽象クラスなどに引っ張り出しておく必要があります。

今回のデザインパターンはそれが本質です。