FilipMalczak
commented
7 years ago I like the idea, though I see need for some details.
As far as I can see, handling of @Factory(T) annotation would look like this:
- find all instantiable subclasses/implementations of
T - for each subclass: 2.1. for each public constructor 2.1.1. generate public static method named the same way as the subclass and with the same argument list as constructor (alternatively, as you've shown - use builders, it doesn't matter for example's case)
The problem is in (1) - where do you look for them?
a. in the same package as annotated class (what with inner classes? should we look only through the same scope, so only in outer class, or maybe in the most outer class and all below, or the package in which the most outer class is?)
b. in currently compiled sources
c. in the whole classpath
d. add argument to annotation: @Factory(T, scanPackages: String[], scanClassPackages: Class[]) in similiar fashion as in Spring Boot; if both scan... argument are missing, we may then fall back to some variant of (a), (b) or (c).
I would propose (d) with fallback to (b) (though this may be tricky, so maybe to (a) - with the scope of whole package and its subpackages). This way it would be configurable, and would have an easy to understand fallback.
Another idea for this pattern would be grouping common constructor parameters, but it would need some questions answered too and I'm not really sure if that's a good idea:
@Value
class abstract Autobot extends Transformer {
int healthPoints;
}
@Builder
@Value
class Optimus extends Autobot {
}
@Builder
@Value
class Bumblebee extends Autobot {
}
...
------------------------
@Value
class abstract Decepticon extends Transformer {
boolean lovableVillain;
}
@Builder
@Value
class Megatron extends Decepticon {
}
@Builder
@Value
class Soundwave extends Decepticon {
}
...
------------------------
@Factory(Autobot.class)
class Autobots {}
@Factory(Decepticon.class)
class Decepticons {}
//
// vs. Vanilla Java
//
class Autobots {
private final int healthPoints;
//constructor
public static Optimus.Builder optimus() {
return Optimus.builder().healthPoints(healthPoints);
}
public static Bumblebee.Builder bumblebee() {
return Bumblebee.builder().healthPoints(healthPoints);
}
// ...
}
class Decepticons {
private final boolean lovableVillain;
//constructor
public static Megatron.Builder megatron() {
return Megatron.builder().lovableVillain(lovableVillain);
}
public static Soundwave.Builder soundwave() {
return Soundwave.builder().lovableVillain(lovableVillain);
}
// ...
}
wheredevel
punkratz312
bobdrad
brant-hwang
janrieke
randakar
burdoto
@Factoryis a new annotation I would like to propose .Many times, I find it very convenient to have all siblings of a parent class/interface/annotation a) enlisted (great for code assistance) and b) ready for construction. In vanilla Java - I have to either remember all those siblings, or use IDE's method do rediscover them over-and-over again, or create and maintain a corresponding Factory class manually. The Factory class is responsible for building (assuming
@Buildannotation) instances of those (non-abstract) siblings.It would be much more convenient to have that Factory class, created by Lombok! (Moreover, to turn the parent class itself into the siblings factory!)
I show this in the example below.
Sources:
List of The Transformers