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

Ответ 1

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

Ответ 2

Лучшей практикой является быть последовательным.

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

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

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

Ответ 3

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

Ответ 4

Я думаю, что у меня другая философия, чем у большинства. Я предпочитаю группировать связанные элементы вместе. Я не могу стоять, чтобы прыгать, чтобы работать с классом. Код должен протекать и использовать довольно искусственный порядок, основанный на доступности (публичный, закрытый, защищенный и т.д.), Или экземпляр против статичности или функции member versus property или не помогает сохранить хороший поток. Поэтому, если у меня есть открытый метод 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;
    }       
}

Ответ 5

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

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

Ответ 6

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

• Статические переменные
• Статические методы
• Общие переменные
• Защищенные переменные
• Частные переменные
• Конструкторы
• Общие методы
• Защищенные методы
• Частные методы

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Если это конкретный factory, я сначала положил функцию getNew() и функции register/initialize.

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

Далее следуют следующие функции:

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

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

Ответ 9

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

Ответ 10

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

Я использую Qt С++ некоторое время и вижу несколько новых типов ключевых слов, таких как 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 rule followed like public functions


private slots:

private:

    // methods

    // members

};

#endif // TEMPLATE_H