6

「従来の」C++クラス（いくつかのランダムな宣言）は、次のようになります。

class Foo
{
public:
  Foo();
  explicit Foo(const std::string&);
  ~Foo();

  enum FooState
  {
    Idle, Busy, Unknown
  };

  FooState GetState() const;
  bool GetBar() const;
  void SetBaz(int);

private:
  struct FooPartialImpl;

  void HelperFunction1();
  void HelperFunction2();
  void HelperFunction3();

  FooPartialImpl* m_impl; // smart ptr
  FooState m_state;
  bool m_bar;
  int m_baz;
};

このタイプのアクセスレベルの仕様は、元のプログラマーが自分の「アクセス領域」をきちんと整理していなければ、醜くて従うのが難しいといつも思っていました。

Java / C＃スタイルの同じスニペットを見ると、次のようになります。

class Foo
{
  public: Foo();
  public: explicit Foo(const std::string&);
  public: ~Foo();

  public: enum FooState
  {
    Idle, Busy, Unknown
  };

  public: FooState GetState() const;
  public: bool GetBar() const;
  public: void SetBaz(int);

  private: struct FooPartialImpl;

  private: void HelperFunction1();
  private: void HelperFunction2();
  private: void HelperFunction3();

  private: FooPartialImpl* m_impl; // smart ptr
  private: FooState m_state;
  private: bool m_bar;
  private: int m_baz;
};

私の意見では、アクセス指定子はターゲットのすぐ隣にあり、行の束ではないため、これはヘッダーではるかに読みやすくなっています。これは、通常の「* .hpp/*。inl」ペアに分離されていないヘッダーのみのテンプレートコードを使用する場合に特に当てはまります。そのシナリオでは、関数の実装のサイズがこの小さいが重要な情報を圧倒しました。

私の質問は単純で、他の誰かがC++コードでこれを積極的に行っているのを見たことがないという事実から生じています。

「クラスビュー」対応のIDEがないと仮定すると、このレベルの冗長性を使用することの明らかな欠点はありますか？

他のスタイルの推奨事項は大歓迎です！

4

5 に答える 5

10

「ローマにいるときは、ローマ人と同じようにしてください。」

私は、すべてのフィールドとメソッドに個別にアクセス指定子を指定するスタイルのように、Javaで多くの時間を過ごしました。ただし、C ++でプログラミングしているときは、最初のコードスニペットに示されているスタイルを常に使用します。

于 2010-04-11T05:56:38.170 に答える
5

個人的には、すべてのシンボルにアクセス修飾子を指定しなければならないのは非常に面倒です。それは物事を読みにくくし、簡単ではなく、クラス定義全体でプライベートなものとパブリックなものを自由に混ぜるという非常に悪い習慣を助長します。私はいつもこの種の混乱を目にします。C＃では、などを使用してこれを軽減しようとしています。これにより#region private、将来のメンテナが物事をクリーンに保つことができれば幸いです。

于 2010-04-11T05:42:36.057 に答える
1

あなたは眉を上げるでしょうが、それは何も悪いことではありません。アクセス指定子を分離しておくことの主な利点は、すべてのプライベートメンバーとメソッドをクラスの最上位に配置することを奨励することです。

クラスが大きすぎて1つの画面いっぱいに収まらない場合は、おそらく複数のクラスに分割するか、実装をクラスから移動して、暗黙的にインライン関数を明示的にインラインで宣言する必要があります。

于 2010-04-11T05:42:39.683 に答える
0

後者のアプローチの欠点は、ほとんど行われないことです。この方法で他の開発者を驚かすことはお勧めできません。また、アクセス修飾子を100万回入力する必要があります。従来のアプローチを使用すると、修飾子を何度も何度も入力する必要がなくなり、予想されるアプローチでもあります。

于 2010-04-11T05:54:51.137 に答える
0

確かに、意味的には違いはありませんが、受け入れられたものに従うだけで、自分自身と同僚に大きな恩恵をもたらすでしょう。

個人的に私は私のクラスが好きです：

struct S {
    S(int m) : m(m) { }
    S(const S& o);
    S& operator=(const S& o);

    void f() const;
    std::string g();

private:
    void help();

private:
    int m;
};

しかし、厳密に自分のものではないリポジトリにコミットする場合は、2回考えずにマナーを変更します。これは、誰かが私の習慣に従ってコードをリポジトリにコミットする場合にどれほど感謝するかを知っているからです。

于 2010-04-11T07:53:55.150 に答える