1. CS 2430 Day 28

2. 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

3. Agenda When is inheritance good? Abstract classes

4. When is your inheritance good?

5. 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.

6. “Good” inheritance Use the notion of “is-a” and LSP to determine if your inheritance is “good” Don’t overdo inheritance!!

7. 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)

8. 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)

9. 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

10. Speaking of Shape s…

11. Shape hierarchy public 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) {... } }...

12. 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!

13. 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???

14. Shape is the perfect candidate for a class that should never be instantiated

15. Classes that can’t be instantiated: abstract

16. abstract methods An abstract method has no body, not even an empty body Example: public abstract void draw(Graphics g); Constructors cannot be abstract

17. abstract class A class with one or more abstract methods An abstract class CANNOT be instantiated (would generate a syntax error)

18. 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

19. 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) {... }... }

20. 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!

21. Good? public void paintComponent(Graphics g) { Shape s; int x, y, radius;... s = new Circle(x, y, radius); s.draw(g); } Good!

22. Any questions?