harshit wrote > So I was creating this dictionary for column at the instance side > initialization of Employee. > > My instructor suggested to do that in class side initialization, > > My Doubts are: > > 1. Why should we do class side initialization instead of instance side > initialization. > > 2. Could you please refer me to the link which explains how to do class > side initialization. Because when I do Employee new, I see only instance > side initialization is being called.
This comes down to the distinction between class and instance. As you know, instance-side functionality relates to how individual instances behave while class-side functionality related to how /all/ instances behave. In this case, the relational mapping rules are not going to differ from one instance to another. That is why your instructor advised you to set that up using class-side behaviour. If you aren't that familiar with Smalltalk - compared to C-derived languages like Java - it may be hard to get really and truly adapted to the meaning of "everything is an object". In this case, you have a number of classes which represent objects mapped to a relational database, so it makes sense that each such class is responsible for defining what that mapping is. (Although, one could argue that proper decoupling of layers moves the responsibility of knowing how to map the data from the individual classes to some other objects.) As far as doing class-side initialization, it is simply a matter of sending the right messages to the classes at the right time. For example, you might have a Employee class>>#setUpRelationalMappingRules method defined. Before you can replicate the data between Smalltalk and SQL, you need to execute that method. You have choices in terms of when you actually do it. - There is "lazy initialization" in which the initialization is done at the last possible instant. But this incurs an overhead in that every mapping occurrence requires the check. - There is "application start up initialization" in which the initialization is done early, as part of starting the application. For example, when you connect to the database, you can initialize the mapping rules. - There is "class loading initialization" in which the initialization is done when you actually load the code into the image. This is typically controlled by a class-side method called #initialize. The code loading frameworks may execute the method automatically for you. I find too many "corner cases" with this technique and I prefer explicit behaviours rather than implicit ones. The "application start up initialization" is my preferred approach. If you imaging the UML of an application, you would have a package for your model code, another for your persistence mechanism, and a third for your "application". This is grossly simplified, of course. The application package has dependencies on the other two packages, but they have no dependencies on any of the others. In this sense, you are using the application to tie together the model and the persistence mechanism of your choice. At start up, you "configure" the persistence mechanism by explicitly invoking the appropriate methods to set up the server connection, the mapping rules, and anything else your choice of persistence requires. -- View this message in context: http://forum.world.st/Doubt-in-Pharo-tp4769465p4769668.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
