- - PR -
C++ におけるクラスの多重化について
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-08-06 18:35
C++で、ということは、できる言語があるということでしょうか? いえ、コンストラクタが別のクラスのインスタンスを返すのって、なんだか怖いなぁと思ったので。 [ メッセージ編集済み 編集者: Jitta 編集日時 2007-08-06 18:36 ] | ||||||||||||
|
投稿日時: 2007-08-06 20:18
こんばんは。
いえ、そういうつもりで書いたわけではないです。 自分がどういうニュアンスでこういう書き方をしたのか、しばらく思い出すのに時間が掛かりましたが…たしか 「質問者さんのC++のスキルはどのくらいなんだろう?上級者なのか、それとも(失礼ながら)初心者かも」と思いつつ、 「すくなくともC++の文法レベルで無理なことは理解されているのかな?」という気持ちがあったように思います。 たしかに、C++以外だったらできる言語があるような言い回しだったかもしれません(-_-;) 実際のところ私が知っているプログラミング言語なんて、世にあるうちのホンの一握りなので もしかしたらあるのかも?とは思いますが。
プログラマが意図しているものとは別のものができあがるっていうのは確かに怖いですが、 ”仮想コンストラクタ”的なことをしたい(コンストラクタを抽象化したい。実行時に決定したい。)という要望はよくあると思います。 #たしかFactoryMethodパターンの別名がVirtual Constructorだったような!? | ||||||||||||
|
投稿日時: 2007-08-06 21:37
紛らわしいことしてごめんなさい。そのことを、遠回しに(ry
こちらも言葉が抜けました。 "クラスのコンストラクタ"が、そのクラス以外のインスタンスを返すのは怖いなぁ、と。なので、Factory 系のデザイン パターンができたのだと思います。 もちろん、継承やインターフェイスを実装したクラスで、ある条件に適合したオブジェクトがほしいと言うことはよくあることです。それを行う、メソッドなら何とも思わないのですが、コンストラクタが、というのが、怖いかな、と。宣言の時に型を付けないなど、メソッドの形式をしていますが、特別なメソッドだと思いますので。 | ||||||||||||
|
投稿日時: 2007-08-07 01:15
それは、元質問者のわたくしが「C++で」と書いたからでしょう。 わたくしは、他人の書いたソースをメンテナンスする程度はしていましたが C++ のプログラマの初心者と言えば初心者でしょうし オブジェクト指向の継承絡みの実用的設計とかについても 初心者と言えば初心者でしょう。 困った class_a と class_a1,class_a2 のおかげで、多少は学習しましたが。
ダミー関数とかでインスタンスのポインタを返すのも 似たような意味合いからなんとなく嫌なのですが... ラッパークラス利用方式もメンバー関数を呼ぶ毎に 毎回、private の本物クラスへのポインタを評価しなければならないのが嫌なのです。 かと言って、仮に可能だとしても オペレータ( -> とか new とか)の書換えなんてマニアックな事まではしたくない (誰もメンテナンス出来なくなりそう)。 しかし... ドライバマネージャのようなクラスって、どう作っているんだろう? 例えば ODBC とかって、ODBCドライバが何であるか(OracleとかMSとか)を意識しなくても 共通的に利用出来るじゃないですか? ある意味で似たような事(と思っている)をしたいだけなのです。 まだ、デザインパターンとかを、詳細に考察してません。 デザインパターンをきちんと学習すれば、その中にヒントはあるかも知れませんが。 | ||||||||||||
|
投稿日時: 2007-08-07 09:41
A1、A2からなんらかの名前を生成して、あるDLLに対してGetProcAddressして実行。そのプロシージャがB1またはB2を返すとか。
| ||||||||||||
|
投稿日時: 2007-08-07 22:44
それに近いような手法も必要な気がします。 実はさらに先の .so (DDL) の関係で あるマシンでは class_a1 と class_b1 しか使えず 別のマシンでは class_a1,class_a2 と class_b1,class_b2 が使えるのです。 で、class_a_common とか class_b_common で #ifndef XXX2_NOT_INSTALL を使って呼び出されないような形にして make (BUILD)と言うか ld (LINK) していたりします。 自分らのライブラリを .so にする分には 未解決のエントリがあっても良いみたいなのですが ロードモジュール (.exe) を作る際とか 実行時にエントリが無いだけ(別環境で作成したもの)で 使えないはずのクラスが呼ばれる前にコケルので。 class_a3 とか class_b3 とかが必要になる前にキレイにして置きたいところですが... たぶん、その頃にはわたくしは担当していなくて、新しい担当者が泣くのです。 class_a だけじゃなく class_b のために泣かされるのです。 そして class_c 配下に class_c1,class_c2,class_c3 が出来て... 限りなくメンテナンス出来なくなるまで複雑怪奇化した時に 初めて class_a から見直しして貰えるのです(廃棄処分とも言うかも)。 もっとも、15年以上存在しやがる不可解な class_a だから... しぶとく生き残ったりして。 |