Is Navigational And Behaviorism Tied

I generally consider OOP to be about primarily 2 features:

Navigational relationships (See NavigationalDatabase)
Behavior-centric interfaces (as opposed to data or attribute-centric interfaces)

These are generally the anti-thesis of TableOrientedProgramming. But I wonder if these two items are really related, or if its possible to have a paradigm/technique that is one or the other. It is important because ideally a compromise or merging can be found between the two so that one is not forced to accept the whole OO kit and kaboodle if one ends up in an OO shop.

I tend to think the two go hand-in-hand because behavior-centric interfacing leads naturally to navigational. This is because interfaces tend to downplay relationships into just a behavioral request. It seems a philosophy that skips around the issue of relationships between things and religates it to an implimentation detail. Thus, there is no factoring of common relationship idioms that a DB-centric approaches take. But, maybe I am just blinded by the OO-versus-TOP fights into not seeing something in-between.

--top

I don't believe they are directly related. I think the desire for encapsulation is what effects the need for navigational. Encapsulation has a number of benefits in terms of security, safety, expense of development and change (low encapsulation tends to lead to high inter-module coupling in the chaos of large-team programming), expense of error, etc... but isn't truly necessary for behavior-centric programming. Now, encapsulation leads to navigational in a fairly straightforward manner: if you've 'encapsulated' data or behavior, you definitely need a means to identify it, and that generally means first identifying 'the capsule' in which the data or behavior is described (speaking loosely).

But consider behavior-centric programming without navigational. You simply need to kick encapsulation from the picture. You couldn't have 'objects', of course, because 'objects' are little pockets of encapsulation. Rather, 'behaviors' would need to be global in nature (i.e. global to the database, or to 'the entity' or 'the brain' or, most broadly, 'the actor'). To see what this might mean, you'd probably want to study 'behavior' over actors in general to understand what the options are. As a person who HAS studied 'behavior' (while intending to understand 'intelligence'), I've identified three basic types. I do not claim these three to be all possible types; however, they are the only three of which I've ever found example:

Active behavior (associated most closely with ProceduralProgramming minus any polling loops or interrupts): You give the computer a bunch of actions to perform, one after another, possibly with conditions. It performs them like some mechanical number-crunching juggernaut... i.e. lacking any understanding or purpose of its own. Any 'intelligence' procedural behavior can be said to possess belongs clearly to the programmers (who made ALL the decisions ahead of time). Can still be incredibly complex, of course, just like any other piece of clockwork.
Reactive behavior (associated most closely with EventDrivenProgramming): You create a set of triggers that cause actions. The fundamental component of 'reactive' that sets it apart from 'active' is the percept - the ability to receive and process a signal - an event - that a certain trigger-condition has been met. Triggers can be arbitrarily complex (e.g. complex patterns of inputs, both temporal and spatial, with arbitrary conditions)... but the triggers themselves aren't really 'actions' (i.e. they don't deliver signals outside 'the system', though they may trigger actions). Intelligence level of reactive programming is about on par with jellyfish, but human programmers have proven adept at putting it to good use... e.g. modern GUIs are based primarily on reactive behavior.
- Merging 'Reactive' behavior-centric programming with Databases isn't too difficult in concept - it is similar to 'triggers' based on other things. Ideally, you could trigger on arbitrary patterns being identified within the Database... i.e. trigger on changes to arbitrary queries.
- Human reflexes, like the knee-jerk or blinking, are clearly reactive behavior, but trained (unplanned) reactions also count.
Goal-based behavior (associated only with ArtificialIntelligence and ControlTheory? today, but GoalBasedProgramming is described in ThereAreExactlyThreeParadigms): The behaving entity has a 'goal' - a percept or condition to effect (generally described in terms of the 'final state' of one's perception of self and world (though there is usually an assumption that one's perception of the world is the world)). This entity then generally plans (via creation of reactive and active behavior-descriptions) then actuates towards accomplishing the goal. Strictly, 'planning' is not necessary - one could actuate at random to obtain a goal - but planning does have a tendency to make the operation efficient and less dangerous and far more likely to succeed. Planning, of course, requires KnowLedge of how one's actions affect self and the world (or at least one's perception thereof)... this is often encoded directly into the system, but could be learned (learning is not a necessary component of 'behavior', and is a very deep subject on its own). 'Percept' in this behavior model can affect one's behavior, but not via direct reaction; rather, percept goes into a database (or equivalent), from which higher-level KnowLedge is derived (based on encoding or learning) which affects one's plans and thus one's actions towards achieving goals.
- Programming a system like this would involve manipulating the set of goals, the knowledge set, knowledge derivation from percept (i.e. the inference engine, the set of pattern-recognizers), and derivation of knowledge on how one's behaviors affect the world and self (i.e. the planner, the prediction/'imagination' unit).

Note that none of the three above clearly utilize or benefit from encapsulation except insofar as there is intrinsic encapsulation over the entity (the actor) doing the thinking and thinking about the doing. I.e. there is a limit to the database, and there is a clear 'set of goals' or 'set of triggers', for example, and there are obviously limits on the computation that can be performed based on the available hardware. I'd go so far as to say that all of these behavior-models benefit from avoiding encapsulation. Procedural can carefully plod along all the data when given access to it. Reactive behaviors need to have access to everything to which they might react. Goal-based behavior needs access to all the data to make the very best plans.

Encapsulation, of course, is a fact of life. We won't ever get around the fact that there are CPUs and caches and individual 'actors' with their own independent goals and interests and such. Nor does the need for security or privacy go away. As I mentioned on your page for GrandParadigmUnification, encapsulation would be needed even there to model different computation spaces with different required properties (security, type-safety, memory limitations, temporal limitations (& resource limitations in general), etc.). It'd be foolish in any GrandParadigmUnification to not support encapsulation and utilize it where it benefits. But I'd agree that putting encapsulation on a podium and treating it as some end-all-be-all is a very bad idea. I prefer service-oriented or computation-oriented programming with first-class processes and actors where encapsulation is a consequence of natural forces (need for security, need to keep stuff on one machine or efficiency, and simple avoidance of coupling that would make it difficult to change things in the future). Skilled object-oriented programmers do the same by habit (creating 'components' of processors that encapsulate data primarily to avoid coupling, provide security, and other natural reasons), but 'traditional' OO tends to teach bad habits like creating business-simulators rather than business-data-processors. (e.g. One should never have an object of class 'person' unless that object represents a virtual 'person' walking around with his own encapsulated set of knowledge and behavior in some sort of simulator. And one should never have a business simulator while working for a business that isn't essentially writing video-games, virtual office software, city-modeling, or something similar.)