The controversy in IOS development (i)

This is the first of the series, and what I want to discuss is: How are the member variables of the class defined?

In the early days of Objective-c's language, private member variables of a class could only be defined in the header file of. H. It looks like this:

@interface Viewcontroller:uiviewcontroller {@private nsinteger _value;}

After that, Apple improved the objective-c, allowing the addition of a special anonymous category in. m, the category without a name, to implement the addition of member variables to the class. It looks like this:

@interface Viewcontroller () @property (nonatomic) nsinteger value; @end

The advantage is that these variables are completely hidden in the header file, and are not exposed to the user.

Then, in the WWDC of 2013, Apple further improved the objective-c, allowing in the. m
The private member variable of the class is added directly @implementation. It looks like this:

@implementation Viewcontroller {nsinteger _value;}

So, you have a disagreement about how to define a private member variable. Many people like to define private member variables in an anonymous Category. However, I personally recommend adding private member variables of the class directly in the @implementation. Let me make some explanations.

Historical reasons

First of all, early IOS programmers must have known that OBJECTIVE-C was required to manually manage the reference count before the 2011 ARC was introduced. In the form of Self.property for all private members of a class, you can have the compiler automatically generate code that manages the reference count for us. 2012 years ago, this feature also needed to be enabled using @synthesize keywords. As a result, Apple recommends and emphasizes the use of Self.property programming habits in code specifications to avoid problems in memory management. In the ARC era, the advantages of this programming habit no longer exist, because the compiler will automatically manage the reference count for us, and we just need to be concerned about not causing circular reference problems.

Hassle --Easy

Just now, there is no memory management problem when accessing private member variables completely in a class using the _property method. But isn't it the same as using Self.property to access private variables without the memory management problem? It is true, but one thing to note: We'd better not use Self.property in init and dealloc to access member variables.

So, if you use Self.property to access private member variables. Then you need to be aware that this is not used in Init and dealloc. This is actually a burden to the programmer, and you need to keep reminding yourself that you have made a mistake. If you use a completely _property way to access private member variables, you don't have to think about this type of problem.

about Hidden

As you know, Self.property is actually invoking the [self] method of the class, so this is actually a layer of method call hiding, many times we need to delay the first time to make a class member, we will write this member's initial method in this [self Property] method in the implementation.

So the question is, when you read someone's code and you see Self.property, you wonder: Is there some hidden function implementation? So you need to jump to its method implementation to find out. However, in the actual development, most of the property is actually using the compiler automatically generated Getter and Setter method, so you will not find the implementation, this time, you just know: "Oh, the original code did not do the custom of the initial work of the members."

This default is more hidden in the code, which can affect the reading and maintenance of the code. In fact, most of the class member variables need to be assigned in the first-class method, and most of the Uiviewcontroller member variables need to be assigned in the Viewdidload method. That being the case, it is better to use a method called Setupproperty directly in the corresponding method to make the initial initialization. The advantage of this is that the code is more readable, and self.property is only used if it needs to delay the initial implementation.

There's a little story about this, I've Review a colleague's IOS code before, and that colleague likes to encapsulate the table view's data in a separate class, and I think the data is actually an array, and there's no need for this layer of encapsulation, and we ended up arguing for a long time. My point is that all concealment is an increase in the complexity of the code, unless it brings benefits such as code reuse, improved maintainability of the code, or, otherwise, a package with no benefit will only cost the code reading comprehension. In my current experience, most of the table view data can be placed in an array, there is no need to encapsulate this array, and a set of methods to manipulate the array data.

Short code is easier to read

_property is shorter and simpler than self.property. I think this code is easier to read.

faster execution and smaller IPA volume

I never thought it would make a big difference between the speed and the application volume. But a peer (from a famous foreign social network company) told me that their company found that there is still a gap between the two, if your application needs to do some depth optimization, you can consider the change of Self.property to _property. But I think that most applications should not need to do this depth optimization.

KVO and KVC

Yes, if you use _property, you can't use KVO and KVC. But I have to ask, is it a good design to KVO own private member variables inside a class? We talk about classes to "high cohesion, low coupling", KVO is to implement the observer pattern, so that the objects are decoupled from each other. If KVO is used inside the class, KVO own private members, I don't think it's a good design.

Computed Properties

In Swift, Computed Properties was introduced (Https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_ programming_language/properties.html#//apple_ref/doc/uid/tp40014097-ch14-id259) concept, in fact this is also in the Objective-C, Just didn't give it a name specifically. If a property provides the corresponding setter and getter, and does not directly use its corresponding _property variable, then this property is called the Computed Properties.

Yes, if you use the _property form directly inside the class, you can't use the Computed Properties, but I don't think it has much effect. In fact, Computed Properties is a layer of data access to the package, we also implement two functions, respectively, corresponding to the data setter and getter function, you can achieve the same effect.

Circular Reference Issues

Weibo on the "king _" in the comments mentioned: directly with the private variables have a need to pay special attention to the place, in block directly write _property equivalent to Self->_property, although not write self, but implied to self retain, Easy to create circular references. Remember to use Weakself/strongself Dafa.

This is really a lot of people overlooked, so I also write here, thank him for his supplementary.

written in the last

In fact, I mentioned above these problems are small problems, the impact is not big. But the unity of code style is a big problem. So no matter whether you're using self.property style or _property style in your project, it's not a big problem, but if you use both styles at the same time, it's very bad.

I hope this article will let you understand the controversy in this respect, but also hope that we can at this point, within the company to achieve unity.

The controversy in IOS development (i)