ООП сейчас не все используют⁠⁠

Знаешь, рассказывать, что инкапсуляция это не сокрытие, это в наше время примерно то же самое, что рассказывать, что у человека нет инстинктов. Формально верно, но на самом деле спор об определениях.

Ну и много ты сейчас видел кода, в котором вот такие объекты типа собак? Тем более кода, где эти собаки бывают разных пород, чтобы применялся полиморфизм?

Тоже полыхнуло

, инкапсуляция, с необходимостью в гетерах и сетерах, не нужна в пайтон (такова философия языка)

С чего бы это в пайтоне нет необходимости в геттерах и сеттерах с точки зрения философии языка? То, что вместо функции set_a ты пишешь вначале property a, а затем a.setter ничего принципиально не меняют.

Есть более строгие и широкие определения.

Инкапсуляция - это не просто хаотичное объединение данных, это разделение на логические абстракции и так же разделение их публичных контрактов от реализации. В строгом определении инкапсуляция подразумевает в себе абстракцию данных. Если вы запихнули все в один класс на 20к строк (объединили данные и методы), то это не инкапсуляция.

Нарушение инкапсуляции ведет к побочных эффектам и потенциальным ошибкам. В других языках закладываются ограничения специально, чтобы не было исскушения лезть куда не надо. В Python это всё на соглашениях, только и всего. А так и в тех же Java|C#|C++ есть способы обратиться к приватной переменной.

Абстракция данных - это не принцип ООП как таковой, это общий принцип проектирования хороших программ и используется не только в ООП.

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

Полиморфизм - возможность обращаться одинаковым образом с сущностями разных типов. Это касается не только иерархии классов. Переопределяемые функции тоже являются частью полиморфизма, те же print, len и другие (ad-hoc и параметрические полиморфизм).

Пойду открою окно, а то душно стало...

как собеседующий, правда AQA, отвечу - ради охуительных историй примеров. Для AQA SOLID это вопрос для сеньоров и уверенных мидлов и он обычно звучит не "что такое солид", а "почему им надо пользоваться". У сеньора к этому времени должен появиться хоть один любимый принцип, на примере которого он расскажет или почему АТ-фреймворк стал удобней и читабельней благодаря соблюдению, или как после нарушения начался анал-карнавал.

Если АQA к своему сеньорству не спроецировал solid на свой практический опыт, это не то что проблема, но тревожный звонок.

автор, не кипешуй. сейчас наплодилось ебланов, прошедших говнокурсы, которые мнят себя программистами. а сколько еще наплодят (господдержка же теперь)! так что на все реагировать - никаких нервов не хватит )

инкапсуляция, наследование, полиморфизм

С этим я не спорю.

Просто позиция вашего оппонента - что ООП используют не полностью, и я с этим в принципе согласен. Как я написал выше, часто проще не инкапсулировать состояние, а разделять на класс с чистыми функциями и тупую дтошку без логики. Хотя это противоречит ООП, но прекрасно работает. В частности, решает проблему лопаты.

Хотя, конечно, инкапсуляция не про геттеры и сеттеры - с этим я полностью согласен.

В общем, ООП сейчас не такая незыблемая парадигма, как может показаться.

Только не функций, а «подпрограмм», это могли быть как функции (call/ret), так и просто выделенные куски кода (jmp с ручным управлением адресами возврата)

"переписать" - суть поменять, похуй что ты делаешь, ты использовал именно формулировку "переписать", на что я тебе и указал, что если ты придираешься к словам будь добр сам быть точен в словах, но ты даже не прочитав что я сказал начал оспаривать что ты всё правильно делаешь - я ни слова не писал о том, что ты делаешь, я чётко написал "формулировки"

А уж кусок что ты привел - нахуя? Кому ты что этим доказал?

Перечитай что я написал - "Если критикуешь других за неточности формулировок будь добр сам быть поточнее" - это называется не переопределение, а доопределение, метод должен быть закрыт для изменений - какие нафиг "переопределения"? Метод открыт для дополнения, а именно для "доопределение"

причем тут ооп и микросервисы? Это разные уровни совсем. Микросервис как раз и будет инкапсулировать какую-то часть логики нид для бэка

А куда code reuse дели? Тоже к ООП относится.

да, пишу автотесты и участвую в развитии АТ-фреймворка.

у меня там статусы пациентов, которые группируются и заполняются на основе отделения которое приняло больного, имеют разные поля в зависимости от того обследуется человек или лечится, но одни и те же действия "принимаем--обслуживаем-переводим в другое своё отделение-даём направление в другое учреждение-выписываем".
Есть события рабочей смены, вида отгул-стандартная смена-ночная-сверхурочные-больничный-дежурство. Интерфейс у них один на всех, предок общий ибо три поля(день, время-начало, время-конец) есть у всех. Потом кстати более разветвлённое наследование, потому что и дальше можно группировать. Но действия у всех одни.

У меня до пизды классов из трёх-пяти полей и этак пяти методов, потому что с точки зрения бизнеса всё довольно просто, список систематически проверяемых значений небольшой, часть полей проверяется в 70 тестах и идёт в DTO, часть в 7 и проверяется непосредственно в тесте. А ещё для некоторых проверок я в очень упрощённом виде копирую полноценную работу приложения, например чтобы свериться что разрабы считают надбавку за сверхурочные по правильной формуле.

Ну и отдельные сто грамм про DTO. DTO - охуенная тема. В API тестах пишешь хороший годный DTO, может даже нагло копируешь у разрабов. Ответы с бэка в него парсятся просто отлично, пихать весь DTO в асёршен вместо построчной проверки по полям волшебно. Переиспользовать его для создания более сложных объектов и передачи части полей сразу в другой объект куда удобней чем ковырять построчно или писать методы-уродцы на 3-5 параметров. Потом берёшь и цепляешь API-репо как зависимость к UI. Этот же DTO используешь для парса объектов с UI, потому что это тот же бизнес-объект, просто представленный в ином формате. У тебя везде одинаковый объект для работы с некой бизнес-сущностью, даже полный дегенерат не сможет забыть проверить поле или заполнить его неправильно, потому что или получит эксепшеном в консоль, или будет трахаться с падающим асёршеном на дебаге. Если заказчик и как следствие приложение отказались от поля, поменяли формат, нассали в тапки, всё чинится в одном месте, а не во всех автотестах.

и да, можно пихать гиен в кошек(не буквально). Пока разделение идёт на уровне кошки/собаки, я не буду ебать себе мозги с строгой терминологией и буду называть кошкобразных - кошками, а собакообразных - собаками. Птица так-то тоже слишком широкий термин, но пока он применим - нехер усложнять. Вот если придётся виверровыми оперировать, вот тут придётся брать более детальную абстрактную модель.

...и объяснять джунам что такое виверровые.

Что питон, что си++/ява слишком узко трактуют изначальные принципы. Реакция на события и взаимодействие событиями первичны (а вовсе не частная реализация на таблицах указателей), так что в этом смысле SmallTalk/Objective-C/Self бОлее ООП системы, чем обсуждаемые.

Исторически ООП задумывалось в таком виде: программа проектируется как множество объектов

Есть "исторически" а есть "практически". История ушла (это где там сообщения ыли ... в smalltalk'е?)

На практике ООП слишком часто использут и злоупотребляют наследованием.

Вообще польза в ООП не в том, что делать можно, а в том что делать нельзя. Например хочешь ты данные покоцать, а не дают, потому что они скрыты.

Или хочешь ты метод написать, который принимает только млекопитающих, и в него нельзя засунуть автобус. Для этого система типов нужна.

Или очешь ты дать возможность переопределить метод, но только один а не все сразу.

Ну и так далее...

А в питоне у нас вместо ограничений duck typing...

Как это? Все сломает! У нее сразу скорость будет 30км/ч вместо ожидаемых 0.

Все, гонка выиграна

То есть все методы которые работают с полями обьекта и есть инкапсуляция?

Кардинально все меняется! Нужно правильно софт писать и будет все ок! Никакой неправильпый порядок не помешает! Валидируем данные, паттерн State и State Machine еще почитай  - и все ок

Представьте что вы пишете библиотеку которая используется на всем проекте, и какойто вася гдето меняет значение поля напрямую и весь проект идет по пи...

А если это еще и не обычный сайт а например управление цехом на заводе? А если управление космическим кораблем? Атомной электростанцией?

Можно писать что угодно - вопрос - зачем нужна инкапсуляция?

что за пример - dog = cat? при чем это вообще

я навел конкретный пример - собака не начинала даже бежать - а скорость уже равна 30, координаты собаки тожде не менялись, и т.д.

ограничение тоже важно! то что вы рассказываете - это просто архитектурное решение!

Инкапсуляция позволяет также скрыть от прямого доступа информацию обьекта

к примеру - сделали

const dog = new Dog();

//dog.run() мы не вызывали.
и напрямую делаем
dog.speed = 30;

Это норма? то есть собака бежать даже не начинала - а скорость ее уже 30 км/ч

Я python не шарю - но судя по спичу - инкапсуляции в нем нет.

private методы и поля есть в python?

Под абстракцией я понимаю более узкое определение - абстракция некое описание/представление объекта. Описание отдельно - операции с данными отдельно. Интерфейс - класс имплементирующий этот интерфейс.

Под сокрытием я тоже не про private/protected. А скорее про то что вызывая метод объекта, пользователь не видит что происходит в этом методе, есть набор параметров и есть ожидаемый результат, все что внутри - черный ящик, инкапсуляция

Странно... Точно помню что меня учили именно 4 принципам ООП. Питон вообще не знаю, не думал что там так устроено и этот аспект оставлен на ответственность разработчика.

Эм. Какие меньше 10 лет?)))) Я когда начинал изучать, лет 15 назад, уже была одним из принципов.

Про сокрытие. В питоне вообще невозможно скрыть внутреннее состояние объекта?

Нахера объяснять, если не умеешь?

Рефлексию тоже не просто юзать ) но, если мне не изменяет память, тот же Spring на ней целиком построен был, из-за чего и поломался при очередном обновлении Явы, где этот механизм поменяли.

Да, в Питоне много чего не в реализации языка, а в соглашениях, но это естественно - чем больше динамики в языке, тем больше там соглашений.

Вроде всю жизнь было 4 основных принципа ООП? - Абстракция, инкапсуляция, наследование, полиморфизм.

Инкапсуляция - именно что сокрытие. Сокрытие внутреннего состояния, предоставление публичного набора методов.

Ну как нет, если два подчеркивания добавить - напрямую, как к обычным полям обратиться нельзя.

Также и в Яве - напрямую нельзя, но через рефлексию можно и private править. По геттерам-сеттерам да, их основной смысл не в сокрытии данных, а в доп обработке.

> а у функции на входе аргументы или параметры?

При вызове аргументы, при использовании параметры. Но тут похуй, честно говоря) 
Да и с функциями тоже на самом деле, ты прав)

Все это круто, но в реальности несколько сложнее.

Во-первых, выделение интерфейса логической сущности и изоляция внутренней логики - то, как вы описали инкапсуляцию - присутствует практически во всех парадигмах. В рамках ФП, к примеру, у нас будет функция, что-то типа makeRunningDog, которая внутри может содержать кучу вызовов более мелких функций, часть из которых могут содержать замыкания.

Инкапсуляция в терминах ООП - обычно именно про состояние. Т.е. про поля. Но я видел как кучу классов без полей (по сути, контейнеры для функций), так и классы без логики (простые DTO-шки). А геттеры-сеттеры - это и вовсе карго-культ какой-то, так как 99% виденных мною ничего не делали кроме как чтения/записи приватного поля. Но все равно их зачем-то пишут.

Наследование... Вот реально, крайне редко оно оправдано и обычно не более одного уровня. В случае с чихуахуа проще и гибче вынести всю логику в DogService, и вызывать из методов чихуахуа. А собаку сделать интерфейсом, если очень надо.

Короче, ООП в реальных проектах не совсем по учебнику. И смешано с другими парадигмами, в частности с ФП.

Хотя, конечно, наверное ещё и от области зависит, я со своей колокольни смотрю.

Если критикуешь других за неточности формулировок будь добр сам быть поточнее - если ты наследовал чихуахуа от собаки, то ты не можешь "переписывать" его методы, можешь только доопределять, если собака бежит по вызову команды бежать, чихуахуа не начинает лизать яйца по этой же команде, он так же бежит, просто при этом попутно шкрябает. Переписывая же методы ты мало того что портишь весь смысл наследования так ещё и нарушаешь принцип open-closed

ну так в этом одно из отличий сеньорства на взгляд некоторых компаний и людей. Человек может работать по solid или интуитивно применять паттерны, я фабрики и декораторы с определённого момента начал писать вообще без задней мысли, очень часто нужны. Но сеньор это человек который уже принимает решения и отстаивает свою позицию, он должен это уметь ссылаясь на принципы, паттерны и иные практики, при том в идеале настолько развёрнуто чтобы менее компетентный(джун) с первого раза понял.

Последнее время возникает ощущение что  что стали забывать про все это ооп.  И получается, сделали микросервис,  если он херово работает, не будут его чинить, а создадут новый. И так до бесконечности.

Мое ооп круче твоего)

Я вот вообще нихера не понял, но плюсов всем насовал.

только знакомлюсь с питоном, это самое офигенное объяснение сути, которое я видел)

не, по сути всё норм, я чисто из-за оформления брюзжу.
например self. Ну блин, ну ты-же внутри класса, ну ясен-красен это self, зачем его писать-то везде? Ну и ещё какая-то вкусовщина, не помню уже

как ООП'шник со стажем. тесты никуда не деваются. это норма, я бы сказал база для любой разработки. язык, подходы, не особо важны

На практике - у типа 1 надо автоматом закрыть issue, если прошли тесты, а у типа 2 не надо. Вот появилось разное поведение. И оно не ползёт по коду в виде портянки if.

Ты мог бы сделать много функций, по одной на каждый тип. И внутри иф вызывать нужную функцию в зависимости от типа. Это был бы внешне точно такой же иф как иф с хендлерами.

Но ты выбрал иф при конструировании хендлеров. Вот интересно чем ты руководствовался.

Инкапсуляция, если подняться повыше, от уровня языка к уровню архитектуры, несколько меняет смысл и становится ближе к модели чёрного ящика из системного анализа. Сокрытие реализации + контракт для взаимодействия. Модификаторы доступа в этом случае служат одним из инструментов достижения цели.
От сырого принципа из учебника информатики "мы объединили данные и методы в один класс, вот это да!" в проектировании пользы примерно ноль.

Да, вроде того. А потом все hander сохраняются в списке объектов для дальнейшей обработки

А как ты для себя решил, что вот этот подход лучше, чем такое же ветвление, но в методе класса handler? Чем один if лучше чем другой?

Снаружи, т.е. указано во входном файле. Студент1 — тип1. Но там многостадийная система, поэтому проще при инициализации экземпляра класса сказать тип и забыть про него.

То есть у тебя где-то в фабричном методе код типа

var handler ;

if student.type == 1 then hander = new Handler1()

else if student.type == 2 then hander = new Hander2()

Так выходит?

Утверждаю, что определение "инкапсуляция - это сокрытие данных" неверное

Это не только ты утверждаешь, это ещё в википедии написано. Но если ты это выдашь случайному программисту, то он мягко говоря офигеет от удивления ))) . И соответсвенно, рассчитывать, что когда ты говоришь инкапсуляция, он думает о чём-то отлчичном от сокрытия - нельзя.

Питон - мультипарадигменный. Там можно как угодно писать.

Ну так в основном как на нём пишут? Если без ООП, то тогда уверждение что ООП  в основном не используется,  вполне может быть верным ))

Да, len - параметрический полиморфизм, но полиморфизм же.

Ну так в ООП не любой полиморфизм, а полиморфизм подтипов. Так что с моей точки зрения функция len - не очень пример для ООП.

Метод process наследуется у BaseHandler и не трогается, а вот список файлов вынесен в поле Handler1 и Handler2.

А как ты принимаешь решение каким хендлером обрабатывать проект?

В питоне нет сокрытия. Всякие нижние подчёркивания — это договорённости

Договорённостей вполне достаточно для того, чтобы писать код, так что предлагаю считать, что сокрытие в Питоне есть. Сложившаяся практика важнее наличия фич мне кажется.

При этом в питоне ООП есть, верно?

В Питоне есть обвязка для ООП, согласен. Но мне кажется лучше задать вопрос, пишут ли на Питоне объектно ориентированный код. Впринципе ты можешь начисто игнорировать ООП, несмотря на наличие поддержки в языке.

Например, функция len работает в зависимости от объекта, в которому она применяется.

Ты сейчас имел в виду именно свободную функцию? Не метод? Функцию, которая по разному работает, когда в неё передают объекты разных типов? Тогда это совсем не ООП, а в лучшем случае параметрический полиморфизм.

Дальше, в gamedev всё тоже на этом.

Ааа, ты геймдевом занимаешься? Это многое объясняет, конечно. Наверное там действительно есть такой код.

Ты слышал про ECS? В Unity вроде в полный рост практикуется. В Питоне в геймдеве этот подход не используют?

Согласен, композиция это круто.

Отсутствие ограничений даёт проблемы в долгосрочной перспективы. Так как любая ошибка, которую не поймал компилятор - это потенциальный косяк в рантайме. Чем больше свободы, тем меньше ошибок ловит.

Ну хоть у меня это не основной язык, что радует. (*смотрит на страницу питон кода*)

Да спрашивают по тому, насколько глубоко в понимании нахера оно надо собеседуемый зайдет. Если скажет, что инверсия зависимостей это про "детали от абстракции", то значит список ответов на собесы прочитал, если расскажет, что это породило класс архитектур, включая чистую, расскажет про IOC контейнеры и прочая, то это значит чел хотя бы в курсе, как этим пользоваться

Исторически ООП задумывалось в таком виде: программа проектируется как множество объектов

Есть "исторически" а есть "практически". История ушла (это где там сообщения ыли ... в smalltalk'е?)

На практике ООП слишком часто использут и злоупотребляют наследованием.

Вообще польза в ООП не в том, что делать можно, а в том что делать нельзя. Например хочешь ты данные покоцать, а не дают, потому что они скрыты.

Или хочешь ты метод написать, который принимает только млекопитающих, и в него нельзя засунуть автобус. Для этого система типов нужна.

Или очешь ты дать возможность переопределить метод, но только один а не все сразу.

Ну и так далее...

А в питоне у нас вместо ограничений duck typing...

Можно ещё вспомнить принципы ООП SOLID:
- Единственной ответственности
- Открытости/закрытости
- Подстановки Лисков
- Разделения интерфейсов

- Инверсии зависимостей