I'm going through the laser game example presented on this list a
short time ago. I notice that he creates accessors for everything. Can someone explain the reasoning for that? I can understand having a wrapper for those functions for which you want external access. However, doesn't it effectively remove the protection of private variables by providing such open access on EVERYTHING. What's the Tao of Squeak on this subject? _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
I've seen both.
I try to avoid creating accessors and only add them as I need. I try to create methods based on the responsibilities of the object and not around its data structure. But, I've worked on projects where every object had accessors for every variable (often necessitated by the persistence framework). You have to trust the programmers not to abuse them as a simple data structure. Kent Beck's Smalltalk Best Practice Patterns describes the forces behind each approach. Another reason to use accessors is lazy initialization. On Tue, Jan 6, 2009 at 8:17 AM, Ryan Zerby <[hidden email]> wrote: I'm going through the laser game example presented on this list a _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
David Mitchell wrote:
> I've seen both. > > I try to avoid creating accessors and only add them as I need. I try to > create methods based on the responsibilities of the object and not around > its data structure. > > But, I've worked on projects where every object had accessors for every > variable (often necessitated by the persistence framework). You have to > trust the programmers not to abuse them as a simple data structure. > > Kent Beck's Smalltalk Best Practice Patterns describes the forces behind > each approach. > > Another reason to use accessors is lazy initialization. > myVar "return state of myVar. if nil, initialize with default value" myVar isNil ifTrue:[myVar := myClass defaultValue]. ^myVar If you have to pay attention to variable initialisation, you have to do it somewhere. So, if you have your own domain model objects, you can do it in #initialize (or #new, if you are adventurous). If you do not have classes for your own objects, i.e. if your instance variables are Strings/Collections/whatever, then you have to do it somewhere else, but where? In #new or #initialize of the class containing the instance variables? Or even in a factory method? That can lead to a lot of code, hence confusion. Personally, I favour lazy initalisation, due to the pseudo-encapsulation (if I may misuse the term here) it offers (whatever the variable is, it will have a meaningful value after accessing it the first time) but that is just my opinion. Claus _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Free forum by Nabble | Edit this page |