SOLID - являются ли принцип единой ответственности и принцип открытости / закрытости взаимоисключающими?

Это похоже на обсуждение семантики «расширения поведения классов». Добавление нового типа в фабрику изменяет существующее поведение, а не расширяет поведение, потому что мы не изменили единственное, что делает фабрика. Нам может потребоваться расширить фабрику, но мы не расширили ее поведение. Расширение поведения означает введение нового поведения и будет больше похоже на событие каждый раз, когда создается экземпляр типа или авторизует вызывающий объект фабрики - оба этих примера расширяют (вводят новое) поведение.

У класса должна быть одна и только одна причина для изменения.

Пример в вопросе - это фабрика для создания Product экземпляров, и единственная веская причина для ее изменения - это изменить что-то в создаваемых ею Product экземплярах, например, добавить новый ZenProduct.

Вы должны иметь возможность расширять поведение классов, не изменяя его.

Очень простой способ добиться этого - использовать Decorator.

Шаблон декоратора часто бывает полезен для соблюдения принципа единой ответственности, поскольку он позволяет разделить функциональность между классами с уникальными проблемами.

public interface IProductFactory
{
    Product GetProduct(string type);
}

public class ProductFactory : IProductFactory
{
    public Product GetProduct(string type)
    {
        \\ find and return the type
    }
}

public class ProductFactoryAuth : IProductFactory
{
    IProductFactory decorated;
    public ProductFactoryAuth(IProductFactory decorated)
    {
        this.decorated = decorated;
    }

    public Product GetProduct(string type)
    {
        \\ authenticate the caller
        return this.decorated.GetProduct(type);
    }
}

Шаблон декоратора - мощный шаблон при применении принципов SOLID. В приведенном выше примере мы добавили аутентификацию в ProductFactory без изменения ProductFactory.

У класса должна быть одна и только одна причина для изменения.

По сути, это означает, что ваш класс должен представлять единоличную ответственность и не должен впоследствии изменяться для включения новой функции.

Например, если у вас есть класс, который отвечает за печать отчета в формате pdf. Позже вы захотели добавить новую функцию для поддержки печати отчетов в других форматах. Затем вместо изменения существующего кода вы должны расширить его для поддержки другого формата, что также подразумевает расширение поведения классов без его изменения.

Я думаю, это зависит от вашей интерпретации SRP. Это всегда несколько субъективно. Попросите 100 человек дать определение «единоличной ответственности», и вы, вероятно, получите 100 разных ответов.

Используя сценарий из ответа Рави, типичным решением может быть класс ReportGenerator, который предоставляет GeneratePdf метод. Позднее он может быть расширен дополнительным GenerateWord методом, если потребуется. Хотя, как и вы, я думаю, что в этом есть привкус.

Я бы, вероятно, реорганизовал метод GeneratePdf в класс PdfReportGenerator, а затем представил бы его через ReportGenerator. Таким образом, ReportGenerator несет только одну ответственность; который должен раскрыть различные механизмы генерации отчетов (но не содержать их логики). Затем его можно было бы продлить, не расширяя эту ответственность.

Я бы сказал, что если вы обнаружите конфликт, это вполне может быть архитектурный запах, который требует быстрого обзора, чтобы увидеть, можно ли сделать это лучше.

У меня есть класс StudentOrganiser, который принимает IStudentRepository зависимости. Интерфейсы, представленные IStudentRepository, говорят GetStudent(int studentId)

Класс подчиняется SRP, потому что у него нет никакой логики, связанной с управлением соединением с источником репозитория.

Класс подчиняется OCP, потому что, если мы хотим изменить источник репозитория с SQL на XML, StudentOrganiser не нужно претерпевать никаких изменений => открыт для расширения, но закрыт для модификации.

Подумайте, если StudentOrganiser был разработан так, чтобы не зависеть от IStudentRepository, тогда метод внутри самого класса должен заботиться о создании экземпляра new StudentSqlRepository() Если позже возникнет потребность также поддерживать StudentXMLRepository на основе определенного условия времени выполнения, ваш метод закончился бы с некоторая case switch парадигма и, таким образом, нарушение SRP как метода также является решающим фактором фактического хранилища. Внедряя зависимость репозитория, мы сняли эту ответственность с класса. Теперь класс StudentOrganiser можно расширить для поддержки StudentXMLRepository без каких-либо изменений.