0

インターフェイスを実装する抽象クラスを作成しました。この抽象クラスは、そのインターフェイスのプロパティを入力する必要があるいくつかの具象クラスのベースになります。

最初の 2 つの例では、CLR 準拠の警告がポップアップ表示されます。私はそれらが何を表しているかを理解しており、それらをカバーするいくつかの質問がここにあります.

フィールドを異なるものにするために、末尾にアンダースコアを追加できます。コンパイラによって受け入れられます。これは正しいスタイルの選択ですか。あまり目立たないと思いますし、コードの匂いかもしれません。ただ、慣れていないだけかもしれません。

それとも、プロパティ フィールドを定義する抽象的な祖先を作成するのは間違っていますか? もちろん、作業の重複を省き、標準的な実装を強制するのに役立つという考えですが、これらの「隠し」フィールドに値を割り当て始めると、子孫に独自の匂いがする可能性があることがわかります。

namespace MyLittleCompany.Widgety
{
  public abstract class MlcWidgetInformation : IMlcWidgetInformation
  {
    //Compiler complains of Non-CLR Compliance (case difference only)
    protected int sides;  //Number of sides for this widget

    //Compiler complains of Non-CLR Compliance (non-private name with underscore
    // is not compliant)
    protected int _hooks; //Number of hooks on this widget

    //Compiler is happy with a trailing underscore
    protected int feathers_; //Number of feathers on this widget

    // Interface items
    public Sides { get { return sides; } } 
    public Hooks { get { return _hooks; } }
    public Feathers { get { return feathers_; } }
  }
}
=====================================
namespace MyLittleCompany.Widgety
{
  public class SmallWidgetInformation : MlcWidgetInformation 
  {
    public SmallWidgetInformation()
    {
      // Is this a smell? As in "What are these things?"
      sides = 6;
      _hooks = 3;
      feathers_ = 1;
     }
  }
}
4

2 に答える 2

2

抽象クラスで保護されたフィールドを作成することは絶対に認められています。

命名規則は単なるガイドラインであり、使用しているスタイリング ツールによって異なります。あなたやあなたのチームが好むスタイルを使用し、そこからツールをカスタマイズします。最も重要なことは、プロジェクト自体が一貫していることです。

個人的には、末尾のアンダースコアが使用されているのを見たことがありませんが、その利点はわかります。保護されたフィールドを表示するかなりスマートな方法かもしれません。それを使用しているチームに遭遇した場合、私は間違いなくその規則を承認します.

于 2015-07-09T16:49:26.700 に答える