Не так давно наткнулся на опус "Dear Python"
zideck.com
Вкратце, писатель сего опуса всячески ругает python за(в основном) отсутвие привычного ему(писателю) синтаксического сахара, что по его мнению ведёт к синтаксической избыточности. Помимо этого писатель опуса пытается доказать читателям опуса, что в python де не правильный OOP, так как в python якобы нет честной инкапсуляции. Я кинул сей опус на "поржать" нескольким товарищам из ростера, на что получил ответы виды "чевак прав, всё правильно сделал, батя одобряет", и стало мне грустно и обидно, как из ушата окатили. В представлении многих людей, вылезших из c++/java world инкапсуляция — это такая штука, которая явно(ключевым словом) позволяет сказать компиляторы какие методы/переменные внешний мир может видеть, а какие нет. А если внешний мир попробует их ронуть, компилятор ударит по рукам. Поэтому, как оказалось, бытоет мнение, что языки типа perl, python, lisp, etc не полностью поддерживают OOP парадигму, не давая возможности компилятору/интерпретатору бить юзера по лапам(в лиспе кстати методы/переменные класа можно защитить с помощью asdf, но это не относится к стандарту языка).
Хочется процитировать Буча: "Инкапсуляция, таким образом, определяет четкие границы между различными абстракциями. Возьмем для примера структуру растения: чтобы понять на верхнем уровне действие фотосинтеза, вполне допустимо игнорировать такие подробности, как функции корней растения или химию клеточных стенок. Аналогичным образом при проектировании базы данных принято писать программы так, чтобы они не зависели от физического представления данных; вместо этого сосредотачиваются на схеме, отражающей логическое строение данных [52]. В обоих случаях объекты защищены от деталей реализации объектов более низкого уровня." и
"Инкапсуляция — это процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение; инкапсуляция служит для того, чтобы изолировать контрактные обязательства абстракции от их реализации."
Ещё раз: инкапсуляция — это всего лишь одна из парадигм
дизайна архитектуры приложения, не более. Архитектор должен гарантировать, что в разработанной им моделе сокрытые данные инстансов классов не могут быть изменены извне. А уж как эти сокрытые данные обозначаются для облегчения
чтения и отладки: через private/protected, через __ илл любое другое соглашение — это дело десятое.
Так что пожалуйста перестаньте говорить, что языки, в которых нет private/protected — "не полностью объектно-ориентированные".
Voker57