February 17, 2019
Hot Topics:

Object Signatures

  • October 6, 2005
  • By Matt Weisfeld
  • Send Email »
  • More Articles »

Theoretically, if the return type were indeed included in a Java signature, you could have the following methods in the same class:

public double squareRoot (double value)
public int squareRoot (double value)

These methods return different types. Even though the rest of the signature is identical, the Java language design does not allow overloaded methods to have different return types. The Java compiler will catch this and report an error. Even though the return types are different, the Java compiler will not allow methods with the same name and parameter list as long as there is a different return type. Thus, the signature for a Java method is effectively just the method name and its parameter list. That said, each signature must be unique—that is what allows you to overload methods as in the example above.

The method signature that you will use for your example is:

public double squareRoot (double value)

Listing 2 shows what the code would look like if you used the java Math package to do the dirty work.

Listing 2: The Calculate Class

// Class Calculate
public class Calculate {
   private double result;
   public double squareRoot(double value){
      result = java.lang.Math.sqrt(value);
      return result;

Listing 3 shows the application that actually uses the squareRoot class.

Listing 3: The Application

class TestSQRT {
   public static void main(String args[]) {
      Calculate calc = new Calculate();
      double result = calc.squareRoot(16);
      System.out.println("result = " + result);

When this application is executed, the results shown in Figure 4 are displayed. The calculation of the square root of 16 is obviously 4.

Figure 4

What you have done here is provide an object service that calculates the square root of a number. The important point here is the way the application uses the service: invoking a method by using its signature appropriately.

When developers create APIs, they are in effect creating a collection of signatures for programmers to utilize. Although the APIs are accessible to the programmers (these are the public interfaces), the code behind the so-called curtain is not accessible—it is not even viewable. So, when the programmer sees this API:

public double squareRoot(double value);

The programmer does not see this (the implementation):

result = java.lang.Math.sqrt(value);

The fact that the code is hidden is a major plus. There is a very real advantage in separating the interface from the implementation. Among other issues, if the programmer knew what the code looked like, it might actually influence some design decisions. Your goal is to make the interface as independent as possible from the implementation. Just consider what the programmer really needs to know when using the sqrt() method.

  • Method Name
  • Parameter List
  • Return Value

This should look very familiar—it is the signature. All the programmer wants to get from the sqrt() method is the correct answer; he/she does not really care how the answer is derived. Most likely, the majority of people would not even know how to calculate a square root by hand. Thus, you could change the implementation of our sqrt() method, and it WILL NOT require a change in the application. For example, you can create a square root with the following formula.

sqrt =exp( log(x)/2)

This formula can then be substituted for the original code in the Calculate class as seen in Listing 4.

Listing 4: The New Calculate Class

// Class Calculate
public class Calculate {
   private double result;
   public double squareRoot(double value){
      result = java.lang.Math.exp(java.lang.Math.log(value)/2);
      return result;

Focus on the fact that the code in Listing 2 and Listing 4 returns the exact same result—despite the fact that the implementation is different. Yet, the interface is the same, and the result is the same. In both cases, you get the result of the method with this line of code.

double result = calc.squareRoot(16);

And, although you might not want to calculate the square root using the code in Listing 4, the fact that you can plug in a new (perhaps better) implementation without forcing a change in the user applications is a major benefit.

Recall the example of the relationship between the interface and the implementation that was presented in an earlier column. Figure 5 illustrates the scenario where you plug in an appliance to take advantage of the electricity coming out of the electric outlet. In Figure 5, the electricity is being produced by a conventional coal power plant. The coal power plant is the implementation. The electric outlet is the interface.

You, as a user of the electricity, do not care where the electricity is coming from—for all you know the electric company could have purchased the power from another state. In fact, a nuclear power plant could be generating the electricity. Or, perhaps your power went out and a generator switched on. In any event, all you need to know to utilize the electricity is to have the proper interface.

Figure 5

Consider an application that connects to a database. If the interfaces in the application are dependent on the code in the implementation, any change to the code inside the method would perhaps force a change in the actual application. However, if you spend the time to design your system properly and separate the implementation from the interfaces, a change to the code should not effect the application, as the diagram shows in Figure 6.

Figure 6


In the database example above, if you are using an SQL Server database and put code in your application specific to SQL Server, then a change to, let's say, an Oracle database would require a change in the application code. The rule of thumb is to avoid putting code in a frontline application that is specific to any specific implementation.

At first, this may seem counterintuitive—how do you not put code for a SQL Server application in the actual application? The answer is to utilize the concept of wrappers. You can "wrap" any implementation specific code in an intermediate class that acts as a "buffer" of sorts. The application would then call methods (services) or the intermediate class, a kind-of middleware. In the next column, you will explore the concept of wrappers and how they improve your designs and how you can take advantage of wrappers to upgrade some legacy code—even if the code is not object-oriented.


Gilbert, Stephen, and Bill McCarty: Object-Oriented Design in Java. The Waite Group, 1998.

Meyers, Scott: Effective C++. Addison-Wesley, 1992.

Tyma, Paul, Gabriel Torok and Troy Downing: Java Primer Plus. The Waite Group, 1996.

Ambler, Scott: The Object Primer. Cambridge University Press, 1998.

Jaworski, Jamie: Java 1.1 Developers Guide. Sams Publishing, 1997.


About the Author

Matt Weisfeld is a faculty member at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a member of the Information Technology department, teaching programming languages such as C++, Java, and C# .NET as well as various web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management. Besides the first edition of The Object-Oriented Thought Process, Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb's Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada.

The material presented in these articles is based on material from the second edition of his book, The Object-Oriented Thought Process, 2nd edition. The Object-Oriented Thought Process is intended for anyone who needs to understand the basic object-oriented concepts before jumping into the code.

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date