Поскольку вы говорите, что знаете теорию, а другие ответы копались в значении общедоступных/частных, геттеров и сеттеров, я хотел бы сосредоточиться на том, почему использовать аксессоры вместо создания общедоступных атрибутов (данные-члены в С++) .
Представьте, что у вас есть класс Truck в логистическом проекте:
class Truck {
public:
double capacity;
// lots of more things...
};
Если вы из Северной Америки, вы, вероятно, будете использовать галлоны для представления вместимости ваших грузовиков. Представьте, что ваш проект закончен, он отлично работает, хотя и сделано много прямых применений Truck::capacity. На самом деле, ваш проект становится успешным, поэтому какая-то европейская фирма просит вас адаптировать ваш проект к ним; к сожалению, проект теперь должен использовать метрическую систему, поэтому для емкости следует использовать литры вместо галлонов.
Теперь это может быть беспорядок. Конечно, одной из возможностей было бы подготовить кодовую базу только для Северной Америки и кодовую базу только для Европы. Но это означает, что исправления ошибок должны применяться в двух разных источниках кода, а это считается невыполнимым.
Решение состоит в том, чтобы создать возможность конфигурации в вашем проекте. Пользователь должен иметь возможность устанавливать галлоны или литры, а не фиксированный, жестко заданный выбор галлонов.
С подходом, показанным выше, это будет означать много работы, вам придется отслеживать все случаи использования Truck::capacity и решать, что с ними делать. Это, вероятно, будет означать изменение файлов по всей кодовой базе. Предположим, в качестве альтернативы, что вы выбрали более theoretic подход.
class Truck {
public:
double getCapacity() const
{ return capacity; }
// lots of more things...
private:
double capacity;
};
Возможное альтернативное изменение не требует модификации интерфейса класса:
class Truck {
public:
double getCapacity() const
{ if ( Configuration::Measure == Gallons ) {
return capacity;
} else {
return ( capacity * 3.78 );
}
}
// lots of more things...
private:
double capacity;
};
(Пожалуйста, примите во внимание, что есть много способов сделать это, это только один вариант, и это только пример)
Вам нужно будет создать глобальную конфигурацию служебного класса (но вы все равно должны были это сделать) и добавить включение в truck.h для configuration.h, но это все локальные изменения, остальная часть вашей кодовой базы остается неизменной, что позволяет избежать потенциальных ошибок.
Наконец, вы также заявляете, что сейчас работаете над большим проектом, и я думаю, что это та область, в которой эти причины на самом деле имеют больше смысла. Помните, что при работе над крупными проектами нужно помнить о создании кода, который можно обслуживать, т. е. кода, который можно исправить и дополнить новыми функциями. Вы можете забыть о геттерах и сеттерах в личных, небольших проектах, хотя я постараюсь привыкнуть к ним.
Надеюсь это поможет.
person
Baltasarq
schedule
18.01.2013
