1. The attributes are the most direct. Two objects can be in direct contact. For example, a UIImageView is built in a UIViewControllerA and provides pictures to the UIImageView. 2. The proxy environment is generally: A operates B, and then B does not return the result immediately. Waiting for the condition to be met, B comes back to notify A. A common network request is characterized by a return action. 3. Block is similar to delegate in behavior and is also used for callbacks. But (1) block is easier to write, such as a pop-up box, and click event callback after pop-up box. I build an alertView, and then I can write its callback alertView.clickBlock = xxx, and I have to build another method for delegate (2 ) block will copy its internal objects, which will have a good isolation effect. For example, A is a general singleton, B->A->C, and then C handles the callback B, E->A- >F, then F handles the callback to E. If it is a delegate, after C calls back to A, does A call back to B or E? A doesn’t know. But block will copy the object. When B creates the block, he copies himself into it. The callback object C gets is B. This is a bit difficult to understand. 4. Compared with the first two, notifications are: (1) One-to-many, when one notification is sent out, all recipients will respond and it will be synchronous. (2) There is no direct relationship between the sender and the receiver. Especially in complex projects, when the two objects cannot contact each other, notifications can be used to send messages, but it is easy to mess up. For example, if the login is successful, the data needs to be updated in many places, but the login module is focused on login. What should be done after the login is successful should not be managed by it, so it is better to use notifications. Of course, projects should have as few cross-interactions as possible.
1. The attributes are the most direct. Two objects can be in direct contact. For example, a UIImageView is built in a UIViewControllerA and provides pictures to the UIImageView.
2. The proxy environment is generally: A operates B, and then B does not return the result immediately. Waiting for the condition to be met, B comes back to notify A. A common network request is characterized by a return action.
3. Block is similar to delegate in behavior and is also used for callbacks. But (1) block is easier to write, such as a pop-up box, and click event callback after pop-up box. I build an alertView, and then I can write its callback alertView.clickBlock = xxx, and I have to build another method for delegate (2 ) block will copy its internal objects, which will have a good isolation effect. For example, A is a general singleton, B->A->C, and then C handles the callback B, E->A- >F, then F handles the callback to E. If it is a delegate, after C calls back to A, does A call back to B or E? A doesn’t know. But block will copy the object. When B creates the block, he copies himself into it. The callback object C gets is B. This is a bit difficult to understand.
4. Compared with the first two, notifications are: (1) One-to-many, when one notification is sent out, all recipients will respond and it will be synchronous. (2) There is no direct relationship between the sender and the receiver. Especially in complex projects, when the two objects cannot contact each other, notifications can be used to send messages, but it is easy to mess up. For example, if the login is successful, the data needs to be updated in many places, but the login module is focused on login. What should be done after the login is successful should not be managed by it, so it is better to use notifications. Of course, projects should have as few cross-interactions as possible.