Объясните пожалуйста, нужно ли и зачем (действительно важные случаи) писать код таким образом, чтобы у "пользователя" не было доступа к членам класса и он мог обращаться к ним только через методы???
Об этом часто пишут в книгах, например у Дж.Либерти. что вот, мол, надо чтобы пользователь имел доступ к закрытым членам только через методы, а то "нарушается защита данных и концепция ООП, поэтому лучше не делать члены открытыми а писать private или protected".

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

Объясните пожалуйста.

Ваш код может быть импользован другим программистом(да и вам самим), для вас он будет клиентом. Вот от него и надо защищать внутреннюю инфраструктуру класса. Она ему не нужна.

это как минимум помогает в отладке Вашего приложения. Вы можете отслеживать когда идет доступ к Вашим данным. Кроме того конечный пользователь можжет неправильно истоковать открытый член класса... ну например:

представим что пользователь уже когда-то вычислял GetTotalPrice(), потом он меняет qty, и ожидает что GetTotalPrice() вернет ему новое значение... только этого не происходит... это непонятно.

вот и я говорил только что об этом. Одни общие слова, ни чего конкретного. Зачем мне от самого себя защищать? зачем от программиста защищать? чтобы соблюдать догмы ? тогда это ни разу  не причина.

Добавлено через 1 минуту и 8 секунд

поясните пожалуйста. ( или это вопрос к кому-то?)

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

это не вопрос. это баг, вызванный ошибкой кеша. если будут методы set\get , то такое просто избежать (сбрасывая флаг "кешировано"). в случае прямого доступа к данным такого нельзя сделать.

Поимеете опыт, тогда поймете.

Чтобы потом проблем с сапортом не иметь.

Чтобы продуктивнее работать.

Суть в том, что в интерфейсе должно быть только то что нужно для работы подсистемы/класса. Всё остальное детали реализации и знать о них никому не надо(на уровне кода конечно). Вы меняете реализацию, но оставляете интерфейс и поведение, что происходит? Правильно, клиентский код работает как и раньше, а вы уже приступили к следующей задаче.

Слово "защищать" не очень подходит, лучше слово "скрывать".  "От самого себя" тоже не верное словосочетание. 
В ООП нет как такового понятия "программист" .  Есть понятия "объект" и "взаимодействие". 
1.   Каждый объект должен максимально полно  и эффективно  выполнять возложенные на него обязанности, т.е должен иметь эффективную реализацию. Как он это делает никому(другим объектам) знать не нужно, поэтому вся внутренняя логика работы (реализация)  должна быть скрыта. Это поможет избежать ненужных связей и  скрытых непредвиденных эффектов.
2.  Каждый объект должен максимально удобно взаимодействовать с другими объектами, т.е предоставлять удобный интерфейс. Естественно интерфейс является открытым для других объектов.

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

П.С. Хочу заметить что есть и другие подходы(стратегии) помимо ООП, например процедурное, функциональное  или аспектное программированние,
у каждого из которых есть свои преимущества и недостатки. Но для успешного воплощения стратегии , язык программирования должен поддерживать ее.
Раз выбрали С++, то надо учитывать, что ориентирован он на ООП.   




Это сообщение отредактировал(а) mes - 12.10.2008, 15:17

Инкапсуляция

я не пытаюсь противоречить ООП, я пытаюсь понять "зачем нужно это и это". А в ответ получаю "наберетесь опыта - узнаете."

Ну если вы не можете этого понять на основе имеющейся теории, тогда поймете на основе своей практики.

для удобства - чтоб достичь цели с наименьшими затратами.

Добавлено через 9 минут и 9 секунд




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

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

Повторю то, что уже сказали Daevaorn и Fazil6... Есть понятие интерфейс - набор доступных всем методов и свойств объекта. Как работают эти методы и как используются свойства - не важно. Важно что они делают.
Например, есть такой стандартный класс string (#include <string>). У него есть куча всяких методов (begin(), end(), operator[], empty(), resize(), data(), c_str() и пр.), при этом ты и понятия не имеешь, как они все работают, и в каком виде хранятся данные. Ведь можно реализовать этот класс через один указатель на строку (char*), можно через 2 (указатель на начало строки и на ее конец), можно через 3 (начало, конец, конец буфера), а можно через указатель и одно(два) целых числа (указатель на строку, (размер зарезервированный области) и количество символов в строке). Вот видишь сколько вариантов реализации? А теперь скажи, как бы все программы работали под разными реализациями STL, если бы данные свойства класса были публичными? Тут получается или все реализуют одинаково (ограничивает возможности оптимизации), или одна версия несовместима с другой.

спасибо, вот этот пример я почему-то понял лучше остальных.