お邪魔します。
現在、DXライブラリで、ウィンドウ内に子ウィンドウもどきを生成することができるような
プログラムを考えています。WINAPIを駆使しなくても、
Window.Draw(x,y);
的な感じで、楽にちょっとしたウィンドウを生成できるようにしたいという目的です。
(もちろん、Windowsのウィンドウそのものが出るわけではない)
ぱっと思いついたのが、管理を一つのオブジェクトですると考えました。(JAVAの様に)
しかし、簡単なものと言えど、ウィンドウは管理する事が多く、メンバ、メソッドともに
どんどん膨れ上がっていきます。
最小限に抑える事が重要ですが、やはり設定面では、ユーザーが細かく設定できるようにしたいです。
となると、最小限のクラスと関数群のほうのがいいのかな?
とも思ってしまいます。(DXライブラリの様に)
クラスにすれば、
・VC++で管理が楽(もともとDXライブラリはWindows環境開発で特化している為)
・コードの可読性が上がる(ここは疑問点。生成・破棄などを考慮して)
など、そこそこ便利にユーザーが使えるのが魅力だと思っていましたが、
一つのオブジェクトに対し非公開関数も含めて、数十種類っというようなクラス設計は
やはり好ましくないのでしょうか?
皆さんだったらどの様に管理していくかお聞きしたいです。
よろしくお願いします。
規模の膨れ上がるクラスについて
Re:規模の膨れ上がるクラスについて
MFCみたいにWINAPIのラッパークラスにしてしまうのが楽だしスッキリしそうな気がします。
必要な機能だけ簡単に使えるように実装しておいて、細かい設定はWINAPI群からアクセスできるようにしておけばよいかと。
必要な機能だけ簡単に使えるように実装しておいて、細かい設定はWINAPI群からアクセスできるようにしておけばよいかと。
Re:規模の膨れ上がるクラスについて
バグさんご回答ありがとうございます。
> WINAPIのラッパークラス
DXライブラリでもダイアログボックスが使えるのですが、
一度に登録できるのは単一だけであるっことや、
DxLib::DrawGraphなどが子ウィンドウ(ダイアログボックス)に使えない
などが理由で、現在自分が作ろうとしているものはWINAPIを一切使わない
っという前提となってます。。
もちろん、この子ウィンドウはメインウィンドウの描画領域内
しか移動できませんし、タスクバーも登場しません。
(メインウィンドウにタスクバーをつけるかもしれない)
言葉足らずで申し訳ありませんでした。
> WINAPIのラッパークラス
DXライブラリでもダイアログボックスが使えるのですが、
一度に登録できるのは単一だけであるっことや、
DxLib::DrawGraphなどが子ウィンドウ(ダイアログボックス)に使えない
などが理由で、現在自分が作ろうとしているものはWINAPIを一切使わない
っという前提となってます。。
もちろん、この子ウィンドウはメインウィンドウの描画領域内
しか移動できませんし、タスクバーも登場しません。
(メインウィンドウにタスクバーをつけるかもしれない)
言葉足らずで申し訳ありませんでした。
Re:規模の膨れ上がるクラスについて
>など、そこそこ便利にユーザーが使えるのが魅力だと思っていましたが、
>一つのオブジェクトに対し非公開関数も含めて、数十種類っというようなクラス設計は
>やはり好ましくないのでしょうか?
MFCだと平気でありますけどね。
今のメソッド・インターフェイスを見せてもらえるとコメント出来るかもしれません。
>一つのオブジェクトに対し非公開関数も含めて、数十種類っというようなクラス設計は
>やはり好ましくないのでしょうか?
MFCだと平気でありますけどね。
今のメソッド・インターフェイスを見せてもらえるとコメント出来るかもしれません。
Re:規模の膨れ上がるクラスについて
kazuoniさんのレベルが分からないのですが、オブジェクト指向、
特に継承とポリモーフィズムを使いこなせているでしょうか?
トータルで関数が数十あっても、きちんと階層別に定義されていて、
インスタンスを適切なクラスで作成するならば、管理はそれほど煩雑ではありません。
もしも現在の子ウィンドウクラスが、単一のクラスであり、
そのインスタンスが使う可能性のある関数を全て持っているのならば、
構造を変えたほうが良いと思います。
# 人クラスが、食べる・寝る・プログラムを書く・運転する・ゲームをする
# の全ての関数を持つのではなく、プログラマ・ドライバ・ゲーマークラスを派生させることで、
# 関数と変数を管理しやすくなります。ということ。
# ものの本には必ずこのような例が書いてますが、自分の問題を解決しないと
# なかなか自分のものにはなりません。この機会に整理されてはいかがかと。
特に継承とポリモーフィズムを使いこなせているでしょうか?
トータルで関数が数十あっても、きちんと階層別に定義されていて、
インスタンスを適切なクラスで作成するならば、管理はそれほど煩雑ではありません。
もしも現在の子ウィンドウクラスが、単一のクラスであり、
そのインスタンスが使う可能性のある関数を全て持っているのならば、
構造を変えたほうが良いと思います。
# 人クラスが、食べる・寝る・プログラムを書く・運転する・ゲームをする
# の全ての関数を持つのではなく、プログラマ・ドライバ・ゲーマークラスを派生させることで、
# 関数と変数を管理しやすくなります。ということ。
# ものの本には必ずこのような例が書いてますが、自分の問題を解決しないと
# なかなか自分のものにはなりません。この機会に整理されてはいかがかと。
Re:規模の膨れ上がるクラスについて
デコレータパターンで追加していくようにしていく方法もあります
#include <stdio.h> //------------------------------------------ class Interface { public: virtual void Draw() = 0; }; //------------------------------------------ class CLine : public Interface { public: void Draw(); }; //------------------------------------------ class CDialog : public Interface { public: void Draw(); }; //------------------------------------------ class CWindow { Interface* p_line; Interface* p_dialog; public: void Init(); void Release(); void Draw(); }; //------------------------------------------ // ウィンドウの処理 void CWindow::Init() { p_line = new CLine; p_dialog = new CDialog; } void CWindow::Release() { delete p_line; delete p_dialog; } void CWindow::Draw() { p_line->Draw(); p_dialog->Draw(); } //------------------------------------------ // ラインの処理 void CLine::Draw() { printf( "線を引く\n" ); } //------------------------------------------ // ダイアログの処理 void CDialog::Draw() { printf( "ダイアログボックスを描く\n" ); } int main() { CWindow window; window.Init(); window.Draw(); window.Release(); return 0; }
Re:規模の膨れ上がるクラスについて
ご回答ありがとうございます!
>softyaさん
> 今のメソッド・インターフェイスを見せてもらえるとコメント出来るかもしれません。
申し訳ありません。。さほど、時間もなく、まだ実装の段階には至ってません。。
完成しだい、また質問させていただきます。(添削も含めて)
> たいちうさん
> 特に継承とポリモーフィズム
一度自分で学習はしましたが、能力レベルとしてはかなり低いと思われます。
> 自分の問題を解決しないと
> なかなか自分のものにはなりません。この機会に整理されてはいかがかと。
そうなんです。実際に実装しないとまったくもって身についていないんです。
見直そうとしても、(基本的にはデザインパターンになってしまうのですが)
最終的に「読むだけ」で終わってしまい、
さてやろうとすると「何からすれば・・・?」みたいな状態に戻ってしまんですね。。
プログラミングに割く時間が少ないとはいえ、基礎をすっ飛ばして高望みしている状態ので、
もう少し、努力してみます。
(こういう時に、ここで回答している皆様のソースコードを解析するのが一番良い気がします。)
> デコレータパターン
デコレータパターンを採用するかは分からないですけど、
参考にさせていただきます。
ソースまで書いていただき、真にありがとうございます。
単一クラスで管理する気はなかったですけど、うまく階層化は出来ていないと
明らかに分かるので、もう少し自分で考えてみます。
修正が必要な事が分かっただけでも大きな収穫となりました。
ご回答していただきありがとうございました。
実装できたら、再度相談させていただきます。
次回もよろしくお願いします。
>softyaさん
> 今のメソッド・インターフェイスを見せてもらえるとコメント出来るかもしれません。
申し訳ありません。。さほど、時間もなく、まだ実装の段階には至ってません。。
完成しだい、また質問させていただきます。(添削も含めて)
> たいちうさん
> 特に継承とポリモーフィズム
一度自分で学習はしましたが、能力レベルとしてはかなり低いと思われます。
> 自分の問題を解決しないと
> なかなか自分のものにはなりません。この機会に整理されてはいかがかと。
そうなんです。実際に実装しないとまったくもって身についていないんです。
見直そうとしても、(基本的にはデザインパターンになってしまうのですが)
最終的に「読むだけ」で終わってしまい、
さてやろうとすると「何からすれば・・・?」みたいな状態に戻ってしまんですね。。
プログラミングに割く時間が少ないとはいえ、基礎をすっ飛ばして高望みしている状態ので、
もう少し、努力してみます。
(こういう時に、ここで回答している皆様のソースコードを解析するのが一番良い気がします。)
> デコレータパターン
デコレータパターンを採用するかは分からないですけど、
参考にさせていただきます。
ソースまで書いていただき、真にありがとうございます。
単一クラスで管理する気はなかったですけど、うまく階層化は出来ていないと
明らかに分かるので、もう少し自分で考えてみます。
修正が必要な事が分かっただけでも大きな収穫となりました。
ご回答していただきありがとうございました。
実装できたら、再度相談させていただきます。
次回もよろしくお願いします。