Могу похвастаться - я за свою жизнь осознанно написал всего одну фабрику - по типу viewset's в Django DRF. Она инстанцирует кучу однотипных вьюшек во внутреннем проекте.
Вспомнил свою молодость, когда я начинал работать электромонтажником (2006 год). На ближайшем рынке за 100р купил отвёртку под биты с битами в комплекте. Казалось бы, чему там ломаться, но отвёртка, включая биты в итоге была сломана в 10 местах уже через пару недель. С тех пор всяких noname производителей стараюсь обходить стороной.
Покупал у них ленточную шлифмашинку этого же производителя. В первый день работы сломалась в 4-х местах. Отшлифовал вагонки на комнату 10м2, к концу работ она сама себя перепилила постепенно съезжающей лентой. На этом всё.
Для меня самый полезный hotkey в терминале - это Esc + . (точка) - повтор последнего аргумента предыдущей команды. Ещё, конечно же, повтор последней команды через !, например !cat Ну и поиск Ctrl+R.
Прошу прощения. Пример автора утверждает, что переопределение общего метода в классе-наследнике противоречит принципу LSP. И мой вопрос был, действительно ли это так. Спасибо за Ваш развёрнутый ответ.
Спасибо, но всё же пока не нашёл ответа на свой вопрос. В статье Принципы SOLID на примерах приводятся классы Account, SalaryAccount, DepositAccount в разделе про LSP и каждый повторно реализует общую логику с учётом своих особенностей. В статье Принципы SOLID в картинках автор явно пишет
Необходимо, чтобы класс-потомок был способен обрабатывать те же запросы, что и родитель, и выдавать тот же результат. Или же результат может отличаться, но при этом относиться к тому же типу.
"не усиливать предусловие" - Вы имеете ввиду - реализовать в наследниках логику, соблюдая контракт? Не могу сказать, что хорошо разбираюсь, но отталкиваюсь от здравого смысла (автор привёл семантическую ошибку как нарушение LSP) и посмотрел ещё пару статей про SOLID на Хабре и авторы указывают, что переопределение общих методов в наследниках возможно.
Но разве это верно в случае LSP? Код должен работать, а как он будет это делать - зависит от конкретной реализации в наследнике. Иначе, для чего тогда по вашему, нужен полиморфизм?
Регулярно сталкиваюсь с задачами в интернете, условия которых понятны только автору текста. Прочитайте Вашу первую задачу и попытайтесь понять, что же всё-таки имеется в виду под "этот день".
Спасибо, теперь картина полная.
Алексей, а как между L4 балансировщиками трафик распределяется в вашей схеме?
Восток-Запад - это по России видимо имеется ввиду.
Сначала создали проблему, а теперь героически с ней боротся. Ещё забыли учесть курьеров, которым правила ПДД тоже не писаны.
Спасибо за пояснения :)
Могу похвастаться - я за свою жизнь осознанно написал всего одну фабрику - по типу viewset's в Django DRF. Она инстанцирует кучу однотипных вьюшек во внутреннем проекте.
Вспомнил свою молодость, когда я начинал работать электромонтажником (2006 год). На ближайшем рынке за 100р купил отвёртку под биты с битами в комплекте. Казалось бы, чему там ломаться, но отвёртка, включая биты в итоге была сломана в 10 местах уже через пару недель. С тех пор всяких noname производителей стараюсь обходить стороной.
Покупал у них ленточную шлифмашинку этого же производителя. В первый день работы сломалась в 4-х местах. Отшлифовал вагонки на комнату 10м2, к концу работ она сама себя перепилила постепенно съезжающей лентой. На этом всё.
Было бы странно, если бы не занял.
Не иронично ли, что создатель Flask использовал Django для Sentry? Интересный парень, этот Армин.
Для меня самый полезный hotkey в терминале - это Esc + . (точка) - повтор последнего аргумента предыдущей команды.
Ещё, конечно же, повтор последней команды через !, например !cat
Ну и поиск Ctrl+R.
Прошу прощения. Пример автора утверждает, что переопределение общего метода в классе-наследнике противоречит принципу LSP. И мой вопрос был, действительно ли это так.
Спасибо за Ваш развёрнутый ответ.
Спасибо, но всё же пока не нашёл ответа на свой вопрос.
В статье Принципы SOLID на примерах приводятся классы Account, SalaryAccount, DepositAccount в разделе про LSP и каждый повторно реализует общую логику с учётом своих особенностей.
В статье Принципы SOLID в картинках автор явно пишет
В статье Принципы SOLID, о которых должен знать каждый разработчик аналогично первым двум.
Это первые три результата из тех, что выдал поиск.
"не усиливать предусловие" - Вы имеете ввиду - реализовать в наследниках логику, соблюдая контракт?
Не могу сказать, что хорошо разбираюсь, но отталкиваюсь от здравого смысла (автор привёл семантическую ошибку как нарушение LSP) и посмотрел ещё пару статей про SOLID на Хабре и авторы указывают, что переопределение общих методов в наследниках возможно.
Но разве это верно в случае LSP?
Код должен работать, а как он будет это делать - зависит от конкретной реализации в наследнике.
Иначе, для чего тогда по вашему, нужен полиморфизм?
Считают, что 4.97с слишком медленно.
Это Вам спасибо! Я уже начал сомневаться в своих когнитивных способностях.
Как-то не ломается. Не подскажете в какую сторону копать?
Регулярно сталкиваюсь с задачами в интернете, условия которых понятны только автору текста. Прочитайте Вашу первую задачу и попытайтесь понять, что же всё-таки имеется в виду под "этот день".
Проблему сканирования и объединения pdf в Windows решил с помощью программы WinScan2PDF
Ничего лишнего и весит всего 300кб.