Utilizzo di protocolli C oggettivi

Question

Ho una domanda sui compiti che mi ha confuso, molto male. Di seguito una breve spiegazione di una domanda.

Immaginate di sviluppare un'applicazione che memorizza le informazioni di contatto . La rubrica può contenere molti tipi di entità, ad es. Umano essere, una società o qualsiasi altra cosa che abbia un contatto.

• Ora, invece di esplicitamente controllare ogni tipo di oggetto scrivere un protocollo che dichiara come un oggetto deve comportarsi e con successo apparire nella rubrica.

---

mia comprensione e gli sforzi di rispondere a questa domanda è,

1. Costruire un protocollo che ha metodi comuni di ogni tipo di informazioni di contatto sotto @required tag. E tutti gli altri metodi che non sono simili in contatti diversi (ad esempio il numero di fax è associato con la società ma non con la persona ...) in @optional. In fase di esecuzione è possibile verificare se un oggetto risponde a un determinato metodo utilizzando selector. Dubbio: Tuttavia, anche in questo caso si verifica esplicitamente il tipo di oggetto indirettamente, ho ragione?

2. Il mio secondo pensiero è usare qualcosa come abstract class in java. Il che significa che le classi ereditate dalla classe astratta implementano i propri metodi astratti. Ma come un ingenuo sviluppatore iOS non so come implementarlo? e non sono sicuro se questo risolverà il mio problema. Vorrei ottenere chiarimenti se qualcuno lo sa.

---

lettura esterno fatto finora, per favore fatemi sapere se la risposta che sto cercando è in uno di questi link. Lo leggerò di nuovo per capire e risolvere questo :). Grazie.

1. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProtocols.html#//apple_ref/doc/uid/TP30001163-CH15-TPXREF144

2. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProtocols.html#//apple_ref/doc/uid/TP30001163-CH15-TPXREF146

3. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProtocols.html#//apple_ref/doc/uid/TP30001163-CH15-TPXREF149

Answer 1

Un protocollo è la stessa cosa di un'interfaccia Java. Definisce solo i metodi che la classe dovrebbe supportare. Ecco una pagina che spiega chiaramente: http://www.otierney.net/objective-c.html#protocols

In sostanza, se si vuole fare in modo di una classe avrà un metodo phoneNumber (di accesso alla proprietà phoneNumber) si farebbe qualcosa di simile:

@protocol ContactProtocol 
-(void) phoneNumber; 
@end 

@interface Person: NSObject <ContactProtocol> { 
    ... 
} 

@interface Company: NSObject <ContactProtocol> { 
    ... 
} 

E poi in fase di compilazione (o live per xcode 4) ti dirà se hai dimenticato di aggiungere il metodo phoneNumber alle classi Person o Company.

Answer 2

Tuttavia, si tratta ancora di controllare esplicitamente il tipo di oggetto in modo indiretto, vero?

No, il controllo del comportamento è diverso dal tipo di controllo. È possibile inviare -respondsToSelector: a qualsiasi oggetto e, se il risultato è SÌ, è possibile inviare il messaggio indipendentemente dal tipo di oggetto. È inoltre possibile richiedere che un oggetto implementare un determinato protocollo, ancora una volta senza preoccuparsi di suo tipo effettivo:

id<SomeProtocol> foo; // foo points to any type that implements SomeProtocol 

mio secondo pensiero è quello di usare qualcosa come classe astratta in java.

Questo potrebbe funzionare, ma apparentemente non è ciò che il tuo incarico ha richiesto, giusto? Dice "... scrivi un protocollo ..."

Objective-C non fornisce un modo per rendere esplicitamente un abstract di classe come fa Java. Devi solo creare la classe, e se non vuoi che sia istanziata direttamente, puoi documentarla da qualche parte.

Answer 3

Hai ... opzioni.

I metodi facoltativi sono convenienti per la persona che scrive la classe per conformarsi al protocollo, fastidiosa per la persona che fa uso del protocollo. Quindi dipende da chi stai cercando di soddisfare.

I metodi facoltativi non sono negativi come il tipo di controllo. Immagina come apparirà il codice quando accedi a un oggetto entità contattabile. Quando usi un metodo opzionale, devi avere un caso if e un altro caso. Non è così conveniente come andare avanti e assumendo che tu possa chiamare il metodo. Ma è molto più conveniente che controllare il tipo. Questo sarebbe uno se caso per ogni diverso tipo di entità (e un altro caso, che potrebbe essere un'asserzione). Inoltre, se si utilizzano metodi opzionali, le informazioni sull'entità sono incapsulate nella sua classe. Se si controlla il tipo prima di chiamare un metodo, le informazioni sul tipo di informazioni di contatto fornite da un'entità si trovano al di fuori della classe nel codice chiamante. Se si aggiorna l'entità per fornire un tipo aggiuntivo di contatto, tale miglioramento non è disponibile finché non si aggiorna il codice chiamante.

L'opzione B consente di eseguire tutti i metodi richiesti, ma offre loro la possibilità di restituire un valore che indica che non sono disponibili informazioni, ad esempio zero. Ovviamente questo significa ancora un caso in caso di controllo di un risultato nullo, è solo meno dettagliato. Una soluzione ancora migliore per questo problema è che i metodi restituiscano le raccolte di più contatti. Dopo tutto, le persone possono avere più di un numero di telefono. Quindi per indicare che un tipo di contatto non è applicabile, si restituirà semplicemente una raccolta vuota.

Lo svantaggio è che chiunque scrive la classe conforme al protocollo deve aggiungere un semplice metodo di stub che dice return nil o qualcosa del genere.