A solution to the final classes problem
Randahl Fink Isaksen
randahl at rockit.dk
Tue Sep 4 02:41:02 PDT 2012
Werner, you are right – in some cases, that could be a solution. In my case, however, I need to implement additional interfaces in the subclass to fully leverage the advantages of our JavaFX-based framework.
I would also like to add that it seems less like traditional object oriented Java, to have to use a second class to construct the first class, which is why in general I prefer not to use that pattern.
It is sometimes a solution, yes, but I do not think it is optimal.
On Sep 4, 2012, at 11:31 , Werner Lehmann <lehmann at media-interactive.de> wrote:
> On 04.09.2012 09:11, Randahl Fink Isaksen wrote:
>> Wonderful. I have created the first Jira issue here:
> ...about makeing FileChooser non-final. Just for the record: your usecase seems to be FileChooser customization in the constructor (a constructor you want to override). An alternative to this could be a factory method:
> public static FileChooser createMyFileChooser()
> FC fc = new FC
> return fc
> Something similar would work in FXML with a builder class. If necessary it could use a map and thus avoid having to delegate each and every FileChooser property.
More information about the openjfx-dev