Concepts In Object Oriented Programming Languages

  • 2,454 views
Uploaded on

An overview lecture on OOP - presented at Department of Computer Science and Technology, BESU in 2004

An overview lecture on OOP - presented at Department of Computer Science and Technology, BESU in 2004

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,454
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
109
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Lecture at BE College
  • We will look at ADT’s example to see what the problem is

Transcript

  • 1. Concepts in Object Oriented Programming Languages Dr. P P Das [email_address] Interra Systems India Pvt. Ltd. June 07, 2004
  • 2. Outline of lecture
    • Object-oriented Design & Primary Language Concepts
      • dynamic lookup
      • encapsulation
      • inheritance
      • sub-typing
    • Programming Languages – Past, Present & Future
      • Understanding the Evolution Process
    • Component Object Model
      • Object Programming in a Language Independent Fashion
  • 3. Object-oriented Design & Primary Language Concepts
      • dynamic lookup
      • encapsulation
      • inheritance
      • sub-typing
  • 4. Objects
    • An object consists of
      • hidden data
        • instance variables, also called member data
        • hidden functions also possible
      • public operations
        • methods or member functions
        • can also have public variables in some languages
    • Object-oriented program:
      • Send messages to objects
  • 5. What’s interesting about this?
    • Universal encapsulation construct
      • Data structure
      • File system
      • Database
      • Window
      • Integer
    • Metaphor usefully ambiguous
      • sequential or concurrent computation
      • distributed, synchronous or asynchronous communication
  • 6. Object-Oriented Programming
    • Programming methodology
      • organize concepts into objects and classes
      • build extensible systems
    • Language concepts
      • encapsulate data and functions into objects
      • Sub-typing allows extensions of data types
      • inheritance allows reuse of implementation
  • 7. Object-Oriented Method
    • Four steps
      • Identify the objects at a given level of abstraction
      • Identify the semantics (intended behavior) of objects
      • Identify the relationships among the objects
      • Implement these objects
    • Iterative process
      • Implement objects by repeating these steps
    • Not necessarily top-down
      • “ Level of abstraction” could start anywhere
    Booch
  • 8. This Method
    • Based on associating objects with components or concepts in a system
    • Why iterative?
      • An object is typically implemented using a number of constituent objects
      • Apply same methodology to subsystems, underlying concepts
  • 9. Example: Compute Weight of Car
    • Car object:
      • Contains list of main parts (each an object)
        • chassis, body, engine, drive train, wheel assemblies
      • Method to compute weight
        • sum the weights to compute total
    • Part objects:
      • Each may have list of main sub-parts
      • Each must have method to compute weight
    • Example: Compute Weight of Car
  • 10. Example: Evaluation of a Filter
  • 11. Comparison to top-down design
    • Similarity:
      • A task is typically accomplished by completing a number of finer-grained sub-tasks
    • Differences:
      • Focus of top-down design is on program structure
      • OO methods are based on modeling ideas
      • Combining functions and data into objects makes data refinement more natural
  • 12. Object-Orientation
    • Programming methodology
      • organize concepts into objects and classes
      • build extensible systems
    • Language concepts
      • dynamic lookup
      • encapsulation
      • sub-typing allows extensions of concepts
      • inheritance allows reuse of implementation
  • 13. Language concepts
    • “ dynamic lookup”
      • different code for different object
      • integer “+” different from real “+”
    • encapsulation
    • sub-typing
    • inheritance
  • 14. Dynamic Lookup
    • In object-oriented programming,
      • object  message (arguments)
      • code depends on object and message
    • In conventional programming,
      • operation (operands)
      • meaning of operation is always the same
  • 15. Example
    • Add two numbers
        • x  add(y)
      • different add if x is integer, complex
    • Conventional programming add(x, y)
      • function add has fixed meaning
    • Very important distinction:
      • Overloading is resolved at compile time,
      • Dynamic lookup at run time
  • 16. Language concepts
    • “dynamic lookup”
      • different code for different object
      • integer “+” different from real “+”
    • encapsulation
    • sub-typing
    • inheritance
  • 17. Encapsulation
    • Builder of a concept has detailed view
    • User of a concept has “abstract” view
    • Encapsulation is the mechanism for separating these two views
  • 18. Comparison
    • Traditional approach to encapsulation is through abstract data types
    • Advantage
      • Separate interface from implementation
    • Disadvantage
      • Not extensible in the way that OOP is
  • 19. Abstract Data Types
    • abstype q
      • with
        • mk_Queue : unit -> q
        • is_empty : q -> bool
        • insert : q * elem -> q
        • remove : q -> elem
      • is …
      • in
        • program
      • end
  • 20. Priority Q, similar to Queue
    • abstype pq
      • with
        • mk_Queue : unit -> pq
        • is_empty : pq -> bool
        • insert : pq * elem -> pq
        • remove : pq -> elem
      • is …
      • in
        • program
      • end
    • But cannot intermix pq’s and q’s
  • 21. Abstract Data Types
    • Guarantee invariants of data structure
      • only functions of the data type have access to the internal representation of data
    • Limited “reuse”
      • Cannot apply queue code to pqueue, except by explicit parameterization, even though signatures identical
      • Cannot form list of points, colored points
    • Data abstraction is important part of OOP, innovation is that it occurs in an extensible form
  • 22. Language concepts
    • “dynamic lookup”
      • different code for different object
      • integer “+” different from real “+”
    • encapsulation
    • sub-typing
    • inheritance
  • 23. Sub-typing and Inheritance
    • Interface
      • The external view of an object
    • Sub-typing
      • Relation between interfaces
    • Implementation
      • The internal representation of an object
    • Inheritance
      • Relation between implementations
  • 24. Object Interfaces
    • Interface
      • The messages understood by an object
    • Example: point
      • x-coord : returns x-coordinate of a point
      • y -coord : returns y -coordinate of a point
      • move : method for changing location
    • The interface of an object is its type.
  • 25. Sub-typing
    • If interface A contains all of interface B, then A objects can also be used B objects.
    • Colored_point interface contains Point
      • Colored_point is a subtype of Point
    change_color color move move y -coord y -coord x-coord x-coord Colored_point Point
  • 26. Inheritance
    • Implementation mechanism
    • New objects may be defined by reusing implementations of other objects
  • 27. Example
    • class Point
      • private
        • float x, y
      • public
        • point move (float dx, float dy);
    • class Colored_point
      • private
        • float x, y; color c
      • public
        • point move(float dx, float dy);
        • point change_color(color newc);
    • Sub-typing
      • Colored points can be used in place of points
      • Property used by client program
    • Inheritance
      • Colored points can be implemented by reusing point implementation
      • Property used by implementer of classes
  • 28. OO Program Structure
    • Group data and functions
    • Class
      • Defines behavior of all objects that are instances of the class
    • Sub-typing
      • Place similar data in related classes
    • Inheritance
      • Avoid re-implementing functions that are already defined
  • 29. Example: Geometry Library
    • Define general concept shape
    • Implement two shapes: circle, rectangle
    • Functions on implemented shapes
        • center, move, rotate, print
    • Anticipate additions to library
  • 30. Shapes
    • Interface of every shape must include
        • center, move, rotate, print
    • Different kinds of shapes are implemented differently
      • Square: four points, representing corners
      • Circle: center point and radius
  • 31. Subtype hierarchy
    • Shape
    • Circle Rectangle
    • General interface defined in the shape class
    • Implementations defined in circle, rectangle
    • Extend hierarchy with additional shapes
  • 32. Code placed in classes
    • Dynamic lookup
      • circle  move(x,y) calls function c_move
    • Conventional organization
      • Place c_move, r_move in move function
    r_center r_move r_rotate r_print Rectangle c_center c_move c_rotate c_print Circle center move rotate print
  • 33. Example use: Processing Loop
    • Loop
    • {
      • Remove shape from work queue
      • Perform action
    • }
    • Control loop does not know the type of each shape
  • 34. Sub-typing differs from inheritance
    • Collection
    • Indexed Set
    • Array Dictionary Sorted Set
    • String
    • Sub-typing
    • Inheritance
  • 35. Design Patterns
    • Classes and objects are useful organizing concepts
    • Culture of design patterns has developed around object-oriented programming
      • Shows value of OOP for program organization and problem solving
  • 36. What is a design pattern?
    • General solution that has developed from repeatedly addressing similar problems.
    • Example: singleton
      • Restrict programs so that only one instance of a class can be created
      • Singleton design pattern provides standard solution
    • Not a class template
      • Using most patterns will require some thought
      • Pattern is meant to capture experience in useful form
    • Standard reference: Gamma, Helm, Johnson, Vlissides
  • 37. OOP in Conventional Language
    • Records provide “dynamic lookup”
    • Scoping provides another form of encapsulation
      • Try object-oriented programming in ML. Will it work?
      • Let’s see what’s fundamental to OOP
  • 38. Dynamic Lookup (again)
        • receiver  operation (arguments)
    • code depends on receiver and operation
    • This is may be achieved in conventional languages using record with function components
  • 39. Stacks as closures
    • fun create_stack(x) =
      • let val store = ref [x] in
        • {push = fn (y) =>
          • store := y::(!store),
        • pop = fn () =>
          • case !store of
            • nil => raise Empty |
            • y::m => (store := m; y)
        • } end;
    • val stk = create_stack(1);
      • stk = {pop=fn,push=fn} : {pop:unit -> int, push:int -> unit}
  • 40. Does this work ???
    • Depends on what you mean by “work”
    • Provides
      • encapsulation of private data
      • dynamic lookup
    • But
      • cannot substitute extended stacks for stacks
      • only weak form of inheritance
        • can add new operations to stack
        • not mutually recursive with old operations
  • 41. Programming Languages – Past, Present & Future Understanding the Evolution Process
  • 42. Connection between Functional & OO
    • λ -Calculus
    • Functional Programming
      • Impractical
      • Strong Mathematical Properties
    • Turing Machine
    • Procedural
      • Practical
      • Little Math Grounding
    • Object-Oriented
      • Very Practical (fixes problems)
      • No Math Basis/ Chaos Theory
    Future of OO – What we want to see
  • 43. Fortran (1957-66)
    • Program Structure
      • Flat
        • No recursion
        • No nested scopes
          • No statement grouping
        • No control structures
          • goto & computed goto
          • if (like computed goto)
          • do (based around labels)
      • Static
    • Data Structure
      • Flat
        • Arrays
        • Later strings
        • Only locals & globals
      • Static
        • No dynamic allocation
        • All locations picked at compile time
  • 44. Fortran: Abstractions?
    • Functions/Procedures
    • Absolutely no layered abstraction
      • Layered Abstraction: “first understand in general or in the abstract what’s going on; then worry about the details.” Apply recursively for best effect
    • At Least it’s consistent
    • Achieved its goal to replace assembly
    • Got people to actually use programming languages
  • 45. Algol 60
    • Program Structure
      • Recursive
        • Nested scopes
        • Modules
        • Recursive function calls
        • Full set of control structures
      • Static
    • Data Structure
      • Flat
        • Arrays
        • No records
      • Dynamic
        • Dynamically sized arrays
    “ Algol Wall ” Data and program structure are separate worlds
  • 46. Algol 60
    • Discovered Recursive Program Structure.
  • 47. Lisp (60-65)
    • Program Structure
      • Recursive
        • Structure
        • Calls
      • Static
        • Functions still aren’t first class values
      • Dynamic Binding
        • variables are bound within the calling environment
    • Data Structure
      • Recursive
        • Atoms
        • Lists
      • Heterogeneous Lists
      • Dynamic
        • Garbage collection
      • No records
  • 48. PL/I (1964) and Algol 68
    • PL/I for example:
      • DECLARE FOOBAR DECIMAL FIXED REAL (8,3) STATIC EXTERNAL
    • Algol 68:
      • Allows anything, for example:
        • this is an acceptable name for a variable of type integer
      • Operator overloading, unions, pointers to anything, Call-by-reference
      • Everything is first class and transparent, including procedures
      • Yet: procedures are objects while structs “extend the language”, structures are based on arrays and one has data and programs and never shall the twain meet
  • 49. Pascal (1971-74)
    • Program Structure
      • Partially recursive
        • Procedures with recursive calls
        • No true blocks, only compound statements
      • Static
    • Data Structure
      • Flat
      • Records
        • Dynamic
        • Record types extend type system
        • Based on arrays
      • Strongly typed
    Most importantly its simple! Temporarily reversed the trend
  • 50. Simula 67
    • The first Object-Oriented Language!
    • The “Algol Wall” falls at last!
    • Well, almost
  • 51. Simula 67: the language
    • Program Structure
      • Recursive
      • Same as others
    • Data Structure
      • Recursive
      • Dynamic
      • Classes & Objects
        • Classes instantiate objects
        • Classes have code and take parameters
        • Inheritance
  • 52. Smalltalk (1972-76)
    • No primitives
    • Classes are objects
    • Even blocks are objects
    • Dynamically typed
    • Extremely uniform
    • Despite all this, it never was quite “it”
    • Syntax is nearly unreadable, example:
      • Given a “Point” class the plus method might be:
        • +pt [ Point new x: x+pt x y: y+pt y]
  • 53. Ada (mid 1970s)
    • A complicated language designed for the DOD
    • Based on Pascal
    • Many different forms of packaging and data type declarations
    • Strong typing with the flexibility of making new types
    • Security was important (unlike Smalltalk and Scheme)
    • No quite Object-Oriented
  • 54. C, C++ and Eiffel
    • C gave us
      • { } for blocks and lots of other nice syntax
    • C++ made
      • OO and exceptions mainstream
      • Const allows expression of invariance
    • Eiffel is in the Pascal family
      • It is a well thought out OO language
      • Gave us the concept of whole program optimization
      • Hopefully the last of the Pascal line
  • 55. Java
    • Anonymous Inner Classes
    • Have pretty good generics semantics
    • Simplifies C++ greatly
    The Hero Language?
  • 56. Prototype Based OO Languages Self etc.
    • No classes, only objects
    • New objects are made by cloning others
    • A “class” is just an object you use as a template
    • Can directly write objects and often add methods/properties on the fly
    • May be strongly or weakly typed
  • 57. BETA
    • Everything is a “pattern”
    • Patterns make up classes and methods
    • There is no direct representation of an object
    • Very similar to functional languages like Scheme
    • Strongly typed
  • 58. The Future?
    • Patterns are first class entities representing classes and methods
    • Direct object representations allow inner objects and modules
    • Ways to express invariance
    • Anonymous patterns and objects
    • Integration of Generics into the polymorphism system
  • 59. Component Object Model Object Programming in a Language Independent Fashion
  • 60. The Component Object Model
    • COM is:
      • Platform-independent,
      • Distributed,
      • Object-oriented,
      • System for creating binary software components that can interact.
    • Foundation technology for:
      • Microsoft's OLE (compound documents),
      • ActiveX (internet enabled components),
      • Automation
      • Others.
  • 61. What COM is NOT?
    • It is NOT an object-oriented language,
    • It is NOT a coding or s/w Architecture Standard.
    • It DOES NOT bind the Language, structure, and implementation details.
    • It is NOT Language-specific
  • 62. What COM is?
    • It is a Binary standard applicable after a program has been translated to binary machine code
    • It is an object model and programming requirements that enable COM objects to interact with other objects.
    • COM objects can be within a single process, in other processes, even on remote machines.
    • COM objects may be written in different languages, and may be structurally quite dissimilar.
  • 63. Language Requirement for COM
    • The language that can create
      • Structures of pointers and,
      • Call functions through pointers (either explicitly or implicitly)
    • Object-oriented languages simplify the implementation of COM objects
      • C++, Smalltalk and Java
    • But other languages can be used:
      • C, Pascal, Ada, and even BASIC programming environments can create and use COM objects.
  • 64. Nature of a COM
    • A software object is made up of :
      • A set of data and
      • The functions that manipulate the data.
    • In a COM object the access to the object’s data is achieved exclusively through one or more sets of related functions.
      • These function sets are called interfaces , and
      • The functions of an interface are called methods.
    • The only way to gain access to the methods of an interface is through a pointer to the interface.
  • 65. Universal Interfaces
    • COM defines:
      • Basic interfaces that provide functions common to all COM-based technologies,
      • A small number of API functions that all components require,
      • How objects work together over a distributed environment, and
      • Security features to ensure system and component integrity.
  • 66. COM Objects and Interfaces
    • Allows objects to interact across process and machine boundaries (as objects within a single process interact.
    • The only way to manipulate the data associated with an object is through “an interface on the object”.
    • “ An object that implements an interface” means that the object uses code that implements each method of the interface and provides COM binary-compliant pointers to those functions to the COM library.
    • COM makes those functions available to any client who asks for a pointer to the interface, whether the client is inside or outside of the process that implements those functions.
  • 67. Interfaces & Interface Implementations
    • COM makes a fundamental distinction between:
      • Interface Definitions and
      • Interface Implementations.
    • An interface is actually a contract that consists of a group of related function prototypes whose usage is defined but whose implementation is not.
    • An interface implementation is the code a programmer supplies to carry out the actions specified in an interface definition.
  • 68. Interfaces
    • An interface is a contract consisting of a group of related function prototypes whose usage is defined but whose implementation is not.
      • The function prototypes are equivalent to pure virtual base classes in C++ programming.
      • An interface definition specifies the interface’s member functions, called methods, their return types, the number and types of their parameters, and what they must do.
      • There is no implementation associated with an interface.
  • 69. Interface Implementations
    • An interface implementation is the code a programmer supplies to carry out the actions specified in an interface definition.
      • Implementations of many of the interfaces a programmer could use in an object-based application are included in the COM libraries.
      • Programmers are free to ignore these implementations and write their own.
      • An interface implementation is to be associated with an object when an instance of that object is created, and provides the services that the object offers.
  • 70. IStack
    • A hypothetical interface named IStack
    • Two methods – Push and Pop ,
    • successive calls to the Pop method return, in reverse order, values previously passed to the Push method.
    • This interface definition, however, would not specify how the functions are to be implemented in code.
    • In implementing the interface, however, one programmer might implement the stack as an array and implement the Push and Pop methods in such a way as to access that array; while another programmer might prefer to use a linked list and would implement the methods accordingly.
    • Regardless of a particular implementation of the Push and Pop methods, however, the in-memory representation of a pointer to an IStack interface, and therefore its use by a client, is completely defined by the interface definition.
  • 71. “ Interface” Connotations
    • A C++ interface refers to all of the functions that a class supports and that clients of an object can call to interact with it.
    • A COM interface refers to a predefined group of related functions that a COM class implements, but does not necessarily represent all the functions that the class supports.
    • Java defines “interfaces” in just the same way as COM.
  • 72. Universally Unique Identifier (GUID)
      • A 128-bit value that uniquely identifies objects:
      • OLE servers
      • Interfaces
      • Manager entry-point vectors, and
      • Client objects
      • Universally unique identifiers are used in cross-process communication, such as remote procedure calling (RPC) and OLE.
      • Also called Globally Unique Identifier (GUID).
  • 73. How an Interface Works?
    • An instantiation of an interface implementation (the defined interfaces themselves cannot be instantiated without implementation) is simply pointer to an array of pointers to functions.
    • Any code that has access to that array – a pointer through which it can access the array – can call the functions in that interface.
    • A pointer to an interface is actually a pointer to a pointer to the table of function pointers. The term interface pointer is used to refer to this multiple indirection.
  • 74. How an Interface Works?
    • Conceptually, then, an interface pointer can be viewed simply as a pointer to a function table in which you can call those functions by de-referencing them by means of the interface pointer.
  • 75. IUnknown & Interface Inheritance
    • Inheritance in COM does not mean code reuse.
    • W/o any implementations with interfaces, interface inheritance !  code inheritance.
    • By inheritance, the contract associated with an interface is inherited in a C++ pure-virtual base-class fashion and modified
      • by adding new methods or
      • by further qualifying the allowed usage of methods.
    • There is no selective inheritance in COM. If one interface inherits from another, it includes all the methods that the other interface defines.
  • 76. Interface Inheritance
    • Inheritance is rare (but found) in predefined COM interfaces.
    • All interfaces (predefined / custom) must inherit their definitions from IUnknown containing:
      • QueryInterface – allows to move freely between the different interfaces that an object supports
      • AddRef – to manage object lifetime (Birth)
      • Release – to manage object lifetime (Death)
    • All COM objects must implement the IUnknown interface.
  • 77. Examples
  • 78. Summary
    • Object-Orientation is a matter of discipline
      • Language just works as a vehicle
    • OO works at every level of abstraction
      • Design
      • Source
      • Binary