Si trigger son malos, es también el mal que tienen efectos secundarios al establecer una propiedad en Java o C #?

Question

Vamos a suponer que [trigger son el mal]. 1

¿Quiere esto decir que los efectos secundarios cuando se establece una propiedad en un Java o C # objetos son también el mal?

Me parece que existen los mismos problemas.

Answer 1

Ir contra la corriente aquí ...

Las propiedades no debe dar lugar a efectos secundarios. Eso es lo que son para Método.

Al tener propiedades causar efectos secundarios que terminan en una situación fuera de código es esencialmente oculto. La gente rara vez esperan propiedades para poner en marcha algún proceso o causa algo más que voltear. Si esto tiene que ser documentado, entonces no es obvio y sujetos a ser ignorado.

Sin embargo, esperamos que suceda algo cuando llamamos a un método.

Tomando el ejemplo de Astander @, dice que el hecho de cambiar "Precio" debería causar una propiedad diferente "Costo" para el cambio. Sin embargo, lo que si posteriormente añadir una nueva propiedad llamada "Descuento"? El código en torno a las propiedades de precios y la cantidad tendría que cambiar. Que no es muy visible.

Sin embargo, si el costo calculado en sí .. entonces todo es mejor.

Answer 2

No necesariamente, no. Si usted tiene una propiedad o Price Amount, y que cambia, parecería que el Cost debe cambiar en consecuencia?

O hay algo diferente que tenía en mente con este anuncio?

Answer 3

No. Muchas propiedades pueden y deben dar lugar a efectos secundarios.

Ejemplo: Imagínese dos elementos visuales que un niño está contenido dentro de una matriz. Configuración parent.Visible = false debe probablemente también establecer child.Visible = falso.

A menudo, estos efectos secundarios se explicitan a través de un evento (System.Windows.Forms está lleno de eventos PropertyChanged) o una interfaz (tal como INotifyPropertyChanged).

Answer 4

Tan útil como propiedades son a veces, lo hacen introducir algunas incertidumbres en el día a día de codificación en un ambiente de equipo, donde no todo el mundo interpreta necesariamente el propósito y adecuado uso de las propiedades de la misma manera.

Esta es una de una serie de cuestiones que surgen:

• ¿Deben los emisores de propiedad tienen efectos secundarios no evidentes.
• deben hacer potencialmente procesamiento intensivo?
• ¿Los campos públicos todavía tienen un lugar, o deberían ser todos los ámbitos privado / protegido y accesible a través de propiedades? Esto puede tener un impacto al hacer uso de la reflexión:. Que puede ser muy útil para saber que nunca tiene que buscar colección Fields de un tipo

En última instancia, creo que lo anterior 2 puntos no importan tanto, siempre que los efectos secundarios o potencialmente costosas operaciones están documentados, debido a que el mismo debería aplicarse a los métodos también.

Los más supuestos que puede hacer con seguridad la complejidad del código disminución, sino que la ganancia es negado en cierta medida por los gastos generales de comunicación adicionales. Sólo funciona siempre y cuando todo el mundo en el equipo está en la misma página, y las estancias en la misma página.

A veces pienso propiedades causar más problemas de los que resuelven.

Answer 5

Eso depende. Es cierto que hay efectos secundarios, que llevará al usuario por sorpresa y lo mejor es evitar los OMI.

Yo prefiero que las propiedades se comportan muy parecido a los campos, ya que tienen el mismo aspecto desde el punto de vista del lector (en C # de todos modos). Si una propiedad tendría ningún efecto secundario no obvio, yo preferiría un método más de una propiedad.

Answer 6

En adiciones a los comentarios de Chris anteriores, que estoy de acuerdo con hay otro aspecto que ha contribuido a los factores desencadenantes que se considera un poco retorcido y que es el hecho de que son no - obvio.

Esto hace entonces muy fácil olvidar que a su vez hace que sean muy difíciles de depurar.

Las personas (y yo soy uno de ellos y no el único seguro) han pasado horas tratando de depurar problemas y que pasan por el comienzo del flujo a extremo (procedimientos es decir, bases de datos finales aparente / consultas DML) para darse cuenta de lo que estaba causando la problema todo el tiempo fueron los disparadores -. porque de ellos es inherentemente operaciones en segundo plano

También podría argumentar que el registro adecuado de los factores desencadenantes debería dar como resultado fácil evitar este tipo de problema, pero general registro no se realiza en la capa de base de datos en sí, por tanto, lo que complica este aspecto de la resolución de problemas un poco más.