Graduate Program KB

  1. Encapsulation
  2. Inheritance
  3. Polymorphism
  4. Conclusion
  • Things OO is claimed to be but can't be defined by:
    • 'The combination of data and function'
    • 'A way to model the real world' (what does that mean and why would we want to do it?)

Encapsulation

  • C had perfect encapsulation: If you declared data structures and function calls in header files and implemented them in implementation files users of those header files could call those functions but would have no access to the members of those data structures.
  • C++ removed this perfect encapsulation by requiring declaration of class's member variables in header files. The compiler will prevent access to them but the client still knows they exist. If those member names are changed, the program must be recompiled.
    • Encapsulation is partially repaired by introducing the public, private, protected keywords but it's just a hack(?)
  • Java and C# abolished the header/implementation split altogether, making it impossible to separate the declaration and definition of a class
  • OO can't be defined by encapsulation. Many OO languages have little or no enforced encapsulation.

Inheritance

  • Inheritance - The redeclaration of a group of variables and functions within an enclosing scope.
    • C had this - you just had to do it manually, and you didn't have C++'s implicit upcasting.
  • 'While OO languages didn't give us something completely new, it did make the masquerading of data structures significantly more convenient

Polymorphism

  • We had polymorphism before OO languages - it was called STDIN and STDOUT. Every IO driver (at least in the UNIX perspective) had to have an identical signature:
struct FILE {
    void (*open)(char* name, int mode);
    void (*close)();
    int (*read)();
    void (*write)(char);
    void (*seek)(long index, int mode);
}
struct FILE console = {open, close, read, write, seek}
  • This trick is the basis for all polymorphism in OO.
  • In C++ every virtual function within a class has a pointer in a table called a vtable and all calls to virtual functions go through that table. Constructors of child classes simply load their version into the vtable of the object being created.
  • Polymorphism is just syntactic sugar for the application of pointers to functions. It does have an obvious practical purpose though. Polymorphism makes it much safer and more convenient than explicitly using pointers to functions. There are many conventions to follow to avoid introducing bugs, and OO's polymorphism imposes those conventions
  • OO imposes discipline on indirect transfer of control
  • What makes polymorphism great is it's ability to make logic that can be independent of how it is applied.
    • In the 50's we realized that programs should be device independent. We wrote lots of programs that were device dependent only to discover we really wanted those programs to do the same job but on a different device.
    • For example, as the standard for data moved from punch cards to tape large portions of existing programs had to be rewritten to handle that.
  • The plugin architecture was invented to support device independence and has eben implemented in almost every operating system since its introduction. Despite this, most programmers didn't apply the plugin architecture because of how dangerous using pointers to functions could be until OO made it easy and safe.
  • Polymorphism introduces the possibility of dependency inversion, which gives software architects absolute control over the direction of all source code dependencies in the system.
    • No matter which module does the calling and which module is called, the software architect can point the source code dependency in either direction.

Conclusion

  • Object-Oriented programming is programming that uses mechanisms imposing certain conventions to safely perform polymorphism and gain absolute control over every source code dependency in the system.