 2009 Qing Li Introduction to Object Orientation Background: Background:  [behaviorally] object-oriented databases (OODBs) = OO Concepts + Persistency + Transaction support  history & evolution of object orientation: > “Begin … End” blocks in Algol 60 (first attempt at providing encapsulation/protection within a PL) > “Object” in Simula-67 (took the block concept one step further towards data encapsulation) > “Object”, “Class”, “Inheritance” in Smalltalk (further towards data encapsulation & abstraction; ‘70s) > theory of ADT (abstract data type) began to be developed in late ‘70s (eg, Ada)

 2009 Qing Li Introduction to Object Orientation  history & evolution of object orientation (cont’d): > DB languages emerged to support data abstraction & inheritance (eg, Taxis) from semantic modeling > Concepts began to merge towards a unified concept strucutre -- object today! (early ‘80s --> ) E.g., Smalltalk-80, C++, Objective-C, CommonLisp,… Gemstone, Orion, Vbase, Ontos, ObjectStore,... Object Orientation Object Orientation (1) three most fundamental/essential concepts: - abstract data typing (encapsulation) - inheritance - object identity

 2009 Qing Li Introduction to Object Orientation Object Orientation (cont’d) Object Orientation (cont’d) (2) Advantages of object orientation: * better concepts and tools to model and represent the real world as closely as possible (=> model of reality!) * OO languages provide expressive programming and/or manipulation primitives (=> behavior modeling!) * better reusability & extensibility => reduce the time/cost of development * enhanced maintainability & improved reliability (eg, changes can be localized to the implementation of one or more classes) * better performance for complex applications

 2009 Qing Li Introduction to Object Orientation Object Orientation (cont’d) Object Orientation (cont’d) (3) Approaches to OO Programming: a) Novel languages: most radical approach Eg, Smalltalk; Eiffel; Trellis/Owl b) Language Extensions: less controversial approach Eg., C++; Objective-C; Flavors; Object Pascal; … c) Object-oriented style: as an enforced discipline Eg., in C to enforce ADT discipline to simulate other OO features

 2009 Qing Li Introduction to Object Orientation OO Systems vs. Conventional ones OO Systems vs. Conventional ones   In Conventional Languages/Systems: Programs: collections of procedures/subroutines that pass parameters Procedure: manipulate its parameters, possibly return a value => the execution units (procedures) are the central focus!   In OO Systems/Languages: the universe: a collection of independent objects communicating through message-passing objects: the active entities; procedures (messages): passive entities => the data (ie, objects) are the central focus!

 2009 Qing Li Introduction to Object Orientation Features of Object Orientation Features of Object Orientation  Abstract Data Type (ADT) > ADT: defines a set of similar objects with an associated collection of operators > Three criteria for a PL to support ADTs: a) object classes: every datum (object) belongs to an ADT (the object’s class) b) information hiding: - object only accessible through the external interface routines/operations defined by its ADT - its internal implementation details, data structures, and storage elements are not visible outside c) completeness: all required operations are defined. Left to the user!

 2009 Qing Li Introduction to Object Orientation  Abstract Data Type (cont’d)  Object Class: incorporates the definition of the structure as well as the operations of the ADTs Instances: elements pertaining to the collection of objects described by a class Minimally, a class definition should include: a) the name of the class b) the external interface (ie, operations for manipulating its instances; typically have a target object & some arguments) c) the internal representation (ie, instance variables) d) the internal implementation of the interface

 2009 Qing Li Introduction to Object Orientation  Object Class (cont’d) 1) Instance Variables: to capture the internal representation of an object of the class * declaration: Name: string Address: string Revenue: dollar Employees: SetOf Employee Subsidiaries: SetOf Company … Note: there are typeless PLs like Smalltalk, LISP, APL ( where x can be bound to integer 5, and later to a string ‘xy’ within the same session/program). “type constraints” (checked at compile time for typed DB PL)

 2009 Qing Li Introduction to Object Orientation  Object Class 1) Instance Variables (cont’d) * Operator “overloading”: E.g., in PASCAL, “+” can be used for integers as well as for floats! 2) Object Creation: done through invoking a “new” operator on the class E.g. in Eiffel: IBM:= new(Company, “IBM”, “111 success street, New York”) in C++: IBM = new Company (“IBM”, “111 success street, New York”)

 2009 Qing Li Introduction to Object Orientation  Object Class 2) Object Creation (cont’d) Note: instance variables are initialized either at object creation time (via “new”), or subsequently through calling specific operators E.g., Set-Revenues(IBM, $5,000,000,000) … 3) Methods & Messages 3.1) invoking an operation involves: a) the target object b) the name of the operator c) the argument of the operation d) calling the code that implement the operator, binding the parameters to the actual arguments

 2009 Qing Li Introduction to Object Orientation  Object Class 3) Methods & Messages (cont’d) E.g., in Smalltalk, a message looks like below: GM(AddSubsidiary: Hughes) in C++: GM.AddSubsidiary(Hughes) in Eiffel: AddSubsidiary(GM, Hughes)  very similar to invoke procedures! (Difference: binding is done at run time, depending on the class of the target object!! ) A message (to GM): (i) a selector (ii) one/more arguments The selector (name of a “method”) AddSubsidiary(C: Company, NewSubsj: Company) C.Subsidiary[TotalSubsj]:= NewSubsi TotalSubsi := TotalSubsi + 1

 2009 Qing Li Introduction to Object Orientation  Object Class 3) Methods & Messages (cont’d) On Dynamic Binding (“late binding”): the system will bind at run-time a selector to the particular method (procedure) that implement it, based on the recipient object’s class. Motivations: 1) the same message or method name could be used by different classes (overloading!) 2) a variable’s object class might not be known till runtime (eg, in typeless languages) Advantages: flexibility & extensibility (the cost is the performance penalty!)

 2009 Qing Li Introduction to Object Orientation  Object Class 3) Methods & Messages (cont’d) On Dynamic Binding (“late binding”): E.g., there is a stack of heterogeneous objects, and we want to print every entry in the stack in OOPL in conventional PLs: for i:= 1 to Top for i:= 1 to Top do do Print(Stack[i]) case Stack[i].type integer: PrintInteger( Stack[i].object) float: PrintFloat( Stack[i].object) string: … Boolean: … If a new type X is added, then the OOPL system can be extended without affecting the code, whereas the other would need to add PrintX and recompile the while thing!

 2009 Qing Li Introduction to Object Orientation  Object Class (cont’d) 4) Constraints to help enforce correctness/completeness of ADT Two approaches: a) Constraints on objects and their instance variables E.g., Student.age > 15 b) Pre- and Post-conditions of methods (as supported in, eg., Eiffle)

 2009 Qing Li Introduction to Object Orientation  Inheritance Hierarchy  the 2nd powerful concept of OOPL and systems  similar concept found in semantic networks (Minsky’68) and semantic data models  useful in organizing/structuring information, and facilitating reusablity (rather than designing everything from scratch) E.g. Company Commercial Company Non-profit Organization superclass subclass

 2009 Qing Li Introduction to Object Orientation  Inheritance Hierarchy (cont’d)  subclass and superclass relations are “transitive”  there is the notion of inheritance applicable  two main aspects of inheritance: 1) structural (instance variables) 2) behavioral (methods) 1) Inheriting Instance Variables - common in AI (KR) and semantic data models - subclsses “inherit” their superclass’ instance variables - different ways to achieve the goal of inheritance:

 2009 Qing Li Introduction to Object Orientation 1) Inheriting Instance Variables (cont’d) * in Smalltalk: visible directly & completely! Problem: violates both uniformity & encapsulation (eg, suppose A changes its “Subsidiaries” from an array to a list of company, then B’s evaluate-profit method has to be modified!) A B

 2009 Qing Li Introduction to Object Orientation 1) Inheriting Instance Variables (cont’d) * in CommonObjects & Encore: invisible completely! * more general approach: (eg, in C++, Trellis/Owl) - Public (any client can access) - Private (no client can access) - protected (subclass’ clients can access) A B Instance variables in the hierarchy are independent from each other

 2009 Qing Li Introduction to Object Orientation 2) Inheriting Methods - unique to OO languages and systems - methods defined for a class are inherited by its subclasses E.g. Window Bordered Window Text Window move-window() resize-window() retate-window() edit-font() reset-size() edit-font() edit-size()

 2009 Qing Li Introduction to Object Orientation 2) Inheriting Methods (cont’d) - a subclass can “over-ride” an inherited method E.g. Where: Evaluate-profit(FC: ForeignCommercial) return (CommercialCompany.evaluate-profit(FC)- ForeignTax(FC)) Commercial Company Foreign Commercial evaluate-profit()

 2009 Qing Li Introduction to Object Orientation 2) Inheriting Methods (cont’d) - multiple inheritance: combine several classes to produce “conglomerate classes” E.g. Person EmployeeStudent StudentWorkerManager

 2009 Qing Li Introduction to Object Orientation 2) Inheriting Methods - multiple inheritance (cont’d): Suppose Employee : {name, age, salary, rank, dept} Student : {name, age, GPA, program, advisor} then StudentWorker: {name, age, salary, rank, dept, GPA, program, advisor} What happen when there is a “conflict” (ie, different methods/instance variables have the same name)? Eg., assume both student & employee had a method called “bonus” (with totally different semantics), which bonus method should apply to StudentWorker?

 2009 Qing Li Introduction to Object Orientation Meta Classes - Are classes instances of other classes? - If Yes, what is the class describing them, and where does the transitive closure end? E.g., in Smalltalk: * classes are instances of their metaclasses which are created by the system (the user distinguishes between class methods/attributes from instance methods/attributes) * all metaclasses are instances of METACLASS; * METACLASS is an instance of CLASS which is an instance of OBJECT ( the root!)

 2009 Qing Li Introduction to Object Orientation  Object Identity  the 3rd powerful concept of OO systems Definition: an identity is a handle which distinguishes one object (entity) from another  the idea: within a complete OO system, each object will be given an identity (Oid) permanently, immaterial of the object’s structural or state transitions  necessity: without Oids, it is a) awkward (if not impossible) to assign self- contained objects to instance variables b) impossible to make the same object a component of multiple objects

 2009 Qing Li Introduction to Object Orientation  Object Identity (cont’d)  Conventional programming language’s way: - use variable names to distinguish objects  mixes addressability and identity! - practical limitations: no way to test if x and y refer to the same object (ie, x==y), as opposed to x=y (assignment). Supported in Smalltalk External to object (a way to access; typically through pointers or virtual addresses) Internal to object (to represent the individuality; should be independent of how it is accessed!)

 2009 Qing Li Introduction to Object Orientation  Object Identity (cont’d)  Conventional DB Approach: - uses record keys to distinguish objects  confuses identity and data values (obj. state)! - practical problems: a) modifying key attributes? b) non-uniformity: Eg, Compaq uses emp# as key attribute IBM uses ss# as key attribute a merge of Compaq and IBM  one of these keys to change!

 2009 Qing Li Introduction to Object Orientation  Object Identity  Conventional DB Approach (cont’d) c) unnatural join: Eg, Employee Company EmpName ss# salary CompName Name Budget Location Query: “find for all employees the Employee name and the location that employee works in”. In SQL: SELECT Employee.EmpName, Company.Location FROM Employee, Company WHERE Employee.CompName = Company.Name; But if two companies have the same name?

 2009 Qing Li Introduction to Object Orientation  Conventional DB Approach c) unnatural join (cont’d) (in most cases, what the user wants is the actual company object (tuple), instead of the CompName!) Part of the reason: due to normalization which loses the semantic connections amongst the objects  relational systems have to use additional facilities such as foreign key constraints to recapture the lost semantics!! What about relax the normalization constraints?  nested relations (or, Non-1NF relations) allowed, so as to support a more direct & intuitive representation

 2009 Qing Li Introduction to Object Orientation But, non-1NF models only provide a partial solution… E.g. Person Name age address spouse Education Degree Univ. Year John parker st. Mary MSc MIT 1981 PhD CMU 1986 Mary parker st. John BBA USC 1985 MBA USC 1987 Children Parent Child Cage John Tim 5 Mary Tim 5 John Jane 3 Mary Jane 3 Note: children still need to be represented separately, since each child pertains to both parents

 2009 Qing Li Introduction to Object Orientation What’s missing? the ability to share objects (to refer to objects directly and completely) Answer: Oid ! * preserve identity throughout object evolution: evolve - strong support of identity is important for temporal data models (where objects can evolve!) - Oid can serve as the common thread that ties together the historial versions of an object Some Oid operations: - merge / coerce - copy: shallow vs. deep