Newsgroups: comp.lang.smalltalk Path: utzoo!utgpu!cunews!helmut!eat From: eat@helmut.scs.carleton.ca (Eric Arseneau) Subject: Re: Access methods - New feature ? Message-ID: <1991Apr24.184323.8018@ccs.carleton.ca> Sender: eat@helmut (Eric Arseneau) Organization: School of Computer Science, Carleton University, Ottawa References: <1991Apr21.221149.8057@vuse.vanderbilt.edu> Date: Wed, 24 Apr 1991 18:43:23 GMT In article , voss@cs.uiuc.edu (Bill Voss) writes: |> |> For some reason GNUS/nntpd keeps dropping the tail of my posting |> with the message "writing to process: no more processes, nntpd" |> So here is that final section, ONE MORE TIME. |> -Bill |> ------------------------------------------------------------------------------- |> The next obvious question is "What do you do instead?" |> ;-) So glad you asked. ;-) |> |> It is my contention that instead of using something like |> |> x1 <- point x. |> y1 <- point y. |> anObject myThingX: x1 Y: y1. |> or in one line |> anObject myThingX: (point x) Y: (point y). |> |> in those cases where you legitimately need to know x and y, |> outside of Point, you should instead write a Point method: |> |> doMyThingOn: anObject |> |> ^anObject myThingX: x Y: y. |> |> I consider this CLEANER, more READABLE, more MAINTAINABLE, and |> much harder to abuse than a straight ACCESS technique. |> |> The fact that it usually involves both less programmer typing, |> and fewer runtime message sends is a nice bonus. |> |> -Bill Voss This goes without saying. But saying that access methods are a no-no is absolutely wrong. This is easy to show by simply stating that a user of an object has absolutely no way to know what is being returned, an instance variable or a function of some other objects. This is what encapsulation gives you, and it suppors CLEANER, READABLE and MAINTAINABLE as the users do not know ho they are implemented. If a function makes sense to do on a particular object, then you add it to that object's class. If myThingOn: is something that is general for a point then it is totally obvious that you shoudl implement it under Point, but this does not rule out access methods. If at a later point I change the representation of my objects, then I still have to provide the accessing methods I had before, so if a method used to return an instance variable, and it no longer does, who's to know the diference. The point is that the method still has to be supported in the new representation because it was part ofg the public interface to your objects before, and you're still repsonsible for supporting all of the previous operations, even if the representation chenages. When I am writing a class, I write an access method for all of my instance variables, making some private and some public. Instead of referencing an instance variable directly, I will send myself the accessor message` to get it's value. That way when I change the representation of my class later on, all of my other operations will still work as long as I still support the old accessor messages, but mapped to something appropriate. This makes it much easier for the implementor (not the user) of a class to change his represenation and still have things working somewhat, maybe not as efficient as it should be, but he can go back later and replace the senders of the old accessors and update them to the new representation. THE POINT: Acessor methods are definitely OK !!!