La verdad es que muchas veces se implementa la manipulación de los valores de los objetos fuera de éstos, convirtiéndolos en meros contenedores de datos.

Un saludo.

Saludos, Pablo.

Bueno, en mi opinión prefiero los getters/setters por el tema de la herencia y puesto que no es lo mismo heredar desde zona private que desde public en la mayoria de lenguajes orientados a objeto. En JAVA o Delphi la cosa queda bastante clarita…pero en C++ se complica que no veas. Por tanto, de este modo Standard es más facil no tener que recordar cada visibilidad de cada lenguaje: “¿Era a nivel de UNIT o a nivel de clase?”. Usualmente no se complica mucho la gente y se mete todo en “public” y “private”, pero desde las “Friendly” hasta “Protected” existen muchas opciones a tener en cuenta en las clases.

Aún así­ PREFIERO que todo el codigo tenga uniformidad sobre la standarización. Si se ha hecho de la forma sencilla del ejemplo, perfecto… pero luego no liar con property’s, getters o procedimientos vagabundos.

De todos modos el objetivo principal son 2: QUE SE PERMITA EVOLUCIONAR FACILMENTE a partir del código actual y que SEA CLARO. Todo lo demás es más superfluo.

Me ha gustado este post.

Saludos.

El problema de los ejemplos es que al ser una clase con tan solo dos atributos (o propiedades) y no hacer un uso interno ni mostrar un ejemplo más complejo, hace que el segundo sea mejor ya que es más corto y más claro.

Si estan familiarizados con la teoria del Paradigma de objetos sabran que dice q para leer y modificar atributos se debe usar settery getter, eso no implica q su pueda programar si ellos.

Cualquier paradigma q sea puramente de objetos como puede ser smalltalk siempre tendarn getter y setter

salu2

Yo solo defino properties si necesito definir algo en tiempo de diseño.

Saludos

Yo lo veo como una facilidad a la hora de escribir código, me resulta comodo tratar una propiedad como una variable más. Y, si es necesario, implementar un setter/getter, pero si no es necesario no, y de eso es de lo que me quejo, de la maní­a que tenemos a veces de complicar las cosas más de lo necesario, también por eso existe la refactorización, no?

Tienes razón cuando dices que se abusa de getters/propiedades/atributos, etc. cuando lo que habrí­a que hacer es “pedir al objeto que haga algo”, en vez de preguntarle por sus datos y hacelo desde fuera.

Muchas veces se tiene la costumbre de poner un get/set automático por cada miembro privado, automaticamente, y eso no tiene sentido, ya que se está rompiendo igual la encapsulación, pero con una máscara de OOP.

(sobre este tema merece la pena leer este artí­culo de Martin Fowler)

Sin embargo, creo que con el tema de las propiedades de equivocas. En Delphi/C# (y supongo que algún otro) dan un paso más y sustituyen los get/set por una propiedad. Esa propiedad se accede de la misma forma que una variable normal (primer error) y lo que se hace en tiempo de compilación es sustituí­r la asignación por una llamada a un set y la lectura por una llamada a su get.

Se trata de disfrazar un get/set de variable para que desde fuera no se note la diferencia (grave error).

Así­ que si dices que “las propiedades públicas deberí­an estar prohibidas”, deberí­as decir también que “los métodos públicos deberí­an estar prohibidos”, ya que al fin y al cabo una propiedad se tranforma en un get/set.

JM, has dado en el clavo, porque esos “vicios” vienen de Java, seguro.

Rastafari, me parece demasiado radical lo que propones A mi me parece más “elegante” tratar las propiedades directamente y no a través de llamadas (setNombre(‘Juan’), getNombre,...)

pkito, no puedo estar de acuerdo con lo que comentas, el cambio a realizar es prácticamente el mismo, si necesitas añadir una validación a una propiedad solo tocaras o añadiras el setter.