What do method signatures tell us?

A Java method signature

A significant aspect of object oriented programming is deciding what "objects" need to be designed, what data fields (or properties) they will have, and what behaviors (methods) are encapsulated within. For large projects, this usually starts on pencil and paper as opposed to in some IDE. One of the artifacts during what I like to call the "drawing board stage" is a class diagram. In the Unified Modeling Language, a class diagram is a structural representation of a system's classes and the relationships between them. Often, a class diagram will include listings of the properties (and their types) and methods (and their signatures) of a given class. UML is supposed to give us the means to design a system entirely before any code is truly written in a way such that anyone with the UML design plan can implement the system. Hence, the term "unified." 

So the question may arise, how much can we ascertain about the implementation of a particular aspect of a software system from a given method signature? What degree of ambiguity does it introduce to the implementation phase?

If you look at a method signature as it is represented in a UML class diagram, you can pick up the followings things: what class it belongs to, what it's name is, what its return type is, what its expected parameters are. For those who are reading this just to answer the title question, let's look at those individual pieces.

What class it belongs to
Keep in mind, you can garner this without having to look at a class diagram. It is obviously also apparent in the code itself. Say your colleague uses a tool that transforms a class diagram into a bunch of classes with their associated properties and method stubs to start you off with before you do the dirty work of actually coding. Clearly, the methods owner is still available to you. Is the class a hint to how the method should be implemented? Maybe so. A method called "speak" that belongs to a Dog class would probably indicate that the intention with "speak" was for the Dog object to bark, as opposed to what "speak" might do in a Cat class.

What its name is
Your biggest ambiguity buster is the method's name. For example, a method called "average" can usually be rightfully assumed to take an average of it's argument(s). However, a method called "fx98234kl" may do any sort of computation known to man.

What its return type is / what parameters it expects
Largely, the implementation of a function whose signature is the only clue you have is the input and output. Take a look at what parameters have been chosen as the input to the method and their names and types. Then examine the return type of the method. Then it becomes much like a physics problem for a student who hasn't studied. He or she may ask, "What are the starting units for this problem? What does the question tell me the ending units should be? What formula will get me there?" 

Often we can infer what is intended by a method signature from these 4 things. Say, for instance your colleague designs a class called Flight with a property, departureTime : Date that contains the method delayFlight(int minutes) : Date. What can we reasonably assume? 

We might decide that the method body should simply compute the Flight's departure time plus the number of minutes given in the argument and return that result. In a different company, someone does the following sighature: delayFlight(int minutes) : void. Suddenly, we are to write the function such that it computes the same result, but likely we are to set the class' instance variable departureTime right inside the method body.

To answer my title question, we can get a lot of concrete information from method signatures, and can even make some reasonable inferences. However, a method stub is a hole in the plan laid out by the use of UML. Filling the hole and making an ultimate complete design plan for a software system before code is written should include a similar plan at the modular level. A "unified pseudo-code," if you will might solve this problem.