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
John, I am a fellow newbie, but I have a question to clarify yours:
Does each item object encapsulate the hostname etc of the database it came from (metadata), or does it only encapsulate the actual business data?
David
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
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Websites for On-line Collectible Dealers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Identry, LLC John Almberg (631) 546-5079 jalmberg@identry.com www.identry.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi John,
Good luck with your project. By the way if you haven't already heard about it you might want to look at Glorp. Glorp is an object to RDBMS mapping system for Smalltalk (written in VW but ported to Squeak). It is possible that it is more complicated then you need but you may find that it is very useful. Reading the documentation may also give you some idea of the types of issues that you may encounter in your system.
It does sound like you are having fun. There is nothing like solving real problems for learning.
Happy coding!!
Ron
-----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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Websites for On-line Collectible DealersIdentry, LLC John Almberg (631) 546-5079 jalmberg@identry.com www.identry.com
_______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On Sat, Oct 27, 2007 at 09:51:52PM -0400, John Almberg wrote:
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...)
<snip>
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
Dave,
Thanks for the positive feedback. Smalltalk is indeed all about fun for me, but I'm also on a mission to become more productive in my day job as a Ruby designer/programmer. And that mainly means finally mastering the whole OO/Design Patterns/Agile approach (i.e., the difference between 'knowing' OO, and being really proficient with it.)
Luckily, I had the insight to think maybe it might be smart to use Smalltalk as my learning laboratory. Not to pat myself on the back, but that was a really smart move!
I'm not sure why it is so, but I find it much easier to learn things first in Smalltalk. It's probably a combination of the language itself, the environment, but mainly the amazing collection of Smalltalk-oriented books that people have written (including Kent) and that are available for a pittance, used, on Amazon. I've been buying up every Smalltalk book that I can find, and have quite a collection at this point.
Once I figure something out in Smalltalk, I find it translates quite easily to Ruby, which is also a beautiful language, IMHO, but not as good a learning environment.
Anyway, thanks again.
-- John
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Websites for On-line Collectible Dealers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Identry, LLC John Almberg (631) 546-5079 jalmberg@identry.com www.identry.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
beginners@lists.squeakfoundation.org
-
David Corking -
David T. Lewis -
John Almberg -
Ron Teitelbaum