TWiki > Doc > NiceTutorial > FunctionsAndMethods	TWiki webs: Dev | Doc | Main | TWiki | Sandbox
	Doc . { Changes | Index | Search | Go }

Java version

In our example, we declare some classes to describe geometrical figures.

package geometry;

public abstract class Shape
{
  abstract double area();
}

public class Rectangle extends Shape
{
  private double length;
  private double width;

  double area()
  {
    return length * width;
  }
}

In class Shape, we declared a method area, and we implemented it in Rectangle.

Nice version

In Nice, you would write the following:

package geometry;

public abstract class Shape
{
  double area();
}

public class Rectangle extends Shape
{
  private double length;
  private double width;

  area()
  {
    return length * width;
  }
}

There are only two differences:

• the declaration of the area method in class Shape does not need the abstract keyword. It is obvious, from the fact that the is no implementation of area in class Shape.
• the implementation of area in Rectangle does not mention the return type double. This type is already known from the declaration of the method (and the compiler will check that the returned value has really type double).

Using this syntax, you already know how to write methods in Nice. For every method written in Java, you can write an equivalent one in Nice, applying the two differences. In the next section, we see more advanced features for writing methods in Nice that have no equivalent in traditional OO languages.

External methods and multiple dispatch

Suppose that a geometry library is already written. It might be in the standard library of the language, or distributed as a jar file by a company or a freeware website. In any case, you can only use it, but not modify this library. Now, what happens if you need some functionality that is not in the library? For instance, you would like a method that takes two shapes, and returns a boolean, depending on whether they overlap or not.

If you are using Java, your only possibility is to create a utility class, with a static method overlap that has two Shape arguments.

package my.package;

import geometry.*;

class Tools
{
  static boolean overlap(Shape s1, Shape s2)
  {
    if (s1 instanceof Rectangle && s2 instanceof Rectangle)
      {
         ...
         // return the result in this case
      }
    throw new Error("Case not supported: " + s1.getClass() + " and " + s2,getClass());
  }
}

Not very pretty. And this solution has three fundamental problems:

• First, it is not object-oriented: you need to use instanceof to decide which code to execute. In that code, you will need to cast s1 and s2 to class Rectangle. Calling this method will look akward: Tools.overlap(s1, s2) instead of s1.overlap(s2).
• Second, if you create a new subclass of Shape, you will need to edit the source of Tools to handle that new case. If this is done by a user of your code who cannot change the source, it is simply impossible to do that, so extensibility is blocked.
• Third, if you forget a case, the compiler will not tell you, but the code will fail at runtime.

What you would really like to do is to add a new method to class Shape. This is something very simple and natural to do in Nice:

package my.package;

import geometry;

// We declare a new method, that has two arguments.
boolean overlap(Shape s1, Shape s2);

// Here is the code for overlap, when both arguments are rectangles
overlap(Rectangle s1, Rectangle s2)
{
  // Here s1 and s2 are both rectangles. We don't need to use instanceof or cast.
  ...
  // return the result
}

This solution solves all three problems:

• It is object oriented. You can simply call the method with s1.overlap(s2), as if overlap had been declared in class Shape.
• If you declare a new subclass of Shape, you can simply add new implementations for the new cases that it belongs to. This can be done anywhere, including in a different package.
• The compiler automatically checks that all cases are covered without ambiguity. It is guaranted that there will be no error at runtime.

Note that this solution uses two concepts in Nice:

• External methods: methods can be declared outside of classes
• Multiple dispatch: the selection of the code to execute for a method can depend on all arguments. In most OO languages, only the first one (this, or self) is used. This is important here, since we cannot decide if a rectangle overlaps with an arbitrary shape.

If you go back to the first example now, you will see that we could also have defined area as an external method, instead of declaring it inside the class. Both forms are stricly equivalent. It is a matter of style to decide which one to use in that case.

-- DanielBonniot - 30 May 2003

I think it needs to be bit more simplified

First, Simple Examples so that bad developers like me and those who haven't got any base in Java can understand such a good concept of "class-name name" used for method arguments when implementing that particular method.

Second, examples of Nice can be given with no comparison to any other OOL and then can be explained with a normal OOL fundamentals and basics, which will help a newbie to grab more of Nice.

• Can i write an HTML page or two to simplify NICE a bit more by explaining it with basic OOL concepts. I would like to contribute to NICE but at the moment the only thing i can do is a more simplified tutorial and Help in compiling and running, but i don't know how to write documentations the way Microsoft and others guys do. Anyhow, i'll try my best to write a simplified help in couple of days time. One thing more, first i thought to write a NICE addin for SharpDevelop? but i dropped my idea because SharpDevelop? isn't developing fullon, instead i am planning to be on the side for Eclipse( I didn't know about it till today .... no wonder i am an idiot :) ) ...but i'll be needing some time and help in that.