SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Introduction to Object-Oriented Programming Principles and Paradigms

pavel avatar
pavel
26 diapositives · 422 Views · Jul 28, 2014

This introduction explores the fundamental principles of Object-Oriented Programming (OOP), tracing its historical development from the 1960s with Simula to languages like Smalltalk, Java, and C++. Key OOP concepts such as encapsulation, abstraction, inheritance, and polymorphism are defined, highlighting the paradigm's effectiveness in organizing tasks and enhancing code reusability. OOP encourages a natural way to model complex systems with interacting objects, providing a framework that eases problem-solving and boosts programmer productivity.

Introduction to Object-Oriented Programming Principles and Paradigms - slide 1
01 / 26Introduction to Object-Oriented Programming Principles and Paradigms
1 / 17

Télécharger la présentation

Introduction to Object-Oriented Programming Principles and Paradigms
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  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