День 1543. #Курсы
Сегодня порекомендую вам ютуб канал Зонара Хорвата (Zoran Horvat) Зоран - консультант, разработчик и архитектор ПО, автор на Pluralsight, Udemy и YouTube. На его канале вы найдёте советы по разработке и архитектуре, паттернах проектирования, чистом коде, новинкам языка C# и т.п.
Видео, которое попалось мне, вышло совсем недавно и называется Are Design Patterns Dead in C#? (Паттерны Проектирования в C# Умерли?) В нём Зоран на примере оригинальной книги «Паттерны Проектирования» банды четырёх рассуждает, полезна ли до сих пор информация о паттернах проектирования и применимы ли они в современной разработке в .NET.
Не буду спойлерить, смотрите до конца)))
Кстати, про паттерны проектирования вы можете почитать на канале по тегу #DesignPatterns.
Сегодня порекомендую вам ютуб канал Зонара Хорвата (Zoran Horvat) Зоран - консультант, разработчик и архитектор ПО, автор на Pluralsight, Udemy и YouTube. На его канале вы найдёте советы по разработке и архитектуре, паттернах проектирования, чистом коде, новинкам языка C# и т.п.
Видео, которое попалось мне, вышло совсем недавно и называется Are Design Patterns Dead in C#? (Паттерны Проектирования в C# Умерли?) В нём Зоран на примере оригинальной книги «Паттерны Проектирования» банды четырёх рассуждает, полезна ли до сих пор информация о паттернах проектирования и применимы ли они в современной разработке в .NET.
Не буду спойлерить, смотрите до конца)))
Кстати, про паттерны проектирования вы можете почитать на канале по тегу #DesignPatterns.
YouTube
Are Design Patterns Dead in C#?
Become a patron and gain access to source code and exclusive live streams: https://www.patreon.com/posts/are-design-dead-81382714
When was the last time you implemented a proper design pattern in your object-oriented code? Not a factory method, but a proper…
When was the last time you implemented a proper design pattern in your object-oriented code? Not a factory method, but a proper…
👍17
День 1697. #DesignPatterns
Принцип Применения Принципов: Когда НЕ Использовать SOLID
Мы знаем много примеров того, когда и как использовать принципы SOLID. Есть ли какие-нибудь хорошие примеры того, когда соблюдение этих принципов является плохой идеей?
Принцип Применения Принципов (Principle of Applying Principles - POAP):
Принципы, модели и лучшие практики не являются конечными целями. Хорошее и правильное применение каждого из них вдохновляется и ограничивается высшей, более конечной целью. Нужно понимать, почему вы делаете то, что делаете.
Т.е. позиция по умолчанию - не применять принцип, пока вы достаточно хорошо не поймёте, почему вы его применяете*. Слепая вера во что-либо имеет тенденцию приводить к проблемам, и принципы разработки ПО не являются исключением. Обычно это просто потребует дополнительной работы и может привести к результатам, противоположным самой сути принципа.
*Это обычно предполагает, что у вас нет техлида, на которого можно положиться. Если вы младший инженер или новичок в команде, фраза «старший коллега сказал мне, применить этот принцип, и я ему доверяю» — это достаточная (хотя и временная) причина просто применить принцип. Пока вы не вырастете в своей роли и не возьмёте на себя больше ответственности.
Создайте шпаргалку, чего должен достигать каждый принцип, к каким проблемам он может привести, и добавьте примечания для вашего домена.
1. Принцип единственной обязанности (SRP)
Цель: сделать изменения изолированными, их легко тестировать и анализировать.
Проблемы: гипердекомпозиция. Вряд ли вам потребуется отдельный класс для установки заголовка страницы.
Примечания по конкретному домену: это ваше домашнее задание.
2. Принцип «открыт/закрыт» (OCP)
Цель: предотвратить выход из строя старых функций при реализации новых.
Проблемы: «закрытие» модуля, которым вы владеете, поддерживаете и можете безопасно расширять, может привести к ненужной сложности, цепочкам наследования и увеличению размера кода.
Примечания: …
3. Принцип подстановки Лисков (LSP)
Цель: предотвратить появление неправильного кода, который выглядит правильно.
Проблемы: чрезмерная уверенность в LSP как в сигнале правильности.
Примечания: …
4. Принцип разделения интерфейса (ISP)
Цель: уменьшить связанность между классами и их клиентами.
Проблемы: требование минимально возможного интерфейса может противоречить намерениям LSP.
Примечания: …
5. Принцип инверсии зависимостей (DIP)
Цель: обеспечить возможность повторного использования, замены и тестирования большей части системы.
Проблемы: чрезмерная инверсия. Создание и «инвертирование» абстракций без всякой выгоды, усложнение чтения и понимания кода.
Примечания: …
Бонус. Не повторяйтесь (DRY).
Цель: предотвратить несогласованное применение бизнес-правил в системе.
Проблемы: чрезмерное применение. Код, который выглядит одинаково, может служить разным целям, а поведение, которое должно отличаться, становится трудно изменить.
Примечания: …
Заметки выше краткие и общие, и вы можете не соглашаться с целями и проблемами. Хорошо изучите и поразмышляйте над каждым принципом и над тем, как он применим к вашей конкретной системе и домену. Применимость на самом деле зависит от вещей, которые знает только эксперт в предметной области: что может измениться? какая логика будет сквозной? и т. д. Думайте, делайте заметки и делитесь ими со своей командой.
Помните, что даже POAP подлежит POAP! И цель POAP — удержать вас от совершения глупых, расточительных или вредных поступков ради принципов. Спор из-за принципов обычно является нарушением как намерения POAP, так и, возможно, смысла принципа, о котором вы спорите.
Источник: https://softwareengineering.stackexchange.com/questions/447532/when-to-not-use-solid-principles
Принцип Применения Принципов: Когда НЕ Использовать SOLID
Мы знаем много примеров того, когда и как использовать принципы SOLID. Есть ли какие-нибудь хорошие примеры того, когда соблюдение этих принципов является плохой идеей?
Принцип Применения Принципов (Principle of Applying Principles - POAP):
Принципы, модели и лучшие практики не являются конечными целями. Хорошее и правильное применение каждого из них вдохновляется и ограничивается высшей, более конечной целью. Нужно понимать, почему вы делаете то, что делаете.
Т.е. позиция по умолчанию - не применять принцип, пока вы достаточно хорошо не поймёте, почему вы его применяете*. Слепая вера во что-либо имеет тенденцию приводить к проблемам, и принципы разработки ПО не являются исключением. Обычно это просто потребует дополнительной работы и может привести к результатам, противоположным самой сути принципа.
*Это обычно предполагает, что у вас нет техлида, на которого можно положиться. Если вы младший инженер или новичок в команде, фраза «старший коллега сказал мне, применить этот принцип, и я ему доверяю» — это достаточная (хотя и временная) причина просто применить принцип. Пока вы не вырастете в своей роли и не возьмёте на себя больше ответственности.
Создайте шпаргалку, чего должен достигать каждый принцип, к каким проблемам он может привести, и добавьте примечания для вашего домена.
1. Принцип единственной обязанности (SRP)
Цель: сделать изменения изолированными, их легко тестировать и анализировать.
Проблемы: гипердекомпозиция. Вряд ли вам потребуется отдельный класс для установки заголовка страницы.
Примечания по конкретному домену: это ваше домашнее задание.
2. Принцип «открыт/закрыт» (OCP)
Цель: предотвратить выход из строя старых функций при реализации новых.
Проблемы: «закрытие» модуля, которым вы владеете, поддерживаете и можете безопасно расширять, может привести к ненужной сложности, цепочкам наследования и увеличению размера кода.
Примечания: …
3. Принцип подстановки Лисков (LSP)
Цель: предотвратить появление неправильного кода, который выглядит правильно.
Проблемы: чрезмерная уверенность в LSP как в сигнале правильности.
Примечания: …
4. Принцип разделения интерфейса (ISP)
Цель: уменьшить связанность между классами и их клиентами.
Проблемы: требование минимально возможного интерфейса может противоречить намерениям LSP.
Примечания: …
5. Принцип инверсии зависимостей (DIP)
Цель: обеспечить возможность повторного использования, замены и тестирования большей части системы.
Проблемы: чрезмерная инверсия. Создание и «инвертирование» абстракций без всякой выгоды, усложнение чтения и понимания кода.
Примечания: …
Бонус. Не повторяйтесь (DRY).
Цель: предотвратить несогласованное применение бизнес-правил в системе.
Проблемы: чрезмерное применение. Код, который выглядит одинаково, может служить разным целям, а поведение, которое должно отличаться, становится трудно изменить.
Примечания: …
Заметки выше краткие и общие, и вы можете не соглашаться с целями и проблемами. Хорошо изучите и поразмышляйте над каждым принципом и над тем, как он применим к вашей конкретной системе и домену. Применимость на самом деле зависит от вещей, которые знает только эксперт в предметной области: что может измениться? какая логика будет сквозной? и т. д. Думайте, делайте заметки и делитесь ими со своей командой.
Помните, что даже POAP подлежит POAP! И цель POAP — удержать вас от совершения глупых, расточительных или вредных поступков ради принципов. Спор из-за принципов обычно является нарушением как намерения POAP, так и, возможно, смысла принципа, о котором вы спорите.
Источник: https://softwareengineering.stackexchange.com/questions/447532/when-to-not-use-solid-principles
👍19👎1