class A {
public :
class ErrorIsNotB { } ;
class ErrorIsNotC { } ;
int fooA ( ) { return 0 ; }
int fooB ( ) { throw ErrorIsNotB() ; }
int fooC ( ) { throw ErrorIsNotC() ; }
} ;
class B : public A {
public :
int fooB ( ) { return 0 ; }
} ;
class C : public A {
public :
int fooC ( ) { return 0 ; }
} ;
and by LSP "B is-a A".
No, it isn't; not in any way that doesn't totally misunderstand the
point of LSP. Although syntatically it appears to, conceptually B is
not implementing the A interface. Thowing an "Is not a supported call"
function is not an implementation unless it's part of the specification
of A.
Further, you are misrepresenting the LSP. B does not need to, "only
implement as much of A as A does." B needs to be a proper subtype of A:
"Let q(x) be a property provable about objects x of type T. Then q(y)
should be true for objects y of type S where S is a subtype of T."
The problem here is that nothing is provable about "x of type T" when it
comes to fooB and fooC in your above example. Type T (A) is not
providing a contract that can be followed or not followed by subtypes
and these calls make no sense in terms of A. It's an improper
abstraction; LSP doesn't even really apply to it.
If we were to apply LSP though then we need to say what "fooC" is
supposed to do. Let us say that preconditions state it should be a
valid object. Postcondition states it returns an integer. As you can
see, B does not respect this contract. Exceptions are used in cases
when preconditions are not met or when postconditions cannot be.
Of course you might say that the precondition of "fooC" is that "this"
is a pointer to a C. This just restates my original statement that A is
not a proper abstraction. It's incomplete in that it depends on
subobjects for its own definition. A is not even an A...it's an ABC and
whatever else might subclass it.
To understand why this would be different with a possible state machine
where "fooC" cannot be called in certain states the contract would be
reworded such that a precondition is that the machine is not in a state
that makes it invalid. This *may or may not* be implemented by a scheme
like shown in your example; there are many ways to do it. Further, fooC
will more likely make sense in more subobjects. Yet further we aren't
saying, "*this must be a C," but we are saying "A must be in state C";
in other words we are making a conceptual statement about *A* in terms
of A, not a type statement about A in terms of the C type.
You can see this even further by the fact that you'd probably implement
this machine using the state pattern and classes A, B, and C would be
implementation details to a higher abstraction.
It's all in the process of discovery that makes it a good vs. bad design
decision. We don't say, "Hey, I want to stick B in a container of A
objects so I'll stick B functionality in A that doesn't belong there."
That's a bad guiding principle, is what Sam is proposing, and it DOES
violate the LSP on many levels. As such it is not only prone to
problems, it will inevitably cause them. Not ALL cases when B throws an
exception in reply to a "fooC" are such violations but the likelihood of
one being guided by the proposed principle is very high. The design
practice that Sam is recommending is pure hackery that gives no thought
to the abstraction being implemented.
In short, whether or not C or B throw an exception should be on the
basis of A, not the other way around. C and B should be implementing
the interface of A, the interface of A should not be altered to suit the
needs of B and C nor defined in their terms. This is the fundamental
meaning behind the LSP. As an alumni from MIT I'd actually expect you
to know this. Might not be design 101 stuff but it's not that advanced
either. Are you just trolling?
