Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 '13 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 '13 at 11:49
add comment

2 Answers

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:

if(someCondition)
   call Timeline methods

else 
   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) {

      f.interfaceMethod()

}

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.

share|improve this answer
    
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. –  Mike G Aug 6 '13 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. –  Chander Shivdasani Aug 6 '13 at 2:58
    
Would you consider making Output and Timeline interfaces sufficient to decouple the classes, since any class could implement those interfaces? –  Mike G Aug 7 '13 at 17:15
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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