ООП-дизайн в Python / Задача про сотрудников / Наследование vs. Композиция

***
💡Ламповое комьюнити питонистов в Telegram: t.me/pymentor
✈️ Дорожная карта по изучению Python: pymentor.org
📡 Записаться на тестовый собес: t.me/pymentor/106992
✒️ Тестовые собеседования (плейлисты): / @pymentor.
❗️Код: github.com/pymentor/it-compan...
✉️ Связь с автором канала - [e-mail]
***
Тайм коды:
00:00 - начало
00:10 - условие задачи и имеющееся решение (через наследование)
08:00 - что не так с имеющимся решением?
14:35 - решение задачи через композицию
19:45 - забыл вырезать
19:50 - решение задачи через композицию
01:10:40 - немного про абстрактную фабрику
01:14:10 - расширяем функционал
01:19:20 - почему в исходном решении, наследование использовано неправильно?
01:23:12 - принципы, которым следует хороший ООП дизайн
01:30:40 - рекомендация про использование наследования и композиции
***
Теги:
#python #pythondeveloper #собеседование #наследование #композиция #аггрегация #ооп

[@pymentor.]

01:23:00 - оговорился, должно быть "все что генерализация должно решаться с помощью наследования"

[@clandast2136]

Комментарий для продвижения. Спасибо за видео!

[@bak1necWWE]

привет) спасибо!

[@nikita75385]

Привет. А что ты думаешь насчет решения этой задачи через миксины? Это относится к решению через наследование?

[@pymentor.]

Привет, да относится, так как в python миксины реализуются через наследование (множественное)

[@e.b.7568]

А почему та самая?

[@pymentor.]

потому что она была на одном из тестовых собеседований

[@apostol_fet]

А зачем протокол IPaymentCalculator, почему бы просто не использовать аннотацию типа - Callable[[Decimal, Decimal | None], Decimal]
И как данный протокол обеспечит, например поддержку фрилансерам, которым мы платим за выполненные задачи, а не за период работы.
Да и в Decimal передавать float - не очень хорошая практика -
>>> from decimal import Decimal
>>> Decimal(0.9) * Decimal(1000)
Decimal('900.0000000000000222044604925')
>>> Decimal('0.9') * Decimal(1000)
Decimal('900.0')