Is this bad practice?

Question

Consider the follwing two classes:
public class Widget
public class CustomWidget extends Widget
}Now consider another class that has a Widget class member:
public class OrdinaryClass
  private Widget w = new Widget();
  public Widget getTheWidget()
    return w;
}Now suppose I were to subclass OrdinaryClass as follows:
public class SpecialClass extends OrdinaryClass
  private CustomWidget cw = new CustomWidget();
  public CustomWidget getTheWidget()  // violate LSP?
    return cw;
}My questions are:
1) does SpecialClass violate Liskov's Principle in that the getWidget return type has changed?
2) if it's not in violation, is it bad practice anyway? Or is this some polymorphic trick that is not only acceptable, but very useful (and encouraged)?
Please advise.

Answer 1

A custom model was subclassd from AbstractListModel.
One of the getter methods from ALM has a return of
f type Object. The custom model used the same
getter, but returned the toString() of the Object (a
property) instead of the Object in its entirety.Given this specific class hierarchy, you're into territory for design lawyers. A list mode maintains data that's used by a JList[i/]. The contract, as a result, is fairly open, and you could define the model as maintaining string representations for an object. The purists would respond with "no, the view should decide the representation," and I'd probably agree with them.
By comparison, the contract for a [i]java.util.List is much more explicit: you put objects into the list, and you get the same objects out. If your colleague was creating a List implementation that returned toString() of an object rather than the object itself, then your argument would have much more force.
It seems as if changing the return type of a method
in a subclass seems wrong, even if the new return
type is a sub of the original return type.
I have nothing against returning the subclass, mind
you. Just keep the contract (i.e, the return type)
the same.However, the "contract" is not defined just by method signature. If that were the case, then this would be a perfectly valid implementation of List.get():
public Object get(index i)
    return new Integer(i);
}Instead, the "contract" is defined by the class as a whole, and furthermore is defined by your application for each instance of a class that it creates (eg, "this List is used to pass strings between these two methods").