Come si definiscono i metodi stateless mantenendoli insieme in Objective-C?

Question

Come si definiscono i metodi stateless mantenendoli insieme in Objective-C?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

4

Ho alcuni metodi che sono senza stato:

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

Attualmente quello che faccio è creare una classe che contenga questi metodi stateless:

@interface KGAccountService : NSObject

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

@end

Quindi chiamerei i metodi da qualche posto come un controller di visualizzazione che un utente sta usando per accedere.

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

Un mio collaboratore è piuttosto irremovibile sul fatto che, anche se la classe contiene solo metodi di classe e non ha bisogno di alcun tipo di stato, dovrebbe essere implementata usando il modello singleton ed essere chiamata attraverso questo:

@interface KGAccountService : NSObject

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

@end

Quindi:

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

Non vedo il punto nell'attuazione del modello singleton quando non è necessario e il mio collega non è stato in grado di ottenere il suo punto di vista fino a me. C'è uno schema di progettazione che mi manca e il mio modo di creare una classe per ospitare i metodi di classe stateless è corretto?

object-oriented design-patterns singleton objective-c

posta Kris Gellci 30.07.2015 - 23:35

fonte

3 risposte

Leggi altre domande sui tag object-oriented design-patterns singleton objective-c

Verifica in quale regione è presente un indicatore di posizione Prestazioni di concatenazione di elenchi seguita da scansione

score 2 · Answer 1

Non vi è alcun motivo per ricoprire le funzioni globali stateless come metodi di classe, a meno che non si voglia semplicemente rendere più lungo il nome della funzione ... E se è tutto ciò che si vuole fare, basta semplicemente rendere il nome più lungo. Per questo motivo, raccomando strongmente l'approccio che stai considerando. Non fa nulla di utile.

Per quanto riguarda l'idea del tuo collega, se hai appena intenzione di far precedere ogni chiamata a queste funzioni con [[KGAccountService sharedInstance] ... (o [[KGAccountService alloc] init] ... ), di nuovo, non stai facendo nulla, ma rendendo più lungo il nome della funzione .

Ora se prevedi di iniettare l'oggetto in altri oggetti così puoi facilmente sostituirlo con un oggetto diverso, allora l'idea del tuo collega ha qualche merito ... Tranne il metodo sharedInstance diventa superfluo. Non preoccuparti di metterlo dentro.

E poi c'è il punto che ha reso @ gnasher729 ... Non è giusto che questi metodi siano apolidi. Probabilmente sono collegati da qualche stato sottostante in qualche modo (basandosi solo sul nome delle funzioni).

score 1 · Answer 2

Prima di tutto, hai provato a chiedere al tuo collega quali sarebbero i benefici del suo approccio? Dal mio punto di vista, l'unico vantaggio di avere un singleton (e fondamentalmente metodi di oggetti) è quello di garantire che in seguito, sarete in grado di estendere tali funzioni (o di prenderle in giro) e di cambiare il comportamento del codice che si basa su esso. Questo è particolarmente utile se hai bisogno di fare qualche test unitario.

@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:

Questa è la risposta alla tua domanda?

Per ulteriori informazioni, potresti fare alcune ricerche sul principio Open-Closed.

score 0 · Answer 3

Il modello singleton può essere di vantaggio. Anche se dici che i metodi sono senza stato, l'implementazione non è necessariamente, e quindi avere un oggetto che regge lo stato sarà utile.

Come esempio semplice, loginWithEmail: ... è probabilmente asincrono e non vuoi avere un'altra chiamata mentre il primo è in esecuzione. È difficile senza averlo intorno.