¿Se considera una mala práctica agregar lógica en un establecedor de propiedades?

Salté a un proyecto y veo que los otros desarrolladores están agregando mucha lógica en los establecedores de propiedades sintetizadas. Entiendo cómo funciona esto, pero creo que dificulta la comprensión del flujo del programa; Mientras leo el código, cada vez que veo self.something = whatever, siempre verifico si somethingel setter está anulado.

¿Cuáles son sus opiniones sobre este tema? ¿Crees que esto es un signo de mala arquitectura o una solución elaborada?

Me gustaría leer más sobre esto si tiene enlaces / fuentes relevantes, es demasiado difícil obtener buenos resultados de Google, así que decidí preguntar aquí también.

Gracias por cualquier respuesta y tenga en cuenta que estoy hablando del objetivo C en caso de que no haya visto la etiqueta (aunque supongo que esto no debería ser un problema específico del idioma).

¿Se considera una mala práctica agregar lógica en un establecedor de propiedades?

No

Las propiedades se inventaron para permitir a los diseñadores de clase tener lógica unida a una interfaz conveniente de acceso y asignación de campo.

¿Cuánto es demasiado? Depende de las responsabilidades de la clase. Aquí hay algunas cosas que son razonables para poner en un configurador de propiedades:

• actualizar algunos valores derivados
• notificar a los observadores que el estado de la clase ha cambiado
• propagar el cambio a algún objeto contenido
• propagar el cambio a una tienda de respaldo
• realizar validación

La programación es más fácil cuando las clases tienen interfaces que hacen obvio lo que la clase puede hacer, sin hacer que las personas que llaman piensen cómo se está haciendo. Poner la lógica detrás de los establecedores de propiedades permite a las clases ocultar su implementación detrás de una interfaz simple. Para algunas clases, no se requieren métodos. Simplemente gire las perillas configurando propiedades y lea la salida obteniendo propiedades.

Los setters generalmente se usan para cambiar el estado de un objeto sin efectos secundarios significativos o cálculos pesados; use métodos y funciones para eso. La razón principal para la implementación del setter es cambiar y mantener un estado válido . Por lo tanto, limitar el rango, establecer banderas para solicitar un nuevo cálculo o ajustar las propiedades relacionadas está absolutamente bien.

No sé sobre el objetivo C, pero como dices, parece una pregunta lo suficientemente genérica para cualquier lenguaje OO. En primer lugar y en realidad relacionado con eso, si es necesario tener setters y getters en primer lugar (en algunos casos su existencia se justifica mediante el uso de un marco o biblioteca).

Creo que el nombre del método debería explicar lo que hace el método y todo lo que hace. Además, la documentación asociada a ese método debería describirlo de una manera más explícita. En este sentido, un nombre de método en la forma "set" + {sustantivo} no debería tener ningún efecto secundario aparte de establecer el valor de una variable y esa debería ser la única acción asociada a ella. Verificar que el argumento sea válido es aceptable, pero debe describirse en su documentación.