rick@tetrauk.UUCP (Rick Jones) (06/21/91)
In article <4907@osc.COM> Joe Keane <jgk@osc.com> writes: >Not surprisingly, something i wrote touched off a bunch of replies. So now >i'm going to write some more on method names. > >Actually, i agree completely with Jim Adcock's main point, that redundant >information should not be included in a method name. However, i'd say that >it's hardly a minor point whether a method changes the object it's run on or >merely returns some value based on it. In fact, when listing methods the most >important distinction i make is between accessors and modifiers, or whatever >you call them in your language. Agreed. And to do this effectively, you need to distinguish clearly between procedures and pure functions (back to the side-effects argument :-). >My rule on method names is simple. Methods with the same name should do the >same thing. Really this is just common sense, but it can't hurt to make it >explicit. > [ ... ] >At a conceptual level they should perform the same operation on different >things. > >Here is an example of overloading: > > print(char); // print a character > print(int); // print an integer > print(const char*); // print a string > print(const Widget&); // print a widget Also sound. I think that Jim Adcock's example of a single routine name overloaded to either return or set an attribute is extremely confusing, and liable to all sorts of errors. I believe that overloading, while useful, can easily be abused, and in C++ is one the facilities I don't feel too happy about. The problem is that a simple, innocent looking statment can trigger off all sorts of activities which are not at all obvious from the calling code. It's synactically neat, and fine if you know all about the class you're calling (i.e. you wrote it), but if you don't ... >A good convention to follow is that method names should be predicates, in the >grammatical sense. This means that the first word should be a verb which >desribes the conceptual operation, and then this is possibly followed by some >nouns which clarify what the operation is to be performed on. What I believe is a better convention, and described in "Object Oriented Software Construction", is to use different parts of speech for attributes, functions, and procedures. A procedure does something, and is best written as a verb. A function (lets assume no side effects) gives you something; this is semantically the same as a read-only attribute, and is usually best represented as a noun. The exception is boolean attributes/functions, which can either be adjectives (ready, busy, empty, etc), or queries (is_too_big, etc). This convention is used in the Eiffel libraries, and I have followed it myself - it does help considerably to make the code readable. Something I disagree with is functions called "get_thing". This is just emphasising the implementation detail which requires a routine to get a value. The semantics of the calling code is that it wishes to use a value. How the value is provided is not its business. Eiffel illustrates this by making attributes read-only and syntactically the same as argument-less functions. Incidentally, this also helps considerably with the reference/value problem. An attribute/function called "thing" gives you whatever "thing" is in the called object - if it's a reference, you get the reference. If the client code wants a copy, it can copy it explicitly, or if clients are often going to want a copy, a function called "copy_of_thing" can be provided, which is obvious as to what it does. References are not a problem as long as you know what you are dealing with. -- Rick Jones, Tetra Ltd. Maidenhead, Berks, UK rick@tetrauk.uucp Chairman, NICE (Non-profit International Consortium for Eiffel) Any fool can provide a solution - the problem is to understand the problem