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'm trying to follow LSP in practical programming. And I wonder if different constructors of subclasses violate it. It would be great to hear an explanation instead of just yes/no. Thanks much!

P.S. If the answer is no, how do I make different strategies with different input without violating LSP?

class IStrategy
{
    public:
        virtual void use() = 0;
};

class FooStrategy : public IStrategy
{
    public:
        FooStrategy(A a, B b) { c = /* some operations with a, b */ }
        virtual void use() { std::cout << c; }
    private:
        C c;
};

class BarStrategy : public IStrategy
{
    public:
        BarStrategy(D d, E e) { f = /* some operations with d, e */ }
        virtual void use() { std::cout << f; }
    private:
        F f;
};
share|improve this question
add comment

1 Answer 1

up vote 10 down vote accepted

Generally constructors are not considered to be part of the Liskov substitution Principle (LSP). The LSP with objects, not classes:

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. (quoted this PDF file)

Since an object doesn't exist until after construction, the constructor itself is generally consider to be out of scope. The LSP wants all subclasses to behave the same. How they get to that behaviour is a different matter.

This means you're code example is not in violation of the LSP per se. The constructor and the private methods are not part of the public contract when viewed from a LSP perspective.

Do keep in mind that LSP goes a lot further than function signatures. If a parent throws an exception in a specific case, so should the children. If a parent doesn't children can't start throwing execptions all of a sudden, if a getStock function in a parent returns an integer, a child can't start returning stock objects, etc, etc

The LSP deals with every aspect of public behaviour an object has.

A common solution to creating strategies with different constructors is the factory pattern by the way.

share|improve this answer
    
So my example seems not violating the LSP, right? –  Kolyunya Dec 10 '12 at 8:01
    
As far as the example goes, it is not in violation of the LSP, I've updated my answer to reflect that. –  hoppa Dec 10 '12 at 8:15
    
Did the author of that quote make a typo when she said, "...then S is a subtype...", meaning, "...*when* S is a subtype..."? I'm trying to analyze that quote, but that phrase is getting in the way. (Apparently italics isn't working the same way in the comments.) –  Panzercrisis Jun 13 at 13:08
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.