4

I have a few methods which are stateless:

loginWithEmail: password: completion:
signUpWithEmail: password: completion:
resetPasswordForUsername: completion:

Currently what I do is I create a class which holds these stateless methods:

@interface KGAccountService : NSObject

+ (void)//method1
+ (void)//method2
+ (void)//method3

@end

I then would call the methods from some place like a view controller that a user is using to log in.

[KGAccountService loginWithEmail:@"email" password:@"password" completion:{
    // user logged in or error
}];

A co-worker of mine is pretty adamant that even though the class only houses class methods and does not need any sort of state, it should be implemented using the singleton pattern and be called through that:

@interface KGAccountService : NSObject

+ (instanceType)sharedInstance;
- (void)//method1
- (void)//method2
- (void)//method3

@end

Then:

[[KGAccountService sharedInstance] loginWithEmail:@"email" password:@"password" completion:{
// user logged in or error
}];

I don't see the point in implementing the singleton pattern when it is not needed and my co-worker was not able to get his point of view through to me. Is there a design pattern which I am missing and is my way of creating a class to house stateless class methods correct?

2

There is no reason to wrap stateless global functions as class methods unless you just want to make the name of the function longer... And if that's all you want to do, then just make the name longer. For this reason, I strongly recommend against the approach you are considering. It accomplishes nothing useful.

As for your co-worker's idea, if you are just going to preface every call to these functions with [[KGAccountService sharedInstance] ... (or [[KGAccountService alloc] init] ...) then again, you aren't accomplishing anything but making the name of the function longer.

Now if you plan on injecting the object into other objects so you can easily replace it with a different object then your co-worker's idea has some merit... Except the sharedInstance method becomes superfluous. Don't bother putting it in.

And then there is the point that @gnasher729 made... It doesn't feel right for these methods to be stateless. They are likely connected by some underlying state in some way (just based on the names of the functions.)

1

First of all, have you tried to ask your co-worker what would be the benefits of his approach ? From my point of view, the only advantage of having a singleton (and basically object methods) is to ensure that later on, you will be able to extend those functions (or to mock them), and change the behavior of code that relies on it. This is especially useful if you need to make some unit-test.

@interface KGAccountService : NSObject

+ (instanceType)sharedInstance;
- (void)//method1
- (void)//method2
- (void)//method3

@end

@implementation KGMockedAccountService : KGAccountService

- (void)//overridden method1
- (void)//overridden method2
- (void)//overridden method3

@end

// The account service injected here could be any one implemented above
-(Data *) retrieveUserDataWithAccountService: credentials: completion:

Is this answering your question ?

For more information, you could make some researches on the Open-Closed principle.

0

The singleton pattern may be of advantage. Even though you say the methods are stateless, the implementation isn't necessarily, and then having an object holding the state will be useful.

As a simple example, the loginWithEmail: ... is probably asynchronous and you don't want to have another call while the first one is running. That's difficult without having state around.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.