CODEWITHSUNDEEP
iosobjective-c
j_mcnally
j_mcnally

Reputation: 6968

id vs class name when defining delegate properties

I am working on a delegate pattern for authorization in my app.

Most things i've seen before use something like:

@property (weak) id<Delegate> delegate;

Does that make it weaker than say

@property (weak) UIViewController<Delegate> *delegate;

I realize i am asking for any pointer in the first one and in the second I am expecting a typed pointer. But i only want my delegate to be a UIViewController or subclass.

Can anyone explain the differences and pros and cons?

Upvotes: 0

Views: 101

Answers (2)

Julien
Julien

Reputation: 3477

There are not real pros or cons. The contract is just different. One says "I don't care what class it is as long as it conforms to that protocol" and the other says "I want a subclass of UIViewController which also conforms to the protocol".

The only thing here is that the idea of the "delegate" pattern in Cocoa is generally to give the client of your API a way to create an object that will customize the behavior of one or several other components.

Since you want this property to be a view controller, the semantic is more than just a delegate so I would not call it a delegate but a xxxViewController with "xxx" being the actual functional relationship between your object and that view controller.

Upvotes: 0

user529758
user529758

Reputation:

But I only want my delegate to be a UIViewController or subclass.

Then go for the second way - the first one indicates that it can be any object that conforms to the <Delegate> protocol.

Upvotes: 3

Related Questions