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?
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?
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. ...
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.
"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?
For me the static way is working swell. It does exactlly what I want. Till I find a better solution, I will use static :-)
[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.
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.
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.
I used static instead, worked swell :-)
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.You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here.
Flag this post as spam/abuse.
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).
[quote user="goo"]
[/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.
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.
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?
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
|
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.