Oo Conflicts With Collection Orientation

Moved from RelationalBreaksEncapsulation.

It seems that CollectionOrientedProgramming in general breaks encapsulation, not just relational in particular. It is wider than that. The rules or interface for handling the "cells" as groups are on the outside, while OO wants them to be inside because each object is supposed to handle its own affairs. But if they are inside, then it is hard for the outside operations to operate consistentantly for each cell and take advantage of parellel processing, indexing, and other techniques that require a central or controlled view of collections to work effectively. In my observation, it seems that CollectionOrientedProgramming uses InterfaceFactoring to give each "thing" common or standard operations for handling typical collection operations. It is hard to have an efficient collection-based system without dictating operations on the cells, but such dictation requires something outside the cell to tell it how to handle collection-oriented stuff. This is what busts encapsulation. Collection orientation requires "exocapsulation", that is CollectionOrientedVerbs are like an exoskeleton that binds the "objects". The cell is not allowed to handle its own collection affairs, at least not without violating "collection norms" and possibly reinventing the wheel. It is a philosophical divide over internal responsibility versus dictated collection-oriented norms. -- top

Not really. It depends on what you want to do with collections; in many cases, collections are little more than holders of arbitrary entities and need not care one whit about the entity being held. Of course, the RelationalModel (more specifically, the RelationalAlgebra) defines several operations on relations which do "break encapsulation". More specifically, it required that the items collected within a given relation be records whose internal structure be visible. This is necessary to support relational operations like join, project, select, etc.

For each of those, however, a more generic "object" analog can be constructed (wherein it is assumed a container can hold arbitrary objects, we still assume here that the outer container is a set and thus the contained objects are unique).

But what is "doing" these things? Not the objects themselves. COP is usually driven by a god-like outer service, not each object's methods. It seems a database is being reinvented. What about concurrency issues and all the features listed in DatabaseDefinition? Can you get these without a DiscontinuitySpike?

But two things are happening:

I agree that if one bends and twists OOP enough, it may be able to pull off decent COP. But the fact that it has to be bent, twisted, and perhaps "polluted" with functional programming generally demonstrates my point. I'm pretty sure most any paradigm/style can be pounded into anything else if we push the edges of the definitions or accepted characteristics to their edge. The issue is how much force-fitting is required. -t

There are more ways of combining OOP and COP in heaven and earth than are dreamt of in your philosophy. For example: Collections as FirstClass objects, and collections OF opaque object references.

Perhaps we can divide it into "OOP as commonly-used" and "potential".

Sure. OOP as commonly-used (i.e. in Java, C++, C#) utilizes structured collections of opaque object references. This is called "GenericProgramming". The collections themselves are represented by FirstClass objects. Historically, collections are mutable objects, but the growing use of concurrency has encouraged many OOP languages to focus on immutable collections (collections as ValueObjects) using CopyOnWrite and similar techniques. The result is a hodge-podge of collection implementations that have funky safety and performance characteristics (especially under conditions of concurrency and mutation) - i.e. OOP as commonly used does not handle collections very effectively. But there are no conceptual barriers against an OO language coming boxed with high-quality FirstClass collections (perhaps even relations or tables) in the same sense that OO typically comes boxed with support for integers. Thus, there is no fundamental difficulty combining OO and Collection Orientation.

What you want to do is claim: "but my collections interface won't be able to peek inside the objects!". Sure. That's the point of encapsulation, after all. But that's not a valid argument for 'conflict' because both objects and collections will still coexist peacefully in the same system. That is, the argument "CollectionsArentOo" has merit, but the argument "OoConflictsWithCollectionOrientation" does not.

Opaque objects tend to be object wrappers. It may not be making the OOP be COP, but rather putting an OO wrapper on top of COP.

What do you mean by "object wrapper"? In any case, "conflict" would mean there is some problem with having both OOP and COP coexist in a system. Would you say COP conflicts with integers and characters and booleans?

See also: CollectionsArentOo, CollectionOrientedProgramming, MultiParadigmDatabase, DomainsNotRecordsOrTablesAreObjects
CategoryObjectOrientation, CategoryOopDiscomfort

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