Потому что суть сводится к внедрению (проникновению). Но у американцев, наверное, тоже такой мем)

Друзья - неформальное понятие, а программная архитектура - это топология.
Нужно показать, какая именно получается сложной в исполнении.

С графами всё просто - это наборы указателей. Так что они по-любому будут, не в статитике, так в динамике.

Отредактировано MihalNik (2017-11-30 21:14:49)

А Лис-то был оперативно услышан ))) :

Отредактировано MihalNik (2017-12-09 22:20:39)

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

Это позволяет:
1. До невозможности усложнить процесс тестирования и отладки
2. В принципе перечеркнуть концепцию ООП (нафиг она упала, если нужно потом костыли добавлять)
3. Увеличить порог вхождения при изучении языка, так как до сих пор никто четко не объяснил практических выгод и реального практического применения.

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

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

Отредактировано utkin (2017-12-14 14:46:17)

Увеличив затраты на отладку. Потому что класс может быть объявлен в одном месте, а тот кто его меняет у черта на куличках. Соответственно, давая доверие не из единого центра, получаем геморрой. Для одной дружественной функции это не существенно, но кто же нас останавливает? Если их 100? Как можно контролировать целостность внутреннего состояния объекта? Сначала один программист напишет свою дружественную функцию, потом второй напишет свою, третий еще чего-нибудь. Какие гарантии что они знают о существовании других дружественных функций? Потенциальная угроза при разработке в команде имеется, а при разработке в одиночку механизм просто не имеет смысла.

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

Да, мы раздаем задачи, но не раздаем ответственность. В результате кто виноват и что делать узнается не так быстро как надо.

Это сферический конь в вакууме, а не задача .

GUID. Мелкософт доверяет даже классам, которые написаны для другой программы или другим издателем. Не знаю как это шикарно выглядит, но решение есть. Это была борьба с интерфейсами - типа полиморфизм и общие интерфейсы позволяют именовать сто тысяч миллионов функций одними и теми же именами (я не против ), но в результате каждый зная интерфейс (а они же унифицированы) мог вызвать че хотел. А тут GUIDы и все вызывает только тот у кого нечитабельный труднозапоминаемый код . Зарегистрировался, передавай GUID и пользуйся всеми плюшками.

Как же не очевидна - если у Вас 100500 объектов, для которых есть доступ с дружественной функцией они все не параллельны, так как нельзя предсказать какой конкретно экземпляр должен простаивать в момент обращения дружественной функции. Сам механизм предсказания может стоить столько по времени исполнения, что не будет смысла заморачиваться параллельностью в принципе. Даже если у Вас примитивный тип данных (например, массив объектов), то вычислять индексы, то еще дело. Если объекты в объектах (например, в списке) это ад, потому что понадобится офигенная реализация механизма предсказания для каждого из контейнеров, включая не описанные ранее. В результате даже сам факт проверки имеется ли дружественная функция (а например, она может тянуться  не к данному классу, а к родителю) это уже накладные расходы для параллельного исполнения. Так например, внутри класса можно было бы там завести список дружественных функций и учитывать их, но есть же родительские объекты. Каждый раз при обращении к ним все равно нужно будет проводить вычисления.

Я честно говоря даже, не пойму смысла в том, что бы давать доступ одним объектам и не давать другим. Если человек захочет, он же всегда может написать дружественную функцию и тем самым все равно объект можно будет ковырять. Ну просто все кто хочет будет писать дружественные функции и превращать код в неуправляемый мусор. Это какие-то игры разума с реализацией психологического программирования программиста, а не реализации алгоритмов. Разве дружественную функцию может написать только тот кто действительно в этом нуждается? Нет ее могут написать все кому не лень. Следовательно в чем разница между Public и дружественной функцией? Только в том, что написать функцию для Public проще, цели ясны.

Отредактировано utkin (2017-12-15 07:31:36)

Ну и рассматривайте вопрос доверия как вопрос типов. Я к этому и веду.

Сомнительно это все. Как идентифицировать объект, к которому будет обращение дружественной функции? Я же привел пример. Вы имеете список объектов - вычислите нужный объект, чтобы определить куда будет обращаться дружественная функция.

Это опять же попытка заменить проектирование алгоритма и результат не очевиден.

Это и для Public также работает.

Организуйте их интерфейсами.

Да как отсечь-то, если всегда можно написать дружественную функцию ? Как так получается что Public может смотреть любой, а написать дружественную функцию только избранный? Любой может смотреть Public, любой может написать дружественную функцию. В чем разница-то?

Отредактировано utkin (2017-12-15 12:49:47)

Я же про это и пишу это чистая психология . Вызовом Public функций тоже пользуются только те кому эти функции нужны, а не каждый встречный и поперечный. Мы же возлагаем какие-то эфемерные возможности на механизм. Результат не решение проблемы, а ее маскировка. Этот механизм делегирует возможности, но не ответственность за их использование. Public - это прямой доступ и прямая ответственность. Вы можете организовать геттеры и сеттеры в Public и это дает некоторые гарантии внутренней целостности объекта (как СУБД гарантируют целостность БД), вся ответственность лежит на авторе класса. Объект не работает как положено - все, есть тот кто должен его исправить, есть возможность управлять проектом. С дружественными функциями поиск ответственного не тривиальная задача, в результате ошибка может быть выяснена на более поздних сроках, в рамках проектов уровня фреймворка или операционной системы это фатально (ну вот Виста например не взлетела, понятно, что дружественные функции не при чем, вина очевидна в скорость разработки в ущерб времени затраченного на проектирование). Практически процентов 80-90 неудачных проектов это вина проектировщика. И дружественные функции прямо усугубляют это положение.

Это известная проблема - Вы переносите время написания кода на время отладки. Суть-то не изменилась, ну кроме того, что увеличивается шанс получить трудно отлавливаемую логическую ошибку (кто-то изменил внутреннее состояние объекта, не предусмотрев другое изменение другой дружественной функции и тем самым нарушив логическую целостность модели). И отдельное тестирование компонентов тут не спасет - каждая функция отдельно от другой будут работать корректно.

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

Отредактировано utkin (2017-12-16 11:02:24)

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

Это не однозначно, не согласен с Вами. Может да, может нет. Эффективность сомнительна, абсолютная необходимость (то есть что вот прямо вот такие цели, которые решаются только дружественными функциями) отсутствует. Человек может заморочиться с Public именами (ввести префиксы какие-нибудь) и тогда структура станет эффективной (или усугубит ситуацию), а может не заморочиться. Опять психология, а не механизм приводящий к производительности.

Если считать, что нет интерфейсов, если считать, что имена в public случайный набор символов, то да, безусловно.

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

С какой стати? Я предлагаю использовать геттеры и сеттеры, которые гарантируют, что переменная будет содержать корректное значение, а вот прямой доступ к переменной как раз-таки наоборот лишает нас таких гарантий. Очевидно, что создатель класса лучше знает его работу и структуру и потому его механизмы более корректны, чем грубый хак.

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

Это абстрактная задача, она не нужна для создания алгоритмов (решений практических задач). Но даже для нее вводить GUID и заставляете регистрироваться объекты. Например для есть структура А, которая должна выдавать разные возможности для разных классов. ОК - вводите функцию Регистрация(Идентификатор, Полномочия). И потом для доступа к сомнительным возможностям не для всех такой вызов функции: ЗапускЯдерныхРакет(Идентификатор, параметры_запуска). Не зарегистрированные Г, Д, Е (хоть еклмн) не получат такую возможность. Отличие механизма в универсальности - нет ДляЕ, нет ДдляЕ, есть ДляГруппыКотораяУдовлетворяетУсловиямАвторизации, то есть универсальный способ доступа. При этом Идентификаторы можно раздавать извне (как и хранить списки доступа вне самого класса, реализующего возможности для избранных). При этом разумеется разные объекты могут раздавать полномочия разным участникам процесса, да еще и динамически (мы ведь может и разрегистрировать объект в силу каких-нибудь обстоятельств, например когда структура к которой нужен доступ больше не существует внутри данного объекта), оцените мощь и возможность масштабирования. Если требуется параноидальный режим, то Идентификатор (например, строка в пару тысяч символов) может раздавать сам регистратор. Вероятность ошибки (то есть неверно рассчитанный Идентификатор) начинает стремиться к нулю - скорее человек создаст какую-то организационную структуру, чем в программе будет такое количество объектов, что у них начнут совпадать Идентификаторы. Тут и волки сыты и объект по-прежнему самостоятельно управляет своим состоянием.
Если рассматривать вопрос философски - грубый хак системы возможен тоже только тогда когда объект предусматривает эту возможность. Ну например, в природе - хищники едят жертв. Это грубый хак - повреждения системы, с переводом ее из одного состояния в другое (ну например, растение или животное может выжить, не обязательно же грустный финал). Но это возможно строго тогда, когда жертва позволила это сделать. Например, антилопа не смогла убежать от льва. Но ведь могла и убежать, или там ежик имеет иголки и не каждый хищник способен их преодолеть. Или черепаха имеет панцирь. То есть примеров в жизни, когда система не позволяет изменять свое внутренне состояние без своего согласия просто тьма. Даже сам термин - толерантность есть. Это согласие на изменение, терпимость по отношению к окружающей среде.

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

Отредактировано utkin (2017-12-18 13:17:18)