1 / 17

Lecture 21: Object-Oriented Programming (Section 10.1-10.2)

Lecture 21: Object-Oriented Programming (Section 10.1-10.2). CSCI 431 Programming Languages Fall 2002. A compilation of material developed by Felix Hernandez-Campos and Michael Scott. Data Abstraction and Object Orientation.

burton
Download Presentation

Lecture 21: Object-Oriented Programming (Section 10.1-10.2)

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. Lecture 21: Object-Oriented Programming(Section 10.1-10.2) CSCI 431 Programming Languages Fall 2002 A compilation of material developed by Felix Hernandez-Campos and Michael Scott

  2. Data Abstraction and Object Orientation • Control or process abstraction is a very old idea (subroutines!), though few languages provide it in a truly general form (Scheme comes close). • Data abstraction is somewhat newer, though its roots can be found in Simula67. • An Abstract Data Type is one that is defined in terms of the operations that it supports (i.e. that can be performed upon it) rather than in terms of its structure or implementation.

  3. Historical Development of Abstraction • We’ve talked about data abstraction previously. Recall the historical development of abstraction mechanisms: static set of variables Basic locals Fortran statics Fortran, Algol 60, C modules Modula-2, Ada 83 module types Euclid objects Smalltalk, C++, Eiffel, Java, Oberon, Modula-3, Ada 95

  4. Fundamental Concepts in OOP • Encapsulation • Data Abstraction • Information hiding • The notion of class and object • Inheritance • Code reusability • Is-a vs. has-a relationships • Polymorphism • Dynamic method binding

  5. Software Engineering Goals Encapsulation • Data abstraction allow programmers to hide data representation details behind a (comparatively) simple set of operations (an interface) • What the benefits of data abstraction? • Reduces conceptual load • Programmers need to knows less about the rest of the program • Provides fault containment • Bugs are located in independent components • Provides a significant degree of independence of program components • Separate the roles of different programmer

  6. Method calls are known as messages EncapsulationClasses, Objects and Methods • The unit of encapsulation in an OO PL is a class • An abstract data type • The set of values is the set of objects (or instances) • Objects can have a • Set of instanceattributes (has-a relationship) • Set of instancemethods • Classes can have a • Set of class attributes • Set of class methods • The entire set of methods of an object is known as the message protocol or the message interface of the object

  7. EncapsulationModules and Classes • The basic unit of OO, the class, is a unit of scope • This idea originated in module-based languages in the mid-70s • E.g. Clu, Modula, Euclid • Rules of scope enforce data hiding • Names have to be exported in order to be accessible by other modules

  8. Classes and EncapsulationTwo Views • Module-as-type • A module is an abstract data type • Standardized constructor and destructor syntax • Object-oriented design is applied everywhere • E.g. Java, Smalltalk, Eiffel, C++, Python • Module-as-manager • A module exports an abstract data type • Create and destroy operations • Object-oriented design is optional (OO as an extension) • E.g. Ada 95, Modula-3, Oberon, CLOS, Perl

  9. Visibility Rules • Public and Private parts of an object declaration/definition. • 2 reasons to put things in the declaration • so programmers can get at them • so the compiler can understand them • At the very least the compiler needs to know the size of an object, even though the programmer isn't allowed to get at many or most of the fields (members) that contribute to that size. That's why private fields of an object have to be in the declaration.

  10. Access Restrictions • C++ distinguishes among • public • protected • private class members. • Public means accessible to anybody. • Private means just to members of this class. • Protected means to members of this or derived classes. • A C++ struct is simply a class whose members are public by default. • C++ base classes can also be public, private, or protected. E.g. class circle : public shape { ... anybody can convert (assign) a circle* into a shape*

  11. C++ List Example

  12. C++ Example

  13. C++ Example

  14. C++ Example

  15. Ada 95

  16. Ada 95

  17. Ada 95

More Related