Concrete classes... multiple users

> Hi John,
>
> 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
> databases.
>
> 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.
>
> Happy Coding!!
>
> Ron Teitelbaum
> 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
> other languages...
>
> 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
> object consumer.
>
> 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
> thing? :-)
>
> TIA... John
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

> -----Original Message-----
> From: John Almberg
>
> Hi Ron,
>
> In a nutshell, I have an application that needs to read Items from a
> database.
>
> I recently discovered that in Smalltalk classes are real objects.
> This struck me as cool, so when I was deciding how to instantiate
> these Items, I thought, hey I'll use the class object as a factory
> (actually, I think it's more of an adapter pattern, but...)
>
> So I taught the Item class object how to talk to the database,
> including username/password, and then I was able to do something like:
>
> item = Item findById: 2
>
> And items from the database were instantiated as Items, seemingly by
> magic.
>
> This seemed so intuitive and simple, and just 'right'. It
> encapsulated and hid the whole legacy database messiness and adapted
> the database fields into the Item attributes I really needed.
>
> Best of all, it could later be reprogrammed to talk to a slightly
> different database and adapt that database's fields into exactly the
> same Items, so the rest of the program didn't have to know it was
> talking to a different database.
>
> The problem arose when I needed to talk to more than one database *at
> the same time*, since the Item class was programmed to talk to a
> specific database. The only way to talk to another database was to
> update the class variables before asking for the new Item. This was
> ugly and, worse, the Item users had to know that there were different
> databases to deal with.
>
> Anyway, yesterday I realized I needed multiple objects to connect to
> multiple databases. I figured I had two choices:
>    - subclass the Item class
>    - refactor entirely and build something like an ItemAdapter class,
> who's instantiated objects would connect to the database, create Item
> objects, initialize them from the data records, and hand them to the
> Item consumers.
>
> The second choice seemed the better, so that's what I did.
>
> So, I think it was a case of falling in love with a cool feature, and
> then mis-applying it, just because it was dying to be used.
>
> Hope this explains it... I'm afraid I don't always get the jargon
> right, but that's why I'm a newbie, I guess!
>
> -- John
>
>
>
> On Oct 26, 2007, at 10:48 PM, Ron Teitelbaum wrote:
>
> > Hi John,
> >
> > 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
> > databases.
> >
> > 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.
> >
> > Happy Coding!!
> >
> > Ron Teitelbaum
> > 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
> > other languages...
> >
> > 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
> > object consumer.
> >
> > 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
> > thing? :-)
> >
> > TIA... John
> >
> >
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Websites for On-line Collectible Dealers
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Identry, LLC
> John Almberg
> (631) 546-5079
> [hidden email]
> www.identry.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

> Hi Ron,
>
> In a nutshell, I have an application that needs to read Items from a  
> database.
>
> I recently discovered that in Smalltalk classes are real objects.  
> This struck me as cool, so when I was deciding how to instantiate  
> these Items, I thought, hey I'll use the class object as a factory  
> (actually, I think it's more of an adapter pattern, but...)
>

>
>> So, I think it was a case of falling in love with a cool feature, and
>> then mis-applying it, just because it was dying to be used.
>
> On the contrary, it sounds to me like you approached the problem in
> exactly the right way. You correctly observed that classes can serve
> as factories, so there was no need to invent something new for that
> purpose. You used that understanding to implement a simple solution
> that worked well, and when you encounted a need to support additional
> complexity, you refactored your system to do so. Well done.
>
> One of the things that makes Smalltalk an enjoyable environment is
> that it does not force you to completely understand a problem before
> you get started solving it. You can start simply and move things  
> around
> later on as you improve your understanding and discover your mistakes.
>
>> Hope this explains it... I'm afraid I don't always get the jargon
>> right, but that's why I'm a newbie, I guess!
>
> If you like to think in terms of design patterns, "Smalltalk Best
> Practice Patterns" by Kent Beck is a very useful guide.
>
> Dave
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners