Логирование это скорее сайд эффект поэтому бизнесу на него пофиг. Тем более вы только вызываете функции логгера. Если нужно будет поменять формат логгирования ты вы свой бизнес класс не должны менять.
Проверку входных данных лучше отделять от логики. Так тестировать проще.
Копипастить сразу не надо. А вот когда надо будет внести изменение нужное одному актору, нужно будет применить принцип закрытости и создать новый класс (копипаста, наследование, композиция).
UnmodifiableList в джава нарушает LSP. Это приводит к проблемам с использованием этого класса приведённого к типу List. Это как раз аргумент за то, что этот принцип работает.
ArrayList и LinkeList соблюдают этот принцип, поэтому вам не нужно знать кто именно из них передан.
Если учитывать все варианты то комбинированных интерфейсов будет очень много. В Питоне приняли решение ограничиться этими. С математической точки зрения не идеально, но пользоваться можно.
Так, игра должна быть основана на прекоде от команды курса, код должен быть написан с использованием ООП
Так сделайте шаблон готового репозитория где будут requirements.txt, ридми, настроенные линтеры, прекоммитхуки и всё подготовленное для написания тестов.
Это некоторый оверхед для студентов, но зато с места в настоящую разработку. И это будет проект который не стыдно показать.
Зачем тут абстрактный класс? Это же может быть интерфейс. Вынести writter наружу это типичная инверсия зависимостей. Для OCP пример должен быть в трёх частях. Старый класс - старый класс с новым кодом - старый класс и новый класс.
SOLID это маркетинговый булшит. Красивые имена которые никому не понятны и тысячи программистов трактуют их по своему. При этом проблема написания поддерживаемого кода и набор рекомендаций как это сделать вполне реальны. Спорить какая из трактовок принципов правильная не всегда имеет смысл. Все варианты могут быть полезны, просто в разных контекстах.
Я могу на собесе красиво рассказать про SRP и ISP. Но в жизни это для меня одно и тоже. Интерфейс, это то что определяет ответственность класса, если он не достаточно сегрегейтед, то фиг вам, а не сингл респонсибилити класса. (Под интерфейсом я воспринимаю, то что можно сделать с классом, а не специальный объект язака, как в java).
Метаклассы они для библиотек. Например, ABC удобно использовать для документации и автоматических проверок. А под капотом там метакласс. Использовать метаклассы можно и нужно (обычно это происходит неявно), а вот писать стоит пореже.
Не знаю, что вы имеете в виду под массивом, и зачем вам нужно много их. Очередь - это ссылки на данные. Я подозреваю, что разницы по нагрузке особо не будет. Но точные данные может дать только профайлер.
Логирование это скорее сайд эффект поэтому бизнесу на него пофиг. Тем более вы только вызываете функции логгера. Если нужно будет поменять формат логгирования ты вы свой бизнес класс не должны менять.
Проверку входных данных лучше отделять от логики. Так тестировать проще.
Копипастить сразу не надо. А вот когда надо будет внести изменение нужное одному актору, нужно будет применить принцип закрытости и создать новый класс (копипаста, наследование, композиция).
UnmodifiableList в джава нарушает LSP. Это приводит к проблемам с использованием этого класса приведённого к типу List. Это как раз аргумент за то, что этот принцип работает.
ArrayList и LinkeList соблюдают этот принцип, поэтому вам не нужно знать кто именно из них передан.
На мой взгляд лучше давать разные задачи. Веб сервер, обучить модельку, поиграться с базой данных и каким-нибудь API, простенький парсер.
В примере с барсуками и я не вижу инкапсуляции.
Да и с полиморфизмом там не очень. Draw вызывается у конкретных объектов.
У вас точно ревьюверы на нужной волне?
Некоторые репозитории в примерах этого не видно.
Как кстати istty делать через интерфейсы? Это же параметр запуска приложения.
Хорошего что она есть и есть документация.
Если учитывать все варианты то комбинированных интерфейсов будет очень много. В Питоне приняли решение ограничиться этими. С математической точки зрения не идеально, но пользоваться можно.
Собес обычно не похож на обычную работу. Да и собеседуют порой не будущие коллеги.
Я для себя не нашел связи между вопросами на собесе и комфорте работы с коллегами. Что является нормой для коллег уже узнаёшь по факту.
Какие критерии для оценки что используется ООП?
Так сделайте шаблон готового репозитория где будут requirements.txt, ридми, настроенные линтеры, прекоммитхуки и всё подготовленное для написания тестов.
Это некоторый оверхед для студентов, но зато с места в настоящую разработку. И это будет проект который не стыдно показать.
https://docs.python.org/3/library/io.html#class-hierarchy в Питоне интерфейсы сделанны неявно. Вот такая комбинация на практике.
Зачем тут абстрактный класс? Это же может быть интерфейс. Вынести writter наружу это типичная инверсия зависимостей. Для OCP пример должен быть в трёх частях. Старый класс - старый класс с новым кодом - старый класс и новый класс.
Я бы сказал, что это может быть не очень эффективно. Особенно на стадии общения с HR. Я просто базовые определения выучил и уверенно их произношу.
Если верить Вики то солид именно для ООП. У ООП с функциональной парадигмой очень много общего поэтому и принципы работают и там и там.
SOLID это маркетинговый булшит. Красивые имена которые никому не понятны и тысячи программистов трактуют их по своему. При этом проблема написания поддерживаемого кода и набор рекомендаций как это сделать вполне реальны. Спорить какая из трактовок принципов правильная не всегда имеет смысл. Все варианты могут быть полезны, просто в разных контекстах.
Я могу на собесе красиво рассказать про SRP и ISP. Но в жизни это для меня одно и тоже. Интерфейс, это то что определяет ответственность класса, если он не достаточно сегрегейтед, то фиг вам, а не сингл респонсибилити класса. (Под интерфейсом я воспринимаю, то что можно сделать с классом, а не специальный объект язака, как в java).
Метаклассы они для библиотек. Например, ABC удобно использовать для документации и автоматических проверок. А под капотом там метакласс. Использовать метаклассы можно и нужно (обычно это происходит неявно), а вот писать стоит пореже.
Про единственную причину для изменений он же часто говорит в видео.
Метакласс в двух словах: хук для создания класса. Другими словами возможность создать класс программно, а не декларативно.
Не знаю, что вы имеете в виду под массивом, и зачем вам нужно много их. Очередь - это ссылки на данные. Я подозреваю, что разницы по нагрузке особо не будет. Но точные данные может дать только профайлер.