18th: Try to use immutable objects

1, the design of the class, should fully use the attributes to encapsulate the data.

2, should try to publish the external properties as read-only, and only if it is necessary to publish the attributes.

3 . If the property can only be modified inside the object, expand it from the ReadOnly property to the ReadWrite property in the Class-continuation category.

In this way, if the attribute is nonatomic, then a "race condition" (race condition, race condition ) may result. When a property is written inside an object, an observer outside the object may be reading the property. To avoid this problem, you can set all data access operations (including internal objects) to synchronous operations by means of " dispatch queue " (dispatch queue, see article 41st), if necessary.

A) These properties can now be set only within the implementation code. In fact, it is more accurate to say that these property values can still be set from the " key-value encoding " (Key-value Coding, KVC) technology outside the object. Doing so is tantamount to bypassing the API provided by this class.

b) You can also use the type information query function to isolate the value of this instance variable by identifying the offset of the instance variable in the memory layout that corresponds to the property property. It is also inappropriate to bypass the public API for this class.

The above added two ways of setting properties around the public API.
But this is a kind of sabotage that could be problematic. Therefore, it is recommended that you try to write immutable objects as much as possible.

4 . Do not expose mutable collection as attributes, but provide related methods to modify variable collection in the object.

Cases:
. h
In the Person class
Has a property
@property (Nonatomic, Strong, ReadOnly)nsset *friends;
Two methods
-Addfriend
-Removefriend

. m
Variable
Nsmutableset *_internalfriends;
-(nsset*) Friends {
return [_internalfriends copy];
}

-Addfriend {
_internalfriends
}

-Removefriend {
_internalfriends
}

You can also use Nsmutableset to implement the Friends property directly, so that the class does not manipulate this property directly by using the Addfriend:removefriedn: method.
However, this overly decoupled (decouple) data approach is prone to bugs. For example, when you add or remove a friend, the person object may also perform other related actions, and if this is the case, it will be equivalent to modifying the set that is used internally to hold the friend object directly from the bottom. When the person object is not known, modifying the set directly from the underlying may result in inconsistencies between the data within the object.

Therefore, it is recommended that you do not query the type on the returned object to determine whether it is mutable.
Cases:
Nsset *friends = person.friends;
if ([Friends Iskindofclass:[nsmutableset class]]) {
Nsmutableset *mutablefriends = (nsmutableset*) firends;
// .....
}
This practice should be avoided in every effort. Do not assume that the nsset used by friends must be mutable.
5, This still indicates: it is not appropriate to directly modify the data in the object from the bottom.

18th: Try to use immutable objects