Comments 106
Если кто-то реально натыкался в других языках с private и protected методами на случаи, когда нужный метод в результате архитектурной недальновидности авторов кода объявляется private, а он позарез нужен в наследниках, тот с вами несомненно согласится.
С protected ещё можно костыльно отнаследоваться и открыть метод в наследнике, но невольно возникает вопрос — на кой чёрт его было прятать? Что это за синдром вахтёра в программировании?
Но некоторые вещи нельзя спрогнозировать заранее, поэтому возможность вызвать защищенные или приватные методы без танцев с бубном — это соломка на будущее.
Да и доступ требуется не для любого приватного метода, который «позарез нужен», а в том случае, когда без этого уже не обойтись (отсутствуют исходники, нарушается логика работы при переходе на новую версию из-за корявой архитекторы и т.д.)
Типичное общение некоторого кодера на stackoverflow или другом форуме:
— Срочно! Подскажите как вызвать A!?
— Ну… Наверное A можно вызвать через B… Но это вызовет утечку памяти и будет убивать по одному котёнку за каждый вызов. Ты пытаешься добиться C? Или может быть D? Правильней делать это через E, F и G… Объясни подробней.
— Спасибо!!!111 Сделал вызов A через B. *исчезает с форума до следующей проблемы*
Может просто автора, что не может правильно разграничить public/protected/private вообще не пускать к компьютеру? Думаю, это будет лучшее решение.
- Если я за каждую ошибку перестану пускать программиста к компьютеру, то очень скоро останусь без программистов.
- Бывало, что программист неправильно разграничил правила доступа — объявил публичным только то, что требовалось внешним процедурам на тот момент, а остальное закрыл. Программист уволился, а мне для новой функциональности потребовалось вызвать вполне безопасный метод его класса (на С++). Проверяю, что вызов безвреден, и перевожу его в публичные. А как ещё?
- Согласен с автором поста. Вызов приватного метода должен выдавать не ошибку компилятора, а только предупреждение. Если человек предупреждён, то вся ответственность за последствия переложена на него. Но это я говорю как плюсист. Нельзя запрещать мне выстрелить себе в ногу, если мне это очень надо. Сторонники безопасности могут иметь иное мнение.
Все кто используют мой класс должны использовать только публичные методы
нет, они вам ничего не должны, они свободные люди, но вы вправе не принимать претензии от них по поводу использования непубличных методов.
Мал того IDEшечка в автокомплите не должна показывать мириады методов
вероятно, но этот никак не противоречит описанному, соглашения об именовании для этого достаточно
Если в лицензии написано, что должны использовать только публичные методы, то будь добр выполнять это ограничение, а не нравится — ищи другое ПО или пиши класс сам.
Матом тоже можно разговаривать, вот только тебя мало кто будет слушать.
P.S. Сама лицензия GNU GPL, предлагая пользователям свободное ПО говорит, как его использовать, а именно, требует сохранения данной лицензии в производных продуктах. С одной стороны, это вполне правильно, с другой — «Если ты уже поделился чем-то с другими, не диктуй им как они должны это использовать, они сами отвечают за свои действия». В особенности это касается риторики относительно использования свободных продуктов совместно с несвободными, которая сводится к «не используйте несвободные продукты, т.к. нам это не нравится и вы должны быть свободны».
Ограничения к тому, что приватный метод только для того, чтобы работать с данными так, как нельзя работать извне этого класса.
Ну вот, возьмём для простоты свойство класса. Вот оно публичное. Можно в свойство записать любое значение, а потом работать с ним, правильно? Ну собственно почему бы и нет. а если в свойство внесли данные не того типа, что может произойти?
А если и свойство приватное, то с ним работать можно только через метод-сеттер (утрированно) и уже в методе сделать все нужные проверки и не возлагать эту работу на программиста который пользуется классом.
Так и с методом приватным, он создан для того чтобы делать внутреннюю работу класса. Для внешней он не приспособлен, да и можно быть опасен.
Кстати, в питоне же есть модули? А у них есть понятие списка экспортов, чтобы некоторые вещи можно было, ну, не экспортировать из модуля?
ну, там можно импортнуть не весь модуль, типа:
from random import choice
from string import ascii_lettersНасколько знаю, нет. Всё, что есть в модуле можно брать снаружи по честному и не очень.
Прям приватного нет. Есть __all__. А ещё в случае пакетов можно в ините можно импортировать нужные вещи из вложенных пакетом/модулей и только самые сообразительные найдут что ещё есть, посмотрев состав файлов.
- приватный метод может не иметь никаких проверок аргументов
- циклические вызовы
- нет гарантии, что приватные методы останутся или сохранят свой контракт при обновлении, нужно _специально_ лезть в код и смотреть на то что происходит, а если этоих мест много?
- следовательно, о приватных методах не пишут в документации
- заведомо бунтуете против архитектуры интерфейса некоторого класса
Ещё приватные методы могут оставить объект в невалидном состоянии. После чего объект использовать небезопасно.
Хотя в некоторых случаях бывает просто никак не обойтись без вытаскивания «кишков» класса наружу, и такая возможность, хоть и проктологическая, должна быть, но по умолчанию лучше всё же их скрывать. Потому что позиция «вот вам все потроха, юзайте, но за 90% непубличных методов и полей я не ручаюсь, все на свой страх и риск» не очень работает. Обязательно будут применять к месту и не к месту, методики разлетятся по сети, устаканятся, каждый релиз превратится в кошмар с воем кучи костылестроителей, все будут сидеть на старых версиях, потому что на новые сложно переползать и т.д.
Более продуктивным мне видится контакт с разработчиком и повышение видимости нужных методов, либо добавление средств доступа к ним. Конечно, это далеко не всегда возможно, но к этому стоит стремиться
Оно существует только потому что людям так удобно. Удобно тянуть из других языков те концепции, которые им привычны.
В ООП языка X есть изоляция методов? Ну раз с питоном пришлось работать, буду считать, что сокрытие имён — это тоже самое, что и приватные методы. Потому что так удобно.
А то, что по факту это — натягивание совы на глобус мало кого волнует и оказывается, что изоляция методов в питоне внезапно работает не как в языке Х. Но на самом деле её просто нет, поэтому она и не работает. А не потому, что разработчики питона любят или так и задумано, чтобы попортить жизнь плохой реализацией ООП.
Не для всех библиотек указаны хинты
пока да, но насколько мне известно ситуация улучшается
не любая семантически корректная программа (на Тьюринг-полном языке) типизируема для любой системы типов
ну это уже другой вопрос, не о проверке типов, а о самой системе типов, тут я ничего не могу сказать по поводу того насколько она в питоне хороша — некомпетентен
Как mypy следит, какие типы аргументов были указаны как дефолт-параметры getopt, а какие ожидаются?
ну так навскидку никакой проблемы не должно быть, дефолт же присваивается в случае отсутствия значения, соответственно при присвоении значения не того типа mypy должен ругаться, но конечно при условии наличия тайпхинтов (хотя часть проверок типов и без них работает, может и сработает)
Концептуальная проблема private и protected методов в питоне состоит в том что их нет.
Нет абсолютно никаких гарантий что "приватный" метод который меняет стейт объекта и может сделать его неконсистентным, и который логически предназначен для использования только изнутри класса, не будет вызван каким-то умником который лучше автора библиотеки знает что нужно делать.
Защита от дурака — это фундаментальная концепция которой следуют все кто работает в команде и пишет софт с циклом поддержки длиннее одной недели. И да, модификаторы доступа — это не попытка объявить машину умнее человека а наоборот — инструмент для умного человека организовать код так, чтобы им можно было пользоваться только правильным и безопасным способом.
Очень забавно поведение питонистов, которое я не встречал среди адептов других языков — очевидные недостатки языка обмазываются доводами "почему и так можно" и объявляются "философией языка".
Да, можно в автомобиле расположить движок на пассажирском сиденьи и сказать "просто не касайся его чтобы не обжечься", предоставив пользователю авто "полною свободу". Можно ходить по улице без с голой задницей, окружающие ведь могут просто не смотреть на вас. Можно прикрепить к ложке бритву и сказать — "это особая, правильная философия столовых приборов. чтобы не порезаться просто держи вилку правильно. жаль что другие производители ложек не понимают таких простых вещей".
Но никто так не делает.
На самом деле python ненавидит вас, если вы пытаетесь написать что-то сложнее скриптов на 300 строк, но вы действительно можете поиграть в стокгольмский синдром и объявить эту ненависть особой философией любовью.
Очень забавно поведение питонистов, которое я не встречал среди адептов других языков — очевидные недостатки языка обмазываются доводами «почему и так можно» и объявляются «философией языка».
JS такой же. Нету наследования? Зато есть прототипирование, это намного лучше! Нет приватных членов класса? А зачем, мы ведь за открытость, называйте с "_" в начале и всё будет ОК. Все-таки хотите, чтобы совсем-совсем нельзя было достучаться? Ну тогда вот вам варианты *пяток проктостоматологических решений*. Замыкания взрывают мозг? Так это базовая фича, с помощью которой можно делать зашибенские штуки *пример хитрозадой и полностью синтетической конструкции*.
Наследование запросто реализуется через прототипирование, а сейчас так вовсе вошло в стандарт.
С приватными членами — да, сначала был облом. Но теперь есть символы, и хотят ввести собственно приватные члены. А "проктостоматологические" решения остались в проктостоматологиях.
Замыкания интуитивно понятны.
Наследование запросто реализуется через прототипирование
Не совсем. К сожалению, навскидку не назову, где прототипы дают сбой. То ли в проверке цепочки наследования, то ли еще где-то
Не совсем. К сожалению, навскидку не назову, где прототипы дают сбой. То ли в проверке цепочки наследования, то ли еще где-то
Да не дают они сбоев, если все правильно сделано.
Возможно, вы вспомнили конструкцию наподобие this.constructor.prototype для обращения к базовому классу — она и правда даёт сбой. Но стоит только перестать пытаться сделать все "красиво" и "по-джеэсному", и просто обратиться к базовому классу по имени — и вот уже все работает как надо.
Я например часто использую обращение к приватным полям класса, для логирования и поиска ошибок.
А почему бы логирование не разместить прямо в нужном классе?
Как показывает практика в системах, в которых работают квалифицированные рабочие зачастную нет защиты от дурака.
Её нет потому, что её просто невозможно ввести, либо ценность рабочей силы настолько низка, что вводить меры безпасности нерентабельно. В этом даже есть своеобразная философия.
Python не запрещает вызов private/protected методов потому, что любит тебя :-)
Для меня эта фраза звучит так: «Наша система защиты от дурака позволяет обойти её, потому, что любит тебя :-)»
Надеюсь, мне удалось улучшить объяснение философии питона и высмеять другие подходы )
Нет, просто Вы пытаетесь оправдать сомнительный дизайн языка образца 1990 года, выдав его за некую философию, а его создателя возвести в ранг пророков.
принцип свободы и ответственности: «Если ты уже поделился чем-то с другими, не диктуй им как они должны это использовать, они сами отвечают за свои действия»,Есть принцип защиты от дурака («poka-yoke»), и японцы применяют его в Произвдственной Системе Тойота (Toyota Production System — TPS) не потому что считают людей дураками. А потому, что вещи не должны допускать возможности неверного использования. Трудно себе представить во что превратилась бы наша жизнь, если бы этот принцип не существовал.
Но питон тут можно понять. Зачем делать ограничения, которые все равно будут обходить?
Вот в java есть рефлексия. И вот тогда появляется проблема двойного стандарта. В школе учат инкапсуляции, а на работе узнаешь что мол да, но не всегда, потому что иногда «подругому никак». Так вот у питона тут совесть чиста.
Надо заниматься просвещением, и учить людей принимать осознанные решения. А не вводить бесполезные запреты.
См. также:
Вобщем, запреты не работают. Голландский менталитет.
Слышу кто-то кричит — может сломаться при обновлении, конечно, но раз вы целенаправленно использовали непубличный метод, то понимаете этот риск (если нет, то вы не на своём месте).
Расчет на то, что каждый кодописатель на своем месте, делает эту аргументацию бессмысленной. Кодеры бывают разные, а язык тем лучше, чем меньше возможностей сделать ошибку, программируя на нем, особенно если она не для всех очевидна. В конце концов, языки изобретают для того, чтобы выражаться, а не боятся сделать ошибку.
Если язык позволяет, и пользователь кода этот метод все же вызывает, это мис-юз, неправильно использование и непонимание автора, поломаная коммуникация. Какой смысл в таком соглашении, неясно. Я думаю есть какието иные, эффективные внутренние причины не обеспечивать видимость методов в Питоне, нежели просто соображения «нельзя, но можно, если очень хочется».
Такая возможность языка провоцирует небрежность в разработке. Разработчик кода предположил, что метод "foo" должен быть приватным, а вам вдруг понадобилось в своём коде дёрнуть этот приватный метод как публичный. Ну вы и дёрнули. Вместо того, чтобы обратиться к разрабу и сказать, что его вИдение прекрасного не так уж и совершенно. Эта особенность языка python помогает кодерам думать, что они более сообразительные, чем есть на самом деле, вместо того, чтобы делать код более совершенным. Для кого-то это хорошо, кому-то — не очень.
так как пользователь всегда прав и лучше знает, какой функционал ему нуженА потом у библиотеки меняется что-то в кишках, и после обновления у «всегда правого» пользователя все внезапно ломается с неопределенным уровнем последствий. Смысл приватных полей в том, чтобы убрать зависимость и контроллировать сложность. Если пользователь класса начинает обращаться к приватным полям, они перестают отличаться от публичных. Не понятно зачем таким полям вообще может понадобиться отдельное ключевое слово в языке.
А комментирующие разделены на 2 группы:
- Не стоит ограничивать пользователей, они же умные. Да бывает иногда нужно и посушить плюшевую кошку.
- Нужно поставить запрет на включение микроволновок, если внутри любой объект не похожий на еду.
Кажется, что решение этой проблемы уже давно известно.
Попробуйте объяснить эту философию архитектору проекта на несколько миллионов строк кода. В проектах с кровавым энетрпрайзом, где задействовано куча народу разных мастей, гораздо безопаснее вообще насовсем запретить использование приватных методов (например джунам или командам внедрения), нежели разрешить если очень хочется, а потом разгребать последствия вот такой вот философии "как бы нельзя, но на самом деле можно если хочеться".
У питона нет этого инструмента индустриальной разработки и точка. Нижнее подчеркивание и всеобщее соглашение в некотором роде его заменяет, но лучше, когда эту работу делает синтаксис, а не наш мозг.
но лучше, когда эту работу делает синтаксис, а не наш мозг
но она требует обоснования, думаю в обоих случаях всё делает мозг и вопрос «лучше» это лишь вопрос привычки, хотя мне кажется что дополнительные слова как раз замусоривают код.
она требует обоснования
- При использовании интерфейса извне проще игнорировать недоступные методы класса.
- При расширении интерфейса проще не думать о его внутренней реализации. Даже об именах надо думать, чтобы не переопределить случаем.
- Самое важное, при изменении класса не нужно задумываться, используется ли этот код или нет.
В крупном проекте эффекты очень легко ощущаются, но и в мелком одиночном хобби проекте бенефиты инкапсуляции можно заметить: я сейчас и я через месяц — это разные люди.
Для сравнения представим, что мы разрабатываем внутренний банковский проект с REST API. Внутри всё сделано на SOA. Что будет, если придерживаться подхода Python или Javascript:
- Все внутренние API [микро]сервисов торчат наружу
- Огромная OAS документация
- Но куски API из микросервисов там обозначены «internal», дескать, избегайте использования
- Зато у клиентов максимальные возможности по использованию сервиса
- Но они их используют как-то по-своему, а не как мы планировали
- Поддержка и изменение проекта — филиал ада для разработчиков
Это гиперболизированное сравнение, но логически аналогично.
Python не запрещает вызов private/protected методов потому, что любит тебя :-)