ICS 121: Object-orientation

Object-orientation is an approach to analysis, design, and implementation where the system is viewed as a set of communicating objects.
History:
- Simula (1960's): Simulation of physical objects.
- Smalltalk (1970s): Tried to make programming easier for average people, invented at Xerox PARC along with modern GUIs and many other concepts.
- C++, Eiffel (1980s): Tried to make object-orientation more applicable to more systems: more like C and Pascal, more efficient, more scalable
- Java, UML (1990s): Java selects the best C++ ideas and makes them simpler; UML is a standard object-oriented analysis and design notation.
- Controls (1990s): VisualBasic controls are objects with a UI.
- Future: objects inside web services. WS = classes running on a web server.
Core ideas of object-orientation:
- Homomorphism: Many objects correspond to real-world objects and concepts.
- Encapsulation: Each object exposes only public operations and encapsulates its state and algorithms
- Classification: Classes define types of objects. Instances are created at run-time.
- Inheritance: Classes exist in an inheritance hierarchy
- Polymorphism: Objects refer to other objects based on class, but instances of subclasses may be used
- Dynamic binding: Different classes may implement the same operation with different methods, and the correct method body will be executed at run-time

Programs were viewed as big algorithms with data flowing from statement to statement. Whereas now, we see programs more as big representations of data with little algorithms inside each object.
Source code was organized into modules. Now, module = class, also packages or name-spaces provide additional structure.
Much of program logic was "case analysis". Now, the OO language compilers and run-time systems use inheritance, polymorphism, and dynamic binding to provide much of that logic automatically.
Reusable code was viewed as libraries of functions, e.g., a math or string library. Now, reusable code may be part of a framework that other developers can use directly or extend with subclasses.

The term "Object" is often used too loosely. An object is an instance of a class, not a class itself.
An instance is a set of values in memory. Each instance belongs to a given class.
Each class has a set of attribute definitions that form a template for creating new instances. Each class has a set of operations. (Classes may also have "static" elements.)
Instances can update their own attribute values, and they may send messages to other instances (or call static methods)
Usually messages are the same as procedure calls, but they could be asynchronous in some languages.

Abstract classes are classes that are only intended to be subclassed, not to be used directly to create instances.
Abstract classes provide attributes and operations that can be reused by multiple subclasses.
Abstract classes may also declare abstract operations that have no implementation. Subclasses of the abstract class provide the implementation.
A class that is not abstract is called concrete, meaning that it has code to implement all operations.
An interface is like an abstract class that consists solely of abstract operations, with no implementation code or attributes.
Abstract class and interface are useful because they allow other code to make limited assumptions about the class of an instance. E.g., the TELE system could ask an Instructor to enter a grade, it does not need to handle Professor and Lecture as separate cases. A new concrete subclass, Mentor, could be added to the system without the need to update other code.
Java allows single-inheritance plus the implementation of zero or more interfaces.

Multiple inheritance allows one class to have several superclasses at the same time.
The new class inherits all attributes and operations from all superclasses. This can sometimes lead to conflicts.
E.g., a ToyTruck is a subclass of Toy and a subclass of Truck. It is plastic because all toys are plastic. It has wheels because all trucks have wheels. But, is it powered by diesel fuel or AA batteries?
Java avoids multiple inheritance to keep the language simple. UML and C++ allow it. If you want the effect of multiple inheritance, you can do it with multiple interfaces and some cut-and-pasted code.

Each variable has a value. The variable has a declared type, e.g., Shape. The value of that variable has its own dynamic type, e.g., Circle. The dynamic type may be a subclass of the declared type.
Each class may provide its own implementation of operations. E.g., a Circle is drawn differently than a Square.
At runtime, a message draw(Window w) may be sent to a variable with declared type Shape. That message will be bound to Circle.draw() or Square.draw() depending on the class of the instance in that variable value.
Polymorphism and dynamic binding can eliminate much of the "case analysis" logic in programming. In general, if you find yourself writing code that tries to detect the class of some object and uses that information in an if-statement or case-statement, it would be better to use subclasses.