Hi all, First of all I very much agree with Gael. The discussion is not about a Singleton pattern.
Secondly, similarly as @Timo and @Gael I find the pattern very confusing. Each time I see it I have a hard time figuring out why there are no enumerations in the enum. This is my preference though. Best, Dawid On 25/09/2020 11:42, Gaël Renoux wrote: > Hi > > One small remark here: you should not call this a Singleton. For most > people, a Singleton would refer to the implementation of the GoF Singleton > pattern, where you have a single instance of the class (see for instance > the corresponding Wikipedia page: > https://en.wikipedia.org/wiki/Singleton_pattern#Java_Implementation_[7]). > Your discussion is about a non-instantiable class (containing only static > methods). > > As for the choice between the two, the private constructor pattern seems > much more intuitive to me. If using enum, I think you need to impose some > documenting comment to explain the dangling semicolon (it's very weird to > coders unfamiliar with the pattern). > > Gaël Renoux > > On Fri, Sep 25, 2020 at 11:38 AM Timo Walther <twal...@apache.org> wrote: > >> Hi, >> >> honstely, I find using enums is more of a hack. `enum` stands for >> enumeration and is meant for listing flags or options. Using it for >> singleton patterns is just abusing a concept due to certain >> implementation details and less code. >> >> I feel this topic is like using Lombok for generating hashCode/equals. >> It means less coding but introduces another dependency and abuses the >> annotation processor. I would rather use the Java language according to >> the author's intention. >> >> Regards, >> Timo >> >> On 25.09.20 11:22, Piotr Nowojski wrote: >>> Hi, >>> >>> I don't mind one way or the other. >>> >>> I guess enum way is somehow safer, however did we really have any issues >>> with our current approach with `private` constructors? I mean, you are >>> mentioning that using reflections could overcome private constructors, >> but >>> is that a real concern in our code base? Has this caused some concrete >>> issues? If I would be reviewing a code doing things like this (or >> generally >>> speaking using reflections in the first place for anything), one should >>> better have a really good excuse :) >>> >>> So all in all, I would be +1 for allowing `Enum`, -0.1 for banning >>> `private` constructors approach, but I also wouldn't mind sticking with >>> `private` constructors for the sake of consistency if the majority of the >>> community has strong feelings against using enums. >>> >>> Piotrek >>> >>> pt., 25 wrz 2020 o 10:22 Yangze Guo <karma...@gmail.com> napisał(a): >>> >>>> Hi, devs, >>>> >>>> Recently, in the PR of FLINK-19179[1], we have a discussion about how >>>> to implement singleton pattern in Flink. >>>> >>>> Currently, most of the utility classes implement singleton pattern >>>> through the private constructor. Seldom utility classes leverage the >>>> enum mechanism. From my perspective, leveraging enum mechanism is more >>>> simple and it can also overcome reflection. >>>> >>>> Whether using enum classes or private constructors, it will be good to >>>> align the approach to achieve singleton in the whole Flink project. >>>> >>>> I would propose to leverage the enum mechanism in the Flink to >>>> implement singleton pattern and append it to the code-style >>>> guidelines. We may also have a JIRA ticket to refactor the existing >>>> code. >>>> >>>> What do you think? >>>> >>>> [1] https://github.com/apache/flink/pull/13416 >>>> >>>> Best, >>>> Yangze Guo >>>> >>
signature.asc
Description: OpenPGP digital signature