Схема наблюдателя и нарушение принципа единой ответственности

Question

У меня есть апплет, который перерисовывает себя, как только текст изменился

Дизайн 1:

//MyApplet.java
public class MyApplet extends Applet implements Listener{
    private DynamicText text = null;
    public void init(){
        text = new DynamicText("Welcome");
    }
    public void paint(Graphics g){
        g.drawString(text.getText(), 50, 30);
    }

    //implement Listener update() method
    public void update(){
       repaint();
    }
}

//DynamicText.java
public class DynamicText implements Publisher{
    // implements Publisher interface methods
    //notify listeners whenever text changes   
}

Разве это не является нарушением принципа единой ответственности (SRP), когда мой апплет не только действует как апплет, но и должен выполнять работу слушателя. Аналогичным образом класс DynamicText не только генерирует динамический текст, но и обновляет зарегистрированных слушателей.

Дизайн 2:

//MyApplet.java
public class MyApplet extends Applet{
    private AppletListener appLstnr = null;
    public void init(){
        appLstnr = new AppletListener(this);
        // applet stuff
    }
}

// AppletListener.java
public class AppletListener implements Listener{
    private Applet applet = null;
    public AppletListener(Applet applet){
        this.applet = applet;
    }

    public void update(){
        this.applet.repaint();
    }
}

// DynamicText
public class DynamicText{
    private TextPublisher textPblshr = null;

    public DynamicText(TextPublisher txtPblshr){
        this.textPblshr = txtPblshr;
    }
    // call textPblshr.notifyListeners whenever text changes   
}

public class TextPublisher implments Publisher{
    // implements publisher interface methods
}

Q1. Является ли дизайн 1 нарушением ПСП?

Q2. Является ли композиция лучшим выбором для устранения нарушения SRP, как в дизайне 2.

Answer 1

Q1: Да.

Q2: Да.

Мой собственный вопрос: это своего рода пуш-опрос, чтобы заставить людей использовать более совершенные методы проектирования?

Так или иначе. То, что вы делаете, это признание того, что в вашей проблеме также есть модель Посредника. Это тонко. Прямо сейчас, похоже, это может быть Адаптер, но, по мере роста вашего дизайна, я подозреваю, что станет ясно, что это действительно Посредник. У посредника много проблем с пользовательским интерфейсом. Фактически, так много людей, что примирили силы Посредника, присутствующие в проблемах пользовательского интерфейса, специальное название: «MVC».

Answer 2

Я действительно не вижу проблемы с SPR для дизайна 1 , как написано . В MVC представление должно прослушивать модель, и в этом случае представление является апплетом, а издатель - моделью.

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