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 > >> > > > >
