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

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

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


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


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

Сообщений 31 страница 37 из 37

31

Это проблема человеческой организации, а не структуры данных. Представьте, что Вам нужна структура данных для некоторой задачи, ну при чём тут разработчики?
Если есть два - они либо равноправно обмениваются данными, проверяют весь код независимо и каждый отвечает за свою версию, либо один из них главный, а второй подчинённый. Для этого существуют системы контроля версий, которые совершенно не связаны с модификаторами 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)

0

32

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

Разработчик класса или разработчик friend?

Обычно класс и его friend пишет один и тот же человек (для тестирования вторым классом первого, например).

Отредактировано Лис (2017-12-19 07:58:54)

0

33

Обычно класс и его friend пишет один и тот же человек (для тестирования вторым классом первого, например).

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

Отредактировано utkin (2017-12-19 08:40:48)

0

34

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

всегда можно написать в Public.

Ага, метод с именем "публично: я-внутренний-диагностический-метод-только-для-тестирования-не-поминайте-меня-в-суе(типы параметры) {}"

0

35

Ага, метод с именем "публично: я-внутренний-диагностический-метод-только-для-тестирования-не-поминайте-меня-в-суе(типы параметры) {}"

Пишите префикс Test_ (debug_, temp_  и т.д.), складываете такие методы в одном месте подряд, визуально выделяете комментариями и нет проблем. Я на такие вещи уже давно не обращаю внимания и пишу таким образом на автомате.

0

36

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

Пишите префикс Test_ (debug_, temp_  и т.д.)

Писать это надо много раз, а директиву про friend - только один раз.
Автокомплит становится более длинным, как указывал MihalNik

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

0

37

Писать это надо много раз, а директиву про friend - только один раз.
Автокомплит становится более длинным, как указывал MihalNik

Все это с лихвой окупается вероятностью ошибки, поиск которой стоит гораздо дороже чем написание префикса. На секундочку набор префикса temp_ занимает менее секунды (если Вы будете писать это часто, это будет стоить Вам еще дешевле из-за постепенно нарабатываемого навыка). Написание текстов программ занимает абсолютно незначительное время. Значительно занимает время проектирования, а потом время отладки - читайте мануалы, это все написано и статистика есть. И если Вы недостаточно уделите время проектированию (а использование friend говорит именно об этом), то Вам придется значительное время уделять отладке. Есть механизм, есть цена его использования. Цена использования префиксов мала, потому что уже куча народа придумало и отладило это технологию. Цена friend не поддается исчислению, потому что Вы можете грамотно использовать этот механизм и будет Вам счастье, а можете запороть проект и получить убытки и по времени и по деньгам. Friend прямо несет угрозу времени проекта (не прогнозируемые затраты на поиск ошибок).

Фактически ты заявляешь "я таким не пользуюсь,

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

но если надо было бы то выкрутился бы"

Потому что есть проект, который выполнять все равно нужно.

А мы не хотим выкручиваться.

А Вас никто и не заставляет. Я написал претензии к friend. Предложите альтернативу. Давайте договариваться.

Отредактировано utkin (2017-12-20 13:42:15)

0


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