Closed MatthewRueben closed 3 weeks ago
Renamed this Issue, as the scope has grown.
Some different approaches to doing this:
SockPairerTester::testAlgorithm()
as an argument. <T extends Matchable<T> & Comparable<T>>
). OK, here's the plan:
Ok, so step 1 above just sort of kicks the can down the road, so I'm making it into a new, separate Issue.
How about an abstract MatchableFactory
extended by a concrete MatchableByNumberFactory
. You would have it createFirstInstance()
, createMatchingInstance(Matchable existingInstance)
, and startRemakingPastMatches()
to reset it. The MatchableByNumberFactory
would have a field to track which ID number it's on.
Ok, but how do we tell Java that the MatchableFactory
we're passing in happens to create objects of type T extends Matchable<T> & Comparable<T>
?
How about instead adding those three methods above as static factory methods required by the Matchable
interface? So (once we wrote the implementations in MatchableByNumber
), we would do something like:
MatchableByNumber mbn1 = MatchableByNumber.createUnmatchedInstance();
MatchableByNumber mbn2 = MatchableByNumber.createInstanceMatching(mbn1);
// ...
MatchableByNumber.startRemakingPastMatches();
...and then pass MatchableByNumber
in via a Class<T>
to whatever method is building the sock list? With type bounds, like:
private <T extends Matchable<T> & Comparable<T>> List<T> makeListOfComparableMatchables(Class<T> implementation, int howMany)
{
T comparableMatchable1 = T.createUnmatchedInstance();
// ...And so on.
}
...and hopefully passing in MatchableByNumber.class
will resolve T
to be MatchableByNumber
and we're golden.
Trying a type parameter for the whole SockPairerTester
class since it's used by multiple functions. That way, I can specify it when instantiating a new SockPairerTester<Whatever>
instead of via type inference by passing in a Class<T>
argument.
Ok, the new hotness is: <M extends Matchable<? super M>>
-- i.e., it's Matchable
with objects of its own type as well as of parent types up to some ancestor. I'm still not sure how to grab that ancestor and use it as a second type parameter unless I were to specify it -- i.e., I can't do <M extends Matchable<T super M>>
.
1a657f1a394f8f23a6f1af1cde7c245f29b6afac
I also implemented something similar to the static factory methods mentioned above according to the pool of objects pattern. 414140d08a296e132a137eb46532836a69ddcfc1
And I think fixed some other type parameter / generics stuff so that everything is happy now. eb72ec0b8cf9274554b7022993c28cf3e2a8f0a9
Original Issue scope: Rename MatchableImplementation to ImplementsMatchable? But... ...on the other hand, doesn't it get defined as
extends Matchable
at one point?