Concepts In Object Oriented Programming Languages

Concepts in Object Oriented Programming Languages Dr. P P Das [email_address] 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

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

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

Algol 60 Discovered Recursive Program Structure.

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

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

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

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

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?

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

Concepts In Object Oriented Programming Languages

Recommended

More Related Content

What's hot (20)

Viewers also liked (11)

Similar to Concepts In Object Oriented Programming Languages (20)

More from ppd1961 (20)

Concepts In Object Oriented Programming Languages

Editor's Notes