Hi Hargrave
Thanks a lot for your quick answer.
The use case I provided is only for the sake of example. Our static
methods do much more than that! :)
You are correct regarding 'promoting' certain static methods to
non-static methods and that's it!
Yeah... there are several situations in the code I'm working on where an
instance variable is interested on some processing performed by a static
method. In this case, an instance variable is typically passed as
argument to the static method. Just to give you a couple of examples,
I've defined some convenience methods which are intended to provide
certain functionalities to instance variables. Something like this:
/**
* Convenience method to {...@link Statics#isLeap(int)}
*/
public final boolean isLeap() {
return statics.isLeap(year()); // obtains 'year' from 'this' and
calls isLeap(year)
}
/**
* Convenience method to {...@link Statics#endOfMonth(Date)}
*/
public final Date endOfMonth() {
return statics.endOfMonth(this); // a bridge to a static method
}
On the other hand, on certain circumstances, having an instance method
will "give an incorrect idea" that a certain functionality is operating
on an instance variable, whilst it's not the case. These are a couple of
examples of static methods turned to instance methods of an inner class
(implementing the sub interface):
/**
* Today's date.
*
* @return a new instance
*/
public final Date todaysDate() {
final java.util.Calendar cal = java.util.Calendar.getInstance();
final int d = cal.get(java.util.Calendar.DAY_OF_MONTH);
final int m = cal.get(java.util.Calendar.MONTH);
final int y = cal.get(java.util.Calendar.YEAR);
return new Date(d, m + 1, y);
}
/**
* Earliest allowed date
*
* @return a new instance
*/
public final Date minDate() {
return new Date(MinimumSerialNumber);
}
Observe "@return a new instance". But, if I provide such methods as
instance methods of the outer class, the call would be:
Date date = ...; // obtain some date somehow
Date today = date.todaysDate();
... which seems weird and may cause confusion because the developer
needs to "remember" that todaysDate() creates a new instance instead of
changing 'this' instance (the 'date' variable).
Obviously we can say that documentation is there to help developers to
"remember" but IMHO "having to remember" is bad by definition because
when you don't remember... you end up with a bug in your code.
So, calls such as:
(1) Date today = date.statics().todaysDate(); // and ...
(2) Date today = statics.todaysDate(); // where 'statics' was
injected by DS, being sub interface of Date
explains much more about what is happening under the covers.
Other methods I mentioned in the beginning can be called as instance
methods or typically as static methods, depending on the use case, like
this:
(1) if (date.isLeap()) { ... } // instance method
(2) if (xyz.isLead(1999)) {...} // mimics static method; part
of the sub-interface
I hope I had explained the technical reasons for keeping some methods
intentionally separated in a sub interface.
Kind Regards
Richard Gomes
M: 44(77)9955-6813
http://www.jquantlib.org/index.php/User:RichardGomes
twitter: frgomes
Jquantlib is a library for Quantitative Finance written in Java.
http://www.jquantlib.org/
twitter: jquantlib
(I had to copy/paste your message :~ I've changed from digest to
individual messages now! )
==================================================================
BJ Hargrave wrote:
I guess my first question is why do you need a static method to access a
static field? Just use a normal interface method whose implementation
operates on a static field.
public interface ABC {
public int getA();
public double getX(); // provides access to static field X;
}
public class ABCimpl implements ABC {
private int a = 10;
public int getA() { a++; return a; }
private static final x = 1.2;
public double getX() { return x; }
}
-- BJ Hargrave
Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
