SarinВ чём полезность этих директив?
Примерно в том же, в чем полезность стен между комнатами, кухней, туалетом...

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

SarinИ, во-вторых, не кажится ли вам, что, например, подход питона практичней и универсальней?
Питона не знаю.

SarinВ питоне у объектов есть специальные имена методов.
Хм. Уже не нравится. Дай угадаю - это интерпретатор?

Sarin def __setattr__(self, attname, attvalue):
if attname == "private": raise AttributeError, "Try to acess to private value!"
self.__dict__[attname] = attvalue
Хм. То есть в нормальном случае получается длинный switch из реакций на разные имена свойств?

Боюсь, я не очень понял, какое это имеет отношение к инкапсуляции. В любом случае, не отличается от


- итого, можно везде писать таким образом.

SarinДа. Интерпретатор. Мне тоже долго не нравился такой подход. Коробило отсутствие private, public и protected.
Вопрос не в этом. Меня коробит от "есть специальный метод с предопределенным именем".

SarinНо вот код на питоне:

Лучше ли он? Уж и не знаю. Мне кажется да.
Лично меня в первую очередь ужасает его производительность.

SarinНапример представте себе ситауацию, что в данном примерепридётся ввести ещё одну переменную с такими же ограничениями. Я добывлю строчку. А вы сколько?:)
Если захочу идти этим путем, столько же. Неужели Вы полагаете, что


чем-то отличается от

SarinПроизводительность питона сопоставима с явой.
В первую очередь я бы не стал называть Яву образцом производительности, хотя это вопрос в основном к ее библиотекам. Более существенно же - это не значит, что плохая программа на Питоне будет быстро работать.

Полагаю, я показал Вам, что такой подход легко реализуется на дельфе. Также нет проблем сделать на плюсах, переопределив оператор []. На яве - можно, но может быть не так синтаксически просто. И, полагаю, Вы понимаете, почему этот подход будет заведомо медленнее простого геттера-сеттера.

Преимуществ в этом подходе я по-прежнему не вижу - чистой воды изобретение велосипеда. Там, где нужны индексированные свойства, их можно и нужно применять. Там, где нужны уникальные - применяем их. Там, где нужны private, применяем их, не притягивая за уши индексированные свойства. Имхо так.

А вот теперь - раз уж Вы подняли эту тему - мне хотелось бы увидеть пример, как в этой технологии будет выглядеть работа с реальными свойствами. Например, следующий простой набор:


Дополнительно: при изменении Min/Max/Width следует проверить условие для Pos, и если оно перестало выполняться, увеличить либо уменьшить Pos так, чтобы попасть в допустимый диапазон.

lockyиногда хочется не перекрыть, а тупо вызвать protected метод...
А какие проблемы-то? Вот с private - не пройдет. Но нормальные люди в private упаковывают то, что действительно лучше не показывать наружу.

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

NotGonnaGetUsПозволяя кому-либо получить доступ к этим данным, мы жестко связываем интерфейс класса и то, как он реализуется.
Хм. При том, что я согласен с Вами, это не есть хороший ответ на заданный вопрос. Практически Вы, как в известном анекдоте говорите: "..чем армян".

Sarin говорит следующее: а давайте уберем создаваемый компилятором забор и вместо этого все будем умными и сознательными людьми; если рядом с полем-методом стоит комментарий "внутреннее. не трогать", то будем пользоваться им только в самом крайнем случае.

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

NotGonnaGetUs
Всё равно остаётся необходимость различать "открытые и публикуемые методы"
Не соглашусь. Отметим, что это вопрос вкусов, неформализуемый. Такая "необходимость различать" очень похожа на оправдание дружественности (которая имхо не нужна). Это желание имхо возникает при черезчур мелком разбиении на классы; если "один правильный класс" разбивать на несколько взаимодействующих мелких, придется выносить в паблик то, что хотелось бы оставить в привате.

NotGonnaGetUs(с) Фаулер. Взять, н-р, паттерн стартегия. Классу стратегии требуется полный доступ к компонентам класса, который она обслуживает.
Хм. Почему это? Ему требуется доступ к интерфейсу класса, если я правильно помню этот паттерн. Поясните?

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

NotGonnaGetUsСогласитесь, тут есть некий парадокс: чем мельче кубики, тем легче их повторно использоваь,
Не соглашусь. С одной стороны, легче использовать каждый конкретный кубик, с другой стороны время решения задачи (aka построения дома) при черезчур мелких кубиках стремительно растет. Именно поэтому необходимо искать некий наиболее удачный промежуточный размер.

NotGonnaGetUsно при этом появляется и больше способов как их использовать не правильно.
Хм. "Использовать кубик неправильно" - имхо несколько бессмысленное словосочетание, приобретающее смысл только в неправильных кубиках.

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

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

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

NotGonnaGetUsИнтересным примером являются базы данных. В схеме определяются сущности, которым всё друг о друге известно, что позволяет строить какие угодно дикие select'ы и update'ы. И при этом никто не плачет и не жалуется, что инкапсуляции нет - все живы и здоровы.
Я бы не сказал, что Вы правы :) В БД используются подходящие для этой задачи формы инкапсуляции; наиболее существенно то, что схема сама по себе является синглтоном, обладающим вполне определенным интерфейсом (и определенными скрываемыми деталями реализации). По сравнению с "классическим ООП" введено интересное понятие "роль" - по сути, разным пользователям предоставляются разные интерфейсы к одному и тому же объекту. Кроме того, существует определенная иерархия инкапсуляции внутри объекта-схемы - скажем, таблица предоставляет свой интерфейс (поля, методы для запроса-изменения), но скрывает детали реализации (индексы, ограничения). Наконец, существует естественный уровень абстрагирования, интерфейсы "по имени" - скажем, я в любой момент могу переименовать таблицу, создать view с тем же именем, и все ранее табличные операции будут работать с этим view. Ну, пакеты предоставляют просто-таки классическую инкапсуляцию (и без них программировать уже.. очень тоскливо).

NotGonnaGetUsИ всё-таки есть объективные ситуации, когда ппп не хватает.
Безусловно, расширять в принципе можно до бесконечности. Это опять-таки задача поиска оптимума.

NotGonnaGetUsЕсли говорить о java, то помимо public и private, есть модификаторы protected (пакет + наследники) и default (пакет). Если требуется открыть доступ только наследникам класса, что вполне "правильное"(?) желание, то сделать этого не получится. Придётся открыться всему пакету.
Ну, это всего лишь дружественность, которую, с моей точки зрения, стоило бы выбросить и из дельфы, и из явы, и из плюсов. В яве, если мне не изменяет память, неприятно еще и отсутствие "наследования" пакетов. Если я решил взять пакет X.Y.Z и отрефакторить его на X.Y.Z.T1, X.Y.Z.T2 и X.Y.Z.T3, это запросто приведет к вороху ошибок недоступности.

NotGonnaGetUsДругой пример.
Хм. А зачем делать именно так? Я бы сказал, "метод insert переименовываем в _insert" - звучит чертовски необъектно, не находите?

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

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


Вроде бы многовато получилось :) Но - если нигде не ошибся в набранном прямо в форуме - корректное расширяемое взаимодействие. И обращаю внимание - это не единственный вариант; только "наиболее идеологично-паттерновый", который пришел мне в голову.

NotGonnaGetUsКлассу стратегии не "требуется" доступ к интерфейсу, он только к интерфейсу и имеет доступ (т.е. к открытым компонентам класса). Соответственно, если не прибегать к созданию _объекта посредника_ для передачи закрытых данных, то все необходимые компоненты класса должны быть открыты.
Я не понимаю, зачем здесь нужно "передачи закрытых данных". Вся суть этого паттерна - я бы его скорее назвал "Алгоритм" - в абстрагировании от закрытых данных обрабатываемого объекта.

NotGonnaGetUsКласс (контекст) для которого создаются стратегии и стратегии на самом деле "один правильный класс",
Не согласен. Например, можно сделать класс "алгоритм сортировки", работающий с интерфейсом типа [getCount();compare(int,int)]. И после этого можно сделать стратегию "Сортировка", параметризуемую алгоритмом и коллекцией Comparable объектов. Решительно не вижу, где здесь "один правильный класс" из объединения этих объектов.