Design and Architecture

DavidNohejl4-Sep-07 7:28

DavidNohejl

4-Sep-07 7:28

"one of the case you can use singleton pattern is to create a connection for your data base application."

Ok, if I was asking about singletons this wouldn't help me. In that I agree with you. But I believe that he is talking about scenario when you have class that manages connection to db, and creates connection in constructor. If that class is singleton, only one instance is created, so only one connection is created (which is usually very expensive operation). But then there's a pooling and you will have connection opened for whole lifetime of the singleton object, sometime you'll connect to db even when you don't need to etc. Which is why I say this is not the supercleanest use of singleton pattern.

[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe

led mike4-Sep-07 7:35

4-Sep-07 7:35

dnh wrote:
Which is why I say this is not the supercleanest use of singleton pattern.

It's a perfectly fine design when the use model is a single user desktop application connecting to a desktop database. Your post also lacks specific use model information required to draw any conclusion as to the accuracy of your statement.

DavidNohejl4-Sep-07 7:49

DavidNohejl

4-Sep-07 7:49

led mike wrote:
It's a perfectly fine design when

Isn't that little word "when", and what follows it, proving my point? (but then again, I've just came from work Sleepy | :zzz:

)

led mike4-Sep-07 5:03

4-Sep-07 5:03

shakeela wrote:
i want applicable knowledge in application development.

That is "experience" and we can't give that to you.

Colin Angus Mackay4-Sep-07 9:13

Colin Angus Mackay

4-Sep-07 9:13

shakeela wrote:
I want to know in which scenario we are using singleton pattern

When dumped by ones girlfriend or significant other.

Upcoming FREE developer events:
* Glasgow: Agile in the Enterprise Vs. ISVs, db4o: An Embeddable Database Engine for Object-Oriented Environments, Mock Objects, SQL Server CLR Integration, Reporting Services ...

My website

Colin Angus Mackay4-Sep-07 13:08

Colin Angus Mackay

4-Sep-07 13:08

shakeela wrote:
I want to know in which scenario we are using singleton pattern in our appl

Here is one scenario[^]

But, my plans for this series will remove the singleton pattern later.

Urs Enzler4-Sep-07 21:37

4-Sep-07 21:37

I consider singletons as evil!

If there has to exist really one one instance of a class then I use a manager pattern (don't know if this patter has a real pattern name):

I request the "singleton" from a Manager that will return me the instance. Depending on configuration and other things it will return me a singleton or a new instance. Furthermore I request interfaces which allows the replacement of "singletons" either for testing (mocks) or changed requirements or if it is a base functionality that is used in different projects.

Much more flexible.

-^-^-^-^-^-
no risk no funk ................... please vote ------>

Colin Angus Mackay5-Sep-07 4:35

Colin Angus Mackay

5-Sep-07 4:35

Sounds like you are using the Factory Pattern to generate the singleton.

Urs Enzler wrote:
Furthermore I request interfaces which allows the replacement of "singletons" either for testing (mocks)

Very useful for that.

Urs Enzler5-Sep-07 4:40

5-Sep-07 4:40

I'm not sure what the exact name is, because a Factory is something that instanciates objects for me, but a manager does that and manages the instance. If I request the same interface I'll get the same instance.

-^-^-^-^-^-
no risk no funk ................... please vote ------>

led mike5-Sep-07 6:24

5-Sep-07 6:24

Urs Enzler wrote:
I consider singletons as evil!

It's just a "Creational Pattern", there are many, your situation calls for a different one. That does not provide reasoning for declaring the Singleton to be "Evil". However there are plenty of arguments about it on the WikiWikiWeb.

Urs Enzler5-Sep-07 7:04

5-Sep-07 7:04

Yes of course, I'm a bit exaggerating Smile | :)

The main reason I'm not a fan of the singleton pattern is because it is overused.

1)
The decision that something exists only once in an application is a very final one. Normally singletons are very basic things in an application (a logger for example). And if that changes (happend about three times to a project I was working in) it is very hard to refactor (because of point 2)

2)
It is often the case that projects using singletons are not loosly coupled: components reference the singleton by something like MySingletonClass.Instance. I consider this very limiting. In an earlier post I mentioned that I use a Manager pattern (or Factory pattern) that allows me to exchagne the real object behind the "singleton" for example for testing (mocks).

3)
In a framework or in a base components library, you should definitly not use singletons because they can not be replaced by project specific instances.

Because of these reasons I prefer using a manager pattern (Factory pattern) because it is not really more complicated but very much more flexible and not limited.

And as a final word: yes there are situations where the singleton pattern is adequat, but they are seldom in my eyes or there exists a better pattern for the scenario.

-^-^-^-^-^-
no risk no funk ................... please vote ------>

led mike5-Sep-07 7:27

5-Sep-07 7:27

Urs Enzler wrote:
The main reason I'm not a fan of the singleton pattern is because it is overused.

not laughing at you. It made me think, well duh software development is ~~overused~~ misused, and pretty much everything in it is misused. Big Grin | :-D

You should see how some of my peers abused the word "Agile" Laugh | :laugh:

Urs Enzler wrote:
Because of these reasons I prefer using a manager pattern (Factory pattern)

You probably know this but there are many more creational patterns[^]

Urs Enzler5-Sep-07 7:51

5-Sep-07 7:51

led mike wrote:
You probably know this but there are many more creational patterns[^]

Unfortunately, this page does not mention the kind of pattern we are using. Maybe this is because it is actually a Factory (instance creation) but with managing functionality Smile | :)

May the crusade for good design continue ...

-^-^-^-^-^-
no risk no funk ................... please vote ------>

led mike5-Sep-07 8:07

5-Sep-07 8:07

Urs Enzler wrote:
but with managing functionality

"managing" would be structural.

Urs Enzler wrote:
Depending on configuration and other things it will return me a singleton or a new instance.

It is difficult to understand that with any certainty. Perhaps you are using both Factory and Flyweight[^] Patterns. Or perhaps you are referring to a higher level abstraction of both into a Composite or Facade. I can't tell.

Urs Enzler5-Sep-07 20:19

5-Sep-07 20:19

Hmm, I'd say it is as you say a higher level of abstraction and containing several individual design patterns.

I think I should write an article about that, that would make the discussion easier Wink | ;)

-^-^-^-^-^-
no risk no funk ................... please vote ------>

Re: singleton pattern example [modified]

hotcodeking5-Sep-07 1:58

hotcodeking

5-Sep-07 1:58

Hi Dear

as theory says singleton use is for making one instance available throughout the life time of application

As far as scenario is concerned the dbconnection is bad one as some one said becos of pooling. You can think of salary being credited and debited to employee accounts in banks. you can make sure this operation is implemented using singleton class can also make sure only the manager or single person in bank has access to this class.

Gokul- MCSD:MCAD:MCP - Technical Lead - GFT INDIA

ElSpinos13-Sep-07 23:00

ElSpinos

13-Sep-07 23:00

Greetings Shakeela,

The Singleton design pattern serves to describe an implementation that restricts instantiation of a class to one object, in other words no copies or additional references. I've created a Singleton instantiate for you here to experiment with and get an idea of my description above. the singleton design pattern also belongs to the Creational Patterns group which consist of the following additional design patterns:

o Abstract factory pattern: centralize decision of what factory to instantiate
o Factory method pattern: centralize creation of an object of a specific type choosing one of several implementations
o Builder pattern: separate the construction of a complex object from its representation so that the same construction process can create different representations
o Lazy initialization pattern: tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed
o Object pool: avoid expensive acquisition and release of resources by recycling objects that are no longer in use
o Prototype pattern: used when the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) is prohibitively expensive for a given application

The singleton class you can experiment with:

<br />
 /// <typeparam name="Type">Any type with a public and parameterless constructor.</typeparam><br />
 public sealed class SingletonCreator<Type> where Type : class, new()<br />
 {<br />
<br />
  #region Private declarations<br />
  /// <summary><br />
  /// The instance to retain after creation<br />
  /// </summary><br />
  private static Type instance;<br />
  #endregion<br />
<br />
  #region Properties<br />
  /// <summary><br />
  /// A lazy instance instantiator property.  It will test for the existence of an object and return that reference otherwise it will create a new object.<br />
  /// </summary><br />
  /// <returns>An singleton instance of type "Type".</returns><br />
  public static Type GetInstance()<br />
  {<br />
   lock (typeof(Type))<br />
   {<br />
    if (instance == null)<br />
    {<br />
     instance = new Type();<br />
    }<br />
    return instance;<br />
   }<br />
  }<br />
  #endregion<br />
<br />
 }<br />

Usage:

<br />
// This will always create an instance it it doesn’t exist or return the <br />
// existin reference if it was previously called.<br />
MyClass myClass = SingletonCreator<MyClass>.GetInstance();<br />

I hope this helps you in your quest to learn design patterns Wink | ;)

Have an awesome weekend...

Fernando Mendes
Senior .NET Developer, Architect

Applications communication

etkid8421-Sep-07 3:02

etkid84

21-Sep-07 3:02

singletons are used when it only makes sense to have exactly one and only one of them... i am not sure the impact singletons have on multi-threaded apps either, you might want to do some research in that area as well.

design patterns are an interesting concept... i always stick to the kiss principle.. and avoid over-engineering my code.

sometimes you can get into trouble with singletons, because sometimes they are implemented with private a constructor and destructor, and some example implementations you find on the web have nearly undetectable flaws ... there are variations to this theme between java and c++, and i am not sure about python (or whether you even need to do it in python).

be cautious and judicious in your decision making,

kind regards,

David

Yoav Zur28-Aug-07 19:18

Yoav Zur

28-Aug-07 19:18

Hi,

I need to develop three applications over LAN. One is the core application, written in C++ and the other two are clients application.
The two clients application are GUI for the core application, they don't run on the same machine.
Can you advise me what kind of technology to use for communication between them?
I prefer to write the GUI application in C# or V.B .Net

Thanks

Yoav Zur

Re: Applications communication

led mike30-Aug-07 4:43