Каков пример принципа единой ответственности?

Ответ 1

Ознакомьтесь с подробное описание.

Если вы не попросите что-то более конкретное, вам будет сложно помочь больше.

Единая ответственность - это понятие класса, выполняющего одну конкретную вещь (ответственность) и не пытающегося сделать больше, чем нужно, что также называется высокой сплоченностью.

Классы не часто начинаются с Low Cohesion, но, как правило, после нескольких выпусков и разных разработчиков, добавляющих на них, внезапно вы заметите, что это стало монстром или классом Бога, как его называют некоторые. Поэтому класс должен быть реорганизован.

Сложно подумать о хорошем примере, но в последнее время я могу подумать, что это класс, который управляет различными этапами обработки пакетов, типа Chain of Responsibility. Первоначальное намерение этого класса состояло в том, чтобы сохранить список этапов и организовать для них вызов packetProcess(). Что ж, все закончилось тем, что все добавили что-либо, связанное с этапами обработки (поскольку класс менеджера был простым местом для доступа к этапам) к этому классу менеджера, особенно к конфигурации этапа. В классе менеджера больше не было единой ответственности, но вместо этого он также отвечал за вызовы на этапы изменения конфигурации: таким образом, Cohesion была уменьшена.

В итоге нам пришлось реорганизовать класс менеджера, вырвать всю конфигурацию сцены и поместить его в factory, оставив менеджером делать то, что он должен был делать.

Ответ 2

Самый эффективный способ разбить приложения на создание классов GOD. Это классы, которые отслеживают много информации и имеют несколько обязанностей. Одно изменение кода, скорее всего, затронет другие части класса и, следовательно, косвенно всех других классов, которые его используют. Это, в свою очередь, приводит к еще большему обслуживанию, поскольку никто не смеет делать какие-либо изменения, кроме добавления в него новых функций.

Следующий пример - это класс TypeScript, который определяет Person, этот класс не должен включать проверку электронной почты, поскольку это не связано с поведением человека:

class Person {
    public name : string;
    public surname : string;
    public email : string;
    constructor(name : string, surname : string, email : string){
        this.surname = surname;
        this.name = name;
        if(this.validateEmail(email)) {
          this.email = email;
        }
        else {
            throw new Error("Invalid email!");
        }
    }
    validateEmail(email : string) {
        var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i;
        return re.test(email);
    }
    greet() {
        alert("Hi!");
    }
}

Мы можем улучшить класс выше, удалив ответственность за проверку электронной почты из класса Person и создав новый класс электронной почты, который будет иметь эту ответственность:

class Email {
    public email : string;
    constructor(email : string){
        if(this.validateEmail(email)) {
          this.email = email;
        }
        else {
            throw new Error("Invalid email!");
        }        
    }
    validateEmail(email : string) {
        var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i;
        return re.test(email);
    }
}

class Person {
    public name : string;
    public surname : string;
    public email : Email;
    constructor(name : string, surname : string, email : Email){
        this.email = email;
        this.name = name;
        this.surname = surname;
    }
    greet() {
        alert("Hi!");
    }
}

Удостовериться, что у класса есть одна ответственность, он по умолчанию также легче видеть, что он делает, и как вы можете расширять/улучшать его.

Ответ 3

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

Типичным примером может служить класс EmailSender:

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

Здесь есть статья об этом.

Ответ 4

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

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

Если есть две причины для изменения, возможно, что две разные команды могут работать по одному и тому же коду по двум причинам. Каждый из них должен будет развернуть свое решение, которое в случае скомпилированного языка (например, С++, С# или Java) может привести к несовместимым модулям с другими командами или другими частями приложения.

Этот принцип тесно связан с понятиями сцепления и сцепления. Связывание относится к тому, как неразрывно связаны различные аспекты приложения, в то время как сплоченность относится к тому, насколько тесно связаны содержимое конкретного класса или пакета. Все содержимое одного класса тесно связаны друг с другом, поскольку сам класс является [отдельной единицей] [1], которая должна быть полностью использована или вообще не использоваться.

Мое сообщение в блоге об этом:

http://javaexplorer03.blogspot.in/2016/12/single-responsibility-principle.html