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

Question

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

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

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

над чем-то вроде этого:

void display() {
    cout << data;
}

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Ваше здоровье !

Answer 4

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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