Каждый класс должен иметь ровно одну причину для изменения. Представь пекарню, где каждый работник специализируется на одной задаче — пекари пекут, декораторы украшают. В C# это означает разделение задач на отдельные классы.
// Хорошо: Разделённые ответственности
public class OrderProcessor { }
public class EmailNotifier { }
public class PaymentHandler { }
Такой подход делает код проще для понимания, тестирования и поддержки.
Классы должны быть открыты для расширения, но закрыты для модификации. Ты должен добавлять новую функциональность без изменения существующего кода, как при строительстве из ЛЕГО — добавляешь новые кубики без изменения старых.
public abstract class PaymentProcessor { }
public class CreditCardProcessor : PaymentProcessor { }
public class PayPalProcessor : PaymentProcessor { }
Используй абстрактные классы и интерфейсы для расширяемости, защищая при этом существующие реализации.
Подклассы должны быть взаимозаменяемы со своим базовым классом без нарушения функциональности. Если класс ожидает Bird, любой подкласс Bird должен работать корректно без изменений.
public class Bird { public virtual void Fly() { } }
public class Sparrow : Bird { public override void Fly() { } }
Это гарантирует, что полиморфизм работает надёжно во всём приложении.
Классы не должны быть вынуждены реализовывать методы, которые они не используют. Разбей большие интерфейсы на более узкие, заточенные под конкретные нужды.
public interface IFlying { void Fly(); }
public interface ISwimming { void Swim(); }
public class Duck : IFlying, ISwimming { }
Это предотвращает зависимость классов от ненужной функциональности.
Модули высокого уровня не должны зависеть от модулей низкого уровня; и те и другие должны зависеть от абстракций. Используй внедрение зависимостей для развязывания кода.
public class OrderService
{
private readonly IPaymentProcessor _processor;
public OrderService(IPaymentProcessor processor) => _processor = processor;
}
Это позволяет писать гибкий, тестируемый код, который легко адаптируется к меняющимся требованиям.
Принцип единственной ответственности гласит, что класс должен иметь только одну причину для изменения, что достигается разделением ответственности, таких как обработка заказов, отправка уведомлений по email и обработка платежей в отдельные классы.
Новый — ещё не проверен сообществом
Вы