- Does anyone know where I can find a good explanation/tutorial of what and how an application delegate works in
objective-C
? - The two books I have don't dwell on
delegates
enough and do not explain them very well for me to truly understand their power and function.
相关问题
- CALayer - backgroundColor flipped?
- Core Data lightweight migration crashes after App
- How can I implement password recovery in an iPhone
- State preservation and restoration strategies with
- “Zero out” sensitive String data in Swift
相关文章
- 现在使用swift开发ios应用好还是swift?
- UITableView dragging distance with UIRefreshContro
- TCC __TCCAccessRequest_block_invoke
- Where does a host app handle NSExtensionContext#co
- xcode 4 garbage collection removed?
- Unable to process app at this time due to a genera
- Swift - hide pickerView after value selected
- How can I add media attachments to my push notific
As described above, a delegate is not a feature of iOS or Objective-C, but just a programming technique and requires no specific language support.
A class (e,g, classA) may be written such that its getData and doSomething methods can be implemented not by itself, but by a delegate (perhaps because classA doesn't know what the data will be or what it will have to do).
To achieve this, classA provides a property, usually called delegate, (which is just a pointer to the class - the delegate - that implements the delegated methods) and then, when it wants to call those methods, it actually calls the methods in the delegate:
and
self.delegate
may be initially set toself
:i.e. classA implements it's own version of these methods, unless they are delegated.
Any other class, wanting to be the implementor of the methods (i.e. to be the delegate and possibly override classA's default implementation), would first set classA's delegate to be itself. so if classB wanted to be the delegate for these methods, in classB, we would have:
So when classA calls these delegated methods, it's actually calling classB to implement these methods, without knowing anything about classB or even that it exists and classB doesn't have to sub-class classA.
The limitation is that classB can only override methods which classA wants to delegate - with subclassing, you can override any method.
Protocols are used to formalise the delegation process by defining a list of methods which either must be implemented by the delegate (the delegator provides no default version of the method and the method must be implemented somewhere) or can be optionally implemented by the delegate (i.e. the delegator has it's own version or it does not matter if the method is not implemetned).
I try to elaborate it through simple program
Two Classes
Student.h
Student.m
Teacher.h
Teacher.m
main.m
EXPLANATION :::
From main method when initWithStudent:student will execute
1.1 Teacher's object's property 'student' will be assigned with student object.
1.2 self.student.delegate = self means student object's delegate will points to teacher object
From main method when [student studentInfo] will be called
2.1 [self.delegate respondToSelector:@selector(teacherName)] Here delegate already points to teacher object so it can invoke 'teacherName' instance method.
2.2 so [self.delegate performSelector:@selector(teacherName)] will execute easily.
It looks like Teacher object assign delegate to student object to call it's own method.
It is a relative idea, where we see that student object called 'teacherName' method but it is basically done by teacher object itself.
Delegates are a design pattern; there is no special syntax or language support.
A delegate is just an object that another object sends messages to when certain things happen, so that the delegate can handle app-specific details the original object wasn't designed for. It's a way of customizing behavior without subclassing.
When in doubt, check the docs!
Basically, delegation is a way of allowing objects to interact with each other without creating strong interdependencies between them, since this makes the design of your application less flexible. Instead of objects controlling one another, they can have a delegate which they send (or delegate) messages to, and the delegate does whatever they do, in order to respond and act to this message, and then usually return something back to the other object.
Delegation is also a better alternative to subclassing. Instead of you having to create your own custom classes to slightly alter the way that other objects behave, or pass them data, delegation allows objects to send messages to their delegates to do work for them without the overhead of creating subclasses to make minor changes to other objects.
Of course, the main disadvantage of delegation is that the delegate methods available are dependent on what the Apple engineers foresee as being useful and what common implementations they expect people to need, which imposes a restriction on what you can achieve. Although, as Quinn Taylor pointed out, this is specific to the Cocoa frameworks and so doesn't apply in all situations.
If delegation is an option over subclassing, then take it, because it's a much cleaner way to manage your code and interactions between objects.
Just imagine that you call by phone, and order a pizza. Then, a pizza delivery boy arrives to your home (this is a Delegate), and when you pay for the pizza, the delivery pizza boy returns the money to his restaurant.
you = object delivery boy = Delegate restaurant = object