1 / 28

Object Oriented Programming

Object Oriented Programming Some Interesting Genes Object Oriented Programming A Brief Encounter What Abstract Data Types Classes Objects Methods Inheritance Polymorphism Why Productivity increase Better code Reusable code Easier to model real things Object Oriented Design

paul
Download Presentation

Object Oriented Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related