“access-modifiers”の関連問題_Stack Overflow日本語サイト

0 投票する

8 に答える

766 参照

c# - パブリック変数を使用する理由

変数、メソッド、およびクラスは、さまざまなセキュリティレベルを受け取ることができます。私の C# の経験から、次のようなものがあります。

パブリック
内部
保護
保護内部
プライベート

これで、メソッドとクラスを非公開にする、または内部または保護することの使用法は理解できましたが、変数についてはどうでしょうか? 変数を private にしても、Property を使って別のクラスから呼び出すことができます。

私は常に、プロパティがベストプラクティスであると考えてきました。したがって、それを使用できれば、インスタンスを介して変数を直接呼び出す必要はありません。

変数をプライベートにしない理由はありますか?

編集: プロパティについて、あたかも栄光のパブリック変数に過ぎないかのように話している人がいます。

簡単な注意: public 変数はその値だけを返します。プロパティを使用すると、さらに多くのことができます。例えば：

私のプロフィールを読んだ人は、私が学生であることを知っています。プロパティを「美化されたパブリック変数」として使用することは、多くの仲間の学生が行っていることです。彼らにこれができると言ったときの最も一般的な反応は、「それは許されますか?」です。

c#variables access-modifiers

2009-11-23T00:11:42.797

0 投票する

1 に答える

715 参照

c# - アクセス修飾子を自動的にリファクタリングする

Visual Studioソリューションを実行し、ソリューションで呼び出されていないものにアクセス修飾子を調整して、該当する場合はプライベートまたは内部に変換できるツールはありますか？

すべてをプライベートに変更してから、コンパイラメッセージを使用して手動で実行できると思います...しかし、自動化されたものがあれば、それは素晴らしいことです！

c#visual-studio refactoring access-modifiers

2009-12-07T18:56:25.510

0 投票する

2 に答える

1498 参照

c# - アクセス修飾子が原因で、子コントロールにアクセスできません

WPFでユーザーコントロールを作成すると、このコントロールのすべての子が内部として宣言されているように見えますか？私はこれを確認することができず、この問題について議論しているリソースをまったく見つけることができませんでした。

同じアセンブリ内のコントロールにアクセスできますが、ユーザーコントロールが配置されているアセンブリを参照しているプロジェクトではアクセスできません。XAMLの子コントロールのデフォルトのアクセス修飾子をオーバーライドして、ユーザーコントロールのプロパティを介してコントロールを手動で公開する必要がないようにする方法はありますか？

c#.net wpf xaml access-modifiers

2009-12-14T15:24:50.110

0 投票する

6 に答える

4375 参照

c# - .NET - 他の特定の 1 つのクラスのみがインスタンス化できるようにクラスを作成する方法は?

次の設定をしたいと思います。

XML ファイルからロードされると、構造全体が読み取り専用になります。Descriptor クラスだけが Parameter をインスタンス化できるようにしたいと思います。

これを行う 1 つの方法は、IParameterインターフェイスを作成してからParameter、Descriptor クラスでクラスをプライベートにすることですが、実際の使用では、パラメーターにはいくつかのプロパティがあり、それらを 2 回再定義することは避けたいと思います。

これはどういうわけか可能ですか？

c#.net class c#-3.0 access-modifiers

2009-12-18T16:04:16.150

0 投票する

2 に答える

4534 参照

javascript - Prototype ライブラリを使用して JavaScript のアクセス修飾子を模倣するにはどうすればよいですか?

私はしばらくプロトタイプライブラリを使用してきましたが、複数のアクセスレベル (パブリック、プライベート、および保護) があればいいのにと思うことがあります。これまでに最も近いのは次のとおりです。

これは、いくつかの理由で理想的とは言えません。

保護レベルなし
プライベートメンバーにアクセスできるパブリックメンバー、またはオーバーライドできるパブリックメンバーを使用できますが、プライベートメンバーにアクセスしてオーバーライドできるパブリックメンバーは作成できません。
オーバーライドできるパブリックメソッドはプロトタイプ化されていません。

私はいくつかの検索を行いましたが、プロトタイプの動作を変更せずに改善できることを示唆するものは何も見つかりませんでした. より興味深いリンクのいくつかを次に示します。

次のようなことを行うことで、パブリック仮想メソッドが使用するアクセサーを提供できることが示唆されているのを見てきました。

これは明らかに意図したとおりには機能しません。目標は、オブジェクトの外部からのメッセージへの印刷と追加のみを許可することです。仮想パブリック関数を機能させるために提供されるセッターは、メッセージの完全な制御も可能にします。次のように、仮想メソッドをシェルよりも少し多くするように変更できます。

この新しいバージョンでは、このクラスのパブリックアクセスが制限されていますが、やや冗長です。サブクラスで appendToMessage がオーバーライドされている場合は言うまでもなく、サードパーティが _appendToMessage を呼び出して元のメソッドにアクセスできますが、これは良くありません。

私は私を近づける非常に汚い考えを持っていますが、開けたくないワームの缶です. 後で投稿するかもしれませんが、その間に、2 つのタイプのパブリックメソッドを 1 つの有用なタイプにマージする方法や、保護されたメンバーを実装する方法について提案がある人はいますか。

編集：フィードバックの欠如（bobinceのコメントを気にしないでください）は、これ以上先に進むことができないという点で私が正しいことを意味すると思いますが、念のため少し明確にすると思います。他の言語の保護に近いものを手に入れることは不可能だと思います。限界がどこにあるのか、関係する原則についての私の理解がどれほど正確であるかを知ることにもっと興味があります。ただし、非公開メンバーが for...in ループ (または Prototypes Object.keys for..in) を使用している場合でも、自分が何をしているかを知っている人が、私のプロトタイプをいじるなどしてルールを破ることができます。やっぱりボビンスみたい「彼らは自分以外に責任を負わない」と言う

bobinceによって提起された問題についてコメントします。

実際のプライベート/保護された変数を作成したとしても、効果的なセキュリティ境界に必要な完全なカプセル化は得られません。メソッドが使用する組み込み型のプロトタイプをいじる JavaScript の機能により、攻撃者はメソッドを妨害することができます。

これは私が理解している 1 つの制限であり、おそらく上記で言及する必要がありました。ただし、コードを「ハッキング」しようとする人からコードを保護するという観点からは、これを見ていません。ただし、注意すべき点がいくつかあります (または、間違っている場合は修正する必要があります)。

私の公開メンバーだけがこのように脆弱です。
私のパブリック仮想メソッドがこのように「侵害された」場合、「侵害された」メソッドはプライベートメンバーにアクセスできません。
パブリック (非仮想) メンバーがこのように「侵害」された場合、メソッドの元のバージョンとは異なり、「侵害」されたバージョンはプライベートメンバーにアクセスできません。
私の知る限り、initialize メソッドの外部で定義されたメソッドによってプライベートメンバーにアクセスする唯一の方法は、一部のブラウザーが eval 呼び出しを処理する方法のバグを利用することです。

javascript inheritance prototypejs theory access-modifiers

2009-12-24T12:41:35.983

0 投票する

7 に答える

5647 参照