Object Oriented Programming - PowerPoint PPT Presentation

paul
slide1 l.
Skip this Video
Loading SlideShow in 5 Seconds..
Object Oriented Programming PowerPoint Presentation
Download Presentation
Object Oriented Programming

play fullscreen
1 / 28
Download Presentation
Object Oriented Programming
711 Views
Download Presentation

Object Oriented Programming

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Object Oriented Programming Some Interesting Genes

  2. Object Oriented Programming A Brief Encounter

  3. What • Abstract Data Types • Classes • Objects • Methods • Inheritance • Polymorphism

  4. Why • Productivity increase • Better code • Reusable code • Easier to model real things

  5. Object Oriented Design • one identifies real objects and the operations on them that are interesting. • these operations can then by systematically implemented. • for example: we might have pdf’s and cdf’s as different objects. • methods might be means, median, maxima and so on.

  6. Object Oriented Design • a basic principle (or perhaps hope) is that by faithfully representing the objects we get easier to implement functions. • if a cdf object knows how to answer all the cdf questions then it is more useful. • if, instead, the cdf is implemented as two vectors (xpos and ypos), it is harder for others to use it.

  7. Three big ideas • Abstraction: think only about the components of the problem that are important. • Encapsulation: keep the means used to produce the result secret. Other programs get to see only what you want them to. • Modularity: group related services into a module with a well defined interface. Other programs should rely only on the interface.

  8. ADT’s • we usually write programs to manipulate data • data can almost always be represented in many different ways • we don’t want our program to depend on the representation of the data • an abstract data type provides with a mechanism to avoid a dependence on representation

  9. ADTs • a point in the plane can be represented either in terms of its x and y coordinates or in terms of r and q. • if we write a program that assumes one form or the other then we cannot easily change (and cannot easily use data obtained in different ways) our representation.

  10. ADTs • if instead we employ the rather simple tactic of only accessing the data through a function (a macro in many languages) then we can make the access independent of the representation. • have a look at the R code in • ~rgentlem/Rexamples/xy.R

  11. Classes • A class is a specification. It generally consists of some slots and some functions or methods that act on those slots. • The slots represent values that are intrinsic to the class. • There are many different classes that can represent a single ADT.

  12. Classes • Consider a triangle. If we know the lengths of the three sides then we know all about the triangle. • So we could implement triangles as objects with three slots: the lengths of each side. • We could also implement them as classes with 2 side slots and the angle between the two.

  13. Classes • Why would I prefer one implementation over the other? (Basically efficiency) • An operation that we might want to perform on a triangle is finding its area. • Should we make area a slot? • Should we compute it each time it is needed?

  14. Instances • Once I have defined the class I need to obtain some objects that are of that class. • These are called instances. And one usually says something like instantiate. • All programming is done on instances of a class.

  15. Some Subtleties • Much of the usefulness of object oriented programming comes from the fact that different instances have different values for the slots. • Sometimes we want there to be a slot that has the same value for all instances. This is a class slot (not all OO systems have this).

  16. Objects • One definition of an object is that it is a set of operations that share a state. • The state consists of one or more values that can only be viewed and modified by operations belonging to the object. • The state information is available through the slots.

  17. Objects • Some implementations allow direct access to the slots (usually for efficiency) but this can break the data abstraction. • In other implementations one can only access slots through accessor functions. • Then the implementation can change but I need to only change the accessors, not all my code.

  18. Classes vs Objects • an object is a specific entity that exists at run time • a class is a static entity that exists in the program code • a class describes how to create an object (and in some languages how to interact with that object)

  19. Instances/Objects • We instantiate an object with a call to a constructor. Usually it has a nice name like new. • x = new(“circle”, r=3.3) • Now x is an instance of the circle class. • The next step is to think about functions that operate on circles (or more properly instances of the circle class).

  20. Methods • A method is a function. But it is a special type of function. • Methods act on instances. The argument list for a method is often referred to as a signature. The types of the arguments to a method are used to determine which method should be called.

  21. Methods • Methods can have single dispatch. That means that the appropriate method is determined by using a single argument. • This is the system used in the S class system. There it is the class of the first argument that is used. • For multiple dispatch we want to use all (or many) of the arguments to determine the appropriate method. (S4 methods).

  22. Methods • A method is simply a function that has been called from a generic. • In many systems it is not possible to call a method directly (and usually it is not a good idea in any system). • Accessing slots directly breaks the notion of an ADT.

  23. Programming • let’s return to the code in xy.R. • in S4 classes there are no accessor functions created by default • you must write your own, this is what I have done using Xpos and Ypos • can you see a problem with taking that approach?

  24. Problem • Why do I have to have Xpos.xy and Xpos.rt? • I really just want Xpos! • This is where generic functions come in. They basically act as dispatchers. • The mechanisms used to determine which method (we can think of Xpos.xy and Xpos.rt as methods) differ between languages.

  25. Generic Functions • a generic function is a dispatcher • it determines the type of arguments and looks for a method that will match those arguments. • that method is then invoked with the arguments used for the generic function.

  26. Costs • so what does this cost? • it tends to be slower (this does not have to be true) in terms of execution time • the burden goes from programming to design (often a good thing).

  27. NextMethod • in most (but not all) languages there is a concept of the next method that would be appropriate (after the current method). • In the S3 class system there is a NextMethod function. • In the S4 object system it is being developed.

  28. Why bother? • you know you are only going to write small programs • it’s easier to learn good style on small programs • small programs have a tendency to grow into large programs • small program, written well, can be used as components in large programs