objective-c - tipos - recomendaciones para lectura en casa

Pautas para usar propiedades versus métodos

Question

A menudo me cuesta decidir si ciertos datos deben exponerse a través de una propiedad o un método. Puedes decir "usar propiedades para el estado del objeto", pero eso no es muy satisfactorio. Tome este ejemplo, por ejemplo:

- (NSString *)stringOne
{
    return _stringOne;
}

- (NSString *)stringTwo
{
    return _stringTwo;
}

- (NSString *)mainString
{
    return [_stringOne length] > 0 ? _stringOne : _stringTwo;
}

Está claro que stringOne y stringTwo deberían ser propiedades porque están claramente en estado de objeto. Sin embargo, no está claro si mainString debería ser una propiedad. Para el usuario final, mainString actúa como estado. Para su objeto, mainString no es estado.

Este ejemplo es artificial pero espero que entiendas la idea. Sí, las propiedades no son más que una forma conveniente de crear getters y setters pero también comunican algo al usuario. ¿Alguien tiene pautas decentes para decidir cuándo usar una propiedad frente a un método?

Answer 1

Ocultar la división entre el estado "verdadero" ( string1 y string2 en su ejemplo) y el estado "dinámico" ( mainString ) es, diría, exactamente para qué son las propiedades.

El ejemplo canónico probablemente sea un objeto que represente a una persona, con nombres dados y familiares como "estado". Una tercera pieza de estado, "nombre completo" se puede presentar a partir de esas dos piezas, pero los clientes no tienen absolutamente ninguna razón para saber si el nombre completo se construye a pedido, o si se crea y almacena cuando se establecen ambas piezas. Simplemente no importa.

Las propiedades son una interfaz : ¿qué bits de datos proporciona esta clase a sus clientes (y qué pueden configurar los clientes sobre la clase)? La implementación de cada propiedad está encapsulada y no afecta su estado como propiedad.

En ObjC, por supuesto, usamos métodos para acceder a las propiedades. Sin embargo, otros métodos representan acciones que un objeto puede realizar, posiblemente se le pase algún dato para operar.

Answer 2

Otra consideración a tener en cuenta: ¿desea almacenar el valor de la propiedad? (a través de NSCoding o en Core Data, por ejemplo) Supongo que NECESITA crear propiedades para cosas que necesita "guardar" (en "encodeWithCoder", por ejemplo. Decidir qué quiere poner en encodeWithCoder podría ayudarle a decidir de qué manera desea definir cosas).

Para cosas que no necesita guardar y puede volver a calcular fácilmente, tiene la opción entre un método y una propiedad de solo lectura (que es equivalente bajo el capó: una propiedad de solo lectura crea un método de acceso getter y no tiene una variable de instancia) para respaldarlo). Entonces eso es más una cuestión de estilo.

Hablando de estilo, si usas la notación de puntos solo para propiedades (como yo lo hago), tal vez te preguntes: - ¿Quiero acceder al nombre completo como foo.fullName y no marcar la diferencia con otras propiedades como foo.firstName? y foo.lastName? ¿O quieres marcar la diferencia accediendo al nombre completo con [foo fullName], mostrando al mundo que esto se calcula?

Creé una aplicación para las siguientes cotizaciones, y la modelo se inspiró en un ejemplo del libro Big Nerd Ranch sobre Objective C (buena lectura, dicho sea de paso). Así es como se definen las propiedades y los métodos:

// properties
@property (nonatomic, copy)   NSString *name;
@property (nonatomic, copy)   NSString *symbol;
@property (nonatomic, copy)   NSString *currency;
@property (nonatomic, copy)   NSString *market;
@property (nonatomic)         int    numberOfShares;
@property (nonatomic)         double purchaseSharePrice;
@property (nonatomic)         double currentSharePrice;

// Stock Calculation methods
- (double)costInLocalCurrency; // purchaseSharePrice * numberOfShares
- (double)valueInLocalCurrency; // currentSharePrice * numberOfShares
- (double)gainOrLossInLocalCurrency // valueInLocalCurrency - costInLocalCurrency

Puedes ver que se distinguen claramente. El BNR no usa ninguna notación de puntos en su libro, por lo que todo se vería igual: [precio actual de foo] o [valor de Foo en moneda local], pero como uso la notación de puntos para las propiedades, marcaría la diferencia de estilo entre foo. precio actual deShare y [valor de fooIn moneda local].

Espero que esto sea útil.

Answer 3

Por diseño, siempre debes respetar al usuario final: si crees que es un estado de objeto para el usuario de tu clase (que aparentemente es), entonces sigue adelante y crea una propiedad.