クラス間の変数のやり取りについて
クラス間の変数のやり取りについて
質問を修正したので、No.8(88503)を参照してください。
例えば、下記の図のクラス構造を考えます。
図で、保持と言うのはインスタンスの保持です。
クラスA←←←
↑ ↑
↑保持 ↑保持
↑ ↑
クラスB クラスC
↑
↑保持
↑
クラスD
クラスBとクラスC間のメンバ変数のやり取りは、クラスAが両方のインスタンスを保持しているので、簡単に行えると思います。
では、例えばクラスBとクラスD間の様な遠い距離にあるクラス間のメンバ変数のやり取りは、どの様な方法が最適なのでしょうか。
例えば、クラスBのメンバ変数をクラスDに渡す場合、
1.クラスBで対象のメンバ変数をシングルトンクラスに渡す。
2.クラスDでシングルトンクラスから受け取る。
とすれば可能ですが、オブジェクト指向プログラミング的で無い感じ?がします。
シングルトンクラスは、例えば、ゲームのキーボード処理、画像ハンドル受け渡し処理等、どこからでも呼び出せないと困る処理のみ使用すべきであり、単にメンバ変数のやり取りに使うべきでないと思いました。
同じくクラスBのメンバ変数をクラスDに渡す場合、別の方法として、
1.クラスAがクラスBのメンバ変数を受け取る。
2.クラスAがクラスCにそのメンバ変数を渡す。
3.クラスCがクラスDにそのメンバ変数を渡す。
この様にバケツリレーの様な感じで可能ですが、クラスA、Cがそのクラス自体に関係の無い処理を含む事になり、適切なクラス設計でないと思います。
例えば、下記の図のクラス構造を考えます。
図で、保持と言うのはインスタンスの保持です。
クラスA←←←
↑ ↑
↑保持 ↑保持
↑ ↑
クラスB クラスC
↑
↑保持
↑
クラスD
クラスBとクラスC間のメンバ変数のやり取りは、クラスAが両方のインスタンスを保持しているので、簡単に行えると思います。
では、例えばクラスBとクラスD間の様な遠い距離にあるクラス間のメンバ変数のやり取りは、どの様な方法が最適なのでしょうか。
例えば、クラスBのメンバ変数をクラスDに渡す場合、
1.クラスBで対象のメンバ変数をシングルトンクラスに渡す。
2.クラスDでシングルトンクラスから受け取る。
とすれば可能ですが、オブジェクト指向プログラミング的で無い感じ?がします。
シングルトンクラスは、例えば、ゲームのキーボード処理、画像ハンドル受け渡し処理等、どこからでも呼び出せないと困る処理のみ使用すべきであり、単にメンバ変数のやり取りに使うべきでないと思いました。
同じくクラスBのメンバ変数をクラスDに渡す場合、別の方法として、
1.クラスAがクラスBのメンバ変数を受け取る。
2.クラスAがクラスCにそのメンバ変数を渡す。
3.クラスCがクラスDにそのメンバ変数を渡す。
この様にバケツリレーの様な感じで可能ですが、クラスA、Cがそのクラス自体に関係の無い処理を含む事になり、適切なクラス設計でないと思います。
最後に編集したユーザー Fimbul on 2012年7月06日(金) 09:59 [ 編集 2 回目 ]
Re: クラス間の変数のやり取りについて
まず、「保持」について確認ですが
> クラスAが両方のインスタンスを保持しているので
ということは、BとCがAに包含されているという解釈で良いのでしょうか?
それともインターフェイスを保持しているのでしょうか?
まあそれはそれとして、Bのメンバ変数をDに渡す方法がいくらでもあるのはわかると思います。
そのうちどうやって渡すのが良いかというのはケースバイケースだと思います。
ただ、オブジェクト指向的にやるとして一般的なの方法はBのインターフェイスをDに渡す方法ではないでしょうか。
渡したい変数がint型targetという仮定で例えのコードを描くなら、
とし、A経由なりC経由なりで一回InterfaceB*型に格納したBのポインタをDに渡せば良いのではないでしょうか。Dはメンバ変数なりで保持すれば良いと思います。
> クラスA、Cがそのクラス自体に関係の無い処理を含む事になり
もし変数を直接バケツリレーするならそうでしょうね。
ただ先程のようにBのインターフェイスをコンストラクタなりで渡してしまえばそれでオッケーです。
> クラスAが両方のインスタンスを保持しているので
ということは、BとCがAに包含されているという解釈で良いのでしょうか?
それともインターフェイスを保持しているのでしょうか?
まあそれはそれとして、Bのメンバ変数をDに渡す方法がいくらでもあるのはわかると思います。
そのうちどうやって渡すのが良いかというのはケースバイケースだと思います。
ただ、オブジェクト指向的にやるとして一般的なの方法はBのインターフェイスをDに渡す方法ではないでしょうか。
渡したい変数がint型targetという仮定で例えのコードを描くなら、
class InterfaceB
{
public:
virtual int getHensuu() const = 0;
};
class B
:public InterfaceB
{
//例えなのでいろいろ省略します
int target;
public:
int getHensuua() const{ return this->target; }
};
> クラスA、Cがそのクラス自体に関係の無い処理を含む事になり
もし変数を直接バケツリレーするならそうでしょうね。
ただ先程のようにBのインターフェイスをコンストラクタなりで渡してしまえばそれでオッケーです。
✜ で C ご ✜
: す + 注 :
¦ か + 文 ¦
: ? Is the は :
✜ order C++? ✜
: す + 注 :
¦ か + 文 ¦
: ? Is the は :
✜ order C++? ✜
糸冬
――――――――
制作・著作 NHK
――――――――
制作・著作 NHK
Re: クラス間の変数のやり取りについて
はい、継承ではなく包含です。新月獅子 さんが書きました: ということは、BとCがAに包含されているという解釈で良いのでしょうか?
インターフェイスで渡せば、インターフェイスのメンバ関数しか呼べないので、余計な情報を公開する事は無く、隠蔽出来ていると言えると思います。新月獅子 さんが書きました: ただ、オブジェクト指向的にやるとして一般的なの方法はBのインターフェイスをDに渡す方法ではないでしょうか。
ですが、コンストラクタ経由で渡しても、クラス間の距離が今回よりも遠い場合は、リレーが長くなって結局汚いコードになってしまうと思います。
インターフェイスをシングルトンクラスに渡せば、どこからでもそのインターフェイスにアクセス出来ますが、必要なインターフェイスを全てシングルトンクラスに押し込める構造になり、良くない設計になってしまいます。
Re: クラス間の変数のやり取りについて
今回のAやBなどの抽象的な例えで、それらがどういう目的や関係性なのか、Bのメンバ変数がどういう目的、範囲で使用されるかもわからないのですから、こちらは一案を提示するしか無いわけですが。
> ですが、コンストラクタ経由で渡しても、クラス間の距離が今回よりも遠い場合は、リレーが長くなって結局汚いコードになってしまうと思います。
知りません。
リレーが長くなっても、たとえ汚くなっても、それが正しい設計の場合だってあると思います。
BやDそれぞれのクラスの役割や依存の仕方がわからない以上、私にはそれを判断することはできません。
ただ、今回DはBの情報を知りたいわけです。この時、実装はともかくDはBに関係する必要があるわけです。
そのひとつの方法としてコンストラクタリレーを上げましたが、設計的に正しくないと思ったなら他にも方法はあると思います。
例えばBとDの橋渡しとなるクラスを作るとか。
> ですが、コンストラクタ経由で渡しても、クラス間の距離が今回よりも遠い場合は、リレーが長くなって結局汚いコードになってしまうと思います。
知りません。
リレーが長くなっても、たとえ汚くなっても、それが正しい設計の場合だってあると思います。
BやDそれぞれのクラスの役割や依存の仕方がわからない以上、私にはそれを判断することはできません。
ただ、今回DはBの情報を知りたいわけです。この時、実装はともかくDはBに関係する必要があるわけです。
そのひとつの方法としてコンストラクタリレーを上げましたが、設計的に正しくないと思ったなら他にも方法はあると思います。
例えばBとDの橋渡しとなるクラスを作るとか。
オフトピック
これも具体的なクラスの情報がわからないのであんま言えませんが、こんな包含でガッチガチな関係の設計で大丈夫ですか
✜ で C ご ✜
: す + 注 :
¦ か + 文 ¦
: ? Is the は :
✜ order C++? ✜
: す + 注 :
¦ か + 文 ¦
: ? Is the は :
✜ order C++? ✜
糸冬
――――――――
制作・著作 NHK
――――――――
制作・著作 NHK
Re: クラス間の変数のやり取りについて
>クラス間の距離が今回よりも遠い場合は、リレーが長くなって結局汚いコードになってしまうと思います。Fimbul さんが書きました:はい、継承ではなく包含です。新月獅子 さんが書きました: ということは、BとCがAに包含されているという解釈で良いのでしょうか?
インターフェイスで渡せば、インターフェイスのメンバ関数しか呼べないので、余計な情報を公開する事は無く、隠蔽出来ていると言えると思います。新月獅子 さんが書きました: ただ、オブジェクト指向的にやるとして一般的なの方法はBのインターフェイスをDに渡す方法ではないでしょうか。
ですが、コンストラクタ経由で渡しても、クラス間の距離が今回よりも遠い場合は、リレーが長くなって結局汚いコードになってしまうと思います。
インターフェイスをシングルトンクラスに渡せば、どこからでもそのインターフェイスにアクセス出来ますが、必要なインターフェイスを全てシングルトンクラスに押し込める構造になり、良くない設計になってしまいます。
となると、外部変数(シングルトン)で参照しあえば良いのかなと思いますけどね。
後は設計の見直しでしょうか。
クラスD(またはクラスB)でやりたい機能がでかすぎてないか。細分化できないか。
本当に依存しないといけないのか。
など考えます。
ちなみに僕ならこのような設計になってしまって個人で作るなら、シングルトンで管理します。
まぁ、本当に大規模なプログラムを作ったことがないから簡単に言ってますけどね。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: クラス間の変数のやり取りについて
単純にクラスCからクラスDのインスタンスを得てクラスBに渡してはダメなのでしょうか?
なんなら機能制限したクラスEをクラスDの基底クラスにしてクラスEとして渡すという手もありますが。
なんなら機能制限したクラスEをクラスDの基底クラスにしてクラスEとして渡すという手もありますが。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: クラス間の変数のやり取りについて
質問の内容を修正します。
クラスAとクラスBがあり、互いに遠い距離にあるとします。
これらのクラス間で各々のメンバ変数をやり取りする場合、どのような方法が最適なのでしょうか。
そもそも遠い距離にあるクラス間に関係がある設計がおかしいのかも知れませんが、どうしてもそうなってしまったと仮定してください。
補足として私が知っている方法は、
1.Mediator pattern
http://www.geocities.jp/ky_webid/design ... n/020.html
2.Singleton pattern
http://www.geocities.jp/ky_webid/design ... n/009.html
の2つです。
1番目の方法は、サイトを見ても完全に理解出来なかったので、この方法が最適なら詳しく教えてほしいです。
softyaさんにお聞きします。
プロならこうする、と言う方法を可能なら教えてもらいたいです。
クラスAとクラスBがあり、互いに遠い距離にあるとします。
これらのクラス間で各々のメンバ変数をやり取りする場合、どのような方法が最適なのでしょうか。
そもそも遠い距離にあるクラス間に関係がある設計がおかしいのかも知れませんが、どうしてもそうなってしまったと仮定してください。
補足として私が知っている方法は、
1.Mediator pattern
http://www.geocities.jp/ky_webid/design ... n/020.html
2.Singleton pattern
http://www.geocities.jp/ky_webid/design ... n/009.html
の2つです。
1番目の方法は、サイトを見ても完全に理解出来なかったので、この方法が最適なら詳しく教えてほしいです。
softyaさんにお聞きします。
プロならこうする、と言う方法を可能なら教えてもらいたいです。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: クラス間の変数のやり取りについて
デザインパターンで解決できるものでは無い気がします。
私としては、共有する必要性のあるデータを保持する別のクラスを作るが無難な気がします。
※ 仕事でC++を使っていた時にデザインパターンを使うような仕事をしていないので、プロとしてのコメントとしてご期待に添えないかも知れません。
私としては、共有する必要性のあるデータを保持する別のクラスを作るが無難な気がします。
※ 仕事でC++を使っていた時にデザインパターンを使うような仕事をしていないので、プロとしてのコメントとしてご期待に添えないかも知れません。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: クラス間の変数のやり取りについて
何を引き出したいのかわからないけど
「具体的には何もありませんが、”よくある解決法では解決しない(恰好悪いので)”という状況があったとします。
これを解決するための、プロが使うようなカッコイイ最適解はありますか?」
って聞いてるように見える
「具体的には何もありませんが、”よくある解決法では解決しない(恰好悪いので)”という状況があったとします。
これを解決するための、プロが使うようなカッコイイ最適解はありますか?」
って聞いてるように見える
Re: クラス間の変数のやり取りについて
共有するデータを保持するクラスのインスタンスは2つのクラスから参照できて、かつ必要な間ずっと存在してなければならないですよね?softya(ソフト屋) さんが書きました: 共有する必要性のあるデータを保持する別のクラスを作るが無難な気がします。
これをどうやって実現するのでしょうか。
Re: クラス間の変数のやり取りについて
2つのクラスが、それぞれshared_ptrで、共有するデータを保持するクラスのインスタンスへのポインタを保持したら良いのではないでしょうか?Fimbul さんが書きました:共有するデータを保持するクラスのインスタンスは2つのクラスから参照できて、かつ必要な間ずっと存在してなければならないですよね?
これをどうやって実現するのでしょうか。
Re: クラス間の変数のやり取りについて
共有するデータを保持するクラスのインスタンスを、離れた2つのクラスにどの様に渡せばよいのでしょうか。ISLe さんが書きました: 2つのクラスが、それぞれshared_ptrで、共有するデータを保持するクラスのインスタンスへのポインタを保持したら良いのではないでしょうか?
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: クラス間の変数のやり取りについて
mainから最初に渡せば良いのでは。Fimbul さんが書きました:共有するデータを保持するクラスのインスタンスを、離れた2つのクラスにどの様に渡せばよいのでしょうか。ISLe さんが書きました: 2つのクラスが、それぞれshared_ptrで、共有するデータを保持するクラスのインスタンスへのポインタを保持したら良いのではないでしょうか?
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: クラス間の変数のやり取りについて
Abstract Factoryパターンというほどたいそうなものでなくて良いのですが、共有するデータを保持するクラスのインスタンスを引き出す関数とかを用意すれば良いのでは?Fimbul さんが書きました:共有するデータを保持するクラスのインスタンスを、離れた2つのクラスにどの様に渡せばよいのでしょうか。
グローバルにアクセスできてしまうのが気持ち悪いのならば、コンテキストとしてクラス間でリレーするオブジェクトを用意して、そこに含める形になると思います。
Re: クラス間の変数のやり取りについて
すみません。私には理解できませんでした。ISLe さんが書きました: Abstract Factoryパターンというほどたいそうなものでなくて良いのですが、共有するデータを保持するクラスのインスタンスを引き出す関数とかを用意すれば良いのでは?
グローバルにアクセスできてしまうのが気持ち悪いのならば、コンテキストとしてクラス間でリレーするオブジェクトを用意して、そこに含める形になると思います。
「遠い距離にあるクラス間に関係がある設計」は、オブジェクト指向の設計として好ましいものなのでしょうか。
Re: クラス間の変数のやり取りについて
好ましいかどうかは分かりませんが、特にハードウェア絡みだといきなりアクセスする準備ができていない場合があって、コンテキストを介したアクセスをするように設計せざるを得ない場合があります。Fimbul さんが書きました:「遠い距離にあるクラス間に関係がある設計」は、オブジェクト指向の設計として好ましいものなのでしょうか。
使う側からしたら面倒くさいですが、初期化のタイミングを制御できるメリットがあります。
例えば、Win32 APIのDCとか、Java(AWT)のGraphicsとか、AndroidのContextとか。
これらを用意するのはシステム側ですが、システムとアプリケーションの関係はそのままアプリケーション内部の実装に応用できると思います。
古い話ですが、BREWアプリがもろにコンテキストをリレーしないとほとんどのAPIにアクセスできないシステムでした。
なのでコアクラスというかアプリケーションクラスが必ず中心にあってシステムAPIもそのメンバ関数として実装するようにしてました。
Re: クラス間の変数のやり取りについて
好ましいかどうかは状況によるし、どう使うかによっても変わる。そもそも全然好ましくないのなら、デザインパターンとして出てこないのでは?Fimbul さんが書きました:「遠い距離にあるクラス間に関係がある設計」は、オブジェクト指向の設計として好ましいものなのでしょうか。
少なくとも2つのクラスを仲介する専用のクラスを作っとけば、片方の仕様が変わった時は、その片方のクラスと仲介クラスをみればいいのだから、十分じゃないの?
個人的には上の条件が満たせればいいと思っています。
(^^;
written by へにっくす
Re: クラス間の変数のやり取りについて
他の方も返信されてますように好ましいかはその時々です。ただ、遠くたって正しい設計の場合はあると思います。Fimbul さんが書きました:すみません。私には理解できませんでした。ISLe さんが書きました: Abstract Factoryパターンというほどたいそうなものでなくて良いのですが、共有するデータを保持するクラスのインスタンスを引き出す関数とかを用意すれば良いのでは?
グローバルにアクセスできてしまうのが気持ち悪いのならば、コンテキストとしてクラス間でリレーするオブジェクトを用意して、そこに含める形になると思います。
「遠い距離にあるクラス間に関係がある設計」は、オブジェクト指向の設計として好ましいものなのでしょうか。
それと前々の返信から見ていて変数(コンテキスト)等のリレーがそんなに嫌なんでしょうか。
また、質問を修正してから「どうしたらよいのですか」の一点張りになっていますよ
Fimbul さんが書きました: 共有するデータを保持するクラスのインスタンスを、離れた2つのクラスにどの様に渡せばよいのでしょうか。
宿題ではないでしょうが丸投げ状態です。Fimbul さんが書きました: 共有するデータを保持するクラスのインスタンスは2つのクラスから参照できて、かつ必要な間ずっと存在してなければならないですよね?
これをどうやって実現するのでしょうか。
もし手も足も出ていないというなら、デザインパターンやら綺麗な設計やらに手を出すのが早いか、間違いなのではないでしょうか。(私にはそうも見えませんが)
✜ で C ご ✜
: す + 注 :
¦ か + 文 ¦
: ? Is the は :
✜ order C++? ✜
: す + 注 :
¦ か + 文 ¦
: ? Is the は :
✜ order C++? ✜
糸冬
――――――――
制作・著作 NHK
――――――――
制作・著作 NHK
Re: クラス間の変数のやり取りについて
勉強しても分からない事を質問する事と、丸投げは違います。新月の獅子 さんが書きました:また、質問を修正してから「どうしたらよいのですか」の一点張りになっていますよFimbul さんが書きました: 共有するデータを保持するクラスのインスタンスを、離れた2つのクラスにどの様に渡せばよいのでしょうか。宿題ではないでしょうが丸投げ状態です。Fimbul さんが書きました: 共有するデータを保持するクラスのインスタンスは2つのクラスから参照できて、かつ必要な間ずっと存在してなければならないですよね?
これをどうやって実現するのでしょうか。
もし手も足も出ていないというなら、デザインパターンやら綺麗な設計やらに手を出すのが早いか、間違いなのではないでしょうか。(私にはそうも見えませんが)
荒らしが目的なら私は返信はしませんし、最悪の場合は管理人さんに荒らしの処理をしてもらいます。
C/C++しか知らないので全部の理解は出来ませんでしたが、そう設計せざるを得ない場合がある事は分かりました。ISLe さんが書きました:好ましいかどうかは分かりませんが、特にハードウェア絡みだといきなりアクセスする準備ができていない場合があって、コンテキストを介したアクセスをするように設計せざるを得ない場合があります。Fimbul さんが書きました:「遠い距離にあるクラス間に関係がある設計」は、オブジェクト指向の設計として好ましいものなのでしょうか。
使う側からしたら面倒くさいですが、初期化のタイミングを制御できるメリットがあります。
例えば、Win32 APIのDCとか、Java(AWT)のGraphicsとか、AndroidのContextとか。
これらを用意するのはシステム側ですが、システムとアプリケーションの関係はそのままアプリケーション内部の実装に応用できると思います。
古い話ですが、BREWアプリがもろにコンテキストをリレーしないとほとんどのAPIにアクセスできないシステムでした。
なのでコアクラスというかアプリケーションクラスが必ず中心にあってシステムAPIもそのメンバ関数として実装するようにしてました。
確かにそうですね。へにっくす さんが書きました:好ましいかどうかは状況によるし、どう使うかによっても変わる。そもそも全然好ましくないのなら、デザインパターンとして出てこないのでは?Fimbul さんが書きました:「遠い距離にあるクラス間に関係がある設計」は、オブジェクト指向の設計として好ましいものなのでしょうか。
少なくとも2つのクラスを仲介する専用のクラスを作っとけば、片方の仕様が変わった時は、その片方のクラスと仲介クラスをみればいいのだから、十分じゃないの?
個人的には上の条件が満たせればいいと思っています。
(^^;
設計の問題でもあるかもしれないし、コーディングの問題でもあるかもしれないし、しかしながら、一般的に(少なくとも)仲介するクラスで解決すれば十分であるのかもしれまんせんね。
経験を積めば、状況に応じて適切な方法を使い分けられるようになるのかもしれません。
トピックが長くなりましたが、返答してくださった方どうもありがとうございました。
Re: クラス間の変数のやり取りについて
「分かった」というのは実際にそういうプログラムを作ってみて設計思想を理解したということですかね。Fimbul さんが書きました:C/C++しか知らないので全部の理解は出来ませんでしたが、そう設計せざるを得ない場合がある事は分かりました。ISLe さんが書きました:例えば、Win32 APIのDCとか、Java(AWT)のGraphicsとか、AndroidのContextとか。
これらを用意するのはシステム側ですが、システムとアプリケーションの関係はそのままアプリケーション内部の実装に応用できると思います。
古い話ですが、BREWアプリがもろにコンテキストをリレーしないとほとんどのAPIにアクセスできないシステムでした。
なのでコアクラスというかアプリケーションクラスが必ず中心にあってシステムAPIもそのメンバ関数として実装するようにしてました。
例として出したものは同列で、どれかひとつ理解できれば十分なので、C/C++しか知らなくても問題ありません。
考え方を理解できれば良いわけなので。
「C/C++しか知らないので全部の理解は出来ません」という言葉からは、端から理解する意思がないというふうに感じられます。
個人的には、実践しないで質問を繰り返すことも丸投げだと思います。
コンテキストの設計そのものに注目して欲しいので言語には関係ないと思うのですがね。
Fimbulさんは、「情報を引き出して使う」(コンテキスト内のデータにアクセスする)という考え方に固執しているように感じられます。
だからリレーすると汚いと。
Re: クラス間の変数のやり取りについて
「C/C++しか知らないので全部の理解は出来ません」というのは、そういう意味で書いたのではなく、せっかく書いていただいたのに全部理解できず、申し訳ないというニュアンスです。ISLe さんが書きました:「分かった」というのは実際にそういうプログラムを作ってみて設計思想を理解したということですかね。
例として出したものは同列で、どれかひとつ理解できれば十分なので、C/C++しか知らなくても問題ありません。
考え方を理解できれば良いわけなので。
「C/C++しか知らないので全部の理解は出来ません」という言葉は、端から理解する意思がないというふうに受け取れます。
「例として出したものは同列で、どれかひとつ理解できれば十分なので、C/C++しか知らなくても問題ありません。」
との事ですが、返信をもらった側は全部を理解しようとします。
ですので、例えば、Java(AWT)のGraphics、AndroidのContext、Brewアプリと言った言葉は私は初めて聞くので、調べて理解しようとする訳ですが、実際にプログラムを作れないので読んだ程度の理解になる訳です。
返信をした時点で、
「例として出したものは同列で、どれかひとつ理解できれば十分なので、C/C++しか知らなくても問題ありません。
考え方を理解できれば良いわけなので。」
というISLeさんの意思を私が読み取れなかったので、全部理解できず申し訳ないですという意味で書きました。
ですので、
「C/C++しか知らないので全部の理解は出来ません」という言葉は、端から理解する意思がないというふうに受け取れます。
というのは誤解です。
このトピックを立てる時も、自分で出来る範囲での試行錯誤をしています。ISLe さんが書きました:個人的には、実践しないで質問を繰り返すことも丸投げだと思います。
そしてトピックで質問をして、返信をもらう訳ですが、理解できなければ実践も出来ません。
Re: クラス間の変数のやり取りについて
オフトピック
Fimbul さんが書きました:このトピックを立てる時も、自分で出来る範囲での試行錯誤をしています。ISLe さんが書きました:個人的には、実践しないで質問を繰り返すことも丸投げだと思います。
そしてトピックで質問をして、返信をもらう訳ですが、理解できなければ実践も出来ません。
理解できないならまだ考えるのは早いのでは、という返信へ何故こういう煽りが返って来るのか。失礼な方ですね。Fimbul さんが書きました:勉強しても分からない事を質問する事と、丸投げは違います。新月の獅子 さんが書きました:また、質問を修正してから「どうしたらよいのですか」の一点張りになっていますよFimbul さんが書きました: 共有するデータを保持するクラスのインスタンスを、離れた2つのクラスにどの様に渡せばよいのでしょうか。宿題ではないでしょうが丸投げ状態です。Fimbul さんが書きました: 共有するデータを保持するクラスのインスタンスは2つのクラスから参照できて、かつ必要な間ずっと存在してなければならないですよね?
これをどうやって実現するのでしょうか。
もし手も足も出ていないというなら、デザインパターンやら綺麗な設計やらに手を出すのが早いか、間違いなのではないでしょうか。(私にはそうも見えませんが)
荒らしが目的なら私は返信はしませんし、最悪の場合は管理人さんに荒らしの処理をしてもらいます。
✜ で C ご ✜
: す + 注 :
¦ か + 文 ¦
: ? Is the は :
✜ order C++? ✜
: す + 注 :
¦ か + 文 ¦
: ? Is the は :
✜ order C++? ✜
糸冬
――――――――
制作・著作 NHK
――――――――
制作・著作 NHK
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: クラス間の変数のやり取りについて
穏やかにお願いしますね。
みなさんは、荒らしではないですよ。
Fimbulさんの試行錯誤の過程が見えないので、丸投げという印象を持った人が居たってことを理解していただければ良いかと思うのですが如何でしょうか?
今までの内容を整理して実験してみたこと、理解できないこと、疑問に思っていることを書かれてはどうでしょうか?
みなさんは、荒らしではないですよ。
Fimbulさんの試行錯誤の過程が見えないので、丸投げという印象を持った人が居たってことを理解していただければ良いかと思うのですが如何でしょうか?
今までの内容を整理して実験してみたこと、理解できないこと、疑問に思っていることを書かれてはどうでしょうか?
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: クラス間の変数のやり取りについて
なるほど。Fimbul さんが書きました:このトピックを立てる時も、自分で出来る範囲での試行錯誤をしています。ISLe さんが書きました:個人的には、実践しないで質問を繰り返すことも丸投げだと思います。
そしてトピックで質問をして、返信をもらう訳ですが、理解できなければ実践も出来ません。
「全部の理解は出来ませんでした」からどんなニュアンスを読み取ったとしても、わたしの返信を読んだということ以外は分かりませんでしたが。
そういうことであれば、理解できるまで試行錯誤を頑張ってください、とだけ申し上げておきます。
これ以上余計なことを書くのは良くないと思いますので、必要なことは行間から汲み取っていただければ幸いです。