C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

フレンドクラスに対する代替案

(過去ログ 7 を表示中)

[トピック内 20 記事 (1 - 20 表示)]　 << 0 >>

■7138 / inTopicNo.1)

　フレンドクラスに対する代替案

▼■

□投稿者/ 白やぎ二等兵(1回)-(2006/10/03(Tue) 19:38:38)

分類:[C#]　

分類:[C#]　

C#でC++のフレンドクラスみたいなこと（ある特定のクラスからは自分のprivateなメンバにアクセスできる）をやりたいのですが、C#ではフレンドはサポートされていません。
なにかよい代替案をご存知の方がいらっしゃいましたら、是非、教えてください。
デザインパターンとか、これが使える、とおっしゃっていただければ、それについて勉強します。
というか、きちんとクラス設計すればフレンドなんか必要なかったりするんですかね(><;

特に急ぎではないので、お暇なときに気が向いたらレスください...

引用返信 編集キー/

■7141 / inTopicNo.2)

　Re[1]: フレンドクラスに対する代替案

▲▼■

□投稿者/ NANA氏二等兵(2回)-(2006/10/03(Tue) 19:54:15)

分類:[C#]　

フレンドなんて使わない方がいい。
C#でなぜサポートされていないかを考えた方がいい。

引用返信 編集キー/

■7142 / inTopicNo.3)

　Re[2]: フレンドクラスに対する代替案

▲▼■

□投稿者/ 囚人一等兵(35回)-(2006/10/03(Tue) 19:59:32)

分類:[C#]　

internal で十分かな？

引用返信 編集キー/

■7143 / inTopicNo.4)

　Re[1]: フレンドクラスに対する代替案

▲▼■

□投稿者/ 白やぎ二等兵(2回)-(2006/10/03(Tue) 20:10:27)

分類:[C#]　

> C#でなぜサポートされていないかを考えた方がいい。
...ですね。
考えた後、クラス設計をやり直してみます。

> internal で十分かな？
今コーディングしているのが自分用の雑多なライブラリなので、DLLにしておけばinternalもアリですかね。

うーむ。
もっと勉強します。
助言、ありがとうございました。

もう少し、書き込める状態にしておきます。

引用返信 編集キー/

■7146 / inTopicNo.5)

　Re[2]: フレンドクラスに対する代替案

▲▼■

□投稿者/ επιστημη 大尉(179回)-(2006/10/03(Tue) 21:37:41)

分類:[C#]　

> フレンドなんて使わない方がいい。
> C#でなぜサポートされていないかを考えた方がいい。

なぜだろ。わかんないや。教えてください。

- internalがあるから要らない。
なのか、
- フレンドは良くないので削除。代わりにinternalを採用。
なのか。

後者だとすると、疑問は残る。
もっといえば、internalの方が勝手に触れるヒトが増えるんだからもっと悪い。
あたしゃフレンドの方がまだマシに思える。

引用返信 編集キー/

■7149 / inTopicNo.6)

　Re[3]: フレンドクラスに対する代替案

▲▼■

□投稿者/ NANA氏二等兵(3回)-(2006/10/03(Tue) 22:31:12)

分類:[C#]　

■No7146に返信(επιστημηさんの記事)
> - internalがあるから要らない。
> なのか、
> - フレンドは良くないので削除。代わりにinternalを採用。
> なのか。

なんで二択なんだろう？

フレンドは良くないので削除。

internalなんて関係ないと思うのだが。

引用返信 編集キー/

■7152 / inTopicNo.7)

　Re[4]: フレンドクラスに対する代替案

▲▼■

□投稿者/ επιστημη 少佐(181回)-(2006/10/03(Tue) 22:38:22)

分類:[C#]　

2006/10/03(Tue) 22:39:27 編集(投稿者)

> フレンドは良くないので削除。

いや、だからナゼ?

> internalなんて関係ないと思うのだが。

目的は一緒ですよね? 赤の他人の懐に手ぇ入れるんだから。
むしろinternalの方が罪深い。

フレンドが良くないてのを認めると、
フレンドを削除しておきながらなぜにintenalがあるんかがわからんのです。

引用返信 編集キー/

■7155 / inTopicNo.8)

　Re[1]: フレンドクラスに対する代替案

▲▼■

□投稿者/ 魔界の仮面弁士大尉(166回)-(2006/10/03(Tue) 22:59:49)

分類:[C#]　

2006/10/03(Tue) 23:53:08 編集(投稿者)

> C#でC++のフレンドクラスみたいなこと（ある特定のクラスからは自分のprivateなメンバにアクセスできる）をやりたいのですが、C#ではフレンドはサポートされていません。
> なにかよい代替案をご存知の方がいらっしゃいましたら、是非、教えてください。

C++ は門外漢なので、自分の言葉として回答する事はできませんが、
C# の父たる Anders Hejlsberg 氏は、friend に対する案として、

≫ 意見: （public でないメソッドをユニットテストするために）
≫ 　　C++ の friend に相当するものが欲しい。
≫ A: フレンドアセンブリという機能がある。

といった事をおっしゃっていましたね。
http://www.microsoft.com/japan/msdn/community/person/andershejlsberg/communityreport.aspx
http://www.atmarkit.co.jp/fdotnet/insiderseye/20060215cscommunity/cscommunity_02.html

引用返信 編集キー/

■7156 / inTopicNo.9)

　Re[2]: フレンドクラスに対する代替案

▲▼■

□投稿者/ επιστημη 少佐(182回)-(2006/10/03(Tue) 23:06:43)

分類:[C#]　

2006/10/03(Tue) 23:14:10 編集(投稿者)

> C# の父たる Anders Hejlsberg 氏は、friend に対する案として、
>
> ≫ 意見: （public でないメソッドをユニットテストするために）
> ≫ 　　C++ の friend に相当するものが欲しい。
> ≫ A: フレンドアセンブリという機能がある。
>
> といった事をおっしゃっていましたね。

うんうん。(internalがああるから)friendは要らない。これはわかる。

が、friendは悪だとするならinternalはもっと悪です。

friendは必要悪だとするなら、internalでもっと酷くするくらいならfriend温存すりゃええやん。

なんでこんなことしたの? って思うの。

引用返信 編集キー/

■7158 / inTopicNo.10)

　Re[3]: フレンドクラスに対する代替案

▲▼■

□投稿者/ επιστημη 少佐(183回)-(2006/10/03(Tue) 23:21:13)

分類:[C#]　

2006/10/03(Tue) 23:26:10 編集(投稿者)

>>≫ 意見: （public でないメソッドをユニットテストするために）
>>≫ 　　C++ の friend に相当するものが欲しい。
>>≫ A: フレンドアセンブリという機能がある。

MSDNによると:

フレンドアセンブリ機能を使用すると、内部メンバへのアクセスが可能になります。
ただし、プライベート型とプライベートメンバにはアクセスできません。

なんだこれ。friendの代替になってないんじゃない?

引用返信 編集キー/

■7163 / inTopicNo.11)

　Re[4]: フレンドクラスに対する代替案

▲▼■

□投稿者/ 中博俊神(766回)-(2006/10/04(Wed) 01:14:14)

分類:[C#]　

internalはアセンブリ内継承だけを認めるという感じで追加したものと思われます。
基本的にはfriendは入れたくない。だけど抜け道はってところでしょうか。
ちなみにフレンドアセンブリはテスト用アセンブリから中身を丸見えにさせるためだったり。

引用返信 編集キー/

■7166 / inTopicNo.12)

　Re[5]: フレンドクラスに対する代替案

▲▼■

□投稿者/ επιστημη 少佐(184回)-(2006/10/04(Wed) 05:51:15)

分類:[C#]　

> internalはアセンブリ内継承だけを認めるという感じで追加したものと思われます。
> 基本的にはfriendは入れたくない。だけど抜け道はってところでしょうか。

そうなんだけどさ、friendならば特定の誰かに公開するだけなのにアセンブリ内のすべてに対して晒すわけっしょ。
傷口が余計に拡がってるやん。

> ちなみにフレンドアセンブリはテスト用アセンブリから中身を丸見えにさせるためだったり。

UnitTestのために外部のアセンブリに対して公開する、って使い方についてはいいと思う。
そじゃなくて、
赤の他人に触られるのは好ましくない、仕方ないにしても極力晒す範囲を制限しよう。
って趣旨であればfriendがいちばん狭いわけやん。
で、そのfriendを捨てておきながらより悪質(と言わせてもらうが)なinternalや
フレンドアセンブリを導入するたぁどーゆー了見なのよ?

そう考えると「friendは良くないので削除」では理由にならんだろ? と思ってるわけね。

引用返信 編集キー/

■7179 / inTopicNo.13)

　Re[6]: フレンドクラスに対する代替案

▲▼■

□投稿者/ 囚人一等兵(36回)-(2006/10/04(Wed) 12:17:57)

分類:[C#]　

アセンブリっつー概念ができたから「お前ら(アセンブリ内のクラス)はみんな俺のフレンド！いやファミリーだ！晒せる所は晒すさ！でもプライベートには入ってくんな！親友じゃなくて家族なんだから」が可能になった。

firend は晒す「相手」が超限定、晒す「内容」は超オープン。
internal(IL では family) は晒す「相手」はやや広がり、晒す「内容」はややオープン。

friend 、family とはピッタリな名称ですね。.NET では全てを話せる親友は禁止され、家族レベルで考えたらいいやんって事でしょうか。
傷口が拡がったかどうかは視点次第ですね。

でも確かに firend はあっても別にいいかなぁとは思います。「お前は俺の親友！」とクラス自体が宣言するわけですし。
private にアクセスできるのは自分だけじゃないと都合が悪いのかな？

引用返信 編集キー/

■7181 / inTopicNo.14)

　Re[7]: フレンドクラスに対する代替案

▲▼■

□投稿者/ 中博俊神(767回)-(2006/10/04(Wed) 12:34:19)

分類:[C#]　

friendを入れるにしても入れ方が問題。
internal friendなら賛成です。
外部アセンブリも含めたfriendは問題が多いと思われます。

引用返信 編集キー/

■7187 / inTopicNo.15)

　Re[8]: フレンドクラスに対する代替案

▲▼■

□投稿者/ επιστημη 少佐(185回)-(2006/10/04(Wed) 14:26:05)

分類:[C#]　

# ついでに全くの別件といえば別件なんですけど

private {
  // ここに書いたのはみーんなpublic!
  void こっそり関数() { ... }
}

なんて書式を許してくれたらいいのに、と突然思った。
これがあれば:

#if DEBUG
public
#else
private
#endif
  {
    いろいろー
  }

って書けばDEBUG時にのみ晒せるやん。UnitTestが楽よん。
現仕様だとメンバひとつひとつにアクセス指定子がつくから:

#if DEBUG
public
#else
private
#endif
  void こっそり関数() { ... }

てな具合にひとつひとつ書かなならんでマンドクセーでする。

引用返信 編集キー/

■7198 / inTopicNo.16)

　Re[9]: フレンドクラスに対する代替案

▲▼■

□投稿者/ ghost_shell 二等兵(6回)-(2006/10/04(Wed) 15:41:29)

分類:[C#]　

ＣからＣ＃にやってきたので、friendについては知らないのですが、internalについては僕も好意的ではありません。

friendの使用法はここで見てきました。
http://www.page.sannet.ne.jp/mtoga/lang/cp/bih-p_40.htm

正しい理解・利用のもとで使いやすいのはfriendの方ですね。

アクセス修飾子を厳密で明確なものにしたかったからfriendを取り入れなかったのだろうか。

privateな内部クラス（publicな入れ子クラスは推奨されていない）として設計することができても、大きなクラスになるため保守が面倒そうで敬遠することがしばしばあります。

依存（関連）の度合いを低くしても、プログラムにクラス間の相互作用をなくすことはできないのだからオブジェクト指向言語にとってこの機能は"必要悪"ではなく、本当に"必要"なんだと思います。
＃って、ここで言ってどうする。

引用返信 編集キー/

■7200 / inTopicNo.17)

　Re[10]: フレンドクラスに対する代替案

▲▼■

□投稿者/ επιστημη 少佐(189回)-(2006/10/04(Wed) 16:07:31)

分類:[C#]　

> 依存（関連）の度合いを低くしても、プログラムにクラス間の相互作用をなくすことは
> できないのだからオブジェクト指向言語にとってこの機能は"必要悪"ではなく、
> 本当に"必要"なんだと思います。

そーなんだけど、friendもなんもないなら「複数クラスの連携はpublicなインタフェースだけでやれ」ってことですわね。

そじゃなくて、利用者に見せ/関与させたくない連携を取りたいってとき、
できることなら連携の相手を極力限定したい
(そじゃないとどこぞの馬の骨に食べられちゃうかもしんないから)。
ならば連携の相手を名指しで指定するfriendがいっちゃん安全だと思うなー。

引用返信 編集キー/

■7224 / inTopicNo.18)

　Re[11]: フレンドクラスに対する代替案

▲▼■

□投稿者/ 黒龍二等兵(10回)-(2006/10/04(Wed) 18:38:46)

分類:[C#]　

■No7200に返信(επιστημηさんの記事)
> (そじゃないとどこぞの馬の骨に食べられちゃうかもしんないから)。
> ならば連携の相手を名指しで指定するfriendがいっちゃん安全だと思うなー。
配布形態(ソースレベルポータビリティなのかバイナリレベルポータビリティか)をまぜこぜにしちゃうとinternalやfriendも範囲が変わってきちゃう気がします。
僕もC++から入った口なのでソースを使う分にはInternalはちょっとやりすぎかなぁって気もするんですがアセンブリを使う分にはしっかり閉じられているわけで･･･。

引用返信 編集キー/

■7225 / inTopicNo.19)

　Re[6]: フレンドクラスに対する代替案

▲▼■

□投稿者/ NANA氏二等兵(4回)-(2006/10/04(Wed) 20:56:13)

分類:[C#]　

■No7166に返信(επιστημηさんの記事)
> そうなんだけどさ、friendならば特定の誰かに公開するだけなのにアセンブリ内のすべてに対して晒すわけっしょ。
> 傷口が余計に拡がってるやん。

昨日から公開された相手の多さを問題視していたのですか。
確かにこれでは話が合うはずもない。

ちなみに囚人さんに言いたいこととられた・・・

引用返信 編集キー/

■7226 / inTopicNo.20)

　Re[7]: フレンドクラスに対する代替案

▲　■

□投稿者/ επιστημη 少佐(194回)-(2006/10/04(Wed) 21:32:00)

分類:[C#]　

> 昨日から公開された相手の多さを問題視していたのですか。
> 確かにこれでは話が合うはずもない。
>
> ちなみに囚人さんに言いたいこととられた・・・

NANA氏さんは晒す内容(friendはprivateまで晒すのでけしからん)を
云々してたワケすか?

「話が合うはずもない」と仰られても「friendはイクない」ってだけ
だったのでさっぱりわからんかった、つか合うも合わんもなかったです。

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -