The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Object Oriented Design question

Hello, when doing OO design, does it make sense to create a class to represent something that will only have 1 ONE instance at any given time in the application run?  Thanks.
Gonças
Thursday, March 22, 2007
 
 
if it makes sense to encapsulate a group of related data and functions.
onanon
Thursday, March 22, 2007
 
 
How else would you do it?

You should look into the Singleton Design Pattern
Jay
Thursday, March 22, 2007
 
 
"How else would you do it?"

Not use OOP. Dont find it very intuitive to have a "class" that will only have one instance. Why use a class if you only have one "car" in the system? Thanks.
Gonças
Thursday, March 22, 2007
 
 
There may be only one car in the system but it still has state and behaviour, doesn't it?
John Topley Send private email
Thursday, March 22, 2007
 
 
Yes. A structure can handle the state and functions can handle the behaviour.
Gonças
Thursday, March 22, 2007
 
 
John Topley has it right. And Jay has hit the nail on the head - Singleton is what you need.
DJ Clayworth
Thursday, March 22, 2007
 
 
Aren't classes themselves objects with only a single instance?
Steve Hirsch Send private email
Thursday, March 22, 2007
 
 
What makes a class so painful you wish to avoid it?

And you'll definitely have more than once instance when testing, so it's generally not a good design to assume only one instance can run in the class itself. Make another class where you access the common instance.
son of parnas
Thursday, March 22, 2007
 
 
I don't think what you've indicated motivates a singleton pattern.  The singleton pattern is only useful when a global variable should only be initialized if needed.  Most people suggesting a singleton in this case are mistaken about your needs.

But if you have state associated with the functions, it should be a class.  If the functions don't require state to work, they should be helper functions in a single namespace (though it is acceptable to put them in a stateless class as well).

Thursday, March 22, 2007
 
 
Class is better - Intelli-sense will help you write your code.
No need to be afraid of global variables. Make an instance of that
class global and access it from anywhere.
asmguru62 Send private email
Thursday, March 22, 2007
 
 
If your using C++, probably better not to make a global instance, but instead use static member functions.

Thursday, March 22, 2007
 
 
Mark your class as "static"

I don't like singleton pattern, it looks like ugly hack.
lubos
Thursday, March 22, 2007
 
 
You're right that a lot of the times Singleton is used then a  class with all static variables and methods will work as well. You need Singleton if there is some initialization that you need to take before the first access to the class, which you don't want to take if the class is never accessed; such as initializing a singificant number of variables, allocating memory or initializing external resources.
DJ Clayworth
Thursday, March 22, 2007
 
 
Which I stated in my origional reply.  Not to get into a debate about it, but the singleton pattern does what you say.  But it also indicates the object is final. 

Also the object is defining the policy of HOW it can be created.  This limits flexibility.

Instead of using a global variable, why not create a factory class for your would-be-singleton which caches an instance of the singleton as a static variable. 

Ideally you would create an instance of the factory to control the dependencies explicitly, but hey, this way retains the globalness, delayed initialization, and shared instance properties of your would-be-singleton without any of the inflexibility.

The singleton is a global variable.  Global variables increase dependencies in the program, increasing maintenance costs.  They are effective in some cases to speed up development in the near term, but fail to do so in the long term.  Good policy is to avoid them.

Thursday, March 22, 2007
 
 
The question is related this one: Why use a subroutine that is going to be called in only one place?

Organisation.  It is possible that it will be used more later, too.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Thursday, March 22, 2007
 
 
Subroutines are a different thing. My problem is with OO usage and overusage. I dont see the problem of using some classes but I think its weird to create a whole system based on classes, even for conceptual stuff that in realily isnt an object or stuff thats just helper code.
Gonças
Friday, March 23, 2007
 
 
Why? Because the whole design gets more complicated with classes and classes going into the class diagram and code.
Gonças
Friday, March 23, 2007
 
 
To cite from your original question: "when doing OO design". If you don't put it into a class, will it still be OO design? To cite another sentence from you: "Not use OOP."

Maybe you should first decide what you want -- consistent OO design or some mixed hacking? The decision may result in the answer to your question.
Secure
Friday, March 23, 2007
 
 
Do you put all of your code into a single source file?  At the most basic level, classes are merely a way to organize your code.  Which functions do you group together?  In an OO approach this is answered by grouping functions that operate on the same piece of data into a unit, a class, a file.

Personally, I prefer using class organization rather than the previous functional decomposition method.  The latter invariable resulted in page long (and longer) functions where the quantity of lines of code simply overwhelmed the brain.

If you choose to use a different method to organize your code, that is your choice.  I like, however, having a library of related functions at hand whenever I need to deal with a specific data type.
Wayne M.
Friday, March 23, 2007
 
 
Most web apps I have worked on have a large number of singletons.  A few examples -

data access objects
service locators
stateless business service objects

In fact, the only things that aren't singletons are those that contain stateful information that can't be shared between different users/applications/etc..

Good luck ..

Eric
Eric Knipp Send private email
Friday, March 23, 2007
 
 
I had the same problem once, and solved it by implementing the Singleton pattern.  the only catch with the singleton is the fact that the object you are creating is unique through the applications, and since web ASP.NET web applications run on a Multi Threaded Appartment you might run into the problem of deleting the object that is to be used by a diffent process.  again the solution to this proble is to use local variables in the singleton constructor to avoid non-referenced objects, and the local variable can be deleted or unreferenced quite safely.
Driss Selhoum Send private email
Sunday, March 25, 2007
 
 
As a general rule, singleton = bad.

Obviously I have expanded on this point previously in this thread.  But sufficient to say, as you are just learning, avoid getting into the (bad) habit of using singletons!

If you want to have a completely object centered design, those methods need to go in a class, though you can make the methods static so you don't need an instance of the class.

However, if you can get away with making them all static, then you are really just using the class as an encapsulation barrier and should probably stick with wrapping them in a namespace.

Sunday, March 25, 2007
 
 
I can imagine the original poster of this thinking that this has all got really complicated, and deciding to stick with the globals because they understand that, and it works.

Classes with only one instance? I use them all the time. What advantages do they have?

You still get all the encapsulation advantages of a class. You can hide your data members, build function-based interfaces etc.

You also get the naming advantages of a class. Doubtless all your existing global variables have some commonality. Organise them into sensible blocks of common purpose and structure.

If you use a class, you will be trivially able to make multiple copies of it should you ever be faced with the need to do that. Even if it doesn't seem likely today. With the global variables solution you'll be faced with all manner of pain if you have to move to multiple copies later.


I don't agree that 'singleton' is necessarily the way to go here. Most of the time when you only need one instance of a class, it's perfectly OK just to make that one instance without bothering to ENFORCE that there is just one instance.

In fact Singleton, for me, offers two almost completely distinct services.
1. Enforce that there is only a single instance of a particular class.
2. Provide a convenient way of accessing that class from ANYWHERE - just like a global variable.

Most of the time when you just happen to have a single instance of a class, you don't need the first of these, and the second one just acts as a back-door access mechanims to the one object everywhere, which can really spoil your program structure.
Duncan Sharpe Send private email
Sunday, March 25, 2007
 
 
To pick up your 'car' example. In your case, I would make a 'car' class, and just have a single instance. I wouldn't make it a singleton because it is perfectly sensible to have several cars - it's just not what you happen to be doing right now.

I would make a car class, and give it a set of interface functions. The code inside these functions looks pretty similar to the way your global code would look. And the data in the car class will be quite similar to the global data you were thinking of creating. The pain of doing this instead of the globals is very low.

What do you win? If your application is really really tiny, probably not much. As it grows, however, you will discover parts of your program that don't really need to know that the program is about a car. With a 'car' class, you will be able to write functions and classes that aren't part of the car class. By design, these will know nothing about the car, and are incapable of altering the car. This is good - it stops those parts of the program from breaking the car! With globals, you can't do that.

The general rule of software is that small programs are much easier than big ones. The more you can do to keep your big program looking like a set of small ones, the easier it is to look after it. Divide and conquer. And OO is just one way of doing the dividing.
Duncan Sharpe Send private email
Sunday, March 25, 2007
 
 
Replying to blank

"Instead of using a global variable, why not create a factory class for your would-be-singleton which caches an instance of the singleton as a static variable."

Isn't caching an instance of your class as a static variable exactly what a Singleton does? The Singleton is its own factory.
DJ Clayworth
Tuesday, March 27, 2007
 
 
"Subroutines are a different thing. My problem is with OO usage and overusage. I dont see the problem of using some classes but I think its weird to create a whole system based on classes, even for conceptual stuff that in realily isnt an object or stuff thats just helper code."

They are quite similar.  They are ways of organising code.  I have seen subroutines overused in the same way.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Tuesday, March 27, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz