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