1 / 74

Object Oriented Languages Concepts: 1

Object Oriented Languages Concepts: 1. Lecture 14: Dolores Zage. Mechanisms to Produce flexible and understandable software. Encapsulation polymorphism inheritance. OOP paradigm. Progenitor was Smalltalk motivations

gentle
Télécharger la présentation

Object Oriented Languages Concepts: 1

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 LanguagesConcepts: 1 Lecture 14: Dolores Zage

  2. Mechanisms to Produce flexible and understandable software • Encapsulation • polymorphism • inheritance

  3. OOP paradigm • Progenitor was Smalltalk • motivations • biggest - find a better module scheme for complex systems in hiding the details • smaller - find a more flexible version of assignment and then try and eliminate it altogether

  4. Ada • six major goals • suitable for DOD embedded computer applications • appropriate for design, development, and maintenance of reliable software for large, long-lived and continually undergoing change systems • common language ( complete, unambiguous, machine-independent standards) • not impose execution costs in applications • can build a support environment around it • example of good current language design practice

  5. Ada • In 1976, 23 existing languages were appraised • none met the six goals • 5 companies competed, Honeywell Bull of France led by Jean Ichbaih was selected • standard appeared in 1983

  6. Major Features • Tasks and concurrent execution • real-time control of tasks • exception handling • abstract data types

  7. Ada - a “new” beginning • Types in Ada • Polymorphism

  8. Type Equivalence • What is a type? • When are types equivalent? • For example, many programming languages insist that assignments be between expressions which have “identical types” • Also, formal parameters must have the same types as the actuals in procedure and function calls • What does identical mean?

  9. Type Equivalence • Consider the following Ada program fragment: declare type BLACK is INTEGER; type WHITE is INTEGER; B: BLACK; W: WHITE; I: INTEGER; begin W := 5; B := W; I := B; end; Which of the assignments are legal?

  10. Answer • Answers in both affirmative and negative are reasonable. • Two broad categories of type equivalence • NAME • STRUCTURAL • under name - none of the assignments are legal • under structural - all are legal

  11. Name Equivalence Outer: declare type BLACK is INTEGER B: BLACK; INNER: declare type BLACK is FLOAT; A: BLACK; begin B := A; end Inner; end Outer; The type A and B have the same name, namely BLACK, but the type definitions occur in different scopes. Thus their types are different even though they have same name.

  12. Structural Equivalence Type T1 is record X: INTEGER; N: access T1; end record Type T2 is record X: INTEGER; N: access T2; end record Type T3 is record X: INTEGER; N: access T2; end record Type T4 is record N: access T5; X: INTEGER; end record Record type T2 just renames T1 to T2, under structural equivalence the name chosen for the type does not change the type, so T1 and T2 are structurally equivalent. Record type T3 just substitutes names, so it too is structurally equivalent. Finally, T4 and T5 may or may not be equivalent. If order is not important, then T4 is equivalent. If the field names are part of the structure (and usually they are), then T5 is not type equivalent to the others. Type T5 is record Y: INTEGER; N: access T6; end record

  13. Testing Equivalence • Is not easy! • C uses structural equivalence, but when this becomes difficult, i.e., with struct, C uses name equivalence. C++ uses name equivalence. • Name equivalence is sometimes favored because it is simpler and safer

  14. Is Name Equivalence Safer and Simpler? • Consider: • type point is record first, second: real end record; • type complex is record first, second: real end record; • These types are distinct in name equivalence, thus in the scope of • var p: point; z: complex; • both z:=p and p:=z are wrong

  15. Is Name Equivalence Safer and Simpler? • It may be just an accident that the two types are structurally similar. The two conceptually represent completely different data structures. For this reason name equivalence is popular. • Name equivalence is not always clear, because the types of some objects do not have a user-defined or language defined name. In some versions of Pascal the types of x and y and u and v are equivalent but no others. This is called declaration equivalence Type T = record a: integer; b: char end; var x,y: array [1..2] of record a: integer; b: char end; z : array[1.. 2] of T; u,v: array[1..2] of record a: integer; b: char end;

  16. Name Equivalence • The strict interpretation of name equivalence forces the programmer to add a few new type names, in order to ensure that certain variables have the same type. • The strict interpretation also has other considerations

  17. Name Equivalence declare N: INTEGER; type INDEX is INTEGER range 1 ..10; I: INDEX; begin N := I; -- illegal, different types I := I +1; -- illegal, + is for type INTEGER not INDEX • Want an INDEX type to convey the intention that the value of the variable will be a subset of the integers, yet use it as an integer.

  18. Types in Ada • Ada chose name equivalence • Several problems to overcome with name equivalence as we saw • Ada has two innovative type constructs (for the 80s) • subtypes • derived types

  19. Subtypes • Ada solution to the subrange problem is to introduce subtypes, which are not really types at all. As far as the compiler is concerned INDEX is just another name for INTEGER. The purpose of an Ada subtype is the run-time guarantee that the program will notice if the value is out of range. declare N: INTEGER; subtype INDEX is INTEGER range 1 ..10; I: INDEX; begin N := I; -- legal I := N; -- possible, run-time error, but type correct I := I +1;

  20. Subtypes • Subtypes are a way of constraining the values that variables can take at run time • The variables M and F have the same type, but assigning June to F will cause the predefined exception CONSTRAINT. ERROR to be raised. Type Month = (Jan,Feb,March,April,May,June,July,Aug,Sept,Oct,Nov,Dec); subtype Fall is month range Oct .. Dec; M : Month; F: Fall;

  21. Derived Types • Create an isomorphic copy of another type type Centimeters is new INTEGER; -- type definitions type Meters is new INTEGER; Length1: Meters; -- variable definitions Length2: Centimeters; Length1 := Length2 -- cannot be mixed, illegal Length1 := 5 + 2 * Length1; -- perfectly legal, 5 and 2 are ints

  22. Derived Types • Functions and constants can be overloaded in Ada • Only through overload resolution can the proper operation be found • In overload resolution the compiler chooses from among different alternatives for the code to run for some operation. • This is DIFFERENT than conversion

  23. Overloading • Overload resolution is particularly difficult in Ada, since the user can overload operations as well. Function “+” (cm: Centimeters, m: Meters) return Centimeters is begin return (cm + Centimeters(100 * INTEGER(m))); end “+”; Function “+” (m: Meters, cm: Centimeters) return Centimeters is begin return (cm + Centimeters(100 * INTEGER(m))); end “+”;

  24. Overloading • Similar in C++ • but functions differing in only the return type may not have the same name • implicit coercion is not allowed in Ada int f (int i1, int i2) { return (8);} // f1 int f (int i1, double d2) {return (3.5); } //f2 int x = f(1,2); //f1 double y = f( 1, 2.0); //f2 int z = f(1.3, 2); //f1 ( an implicit coercion to int) NOT ALLOWED

  25. Polymorphism • An important purpose of PL design is to find the right abstractions that permit the clear expression of algorithmic ideas • also to reuse these in more complex constructions • it is tedious and error-prone to repeat the same algorithmic content with small variations • example - writing separate Pascal function for arrays of different size, or writing the C code for linked lists of one type and again for another type

  26. Polymorphism • If a subprogram or function can assume more than one type, it is said to be polymorphic. • Polymorphism can be divided into • universal • ad hoc

  27. Kinds of Polymorphism parametric Universal subtype Polymorphism overloading Ad hoc Implicit coercion

  28. Ad hoc versus Universal • Distinguished by different code for the different manifestation of operators • ad hoc - the compiler chooses from an ad hoc and finite number of choices for the correct code to generate • universal - the appropriate arguments to a procedure must be a uniform collection of data structures

  29. Overloading and Implicit Coercion • Overloading occurs when the same name is used for different functions (like the + in Ada). • Implicit coercion occurs when values of one type are routinely converted to another so that a value will have a type appropriate context.

  30. Coercion • Consider 1/3 + 25 • in some languages the answer is 5.333333 • one-third is computed to 15 digits of precision, 14 to the right of decimal point. Then 25 is coerced to the same, losing the most important digit the 2. • Law of least astonishment Always expect the “weirdest” outcome.

  31. Parametric and Inclusion Polymorphism • Universal polymorphism divided into parametric and inclusion. • Differ in what facet of data structures they take advantage of • parametric takes advantage of the fact that data structures are built from many layers of constructors. Not all the layers may be relevant to a particular function.

  32. Parametric and Inclusion Polymorphism • Inclusion takes advantage of the fact that not all fields of records may be relevant to a particular function • in both cases, the part of the data structure that is not relevant to a function is permitted to be filled by different structures with different types

  33. Parametric • Language in which functions have type parameters as well as ordinary arguments • function id [T] (x: T) = return (x) • The identifier T is a type parameter • Notice that the type of the value argument x depends on it • id [Int] (3) • id [Real] (2.3)

  34. Ada Generics • A form of parametric polymorphism can be achieved in Ada using generics Generic type Type is private; function Id(X: in Type) return Type is begin return X; end;

  35. Generic • The id Type is generic parameter - not a predefined type. • This is just a template, it is not executable • to create a function, the template must be instantiated with a particular type • function IntId is new Id (INTEGER); • function FloatID is new ID(FLOAT);

  36. Record model of OO programming • It is possible to capture the aspects of what are called OO programming languages using inclusion polymorphism • Objects are records, methods are fields with subprogram values

  37. Ada Language Evaluation • Language was more complex than expected • took several years (late 80s) to get an effective compiler • Ada has proven to be effective in environments where its use has been mandated, but limited in other environments • Ada is cumbersome for programming in the “small”

  38. Ada Language Evaluation • The advent of C++ has greatly changed the Ada landscape • Ada’s use had been growing in late 80’s • the increase use of C and C++, Ada development has slowed or stopped • C++ has the advantage that the underlying implementation is visible to the programmer which allows the programmer to better understand how the program will execute • In Ada the underlying execution model is often hidden

  39. Abstract Data Types • New data type defined by the programmer that includes • a programmer-defined data type, • a set of abstract operations on objects of that type, and • encapsulation of objects of that type in such a way that the user of the new cannot manipulate those objects by use of the predefined operations.

  40. Data Abstraction • Fundamental part of programming • if the programming language provides little direct support for data abstraction beyond the subprogram mechanism, the programmer may still design and use his own abstract types • he uses his own “coding conventions” to organize his program so that the effect is achieved • without the support for the definition of abstract data types, encapsulation of a new type is not possible

  41. Data Abstraction • if coding standards are violated, whether intentionally or not, the language implementation cannot detect the violation • such programmer-created abstract data types often appear as special subprogram libraries in languages such as C, FORTRAN, Pascal - enforcing “protection” • Ada and C++ (Smalltalk) are among the few widely used languages with data abstraction features

  42. Encapsulation Reviewed • Access restricted so that only subprograms that know how data objects of the type are represented are the operations defined as part of the type itself

  43. No language support for encapsulation of abstract type definitions • Type definitions are provided by C • it is simple to declare new variables of the type, since only the type name is needed in the declaration. • Also any subprogram that can declare a variable to be of the new type is also allowed to access any component of the representation of the type • the subprogram can bypass the defined operations on the data objects and instead directly access and manipulate the components of the data objects

  44. Language Support for encapsulation of abstract type definitions • Ada, C++ and Smalltalk provide such support • Ada through the package construct • C++ and Smalltalk through classes

  45. Example of a Package defining an abstract data type Package SectionType is type StudentId is INTEGER; type Section(MaxSize: INTEGER) is private procedure AssignStudent(Sect: in out Section; Stud in Student ID); procedure CreateSection(Sect: in out Section; Instr in integer; Room in INTEGER); private type Section(MaxSize: INTEGER) is record Room:INTEGER; Instructor: INTEGER; ClassSize: INTEGER range 0..MaxSize :=0 ClassRoll: array(1..MaxSize) of StudentId; end record; end; The declaration is private for type Section indicates that the internal structure of section data object is not to be accessible from subprograms outside of the package

  46. Other observations on Package SectionType • Each Ada package contains two parts • a specification (last slide) - defines all data, types and subprograms that are known and made visible to procedures declared in other packages • an implementation part ( the body)- implementation of the procedures declared in the spec part plus addition data objects, types and procedures that are not to be made visible to other packages

  47. Package SectionType Body package body SectionType is procedure AssignStudent(…) is -- statements to insert student on ClassRoll end; procedure CreateSection(…) is -- statements to initialize components of Section record end; procedure ScheduleRoom(…) is -- statements to schedule section in a room end; end;

  48. Other comments about SectionType • The need of the procedure name in the package spec is clear enough - the compiler need to know the signature of the procedure if is called from another package • HOWEVER, why are the private data definitions place in the package specs, since they are information that is known and used only within the body of the package?

  49. Implementations for abstract data types • Basically two models • indirect encapsulation • direct encapsulation

  50. Activation record package A Activation record package B Activation record package A Activation record package B P P Indirect encapsulation of object P abstract type is defined in Package A Package B declares and uses object P (abstract type in A) the actual storage for P is maintained in the activation record for package A Activation record of package B must contain a pointer to the actual storage Direct encapsulation of object P abstract type is defined in Package A Package B declares and uses object P (abstract type in A) the actual storage for P is maintained in the activation record for package B

More Related