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 >
