Cita:
Iniciado por Lord Kazuky 
Enrique, cuando dices:
"No uses/evita (conceptualmente) los getter/setter, usa métodos simples (si los set/get son parches, no tienes por qué estar obligado a usarlos)."
¿Es por cuestión de diseño? a que te refieres con 'conceptualmente'?
Segun el ejemplo que pones 'asignarTemperatura' y 'tieneFiebre' son nombres que dicen más de lo que hacen que solo 'get'. ¿A eso te refieres?
Estimado Lord, pensé que todo el hilo de la discusión había sido suficientemente claro
Un getter/setter no es más que una "convención de nombres y uso" para un método, por ejemplo:
- si pides datos, get y nombre del atributo que entregas datos, ej: getNombre()
- si es para asignar datos, inica el nombre con set y el atributo, ej: setNombre($valor);
Y conceptualmente, es simplemente para suplir que no hagas atributos públicos pero que quieres/necesitas de alguna forma aplicar una "excepción" (evita que todo lo sea)... si lo razonas verás que si aplicas set/get siempre a tus atributos, es lo mismo que si fueran públicos... y esa no es la idea, los objetos (en su uso tradicional) no deben tener atributos públicos.
Es conceptual, tu perfectamente puedes tener métodos que se llamen "getAlgo" y no sean getter/setter, simplemente porque te queda más cómodo que decir "obtenerValorDeAlgo"; nadie dice que no puedes usar en otros ámbitos la preposición "get"... por eso también la discusión que un método getter/setter tiene que ser simple, como si fuera un atributo público... si hacemos métodos quilométricos, yo diría que se pierde la esencia, usa entonces métodos comunes y no digas que son getter/setter.
Lo "conceptual" es que deberías evitar acceder directamente a datos de un atributo desde el exterior ("principio de ocultamiento") y trabajar con métodos comunes que retornen información procesada.
Ese es el concepto, de ahí que lo puedas aplicar siempre y de forma pura, es lo más difícil.
Por eso mi sugerencia en ese orden, trata de evitar los getter/setter, pero si no puedes, usa ese orden.
¿Queda más claro ahora?