Comments 7
Очень жаль что победил Python, а не Ruby. Моё личное персональное мнение, которое может не совпадать с другими. Синтаксис с подчеркиваниями и переименование на лету на базе этого - выглядит как лютый костыль. А вообще в JS в своё время такое было, по конвенции ставили приватному в начале нижнее подчеркивание. А в Google было принято помечать в конце. Там защиты дополнительной не было, просто ты сразу знал куда лезешь. А потом появился TypeScript. Остаётся надеяться что Ruby воскреснет, но пока он застрял в Rails, по факту. Возможно это и погубило. А концептуально намного лучше чем Python, продуманнее и код выглядит чисто, как английский текст, без визуального мусора. И приватные методы там есть, но очень красиво сделано - пишешь private в середине класса и все методы что идут ниже - теперь приватные. И никаких подчеркиваний и никаких private на каждый метод. Идеальный способ.
...очень красиво сделано - пишешь private в середине класса и все методы что идут ниже - теперь приватные. И никаких подчеркиваний и никаких private на каждый метод. Идеальный способ.
Ну, т.е. как в Паскале :)
То есть чтобы сделать метод private нам нужно его перемещать вниз по файлу?
В git такое отслеживать сложнее потом
Такое происходит чрезвычайно редко. Ну и вообще по практикам кода обычно рекомендуется всё публичное сверху иметь, а приватное внизу, просто потому что когда человек заходит посмотреть что-то в файле обычно его интересует то что публичное, конкретная верхнеуровневая логика, а какие-то тонкости реализации, вспомогательные методы будут интересовать только если что-то не понятно в публичном. А вот если всё в перемешку делать - очень сложно разобраться чего-куда, получается хаос и плохой код. Особенно если в файле 300+ строк кода. Есть, конечно, иногда кейсы когда можно было бы за публичным сразу пару приватных, которые ну очень вот связаны в этом месте, но это спорный способ реализации. Обычно сверху всё что нужно видеть в первую очередь, снизу - глубокие детали. И это я на базе опыта в JS/TS, Ruby и Rust говорю.
Вроде неплохая статья, но со многим не согласен.
Геттеры сеттеры зло не потому, что они многословные. Пример с property не решает проблему геттеров, сеттеров (это же просто реализация). Проблема геттеров и сеттеров это то, что они противоречат инкапсуляции и по сути выносят наружу свойства, вместо обработки внутри класса (есть правило "Don't Ask, Tell"). Да и в целом не понял примера, ведь property это и есть геттеров и сеттеры, но они же "зло"
Поначалу, как мне кажется, проще все делать private (то есть `_attr`)
Двойное подчеркивание, зачастую июля библиотек нужно, чтобы не затерли случайно метод при наследовании
А так неплохую тему затронул, сам копал эту тему, но я к другим выводам пришел)))
Нормальная инкапсуляиция - выделение интерфейсов, когда вы просто заявляете что есть, а об остальном потребитель ни сном ни духом. Все эти "private" в языках наследников c++ - от бедности, когда технтчески понадобилось светить все внутренности потребителю класса и не надо проводить с ними параллели и пытаться повторить.
спасибо за статью. Очень нравится читать ваши статьи, потому что в них типичные вопросы и задачи описаны с очень интересной и необычной точки зрения.
Инкапсуляция в Python: property, name mangling и никаких кофемашин