Introduction to Object-oriented Programming

1. Introduction to Object-oriented Programming CMPS 2143

2. Objectives • Investigate and explain basic principles of OOP • Look at a little theory and history

3. History • OOP and Simula developed in 1960s (Norway) • Alan Kay in 1970s developed Smalltalk • Caught on in 1980s • Seminal paper in Byte in 1981 on Smalltalk • Extension to C at Bell Labs in 1982 • 1st OOP conference in Oregon in 1986 • Objective-C (1986), Actor (1987), Eiffel (1988), Object Pascal, Lisp dialects • Java 1991 and C++ in 1994

4. Why is OOP Popular? • OO solutions scale well • Supports abstraction  understanding • Libraries  reusability

5. Language and Thought • Linguistic theory states: structure of language defines boundaries of thought ?TRUE? • Language can facilitate or impede certain modes of thought • A given programming language can influence class of solutions • Example: DNA sequence analysis in Fortran vs APL

6. Church and Whorf’s conjectures • Several programming paradigms/language formalisms • Church, Post, Markov, Turing, Kleene, etc. • Church: In a fundamental way all programming languages are identical • Sapir-Whorf: It is possible to have ideas that can be expressed in one language that cannot be expressed in another • OO techniques do not provide any new computational power, but do make it easier to address certain problems

7. The OOP Paradigm • Programming paradigm – a way of conceptualizing how to perform a computation and how tasks are structured and organized • The OO Paradigm not new – Biologist Linnaeus categorized biological organisms using ideas of phylum, genus, species, etc. • Easy for novice programmers to grasp ideas of OOP • Natural view of world

8. OOP in a Nutshell • A program models a world of interacting objects. • Each objecthas a role to play and provides a service or performs an action for other members in world

9. Example

10. OOP in a Nutshell • Objects create other objects and “send messages” to each other (ie, call each other’s methods). • Calling object need not know actual means of how request will be honored • Each object is an instanceof a class; a class defines propertiesof its objects and their responsibilities. • The data type of an object is its class.

11. Another view of OOP • Review the main OOP concepts: • encapsulation • abstraction • inheritance • polymorphism

12. Encapsulation and Instantiation Classes provide two very important capabilities: • Encapsulation - The purposeful hiding of information, thereby reducing the amount of details that need to be remembered/communicated among programmers. • Instantiation - The ability to create multiple instances of an abstraction.

13. Encapsulation: SeparatingInternal and External Views

14. Responsibility & Abstraction • Discussing a problem in terms of responsibilities increases the level of abstraction and permits greater independence between agents • This is a standard powerful form of abstraction sometimes called information hiding

15. Another view of OOP • Review the main OOP concepts: • abstraction • encapsulation • inheritance • polymorphism

16. Inheritance • Inheritance implements the “is a” relationship. • Not to be confused with embedding (an object has another object as a part), which represents the “has a” relationship: A sailboat is a boat A sailboat has asail

17. Inheritance • A class can extend another class, inheriting all its data members and methods while redefining some of them and/or adding its own. • A class can implement an interface, implementing all the specified methods.

18. Inheritance (cont’d) • In C++ and Java, a subclass can extend only one superclass. • In Java, a subinterfacecan extend one superinterface • In Java, a class can implement several interfaces — this is Java’s form of multiple inheritance.

19. Class Hierarchies • Inheritance leads to a hierarchy of classes and/or interfaces in an application:

20. Class Hierarchies cont. • Example from Swing: JComponent ... ... ... JTextComponent JTextField JTextArea JEditorPane JPasswordField JTextPane

21. Another view of OOP • Review the main OOP concepts: • abstraction • encapsulation • inheritance • polymorphism

22. Method Binding and Polymorphism • When Fred asks his wife Beth to send some flowers to Robin for her birthday she might use a different method than the florist Fred • The method that gets executed in response to a message depends on the receiver of the message. • Different methods that can execute in response to the same message is a form of polymorphism

23. Sending Messages vs. Procedure Call • A message has a designated receiver (some object) • The interpretation of the message is determined by the receiver and can vary amongst different receivers. • Often the actual receiver of a message is not known until run-time. There is late or dynamic binding between the message and the code fragment (method) used to respond to the message

24. F Functions are not Methods Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions

25. Abstraction mechanisms in programming languages • Procedures and Functions (function centered view) + information hiding for the detail of the behavior - no information hiding for the detail of the data - no encapsulation • Modules and Packages (data centered view) + information hiding + encapsulation - instantiation not always supported • Abstract Data Types + separates interface and implementation

26. References • Budd Book