Is Navigational And Behaviorism Tied

I generally consider OOP to be about primarily 2 features:

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: 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.)


See also: GrandParadigmUnification

EditText of this page (last edited July 9, 2010) or FindPage with title or text search