* The ideal object representation that transforms to real object.

* Abstract unit of measurement that does not depend concrete things. Then, other
concrete units of measurement are provided and conversors factor to convert from
one another is used depending on the purpose.
In Java 2D API this unit is the points in user space. The concrete unit is the
points in device space (mesured in pixels). The points in user space are
converted into inchs first. The factor is arbitrary (or set by some decission
but is selected by the programmers). 72 points in user space is an inch. Then
an inch in EACH DEVICE is converted into pixels.
* The manipulation of the objects are done in phases. In each phase, grouped
things are done and objects with some characteristics are manipulated. For
example, in Java 2D API, in the before transformation phase, the objects to
be manipulated are shapes in user space coordinates. After that, the objects
are those shapes in device space coordinates (pixels).
* The abstraction is a logic understanding. So, the concepts can be presented
in one way and the implementation can layout concepts into physical objects as
it wishes. For example, a Graphics pipeline can be thought as several separated
steps but the implementation can mesh up several of them into one for
efficiency.
Different coordinates systems that are indepent and are linked by convertion
factors or transformations.
* The objects holds an internal state so different objects can colaborate in the
modification of this internal state. When something is done, the internal state
is selected to the job in a predictable way.
* Limit the classes which you interact with and do convertions to that classes.
For example, a rendering engine works with Shapes. A Shape can be filled.
A shape can be drawn its outline. To do so, with the stroke of the pipeline,
transforma the outline of the Shape into another Shape and the fill. To draw
text, transform characters into Shapes with the help of a font and the fill.
* The participant objects are not tightly coupled one another. Instead of that
they are registered and associated with a symbol into a directory. When some
operation is needed to be done, a controller gathers information about the
environment and from that, recovers the associated object. Then, the object
will implement some callbacks and the environment is passed to the job. Another
option is that the object retrieves more objects to the job.
For example
* Name things. Put the things a name and give a definition for them.
* There are object that have no state and provide only function to do things.
Because of that, other objects hold their state and a reference to them.
* There are types of interfaces or concepts that are the glue between
components and are the convention to work. Each component can work as it wants
but when communication is needed, those concepts that all know about them
are used. So, component particular data must be converted to the abstract
concept.
* User objects to generate values, store them and then use other objects to
interpret those values.
* For abstractions specify descriptions but not how they are implemented.
The abstraction must be in terms of concepts. And then, the implementation
picks up mechanisms and defines what that mechanisms mean and the rules
defined over them.

For example, if I have two operations called

move and stop
I can do a specification referring to move and stop. But there can be
The specification could be
move stop move results in stop because something is wrong.
several implementation.
** String implementation.
*** move maps to "move"
*** stop maps to "stop"
"move" "stop" "move" -> "stop"
** Integer implementation.
*** move maps to 0
*** stop maps to 1
0 1 0 -> 1
* The interfaces don't have to be in the same package as concrete classes.
* Try to get general procedures to do things that work on abstract concepts.
For example, when trying to guess which is the interior of a Shape. If you
do that, do it for simple primitives only.
You can do a procedure in which you throw lines from the side and when
the number of cuts with Shape's outline is odd, then that is the Shape's
interior.
* Provide primitives that are the basic units for build more compex things.
They are building blocks. Provide operation to operate with building blocks.
This operations results in other blocks. Provide means to give a name
to the resulting blocks so they can be retained (abstraction). Provide
means so the new building blocks can participate in the same operations
that the primitives can do.
* Define things by their descriptions and also by the groups the belong to.
For example, define a Shape and don't just put it's methods. You can say
that different type of methods (for checking bounds, for detecting colission,
for getting iterators...).
* When defining a addressing space, provide some addressing for none objects.
Addresses that are no valid references. It is the null object for that
addressing space.