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 Banana s in the BagOfApples (weaken post-conditions)

The solution The classes Circle and Oval should each extend Shape Good “is-a” relationship; can substitute Circle s and Oval s in where Shape s 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 Shape s…

Shape hierarchy public class Shape {... public void draw(Graphics g) {... } } public class Line extends Shape public void draw(Graphics g) {... } } public class Oval extends Shape public void draw(Graphics g) {... } } public class Square extends Shape public void draw(Graphics g) {... } }...

Review polymorphic code public 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” Shape s 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; 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?