Русскоязычное программирование

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Русскоязычное программирование » трибуна Уткина » Обшие (public) и Личные (private)


Обшие (public) и Личные (private)

Сообщений 1 страница 29 из 29

1

Считаю, что тут чего-то не хватает. Дружбомагии.

Общие - это для всех-всех, частные - это ни для кого. А как же друзьяшки? Они и не все-все, но и не никто.
Маловато социальности!

0

2

Эта дружбамагия там есть, модель срисована с Паскаля (Делфи и Free Pascal). У них есть и иные области видимости. Для чего это и как работает: http://bourabai.ru/einf/Delphi/Delphi_p … dex10.html
В иных языках программирования есть подобные механизмы. Области видимости в Java:
https://ru.wikibooks.org/wiki/Java/Видимость
Вкратце Общие доступны для чтения/записи всем без исключения. Личные могут менять только функции которые объявлены в этой же системе (они же могут менять все секции). Чтобы что-то изменить в Личные нужно сначала "попросить" (вызвать) функцию которая умеет это делать. Таким образом мы скрываем от всех устройство и поведение системы. Вы не сможете взять систему и вызвать функцию, если она в Личных у системы. Все общение возможно только с функциями из Общие, а уже они решают что и как использовать. Функции из Общих представляют Вам интерфейс для взаимодействия.
Пример из жизни - пульт от управления телевизором. Вы не знаете (и более того знать не должны!) какой последовательностью инфракрасных импульсов переключает канал. В инструкции написано нажать какую кнопку чтобы все работало. Кнопка это функция из Общих. Инфракрасный луч это Личные. Потому что придет время и пульт станет на Вай-Фай. В результате новая система будет полностью совместима (при этом будет переписаны коды в секции Личные) - Вам не надо читать инструкцию, просто нажимаете на ту же кнопку и канал переключается. Большая  часть населения не знает как это вообще работает, нажал на кнопку и все.
Все это родило потом и понятие интерфейса (Джава, Сшарп, Дельфи и огромная куча других языков) - Вы можете описывать интерфейс в принципе, отдельно от реализации (тупо как должна например называться функция и сколько у нее параметров какого типа и т.д.). В ряде языков есть инструменты позволяющие проверить может ли объект работать по такому интерфейсу или нет и т.д. Интерфейсы помогают в командной разработке - можно наклепать интерфейсы объектов и раздать остальным, еще до этапа полной разработки класса и описания всех его функций. В результате никто не ждет класса, а к моменту когда он будет готов уже могут существовать остальные компоненты готовые сразу же работать с новым объектом (ну конечно не всегда все так красиво, но тут хотели как лучше).

Отредактировано utkin (2017-11-30 12:32:25)

0

3

Мы прослушали короткую лекцию про инкапсуляцию.

Но вообще я имел в виду не это, а подобие friends из C++ или C#. Нельзя сказать, что мне нравится как это сделано там или там, мне просто хочется иметь возможность отметить сам факт того, что объекты могут "дружить"

Отредактировано Лис (2017-11-30 12:30:14)

0

4

Мы прослушали короткую лекцию про инкапсуляцию.

Про области видимости. Инкапсуляция более широкое понятие. Модуль в котором описан класс тоже инкапсуляция например.

Но вообще я имел в виду не это, а подобие friends из C++ или C#.

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

Нельзя сказать, что мне нравится как это сделано там или там, мне просто хочется иметь возможность отметить сам факт того, что объекты могут "дружить"

Ничего такого здесь нельзя :). Поведение должно быть максимально предсказуемым.
Цель такого механизма в языке? Вы всегда можете описать новую публичную функцию, которая будет делать то, что нужно "попросить".

Отредактировано utkin (2017-11-30 12:39:18)

0

5

utkin написал(а):

можете описать новую публичную функцию


Я не хочу публичную. Хочу конфиденциальную (но не приватную).

involves a set of rules or a promise that limits access or places restrictions (https://en.wikipedia.org/wiki/Confidentiality)

Отредактировано Лис (2017-11-30 12:44:27)

0

6

Смысл какой в этом? На фига козе боян? Польза дружественных функций сомнительна. Самый весомый аргумент который я читал - так писать наглядней и разумеется не выдерживает никакой критики. Какой алгоритм требует применения дружественных функций? Что за задача в которой решение возможно только с использовании этого механизма?

involves a set of rules or a promise that limits access or places restrictions

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

Отредактировано utkin (2017-11-30 12:51:08)

0

7

utkin написал(а):

На фига козе боян?


лисе

utkin написал(а):

Польза дружественных функций сомнительна.


наблюдение за окружающим миром показывает, что друзья у людей существуют (правда не у всех). Вот зачем делить на общие и свои? Пусть все будут общие!

0

8

Вот зачем делить на общие и свои?

Затем, чтобы есть концепция интерфейсов. Затем что программирование в целом и ООП есть моделирование некоторой системы ценностей. Отражение некоторого мира.

что друзья у людей существуют (правда не у всех).

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

лисе

Я не Вас лично имел ввиду, это такой мем :)
А Вы стали жертвой как раз того что термины в программировании не отражают сути описываемых явлений (это вообще много где беда) :). Дословный перевод friend не переносит этих свойств с программирования на людей. Возьмите древние методики - например, модель агентов и сообщений. Вы агент, имеете внутренне представление и общаетесь с окружающим миром посредством сообщений. Тогда Вам достаточно знать адресата и само сообщение и тогда проблема внутреннего состояния и друзей (из категории человеческих отношений) отлично моделируется (Вы просто назначаете роль "друг" определенному адресату и взаимодействуете в рамках связанного интерфейса). Моделирование с помощью friend абсолютно не прозрачно и не гарантирует эмпирического результата, а значит дополнительные затраты на отладку.

Отредактировано utkin (2017-11-30 13:08:49)

0

9

utkin написал(а):

есть концепция интерфейсов.


Тогда так и делайте, как говорите - все функции сделайте приватными, а интерфейсы опишите особым образом.

А то сейчас у вас интерфейс для публики на уровне синтаксиса прописан, а интерфейс для друзей на уровне синтаксиса не прописан.

0

10

Я Вам сказал какая модель взята за основу - паскалистическая :). Это красиво, это объяснимо, это логично, это имеет смысл, это подходит для той модели которую я хочу применить. Друзей нет и не будет - это графы. Параллелизм опять же - дружественные функции не отпараллелить это сто процентов непредсказуемый прецедент. И на главный вопрос нет ответа - зачем дружественные функции? Их добавление требует некоторых телодвижений и сейчас и потом. Зачем это делать? Просто потому что так хочет Лис это не аргумент. Приведите причины целесообразности и необходимости. А я их просто не вижу, даже в С++.

Отредактировано utkin (2017-11-30 13:40:23)

0

11

utkin написал(а):

Дословный перевод friend не переносит этих свойств с программирования на людей.

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

Лис написал(а):

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

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

Друзей нет и не будет - это графы.

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

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

0

12

Так что они по-любому будут, не в статитике, так в динамике.

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

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

0

13

Можно такой синтаксис сделать:

...
  область
    ...
  область дополнительные-слова-тут
    ...
...

например "область публичная" (область = scope)
или "область договор-42"

0

14

Я повторяюсь - зачем это делать? Смотрели приключения домовенка Кузи - Каждая планка в лесу чему-нибудь назначена. И есть бритва Оккама - если объект не требуется, он не нужен. Поэтому нужно обоснование вводимого инструмента.

область
    ...
  область дополнительные-слова-тут

Это вопрос смены синтаксиса (Общие-Личные) или вопрос изменения семантики языка?

Отредактировано utkin (2017-12-01 13:46:31)

0

15

интерфейс для публики на уровне синтаксиса прописан, а интерфейс для друзей на уровне синтаксиса не прописан.

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

7.12.2017 - новая версия 0.85.7
Изменения:
Добавлен оператор
FRIENDS: {класс1}, {класс2}, ... . Друзья класса могут обращаться к его непубличным полям (и - позже - методам).

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

0

16

Это вопрос какого языка?

0

17

utkin написал(а):

Это вопрос какого языка?

Я думаю, что АЛФОР, так как именно с ним недавно разбирался MihalNik

0

18

Да. Но речь вообще про то, как это правильно обозвать.
В праве это называется "доверенностью", но возможно слишком отвлечённое понятие и лучше доступ[ность], открытость, раскрытие.

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

Отредактировано MihalNik (2017-12-13 14:52:47)

0

19

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

0

20

utkin написал(а):

зачем создавать строгую систему типов, а потом открывать дверь с черного хода?

Это позволяет:
1) Как можно меньше раздавать общие права.
2) Дешевле распределять ответственность м/у классами, особенно когда нет уверенности, какой из них должен отвечать за функцию, принимающую более одного параметра и соответственно неоднозначную с этой точки зрения.

0

21

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

Как можно меньше раздавать общие права.

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

2) Дешевле распределять ответственность м/у классами, особенно когда нет уверенности, какой из них должен отвечать за функцию, принимающую более одного параметра и соответственно неоднозначную с этой точки зрения.

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

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

0

22

utkin написал(а):

Это тем более говорит о том же самом - алгоритм не проработан.

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

2. В принципе перечеркнуть концепцию ООП

Разделение доступа вообще не является собственно ООП. Например:

часто упоминаемый принцип сокрытия в потомках Smalltalk семантически недоступен и идеологически считается несущественным

А у автора премия Тьюринга за ООП.

Человек не до конца понял, что ему нужно

Человек может вообще работать не один. А это возможный способ разделения задач, об отсутствии которого мы ранее говорили.
И ещё раз: поставленные задачи могут изменяться в ходе работы.

В таком случае такой вид доступа можно использовать для экспериментов и отладки, но никак не для реализации.

Давайте уже поставим какую-нибудь задачу. Как открыть доступность переменных некоторой структуры только 1 или 2 классам? Например, служебные ссылки в узлах дерева нужно открыть только для дерева. При этом деревьев дано два разных вида, которые по разному с ними работают.

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

Распараллеливание там задумано, но ещё не реализовано, поэтому ответить на данный вопрос сейчас трудно. Вообще проблема с этим неочевидна.

0

23

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

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

Разделение доступа вообще не является собственно ООП. Например:

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

Человек может вообще работать не один. А это возможный способ разделения задач, об отсутствии которого мы ранее говорили.

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

Давайте уже поставим какую-нибудь задачу. Как открыть доступность переменных некоторой структуры только 1 или 2 классам?

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

Давайте уже поставим какую-нибудь задачу. Как открыть доступность переменных некоторой структуры только 1 или 2 классам?

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

Вообще проблема с этим неочевидна.

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

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

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

0

24

utkin написал(а):

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

Вполне себе задача.

GUID.

Это вообще-то механизм динамической типизации.

В результате даже сам факт проверки имеется ли дружественная функция.

А это на этапе разработки/компиляции.

Я честно говоря даже, не пойму смысла в том, что бы давать доступ одним объектам и не давать другим.

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

в чем разница между Public и дружественной функцией?

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

Отредактировано MihalNik (2017-12-15 10:50:10)

0

25

Это вообще-то механизм динамической типизации.

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

А это на этапе разработки/компиляции.

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

Смысл только в том, что в неупорядоченном пространстве слишком сложно работать.

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

Автоматическая подсказка, дополнение и создание кода ускоряют работу в разы.

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

А нескрытые названия постоянно удлиняют цепочку выбора.

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

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

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

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

0

26

utkin написал(а):

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

Разница в том, что внутренности показываются только тому, кому они нужны и только там, где они нужны. И если они не нужны - ничего для этого не делается. НИЧЕГО, Карл!
Дано: класс А1 со свойствами Б1 и В1.
Б1- закрытое, В1 - открытое.
Класс А2 со свойствами Б2 и В2.
Б2 - закрытое, В2 - открытое.
Объекты Об1 и Об2 классов А1 и А2 соответственно.
Требуется: функция Ф с доступом к Б1 и Б2 объектов Об1 и Об2.

Пусть эта функция в классе А2 объявлена, скажем А2.Ф(Об1: А1) а вызывается Об2.ф(Об1)
Если Б1 - закрытое поле, то когдя Вы набираете "Об1.", где Об1 - класса А1, то (автоматически) возможно два продолжения - Б1 и В1 только в рамках класса А1.
Если при этом А1 раскрыт для А2, то и в рамках А2.
Если Б1 вместо этого сделать открытым, то оно будет вариантом продолжения "Об1." везде и автоматическое завершение как "Об1.В1" за рамками классов А1 и А2 станет затруднительным.

utkin написал(а):

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

А речь не об этой паранойе вообще. Речь - о функциональности в виде скорости разработке, вполне измеримой кол-вом телодвижений для достижения результата.

В том же Делфи это уровень доступа private в рамках одного модуля:

Когда вы описываете методы как приватные они все равно видны по крайней мере в рамках одного unit. То есть это отношение "friend" в терминах C++. Когда вы делаете метод strict private - это означает действительно приватный метод или свойство для класса и не не видим никому, даже в рамках unit.

strict private там есть только начиная с 2007.

Отредактировано MihalNik (2017-12-15 17:48:26)

0

27

Разница в том, что внутренности показываются только тому, кому они нужны и только там, где они нужны. И если они не нужны - ничего для этого не делается.

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

Речь - о функциональности в виде скорости разработке, вполне измеримой кол-вом телодвижений для достижения результата.

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

В том же Делфи это уровень доступа private в рамках одного модуля:

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

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

0

28

utkin написал(а):

Вызовом Public функций тоже пользуются только те кому эти функции нужны

Нет, Вы получаете другую, более замусоренную структуру областей видимости.

utkin написал(а):

чистая психология

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

переносите время написания кода на время отладки.

Где расчёт или измерения увеличения такой вероятности?
Пока всё с точностью до наоборот - избыточная видимость увеличивает вероятность ошибок.
Дано требование использовать переменную в указанном классе, а Вы требуете сразу сделать её повсеместно открытой.

внутренней целостности объекта

Целостность может касаться не только одного какого-то поля-двух, но и довольно сложной взаимосвязи.
Ещё пример. Даны три взаимосвязанных структуры Г,Д,Е с соответствующими полями ГдляВсех,ГдляД,ГдляЕ, ДдляВсех,ДдляГ,ДдляЕ, ЕдляВсех,ЕдляГ,ЕдляД. Требование: изолировать  от внешнего мира их поля друг для друга.
Ждём грамотного решения этой задачи.

utkin написал(а):

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

Здесь опять грязное смешение понятий структур данных и человеческой организации. А всё оттого, что не надо наделять области видимости названиями человеческих отношений.
Public, private и friend к людям не имеют отношения.

utkin написал(а):

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

Подождём решения на этой базе двух указанных задач.

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

0

29

Нет, Вы получаете другую, более замусоренную структуру областей видимости.

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

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

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

Пока всё с точностью до наоборот - избыточная видимость увеличивает вероятность ошибок.

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

Где расчёт или измерения увеличения такой вероятности?

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

Дано требование использовать переменную в указанном классе, а Вы требуете сразу сделать её повсеместно открытой.

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

Целостность может касаться не только одного какого-то поля-двух, но и довольно сложной взаимосвязи.

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

Ещё пример. Даны три взаимосвязанных структуры Г,Д,Е с соответствующими полями ГдляВсех,ГдляД,ГдляЕ, ДдляВсех,ДдляГ,ДдляЕ, ЕдляВсех,ЕдляГ,ЕдляД. Требование: изолировать  от внешнего мира их поля друг для друга.
Ждём грамотного решения этой задачи.

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

Public, private и friend к людям не имеют отношения.

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

Отредактировано utkin (Сегодня 13:17:18)

0


Вы здесь » Русскоязычное программирование » трибуна Уткина » Обшие (public) и Личные (private)