323

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

Случайно наткнулся на такой комментарий

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

И прямо полыхнуло.


Где в трёх принципах ООП (наследование, инкапсуляция, полиморфизм) есть что-то про сеттеры, геттеры и деструкторы?


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


Сейчас в трёх китах ООП логика такая:

1. инкапсуляция — это объединение данных (называемых полями или атрибутами) и функций для работы с ними (называемых методами),

2. наследование — возможность породить класс из существующего, взяв себе все поля и методы,

3. полиморфизм — это возможность взаимозаменять объекты в рамках иерархии.


Давайте на примере. У нас собака - это сложная такая штука. Но всю сложность на себя берёт программист, который реализовал класс Собака. У нас есть поля (например, количество лап), есть методы (например, бежать). Вы можете сказать собака.бежать(), при этом внутреннее устройство собаки вас не интересует - в этом смысл инкапсуляции. Некоторые ошибочно говорят про "сокрытие" и начинают про private-public-protected, но этого не требуется. Поэтому, например, в python нет сокрытия, а инкапсуляция всё ещё есть.


Дальше. Мы создали Собаку. Теперь хотим Чихуахуа. Чтобы не переписывать общие места, у нас есть наследование. Мы создаём Чихуахуа(Собака), то есть наследуемся от неё. Теперь мы можем переписать только отличающиеся места (например, изменить метод Бежать так, чтобы Чихуахуа ещё противно шкрябала когтями).


И третье - полиморфизм. Это когда мы можем сделать много собак, и для каждой собаки вызвать метод собака.бежать(). В зависимости от типа собаки (Собака или Чихуахуа) у нас будет вызван нужный метод бежать. То есть на питоне


# создадим пару очаровательных собак
dog_party = [ Dog(), Сhihuahua() ]
# пройдёмся циклом по всем собакам
for dog in dog_party:
.  # у каждой собаки вызовем свой метод бежать
dog.run()
И тогда все собаки из dog_party побегут как умеют. Такие дела.


PS: некоторые относят к китам ООП ещё и абстракцию "для выделения в моделируемом предмете важного для решения конкретной задачи по предмету" (вики). Тут у меня вопрос. Вообще всё программирование состоит в выделении важного и игнорировании неважного независимо от парадигмы. Причём тут ООП? А если мы говорим о выделении сущности собаки в виде полей, то это свойство называется инкапсуляция.


В телеграмм-канале devfm разбираем разные нюансы из жизни разработчика на Python и не только — python, bash, linux, тесты, командную разработку.

Программирование на python

937 постов11.9K подписчиков

Правила сообщества

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


Приветствуется:

• уважение к читателям и авторам

• конструктивность комментариев

• простота и информативность повествования

• тег python2 или python3, если актуально

• код публиковать в виде цитаты, либо ссылкой на специализированный сайт


Не рекомендуется:

• допускать оскорбления и провокации

• распространять вредоносное ПО

• просить решить вашу полноценную задачу за вас

• нарушать правила Пикабу

Вы смотрите срез комментариев. Показать все
1
DELETED
Автор поста оценил этот комментарий

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

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

раскрыть ветку (13)
0
Автор поста оценил этот комментарий

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

раскрыть ветку (12)
1
Автор поста оценил этот комментарий

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

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

раскрыть ветку (3)
3
Автор поста оценил этот комментарий

Нередка ситуация, когда человек интуитивно работает по SOLID, но объяснить не может. При этом подготовить историю про SOLID умеет любой гадкий курс "как пройти собес", и отличить прошедшего курс от реально понимающего непросто

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Согласен, что senior и team lead — они ещё обязательно про коммуникацию. Даже middle на самом деле тоже.


Вопрос — что спрашивать на собесах, чтобы нанять нужного человека. Вам же не преподаватель нужен, основная задача которого объяснять материал. Вам нужен специалист, который умеет выбрать и обосновать техническое решение. Объяснять SOLID ему не нужно, он может в мануал отправить. А вот тыкнуть в коде, где есть нарушение какого-то принципа — вот это я считаю обязательным

1
Автор поста оценил этот комментарий

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

раскрыть ветку (7)
0
Автор поста оценил этот комментарий

Тяжело определить. Сейчас много профильно готовят к собесам, и как раз развёрнутый ответ даст тот, кого натаскали. Крутым ответом я бы считал свой пример (либо на коленке сделанный типа dog_party, либо давайте зайдём на гитхаб в мой код, вот тут я этот принцип применил).


Пока лучшим решением по оценке разработчика я считаю дать фрагмент кода и попросить починить + объяснить, что было плохо. На это (пока?) натаскать нельзя

раскрыть ветку (6)
0
Автор поста оценил этот комментарий

Гитхаб очень мало у кого есть, а вот дать кусок кода на ревью, обсуждая его построчно, довольно годная практика. Типа джун принес вам ЭТО на ревью, что будете делать?) Хотя времени отжирает от собеседования прилично...

раскрыть ветку (5)
Автор поста оценил этот комментарий

Хорошо, когда у человека хоть что-то есть. Более того, если нет опенсорса, то могут быть закрытые проекты, фрагменты которых на собесе можно показать. Вряд ли у человека только под NDA проекты.


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

раскрыть ветку (4)
0
Автор поста оценил этот комментарий

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

раскрыть ветку (3)
Автор поста оценил этот комментарий

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


Хочешь увидеть обход графа — сформируй задачу, дай входные данные и посмотри на код, который будет написан. Желательно в рабочем окружении того разработчика, которого собеседуешь. Если так не выходит, то в сколь-нибудь приближенном.


Вот я часто пользуюсь vim. Но я же не буду сажать разработчика за машину только с vim? Я дам pycharm, atom, vscode — что привычнее.

раскрыть ветку (2)
0
Автор поста оценил этот комментарий

да вот фиг знает, что понадобится на самом деле)

Только за сегодня мне пришлось покопаться в деталях анзибля, эластика, с3 и кафки, вот как это проверишь?) нужны навыки основ и навык гугления. основы проще по теории и ревью, а гугление как раз допер ли человек погуглить "10 самых частых вопросов на собеседовании".

раскрыть ветку (1)
Автор поста оценил этот комментарий

Навык гугления важен. Я даже пост про это писал Как анализировать предметную область перед разработкой на примере видеоаналитики


А ещё важнее — навык решения проблем и доведения дел до конца. Но на собесе не это спрашивают, а выполнение конкретных, но не имеющих отношения к работе действий (напиши на белой доске / расскажи о SOLID). При этом я сам люблю всякие аббревиатурки, но они не коррелируют с полезными навыками.


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

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества