Hi,
First of all, I'm checking to make sure that this is still an active
mailing list.
Second, I'm trying to verify some thoughts I had for the
implementation of a framework I'm building.
I'm relatively new to design patterns so I want to make sure I'm on
the right track with this new design.
Normally I'd spend a large amount of time analyzing every possible
pattern arrangement, but I need to
get moving on this design. Since the beginning of any design is the
most important time, I thought I'd get
input from people who are much more experienced.
The framework I'm working on is based on component plug-ins in a
graphical environment that allows people
to create, discover, interact, play with and script network objects.
The GUI side is based on wxWidgets (actually wxPython)
and this is what I've figured out so far:
1. The framework is some sort of (abstract) factory architecture
where command requests are constructed either directly through a
command shell
or through GUI-based command constructors (the GUI part of a command
plugin).
2. Factories methods for constructing different network objects
(IP's, IP Ranges, NetGroups, IP Lists etc) register themselves as
observers for
specific commands. I've experimented with using a straightforward
observer/interface arrangement, but I'm curious as to whether
it would be more appropriate to use a mediator in between. I'm not
sure what the advantage would be.
3. When a factory method receives a valid creation command, it
performs the required construction algorithm and delivers a brand new
object.
4. Here is where things start getting a little fuzzy. In the real
world a factory rarely holds onto product for very long. Who "owns"
the object that the factory creates? There isn't a whole lot of
discussion on this. (Or I don't know where to look) I've found some
information on what are called RMII Factories that own their own
output, but that seems to be a little forced. Is there a pattern for
product creation / ownership and delivery? Technically it belongs to
whomever requested it.
That would be the user. But the user can't literally own it, so it
must be proxied by something -- some sort of container so that it can
be displayed, interacted with etc.
5. The reason I ask is because it seems natural that after creation,
the standard way to interact with these objects would be by calling
accessor methods within the owner object that get, set, and otherwise
send command messages to the created objects.
6. Since the purpose of this framework is to encourage exploration of
network space and objects I'd like to save the network objects in a
session environment. Perhaps this should be the output of the
factory. How do I transfer ownership and scoping of the created
objects to this session. Is there a known pattern for this type of
interactive session and tools associated with it? I know that this
is similar to a Model-View-Controller architecture, but I'd like
something a little more appropriate.
7. I've looked at the ZODB object database and it looks like a very
nice nearly-transparent persistence mechanism to implement
persistence of the created network object. I'll ask the pattern
question again within this context, "Is there a known facade or
wrapper around an object persistence mechanism like ZODB" that
cleanly controls both the interaction aspects as well as creation,
destruction, viewing etc?
8. I'm also thinking about the communications and event backplane for
the framework. While the observer pattern seems to fit a number of
different aspects of this, perhaps something more sophisticated like
mediator/observer or reactor/proactor/adapter would be more
beneficial in the long run.
I've gone through a lot of pattern information on the net and the
only pattern I've seen that comes close is the tool/material
pattern. I'm not sure that's what I'm looking for, but it's close.
Is there a workbench or sandbox pattern?
Okay, I've said a mouthful. Maybe someone out there can throw me a
line.
Thanks,
Jim Burnes
Software Engineer
Boulder, CO
_______________________________________________
patterns-discussion mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
