[Newbies] Concrete classes... multiple users
Ron at USMedRec.com
Sat Oct 27 02:48:09 UTC 2007
I read your question, but had some trouble trying to understand what you did
or why you are having trouble now that you have to connect to multiple
You say that you have only one Item class. That's good because your domain
classes shouldn't be affected by your backend database. You mention a
factory to decide on and build your adapter. That's good too because based
on some rule you would need to figure out what database to use.
Then I get foggy, you say you have to change class variables. Ok so I'm
guessing that your factory sets the class variables which hold your adaptors
that are used to pull items.
I think your question is: how can I keep from having to change database
adapter class variables? If this is not your question please let me know.
The answer to that question is to modify your model to provide the
flexibility you need so that you can supply adaptors to your application.
Don't use class variables, use some other object instead. Classes are cheap
if you need more functionality.
There is some rule that you are modeling that tells you when you need one
database versus another database. You already have adapters that handle the
different databases, so you only need to build a new object to hold those
database sessions, built from your factory, and some session manager that
knows when to attach and which adapter to use.
So build a session manager, that holds multiple database sessions
(adapters), and code the logic for picking a session on the manager. When
global behavior stops being global move from class side (and class
variables) to a new class instance and model there instead. Let me know if
any of that wasn't clear, feel free to provide more specific information
about what you are trying to do.
President / Principal Software Engineer
US Medical Record Specialists
From: John Almberg
One of the cool things, I think, about Smalltalk is that Classes are
objects... i.e. concrete factories that can be modified at runtime to
produce objects in different ways, depending on the runtime situation. I
just find this so much more intuitive, compared to how classes are done in
But I think I may have used it in a naive way...
For example, I needed an Adapter class that could produce standard Item
objects by connecting to a variety of legacy database tables, converting the
non-standard item records into standard Item objects. This way, the consumer
of those Item objects doesn't care where the items come from.
Originally, I thought I would only have to make these connections, one at a
time. I.e., I'd program the Item class 'factory' with the legacy database
hostname, username, password, and then just start asking for Items. The Item
class would then go out to the database, fetch the proper row, create an
Item object, initialize the instance variables, and return it to the Item
This is intuitive, cool, and it works.
Then the requirements changed and I needed to connect to multiple database
*at the same time*.
But there is only one Item class object!
This really muddles things up, because I basically have to update the Item
class variables every time I need an Item object. No longer cool!
Did I just misuse this feature? Should I have built two Adapter Objects,
instead? Am I missing something obvious? Is a little knowledge a dangerous
More information about the Beginners