conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf

Concepts in Object Oriented
Programming Languages
Dr. P P Das
ppd@interrasystems.com
Interra Systems India Pvt. Ltd.
June 07, 2004

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

Object-oriented Design &
Primary Language Concepts
dynamic lookup
encapsulation
inheritance
sub-typing

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

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

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

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

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

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

Example: Evaluation of a Filter

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

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

Language concepts
 “dynamic lookup”
 different code for different object
 integer “+” different from real “+”
 encapsulation
 sub-typing
 inheritance

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

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

Encapsulation
 Builder of a concept has detailed view
 User of a concept has “abstract” view
 Encapsulation is the mechanism for
separating these two views

Comparison
 Traditional approach to encapsulation is
through abstract data types
 Advantage
 Separate interface from implementation
 Disadvantage
 Not extensible in the way that OOP is

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

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

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

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

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.

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

Inheritance
 Implementation mechanism
 New objects may be defined by reusing
implementations of other objects

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

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

Example: Geometry Library
 Define general concept shape
 Implement two shapes: circle, rectangle
 Functions on implemented shapes
center, move, rotate, print
 Anticipate additions to library

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

Subtype hierarchy
Shape
Circle Rectangle
 General interface defined in the shape class
 Implementations defined in circle, rectangle
 Extend hierarchy with additional shapes

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

Example use: Processing Loop
Loop
{
Remove shape from work queue
Perform action
}
 Control loop does not know the type of each
shape

Sub-typing differs from inheritance
Collection
Indexed Set
Array Dictionary Sorted Set
String
 Sub-typing
 Inheritance

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

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

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

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

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}

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

Programming Languages
– Past, Present & Future
Understanding the Evolution Process

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

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

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

Algol 60
 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

Algol 60
 Discovered Recursive Program Structure.

Lisp (60-65)
 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

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

Pascal (1971-74)
 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

Simula 67
The first Object-Oriented Language!
The “Algol Wall” falls at last!
The “Algol Wall” falls at last!
Well, almost

Simula 67: the language
 Recursive
 Same as others
 Data Structure
 Recursive
 Dynamic
 Classes & Objects
 Classes instantiate objects
 Classes have code and
take parameters
 Inheritance

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]

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

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

Java
 Anonymous Inner Classes
 Have pretty good generics semantics
 Simplifies C++ greatly
The Hero Language?
The Hero Language?

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

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

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

Component Object Model
Object Programming in a Language
Independent Fashion

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

“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.

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).

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.

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.

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.

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.

Summary
 Object-Orientation is a matter of discipline
 Language just works as a vehicle
 OO works at every level of abstraction
 Design
 Source
 Binary

conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf

More Related Content

Similar to conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf

Recently uploaded

conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf