1

チームソリューションの他のクラスで現在使用されていないメソッドを実装する場合、アクセス修飾子はパブリックまたはプライベートにする必要がありますか？「パブリックメンバーは、このメンバーがこのオブジェクトによって提供される重要な文書化された機能を表していると言っています。」と私は信じています。私たちは「実装の詳細」メソッドのみをプライベートにし、将来役立つ可能性のあるすべてのメソッドを公開する必要があります。現在でも、他のクラスにメソッドのコンシューマーはありません。しかし、私の対戦相手は、そのような方法は私的なものであるべきだと言っています。あなたはどのように思いますか？

追加：より具体的にしましょう。たとえば、クラスSqlHelperがあります。その中には、SQLServerでの操作に役立つ機能があります。特に、SQLサーバーへの接続が使用されます。しかし、そのクラスだけではありません。

たとえば、SqlExeptionsを処理するパブリック静的HandleSqlExeptionメソッド（現在はクラスSqlHelperのみ）を実装する必要があります。しかし、例外処理でSQL接続を使用する操作があるすべてのクラスで、このメソッドを使用する必要があります（たとえば、単純ではなく、catch（Exception）{MsgBox{"SqlError"};現在どこかで発生します。パブリックアクセス修飾子は他の同僚にこのメソッドを使用できると言うと思います。プライベートはそのメソッドを非表示にします。誰かがそのようなメソッドを使用するように要求した場合は、コードを変更してアセンブリを再構築する必要があります。ネガ。

4

5 に答える 5

10

一般に、許容度が最も低いアクセス修飾子を使用してコーディングする必要があります。

  • メソッドがクラス外で使用されていない場合は、 にしprivateます。
  • 型を継承してメソッドを使用する必要がある場合は、 にしprotectedます。
  • メソッドがアセンブリ内でのみ使用される場合は、 にしinternalます。
  • メソッドがアセンブリの外部で使用される場合にのみ、public.

これは情報の隠蔽に役立ち、実装を自由に変更できます。

これはあなたのプライベートを守るものだと聞いたことがあります。

API 設計に関しては、すべての論理機能を公開する完全な API が必要です。publicこれが、すべてのインターフェイス メンバーが .NET である必要があるため、API 設計に .NET のインターフェイスを使用する必要がある理由ですpublic。クラスを実装する際には、インターフェースの一部ではないメンバーに対して上記の経験則を使用してください。ただし、コンシューマーに関する限り、それらがインターフェースの論理部分を形成する場合を除きます。

したがって、現在使用されているメソッドがある場合は、同じアクセシビリティを持つRead補完的なWriteメソッドが必要です。これは良い設計です (対称であり、期待されます) が、パブリック メソッドがプライベート メソッドを使用する場合、読み書きの方法はプライベート メソッドの背後に隠されている必要があります。

于 2013-01-23T09:40:54.147 に答える
1

クラスに外の世界に公開するものがある場合は、それをパブリックにし、それ以外の場合はプライベートにします。現在または将来の要件ではなく、クラスの機能と目的によって異なります。

于 2013-01-23T09:50:47.450 に答える
1

Use public and private depending on the nature of the method as name describes.

public when the method can be exposed to other objects and

private when the method should not be accessed by other objects.

If your object needs to be more secure, use private access specifier. You should also know about protected access specifier which is different in that, those methods can be accessed only by the objects that inherit them.

于 2013-01-23T09:42:10.587 に答える
1

これは裁判の呼びかけです。一般的に言えば、クラスが提供する機能を取得するためにクラスが提示するインターフェイスの論理的な一部である場合は、現在のユーザーがいない場合でも公開する必要があります。これにより、すでに使用しているのと実質的に同じ目的でクラスを使用するたびに、クラスを変更する必要が生じる可能性が低くなります。

ただし、これにはコストがかかります。公開する各機能は、提供することを約束している機能です。将来、パブリック インターフェイスから削除することにした場合、呼び出し元が壊れる可能性があります。

たとえば、マップ クラスを考えてみましょう。現在、マップ内のアイテムの数を知る必要がある呼び出し元がなく、現在の実装にはsize簡単に返すことができる変数があるとします。getSizeマップのサイズを返す関数を追加できます。論理的には、マップ クラスが公開する関数の一部です。そのため、現在の呼び出し元がサイズを知る必要がなくても、パブリックにする必要があると主張できます。

sizeただし、将来の実装で変数を削除する可能性は十分にあります。おそらく、サイズの増加と減少のオーバーヘッドが大きく、サイズを知る必要がないように実装が変更されます。関数を公開しgetSize、それが呼び出された場合、必要がない場合でもサイズを追跡し続けるか、関数を非常に高価にして実際にサイズをカウントする必要があります。

テーブルが空かどうかを知る必要がある多くのコードがありisEmpty、この目的のために関数を提供するとします。経験によると、関数も提供するとgetCount、人々はgetCount() == 0の代わりにそれを行いisEmptyます。それは今日は何の違いもないかもしれませんが、将来の実装の選択を制限しgetCount、isEmpty.

可能であれば、その機能にアクセスすることで恩恵を受けるクラスの壊れていないユーザーが簡単に想像でき、それがクラスが提供する機能の論理的な部分を形成する場合は、公開することを強くお勧めします。それ以外の場合は、後で簡単に追加できます。ですから、あまりストレスを感じないでください。それは主にスタイルの問題であり、将来を予測しようとする試みと混ざり合っています.

于 2013-01-23T10:05:03.230 に答える
0

オブジェクト指向開発の基本原則。クラスのインスタンスは、そのクライアントがアクセスする必要があるものだけを公開する必要があります。リンクを参照して「カプセル化」を検索してください。

于 2013-01-23T09:43:59.003 に答える