Anatoly MoskovskyЭто называется инкапсуляция о, я долго ждал эту тему. (+пятница)
у меня такой вопрос: нужна ли инкапсуляция 100%?
моё мнение: инкапсуляция нужна только там, где требуется валидировать входящие(иногда исходящие) значения, используя информацию самого объекта.
Иначе, класс превращается в монстра, у которого на 1 переменную 8 строчек кода. Читать и отлаживать такой код - убийство. А с интерфейсами - убийство в квадрате.
Надо придерживаться принципа минимализма, и вообще, касаемо инкапсуляции: чтение многих книжек и повторение вслух написанного там, не делает человека программистом и не отменяет надобности постоянного анализа и наличия головы.
Дальше я буду говорить ересь: принцип минимализма, если переменная 1 раз где-то на старте устанавливается, а потом только читается - надо сделать её открытой, у меня, например, это строковые идентификаторы, признаки, частные свойства, определяемые на старте, и, частично, вектора базовых функциональных объектов. Меня будут ругать, что "вооот, это может тогда кто угодно переписаааать...". Да, может. Это называется "выстрелить себе в ногу", да, но моё мнение: это всё упирается в умение пользоваться кодом и понимать архитектуру. Для меня гораздо удобнее напрямую обращаться к вектору в объекте, чем звать геттер, который будет: 1. усложнять читаемость, 2. добавлять (мелкие, но всё же) тормоза в код. Тормоза, с другой стороны, начинают сказываться, когда у вас в аксессорах довольно большая валидация, которая и не всегда нужна-то, но вы перестаёте её замечать, так как этот код скрыт. Тут даже не знаю, как быть, палка о двух концах... на ранних этапах разработки можно это сразу как-то исправить. Наверно.
Кроме того, наличие сеттеров точно так же даёт возможность пострелять себе по ноге. При этом проблема отлова кода, который меняет переменную, имеет одинаковую сложность что при сеттерах, что при прямом доступе. Разве что брек-поинт будет в одном месте. И я готов этим пожертвовать ради читаемости и простоты кода. Чем меньше кода, чем он более модульный - тем меньше таких проблем.
В той же отладке, если я где-то проверяю переменные объекта, в случае геттера, мне надо провалиться в геттер(это если там просто указатель или объект...) и там посмотреть значение переменной vs просто сразу её увидеть.
__declspec(property) меня тоже не устраивает, потому что это получается: 1. этажерка в хедере 2. дополнительная гетаница путаница в коде.

Ещё одна печаль с аксессорами: это их общепринятая форма написания: Get/Set(Entity), сначала глагол, потом свойство. Как так при повальном ООП получилось, янипанимаю!.. Т.о. когда, к примеру, intellisence тебе выдаёт список, или ты сам тыкаешь в комбо с методами: после первых трёх букв, тебе ещё там надо покопаться, или понабирать дальше. Кроме того, визуально ты сначала видишь первые буквы, потом вчитываешься в остальные. Искать по первым буквам удобнее, чем по средним. У себя во внутренних проектах я в именах использовал сначала центральную Entity, потом, если надо, идёт(ут) уточнение(я) в порядке иерархии, и в конце идёт глагол (Get/Set/Reset/Backup/....). Во-первых, искать быстро, во-вторых, в первые же миллисекунды видно, с чем я работаю, в третьих видно в intellisence, какие действия свойство для себя допускает (Get/Set/Reset/Backup/....), что при обычном написании, когда глагол идёт вначале, практически невозможно, во-первых, из-за порядка, во-вторых, из-за неравномерности, при поиске итемы с Get/Set занимают обычно процентов 60-80 всех методов, а у меня всё равномерно распределено по именам свойств. Но, увы, я такой один

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

А как у вас с инкапсуляцией по пятницам?

Dimitry SibiryakovИменно поэтому в борланде изобрели property.я вот тут подумал...
Если кому надо, можно просто написать шаблон(+макрос?), который будет неявно обрабатывать запись/чтение в параметр. Сейчас shared_ptr используем, например, и нормально. Просто добавится ещё один шаблон сверху.
Плюсы:
- Кода меньше: если обработчик не нужен, он не создаётся. Не надо заводить отдельные property
- "Инкапсуляция" искаробки.
Минусы:
- Посмотреть значение под дебагом будет сложно так же, как в случае с аксессорами
- Слегка теряется прозрачность кода

я уже даже так делал, где-то тут писал про систему параметров+GUI+события+сериализация. Но у меня там только не было пользовательских обработчиков -_-

alex_kконстантой!!! :)она читается из настроек
alex_kЕсли вы пишите код, с которым будете работать только вы, значит вы пишете никому не нужный код :) Это так, мысль в сторону, ни к кому конкретно.О_о
а я код потом компилю, и у меня получаются ехе-шники, которые используются другими людьми
alex_kУ класса может быть геттер без сеттера. В своих кишках класс будет копаться своими алгоритмами, другим до этого дела нет.да, но, imho, геттер, просто возвращающий значение, не нужен. Меня задалбывает страшно, когда надо просмотреть работу, например, одного условия, и приходится пройти по двум макросам и внутри их по пять геттеров, потому что шибко умные программисты сделали всё, как надо. Открыть сам объект и найти нужные значения по имени тоже не представляется простым, потому что:
1. иерархия
2. чёрдовы проперти со своими другими названиями
alex_kЕсли кто то реализует алгоритм, который работает с членами класса напрямую, этот алгоритм может быть реализован как метод класса. И, наверное, это будет нагляднее и понятнее?да, только так. Против этого я ничего и не говорил.
alex_kА голый доступ к членам класса, это большой соблазн написать алгоритм там, где он нужен "прямо сейчас". А это может привести к дублированию кода(ужас!) и/или к непоняткам при поддержкеИстинный программианин не должен соблазняться голым доступом для осуществления грешных помыслов

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