Gospel of Object Oriented Programming

OOP has gotten very confused. Besides reaching a plateau of classes which it hasn't seemed to get itself beyond, it has never reached it's noble goals of re-useable code.

This page is to help sort out the confusion that you undoubtedly have, because the whole field is confused.

1. Objects are discrete encapsulations of code + data contained and labeled with a NAME. Objects that don't have data are called lambdas or mix-ins. Objects that don't have code are called arrays or structs.
2. The object domain (or DataEcosystem) is a nascent field, but there should be noted two primary kinds of object interaction: users-of-objects and creators-of-objects. The former shall be called users and the latter programmers. Programmers are also users, but users are not always programmers.
3. Users should be spared programmer idiosyncrasies as much as possible. That means all objects in the ecosystem should conform to a uniform syntax for data passing, rather than learn APIs for every object. The syntax from C++ is perfect (">>" and "<<"). The directionality will be slightly asymmetric as the user/programmer can also pass data into and out of their host environment. That environment, itself, can be seen as a special kind of meta-object.
4. Programmers create inheritances -- allowing the hybridization and cross-fertilization of object traits generally for other users. Objects that don't get inherited by any other objects are called terminal objects and sit at the top of the inheritance hierarchies. These are the "power objects".
5. Working objects should be rooted to something tangible, something concrete, lest you be led astray into theoretical nowhereland, forming vicious circles that Bertrand Russell and others saw as "the root of all evil" attempting to re-create LISP. Just as a raindrop is said to form around an impurity in the air, form your objects around the machine types. Container objects are then meta-objects. Here's a guided meditation.
6. Inheritance hierarchies are grown through is-a style inheritance. Aye, "is" can be interpreted in different ways and a whole host of confusion has ensued (cf. "e-prime").

A diversion:

C++ encouraged a form of IS that was rooted to abstract objects (a Square is a Shape, but shape had no representation in the machine types) and the programmer had to stay loyal to the data. For a true data ecosystem, however, it's the data gets passed around -- not objects. C++ style is best left to simulations. Objects in a data ecosystem should be rooted to concrete types, extending them to make ever greater types, forming a tower of data-handling awesomeness.

For example, a Rational is-an Integer. A Rational isn't an Integer in the C++ way, nor in the predicate calculus kind of way, but it IS in the sense of using and simulating all of an integer`s operations (add, subtract, etc). In this from of "IS", the programmer stays loyal to the API (the functions). Functions were always what defined what the object was anyway.

Here endeth the lesson.