Re: [riena-dev] Riena-Singletons

[Elias Volanakis <elias@xxxxxxxxxxxxxxxxx>]

With regards to API changes, my opinion is that we should remain as
conservative as possible. Would it be possible to share some
information about the impact of the suggested changes (i.e. where
would API break) ?

Just my 2c,
Elias.

On Tue, Sep 7, 2010 at 12:35 AM, Liebig, Stefan
<Stefan.Liebig@xxxxxxxxxxxx> wrote:
> 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
> Gesendet: Montag, 6. September 2010 15:18
> An: Riena Developers list
> Betreff: Re: [riena-dev] Riena-Singletons
>
>
>
> 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
>
>
>
>
>
> -------------------------------------------------------------
> compeople AG
> Untermainanlage 8
> 60329 Frankfurt/Main
>
> fon: +49 (0) 69 / 27 22 18 0
> fax: +49 (0) 69 / 27 22 18 22
> web: www.compeople.de
>
> Vorstand: Jürgen Wiesmaier
> Aufsichtsratsvorsitzender: Christian Glanz
>
> Sitz der Gesellschaft: Frankfurt/Main
> Handelsregister Frankfurt HRB 56759
> Ust-Ident.-Nr: DE207665352
> -------------------------------------------------------------
>
> <ATT00001..c>
>
>
>
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
>
>



-- 
Elias Volanakis | Technical Lead | http://eclipsesource.com
elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | @evolanakis