brian@vuse.vanderbilt.edu (Brian Antao) (04/27/91)
The discussion on Access methods has been very exciting, Thanks to all who participated, and the silent observers too !, it has been an interesting and somewhat enlightning exchange. At this point it seems appropriate to summarize the notable points. This summary may not be complete, so if you feel that I have missed out anything important feel free to follow up. Here goes, 1. Personally, totally disagree with the notion that the use of access methods is a faux-pas. ( No intent to flame Bill the purist !) Here's a justification, Consider a case where you have a hypothetical complex object, whose behavioral state is modeled via a number of instance variables. An event triggered by another object sending a message (not an access method !) causes the object to exhibit a certain behavior marked by a change of state. This causes the various instance variables to be updated, internally of course. One could have a set up such that these cahnges are propagated to dependent objects. subsequently during the course of execution, some object would need to access some of the states, these states can be interpreted as the public states of the object that it exhibits to the rest of the object world. The only way of obtaining these public states is via access methods. So in such instances when certain facets of an object are public, the use of access methods to make these available is only natural. 2. An access method is essentially the simplest form of a method that simply returns an instance variable value, in contrast to a more complex method that returns the result of a more elaborate computation. {this distiction is made without any paradigmatic implications !}. The sender of the method is not necessarily aware of this fact that the message invokes a call to an access method, or a more complex method. An this is what encapsulation is all about !. The external world is only aware of the communication (message) protocol, and not the implementation of the method. In fact instance methods could be used to cache intermediate results of a computation that maybe expensive to perform in response to each message (See point 1, above, where only a major event causes the object to undergo a complete change in its current behavioral state.) 3. The original posting for an automatic mechanism that generates access methods for each instance variable, may not be wholly appropriate. Such a mechanism would be an useful programming aid. However a better structured stratergy that allows a user to designate variables for which access methods have to be defined would satisfy encapsulation requirements. Another useful bookkeeping/error checking feature would be to have the compiler recognize when one of these instance variables is deleted, and appropriately delete the associated access methods. 4. Public v/s Private variables: Since Smalltalk-80 does not have an explicit mechanism to specify public methods, all variables that hace access methods defined, may be interpreted as being "public" in nature. Also one may argue for the message protocols to have some functionality, rather than serve only to categorize methods, such has imposing privacy on the designated methods. Another case for ensuring encapsulation ?, -- Brian Antao, Dept. of Electrical Engg., |INET: brian@vuse.vanderbilt.edu Vanderbilt University, Nashville, TN, USA 37235 Disclaimer: "Artificial Intelligence" - an oxymoron ? -------------------------------------------------------------------------------