1. Abstraction ADTs, Information Hiding and Encapsulation

2. ADT • ADT = Abstract Data Type • A theoretical concept • A set of (homogeneous) objects together with a set of operations on those objects • NO mention of how the operations are implemented • NO rules tell which operations are required • A design decision

3. Two Faces of an ADT • From the outside, the user sees only a collection of operations that together define the behavior of the abstraction • On the other side, the programmer defining the abstraction sees the data variables that are used to maintain the state

4. Stack ADT • The user sees only the description of the legal operations -- push and pop • The implementer knows the concrete data structure used to implement the abstraction • The concrete details are encapsulated within a more abstract framework

5. ADTs (cont’d) To build an ADT, we must • Export the type definition • Make available a set of operations to manipulate instances of this type • Protect the data associated with the type so they can be operated on only by provided operations • Make multiple instances of the type

6. Abstraction • A mechanism to control complexity • Complexity due to interconnections between software components. I.e. the dependence of one portion of code on another section of code • The ability to encapsulate and isolate design and execution information • Using data abstraction is a methodology wherein information is consciously hidden in a small part of a program

7. Procedures • First Abstraction Method • Allowed repeated tasks to be collected in one place and be reused • Gave possibility for information hiding • One programmer writes procedure(s) • Other programmers just need to know interface, not implementation

8. Function 1 Function N In a procedural application, the characteristics (data) and behaviors (functions) may be in the same file Characteristics Function 2 Behaviors

9. Or may be in different files. There may be more than one set of data which use the same functions. Characteristics Behaviors

10. Procedural Stack Example main ( ){ STACK s1; STACK s2; push (s1, 7); push (s1, 10); push (s2, 5); push (s2, pop(s1)); . ………. } void push (STACK s, int i){ // code for push}int pop (STACK s){ // code for pop}

11. What’s the Problem? • The data (STACK variables s1 and s2) are changeable by any line of code in main( ) • The data is “public”

12. Modules • A collection of procedures and related data (a .C file) divided into two parts • Public part accessible outside the module • Private part accessible only within the module

13. Modules (cont’d) • Popularized by David Parnas • “[A module] must provide the intended user with all the information needed to use the module correctly, and with nothing more.” • “[A module] must provide the implementer with all the information needed to complete the module, and nothing more”. • Like the military “need to know” philosophy

14. Modules (cont’d) • Solve some (not all) software development problems • Ex: Stack module • Stack data private • Stack routines public

15. Main.C Stack.C main ( ) { …. } Private Characteristics Public Behaviors

16. Modular Stack Example main ( ){ push (7); push (12): push (15); int x = pop ( ); ………. } static STACK s; void push (int i){ // code for push}int pop ( void ){ // code for pop}

17. What’s the Problem? Question:How do you use more than one stack at a time? Answer:You don’t

18. ADTs with OOP • OOP allows us to instantiate multiple instances of each object. • Each gets its own set of characteristics. • Conceptually, each gets its own set of behaviors • This was what procedures and modules couldn’t give us

19. Objects • The characteristics and behaviors are encapsulated in a single entity (an object). • That entity decides which characteristics and which behaviors are publicly available and which remain private.

20. Encapsulation • Restricting the effects of change by putting a “wall of code” around the data • All access to the data is handle by procedures (functions, behaviors) that were put there to mediate access to the data

21. An OOP Application An OOP Application An Object Object Oriented Application PublicBehaviors private Characteristics

22. Message Passing • OOP extends the concept of ADT by adding the concept of message passing. • A program requests that an object perform a certain operation. • Objects can also request that other objects perform operations

23. A Change of Emphasis • Do you call the push routine with a stack and a data value OR • Do you ask a stack object to push a value onto itself

24. Inheritance • Allows different data types to share the same code • Reduced code size • Increased functionality

25. VEHICLE Land Vehicle Water Vehicle Air Vehicle Car Bicycle Train Boat Submarine Plane Zeppelin Commercial Military Private

26. Procedural “Polymorphism” Similar behavior for each representation Procedural Application Characteristics

27. OO Polymorphism Similar behavior for each representation OO Application Single Interface