Chapter 6 Encapsulation

1. Chapter 6 Encapsulation • Why do we want encapsulation? • Programmer friendliness- programmer need not know about these details • Easier to read, write, modify • Security – programmer cannot corrupt data • Primitive data types are encapsulated • (Not entirely –Pascal variant record, C union, FORTRAN equivalence) • # of bits or digits that implement numeric type perhaps needs to be known G. Levine Chapter 6

2. User defined types • Ability to define new type (Pascal, typedef) • Orthogonality- same syntax and semantics for user defined types and primitive types • Ex: User defined and system defined integer should use infix operators • Structured data types with complex relationships between potentially heterogeneous fields • Ex: Records of records, ptrs as components for recursive data structures • Subprograms for defining functionality of new type • Inheritance (chapt 7) G. Levine Chapter 6

3. Attributes of structured types • Number of components • Type of each component • Organization of components • Names (i.e., index) for selecting components • Is there a limit on the number of components (such as max stack size); is this limit a function of the compiler or hardware? • Can the structure be changed dynamically? • Insertion/deletion of components G. Levine Chapter 6

4. Operations on user defined types • Are primitive operations available (i.e, succ, ++, WRITE); can they be defined to be used by same name (overloading), same form • Primitive aggregate operations • APL – array aggregate operations • SNOBOL – string operations • LISP – list operations • Assignment of values of one to another • (strcpy is library function) • Component selection • Restrictions? • Creation/ destruction of objects G. Levine Chapter 6

5. Implementation- Storage Allocation • Allocate storage for components • Allocate storage (perhaps) for descriptor • Static or dynamic allocation of storage • Efficiency- use of hardware as possible • Sequential or linked storage allocation • Sequential : Base address + offset • This is why C arrays begin with 0 • Linked: follow chain of ptrs • How much can be done at compile time? G. Levine Chapter 6

6. Implementation – Storage Mgt Issues • Lifetime of a data object spans from allocation of storage (and value initialization) to deallocation of storage (binding) and the creation of an ACCESS PATH to it • Data object may have several access paths • ptr1 := ptr2 (ptr assignment) • void copy (int &objects); (reference parameter) • array and array (0) (Array names) • Storage management problems • Garbage - when all external access paths have been lost • Dangling references (ptrs) – when storage has been deallocated (data object is dead), but an access path to it still exists; storage may have been reassigned to another data object G. Levine Chapter 6

7. Type checking for composite objects • Composite type • Number of dimensions (arrays) • Number of components • Type of each component • Range of selection operator • Out-of-range run time hander? • Operations on aggregate type • Ex: C’s string op if not terminated • Operations between components G. Levine Chapter 6

8. Implementation of vectors/arrays • Homogeneity assumed • Fixed size assumed (Pascal) • If size is not known at compile time, then array descriptor (dope vector) is allocated storage by compiler • (a) Base address of vector • LB • UB • component type • (E) component size • (extend above for multiple dimensions) • A(I) is stored at • a + (I-LB)*E • LB is always 0 in C • Where is the array stored? G. Levine Chapter 6

9. Type equivalence How are two objects equivalent, say for assignment or parameter passing • Name equivalence • Same type names • Cannot be any anonymous types • var W: array [1..10] of real; • Type must be declared globally • Supports strong typing • Structural equivalence • Assignment based on component(s) structure • Does not support dimensional analysis • Compare to coercion, casting G. Levine Chapter 6

10. Semi-dynamic arrays • Needed to create general purpose module for all sizes of arrays of that type • For example, vector addition • Need not give a maximum size nor allocate some maximum storage block • Programmer need not be concerned with keeping track of array size • Values in dope vector can be assigned on module entry • Storage for vector allocated on top of the stack G. Levine Chapter 6

11. Packed and unpacked representations • Packed structures save storage • Since typically packed unit is not addressable, there is efficiency cost is unpacking • Ex: Cobol packed decimals • Ex: Pascal characters • Ex: arrays of booleans G. Levine Chapter 6

12. Associative arrays • Subscripts are names • Ex: Perl Declaration • %ClassList = (“Michelle”, ‘A’, “Doris”, ‘B’); Dereferencing • $ClassList {“Michelle”} // ‘A’ • Stored in key alphabetic order for search G. Levine Chapter 6

13. Implementation of records • Attributes • Number of components • Type of each component • Selector (name) for each component • Aggregate operations • Assignment • Sequential storage allocation • Information available at compile time • Records of composite types G. Levine Chapter 6

14. Variant records • Use as general purpose procedure • Type checking (tag field present) discriminated union • Free Union/ representation viewing • Storage allocation • Maximum size • Size allocated by type • Compare to inheritance with objects G. Levine Chapter 6

15. Sets and Lists (LISP) • Pascal sets are limited to bit representation for set membership • Operations of union, intersection, delection, insertion, deletion • Typically limited in size to machine word size • SET-L has heterogeneous sets • LISP has primitive List type • Program is also a list • (define myfunction (cons (a b c) (d e f ))) • Primitive list operations G. Levine Chapter 6

16. Control Abstraction and encapsulation • Functions and procedures • Information hiding • Programmer defined abstraction mechanism • Need only inform user of function and interface • User cannot manipulate body of function • Ignore FORTRAN’s multiple entries • Ignore multiple exits • Ease of replacement of unit • Problems with global data and reference parameters • History sensitive (static) data G. Levine Chapter 6

17. Data Abstraction and encapsulation • All operations are defined for type • User cannot access objects except through provided operations • Selection operators must be provided • Initialization must be provided • Different method of breaking down complex system • Solves global data problem • Simplifies interface • May simplify replacement of parts G. Levine Chapter 6