C++ オブジェクト指向 クラス間の値

Question

Aクラスの値をBクラスのメソッドで使いたい場合オブジェクト指向でどのように記述すればいいのでしょうか？

具体的に言いますと
win32apiにてウィンドウクラスとボタンクラスを作成しました。
ですがボタンクラスでボタンを作るためにはCreateWindow(...)でウィンドウクラスのハンドルを渡さなければいけません。
この場合どうするのが正解なのでしょうか？
publicで値を渡す、メソッドで渡す、ウィンドウクラス内でボタンクラスを使うなどいろいろ考えられますがどのようにすればいいのでしょうか？
よろしくお願いします。

Answer 1

（残念な方向の）個人的な経験からの意見ですが…

ウィンドウクラス

の中にウィンドウハンドルを完全に閉じ込める（そのクラスの外側ではハンドルの値を参照できない）実装を考えているのだとしたら，
その方針自体を　諦めた方が　楽になります．

• Win32APIでウィンドウに関する何かをしたい場合には，ウィンドウハンドルが必要．
  →「ウィンドウクラス」がハンドル値を独占的に抱えるのだとしたら，

　外部からウィンドウに対して行いたい操作に対応するAPI全てに相当するメソッドを公開するような実装になる．
（単にAPIの引数を１個減らしただけのメソッドが大量に……）
あるAPIに対応するメソッドがこのウィンドウクラスに無い場合，
API関数を使っていればさくっと達成できた事柄が「このクラスを使うせいでできない」とかいう謎の縛りプレイみたくなる．

• 「ウィンドウクラス」がウィンドウハンドル値のgetterみたいなのを公開してしまうとしたら，もはやウィンドウクラスはウィンドウをまともには管理できなくなる．

だって，クラスの外部ではウィンドウに何でもできる（ウィンドウを閉じることだってできる）のだから……
「ウィンドウクラス」とは何だったのか？

• ウィンドウハンドル値のgetterをprotectedにして，このクラスの実装では足りない機能がある場合は，派生クラスで何とかしてね！　という方向も考えられるが…

派生クラスのコードが，ウィンドウクラスから見れば「外部」であることには変わらないので，まぁ，うん……

Comments

[yumetodo]

実際C#などで一般的に使うWPFとかでも普通にWindowハンドル取れますもんね。取れないといろいろ困るし。

Answer 2

Visual Studio (Codeではない方）でC++、Win32 APIを使ったデスクトップウィンドウアプリケーションの開発では、20年以上前からMFC(Microsoft Foundation Class)と言うC++クラスライブラリが利用できるようになっています。多くのウィンドウシステムでもそうだと思いますが、ボタン(Win32で言う"BUTTTON"クラスのコントロール)やテキストボックス(Win32で言う"EDIT"コントロール)などは、ベースとなるウィンドウを拡張したシステムに登録済みのウィンドウです。そのようなものはWindowsでは「コントロール(Control)」と呼びますが、他のOS、プラットフォームではウィジェット(Widget)などと呼ばれることがあるのはご存じのことと思います。MFCの話に戻ると、ウィンドウやボタンなどの各コントロールを表すにあたって、C++のクラスとしておおむね以下のようなかたちになっています。(実際はC++のテンプレートであったり、マクロを多用していたり、かなり複雑です）

// ※完成したコードではありません。例の為の疑似コードとしてみてください。

// 基本のウィンドウ
class CWnd {
public:
// 基本のウィンドウとして持っているべきウィンドウハンドルとかウィンドウスタイルとか座標情報とかのメンバー変数群
// 基本のウィンドウとして持っているべきイベントハンドラ（コールバックなどを用いたメンバー関数群）
    virtual void OnCreateWindow() {}; // WM_CREATEでコールバックされるようなメンバー関数
};

// ボタン
class CButton : public CWnd {
// BUTTONコントロールとして動くための特有のメンバー変数やメンバー関数。
// メンバー関数は必要に応じてベースクラスのものをオーバーライド。
};

// テキストボックス
class CEdit : public CWnd {
public:
// テキストボックス("EDIT"コントロール")として動くための特有のメンバー変数やメンバー関数。
// メンバー関数は必要に応じてベースクラスのものをオーバーライド。
    virtaul void OnCreateWindow() {
        CWnd::OnCreateWindow();
        // TODO: テキストボックス特有の処理を追加
    }
};

ダイアログボックスのようにウィンドウが子コントロールを持つ場合、例えば以下のようなクラス構造になるでしょうか。

// ※完成したコードではありません。例の為の疑似コードとしてみてください。

class CUserDialog : public CWnd {
public:
    CEdit   editValue;    // 値入力
    CButton buttonOK;     // [OK]ボタン
    CButton buttonCancel; // [キャンセル]ボタン
    void OnClickOK() {}   // OKボタン押下時のイベントハンドラを表すメンバー関数
};
// ※実際にはMFCにはCDialogと言うダイアログボックスを表す定義済みのクラスがあります。

MFCや他のプラットフォームのウィンドウクラスライブラリについてネーミングルールなどの差はあるでしょうが、おおむね同じような構造になっているはずです。つまり、そのクラスオブジェクトの関係性を示す上でそれぞれ適切と考えられる値や受け渡し制御のやり方があるのです。と言っても方法について常に唯一無二の「正解」がある訳ではなく、独自のクラスを作るのであればまずは動かすことを優先に、使いたいように使えば良いとも思います。C++/Win32APIでは前述のMFCのほかに、WTL(Windows Template Library)と言うものがあります。クロスプラットフォームではQtが有名です。質問者さんの場合はWin32APIをもとに、オブジェクト指向を意識しつつ（恐らく）勉強を目的として本質問を挙げられたのだと思いますが、こういった既存のフレームワークのソースを覗いてみると分かってくるものがあるはずだと思いますので、読んでみるのもお勧めです。

Comments

[dodox86]

C言語での生Win32APIを使った簡単なウィンドウアプリケーションのソースと、それに相当するMFCのソースを見比べてみると、Win32APIのRegisterClass APIを用いた「ウィンドウクラスの登録」、CreateWindowによる登録済みウインドウクラスのインスタンス化の対比が分かってくると思います。各クラス間の値の受け渡しは、メンバー変数や各種のアクセッサー関数と対比してみると良いです。

[ganjo]

いずれはプロになりたいと思いオブジェクト指向を勉強のため、意識して書いていこうと思い質問させていただきました。
win32apiの中身がどうなっているのか等、自分でもいろいろ試したり、ソースコードを見て今後も精進していこうと思います。
それにオブジェクト指向に気を取られすぎて、作りたいものも作れなければ意味がないですし、何のためにそうするのかよく考えて書いていこうと思います。(当たり前ですが...何でもかんでもクラス化、と見失っていたかもしれません。)
皆様の回答とても参考になりました。
回答をしていただいた皆様ありがとうございました。

[dodox86]

回答中に補足で書くつもりだったのですが、抜けていたので追加でコメントさせていただきます。Win32とC言語でウィンドウアプリを作るのに対比して古くからのC++フレームワークであるMFCなどを挙げましたが、最近はWindowsにおいてC++/MFCでのアプリ作成はどちらかと言うと（否、かなり？）レガシーな扱いになっています。様々な理由で推奨はC# + .NET系、です。それでもウィンドウシステムのAPIをネイティブでC言語/C++で扱え、まぁまぁ手軽に扱えるものとしてWin32を対象にするのはお勧めとはいかないまでも、悪いとは言えないと個人的には思います。勉強目的もあるのであれば、貴重な時間を溶かさずハマらない程度に向き合ってみるのが良いと思います。

[ganjo]

わかりました。
はまらない程度に頑張ってみます。
ありがとうございます。

Answer 3

「お好きに」としか答えようがないかな。

  Window win;
  Button btn = win.createButton(); // Windowに作ってもらう

とか

  Window win;
  Button btn(win); // 作るときにWindowを渡す

とか

  Factory fac;
  Window win = fac.createWindow(); // 作成はすべて
  Button btn = fac.createButton(); // Factoryが行う

とか。