Breeder Model

This is old stuff, still interesting, but not relevant anymore for the development as we decided to use existing standards for these processes...

Devision of a C++ or Java program into multiple separate "programs". Doing this through the shell is extremely slow.

It can be done faster: Make the small "programs" (which are really classes in libraries) to register themselves under a string-name at a central class called the Breeder class.

Then ensure that the "using" programs/part of the program only will access the small parts through the Breeder, and that they do this only by using the string name as an address for the program they need to call.

An added feature to this model for LogiLogi specificly is that in LogiLogi the page-data will be in separate "stores" once it's loaded from the database, where it is modified by some modules in turn.

I have to admit that this is still a bit slower than direct class/instance calling. And there's one more disadvantage:

The program becomes more complex to maintain in some aspects. If parts depend on eachother then it is the responsibillity of the programmer to not replace that part by something that would be incompatible with the parts that use it, or that would modify the data in a way that is incompatible.

But in return for this it results in many advantages:

Parts of the program can be replaced or added by putting the parts not in static sourcefiles/libraries but in dynamically loaded libs. A program can also be extended much easier once the base-structure is in place.
It keeps the program simpeler in an other way. Especially where simmilar data-manipulations need to be done in sequence. It is in some way a departure from the Object Oriented Approach as it tends to be making programs again more data-flow centered, but at the same time it allows many aspects of Object Oriented design to be exploited (for a matter of fact it's implementation even depends on many aspects of OO Design, like inheritance).
It can easily be turned into script-like constructions. Like one module leaving traces in the data for other modules to follow or act upon (a bit like SwarmIntelligence). Especially if it's an application in which parsing or acting upon data plays a central role like LogiLogi...