| Re: [riena-dev] Riena-Singletons |
|
Hi Christian, 1. I never said that 3. and 4. are the same. I just said that it
is possible to transform a 3. type singleton into a 4. type singleton 2. The "adding a field tomorrow" argument would make a
4. type to a 2. type singleton (which I do not like very much) However, I would like to reduce the clutter that we currently have
(breaking API :-(). After writing my first post I have also found a mixture of
3. and 4. (SWTBindingPropertyLocator), i.e. static method and getInstance(). I would prefer to only have type 1. and type 4. Type 1 if it has state and type 4 if is does not have state,
i.e. a utility which only consists of "functions". I think (opinion) if a utility gets later some state ("adding
a field tomorrow") it semantic/concern changes and that change should be
reflected either in refactoring the utility to a singleton or creating something
new. Tschüß, Stefan Von:
riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Campo, Christian Hi Stefan, not sure why 3 is the same as 4 and not the same as 1. The
fact that a singleton instance has fields or not is (I believe) something that
is a hidden implementation detail. If an implementation that is now 3
(getInstance() with no fields) could become a 1 (adding a field) tomorrow. A
fact that should be transparent to the user. (he should still be have his
pattern of calling getInstance().invokeMethod().... dont you think ? getInstance() should always have that name IMHO...... (I would call a 4 a Utility class and not a singleton, but
then I am not really good at patterns anyway) christian Am 06.09.2010 um 14:57 schrieb Liebig, Stefan:
Hi
Rienaers, While
working thru our code base I have detected several kinds of
"singletons" (some of them I would not call them a singleton): 1. the classical singelton - a single instance
of class (maybe created lazily or not) with the typical static getInstance()
method (sometimes it has a different name) with fields (state) 2. the static singleton - this a class with
only static methods and static fields carrrying some state 3. the pseudo classical singleton - a single
instance of a class with getInstance() but without fields (state) 4. the utility singleton - a class with only
static methods without fields (state) 1.
and 2. are "real" singletons (they have some state). At these
singletons we need to look a little bit closer when we also want to use them
within RAP. For them we can use SessionSingletonProvider and SingletonProvider. How
about 3. and 4., especially 3. ? Should
we transform 3 to 4 (no more getInstance(), just static methods)? Or
… Should
the getInstance() method always be named getInstance()? Opinions,
feedback, .. Tschüß, Stefan ------------------------------------------------------------- fon: +49 (0) 69 / 27 22 18 0
<ATT00001..c> |