Re: [riena-dev] Riena-Singletons

["Liebig, Stefan" <Stefan.Liebig@xxxxxxxxxxxx>]

The biggest impact would be introduced when changing the LnfManager and the ApplicationNodeManager.

So, we have to decide which way to go: break APIs and having cleaner code or just go on as it is.

Tschüß,
Stefan

> -----Ursprüngliche Nachricht-----
> Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-
> bounces@xxxxxxxxxxx] Im Auftrag von Elias Volanakis
> Gesendet: Dienstag, 7. September 2010 18:15
> An: Riena Developers list
> Betreff: Re: [riena-dev] Riena-Singletons
> 
> 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
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev