iOS Instance methods or singleton class

mpramodjain said:

Hi,

A programming basic quest :

When to go with instance methods and singleton classes(I mean taking a static object of the class and use it all over the application).


To be clear, I have some methods which have the generic functionality (getting substring , height of the string, validating string is numeric or not... etc).

Now I can do in both the ways, but stuck on which way to go. I would prefer to go with singleton class object, because AFAIK it would allow me to access non-static variables too.

Please let me know which is the best way to go (other than the usage of non-static variable scenario).. memory and code size , performance issues.. or experience you had in reference to better code.

Also in reference to OBJ-C.

Thanks,
Pramod Jain

Click to expand...

I think the best method for actions like getting a substring and returning the height of a string (what is that, exactly?) is best implemented as a category extension to the NSString and NSMutableString classes.

Performance between using a singleton and using categories should be the same, and memory allocation and deallocation in singletons works exactly as with normal classes. Note, however, that a singleton's allocated memory is deallocated during the termination of the application. So be careful of what data you store in it.

Singletons are used in cases where we need to have specific Application-Wide methods and variables. So, optimally, each application in general has one or two singletons at most. Use them with great care because they can easily lead to spaghetti code. I use them as containers for references and convenience methods (getting the applications delegate's ManagedObjectContext, saving loading, hold pointers to important classes, hold flags about the state of the program).

In general, I tend to avoid implementing functions like the ones you describe in them.

If you have a method that does the same thing no matter what class of object you're dealing with then, yeah, it wouldn't seem to make sense to have it duplicated in multiple categories for the various classes. But I would doubt that you would have that happening for, say, NSString and UIImage. If you do, perhaps you could post those methods here or, at least, explain what they do.

In the end, there is not always a right and wrong way to code things. Frequently, there are many paths to the same solution. Just go with what you feel comfortable with / makes the most sense in your development environment. I would say don't be overly concerned with memory footprint and performance until they become obstacles; often you will find you were worried for nothing (unless you are writing apps where those things are critical, then a different tact is required).

A category is a kind of utility function. In languages that don't support adding new methods to classes at runtime these kinds of things would be simple functions with C bindings. That's one way that I tend to do these things.

For instance I have an isIpad() function and a MMDocumentsFolder() function that returns the fullpath to the place where my app stores its documents. While these functions live in .m files in the header they are simply C language functions. (Hmmm, I guess NSString isn't a C language type but it could just as easily return a const char *).

My point is that these kinds of global functions don't have to be in a class. Apple has a bunch of utility functions that also aren't in a class.

I also sometimes create Utility classes that only have class methods. Apple tends not to do it that way. These classes tend not to have any state, like ivars, and all the methods have a clear relationship to each other.

What can be concluded is that there are different opinions and it depends on the particulars. You have to decide.

mpramodjain said:

Thanks for all replies..

So would it be good to go with a singleton class for generic methods or do I need make the instance methods..

What can be concluded.... Both performance wise and oops concept wise.

Click to expand...

If these "generic methods" could be put in a singleton class then they can't need access to internal object state from the objects they operate on. If that is the case I'd make them plain C functions rather than instance methods or methods on a singleton: it's faster to call a C function than send a message to an object...

I wanted to open a thread about singletons for some time but now that there's one already, I'll just post here. In my apps I'm often dealing with a set of data (read from disk) that I load from within a singleton. That way, whenever I need the data I just use the singleton without having to worry about allocating the data twice or passing around pointers through my app to prevent the creation of multiple different data sets. Is that a good use of singletons?

(marc) said:

I wanted to open a thread about singletons for some time but now that there's one already, I'll just post here. In my apps I'm often dealing with a set of data (read from disk) that I load from within a singleton. That way, whenever I need the data I just use the singleton without having to worry about allocating the data twice or passing around pointers through my app to prevent the creation of multiple different data sets. Is that a good use of singletons?

Click to expand...

I think so, yes. If you have a single set of data then it makes sense to represent it as such in your model layer.