Presentation is loading. Please wait.

Presentation is loading. Please wait.

G. Levine Chapter 6 Chapter 6 Encapsulation –Why do we want encapsulation? Programmer friendliness- programmer need not know about these details –Easier.

Similar presentations


Presentation on theme: "G. Levine Chapter 6 Chapter 6 Encapsulation –Why do we want encapsulation? Programmer friendliness- programmer need not know about these details –Easier."— Presentation transcript:

1 G. Levine Chapter 6 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

2 G. Levine Chapter 6 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)

3 G. Levine Chapter 6 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

4 G. Levine Chapter 6 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

5 G. Levine Chapter 6 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?

6 G. Levine Chapter 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

7 G. Levine Chapter 6 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

8 G. Levine Chapter 6 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?

9 G. Levine Chapter 6 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

10 G. Levine Chapter 6 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

11 G. Levine Chapter 6 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

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

13 G. Levine Chapter 6 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

14 G. Levine Chapter 6 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

15 G. Levine Chapter 6 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

16 G. Levine Chapter 6 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

17 G. Levine Chapter 6 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


Download ppt "G. Levine Chapter 6 Chapter 6 Encapsulation –Why do we want encapsulation? Programmer friendliness- programmer need not know about these details –Easier."

Similar presentations


Ads by Google