Это проблема человеческой организации, а не структуры данных. Представьте, что Вам нужна структура данных для некоторой задачи, ну при чём тут разработчики?
Если есть два - они либо равноправно обмениваются данными, проверяют весь код независимо и каждый отвечает за свою версию, либо один из них главный, а второй подчинённый. Для этого существуют системы контроля версий, которые совершенно не связаны с модификаторами public/private/friend.
Тогда тем более friend не нужен. Бритва Оккама.
Префиксы всегда только увеличивают трудозатраты. Для чтения это вообще КЭП, для набора возможность умной подсказки и подставовки также всегда лучше любого теоретически возможного набора префиксов. Матан это гарантирует. Если префиксы улучшают работу, значит это костыль к неоптимальной среде разработки.
Не согласен с Вами, префикс может означать например область использования, тем самым визуально разделив Public функции на разделы. Насчет костыля это да. Потому что все, абсолютно все среды и языки не оптимальны. Они решают определенный круг задач и все на этом. Дальше определенный барьер, который стимулирует новый виток эволюции. Вводятся новые фишки в язык, в среду разработки начинают пихать навороты и т.д. Это бесконечный процесс борьбы с неоптимальностью.
Когда свойства всего два, как в примере - закрытие одного из них однозначно делает автоподстановку второго безусловной.
Только частный случай.
Корректность значения полей может определяться исключительно взаимосвязью, которую public/private геттеры и сеттеры никак не могут установить, потому что эти модификаторы по определению сведений об этом не содержат. По сути Вы напрочь игнорируете задачи вообще.
Тогда объясните подробней, в чем проблема?
Это жутко неэффективное решение.
Создавать проблемы в модели, вот это жутко неэффективное решение. Решение в моем случае автоматическое и позволяет прогнозировать результат. За все проблемы нарушения логической целостности в данном случае несет ответственность один человек. Что предлагаете Вы? Да ведущий инженер узнает, что ошибка есть - объект не работает так как надо, но кто в данном случае виновен? Разработчик класса или разработчик friend? Ну очевидно же, время отладки увеличено. Вы пытаясь сократить время разработки увеличиваете время отладки. Поэтому эффективность решения под вопросом. Вы почитайте программную инженерию - там программирование вообще полуавтоматический процесс, 90 процентов времени должно быть уделено именно проектированию системы. В таком случае время на отладку будет сокращено на поиск синтаксических ошибок. Логические ошибки не должны порождаться программистом в принципе, это проблема разработчика проекта. А ему friend не нужен по определению - он всегда спроектирует класс таким образом, чтобы нужные функции получали нужные объекты. Программист в идеале должен получить диаграммы классов и написать их реализацию и тут снова friend не нужен, потому что интерфейс Вам даст разработчик проекта.
А если не могут и не требуется?
Универсальное решение гарантирует универсальное поведение и универсального виновника всех проблем.
Подмена одной математической задачи на другую - это вообще какая-то жесть.
Да уж Вы наговорите. Сплошь и рядом это происходит. Мне вот например в некоторых задачах не требуется весь диапазон значений Integer и ничего, я с транспорантами не хожу по данному вопросу. Логические значения занимают два байта (потому что работа с битом давно неэффективный процесс) и т.д. А почему тот же Integer нужно преобразовать перед выводом на экран? И Вы мне тут еще рассказываете о жести, да все программирование на этом построено - бесконечное навязывание типов, объектов, проблем и полная жесть. А работа с юникодом - когда один символ один байт, другой два, а третий вообще неизвестно то ли два, то ли четыре?
Наоборот, грубый взлом невозможен только когда это предусматривает разработчик. Очередная подмена понятия безопасности.
И где же этот разработчик и тот объект, где предусмотрена невозможность взлома? Ну примеры?
Как только начинает подключаться множество разных библиотек - конфликт неизбежен
Избежен, это проблема людей, а не языка. Вы абсолютно игнорируете простую вещь - есть программирование компьютера и есть программирование человека. Конфликт имен это проблема человека, а не машины. Сделайте утилиту преобразования имен (тем более именно это компилятор и делает). Это можно автоматизировать, нет проблемы для машины. Это проблема на уровне мозга и только. Ведь осмысленность имени (причина конфликта имен) опять нужна человеку, машине класть как называется метод Create или а1. Вы сплошь и рядом наступаете на миражи.
В том-то и дело, что public быстро плодит вопросы, отчего производительность катастрофически падает - компьютер просто не сможет самостоятельно их разрешить.
Еще раз - в ассемблере нет private. Как же он не может решить? Ничего там не падает. Производительность падает у человека. Возьмите и проведите тест с private и public переменными на обсчет чего-нибудь в цикле. Ничего там не падает.
Смешались в кучу кони, люди,...
Я еще раз повторяю Вам, что в ассемблере нет private секций, программы работают и никто не жалуется кроме Вас. И еще раз - язык состоит из двух частей - непосредственные команды компьютеру и ритуал для человека, позволяющий ему создавать сложные конструкции. Без ритуала (всякие области видимости, модули, классы и пр.) создавать программы можно. Но это займет много времени. Люди пишут операционные системы на ассемблере и не жалуются. Вы же говорите, что то что они уже достигли просто невозможно. Я говорю - возможно и повседневно. Вы уже запрограммированы языком, его концепциями 
.
Отредактировано utkin (2017-12-19 09:10:59)