GOOP

NOTE: This document is superceded somewhat (see all objects),
but the essence remains: all objects should conform to a unified
architecture, much like Maxwell's equations dictate all the macro behavior of
your world.

OOP has gotten very confused. Besides reaching a plateau of "everything is an
object" and the false peak of templating systems to re-use code in different
type-contexts ("false peak" because most use of such different types is a
semantic difference, so it makes no sense to conform syntactically), it has
never reached even it`s noble goals of re-useable code. That had been one of
the goals of OOP, not theoretical purity or saving code, although that it can
achieve as well. This document creates a new level of understanding through
the application of philosophy , namely [epistemology] and [Metaphysics],
answering problems with ontology to make a loosely-
coupled , modular , uniform system of objects.

Most programmers never got past Design Patterns, but this is a low bar just to
ensure that your objects don't totally fail. We can do better than that. We
can focus on a computer's syntactic solutions to semantic problems. That is,
we only need a few different syntaxes, if selected properly, to solve many
different semantic problems through something like language analysis. Like
proper use of functions, indentation, inheritance, and message-passing. These
correspond to verbs, nouns (object/function definitions), adjectives (more
specific nouns/objects), and adverbs, respectively. One can say a lot of
useful, compact sentences with these alone.

This page is to help sort out the confusion that you undoubtedly have, because
the whole field is confused. Most programmers thought you should simulate
real-word objects (Square is-a Shape) and C++ originates with SIMULA, but most
programs are not simulations. Generally, objects do not simulate things in the
real world. A "Student" object is not simulating a student, it is a record of
who that student is and what that student is doing. There are at least two
dimensions of object dimensionality or order, such that two separate fields
of object hierarchies may exist, but should not cross (except through their
methods and attribute access?) So, data objects add increasing levels of
structure, sophistication, and constraints to data, while UI objects add
increaseing levels of order and prettiness. The real value of OOP in the age
of the internet is going to be massive amounts of data processing
(exabytes) into elegant ontologies of knowledge.

TL;DR or Zen version for those who don't want to read and cogitate, go
ontology.

---

Here begineth the lesson:

1. Objects are discrete encapsulations of code + data contained and labeled with a unique LABEL. Objects that don't have data are called lambda s or mix-ins. Objects that don't have code are called arrays or structs (or tables for you DB users). And without a label , don't call it an "object". If your input type is the same as your output type, you have a function : don't use an object. (Note: If one is making a simulation, then they need to add a new object model inside this one. This model is for "basic" data: originating and relating to the real world.)
2. All objects must do one thing, or have a single state variable. If an object holds multiple states, the object should be broken up into multiple objects because, inevitably, someone will want to do something with only part of it ([precision domain principle]. If an object doesn't do something, it isn't an object. Complementary if an object doesn't have a state or variable, it is not an object. Refer to rule #1.
3. The object domain (or wiki:DataEcosystem) is a nascent field, but there should be noted only two opposite kinds of object interactions: users -of-objects and makers -of-objects. The former I'll term architects (sometimes: higher-level "applications") and the latter engineers. Engineers are sometimes architects, and architects are sometimes engineers, but they're completely opposite specializations. The object sits in-between, serving both, so there is no canonical way to refer to a object syntactically in some hierarchy (uppercase vs. lowercase, e.g.), as there will always be more than one kind of relationship to any object within a object ecosystem. Each user may structure their objects in a tree (with hierarchy), but ultimately, they exist outside of it as part of a graph (flat, without hierarchy).
4. It is a grave sin to attempt great ontologies of objects XXX OUTOFDATE starting with Abstract Base Classes and building towards specialization. This is backwards (like making a single-table database). Start with concrete base classes, like <int>, and let those hierarchies grow in the other direction (like an object Rational holding an abstracted concept for number that hides machine limitations): the application the user sees -- not your personal relationship to the code. Grasshoppper: just as a raindrop is said to form around an impurity in the air, form your objects around the machine types. Container objects (objects holding objects) are then meta(?)-objects where ABCs are appropriate. [dissolving barriers].

/* ABC methods mimic cell biology: getState (turns into a run method in more
complex objects), getID, clone (move these latter to data ecosystem higher-
level meta method). (look for 1:2:4 type order of methods for each level of
more concreteness.)

1. Users should be spared programmer idiosyncrasies as much as possible. That means all objects in the ecosystem should conform to a API for data passing, rather than learn custom APIs for every object. Just as there are only 26 letters to handle the entire corpus of English text, there are only 5 functions needed to handle Rule of Four: query-object (?), clone-object (%)(push this up to new ABCs?), receive (>>), send (