EstadoObservable
Escrito por Martin Fowler
Traducido por Carmen Vidal
Revisado por Jorge Ferrer
¿Qué quiere decir la gente cuando dicen que un método no cambia el estado observable de un objeto?
Es muy útil diferenciar entre aquellos métodos que cambian el estado y aquellos que no lo hacen. Los métodos que no cambian el estado (lo que llamo consultas), pueden ser usados en cualquier contexto sin preocuparnos del orden en que se ejecutan cuando se mezclan con otros métodos.
La clave aquí no está tanto en que ellos no cambien el estado, sino de que no cambien el estado observable. El estado observable de un objeto es el que puede ser obtenido mediante sus métodos de consulta - dejadme ilustrarlo con unos ejemplos.
El ejemplo más simple es él de una cache. Imagínese una clase que representa un rango como ésta:
# ruby
class MyRange
attr_reader :start, :finish
def initialize start, finish
@start, @finish = start, finish
@lengthCache = nil
end
def length
@lengthCache = (@finish - @start) unless @lengthCache
return @lengthCache
end
end
Aquí tenemos una variable "lengthCache" cuyo valor se asigna en el primer acceso usando LazyInitialization(inicialización tardía). Dar un valor a lengthCache claramente cambia el verdadero estado del objeto. Sin embargo no cambia el estado observable porque no se puede saber que el estado del objeto ha cambiado desde el exterior.
Que no se pueda saber desde fuera significa que el resultado de llamar a cualquier método de "MyRange" desde otro objeto será el mismo se asigne o no un valor a "lengthCache".
La forma habitual de conseguir esto es asegurando que cualquier método de "MyRange" usa el método "length" para obtener el rango en lugar de usar el campo [lengthCache] directamente. Las cachés son un caso obvio de estado cuyos cambios deberían no ser observables. Es cierto también que cualquier inicialización tardía no debería cambiar el estado observable.
