But if you have a method taking as an input a matrix which MUST be both
symmetric and banded, you are bound to define a new interface.
Am I wrong?
Maybe the alternative you are thinking of is testing "instanceof
SymmetricMatrix" and "instanceof BandedMatrix" in the implementation of
the method, instead of specifying the required matrix in the declaration
of the method?
Le 02/07/11 21:18, Greg Sterijevski a écrit :
Not a stupid concern in my book. However there is a synchronization
mechanism in place. We are taking part in it right now. Whether the new
matrix implements both SymmetricMatrix and BandedMatrix or is a new tagging
interface (SymmetricBanded) would determined in the list, after a bit of
back and forth.
2011/7/2 Sébastien Brisard<sebastien.bris...@m4x.org>
Marker interface seems to be a very elegant solution. I am just wondering
about a potential issue. Let us assume we defined two interfaces, say
SymmetricMatrix, and BandedMatrix. User A writes a matrix class which
implements both interfaces. Meanwhile, user B implements an algorithm which
requires a symmetric, banded matrix. Presummably, user B will define a new
marker interface, which extends both SymmetricMatrix and BandedMatrix. So we
have on the one hand
class UserAMatrix implements SymmetricMatrix, BandedMatrix;
and
UserBAlgorithm.operate(**BandedSymmetricMatrix).
One day, user A hears of the work of user B. The matrix he has implemented
has just the required features (symmetric *and* banded). But it does not
implement BandedSymmetricMatrix, so he cannot apply UserBAlgorithm.operate
to an instance of UserAMatrix. There is always the possibility of creating a
new class which extends UserAMatrix and implements BandedSymmetricMatrix,
but that would obfuscate the hierarchy tree. Is this a problem? Is that a
stupid remark?
Sebastien
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
