Application As Collaborating Objects

This application type exhibits the concept that applications are the aggregation of the community of objects that exist and interact with one another. The application's information model is expressed by the objects' states, the application's functionality is expressed by the objects' behaviors.

Much, if not all, of the OO material conveys this perspective. One strength of this perspective, at least for me, is that I can imagine the objects as little folks who happily run around doing their jobs. The ObjectAnthropomorphicPrinciple. Sort of like the sci-fi stories of my childhood...

This is my preferred way to think of the world. Patterns fit well in this world, being concerned with the interactions between objects that can be created to solve particular problems. -- ChrisGerrard

There is a natural antagonism between ApplicationAsDbVeneer and ApplicationAsCollaboratingObjects. I'm trying to puzzle out the hows and whys.

What are the characteristics of applications, and how are these represented in each of the forms?

Behavior
Information State
Lifetime

There's a reference to the Object-Oriented view of applications, and the relationship between Object state and persistence in "Object-Oriented System Development" (ISBN 0-201-56355-X ) by Dennis de Champeaux, Douglas Lea, and Penelope Faure, copyright 1993 by Hewlett-Packard Company. There's an online version, the persistent section is at http://g.oswego.edu/dl/oosdw3/ch23.html#SECTION00040000000000000000

The statement: "Our design attitude about persistence is a little backward from some others. We consider the real objects to be active. Persistent media merely hold snapshots of state information needed to reinitialize or reconstruct functionally identical objects in case the current ones somehow fail or must be made dormant. This is in opposition to the database-centric view that the ``real data'' live in a database, and are transiently operated on by a database manager and other programs."

Pretty much conveys the concepts I'm constantly trying to represent in the applications I'm involved with, and is in contrast to the Db-centric view of most "corporate" types.

Somewhere along the line in the past fifteen years or so "The Database" became the whole point of software systems, at least as manifested in the corporate environments I've been involved in.

But the database is the whole point of software systems. Customer information, sales histories, business activity logs, are assets -- they are valuable to the business. Objects and applications are overhead -- expenses -- needed to effectively record and present data; they have no inherent value beyond their efficacy in recording and presenting data.

I think the antagonism between ApplicationAsDbVeneer and ApplicationAsCollaboratingObjects belongs to ObjectRelationalPsychologicalMismatch. Neither one of the two approaches is right, and the question whether the database or the application should take precedence is a false one. An application is an application and a database is a database; both are very different things and serve different purposes.

The OO side of the story is that "behavior" is more interesting than data, and data without behavior has no value, therefore the OO should take precedence. In fact, this approach is a reinvented wheel. People did just that, and some systems are still running this way, during the 60s and 70s when Cobol was king. It has been established that this approach may lead to disaster. Now with the reinvention of some wheels, many people are likely to repeat the same mistakes.

The DB side of the story is that once data is in the database and well organized, applications can be mixed and matched at will, generated almost automatically with 4GLs, report software, etc., etc., so they are a lesser concern for the enterprise. This approach is also wrong, although it has less potential for disaster than the first approach. -- CostinCozianu