1. Design Issues for Object Oriented Languages
1.1. Exclusivity of Objects
1.1.1. In the purest model of object oriented programming, all types are classes. There is no distinction between predefined and user defined classes. All classes are treated the same way and all computation is accomplished through message passing.
1.1.2. One alternative to the exclusive use of objects that is common when in imperative languages to which support for object oriented programming has been added is to retain the complete collection of types from the base imperative languages and add the object typing model.
1.1.3. Another alternative is to have an imperative style type structure for primitive scalar types, but implement everything else as objects.
1.2. Are Subclasses Subtypes?
1.2.1. Principle of Substitution - When a variable of a class can be substituted for a variable of one of its ancestor classes in any situation without causing type errors and without changing the behavior of the program. When this is true, a subclass can be called a subtype.
1.2.2. To allow this, a parent class cannot have entities that aren't visible to its subclasses.
1.3. Single and Multiple Inheritance
1.3.1. While multiple inheritance is very useful, there are two issues with implementing it.: complexity and efficiency.
1.3.2. Complexity - What if a subclass inherits from two unrelated parent classes, a method with the same name. How is the compiler supposed to deal with the ambiguity?
1.3.3. Efficiency - This issue is sometimes more perceived than real. But the use of multiple inheritance can easily lead to complex program organization that is difficult to navigate. This can cause serious issues with readability and writability.
1.3.4. Interfaces are often used as a substitute for multiple inheritance, since it is similar to an abstract class.
1.4. Allocation and Deallocation of Objects
1.4.1. There are two design issues concerning allocation and deallocation. The first is where objects are allocated from, the runtime stack or the heap, etc.
1.4.2. The second concern is with deallocation. Specifically, whether deallocation is implicit or explicit. If it is implicit, then some method of storage reclamation is necessary. If it is explicit, the dangling pointers or references can become a problem.
1.5. Dynamic and Static Binding
1.5.1. Should all binding be dynamic? Should the user be allowed to specify some as static to increase speed?
1.6. Nested Classes
1.6.1. A class in which another class is nesting is called the nesting class. The main intention here is information hiding. If a class is needed only by one class, then there is no reason to define it so it can be seen by other classes.
1.7. Initialization of Classes
1.7.1. Should objects be initialized implicitly or through user declaration? When an object of a subclass is created, is the associated initialization of the inherited parent class member implicit or should the user deal with it?
2. Support for Object Oriented Programming in Specific Languages
2.1. SmallTalk
2.1.1. The first language to include complete support for object oriented programming. In Smalltalk, everything is an object, from something as simple as the integer constant 2 to a complex file-handling system. As objects, all of them are treated uniformly and with the same capabilities.
2.1.2. Classes can't be nested in Smalltalk. All computation is through messages, even a simple arithmetic operation. All objects are allocated to the heap are are referenced through reference variables. All deallocation is implicit.
2.1.3. Smalltalk classes can't hide anything from their subclasses, so subclasses are usually subtypes. When a subclass has a method with the same protocol as its ancestor, the method from the ancestor is hidden. Smalltalk doesn't support multiple inheritance though.
2.1.4. A message to an object causes a search through that object's class, and if the method doesn't exist in the class, the it searches the parent class and so on until there are no other classes to search and an error occurs. Variables in Smalltalk are not typed so there is very little type checking.
2.2. C++
2.2.1. C++ is described in far greater detail in Chapter 2 and Chapter 11.
2.2.2. C++ has both traditional imperative language style data types - int, char, etc. - while adding support for abstract data types in the form of classes and structs. Objects in C++ can be static, stack dynamic, or heap dynamic, but it must be done explicitly. Deallocation must also be done explicitly.
2.2.3. Classes in C++ can be derived from an existing class or it can be a stand-alone class without a superclass. All objects in C++ must be initialized before being used, which means all classes must have a constructor method that initializes new instances of a class.
2.2.4. Class variables and methods can be private, protected, or public. Public means visible to all, private means visible to none, and protected means only derived classes can access class variables and methods.
2.2.5. C++ supports multiple inheritance and its issues have already been covered. All class functions are implicitly statically bound. C++ also has abstract classes where a function has no body and cannot be called. Such functions are meant to provide the interface of a function without giving it any implementation.
2.3. Java
2.3.1. Java is very similar to C++ in how it supports object oriented programming. Java has non-objects - the primitive data types such as characters, numbers, boolean, etc. Later versions of Java allow for conversion between primitive data types and object versions of them - called boxing. All classes in Java come from the Object class which is the root of all classes. All classes are explicit heap dynamic and deallocation is done implicityl.
2.3.2. Java doesn't support multiple inheritance, but it does have interfaces. Interfaces are similar to abstract classes - also supported by Java - and provide support similar to multiple inheritance without causing as many problems. So while a class can only have on e parent class, it can have multiple interfaces.
2.3.3. All method calls are dynamically bound implicitly unless specified otherwise using the 'final' keyword. Using this keyword makes it so a method cannot be overridden by any descendent classes.
2.3.4. Java allows nested classes, though each instance of an inner class must have an implicit pointer to the instance of the nesting class to which it belongs.
2.4. C#
2.4.1. C#'s support for object oriented programming is similar to Java's. It includes classes - like Java classes - and structs, which are somewhat less powerful constructs. The main difference between classes and structs is that structs are stack dynamic and are not allowed to be sub classed to avoid object slicing. C# Does not support multiple inheritance.
2.4.2. C# requires special keywords in order to allow dynamic binding and override parent class methods. Users must use 'virtual' to allow dynamic binding and 'override' to denote a method is being overridden.
2.4.3. As with Java, all classes are derived from the Object class, which defines certain methods that are available to all classes.
2.5. Ruby
2.5.1. Ruby is a pure object oriented language in that it treats everything as an object. Even simple arithmetic operations that look like predefined methods are evaluated using message passing.
2.5.2. Since all variables are references to objects, they are all typeless. As a result, all variables are polymorphic and are dynamically bound. Any variable can hold any data type. This also makes type checking much less useful, though.
2.5.3. Ruby has no subtypes, only subclasses, since all instance data is private by default. If external access is required, accessor methods must be defined.
2.5.4. Inheritance is Ruby is defined using the less-than symbol.
3. Object Oriented Programming
3.1. Inheritance
3.1.1. The main idea behind inheritance is software reuse. Reusing older code leaves more space for newer code. And the best targets for this reuse are abstract data types.
3.1.2. Inheritance allows for one abstract data type to inherit from another abstract data type its methods and parameters. The new data type can then modify the inherited methods and parameters to better suit itself.
3.1.3. Single Inheritance - This is when a subclass has a single parent class.
3.1.4. Multiple Inheritance - This is when a subclass has multiple parent classes.
3.2. Abstract data types in object oriented languages are generally called classes. And inheritance allows for a clearly defined hierarchy between classes.
3.2.1. A class that is derived from another class is called a subclass or child class, etc. The class from which the new class is derived is called the superclass or parent class, etc.
3.2.2. Instances of classes are called objects.
3.2.3. The subprograms that define the behavior of an object from a class are called methods. Method calls are often called messages. Computations in an object oriented program are specified by messages sent from objects to other objects, or classes.
3.2.4. Methods are similar to subprograms - both are blocks of code that perform computations, and both take in parameters and return results.
3.2.5. Passing a message is different from calling a subprogram. A subprogram typically processes data that is either passed to it by its caller as a parameter or is accessed nonlocally or globally. A message that is sent to an object is a request to execute one of its methods.
3.3. Subclass
3.3.1. There are many ways a subclass can differ from its parent, but there are three common ways.
3.3.2. 1. The subclass can add variables and/or methods to those inherited from the parent class.
3.3.3. 2. The subclass can modify the behavior of one or more of its inherited methods. A modified methods has the same name, and often the same protocol, as the one of which it is a modification. This is called overriding an inherited method.
3.3.4. 3. The parent class can define some of its variables or methods to have private access, which means they will not be visible in the subclass.
3.3.5. Classes can have two kinds of methods and two kinds of variables.
3.3.6. The most commonly used methods and variables are instance methods and instance variables. Instance variables are what store an object's state. Two objects of the same class differ only in the state of their instance variables. Instance methods operate only on the objects of the class.
3.3.7. The other type are class methods and class variables. Class variables belong to the class, and there is only one copy for the class. If we wanted to count the number of instances of a class, then a class variable would be the only thing that can do that. Class methods perform operations on the class, and sometimes on objects of the class. Ex: Array.toString()
3.4. Abstract Class
3.4.1. An abstract class is a class that has at least one abstract method - a method that has been declared but not defined.
3.4.2. Sometimes a class has many subclass that require a method that would be out of place in the main class. In such situations, the class has the protocol of the method, but not the body, which is them inherited by all the subclasses that need it.
4. Implementation of Object Oriented Constructs
4.1. Instance Data Storage
4.1.1. There are multiple mays to store instance variables. One is Class Instance Record. The structure of a CIR is static, so it's built at compile time and used as a template for the creation of the data of class instances. In this variation, classes are extensions of record structures. As such, accessing instance information is as efficient as accessing the fields of records.
4.1.2. Dynamic Binding of Method Calls to Methods
4.1.2.1. Methods bound statically need not be involved in the CIR for the class, but methods bound dynamically must have entries. The entries could simply be pointers to the actual code for the method.
4.1.2.2. Multiple inheritance can complicate the implementation of dynamic binding. Keeping track of the pointers for each inheritance can get very complicated and is not very efficient.