Embed Size (px)
Citation preview
CS 2430
Day 28
Announcements
• Program 5 was posted (on Tuesday, 4/2/2013)
• Can work with a partner (sign up by today at 3:52pm)
• Exam 2 handed back on Monday
• The next two labs will be useful (if not necessary) for Prog6
Agenda
• When is inheritance good?
• Abstract classes
When is your inheritance good?
Liskov substitution principle (LSP)
The essence can be paraphrased as:
• A child can be used wherever a parent is expected
• For every overridden method in a child class: require no more, promise no less
1. Pre-conditions (things true before method invoked) cannot be strengthened
2. Post-conditions (things true after method returns) cannot be weakened.
“Good” inheritance
• Use the notion of “is-a” and LSP to determine if your inheritance is “good”
• Don’t overdo inheritance!!
Some consequences
• The class Circle can’t inherit from Oval (even though it “is-a”)
• Why not?
• Would have to restrict overridden “resize” method (strengthen pre-conditions: focus points equal)
• Or we don’t have restricted “resize”, but then we would have to allow for non-perfect circles (weaken post-conditions)
More consequences
• The BagOfApples is NOT a BagOfFruit• Why not?
• Either restrict overridden “add” (strengthen pre-conditions) to disallow adding other types of fruit
• OR, we would have to allow Bananas in the BagOfApples (weaken post-conditions)
The solution
• The classes Circle and Oval should each extend Shape
• Good “is-a” relationship; can substitute Circles and Ovals in where Shapes are expected
• The Shape class will have methods like “draw”, “rotate” and “translate”, which do not have to be restricted in Circle or Oval
Speaking of Shapes…
Shape hierarchypublic class Shape
{
. . .
public void draw(Graphics g) { . . . }
}
public class Line extends Shape
{
. . .
@Override
public void draw(Graphics g) { . . . }
}
public class Oval extends Shape
{
. . .
@Override
public void draw(Graphics g)
{ . . . }
}
public class Square extends Shape
{
. . .
@Override
public void draw(Graphics g)
{ . . . }
}
. . .
Review polymorphic codepublic void paintComponent(Graphics g)
{
Shape s;
if (selection == LINE) // selection is a class variable
s = new Line();
else if (selection == OVAL)
s = new Oval();
else if (selection == SQUARE)
s = new Square();
. . .
s.draw(g); // g is a Graphics object
}
Which shape gets drawn?
The correct one, which is determined at run-time!
What if?public void paintComponent(Graphics g)
{
Shape s = new Shape();
. . .
s.draw(g);
}
What should happen if this code is executed?
What does a shape look like?
It doesn’t really make sense to let “abstract” Shapes draw themselves.
How to prevent this???
Shape is the perfect candidate for a class that
should never be instantiated
Classes that can’t be instantiated: abstract
abstract methods
• An abstract method has no body, not even an empty body
• Example:
public abstract void draw(Graphics g);
• Constructors cannot be abstract
abstract class
• A class with one or more abstract methods
• An abstract class CANNOT be instantiated (would generate a syntax error)
abstract and inheritance
• Must derive from abstract classes (can’t use them directly)– If subclass doesn’t provide bodies for all abstract methods in superclass, then the subclass is also abstract
• An abstract method in a superclass is a way to “force” the child to provide its own implementation
public abstract class Shape
{
protected int x, y; // bad names!
public Shape(int inX, int inY) { . . . }
public abstract void draw(Graphics g); // no way to draw it!
. . .
}
public class Circle extends Shape
{
protected int radius;
public Circle(int inX, int inY, int inRadius)
{
super(inX, inY);
radius = inRadius;
}
@Override
public void draw(Graphics g) { . . . }
. . .
}
Good?public void paintComponent(Graphics g)
{
Shape s;
int x, y;
. . .
s = new Shape(x, y); // NO! Shape is abstract
s.draw(g); // Doesn't make sense
}
NOT good!
Good?public void paintComponent(Graphics g)
{
Shape s;
int x, y, radius;
. . .
s = new Circle(x, y, radius);
s.draw(g);
}
Good!
Any questions?
