Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!m.cs.uiuc.edu!cs.uiuc.edu!voss From: voss@cs.uiuc.edu (Bill Voss) Newsgroups: comp.lang.smalltalk Subject: Re: Access methods - New feature ? Message-ID: Date: 22 Apr 91 23:38:34 GMT References: <1991Apr21.221149.8057@vuse.vanderbilt.edu> Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager)) Organization: Typed Smalltalk Group, Dept of Comp Sci, Univ of IL in Urbana. Lines: 28 In-Reply-To: voss@cs.uiuc.edu's message of 22 Apr 91 11:36:38 Nntp-Posting-Host: laslo.cs.uiuc.edu Teach me to be careless when I post. ;-) Naah.. >I wrote: > I am not saying don't use such methods. I am saying that until > you finish eliminating such methods from a design, you should know you are > not finished creating your design. Exception: Objects which exist solely > to "encapsulate" external interfaces must frequently violate this rule, > until you can redesign the external part of the interface. I still maintain that using access methods is a strong indication that the programmer has goofed (or not finished). However I forgot the BIG exception. The "private" method category is almost always filled with "access" methods, and I tolerate this (in MY code) PROVIDED all methods in the "private" category are only used by other methods in the SAME CLASS (or maybe reluctantly subclasses). [NOTE: Access methods in the "private" category can also almost always be avoided by using double dispatching. I generally prefer to use double dispatching, but consider a more direct interface acceptable when confined to PRIVATE methods.] My objection is not an algorithm, but it is in my experience a very good heuristic. When I call another class's access methods, I almost always find I should have opened another browser, and started adding methods to the other class instead. Thus as a "purist" on this question, I consider access methods similar to the goto statement. Occasionally needed, but usually abused. Bill Voss - the purist -