The difference between protocol, category and inheritance in OC

The difference between protocol, category and inheritance in OC

using inheritance, polymorphism is a good keep "open to extensions, closed to changes" (OCP) is also the most common approach. Objective C also supports two additional syntaxes to support Ocp:protocol and category. Protocol can only define a set of interfaces, but not the implementation, in disguise is also an abstract class implementation (OC syntax itself does not support the abstract base class). The category can provide additional interfaces and implementations for the class. So what is the essential difference between the three (inheritance, protocol,category) in use? In my opinion, the role of protocol is to provide only a common set of interfaces for some column classes, and there is absolutely no way to provide specific implementations; The category is to provide some additional interfaces and implementations for an existing class, and inheritance is based on the possibility of Protocol provides only pure interface, but also can provide a complete implementation like category, and inheritance can also rewrite the function of the class, so that the power of inheritance is the most powerful. So what is the appropriate situation for each application?

. Protocol is the definition of behavior and no matter who is how to achieve it, it is a relatively free and irresponsible situation, as if the customer in the outsourcing project, he is just what he needs, concrete implementation he will not and can not give the same. Delegate DataSource like this, it's better to use protocol.

. Category is a complement to a fully functional class, as if the main basic function of a thing has been completed, you can use category to add different components to this class, so that this class can adapt to the needs of different situations (but the requirements of these different requirements are the same as the core). Just like you already have a car that can run, we can use category to add a variety of features to your car that you didn't have before, and finally make the car into a supercar.

. When a class is very large, category can be implemented according to different functions to separate the implementation of the class into different modules.

. Inheritance can be done above, but inheritance has a great cost problem, one is to extend through inheritance is a very high coupling behavior, the parent class can be said to be completely dependent on, second, inheritance because of dependency on the parent class, so the development cost is relatively large, requires the parent class workflow is relatively familiar Thirdly, if the inheritance system is too complex, it will cause the whole system to be chaotic and difficult to maintain. So when you can use the above two methods to complete the extension, you should never use inheritance. What is the necessity of using inheritance? That is, if you want to provide a set of interface definitions, but also want to provide some but do not provide the full implementation of the time, this situation will use inheritance. So it seems that inheritance is a binder for both of the above functions.

Additional Insights on Category:

. Although category can access an instance variable of a class, it cannot create a new instance variable, and if you want to innovate an instance variable, use inheritance;

. In the category, overloading of the original method is not advocated. The reason is very simple, overloaded in the category, unable to access the original method, and can use super in inheritance. If you really need to overload the original method, consider inheriting, for example, if I want to define a class that inherits from Uiviewcontroller, I can't use category because, in this class I'm defining, I'm going to implement the viewdidload in Uiviewcontroller. , Init and other methods, using the category stepfather Uiviewcontroller in these methods will not be called;

. A class can define multiple categories, but the compiler cannot decide which category to use if the same method exists in the different category;

. When defining a category, we can just give the method definition, without having to give a specific implementation. This is very helpful in the process of incremental development;

. The category can be inherited. A category is defined in a parent class, and all of his subclasses have that category;

. When you need to create a private member method for a class, it is also implemented in category.

Category does not completely replace subclasses, there are several of the biggest drawbacks:

. When overriding an inherited method in the category, the method in the category can invoke the inherited method by sending a message to the Super class. However, if the method covered in category is already defined in the other category of the class, the previously defined method will not have the opportunity to be called by the program

. It is not possible in the category to be sure that it can reliably overwrite a method that has been defined in other category. This problem is particularly prominent when using the cocoa framework. When you want to overwrite a method that a framework has already defined, the method is already implemented in the other category so that it is not possible to determine which definition and implementation will be used first, with great uncertainty.

. If you re-override some of the methods that are defined, it often results in this approach being implemented throughout the framework. For example, if you increase the implementation of Windowwillclose: In NSObject, this will cause all windows to invoke the new implementation method, thus altering the behavior of all nswindows instances. This creates a lot of uncertainty and is likely to cause the program to crash.

The difference between protocol, category and inheritance in OC