Здравствуйте, tarkil, Вы писали:

WH>>Ну может тогда вобще отменим модификаторы доступа и пусть все будет публичным?
T>Автор, не богохульствуй!
А я то тут причем? Этот ты Andrei N.Sobchuck скажи. Я прекрасно понимаю зачем нужны модификаторы доступа.

Здравствуйте, WolfHound, Вы писали:

T>>Автор, не богохульствуй!
WH>А я то тут причем? Этот ты Andrei N.Sobchuck скажи. Я прекрасно понимаю зачем нужны модификаторы доступа.

Нет, ну как тебе даже мысль могла придти в голову, сделать всё публичным?! Я в шоке... надо выпить чаю.

Sinclair wrote:

> Здравствуйте, Andrei N.Sobchuck, Вы писали:
>
> ANS>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая?
> Я рекомендую тебе воспользоваться поиском. Вопрос о модификаторах доступа здесь уже досконально обсасывался. Специально для тебя повторю главную тему: инкапсуляция = возможность предоставлять контролируемый контракт потребителям. Для потребителей в различных, скажем так, зонах, можно предоставлять различные контракты.
> То, что это необходимо — очевидно.

Обрати внимание — эти правильные слегка общие фразы не кореллируют
непосредственно с указанным способом котроля — public/protected/private.
Более того, такой подход достаточно ущербен.
Если обратиться к азам ООП, то видно, что про контроль поведения ничего
не говорится, а говорится только про инкапсуляцию данных. Поэтому все
данные должны быть приватными, а методы как хочется — это уже будет
высокоуровневой надстройкой конкретной реализации ООП.

В плане развития надстроек можно условно выделить две тенденции —
ограничивающую и непринуждающую.
Первый случай, это наличие ограничений, которые не могут быть
проигнорированы — final, throws, private, жестко прописанные типы и т.д.
Второй случай, это наличие нежестких или более свободных ограничений.
Например, шаблоны C++ vs generics C#, латентная типизация, отсутствие
final, throws, private.
Теперь рассмотрим какие непреодолимые ограничения возникают при
необходимости доступа к поведению с различными модификаторами:
1) private — совсем ничего не сделаешь
2) protected — нужно наследоваться
3) package local — нужно быть объявленным в том же пакете
Первый случай является абсолютно параноидальным, ни разу не возникло
желания им воспользоваться, а когда натыкался, были одни проблемы.
Второй и третий задают ограничение по структуре. Нужно либо быть
потомком данного класса, т.е. выступать в той же роли и поддерживать все
его интерфейсы (что может быть очень даже лишним). Либо находиться в том
же пакете, а значит являться частью некоторой подсистемы и иметь
назначение, заданное данным пакетом (что так же может быть камнем на шее
хорошего дизайна).

Так вот намного более перспективным, общим, полным и неограничивающим
подходом в контроле доступа является так называемый layered approach или
по-другому — субъекты, или еще по-другому — method/selector namespaces.
Идея простая — потребитель *сам* включает видимость/доступность тех или
иных частей системы. Получаются явно прописанные зависимости, которые
определяются исходя из роли каждого конкретного класса. Класс,
наделенный ролью УправлениеРюшками, будет явно включать namespace
СозданиеРюшек, получая доступ к якобы приватным методам других классов,
отвечающим за управление временем жизни Рюшек.

> ANS>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?

Нижеприведенные примеры ничего не говорят в пользу конкретно
protected/private.

> Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.
>
> Если мы сделаем конструктор приватным, то
> а) невозможно будет сделать фабрику отдельным классом. Потому, что ему тоже будет нельзя вызывать конструктор
> б) невозможно будет отнаследоваться от такого класса, т.к. потомок не сконструируется.
> Если мы сделаем конструктор публичным, то никакого контроля над созданием объекта не получится.
> Если мы распространим приватную область видимости на пределы модуля, то в него автоматически приедут все классы, связанные с одним из них.
>
> Простейшая штука номер два: параноидальный подход при конструировании класса требует проверять все приходяшие в методы значения на валидность. И кидать исключение, если что.
> При этом каждый вызов получает дополнительные накладные расходы.
> Уровень доступа "сборка" позволяет нам предоставить менее безопасный, но более производительный интерфейс ограниченному кругу потребителей. Причем, по удачному совпадению, это ровно тот круг потребителей, которые находятся под нашим контролем. Поэтому мы можем гарантировать валидность передаваемых параметров административными методами и статическим анализом кода.
>
> З.Ы.
> Тебя не удивляет, что в жизни все далеко не делится только на личное и общее? Ты даешь свой телефон друзьям, а ключ от квартиры любимой девушке. При этом посторонние не получат ни того, ни другого, хотя могут спокойно спросить у тебя "сколько времени". В программировании — то же самое.

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

T>Здравствуйте, WolfHound, Вы писали:

WH>>Ну может тогда вобще отменим модификаторы доступа и пусть все будет публичным?

T>Автор, не богохульствуй!

А, религия. Тогда без вариантов, конечно.

T>Пишу на досуге на PHP довольно тяжёлую программу. Очень интересный язык оказался. Но вот отсутствие явной спецификации типов и отсутствие приватных элементов (они появились в пятой версии) задалбывает.

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

Здравствуйте, Sinclair, Вы писали:

ANS>>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая?
S>Я рекомендую тебе воспользоваться поиском. Вопрос о модификаторах доступа здесь уже досконально обсасывался. Специально для тебя повторю главную тему: инкапсуляция = возможность предоставлять контролируемый контракт потребителям. Для потребителей в различных, скажем так, зонах, можно предоставлять различные контракты.

Разных "зон" это от 3х до 5ти? Такого примитивизма я не принимаю. Если хочется так предоставить контролируемы контракт, то возьми и предоставь его в смысле, объект, который пересылает разрешённые сообщения объекту. Вариантов тут поболее 5ти .

S>То, что это необходимо — очевидно.

Очевидность необходимости модификаторов мне не очевидна. Повторю вопрос: что они дают?
Вот есть инкапсуляция. Она, уменьшая связность, даёт гибкость. Есть пространства имён (классов). Они уменьшают количество коллизий этих имён. Вот есть модификаторы. Они дают... ???

ANS>>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
S>Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.

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

[...]

Здравствуйте, WolfHound, Вы писали:

WH>public — Публичный интерфейс класса.
WH>protected — Интерфейс класса доступный потомкам.
WH>internal — Интерфейс класса доступный внутри сборки.
WH>private — Детали реализации класса.

+ protected internal — Интерфейс класса доступный потомкам и внутри сборки.

Здравствуйте, tarkil, Вы писали:

T>Нет, ну как тебе даже мысль могла придти в голову, сделать всё публичным?! Я в шоке... надо выпить чаю.

Может лучше йаду?

Здравствуйте, _vovin, Вы писали:

_>Обрати внимание — эти правильные слегка общие фразы не кореллируют
_>непосредственно с указанным способом котроля — public/protected/private.
Да ну? Я, наверное, как-то сильно умно выражаюсь. Ок, разжуем помельче:
public: контракт, предоставляемый всем объектам
protected: контракт, предоставляемый объектам классов, унаследованных от данного
private: контракт, предоставляемый объектам данного класса.
Что, не прослеживается корреляции?
_>Более того, такой подход достаточно ущербен.
Очень интересно.
_>Если обратиться к азам ООП, то видно, что про контроль поведения ничего
_>не говорится, а говорится только про инкапсуляцию данных.
А можно мне эти азы точно указать? И где там сказано "ни в коем случае не скрывайте при помощи инкапсуляции поведение. Она только для состояния!"
_> Поэтому все данные должны быть приватными, а методы как хочется — это уже будет
_>высокоуровневой надстройкой конкретной реализации ООП.

_>В плане развития надстроек можно условно выделить две тенденции —
_>ограничивающую и непринуждающую.
_>Первый случай, это наличие ограничений, которые не могут быть
_>проигнорированы — final, throws, private, жестко прописанные типы и т.д.
_>Второй случай, это наличие нежестких или более свободных ограничений.
_>Например, шаблоны C++ vs generics C#, латентная типизация, отсутствие
_>final, throws, private.

_>Теперь рассмотрим какие непреодолимые ограничения возникают при
_>необходимости доступа к поведению с различными модификаторами:
_>1) private — совсем ничего не сделаешь
_>2) protected — нужно наследоваться
_>3) package local — нужно быть объявленным в том же пакете
_>Первый случай является абсолютно параноидальным, ни разу не возникло
_>желания им воспользоваться, а когда натыкался, были одни проблемы.
_>Второй и третий задают ограничение по структуре. Нужно либо быть
_>потомком данного класса, т.е. выступать в той же роли и поддерживать все
_>его интерфейсы (что может быть очень даже лишним). Либо находиться в том
_>же пакете, а значит являться частью некоторой подсистемы и иметь
_>назначение, заданное данным пакетом (что так же может быть камнем на шее
_>хорошего дизайна).

_>Так вот намного более перспективным, общим, полным и неограничивающим
_>подходом в контроле доступа является так называемый layered approach или
Никогда не встречал подобного применения термина layered approach. Обычно под ним понимают общее структурирование системы на слои, каждый из которых зависит только от нижележащего. Это позволяет минимизировать затраты на замену самого нижнего слоя, т.к. изменения гарантированно затронут только непосредственно зависящий от него слой.
_>по-другому — субъекты, или еще по-другому — method/selector namespaces.
_>Идея простая — потребитель *сам* включает видимость/доступность тех или
_>иных частей системы. Получаются явно прописанные зависимости, которые
_>определяются исходя из роли каждого конкретного класса.
_>Класс,
_>наделенный ролью УправлениеРюшками, будет явно включать namespace
_>СозданиеРюшек, получая доступ к якобы приватным методам других классов,
_>отвечающим за управление временем жизни Рюшек.
Отлично. Слоев тут нет ( (с) Шрек), зато есть ориентированность на потребителя. Как quickfix это должно действительно спасать. Но пока что я не вижу никакой причины для руления этого подхода в долгосрочной перспективе. Подход, где ограничения на потребителей задает производитель (назовем его классическим. Потому как в четырех из четырех мне известных ООП-платформ применяется именно он), выглядит менее демократичным. Но он, имхо, больше похож на реальность, где плодами трудов одного производителя пользуется множество потребителей. Поэтому производитель может себе позволить более высокую квалификацию, при которой принимаются правильные архитектурные решения. И требования к потребителям выдвигаются так, что они вынуждены следовать правильным решениям. От них заботливо убирают грабли, на которые можно наступить. Ты предлагаешь дать потребителям самим решать, чем им пользоваться, и пусть они отвечают за избыточные зависимости (которые не дадут им потом сделать upgrade на новую версию библиотеки), и за поддержание инвариантов.
_>Нижеприведенные примеры ничего не говорят в пользу конкретно
_>protected/private.
Это почему еще? Давай-ка прокомментируй.
>> Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.
>>
>> Если мы сделаем конструктор приватным, то
>> а) невозможно будет сделать фабрику отдельным классом. Потому, что ему тоже будет нельзя вызывать конструктор
>> б) невозможно будет отнаследоваться от такого класса, т.к. потомок не сконструируется.
>> Если мы сделаем конструктор публичным, то никакого контроля над созданием объекта не получится.
>> Если мы распространим приватную область видимости на пределы модуля, то в него автоматически приедут все классы, связанные с одним из них.
>>
>> Простейшая штука номер два: параноидальный подход при конструировании класса требует проверять все приходяшие в методы значения на валидность. И кидать исключение, если что.
>> При этом каждый вызов получает дополнительные накладные расходы.
>> Уровень доступа "сборка" позволяет нам предоставить менее безопасный, но более производительный интерфейс ограниченному кругу потребителей. Причем, по удачному совпадению, это ровно тот круг потребителей, которые находятся под нашим контролем. Поэтому мы можем гарантировать валидность передаваемых параметров административными методами и статическим анализом кода.

Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Разных "зон" это от 3х до 5ти? Такого примитивизма я не принимаю. Если хочется так предоставить контролируемы контракт, то возьми и предоставь его в смысле, объект, который пересылает разрешённые сообщения объекту. Вариантов тут поболее 5ти .
Этого я не понял. Наверное, туплю. Ты имеешь в виду динамическую проверку? Это уже Code Access Security и к областям видимости отношения не имеет.
ANS>Очевидность необходимости модификаторов мне не очевидна. Повторю вопрос: что они дают?
ANS>Вот есть инкапсуляция. Она, уменьшая связность, даёт гибкость. Есть пространства имён (классов). Они уменьшают количество коллизий этих имён. Вот есть модификаторы. Они дают... ???
Блин, я уже уставать начинаю. Может, будем читать сообщения? Эти модификаторы — и есть инкапсуляция. Они уменьшают связность и дают гибкость.
ANS>>>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
S>>Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.

ANS>(в следующем предложении, говоря "ты" я не имею ввиду именно тебя )
ANS>А я, как разработчик-пользователь твоей библиотеки, не хочу, что ты к чему-то меня принуждал, только потому, что ты считаеш себя умнее меня и предусмотрел все мои потребности.
Да нет проблем. Считаешь себя умнее меня — напиши свою библиотеку и объяви все public. Правла, при этом тебе придется контролировать корректность пользовательского кода самостоятельно, потому что гарантий ты предоставить уже не можешь. Ну, вот к примеру, если у нас созданием объектов рулит фабрика, то можно легко ее заменить на другую. А если конструктор объектов при этом публичный, то нет никакой гарантии, что после замены фабрики код будет корректным. В данном случае на большинстве применяемых ОО-языков ты сможешь обойтись банальным контекстным поиском, но в более интересных ситуациях тебе поможет только дорогостоящее тестирование.

ANS>[...]

Здравствуйте, VladD2, Вы писали:

VD>Может лучше йаду?

Лучше Йоду.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Так не нужно путать не-ОО язык, с языком в котором таки есть инкапсуляция (заметь нет ни слова о модификаторах доступа).

Если в PHP отсутствует инкапсуляция, то я не имею права сожалеть об этом, ссылаясь на некий из воздуха вытянутый постулат, дескать, "PHP не ООП-язык"? Это что ли подразумевалось?

Sinclair wrote:
> Здравствуйте, _vovin, Вы писали:
>
> _>Обрати внимание — эти правильные слегка общие фразы не кореллируют
> _>непосредственно с указанным способом котроля — public/protected/private.
> Да ну? Я, наверное, как-то сильно умно выражаюсь. Ок, разжуем помельче:
> public: контракт, предоставляемый всем объектам
> protected: контракт, предоставляемый объектам классов, унаследованных от данного
> private: контракт, предоставляемый объектам данного класса.
> Что, не прослеживается корреляции?

Бедный частный случай, а не изоморфизм.

> _>Более того, такой подход достаточно ущербен.
> Очень интересно.
> _>Если обратиться к азам ООП, то видно, что про контроль поведения ничего
> _>не говорится, а говорится только про инкапсуляцию данных.
> А можно мне эти азы точно указать? И где там сказано "ни в коем случае не скрывайте при помощи инкапсуляции поведение. Она только для состояния!"

Про поведение там просто *ничего не сказано*. Поэтому мимо. Т.е. с
поведением ты можешь делать все что тебе заблагорассудится, в том числе
и private/protected. Если очень нужны фиче-грабли.

> _>Так вот намного более перспективным, общим, полным и неограничивающим
> _>подходом в контроле доступа является так называемый layered approach или
> Никогда не встречал подобного применения термина layered approach. Обычно под ним понимают общее структурирование системы на слои, каждый из которых зависит только от нижележащего. Это позволяет минимизировать затраты на замену самого нижнего слоя, т.к. изменения гарантированно затронут только непосредственно зависящий от него слой.

О, значит тебе осталася совсем маленький переход для понимания связи
между слоями и контролем видимости.
Туда же — layers, views, perspectives, subjects...
Видимо для мэйнстрима это terra incognita.

> _>по-другому — субъекты, или еще по-другому — method/selector namespaces.
> _>Идея простая — потребитель *сам* включает видимость/доступность тех или
> _>иных частей системы. Получаются явно прописанные зависимости, которые
> _>определяются исходя из роли каждого конкретного класса.
> _>Класс,
> _>наделенный ролью УправлениеРюшками, будет явно включать namespace
> _>СозданиеРюшек, получая доступ к якобы приватным методам других классов,
> _>отвечающим за управление временем жизни Рюшек.
> Отлично. Слоев тут нет ( (с) Шрек), зато есть ориентированность на потребителя. Как quickfix это должно действительно спасать. Но пока что я не вижу никакой причины для руления этого подхода в долгосрочной перспективе. Подход, где ограничения на потребителей задает производитель (назовем его классическим. Потому как в четырех из четырех мне известных ООП-платформ применяется именно он), выглядит менее демократичным. Но он, имхо, больше похож на реальность, где плодами трудов одного производителя пользуется множество потребителей. Поэтому производитель может себе позволить более высокую квалификацию, при которой принимаются правильные архитектурные решения. И требования к потребителям выдвигаются так, что они вынуждены следовать правильным решениям. От них заботливо убирают грабли, на которые можно наступить. Ты предлагаешь дать потребителям самим решать, чем им пользоваться, и пусть они отвечают за избыточные зависимости (которые не дадут им потом сделать upgrade на
новую версию библиотеки), и за поддержание инвариантов.

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

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

> _>Нижеприведенные примеры ничего не говорят в пользу конкретно
> _>protected/private.
> Это почему еще? Давай-ка прокомментируй.

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

>
>>>Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.

Здравствуйте, _vovin, Вы писали:
_>Бедный частный случай, а не изоморфизм.
Не понимаю умной мысли.
_>Про поведение там просто *ничего не сказано*. Поэтому мимо. Т.е. с
_>поведением ты можешь делать все что тебе заблагорассудится, в том числе
_>и private/protected. Если очень нужны фиче-грабли.
Там — это где?
_>О, значит тебе осталася совсем маленький переход для понимания связи
_>между слоями и контролем видимости.
_>Туда же — layers, views, perspectives, subjects...
_>Видимо для мэйнстрима это terra incognita.
Снова не понимаю умной мысли.
_>Все мимо, все не в кассу. Производительность достигается не
_>ограничениями, а возможностями.
Какая именно производительность? Ок, ни одна из современных платформ не требует пользоваться чем-либо, кроме public. Объясни мне, какая именно производительность подымется, если пользоваться только им? Уж не производительность ли при поддержке написанного софта?
_>Не испробовав возможности, превышающие
_>твои текущие ограничения (а значит и мышление), не сможешь оценить все
_>плюсы и минусы.
_>Вот и со слоями — ну не видишь ты их здесь, а они есть...
Где?
_>Насчет — ты предлагаешь дать потребителям самим решать, чем им
_>пользоваться — абсолютно правильно подмечено. И поверь, на основе такой
_>предпосылки строится абсолютно иной более гибкий и продуктивный способ
_>мышления и построения программных систем.
Хм. То есть ты считаешь, что авторы С++, Delphi, Java, C# и VB.NET дружно заблуждаются? Можно в студию хоть какие-то аргументы, кроме усмешек и голословных заявлений?
>> _>Нижеприведенные примеры ничего не говорят в пользу конкретно
>> _>protected/private.
>> Это почему еще? Давай-ка прокомментируй.

_>Достаточно в качестве контр-примера привести более гибкую схему,
_>например как указано выше.
Ну так приведи. То, что ты указал выше — всего лишь идея. Из нее не видно, как можно решать задачи структурирования решения, в том числе и контролировать зависимости.
_>Продуктивность неприемлет параноидальности.
Бла-бла-бла. А давай я напишу "Продуктивность требует параноидальности". И дальше что? Аргументы, дружище, аргументы.
_>Бывали случаи, когда
_>приходилось копировать целые классы из базового сертифицированного ядра
_>для обхождения private.
_>Поэтому подход — чтобы вынудить их пользоваться только нашей
_>политикой — заведомо ущербен.
Ага. То есть из того, что существуют конкретные библиотеки, которые некорректно используют private, ты делаешь вывод об ущербности private вообще? Т.е. об инкапсуляции в целом, я тебя правильно понял?
З.Ы. А я вот встречал случаи, когда люди занимались обходом private методом Copy/Paste только от того, что не смогли разобраться в штатном способе расширения функциональности. Ну, типа вместо того, чтобы штатно зарегистрировать свою фабрику, копировали класс и публиковали конструктор. Иожет, вместо private стоит запретить Copy/Paste?

Sinclair wrote:

> Здравствуйте, _vovin, Вы писали:
> _>Бедный частный случай, а не изоморфизм.
> Не понимаю умной мысли.

Человек говорил про неудачность protected/private, ты начал говорить про
необходимость ограничений в общем — но второе вовсе не требует первое.

> _>Про поведение там просто *ничего не сказано*. Поэтому мимо. Т.е. с
> _>поведением ты можешь делать все что тебе заблагорассудится, в том числе
> _>и private/protected. Если очень нужны фиче-грабли.
> Там — это где?

В ООП. В общем случае спрятана только внутренняя структура.

> _>О, значит тебе осталася совсем маленький переход для понимания связи
> _>между слоями и контролем видимости.
> _>Туда же — layers, views, perspectives, subjects...
> _>Видимо для мэйнстрима это terra incognita.
> Снова не понимаю умной мысли.
> _>Все мимо, все не в кассу. Производительность достигается не
> _>ограничениями, а возможностями.
> Какая именно производительность? Ок, ни одна из современных платформ не требует пользоваться чем-либо, кроме public. Объясни мне, какая именно производительность подымется, если пользоваться только им? Уж не производительность ли при поддержке написанного софта?

Речь о продуктивности разработки.
В частности private снижает продуктивность. Но отсутствие некоторого
количества ограничений увеличивает риски, что тоже нехорошо.

> _>Не испробовав возможности, превышающие
> _>твои текущие ограничения (а значит и мышление), не сможешь оценить все
> _>плюсы и минусы.
> _>Вот и со слоями — ну не видишь ты их здесь, а они есть...
> Где?

Указанный подход как раз был сформулирован как layered approach, но
естественным образом получается, что он может осуществлять контроль доступа.
Т.е. отвечая на твой вопрос "Где?" — по определению.

> _>Насчет — ты предлагаешь дать потребителям самим решать, чем им
> _>пользоваться — абсолютно правильно подмечено. И поверь, на основе такой
> _>предпосылки строится абсолютно иной более гибкий и продуктивный способ
> _>мышления и построения программных систем.
> Хм. То есть ты считаешь, что авторы С++, Delphi, Java, C# и VB.NET дружно заблуждаются? Можно в студию хоть какие-то аргументы, кроме усмешек и голословных заявлений?

Причем тут заблуждения?
Не все упорядочивается по принципу Заблуждение > Истина. Кое-что
выстраиваются в цепочки от частного к общему или от менее гибкого к
более гибкому. Всему свое время.

>
>>>_>Нижеприведенные примеры ничего не говорят в пользу конкретно
>>>_>protected/private.
>>>Это почему еще? Давай-ка прокомментируй.
>
>
> _>Достаточно в качестве контр-примера привести более гибкую схему,
> _>например как указано выше.
> Ну так приведи. То, что ты указал выше — всего лишь идея. Из нее не видно, как можно решать задачи структурирования решения, в том числе и контролировать зависимости.

"A Layered Approach to Software Design"
"A Simple and Unifying Approach to Subjective Objects"

> _>Продуктивность неприемлет параноидальности.
> Бла-бла-бла. А давай я напишу "Продуктивность требует параноидальности". И дальше что? Аргументы, дружище, аргументы.
> _>Бывали случаи, когда
> _>приходилось копировать целые классы из базового сертифицированного ядра
> _>для обхождения private.
> _>Поэтому подход — чтобы вынудить их пользоваться только нашей
> _>политикой — заведомо ущербен.
> Ага. То есть из того, что существуют конкретные библиотеки, которые некорректно используют private, ты делаешь вывод об ущербности private вообще? Т.е. об инкапсуляции в целом, я тебя правильно понял?

Неверное обобщение. Наверняка можно собрать статистику какой процент
private является неоправданным и приводит к кривым заплаткам. Не это ли
минус к продуктивности?

> З.Ы. А я вот встречал случаи, когда люди занимались обходом private методом Copy/Paste только от того, что не смогли разобраться в штатном способе расширения функциональности. Ну, типа вместо того, чтобы штатно зарегистрировать свою фабрику, копировали класс и публиковали конструктор. Иожет, вместо private стоит запретить Copy/Paste?

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

А мой случай — является. Там была фабрика, но нужно было сделать
реализацию на основе класса, в котором куча методов кроме одного
главного была private. Вот здесь и видна разница между непреодолимыми и
преодолимыми ограничениями.

Здравствуйте, _vovin, Вы писали:

_>Человек говорил про неудачность protected/private, ты начал говорить про
_>необходимость ограничений в общем — но второе вовсе не требует первое.
Гм. Я все воспринимаю буквально. Человек (ты, надо полагать, в виду имеешь Andrei N.Sobchuck) ничего про неудачность не говорил. Он спросил "зачем нужны модификаторы". Я ему ответил.
>> Там — это где?
_>В ООП. В общем случае спрятана только внутренняя структура.
А можно ссылку на это ООП? Меня вообще восхищает такой подход — если "в ООП" не было сказано о protected, значит protected есмь зло. Ага, а если в библии не было сказано про СТО — то Эйнштейн есмь зло. Ну да ладно.
>> Какая именно производительность? Ок, ни одна из современных платформ не требует пользоваться чем-либо, кроме public. Объясни мне, какая именно производительность подымется, если пользоваться только им? Уж не производительность ли при поддержке написанного софта?
_>Речь о продуктивности разработки.
_>В частности private снижает продуктивность. Но отсутствие некоторого
_>количества ограничений увеличивает риски, что тоже нехорошо.
Ага. Совершенно верно. И с ростом размера проектов управление рисками выходит на передний плвн.
>> Где?
_>Указанный подход как раз был сформулирован как layered approach
Не вижу ни формулировки, ни указания. Вижу только туманные общие фразы, объяснения которым я вынужден придумывать самостоятельно. Фи.
_>естественным образом получается, что он может осуществлять контроль доступа.
Каким образом? Что мне мешает обратиться из Layer1 прямо в Layer2?
_>Т.е. отвечая на твой вопрос "Где?" — по определению.
Определения тоже никакого нет. Есть набор отрывочных фраз.
>> Хм. То есть ты считаешь, что авторы С++, Delphi, Java, C# и VB.NET дружно заблуждаются? Можно в студию хоть какие-то аргументы, кроме усмешек и голословных заявлений?
_>Причем тут заблуждения? Не все упорядочивается по принципу Заблуждение > Истина. Кое-что
_>выстраиваются в цепочки от частного к общему или от менее гибкого к
_>более гибкому.
Т.е. аргументов нет?
_>Всему свое время.
Ок, я подожду, пока protected вымрет в результате естественного отбора. Ха-ха-ха.
>> Ну так приведи. То, что ты указал выше — всего лишь идея. Из нее не видно, как можно решать задачи структурирования решения, в том числе и контролировать зависимости.
_>"A Layered Approach to Software Design"
Это что, тест на пользование Google?
Ок. Вот что я нашел: http://www.cse.ucsc.edu/classes/cmps290g/Fall03/summary/pie_summary.pdf.
Читаем:

Goldstein and Bobrow present a layered network approach to represent changes in software
design and development. The fundamental difference to a file based version control system
is that software is represented as network in which the nodes represent software modules (e.g.,
products, components, classes, class methods, etc.) and the edges denote a containment hirarchy.
Changes in this system are represented by layers. A layer is similar to traditional delta files
such that it only contains the changes to the network layer it was derived from. The layered
network approach was implemented in PIE (Personal Information Environment), which can be
viewed as an extension to the standard Smalltalk class browser.

Т.е. никакого отношения к видимости или управлению доступом здесь нет. Это всего лишь change tracking system, замена file-based VCS. Что еще из оффтопа предложишь?
_>"A Simple and Unifying Approach to Subjective Objects"
Ок, нашел вот это. Оно?
Честно говоря, я не до конца понял идею. Я понял намеренения авторов — использовать единый подход как для видимости с т.з. объектов, так и с т.з. пользователей. Начинают они, фактически, с того, что декларируют недостаточность инкапсуляции данных, которую ты так защищаешь. Вот только вместо фиксированного набора областей видимости, предоставляемого мейнстримом, они предлагают задавать их вручную. Т.е. они не только не отказываются от protected, они предлагают расширить набор областей до неограниченного!
Маахонькая тонкость: автор сам приписывает к коду обозначение той "области видимости", в которой он находится. Я, правда, так и не увидел в статье того места, где описывается perspective, из которой должен вызываться метод.

При этом одним выстрелом убиваются трое .Net-зайцев:
1. Области видимости
2. Интерфейсы
3. CAS
Таким образом, потребность в областях видимости все же есть. Есть также и подходы различной степени экзотичности к обеспечению этой потребности. Никаких причин к подходу Us рулить супротив Java или Net я пока не вижу.
>> Бла-бла-бла. А давай я напишу "Продуктивность требует параноидальности". И дальше что? Аргументы, дружище, аргументы.
Т.е. аргументов опять нет.
>> Ага. То есть из того, что существуют конкретные библиотеки, которые некорректно используют private, ты делаешь вывод об ущербности private вообще? Т.е. об инкапсуляции в целом, я тебя правильно понял?
_>Неверное обобщение.
Отлично. Вот только не я его сделал. Его делвешь ты.
_>Наверняка можно собрать статистику какой процент
_>private является неоправданным и приводит к кривым заплаткам.
Ну так собери. Я нигде не говорю, что модификаторы доступа суть единственный способ реализации fine-grained encapsulation. Но твоя критика в их адрес выглядит, мягко говоря, неубедительной. На фоне этого твоя поза великого гуру, обрывки мыслей которого мы должны ловить с открытым ртом, смотрится смешно.
_>Не это ли минус к продуктивности?
Лично мне — неизвестно. Минусов к продуктивности может быть столько, что ой-ой-ой. Совершенно не уверен, что именно private виноват.
_>А мой случай — является. Там была фабрика, но нужно было сделать
_>реализацию на основе класса, в котором куча методов кроме одного
_>главного была private.
Твой случай ничуть не лучше. Ну сделали тебе неудачный класс — и что теперь, private виноват? Я тебя уверяю — некорректных применений layer/perspective можно наплодить с той же легкостью. Да, залатать кривой дизайн будет проще. Но маинтайнить систему, состоящую из заплаток, я врагу не пожелаю.

Здравствуйте, _vovin, Вы писали:

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

А может быть ты живешь в не нормальном мире? Может все же создатели библиотек несколько мудрее чем нерадивые пользователи? Может они не зря ставят private на методах и переменных?

Я вот согласен с синклером. Большинство жалающих заполучить доступ к private-членам — это просто не очень дальновидные люди (мягко выражаясь) не способные адекватно оценить ситуацию.

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

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

Здравствуйте, Sinclair, Вы писали:

S>но в более интересных ситуациях тебе поможет только дорогостоящее тестирование.

Забавный аргумент. Ты споришь с любителем Смолтока. А они как один костьми лягут, что все фигня и мир спосет юнит-естирование. И вообще проверка ошибок до рантайма — это мовитон.

Здравствуйте, VladD2, Вы писали:
VD>Но ты все ремя хочешь доказаь что инкапсулция — это грех. Не по тому ли что любимый язык-игрушка попросту не позволяет ее достичь?
Вроде бы нет. Я таки выбил из него ссылки на то, что он столь высокомерно цитирует. Это не Smalltalk. Это Us — настолько академический проект, что smalltalk на его фоне просто заезженный мейнстрим.
Прикол в том, что тот подход, который проповедует _vovin, преследует ровно те же цели, что и protected/private. В статье приведено отдельное решение, которое эмулирует поведение private — достаточно привязать нужные методы к перспективе, единственная ссылка на которую хранится в неопубликованном статик-поле. Поскольку обращение из-под определенной перспективы (этакая имперсонация) требует наличия ссылки на эту перспективу, постольку внешний код не сможет выполнить эти методы. Т.е. результат будет ровно тем же самым: опять разработчик библиотеки ставит _vovin в нелепую позу. Манипуляции с отладкой и relection для подглядывания внутрь объекта и копирования этой ссылки, имхо, ничуть не лучше, чем hack classes в Delphi и С++ и прочие хаки для обхода private — тот самый "минус к продуктивности".

Резюме: авторы этого послойного подхода решили предоставить весьма неудобный и ненадежный способ добиться функциональности public/private/protected. Для того, чтобы не по годам развитый прикладник мог исправить редкую ошибку разработчика библиотеки, все остальные разработчики библиотек должны тратить свое время на создание своих protected/private, причем для каждого класса в отдельности. Самое приятное, что никаких паттернов раздачи привилегий, не укладывающихся в возможности Java/.Net в той статье не приведено. И вообще непохоже, что авторы ставили перед собой цель переплюнуть С++. Они всего лишь пытались довести любимый Self — язык без инкапсуляции — до нужного уровня. Ясен перец, что простой подход не мог их устроить. Количество граблей, возникающих вследствие layered approach, и описанных в статье, весьма впечатляет. Опять же понятно, что unit testing спасает вообще от всех граблей — граблей языка, библиотек, и разработчиков.

Я понимаю, почему _vovin сам не рискнул объяснять, что такое Layered approach to subjective objects — оказалось бы, что это те же ягодицы, что и в мейнстриме, только вид спереди.

Здравствуйте, Sinclair, Вы писали:

ANS>>Разных "зон" это от 3х до 5ти? Такого примитивизма я не принимаю. Если хочется так предоставить контролируемы контракт, то возьми и предоставь его в смысле, объект, который пересылает разрешённые сообщения объекту. Вариантов тут поболее 5ти .
S>Этого я не понял. Наверное, туплю. Ты имеешь в виду динамическую проверку? Это уже Code Access Security и к областям видимости отношения не имеет.

Я говорил, скорее, об интерфейсах. Хотя, вариантов больше, чем стандартных модификаторов, в майнстримовых языках и не сделаеш.

ANS>>Очевидность необходимости модификаторов мне не очевидна. Повторю вопрос: что они дают?
ANS>>Вот есть инкапсуляция. Она, уменьшая связность, даёт гибкость. Есть пространства имён (классов). Они уменьшают количество коллизий этих имён. Вот есть модификаторы. Они дают... ???
S>Блин, я уже уставать начинаю. Может, будем читать сообщения? Эти модификаторы — и есть инкапсуляция. Они уменьшают связность и дают гибкость.

Я так и не понял, почему "инкапсуляция = наличие модификаторов"?
Моё виденье такое: поведение объекта зависит от его состояния. Закрыв доступ к его состоянию мы получаем невозможность установки объекта в невалидное состояние со стороны. Нет возможности поломать состояние — есть инкапсуляция. А куда тут притулить модификаторы?

ANS>>>>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
S>>>Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.

S>Ну, вот к примеру, если у нас созданием объектов рулит фабрика, то можно легко ее заменить на другую. А если конструктор объектов при этом публичный, то нет никакой гарантии, что после замены фабрики код будет корректным. В данном случае на большинстве применяемых ОО-языков ты сможешь обойтись банальным контекстным поиском, но в более интересных ситуациях тебе поможет только дорогостоящее тестирование.

Ну, так бы сразу и сказал, что модификатором можно прикрыть дырку в языке. Было бы создание объектов через посылку сообщения изначально (читай, через фабрику), не было б надобности закрывать конструктор.

Sinclair wrote:

> Здравствуйте, _vovin, Вы писали:
>
> _>Человек говорил про неудачность protected/private, ты начал говорить про
> _>необходимость ограничений в общем — но второе вовсе не требует первое.
> Гм. Я все воспринимаю буквально. Человек (ты, надо полагать, в виду имеешь Andrei N.Sobchuck) ничего про неудачность не говорил. Он спросил "зачем нужны модификаторы". Я ему ответил.
>
>>>Там — это где?
>
> _>В ООП. В общем случае спрятана только внутренняя структура.
> А можно ссылку на это ООП? Меня вообще восхищает такой подход — если "в ООП" не было сказано о protected, значит protected есмь зло. Ага, а если в библии не было сказано про СТО — то Эйнштейн есмь зло. Ну да ладно.

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

Где я говорил, "если в ООП... — значит зло"? Про перспективы/субъекты
тоже ничего в ООП не сказано, и?...

>
>>>Какая именно производительность? Ок, ни одна из современных платформ не требует пользоваться чем-либо, кроме public. Объясни мне, какая именно производительность подымется, если пользоваться только им? Уж не производительность ли при поддержке написанного софта?
>
> _>Речь о продуктивности разработки.
> _>В частности private снижает продуктивность. Но отсутствие некоторого
> _>количества ограничений увеличивает риски, что тоже нехорошо.
> Ага. Совершенно верно. И с ростом размера проектов управление рисками выходит на передний плвн.

Угу риски неоправданных private вылазят одними из первых. Про
сбалансированность ограничений не задумывался?

>
>>>Где?
>
> _>Указанный подход как раз был сформулирован как layered approach
> Не вижу ни формулировки, ни указания. Вижу только туманные общие фразы, объяснения которым я вынужден придумывать самостоятельно. Фи.

В таких случаях rsdn-овцы говорят так — что я тебе целую статью должен
пересказывать? Тебе надо — найди и прочти.

> _>естественным образом получается, что он может осуществлять контроль доступа.
> Каким образом? Что мне мешает обратиться из Layer1 прямо в Layer2?

Ты это можешь сделать только непосредственно включив один layer в
другой. А такие явные зависимости уже контролируемы.

> _>Т.е. отвечая на твой вопрос "Где?" — по определению.
> Определения тоже никакого нет. Есть набор отрывочных фраз.
>
>>>Хм. То есть ты считаешь, что авторы С++, Delphi, Java, C# и VB.NET дружно заблуждаются? Можно в студию хоть какие-то аргументы, кроме усмешек и голословных заявлений?
>
> _>Причем тут заблуждения? Не все упорядочивается по принципу Заблуждение > Истина. Кое-что
> _>выстраиваются в цепочки от частного к общему или от менее гибкого к
> _>более гибкому.
> Т.е. аргументов нет?

Гибкость — преодолимые ограничения, заданные хорошо контролируемыми
явными зависимостями. Негибкость — жесткие непреодолимые ни при каких
условиях ограничения, наподобие private.
Сойдет?

> _>Всему свое время.
> Ок, я подожду, пока protected вымрет в результате естественного отбора. Ха-ха-ха.
>
>>>Ну так приведи. То, что ты указал выше — всего лишь идея. Из нее не видно, как можно решать задачи структурирования решения, в том числе и контролировать зависимости.
>
> _>"A Layered Approach to Software Design"
> Это что, тест на пользование Google?
> Ок. Вот что я нашел: http://www.cse.ucsc.edu/classes/cmps290g/Fall03/summary/pie_summary.pdf.

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

> Т.е. никакого отношения к видимости или управлению доступом здесь нет. Это всего лишь change tracking system, замена file-based VCS. Что еще из оффтопа предложишь?

Отзыв не указал главного, поэтому твой коммент съехал в оффтоп.
Главное назначение такого подхода — реализация design alternatives. При
наличии указанной схемы структурирования исходных текстов и layered
approach легко переключать различные варианты реализации — контексты. А
change tracking это один из побочных эффектов.
Механизм же layerd approach может быть различный. Как чисто механический
— мы состовляем граф беря из разных слоев разные альтернативы. Либо
можно придумать чисто декларативный, где слоям назначаются
идентификаторы, и мы можем указывать в своих слоях какие слои в каком
порядке включать. Вот это и будет примерно то, что я описал с областями
видимости.
В следующей статье уже более конкретно разбирается этот случай с
субъектами и перспективами.

> _>"A Simple and Unifying Approach to Subjective Objects"
> Ок, нашел вот это. Оно?
> Честно говоря, я не до конца понял идею. Я понял намеренения авторов — использовать единый подход как для видимости с т.з. объектов, так и с т.з. пользователей. Начинают они, фактически, с того, что декларируют недостаточность инкапсуляции данных, которую ты так защищаешь. Вот только вместо фиксированного набора областей видимости, предоставляемого мейнстримом, они предлагают задавать их вручную. Т.е. они не только не отказываются от protected, они предлагают расширить набор областей до неограниченного!

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

> Маахонькая тонкость: автор сам приписывает к коду обозначение той "области видимости", в которой он находится. Я, правда, так и не увидел в статье того места, где описывается perspective, из которой должен вызываться метод.

Надо знать Self/Us — там и код и слоты и объекты представляются
единообразно. Метод это просто объект с наличием activation record.
Поэтому конструкция — (...) (+) perspective — действует везде.

Дальше практически верно:

>
> При этом одним выстрелом убиваются трое .Net-зайцев:
> 1. Области видимости
> 2. Интерфейсы

Это лишнее. Варианты использования перспектив и интерфейсов могут
пересекаться, но у интерфейсов изначально совсем другое назначение. В
динамическом языке не нужны интерфейсы как средство обеспечения
полиморфизма.

> 3. CAS
> Таким образом, потребность в областях видимости все же есть. Есть также и подходы различной степени экзотичности к обеспечению этой потребности. Никаких причин к подходу Us рулить супротив Java или Net я пока не вижу.

Ну как же, как же. Одну статью не прочитал, вторую не до конца понял, а
берешься утверждать.
Классический пример — поддержка версионности. Одни и те же объекты в
разных перспективах (задающих версию) могут работать по-разному.
По-разному могут работать и конструкторы.
Возможны и другие интересные эффекты: перспектива Version_1_1 может
включать в себя Version_1_0 и переопределять только различающееся
поведение. При этом бывает необходимо иметь раздельное состояние для
различных версий. Тогда в перспективе Version_1_1 заводятся копии
необходимых полей объекта из Version_1_0. При этом в перспективе
Version_1_0 код из Version_1_0 будет естественно работать с полями из
Version_1_0. А в перспективе Version_1_1 — с полями из Version_1_1.

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

>
>>>Бла-бла-бла. А давай я напишу "Продуктивность требует параноидальности". И дальше что? Аргументы, дружище, аргументы.
>
> Т.е. аргументов опять нет.

Личный опыт и наблюдения. Про постоянное натыкание на private и
связанные с этим проблемы я говорил. В отсутствие private никаких
проблем не было, как это обосновать? Тем, что никаких проблем не было...
Это не выглядит супер-аргументом, поэтому и приводить-то его не стоит.
Многим и так интуитивно/эмпирически понятно.

>
>>>Ага. То есть из того, что существуют конкретные библиотеки, которые некорректно используют private, ты делаешь вывод об ущербности private вообще? Т.е. об инкапсуляции в целом, я тебя правильно понял?
>
> _>Неверное обобщение.
> Отлично. Вот только не я его сделал. Его делвешь ты.

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

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

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

> _>Наверняка можно собрать статистику какой процент
> _>private является неоправданным и приводит к кривым заплаткам.
> Ну так собери. Я нигде не говорю, что модификаторы доступа суть единственный способ реализации fine-grained encapsulation. Но твоя критика в их адрес выглядит, мягко говоря, неубедительной. На фоне этого твоя поза великого гуру, обрывки мыслей которого мы должны ловить с открытым ртом, смотрится смешно.

Личный наезд.
"Ну так собери" — абсурдное предложение. Свою статистику я примерно
представляю, а собирается она только при личном натыкании на проблему и
ее обход.

> _>Не это ли минус к продуктивности?
> Лично мне — неизвестно. Минусов к продуктивности может быть столько, что ой-ой-ой. Совершенно не уверен, что именно private виноват.

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

> _>А мой случай — является. Там была фабрика, но нужно было сделать
> _>реализацию на основе класса, в котором куча методов кроме одного
> _>главного была private.
> Твой случай ничуть не лучше. Ну сделали тебе неудачный класс — и что теперь, private виноват? Я тебя уверяю — некорректных применений layer/perspective можно наплодить с той же легкостью. Да, залатать кривой дизайн будет проще. Но маинтайнить систему, состоящую из заплаток, я врагу не пожелаю.

Ну прям назвал заплаткой и понятие приобрело негативный смысл.
А private как представитель подхода *непреодолимых* ни при каких
условиях ограничений действительно сам по себе виноват своим существованием.