神戸電子専門学校ゲームソフト学科の生徒が運営するＧＥＳのブログです。
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
[0回]
デザインパターンとは、GoFと呼ばれる４人の先人達が考え出した、プログラム設計パターンのことです。
プログラムの書き方で、問題に直面することは良くあります。
「この設計どうしようか…」や、「この問題どうすれば直んねん」みたいに…。
そういった場合、大抵同じ書き方、解決策にたどり着くのですが、それをカタログ化したものがデザインパターンなのです。
ということは、それを使ったほうが先人達のノウハウが詰まっているのですから、いいに決まっていますよね。
ですが、これらはあくまで、Bestではなく、ある一つのBetterな方法である、ということを忘れないでください。
プログラムに正解なんてありません。
自分で悩むに悩むを重ねて、その処理に適切なアルゴリズムが求められます。
デザインパターンはあくまでその答えの一つなだけなのです。
また、デザインパターンには、それぞれ一つ一つに意味が込められています。
オブジェクト指向の時にも言いましたように、クラスには一つ一つ意味があって作っていくものであるので、このデザインパターンに措いてもしっかりとその意味が確立されています。
デザインパターンを学んでいくにあたって、その意味をきちんと理解し、使いどころを間違えないようにしてください。
意味を間違えて使ってしまっては、もともと存在する書き方であるだけに、他人から見ると意味不明なプログラムとなってしまいます。
では、シングルトンとはなにか？からいってみたいと思います。
皆さんはゲームを作っている時に、コレは一つしか必要ないよなぁ、というものに出会ったことはありませんか？
ゲーム製作ではDirectXのデバイスなんかがそうですよね。
シングルトンはそういう時に役立つデザインパターンです。
シングルトンは、『あるクラスについて、インスタンス（実体）が単一であることを保証する』パターンとなっています。
では例に行ってみましょう。
class CSingleton
{
private:
CSingleton(){}; //コンストラクタ
~CSingleton(){}; //デストラクタ
public:
CSingleton* GetInstance()
{
static CSingleton obj;
return &obj;
}
};
となります。
コンストラクタ、デストラクタがprivateにありますよね。
このようにすると、main側でこのクラスを宣言することは出来ません。
なぜかというと、このクラスを生成するときにコンストラクタを通るのですが、privateとなっているので、クラス外からはアクセス出来ないのです。
では、どうやって生成するのか。
外で出来ないならこのクラス内で生成してやればいいんですね。
それが、publicにある、
CSingleton* GetInstance()
{
static CSingleton obj;
return &obj;
}
となります。
static宣言でオブジェクトを生成したならば、このオブジェクトはスコープを抜けても維持されますよね。
GetInstance関数の初回呼び出し時にCSingletonオブジェクトが生成され、初回以降はそのオブジェクトが使いまわされることになるのです。
このようにして、外部から実体は生成できず、また単一しか存在しないクラスを保証したクラスを作ることが出来ます。
ちなみにこのクラスのインスタンスの取得方法ですが、
CSingleteon::GetInstance()
とすることで、使えるようになります。
良く使うクラスでしたら、
#define SINGLETON CSingleteon::GetInstance()
のように、定義して置いたら楽ですよね。
以上でシングルトンパターンの説明は終わりです。
本当は、もっと色々なものを付け足すことによって、最適化を図れるのですが、シングルトンパターン自体はこれが基本となります。
逆に色々つけると、説明がややこしくなるだけかと思い、このようにしました。
また、書き方もこれ以外に存在するのですが、そちらはJava風になってしまうのであえてこちらを紹介しました。
そちらの方を使っている方は、どちらが駄目というものではないので、自分の好みの方を使えばいいのでは、と思います。
最後に。
あまりシングルトンは多用しないことをオススメします。
シングルトンはいつ作られるかも決められませんし（厳密には出来るが、それはこのパターンの意味にそぐわない）、破棄されるのもプログラムが終了した時であるため、両方ともプログラム上で決めることは出来ません。
もし、シングルトンクラスを２つ作り、それらが関連性を持っていた場合、作られる順番、破棄される順番を決めれない為、意にそぐわない結果を招くこととなります。
また、最初にもいいましたが、そのオブジェクトが本当に、インスタンス（実体）が単一であることを保証するべきクラスであるのか、よく吟味してください。
例えば、「プレイヤークラスはプレイヤーは一人のためシングルトンにしよう」というのは安直な考えです。
今は良くても、もし後々マルチプレイ対応にしたときはどうするのか、プレイヤーが実行と同時に作られてしまっても（最後まで破棄しなくても）いいのだろうか、そのクラスは本当に他のクラスと関連性がないのか、
など、様々な問題があると思います。
また、プレイヤークラスをコンポジションしているゲームクラスをシングルトンクラスにしてしまえば、プレイヤークラスも自動的に１つしかないオブジェクトとなり得ますよね。
シングルトンクラスにするものは、本当に大切なクラスや、ゲームのベースとなるクラスぐらいに留めておいてください。
勿論例外はありますが、簡単に作っていいようなクラスではありません。
かといって使うなというわけではないので。
だって、新しいことを知ると使いたくなっちゃいますもんね。
何度も言いますが、しっかりとそのクラスの意味を考えて、しっかりと吟味して使用してください。
以上中原でした。
COMMENT
無題