Детализация спецификатора доступа к классу C ++ - PullRequest
Новая
       14

Детализация спецификатора доступа к классу C ++

6 голосов
/ 11 апреля 2010

«Традиционный» класс 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 с поддержкой "Class View", есть ли какие-либо очевидные недостатки использования этого уровня многословия?

Любые другие рекомендации по стилю приветствуются!

Ответы [ 5 ]

10 голосов
/ 11 апреля 2010

«Когда в Риме, делай, как римляне».

Мне, потратив много времени на Java, нравится стиль указания спецификаторов доступа для каждого поля и метода в отдельности. Однако когда я программирую на C ++, я всегда использую стиль, показанный в вашем первом фрагменте кода.

5 голосов
/ 11 апреля 2010

Лично меня очень раздражает необходимость указывать квалификатор доступа для каждого символа. Это усложняет чтение, а не облегчает и поощряет очень дурную привычку свободно смешивать личные и публичные вещи по всему определению класса. Я вижу этот беспорядок все время. В C # я пытаюсь смягчить это с помощью #region private и т. Д., Что, мы надеемся, побудит будущих сопровождающих держать вещи в чистоте.

1 голос
/ 11 апреля 2010

В этом нет ничего плохого, хотя вы поднимите брови. Основное преимущество разделения спецификаторов доступа состоит в том, что он поощряет размещение всех закрытых членов и методов в верхней части класса - вместе.

Если ваш класс слишком велик, чтобы уместиться на одном экране, чем, вероятно, его следует разбить на более чем один класс, и / или любые неявно встроенные функции должны быть явно объявлены как встроенные с удалением реализации из класса.

0 голосов
/ 11 апреля 2010

Действительно, семантически это не имеет значения, но вы окажете большую помощь себе и своим коллегам, если будете просто следовать тому, что принято.

Лично мне нравится мой класс так: 

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;
};

Но я поменяю свои манеры, недолго думая, если сделаю репозиторий, который не является строго моим, потому что я знаю, насколько я был бы благодарен, если бы кто-то передал их код в мои репозитории, следуя моим обычаям.

0 голосов
/ 11 апреля 2010

Недостаток последнего подхода заключается в том, что это делается редко, и не стоит удивлять других разработчиков таким образом, и он требует, чтобы модификатор доступа вводился миллион раз. Использование традиционного подхода избавит от необходимости набирать модификатор снова и снова, а также является ожидаемым подходом.

...