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
|