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
From:
Richard Gomes <[email protected]>
To:
osgi-dev <[email protected]>
Date:
2009/09/15 09:12
Subject:
[osgi-dev] Best practices regarding 'static' variables and methods
Sent by:
[email protected]
Hi,
As this is my first post, let me first quickly introduce myself:
I'm Richard Gomes, lead developer of JQuantLib http://www.jquantlib.org/.
At the moment, we are preparing some of our code for a proof of concept
running on top of OSGi containers.
I've done some tests with Felix, Equinox and Newton. I've also studied
the various programming paradigms: raw API, DS, iPOJO and a a very
little of Spring DM. I selected DS for my tests.
If you are impatient, my question is will pre quicker and very imprecise:
"Are private static variables a good practice from the OSGi container
point of view?"
Thanks a lot for any help, opinions, etc which will be very much
appreciated.
If you are patient, I'd like to expose an use case and I'd like to be
more specific:
Suppose the following class:
class WithoutOsgiInMind {
public int getA() { ... };
static public double getX() { ... };
}
As static methods cannot participate in interfaces we have to find
another way to declare them.
OK. We can make static methods look like non-static methods via a sub
interface.
Our class of interest can implement the interface and an inner class can
implement the sub interface.
More or less like this:
public interface ABC {
public int getA();
public interface XYZ {
public double getX(); // mimics :: static double getX();
}
}
public class ABCimpl implements ABC {
private int a = 10;
public int getA() {
a++; return a;
}
private static final X = 1.2;
private static final class XYZimpl implements ABC.XYZ {
private XYZimpl() { /* outside world cannot instantiate */ }
public double getX() {
return X;
}
}
}
So, the next step is expose the static inner class somehow.
One idea would be provide a public method in interface ABC (and ABCimpl)
which returns the inner class.
Something like this:
public class ABCimpl implements ABC {
...
public statics() {
return statics;
}
private ABC.XYZ statics = new XYZimpl();
...
}
This solution is not very convenient from the API usage point of view
because it oblige us to eventually instantiate an ABC object just
because we are interested on its static methods implemented by XYZ sub
interface. Like this:
double d = new ABCimpl().statics().getX();
Another possibility would be expose an static variable which provides
access to the inner class:
public class ABCimpl implements ABC {
public static final ABC.XYZ statics = new XYZimpl();
...
}
... which allows us to call like this:
double d = ABCimpl.statics.getX();
Well, the later solution does not sounds well because it explicitly
references implementation ABCimpl.
But... if we remember that ABCimpl acts as a service class, injected by
DS, our code would be:
// injected by DS
void setABC(ABC abc) {
this.abc = abc;
}
...
double d = abc.statics.getX();
Another idea would be inject XYZ interface directly:
// injected by DS
void setXYZ(XYZ xyz) {
this.xyz = xyz;
}
...
double d = xyz.getX();
Now my question can be rewritten more precisely:
Is this the correct approach to expose static variables? Am I making
things more complicated than it should be?
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
