A solution to the final classes problem

[Randahl Fink Isaksen]

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.

Randahl



On Sep 4, 2012, at 11:31 , Werner Lehmann <lehmann at media-interactive.de> wrote:

> Hi,
> 
> On 04.09.2012 09:11, Randahl Fink Isaksen wrote:
>> Wonderful. I have created the first Jira issue here:
>> 
>> http://javafx-jira.kenai.com/browse/RT-24692
> 
> ...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
>  fc.setThis
>  fc.setThat
>  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.
> 
> Werner