Objective-C, Delegate as an Adapter Pattern: Who Is Adapted?
I've read several times that the delegate pattern used in Cocoa is an implementation of the Adaptern pattern ( http://en.wikipedia.org/wiki/Adapter_pattern ). They share the same intent, namely, let two objects with incompatible interfaces work with each other. The Delegate is an Adapter because it accepts the protocol required by the client, the class that requires the protocol, and has a weak reference to the delegate, is the Client (so it would be a Cocoa struct class). My question is: who is Adapter? The delegate pattern doesn't wrap around any object, from what I've seen who is the object that needs to be adapted?
source to share
I found the solution in the official documentation, as I suspected there was no adapted one: https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/ uid / TP40002974-CH6-SW5
source to share
Delegates are not really an example of an adapter pattern. The protocols will be closer, but the best way to implement the Adapter pattern in Objective C is to create a new object containing the object you want to adapt and use it to serve the client.
Categories are another way to implement the adapter pattern, but they have some limitations. You cannot override the implementation of existing methods in a category, and you cannot add additional instance variables to a class with a category. All you can do is add new instance methods. However, this is sufficient.
You can also use multiple inheritance to implement the adapter pattern in languages like C ++ that offer it, but Objective-C does not support multiple inheritance.
A simple example of an adapter using a category that I use in my projects looks like this:
Interface Builder (IB) includes a Runtime User-Defined Attributes feature that allows you to set properties on custom interface objects using Key Value Coding (KVC). It allows you to specify a limited number of data types (ints, float, bools, points, rects, UIColors and some others). You can use User Defined Runtime Attributes to set the border width and corner radius at the view level, and you MUST use it to change the layer border color or background color. However, layer colors are specified as CGColors, and UIViews use UIColors. Since IB only accepts UIColors in the User Defined Runtime Runtime attribute, it doesn't work.
To fix this, I created a CALayer category called CALayer + setUIColor. It has 2 methods: setBorderUIColor and setBackgroundUIColor. These methods are very simple. They take UIColors as input and just convert the UIColor to CGColor and set the border color or background color.
You can see an early version of this category in my KeyframeViewAnimations github project .
source to share
I would say that this is a completely wrong look at the Cocoa delegate pattern.
An object requiring a delegate is intentionally left unfinished. But instead of having an abstract class and adding the required functionality by subclassing, we add the required functionality by providing another object, a delegate.
Nowadays, more and more people are switching from using delegate objects to providing the required functionality, passing one or more blocks instead.
source to share