Combining Classes

Marcel Weiher marcel at system.de
Tue Dec 15 00:28:57 UTC 1998


Hi John,

I am not really familiar with SD, but here are a couple of comments  
nonetheless (probably firmly planting foot in mouth):

First a couple of observations: your experiences seems to confirm  
the dual problems of domain specific languages vs. the problems of  
frameworks in general purpose OO languages.  Another central problem  
seems to be dealing with collaborating objects via explicit  
associations (valves/relations) and the fact that explicitly naming  
all the other objects your objects had to talk to was tedious.  Is  
this in the ballpark?

Maybe you shouldn't have built an 'object-oriented' version of SD,  
but rather a message-oriented version. With that, think of messages  
that can be reified, caught, analyzed and used to construct a static  
model of the dynamic interaction that was created by the message  
send.  Also try to think of messages that can be sent not just to a  
single known target, but broadcast or sent to static or dynamically  
determined collections.

The collection example I posted to the group gives an example of  
these ideas (though much simpler than your domain) and also  
illustrates the duality between message-distribution and data-flow:   
the single message or message sequence is intercepted and converted  
into a linked list of 'filter' objects that apply the message to all  
elements flowing through them.

Interactions with neighbours on the map could be obtained by having  
the neighbours computed, the messages distributed to these computed  
neighbours and the distribution paths traced and added to the static  
model.

Regards,

Marcel


> I've used an approach called "Systems Dynamics" to build medium sized 
> simulation models.  In an SD model there are 'level' objects  
(implementing
> floating-point state variables), and 'valves' to represent flows or 
> material
> between levels.  Formulas are attached to values to determine the  
rate of
> flow from an input to an output level.  There are several modeling 
> environments such as Stella (see http://www.hps-inc.com/) that provide 
> a
> nice graphic environment for hooking up complex networks of these
> elements.
> A SD model is equivalent to a system of partial differential  
equations and
> is executed using standard integration algorithms.
>
> It is true that you would never want to implement a  
general-purpose program
> in a SD package, nor even a simulation model that did not fit in to the 
> particular modeling paradigm.  There would be some real advantages to 
> building a SD package within an object oriented programming  
environment.
> In
> particular it would make it easier to integrate SD models with other 
> software and simulation tools.
>
> As a grad school term project built a class library for spatially  
organized
> SD models. In this case small SD models were attached to cells or  
polygons
> on a map.  Each cell's model had to interact with its neighbors.  I 
> discovered that creating an object-oriented version of the SD elements 
> was
> relatively easy, but creating an object-oriented version of the SD 
> paradigm
> was difficult.
>
> I think the same problem would occur in any language that made  
relations (or
> even propositions) first class objects.  Like relations, valves  
have two
> sides (input and output) and really do not belong to any one level  
object.
> If you try to create a container class or module of SD components  
it quickly
> feels a lot less encapsulated when each container sprouts all of those 
> (independent) connections to other modules. Network thinking is
> somewhat
> different from object oriented thinking.  In my case the situation was 
> worse
> as each model on the map had to have connections to the models in the 
> neighboring cells.
>
> I ended up creating an object oriented macro language for building SD 
> networks.  That worked fine but it was no longer really object  
oriented SD.
> It was OOP meta-programming for a non-OOP language.
>
> How could I solve this problem in good object oriented style?   
What features
> would allow me to take a class library implementing SD systems and  
another
> implementing, say, polygon (vector) maps and combine them?  If  
there were
> an
> easy way to do it wouldn't I still have to work out all of the  
difficult
> ramifications of combining two very different kinds of systems?
>
> When using a powerful programming language you still have to try to 
> understand the behavior of the things you create.  If you start  
with two
> complicated systems of classes it may be very difficult (not  
impossible)
> to
> understand the product of combining them.
>
>
> Jonathan





More information about the Squeak-dev mailing list