используя аксессоры в одном классе

Question

Я слышал, что в C ++ использование метода доступа (get...()) в функции-члене того же класса, где был определен метод доступа, является хорошей практикой программирования? Это правда и нужно ли это делать?

Например, является ли это предпочтительным:

void display() {
    cout << getData();
}

примерно так:

void display() {
    cout << data;
}

data - это элемент данных того же класса, в котором был определен метод доступа ... то же самое с методом display().

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

Answer 1

Причина этого в том, что если вы измените реализацию getData(), вам не придется изменять остальную часть кода, который напрямую обращается к data.

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

Answer 2

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

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

Однако я не лучший ребенок богов на этой планете. Иногда я обманываю;) Когда вы в классе владельца, я думаю, что можно получить доступ к личным данным напрямую. Это может даже оказаться полезным, поскольку вы автоматически знаете, что изменяете фактический класс, в котором находитесь. Учитывая, что у вас есть какое-то соглашение об именах, которое фактически говорит вам об этом, например имя некоторой переменной с подчеркиванием в конце: "someVariable _".

Ура!

Answer 3

Это зависит. Использование функции доступа обеспечивает уровень абстракции, который может сделать будущие изменения в «данных» менее болезненными. Например, если вы хотите лениво вычислить значение «data», вы можете скрыть это вычисление в функции доступа.

Что касается накладных расходов - если вы имеете в виду снижение производительности, то оно, вероятно, будет незначительным - ваши средства доступа почти наверняка будут встроены. Если вы имеете в виду накладные расходы на кодирование, то да, это компромисс, и вам придется решить, стоит ли это дополнительных усилий для предоставления средств доступа.

Лично я не думаю, что в большинстве случаев это того стоит.

Answer 4

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

Answer 5

Полагаю, это зависит от того, что вы в конечном итоге можете сделать со своим членом данных.

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

Answer 6

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

Answer 7

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

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