День 1099. #BestPractices Лучшие Практики Разработки в C#. Окончание Начало Продолжение 6. Отделяйте состояние от поведения Раньше понятие класса в ООП языках объяснялось как шаблон, используемый для создания объекта, и что этот шаблон определяет состояние и поведение объекта. Следуя этой концепции, мы привыкли определять классы буквально со всем, что может принадлежать объекту, включая и состояние, и поведение. Однако со временем этот метод работы оказался неэффективным, особенно в области разработки игр. Там объекты чаще, а иногда и по отдельности, меняют своё состояние и поведение. Поэтому возникла потребность в новом методе работы: - Состояние должно легко сохраняться, копироваться и дублироваться. - Поведение должно легко переключаться во время выполнения в соответствии с потребностями и изменениями. Для этих целей существует паттерн «Стратегия». 7. Неиспользование IoC-контейнеров — не оправдание Допустим, по какой-то причине вы не используете контейнеры внедрения зависимостей в своём проекте. Но это не оправдание раскидывать создание объектов через new по всему коду. Разработчики иногда путают внедрение зависимостей (DI), инверсию управления (IoC) и IoC-контейнеры. Это три разные, независимые вещи. Здесь не подходит принцип использовать либо всё, либо ничего. IoC-Контейнеры — это лишь способ сопоставления абстракции зависимости с её реализацией. Поэтому, если вы не используете IoC-контейнеры, это не означает, что ваши зависимости должны создаваться беспорядочно, без какого-либо планирования и проектирования. Да, в итоге вам придётся использовать new, но есть большая разница между использованием его в некоторых изолированных местах (корне композиции) и ​​по всему коду проекта. 8. Оборачивайте статические объекты и внешние сервисы В большинстве случаев трудности, с которыми мы сталкиваемся при написании модульных тестов, вызваны статическими объектами и внешними сервисами, которые мы напрямую используем в коде. В этом случае вы теряете преимущества использования имитаций и заглушек и сильно усложняете себе жизнь. Вы должны абстрагировать их и обернуть в небольшой собственный класс, который затем можно легко имитировать в тестах. 9. Намерения кода должны быть ясны В программном решении у нас есть разные модули. Эти модули взаимодействуют друг с другом посредством контрактов, которые представляют собой входные и выходные данные, но это ещё не всё. Контракты также представляют некоторую логику и её бизнес-значение. Например, если у вас есть интерфейс с двумя методами CalculateIncomeTax и CalculateTransportTax, вы не можете предполагать, что пользователя интерфейса будут заботить только входные и выходные данные методов. Он также должен быть уверен, что во всех реализациях этого интерфейса каждый из методов будет содержать логику расчёта соответствующего налога, и она, например, не будет перепутана местами. Этого компилятор не сможет обнаружить. Об этом говорит принцип подстановки Лисков. Источник: levelup.gitconnected.com/design-…b7c3500a