|
Болтовня Разговоры на любые темы (думайте, о чем пишите) |
12.04.2016, 13:20
|
#1
|
scientist.alien
Регистрация: 12.02.2007
Сообщений: 2,098
Написано 1,030 полезных сообщений (для 2,593 пользователей)
|
Protected internal private
Задался тут вопросом, а насколько вообще ценны в дизайне ЯП модификаторы уровня доступности?
Полезность public/private разделения я явственно ощущаю. А вот дальше начинаются "а что если"...
Была ли у вас реальная производственная необходимость использовать internal, и есть ли у вас серьёзные аргументы против идеи убрать private, оставив protected?
Рассуждения исключительно умозрительные, про "мой проект сломается" не упоминать - считаем, что делаем новый высокоуровневый ЯП.
__________________
Public service announcement: вы можете заблокировать отображение сообщений определённого пользователя, добавив его ник в список игнорируемых.
Tau lab. We LOVE you. We MADE you.
|
(Offline)
|
|
12.04.2016, 14:06
|
#2
|
Бывалый
Регистрация: 26.07.2009
Сообщений: 785
Написано 362 полезных сообщений (для 995 пользователей)
|
Ответ: Protected internal private
Сообщение от Taugeshtu
Была ли у вас реальная производственная необходимость использовать internal
|
Да.
Сообщение от Taugeshtu
есть ли у вас серьёзные аргументы против идеи убрать private, оставив protected?
|
Нет, приват и протектед стоит разделять.
|
(Offline)
|
|
Сообщение было полезно следующим пользователям:
|
|
12.04.2016, 14:17
|
#3
|
scientist.alien
Регистрация: 12.02.2007
Сообщений: 2,098
Написано 1,030 полезных сообщений (для 2,593 пользователей)
|
Ответ: Protected internal private
Нуууу, так не интересно, а аргументы где?
__________________
Public service announcement: вы можете заблокировать отображение сообщений определённого пользователя, добавив его ник в список игнорируемых.
Tau lab. We LOVE you. We MADE you.
|
(Offline)
|
|
12.04.2016, 15:05
|
#4
|
Unity/C# кодер
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений (для 5,323 пользователей)
|
Ответ: Protected internal private
Все private и internal методы/поля/свойства/классы мы обфусцируем.
protected при наследовании часто использую, их никому не видно, кроме наследников.
internal на уровне dll видно, если проектируешь dll для кого-то, то делаешь интерналами все что не надо видеть всем кто "снаружи", но надо иметь доступ отовсюду в самой dll.
C точки зрения Unity - internal не сериализуется, хоть и видна всем. Не надо дополнительного атрибута NonSerialized для публичных полей.
Опять же с точки зрения Unity для методов событий типа Update использую protected чаще чем private потому, что тогда решарпер их не подкрашивает, что это метод не используется нигде.
|
(Offline)
|
|
Сообщение было полезно следующим пользователям:
|
|
12.04.2016, 16:54
|
#5
|
Принтер
Регистрация: 21.04.2013
Адрес: Больше не РФ
Сообщений: 569
Написано 342 полезных сообщений (для 1,242 пользователей)
|
Ответ: Protected internal private
protected очень даже нужен, когда надо работать с наследованием. Его отсутствие бы сильно усложнило (точнее, прокопипастило), вроде как, элементарный код.
Насчет internal уже не знаю, что сказать, но pax имхо довольно четко проаргументировал "за".
Где-то в собственных сырцах есть хороший пример для protected (на PascalABC.Net), только хз, где он.
p.s. да, я каннибал, а еще я люблю баловаться с инвалидами.
|
(Offline)
|
|
12.04.2016, 17:01
|
#6
|
Unity/C# кодер
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений (для 5,323 пользователей)
|
Ответ: Protected internal private
Сообщение от pax
internal на уровне dll видно, если проектируешь dll для кого-то, то делаешь интерналами все что не надо видеть всем кто "снаружи", но надо иметь доступ отовсюду в самой dll.
|
Прокомментирую сам себя еще, опять с точки зрения Unity. Пример: пишешь плагин, ложишь его в папку Plugins. Используешь internal по своему усмотрению. В обычных скриптах, которые не в Plugins, а в самом проекте, этих internal'ов не видно. Никто не получит доступ к неконтролируемому полю, если специально не зайдет и не отредактирует исходники плагина. Почему интерналы в плагинах не видно и так понятно - отдельная dll, компилирующаяся до остального кода.
|
(Offline)
|
|
12.04.2016, 17:02
|
#7
|
scientist.alien
Регистрация: 12.02.2007
Сообщений: 2,098
Написано 1,030 полезных сообщений (для 2,593 пользователей)
|
Ответ: Protected internal private
Гм. В моей голове это всё звучало как-то стройнее... Попробуем ещё раз:
Если вам предложат писать на языке, в котором есть только public и protected, вас вырвет, или даже понравится? Ну так, чисто гипотетически.
__________________
Public service announcement: вы можете заблокировать отображение сообщений определённого пользователя, добавив его ник в список игнорируемых.
Tau lab. We LOVE you. We MADE you.
|
(Offline)
|
|
12.04.2016, 17:17
|
#8
|
Unity/C# кодер
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений (для 5,323 пользователей)
|
Ответ: Protected internal private
Сообщение от Taugeshtu
Гм. В моей голове это всё звучало как-то стройнее... Попробуем ещё раз:
Если вам предложат писать на языке, в котором есть только public и protected, вас вырвет, или даже понравится? Ну так, чисто гипотетически.
|
Ну имхо это уже проблема языка и того, кто предложил, а не программиста, которому задачу решать надо. И ограничение это совсем другое, это не то, когда есть на выбор что использовать. Опять же, когда есть выбор, то все зависит от поставленных задач. Что было бы, если бы все приватные переменные классов Net Framework стали бы protected? Даже те, которые связаны с неконтролируемыми ресурсами. Все бы наследовались от этих классов и ломали бы все что можно.
|
(Offline)
|
|
12.04.2016, 18:40
|
#9
|
Терабайт исходников
Регистрация: 13.09.2008
Сообщений: 3,947
Написано 2,189 полезных сообщений (для 6,051 пользователей)
|
Ответ: Protected internal private
я всё (почти) делаю public, и мне ок.
|
(Offline)
|
|
12.04.2016, 19:40
|
#10
|
Элита
Регистрация: 16.01.2010
Адрес: Новосибирск
Сообщений: 2,157
Написано 502 полезных сообщений (для 1,012 пользователей)
|
Ответ: Protected internal private
Сообщение от Mr_F_
я всё (почти) делаю public, и мне ок.
|
Солидарен, если это конечно не отдельная dll. Правда и тут бывают неудобства.
Вчера пытался положить отдельную текстуру на глаз(смотри тему c# + OpenGL) (тз изменили, приспичило несколько видов радужки), так оказалось что только на процедурных моделях можно это делать, а на загруженных нет. Капец это было проблемно, так как поле SubMeshes было protected readonly. Узнал я это только после того, как написал issues автору библиотеки, ибо в исходниках сложно было найти не зная что искать. Быстро ответил и изменил protected на public, через 6-8 часов.
|
(Offline)
|
|
Сообщение было полезно следующим пользователям:
|
|
12.04.2016, 19:51
|
#11
|
[object Object]
Регистрация: 01.08.2008
Адрес: В России
Сообщений: 4,357
Написано 2,472 полезных сообщений (для 6,854 пользователей)
|
Ответ: Protected internal private
Сообщение от Taugeshtu
Если вам предложат писать на языке, в котором есть только public и protected, вас вырвет, или даже понравится? Ну так, чисто гипотетически.
|
А такое встречается довольно часто. Всё хорошо пока работаешь один.
Мне кажется эти искусственные ограничения как раз придуманы для ситуаций когда кода один кодер завещет другому код и как-бы объясняет:
Вот это наследуй и перегружай (protected)
А вот эту фигню лучше не трогать (private)
Но это всё усложняет. Заведомо предугадать как будут перегружать твои классы и всё при этом учесть очень не простая задача.
__________________
Retry, Abort, Ignore? █
Intel Core i7-9700 4.70 Ghz; 64Gb; Nvidia RTX 3070
AMD Ryzen 7 3800X 4.3Ghz; 64Gb; Nvidia 1070Ti
AMD Ryzen 7 1700X 3.4Ghz; 8Gb; AMD RX 570
AMD Athlon II 2.6Ghz; 8Gb; Nvidia GTX 750 Ti
|
(Online)
|
|
Сообщение было полезно следующим пользователям:
|
|
12.04.2016, 20:38
|
#12
|
Unity/C# кодер
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений (для 5,323 пользователей)
|
Ответ: Protected internal private
Сообщение от Mr_F_
я всё (почти) делаю public, и мне ок.
|
И работаешь наверное с проектом один?)
Ну и Рандом правильно говорит, все эти филосовские мысли только когда один сидишь прогаешь, пусть будет все пабликом, чего от себя самого скрывать все. Все меняется, когда работаешь в команде. В команде и правила написания кода применяются и правила комитов и комментариев. Топикстартер вероятно от того же программирования проектов в одиночку начал придумывать для себя, зачем мне эти ненужные модификаторы нужны то.
|
(Offline)
|
|
12.04.2016, 20:39
|
#13
|
Терабайт исходников
Регистрация: 13.09.2008
Сообщений: 3,947
Написано 2,189 полезных сообщений (для 6,051 пользователей)
|
Ответ: Protected internal private
И работаешь наверное с проектом один?)
|
да
|
(Offline)
|
|
12.04.2016, 20:41
|
#14
|
Unity/C# кодер
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений (для 5,323 пользователей)
|
Ответ: Protected internal private
Сообщение от Mr_F_
да
|
Ну коммент я выше дописал.
|
(Offline)
|
|
12.04.2016, 20:50
|
#15
|
Unity/C# кодер
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений (для 5,323 пользователей)
|
Ответ: Protected internal private
Сообщение от RegIon
Солидарен, если это конечно не отдельная dll. Правда и тут бывают неудобства.
Вчера пытался положить отдельную текстуру на глаз(смотри тему c# + OpenGL) (тз изменили, приспичило несколько видов радужки), так оказалось что только на процедурных моделях можно это делать, а на загруженных нет. Капец это было проблемно, так как поле SubMeshes было protected readonly. Узнал я это только после того, как написал issues автору библиотеки, ибо в исходниках сложно было найти не зная что искать. Быстро ответил и изменил protected на public, через 6-8 часов.
|
Приведу пару примеров:
1. Все открыто, ты меняешь какую-то одну переменную открытую, проблем особо не замечаешь. Потом работаешь дальше, начинают какие-то странные проблемы появляться. С чем это связано? А вот автор той dll не подразумевал, что кто-то будет менять эти переменные, это его "магические числа" что только с ними все работает. И в результате тратишь ппц сколько времени, на то чтобы разобраться.
2. Второй огромный минус когда все открыто - ты подключаешь библиотеку и на тебя сваливается гора ненужных методов и переменных, которые вообще не нужны тебе и всем остальным. Только автору самой библиотеки. И ты должен тратить уйму времени, чтобы отсеять для себя только то, что именно тебе необходимо. Которое выполняет функционал, для которого библиотека предназначена.
|
(Offline)
|
|
Эти 3 пользователя(ей) сказали Спасибо pax за это полезное сообщение:
|
|
Ваши права в разделе
|
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения
HTML код Выкл.
|
|
|
Часовой пояс GMT +4, время: 18:42.
|