画像管理クラスを作っているのですが

[敷布団]

オブジェクト指向になれるために、画像周りの情報を包含したクラスを作ってみたのですが、
オブジェクト指向についてまだあまり理解できていないためそのままの使用に違和感を覚えます。

DxLibを使用して、LoadGraphなどを使い、メンバにロード、描画、画像開放をまとめたクラスです。
LoadDivGraphによる分割読み込みに対応させるため、可変配列を使用してます。
分割しない場合は[0]にのみハンドルが格納されます。

コード:

// Graphic.h
class Graphic
{
private:
	bool	isopen_;
	bool	isdiv_;
	std::vector<int> handle_;
	char*	filename_;
	size_t	filesize_;

	Graphic(const Graphic&){}

public:
	Graphic(void);
	Graphic(char* filename);
	~Graphic(void);

	/**
	 * ファイルを開いているかどうか
	 * @retval true.開いている false.開いていない
	 */
	const bool GetIsOpen()const
	{
		return isopen_;
	}

	/**
	 * ファイルサイズを返す
	 */
	const size_t GetFileSize()const
	{
		return filesize_;
	}

	/**
	 * ファイルパスの設定
	 * @retval 1.成功 0.失敗
	 */
	int SetPath(char* filename);

	/**
	 * ファイルパスから画像をオープン
	 * @retval 1.成功 0.失敗 -1.画像がすでにオープンされています
	 */
	int Open(void);
	int Open(int xnum,int ynum,int xsize,int ysize);

	/**
	 * 画像をクローズ
	 * @retval 1.成功 0.失敗 -1.画像が既にクローズされています
	 */
	int Close(void);

	/**
	 * 画像を描画
	 * @retval 1.成功 0.失敗 -1.画像がオープンされていません
	 */
	int Show(int x,int y,int num = 0);
	int Show(int x,int y,double exrate,int num = 0);
};

そこで考えたのですが、このクラスを使用してシーンクラスを作るとき、
おそらくこのインスタンスを複数利用すると思います。

もしクラス形式でメンバにする場合、おそらく以下の様な書き方になると思います。

コード:

// Initでオブジェクトを作る
CGraphic* actor;
CGraphic* enemy[]; // 仮


// Draw
actor.Show( pos_x, pos_y );

...
for(int i=0; ...)
{
	enemy[i].Show(...);
}

少しイメージと違うのですが敵をまとめて描画するときはこんなかんじになるかと。

ですが私的には、できれば画像情報を構造体で管理したいと思っています。
ロード関数等を含んだクラスをシングルトンとして、ヘッダーincludeすればどこでも使えるように
すれば、おそらく見栄えも良く、適切だと感じます。

そこでみなさんに意見を伺いたく思い、投稿しました。
クラスで管理した場合と、構造体とシングルトンな関数で管理する場合、
また、その他最適な方法があるかもしれませんが、
どちらが管理方法として良いか、またそれは何故かを聞かせてください。

[softya（ソフト屋)]

すいません説明がよくわからないです。
ただ、構造体で管理だとカプセル化は何処へ行っただろうとか？
構造体とクラスの何が違うと思っておられますか？
が気になります。

あとコンストラクタとデストラクタを使ったほうが良いと思います。

【追記】
>ですが私的には、できれば画像情報を構造体で管理したいと思っています。
>ロード関数等を含んだクラスをシングルトンとして、ヘッダーincludeすればどこでも使えるように
>すれば、おそらく見栄えも良く、適切だと感じます。

Ｃ言語の構造化モジュールで組むのと変わらないと思います。

[敷布団]

すいません説明がよくわからないです。

すいません、だんだん日本語がなるのは癖でした、申し訳ないです。

例を挙げると、Cでいう fopenなどはFILE構造体を使っていろいろやりくりしていること。
C++でいう fstreamなどは、ストリーム自体をオブジェクト化してファイルをやりくりしています。
考え直すと、スタイルの好き嫌いでしたね...ごめんなさい。

ただ、構造体で管理だとカプセル化は何処へ行っただろうとか？
構造体とクラスの何が違うと思っておられますか？

クラスはコンパイル後には構造体と同じコードに書き換えられるということは知っています。
また、クラスはアクセス制御ができ、継承、仮想関数などを使用出来るという点が違うと思います。

カプセル化については、今のところ考えていません。

あとコンストラクタとデストラクタを使ったほうが良いと思います。

コンストラクタでは要素の確保、デストラクタでは自動開放をしてます。

構造体管理もストリーム形式の管理も、良し悪しはあると思いますが、
もう一度考えなおして、自分のスタイルでやって行きたいと思います。
ありがとうございました、自己解決とします。

[nil]

例を挙げると、Cでいう fopenなどはFILE構造体を使っていろいろやりくりしていること。
C++でいう fstreamなどは、ストリーム自体をオブジェクト化してファイルをやりくりしています。
考え直すと、スタイルの好き嫌いでしたね...ごめんなさい。

スタイルの好き嫌い、とか言う問題ではなく、
fopenの場合、fcloseを呼ばなければファイルを閉じられませんが、
fstreamならばデストラクタが呼ばれれば確実にファイルは閉じられます。
つまり、安全性の問題では？

カプセル化については、今のところ考えていません。

カプセル化こそオブジェクト指向の真価を発揮するところでは？

コンストラクタでは要素の確保、デストラクタでは自動開放をしてます。

softyaさんの仰りたいことは、
Open,Close関数は使用せずに、コンストラクタで画像のロードと要素の確保、
デストラクタで画像の破棄と要素の解放を行うべきでは？
ということではないでしょうか。

また、ファイル名は与えられているが、画像はロードされていない、という半端なオブジェクトが発生することも防げます。

コンストラクタからは引数を返せないではないか？　エラーが発生したかわからないのではないか？
と考えることがあるかもしれませんが、そういう時は例外について調べて見ることをおすすめします。

あと、ふと気になったのですが、

コード:

void hoge( Graphic graphic );	// 関数宣言
Graphic* pGraphic = nullptr;	// ここではグローバル変数とする

void func(){
	pGraphic = new Graphic;	//	インスタンスの生成

	hoge( *pGraphic );		//	こんなコード
	Graphic g = *pGraphic;	//	またはこんなコード
}

例えばこんな処理の場合、
hoge( *pGraphic );やGraphic g = *pGraphic;のようなコードを書いてしまった時、
Graphicクラスのコピーコンストラクタが呼ばれ、また、変数のスコープを抜ける時にはデストラクタが呼ばれます。
デストラクタで解放処理が行われた場合、pGraphicの中身は空っぽになってしまうのでは？

※これの解決方法はコピーコンストラクタ、また、代入演算子をprivateにする、
また、shared_ptrを使う、などがあります。

[softya（ソフト屋)]

ほとんど涼雅さんが書いてくれていますが、オブジェクト指向を勉強したいとの事でしたのでオブジェクト指向らしくないところを指摘させていただきました。
カプセル化をしないのであればオブジェクト指向におけるオブジェクト化という目的から逸脱していると思いますので、それはサブルーチンをまとめた物でしかありません。
ご自分のスタンスも大事でしょうが、オブジェクト指向の趣旨をもう一度見返していただくと良いかと思います。