- PR -

呼び出し元のクラスをロード？

«前のページへ 1|2|3|4 次のページへ»
投稿者投稿内容
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市（は俺も含めてロクな人間が住んでないよｗ）
投稿日時: 2006-09-13 19:50
引用:

頭脳パンさんの書き込み (2006-09-13 19:24) より:
また、プラグインクラスは使い方が少しやっかいで、
呼び出し側でインスタンス化しないで、クラスライブラリで
なんとかしたいという理由もあります。

その理由が知りたい。

> なので、Hogeクラスは呼び出し側でインスタンス化して渡すことは考えていません。
につながらないので。何がなのでなの？
頭脳パン
ベテラン
会議室デビュー日: 2003/04/03
投稿数: 89
投稿日時: 2006-09-13 19:56
＞につながらないので。何がなのでなの？
わかりにくい文章ですいません。
一応、↓が理由です。

１．
＞Hogeはプラグインクラスで、どこに作成されるかはクラスライブラリを
＞使用する側の自由にしています。（今のところ）
コンソールアプリ(a.exe)には、Hogeクラスはないかもしれないからです。
クラスライブラリ(b.dll)にあるので、それをa.exeでロードしてという
手間もクラスライブラリ(c.dll)を使う側にはやらせたくありません。
（簡単に使用できるクラスライブラリにするため）

２．
＞また、プラグインクラスは使い方が少しやっかいで、
＞呼び出し側でインスタンス化しないで、クラスライブラリで
＞なんとかしたいという理由もあります。
こちらも同様で、簡単に使用できるクラスライブラリにするために
プラグインクラスを使い手に触らせたくありません。
頭脳パン
ベテラン
会議室デビュー日: 2003/04/03
投稿数: 89
投稿日時: 2006-09-13 20:00
＞c.dllを使用する際、必ずb.dll若しくはa.exeを必要とさせたいのですか？
＞それともc.dllを呼び出す際は必ずHogeクラスを新しくコーディングさせたいのですか？
必ずではないです。プラグインクラスなので必要があればです。
必要なければ、Hogeクラスは存在しません。
mio
ぬし
会議室デビュー日: 2005/08/25
投稿数: 734
お住まい・勤務地: 神奈川県
投稿日時: 2006-09-13 21:44
存在しないならnullを渡せばいいだけでは…。
もしくは引数ありなしのオーバーロード。

[ メッセージ編集済み 編集者: mio 編集日時 2006-09-13 21:48 ]
kuma
大ベテラン
会議室デビュー日: 2004/02/25
投稿数: 110
投稿日時: 2006-09-13 23:24
引用:


２．
＞また、プラグインクラスは使い方が少しやっかいで、
＞呼び出し側でインスタンス化しないで、クラスライブラリで
＞なんとかしたいという理由もあります。
こちらも同様で、簡単に使用できるクラスライブラリにするために
プラグインクラスを使い手に触らせたくありません。


触らせたく無い部分を抽象クラス(Hoge)として実装しcに入れ
a(b)では継承クラス(Hoge')をインスタンス化してcを呼び出す。
といったことは.NETでは不可能なのでしょうか？
(Javaがメインなもので単純に考えていましたが
不可能であれば私の勉強不足です。すみません)
Ahf
大ベテラン
会議室デビュー日: 2006/08/16
投稿数: 172
投稿日時: 2006-09-14 00:11
引用:
頭脳パンさんの書き込み（2006-09-13 18:59）より
コンソールアプリ(a.exe)　→（呼び出し）→　クラスライブラリ(b.dll)　→（呼び出し）→　クラスライブラリ(c.dll)

c.dllにて、b.dllに含まれるHogeクラスを使用したい。

プラグイン形式でなおかつc.dll→b.dllという関連があるのなら、
a.exe→c.dll→b.dll　という方向で参照するのが素直なパターンなのでしょうけど、
感覚的にはa.exeとb.dllを作成した人間と、c.dllを作成した人間が別、というタイプ
のアプリケーションとなるのでしょうか。

＃抽象クラスかインターフェースがb.dllにあり、c.dllにはそれを継承したクラスがある。
＃そしてプラグインを管理する機能はb.dllにある、というような関係になっている？

でもそれだと、抽象クラスを別のd.dllなどに切り分けてしまえばスッキリするような？

読み違えていたら申し訳ありません。
頭脳パン
ベテラン
会議室デビュー日: 2003/04/03
投稿数: 89
投稿日時: 2006-09-14 08:56
使い手にプラグインを触らせたくない大きな３つ目の理由がありました。

仕様が、クラスライブラリにて、DBに設定されている設定
（プラグイン使用有無、クラス名等）に従って処理を行う。

というのがあります。ここは私の力では変更できないところです。
（但し、不可能であったり、致命的な欠陥があった場合は変更可能）

よって、呼び出し側でインスタンス生成して渡すってことが
選択できないです。

>存在しないならnullを渡せばいいだけでは…。
>もしくは引数ありなしのオーバーロード。
上記仕様でなければ、これでOKですね。

>といったことは.NETでは不可能なのでしょうか？
仕様に従っているのでやっていないだけで、可能ですよ。

>＃抽象クラスかインターフェースがb.dllにあり、c.dllにはそれを継承したクラスがある。
>＃そしてプラグインを管理する機能はb.dllにある、というような関係になっている？
プラグインはどこに作成してもらうかは決めていません。
（できれば、好きなところに作成してくださいとしたいです）
そして、その抽象クラスは、c.dllにあります。

ところで、論点がずれていっているかもしれません。
私の質問は実は、結構くだらないです。

呼び出し元で、インスタンス化してそれを渡せばいいじゃん？というのは
考えていなくて（やりたくても選択できない）

c.dllで、a.exeにあるクラス（ある場合、ない場合も想定）を
をLoadFromするのは変な気がする？よりよい方法は？といったところが
今回の質問です。

コンソールアプリ(a.exe)　→（呼び出し）→　クラスライブラリ(c.dll)

（ただ、先に、a.exeでインスタンス化して渡すという選択は
やりたくても取れないというのを最初に書いておくべきでした。申し訳ありません）

プラグインクラスは、必ず別途ライブラリに作成して下さいと決めてしまった方が
すっきりするかな。と思い始めました。

c.dllで、a.exeをロードするのはあまりやらない方がいい気がするので。
（a.exeは大きそうなので）
masa
大ベテラン
会議室デビュー日: 2004/10/28
投稿数: 161
投稿日時: 2006-09-14 09:15
話の内容から、以前に私が質問した内容に似ているようなので、

別AppDomainへのアセンブリ読み込み
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=30695&forum=7

指定されたDLLから型情報を読み込んで、インスタンスを作成しています。
終了したら解放したいという目的もありましたので、
AppDomain をつかっています。


で、取得した型を使って

IPlugin obj =
　domain.CreateInstanceAndUnwrap(アセンブリ名, プラグインの型) as IPlugin;

のように目的のプラグインをインスタンス化しています。



[ メッセージ編集済み 編集者: masa 編集日時 2006-09-14 09:27 ]
«前のページへ 1|2|3|4 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）