Implementing a singelton

Posted by goo on 01-Dec-2017 04:45

OE11.7

I found this in KB: https://knowledgebase.progress.com/articles/Article/P159909

Is this the way of implementing a singelton ? I would like to get ridd of the instance part...  

<myclass>:instance:<Method>().

or is that not possible?

All Replies

Posted by Mike Fechner on 01-Dec-2017 04:50

Singletons require something like that.
 
What’s your use case? There may be more elegant solutions than a singleton. A singleton combines implementation and registry. A caller needs to know the implementing class. Singletons are not mockable when unit-testing etc..
 
For many use cases something like the CCS Service Manager is a better solution.

Posted by goo on 01-Dec-2017 04:58

hmmmm. now I am more confused... I would like to have a class that lives the Whole session and is only started once. Keeping general info for me.

Is there other ways of getting this?

Posted by Jeff Ledbetter on 01-Dec-2017 06:49

That is how we've done it:

/*
 caller
*/
define variable depot as repository.content.Depot no-undo.
depot = repository.content.Depot:Instance.

/*
 class
*/
class repository.content.Depot use-widget-pool:
define public static property Instance as class repository.content.Depot no-undo
get.
private set.

constructor private Depot ():
end constructor.

constructor static Depot ():
Depot:Instance = new Depot().
end constructor.

...

Posted by Peter Judge on 01-Dec-2017 08:12

Singleton just means “one and only one running at a time”. Nothing more.

The static-class-property-named-instance is just one way of making sure there’s only one instance  and of getting access to it – and to my mind arguably the *worst* way of doing it.

I totally agree with Mike’s arguments and also that something like a service manager is a far better way of dealing with this. Yes, it’s more complex, and more code,  and usually more abstract/generic. BUT the benefits (to me) far outweigh the costs.

Posted by Jeff Ledbetter on 01-Dec-2017 08:16

"The static-class-property-named-instance is just one way of making sure there’s only one instance  and of getting access to it – and to my mind arguably the *worst* way of doing it."

Why's that?

What are the benefits of the more complex and more code methodology?

Posted by goo on 01-Dec-2017 08:31

For me the static way is working swell. It does exactlly what I want. Till I find a better solution, I will use static :-)

Posted by marian.edu on 01-Dec-2017 09:39

[quote user="Jeff Ledbetter"]

What are the benefits of the more complex and more code methodology?

[/quote]

because it looks more ‘enterprise’ ready :)

the only problem with static is it’s really annoying in development, especially if an application server is involved, and then once started that path peoples have the tendency to abuse it just because it’s easy… the CCS uses static as well so you can say you’re in a good company.

just like the communities forum that rejects my posts, let’s see if no ‘disturbing’ links make it easier to get through… or it’s just my company email that it is ‘moderated’ :(

it turns out none of my accounts let me post by email so probably just having a bad day... damn I do miss the good old days when peg was around.

Posted by Jeff Ledbetter on 01-Dec-2017 09:42

We aren't OO experts around here so I am hoping that someone will edify me. We implemented the static methodology but it has been a few years. If there is a better way, I would love to learn what it is and why.

Posted by Tim Kuehn on 01-Dec-2017 09:49

An alternative is to instantiate a class at the start of the session and then pass it to the constructor of every object created in the session and save the reference to that 'singleton' inside the class. This'll give it the session-wide scope that's needed w/out using statics at all. It's a bit of a pain to implement but it gets the job done.

I'll agree that statics are a pain - I first used them when I was getting going in OO - not so much anymore for exactly the reasons Jeff mentioned.

Posted by goo on 02-Dec-2017 03:29

I used static instead, worked swell :-)

Sendt fra min iPhone

1. des. 2017 kl. 11:51 skrev Mike Fechner <bounce-mikefechner@community.progress.com>:

Update from Progress Community
Mike Fechner

Singletons require something like that.
 
What’s your use case? There may be more elegant solutions than a singleton. A singleton combines implementation and registry. A caller needs to know the implementing class. Singletons are not mockable when unit-testing etc..
 
For many use cases something like the CCS Service Manager is a better solution.

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

Posted by goo on 02-Dec-2017 03:29

Yes, and that is with use of instance….
 
So either you add a definition in each program you want to call depot, or you will have to use repository.content.Depot:instance:myMethod().
 
In my code, I uses that form, in example myLogging:instance:addLog(…..).
 
I found by changing the singleton class to a static class, I know can write
 
myLogging:addLog(…).
 
Perfect &#128522;
 
Thanks
 

Posted by marian.edu on 02-Dec-2017 03:29

Well, as Mike said you can use a manager (factory) to provide you such an instance and then it’s the manager/factory job to make sure it’s only one alive in the session - this will not stop one to create a new instance using new (static or dynamic).


Using the ‘singleton’ approach it’s the object responsibility to make sure it can only be one instance active, for that you do need at least one static property/method to give you that instance so then the ‘static’ part of the class will be there once loaded, a pain in the … on development environment :(

If you only need that to keep state (shared variables anyone) then you can just go with pure static properties and forget about singleton, but then again maybe it’s time to think about some session/context manager to help you keep ‘global state’.
 
Marian Edu

Acorn IT 
+40 740 036 212

Posted by Peter Judge on 02-Dec-2017 03:29

Singleton just means “one and only one running at a time”. Nothing more.
 
The static-class-property-named-instance is just one way of making sure there’s only one instance  and of getting access to it – and to my mind arguably the *worst* way of doing it.
 
I totally agree with Mike’s arguments and also that something like a service manager is a far better way of dealing with this. Yes, it’s more complex, and more code,  and usually more abstract/generic. BUT the benefits (to me) far outweigh the costs.
 

Posted by Mike Fechner on 02-Dec-2017 03:29

I provided one earlier:
 
Being Mockable in unit-tests.
 
Or allowing for customizabiliy.
 

Posted by Peter Judge on 02-Dec-2017 03:29

In addition to Mike’s comments: you can’t require the Instance property to be there since static members cannot be part of an interface (so you rely on doc or tribal knowledge, which is ok-ish).
 
You can hide the instantiation inside the Instance property’s gettier (and call a service manager etc) but at that point the static property is just a wrapper and you should (IMO) be calling the Service Manager (IOC container/what have you) directly.
 

Posted by Matt Baker on 02-Dec-2017 03:29

 
The problem with statics is the tight binding.  OO is all about loose coupling.  As soon as you use a static…you lose interfaces, you get tight binding, you lose abstraction, you lose service injection, you lose a lot of the capabilities of generics, you hard-code your dependencies, you make mocking difficult to impossible…and so on.
 
Service implementations like OSGI, eclipse platform, and so-on make use of either registered services.
 
Then you have dependency injection frameworks like spring and J2EE.
 
OSGI and eclipse have both gone towards a mix of dependency injection, but use the injection of registered services. 
 
 

Posted by goo on 05-Dec-2017 06:20

For us that is not that familiar with oo, I am still a bit confused.
 
Singelton:
I need to use i.e. class:instance:method()/properties to use it. To be honest, it is just for that I find it a bit fussy.
 
Static
Is loaded into session, is a pain when in development since I need to restart session when testing. Other than that, it works more than swell. Nice to read and it does what I need it to do.
 
I haven’t taken the step into interface/abstract/ etc… that’s another ballgame. I believe I need to crawl before I can walk &#128522;
 
What Mike/Peter talks about is a bit unclear for me:
  • A singleton combines implementation and registry.
    • If I understand that correct, it is because it is NEW’ed in the class first time it is refered?
  • A caller needs to know the implementing class”
    • What do you mean?
  • Singletons are not mockable when unit-testing etc..
    • This is for next level oo &#128522;

 

 
Are there examples regarding other, better ways of doing this?
“….There may be more elegant solutions than a singleton.”
 
 
//Geir Otto
 

Posted by Tim Kuehn on 05-Dec-2017 08:15

[quote user="goo"]

  • Singletons are not mockable when unit-testing etc..
    • This is for next level oo &#128522;

[/quote]

Better to look at this now before you spend too much time / effort going down the "static" road and then finding out you need to replace that work with something else. 

Posted by Peter Judge on 05-Dec-2017 11:52

You can store the value of class:instance in a variable/temp-table field/property etc.

The point of it is that there's one and only one instance of the object running and any given time.

The "advanced" stuff is really around how you make sure that the above sentence is true. The static property/method approach is the simplest but it's not the only way of doing things.

Posted by Kim Ward on 06-Dec-2017 04:49

Is the CCS Service Manager Open Source? I'd be curious to see examples of how this works.

I am correct in understand that it is some for of dependency manager or perhaps a factory of sorts?

Posted by jankeir on 06-Dec-2017 05:03

There's not one CCS service manager, there can be many (by different vendors.) The only requirement is they follow the same interface. There is an example implementation here: github.com/.../CCS_Samples

Posted by Mike Fechner on 06-Dec-2017 05:06

A very basic sample …. &#128521;
Von: jankeir [mailto:bounce-jankeir@community.progress.com]
Gesendet: Mittwoch, 6. Dezember 2017 12:05
An: TU.OE.General@community.progress.com
Betreff: RE: [Technical Users - OE General] Implementing a singelton
 
Update from Progress Community
 

There's not one CCS service manager, there can be many (by different vendors.) The only requirement is they follow the same interface. There is an example implementation here: github.com/.../CCS_Samples

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

 

Posted by jankeir on 06-Dec-2017 05:21

Yes, but that is probably a good thing here a basic example has the advantage of showing the concepts without too much code (in fact, it's probably already a little more advanced than you would want just for the purposes of demonstration.)

As a response on the original question, many of the reasons why you may not always want a singleton (in the most traditional sense as a class with a private constructor and a public static instance accessor) can be found in the responses and links in this question: stackoverflow.com/.../why-is-singleton-considered-an-anti-pattern

Living completely without 'singelton' is pretty difficult at the moment (since we don't have the ability to add code to the ABL class loader to automatically populate objects with their dependences after instantiation and passing everything around everywhere isn't always realistic)  but limiting your self to Ccs.Common.Application whenever you can is probably a good idea.

This thread is closed