Colin Kettenacker wrote
> However a more interesting debate is the need for accessor ("getter")
> methods at all.
>
> Some time back, on one of the director mailing lists, Brennan Young (I
> think) had found an article on OOP that he posted to that list. I will see
> if I can find the URL again... Here it is:
>
> http://www.javaworld.com/jw-07-1999/jw-07-toolbox.html
Glad you brought this up again, Colin.
> As with most articles of these types you probably find that you agree with
> some of what is said and disagree with others. But one part that struck me
> as fascinating is that the article went on to say that "Getter and Setter
> methods are evil" or something to that effect. Essentially it says that if
> you have a method that simply returns any private data (such as properties
> in a lingo object) that this is essentially just a cheat for making private
> data public. Wow! Pretty strong statement. But it made me think. It goes on
> to say that when one object requests another object's private data so that
> it can perform a task with that data, there is a fundamental flaw with your
> OOP structure (I'm paraphrasing here). Instead you should modify either the
> object structure or move the task into the object that has the required
> property.
That was exactly the point which got me thinking too. Some of the other
stuff in that article (particularly to do with GUIs) is less relevant in a
Director context because almost everything is part of the GUI anyway, but
this is the suggestion that made the most impact on me:
"Never ask an object for the information you need to do something; rather,
ask the object that has the information to do the work for you."
> Anyway I'm not saying that I buy into this myself but since reading this
> article (and for my own personal interest) I have applied that rule of thumb
> (no "getter" or "setter" methods) into my programming to see if it has any
> legs. The jury is still out for me, but here are some of my initial
> assessments:
Ha! Me too! This is going to be interesting.
Actually, on a very recent project, as a deadline loomed large, I had to
make a couple of get methods because there was not enough time to
encapsulate the functionality that was required. I dirtied three or four
otherwise clean objects with 'get' handlers just to make one hastily
considered, last minute hack work. Ugh. Yet another tale of compromise from
the OO playground. Worst of all, I could see a cleaner solution, but
couldn't spend time implementing it.
> 1) It's more difficult to program (but so was switching to OOP for me a few
> years back and now I never program without it).
Perhaps, yes. I've found it easier than I expected to take this approach to
the centre of my practice. There are certainly some hairy moments, but the
discipline is delicious when you really have a completely opaque
implementation working. Like so many programming approaches, practice and
habit have as much a part to play as knowledge and theory.
> 2) It seems to increase the size (lines of codes) of my objects.
I found this too, but then I also found that I could break down the objects
further than I had expected, and in ways I hadn't considered at first.
Because they were well-encapsulated to start with, I could do this without
fear of 'breaking' something else.
Example: I made a little sticky note widget where you could resize it, type
in it, move it etc. The class was getting really big, so I farmed out all
the imaging lingo tasks to a seperate script. Now I've got a nice resusable
script for drawing rectangles with borders, and various other visual
decorations on the edges and corners. You pass it some numbers and a bitmap
member, and it draws the right thing into the bitmap for you.
> 3) I think I am starting to notice better encapsulation, but at the risk of
> making my objects longer and perhaps a little more unweilding.
> 4) Gone are the days of my many and smaller objects (I got to say that I
> seriously miss that). Not that I did not have large objects before. It's
> just that now there all large.
I recognise this experience, but like I said above; If you treat the
unwieldy object as a system in itself, which you can certainly afford to do,
you might find you can break it down further.
For me, it's been useful to think about how my active objects can provide
'services' to other objects, rather than acting as mere data wrappers or
gatekeepers. The encapsulation should never be in question. If I start
asking 'should the object let others see this property?' then I know I
didn't encapsulate properly. The parts of the 'others' who need to see it
probably need to be siphoned off into a class which hides that data and uses
it to provide some service.
A script which moves a sprite along an arbitrary path (list of points) might
provide ways of manipulating the path, such as procedures to apply offsets,
rotations or full-blown matrix transformations, but should never export the
path itself. I am sure most OO-minded people would agree with that.
But what if another object wanted to know when the path started or finished,
or how many points there were on the path, or how far along the sprite was,
e.g. in order to synchronise with some other activity? Is this a case for a
'get' function?
Well, I can certainly think of alternative ways to do this, and it all comes
down to knowing *why* the 'foreign' object needs that private data. If you
know what it's going to be used for, there's no longer any need for a get function.
In this way, having no 'get' functions gives you a solid rule of thumb to
know whether your implementation is truly opaque. The astonishing thing is,
you really can make it work out. I'm not certain this is the one true way or
anything, but I can feel that there's something very robust about it.
> As you can see this is far from a resounding 'Yea' in favour of doing away
> with setter and getter methods, but I am still experimenting and hope that I
> will see improvements.
It would be interesting to hear what else you discover, and what others think.
--
_____________
Brennan
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
