lecture16

# lecture16 - Caltech CS 1 Fall 2010 Lecture 16 Inheritance...

This preview shows pages 1–11. Sign up to view the full content.

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Caltech CS 1: Fall 2010 Lecture 16 : November 17, 2010 Inheritance Caltech CS 1: Fall 2010 Exception handling • catching exceptions outside of the function that raised the exception • the runtime stack Caltech CS 1: Fall 2010 Class inheritance • subclass, superclass • polymorphism • demos Exceptions and classes • Exception objects • the raise statement • the pass statement • the Exception base class Caltech CS 1: Fall 2010 Previously we defined a Square class that represented squares on a Tkinter canvas object Using Square s and methods made it easy to do a lot of things that are more complicated without them: • setting size ( setSize ), color ( setColor ) • moving the square ( move and moveTo ) • deleting the square ( delete and __del__ ) • changing the stacking order ( lift Caltech CS 1: Fall 2010 Previously we defined a Square class that represented squares on a Tkinter canvas object Using Square s and methods made it easy to do a lot of things that are more complicated without them: • setting size ( setSize ), color ( setColor ) • moving the square ( move and moveTo ) • deleting the square ( delete and __del__ ) • changing the stacking order ( lift ) Caltech CS 1: Fall 2010 Notice that none of the Square class methods are really specific to Square s If we had a Circle or a Triangle class, we would still want to do the following: • setting size ( setSize ), color ( setColor ) • moving the shape ( move and moveTo ) • deleting the shape ( delete and __del__ ) • changing the stacking order ( lift ) Caltech CS 1: Fall 2010 Furthermore, some of the code for these methods would probably be similar or identical: def setColor (self, color): '''Changes this object's color to 'color'.''' self.canvas.itemconfig(self.handle, fill=color, outline=color) self.color = color There is nothing specific to Square s here If this was in a Circle class, would define the exact same method! Caltech CS 1: Fall 2010 In fact, for all these Square methods: • move, moveTo • lift • setColor, setSize • scale • delete, __del__ the code would be exactly the same for Circle methods! The only change would be in the Circle constructor ( Circle.__init__ ) Caltech CS 1: Fall 2010 We have been telling you to obey the D.R.Y. principle in programming: • D.R.Y. = D on't R epeat Y ourself But here, we have two classes ( Square and Circle ) which repeat nearly all of their code • (everything but the constructor) This is highly undesirable This kind of situation comes up quite frequently when writing classes Caltech CS 1: Fall 2010 We would like to have a way to share the code for the methods in the Square and Circle classes that are identical in those classes There is a way to do this: class inheritance Before we explain this, we need to explain one other thing first Caltech CS 1: Fall 2010 What happens when we try to call a method on an object when the method doesn't exist? an object when the method doesn't exist?...
View Full Document

## This note was uploaded on 02/22/2011 for the course CS 1 taught by Professor Pinkston,d during the Fall '08 term at Caltech.

### Page1 / 71

lecture16 - Caltech CS 1 Fall 2010 Lecture 16 Inheritance...

This preview shows document pages 1 - 11. Sign up to view the full document.

View Full Document
Ask a homework question - tutors are online