Object Oriented Programming & Design - Abstraction Lecture 2

1. Object Oriented Programming & Design - AbstractionLecture 2 John Anthony RPI - Adjunct Assistant Professor Department of Engineering and Science

2. Topics • What is Abstraction • The Lientz Study • Examples of Abstraction • Layered View of an Object Oriented Program • Other Forms of Abstraction • Introduction to Abstract Data Types

3. Abstraction The most effective weapon that computing scientists have in their fight against complexity is abstraction. What is abstraction? • A simplified description or view of something that emphasizes characteristics or purposes relevant to the user, while suppressing details that are immaterial or distracting. Translated: focus on the what not the how. http://www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/glossary.html

4. Remember Information Hiding? • Certain details can and in many cases should remain hidden from the client… Why is this????

5. Part of the Answer… Bennet P. Lientz and E. Burton Swanson: Software Maintenance Management: a Study of the Maintenance of Computer Application Software in 487 Data Processing Organizations, Addison-Wesley., Readinhg (Mass.), 1980.

6. Examples of Abstraction • Abstracts of a research papers • Maps • Virtual Memory • The relationship between a registrant for a Race and the Register (Active). • Java.lang.String (vs. array of bytes) • etc.

7. Layered View of an Object Oriented Program Service 1 n Program 1 Decreasing levels of abstraction n Packages 1 n Classes 1 n Operations

8. Layered View - Services Service (Service Oriented Architecture) Service 1 • Services provide network addressable, loosely coupled, and stateless operations to consumers. • Network Addressable – bound to a network address (URI) and (often) published to a registry for discovery. • Loosely Coupled – services exchange data and are invoked using non-proprietary technologies. Services can also be composed into other services. • Stateless – the execution of a Service N does not depend on the execution of Service N-1 or Service N+1. n Program 1 Decreasing levels of abstraction n Packages 1 n Classes 1 n Operations

9. Layered View - Programs Program Service 1 • An object oriented program is a “community” of objects that interact in order to achieve a common goal. A program is the implementation of a service. • Community of Objects –The interface of a program hides the complexity of the underlying number, types, and relationships between the objects. Application Programming Interface (API) User Interface • Common Goal – the program and its underlying model should solve a problem or set of like problems. n Program 1 Decreasing levels of abstraction n Packages 1 n Classes 1 n Operations

10. Layered View - Packages Packages Service 1 Some OOP languages support the grouping of classes into packages. Packages provide a (logical) grouping of classes while providing mechanisms for certain classes and features to be package public and package private. n Program 1 Decreasing levels of abstraction n Packages 1 n Client Classes Package x 1 Class A Class B n Class C Operations

11. Layered View - Classes Classes Service A class is a static representation of the data and behavior of a set of objects. The public interface of a class serves as a contract to the supplier. The interface should abstract the internal implementation details of the supplier from the client. Consider: public, friendly Note: Java supports the notion of inner and anonymous classes which provides yet another level of abstraction at the class level. 1 n Program 1 Decreasing levels of abstraction n Packages 1 n Classes 1 n Operations Client Supplier Class A Class B

12. Layered View - Operations Operations Service 1 • The class level is concerned with what parts of the interface should be exported or made public. • Abstraction considerations can be broken down into design-time and compile-time. • Compile-time • Access modifier (public, protected, private, friendly) • Design-time • Operation Name • Operation Parameters • Return Values (also know as functions) n Program 1 Decreasing levels of abstraction n Packages 1 n Classes 1 n Operations Client Supplier Class A Class B

13. Other Forms of Abstraction

14. Encapsulation & Composition • Encapsulation - A technique for hiding information within a structure. • Composition – A technique for building complex structures out of simpler parts.These techniques not only provides abstraction, it also supports interchangeability. Redesigned And Gate Memory Control Unit Decoder Not Gate Computer CPU ALU Full Adder And Gate Bus Registers Logical Unit OR Gate higher levels of abstraction

15. Composition Example Regular Expressions - A pattern of characters used to match against the same characters in a search. They usually include special characters, which represent things other than themselves, to refine the search. Text Regular Expression Result Catastrophic cat cat (0,3) Catastrophic cat. cata(0.4) Catastrophic [cbz]at cat(0,3) Catastrophic6 ([a-z]*[^5]\b) no match

16. Composition Example 2 • Consider building a GUI in Java. Insert picture of GUI and highlight composition

17. Encapsulation & Composition (con’t) Encapsulation Composition Public Part Secret Part

18. Inheritance • The property of objects by which instances of a class can have access to data and method definitions contained in a previously defined class (the ancestor), without the definitions being restated. When designing a CPU, you’d like to be able to swap in and out different scheduling algorithms without having to build in special considerations into the CPU. Partial implementation Operating System Scheduler higher levels of specialization higher levels of abstraction FCFS SJF RR

19. Composition vs. Inheritance • How do we know when to use which strategy? Apply the “is-a” and the “has-a” test.

20. Interfaces • Interfaces can be separated from the implementation. • The interface describes the “what” and the implementation describes the “how”. Interface Implementation public interface Stack { public void put(Object o); public Object top(); … } public class ListStack implements Stack public void put(Object o) { list.add(o); } … }

21. Cohesion and Coupling • Cohesion – the degree to which components of a single software system (such as members of a single class) are tied together. • Coupling – the degree to which separate software components are tied together. Design goal: Systems (objects) should be highly cohesive and loosely coupled.

22. Poor Cohesion public abstract class Policy { private List drivers; …. /** * @return Returns the drivers. */ public List getDrivers() { return drivers; } /** * @param drivers The drivers to set. */ public void setDrivers(List drivers) { this.drivers = drivers; } …………. }

23. History of Abstraction Mechanisms Assembly Language opcode Operand1 Operand2 33 372 376 35 377 376 integer addition integer subtraction memory locations

24. Assembly Language (with Assembler) Command var1, var2 ADDI A, X SUBI B, X integer addition integer subtraction pointers

25. Procedures & Functions First mechanism for reuse and information hiding. However, there were still problems… …. boolean locked = false; void lock() { locked = true; } void unlock() { locked false; } ….

26. Modules Dr. David Parnas – father of modular design. "...it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others." Modules - divided the name space into public and private areas. …. private boolean locked = false; public void lock() { locked = true; } publicvoid unlock() { locked false; } ….

27. Abstract Data Types • The notion of an ADT was driven by two important goals: • The need to define new data types (beyond the primitives supported by the language). • The need to use the features of an ADT without being exposed to the underlying implementation. An Abstract Data Type (ADT) is an abstract specification that defines the data types and operations independent of the implementation.

28. Abstract Data Types (con’t) Every ADT must contain 4 paragraphs: • Types • Functions • Axioms • Preconditions

29. The Stack ADT The Stack class represents a last-in-first-out (LIFO) stack of objects. It extends class Vector with five operations that allow a vector to be treated as a stack. The usual push and pop operations are provided, as well as a method to peek at the top item on the stack, a method to test for whether the stack is empty, and a method to search the stack for an item and discover how far it is from the top.

30. Types • The types paragraph lists the types introduced into the specification. Types Stack [Object] This specification is about a single abstract data type Stack, describing stacks of objects of type Object.

31. Functions • The functions paragraph lists the operations applicable to instances of the ADT. Functions push: Stack[Object]  Object pop: Stack[Object]  Object peek: Stack[Object]  Object empty: Stack[Object]  boolean

32. Functions (con’t) The functions paragraph described the signatures of the functions but it did not define the functions. As such, we do not have a Stack (LIFO) yet.

33. Axiomatic Definitions Each axiom must hold for all instances s of type Stack and all elements x of type Object. A1: tells us that the top element of the stack is the last element pushed Axioms For any x:Object, s:Stack[Object], A1: peek (push (x) ) = x A2: pop (push (x) ) = s A3: empty (new) A4: not empty (push(s, x)) A2: tells us that removal of the top element returns the stack to the state it had before the last push A3: tells us that a newly created stack is empty A4: tells us that pushing an entity on a stack results in a nonempty stack

34. ??? Are we satisfied with our specification?

35. Preconditions Since ADTs may contain partial functions, preconditions are stated in order to avoid errors. The precondition of an operation is a logical assertion that specifies the assumptions about and the restrictions upon the values of the arguments of the operation. If the precondition of an operation is false, then the operation cannot be safely applied. If any operation is called with its precondition false, then the program is incorrect.

36. Preconditions (con’t) Preconditions pop (s: Stack [Object]) required not empty (s) peak (s: Stack [Object]) required not empty (s)

37. Complete ADT Specification of Stacks Types Stack [Object] Functions push: Stack[Object]  Object pop: Stack[Object]  Object peek: Stack[Object]  Object empty: Stack[Object]  boolean Axioms For any x:Object, s:Stack[Object], A1: peek (push (x) ) = x A2: pop (push (x) ) = s A3: empty (new) A4: not empty (push(s, x)) Preconditions pop (s: Stack [Object]) required not empty (s) peak (s: Stack [Object]) required not empty (s)

38. Implementing an ADT Types, Functions, Axioms, and Preconditions Public Part ADT Specification Secret Part choice of representation implementation of functions Vector public Object pop() { Object x = null; if(! empty()) { x = this.firstElement; this.removeElementAt(0); } else {…} return x; }