I have two classes Output and Timeline, neither of which violate SR, but the two of them are linked together. So what I'd like to do is have a class called Elco (there's a reason behind the name) that has both of them as subclasses. For various reasons (this is just a simplified version) it's important that I don't violate the LoD (Law of Demeter). The issue is that technically Elco now has two responsibilities. It delegates those two responsibilities to two classes, which each have one responsibility. Is that not ok? Why? What's a better solution?

  • 1
    Without reading into more details, Facade is an example in which a single class provide multiple services but which delegates to a number of other classes.
    – rwong
    Aug 6, 2013 at 2:06
  • According to your description, Elco has just one responsibilty -- to decide, whether Timeline or Output is the right tool.
    – nibra
    Aug 7, 2013 at 11:49

2 Answers 2


Technically speaking, its a little hard to tell whether you are breaking Law of Demeter or not without actually looking at your implementation.

Based on the principle, as long as the object of Elco is directly calling methods of Output and Timeline and not the methods of any other objects that are obtained by Output and Timeline, you are fine.

The problem, however, is that you are coding to an implementation and not abstraction i.e In your code you will have conditions like:

   call Timeline methods

   call Output methods

A better approach to this problem would be to define an interface that both Timeline and Output implements. That way, Elco class only has to know about that interface and not about the implementing classes. Your code will then be:

methodCaller(CommonInterface f) {



Each of the classes will then provide their own implementations to the method interfaceMethod. This will decouple your code from its implementation, so that in the future you can plugin as many implementations of CommonInterface as you want, without changing the above code.

  • I must have done a really bad job explaining, sorry. I know I'm not breaking the LoD, I'm worried about breaking Single Responsibility. Timeline and Output don't do the same thing. They're separate, but related. So I would not have something like the first code block in my code.
    – sinθ
    Aug 6, 2013 at 2:49
  • As long as your class calls methods from both Timeline and Output, it is breaking Single Responsibility. You still need an abstraction over these two classes, such that, your Elco class is decoupled from the changes made in either of these classes. Formulation to SR principle can be that your class should have only one reason to change. In your case, its two. Aug 6, 2013 at 2:58
  • Would you consider making Output and Timeline interfaces sufficient to decouple the classes, since any class could implement those interfaces?
    – sinθ
    Aug 7, 2013 at 17:15

To answer the question in your title: a class that only delegates to other classes can violate the single-responsibility principle, but does not do so necessarily.

To tell if your Elco class violates the SRP, we would need to know more about its design and the reason you created it.
One dead give-away for breaking the SRP (and in my opinion, also LoD) is if you have a hard time thinking of names for the Elco methods that do not reveal that it is just a thin forwarding wrapper to a similarly names method in Output or Timeline. Such names can be acceptable for a small percentage of the methods, but should raise a red flag if it happens for a significant number of them.
On the other hand, if Elco provides a conceptually higher-level service that can be described in terms of operations on Output and Timeline, then Elco does not violate the SRP and can be seen as an instance of the Facade design pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.