views:

146

answers:

2

I have an applet which repaints itself once the text has changed

Design 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   
}

Isn't this a violation of Single Responsibility Principle where my Applet not only acts as Applet but also has to do Listener job. Same way DynamicText class not only generates the dynamic text but updates the registered listeners.

Design 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. Is design 1 a SPR violation?

Q2. Is composition a better choice here to remove SPR violation as in design 2.

+1  A: 

Q1: Yes.

Q2: Yes.

My own question: is this some sort of push-poll to get people using better design techniques?

Anyway. What you are doing is recognizing that there is also a Mediator pattern in your problem. It's subtle. Right now, it looks like it could be an Adapter but, as your design grows, I suspect it will become clear that this is really a Mediator. Mediator is in a lot of UI problems. So many, in fact, that people have given reconciling the Mediator forces present in UI problems a special name: "MVC."

I have so much of confusion over deciding what should I prefer. I seek opinions on the same. Probably, most of the best people are here at SO. Seeking their opinions to clarify my own doubts.Thanks for the reply. I may have to look into Mediator now! :)
Devil Jin
A: 

I don't really see an SPR problem with design 1 as it is written. In MVC the view should listen to the model, and in this case the view is the applet and the publisher is the model.

Now OK, applets have a few other responsibilities (lifetime management springs to mind) which might mean you want to separate out a specific view class when you start to handle those. The applet could then use the view by composition.

pdbartlett
What about the other one? Do you see any problems in it?
Devil Jin
In the long run, with more functionality, you'll probably end up closer to design 2 than design 1. But at the moment I'd say it's overkill. Also, because the functionality shown is so simple, it's difficult to come up with good names for all the entities (though choosing them to match well-known patterns - like MVC - can help).I'd stick with the YAGNI principle, but make sure you have plenty of tests and a good IDE. That way you can refactor *when you need to* and not before.Just my $0.02, though...
pdbartlett