Лучшая практика: упорядочивание общедоступного / защищенного / частного в определении класса?

В Чистом коде Роберт К. Мартин советует программистам всегда помещайте переменные-члены в начало класса (сначала константы, затем частные члены), а методы должны быть упорядочены таким образом, чтобы они читались как история, которая не заставляет читателя слишком много прыгать по коду . Это более разумный способ организации кода, чем с помощью модификатора доступа.

Лучше всего быть последовательным.

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

Мое объяснение для размещения public методов вверху состоит в том, что они определяют интерфейс для вашего класса, поэтому любой, кто просматривает ваш файл заголовка, должен иметь возможность немедленно увидеть эту информацию.

В общем, члены private и protected менее важны для большинства людей, просматривающих файл заголовка, если только они не рассматривают возможность изменения внутренних компонентов класса. Хранение их «в стороне» гарантирует, что эта информация сохраняется только на основании необходимости знать, что является одним из наиболее важных аспектов инкапсуляции.

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

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

Я думаю, что у меня другая философия по этому поводу, чем у большинства. Я предпочитаю группировать связанные элементы вместе. Я терпеть не могу прыгать, чтобы работать с классом. Код должен течь, и использование довольно искусственного упорядочения, основанного на доступности (общедоступный, частный, защищенный и т. Д.) Или экземпляр против статического или член против свойства против функции, не помогает поддерживать хороший поток. Поэтому, если я создаю общедоступный метод Method, который реализуется частными вспомогательными методами HelperMethodA, HelperMethodB и т. Д., То вместо того, чтобы размещать эти методы далеко друг от друга в файле, я буду держать их близко друг к другу. Точно так же, если у меня есть метод экземпляра, который реализован статическим методом, я тоже сгруппирую их вместе.

Так что мои занятия часто выглядят так:

class MyClass {
    public string Method(int a) {
        return HelperMethodA(a) + HelperMethodB(this.SomeStringMember);
    }

    string HelperMethodA(int a) { // returns some string }

    string HelperMethodB(string s) { // returns some string }

    public bool Equals(MyClass other) { return MyClass.Equals(this, other); }

    public static bool Equals(MyClass left, MyClass right) { // return some bool }

    public double SomeCalculation(double x, double y) {
        if(x < 0) throw new ArgumentOutOfRangeException("x");
        return DoSomeCalculation(x, y); 
    }

    const double aConstant;
    const double anotherConstant;
    double DoSomeCalculation(double x, double y) {
        return Math.Pow(aConstant, x) * Math.Sin(y) 
            + this.SomeDoubleMember * anotherConstant;
    }       
}

Это будет мой заказ

1. Статические переменные
2. Статические методы
3. Публичные переменные
4. Защищенные переменные
5. Частные переменные
6. Конструкторы
7. Публичные методы
8. Защищенные методы
9. Частные методы

Я использую следующие правила:

• статика прежде всего
• переменные перед конструкторами перед методами (я считаю, что конструкторы относятся к категории методов)
• публичный, прежде чем защищенный, прежде чем частный

Идея состоит в том, что вы определяете объект (данные) до поведения (методов). Статику нужно разделять, потому что на самом деле они не являются частью объекта или его поведения.

Раньше я очень заботился. За последние несколько лет при использовании современных IDE практически все можно получить всего в 1 или 2 нажатия клавиши, я позволил своим стандартам существенно ослабить. Теперь я начинаю со статики, переменных-членов, затем конструкторов, после чего я особо не беспокоюсь об этом.

В C # я позволяю Resharper организовать все автоматически.

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

Хотя я иногда группирую членов группы (получатели и сеттеры), я обычно предпочитаю перечислять членов внутри группы БУКВЕННО, чтобы их было легче найти.

Мне также нравится выстраивать данные / функции по вертикали. Я делаю табуляцию / пробел вправо достаточно, чтобы все имена были выровнены в одном столбце.

Каждому свое, и, как говорит Эльзо, современные IDE упростили поиск участников и их модификаторов с помощью цветных значков в раскрывающихся меню и т. Д.

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

Итак, если это синглтон, я сначала ставлю семантику (статический класс getInstance ()).

Если это конкретная фабрика, я сначала помещаю функцию getNew () и функции регистрации / инициализации.

... и так далее. Когда я говорю «первый», я имею в виду вскоре после c'tors и d'tor - поскольку они являются способом создания экземпляра любого класса по умолчанию.

Следующие ниже функции находятся в:

1. логический порядок вызова (например, initialize (), preProcess (), process (), postProcess ()) или
2. связанные функции вместе (например, аксессоры, утилиты, манипуляторы и т. д.),

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

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

Последовательность публичных, за которыми следуют защищенные и частные, для меня более читабельна. Лучше просто описать логику класса в комментариях в верхней части файла заголовка и упорядочить вызовы функций, чтобы понять, какая доза класса и алгоритмы используются внутри.

Я использую Qt c ++ какое-то время и вижу некоторые новые ключевые слова, такие как signal и slot. Я предпочитаю продолжать упорядочивать, как указано выше, и делюсь своей идеей с вами здесь.

#ifndef TEMPLATE_H
#define TEMPLATE_H


class ClassName
{
    Q_OBJECT
    Q_PROPERTY(qreal startValue READ startValue WRITE setStartValue)
    Q_ENUMS(MyEnum)

public:

    enum MyEnum {
        Hello = 0x0,
        World = 0x1
    };

    // constructors

    explicit ClassName(QObject *parent = Q_NULLPTR);
    ~ClassName();

    // getter and setters of member variables

    // public functions (normal & virtual) -> orderby logic

public slots:

signals:

protected:

    // protected functions it's rule followed like public functions


private slots:

private:

    // methods

    // members

};

#endif // TEMPLATE_H