Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Visibilidad de objetos de una clase
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Programmation Orientée Object
Divers
Thread ID:
01125702
Message ID:
01127252
Vues:
13
Hola, Hugo.

>Aparentemente soy el único al que no le gusta el uso de access y assign por estos pagos <g>, yo trato de usarlos lo menos posible, y solamente cuando uso clases visuales y/o no tengo otra alternativa, cuando diseño classes en código, generalmente hago:
[snip]

>Las ventajas que le veo son:
>
>1) Es explícito, no queda oculto el codigo, sólo por argumentar, digamos que en el _access de la propiedad 1 accedemos las propiedades 2, 3 y 4, y le asignamos a su vez valores a las propiedades 5, 6 y 7, todas a su vez tienen, por supuesto, sus access y assigns que a su vez acceden y/o cambian los valores de otras propiedades, que por supuesto tienen access y assign, seguir, o mejor dicho adivinar el flujo del programa se me hace complicado <g> (No es que con los get/set no vaya a tener este problema, pero para mi es mas claro tenerlo asi, y entiendo es un punto de vista muy personal)

Bueno, como dices, es básicamente lo mismo. Claro, podrías escribir un SetCustomerData que configure varias propiedades del cliente, pero al fin y al cabo también puedes poner una propiedad pública (con accesores) CustomerData que haga lo mismo. También me deja dudas el hecho de tener que ser explícito. Si tengo que ser explícito puede ser porque no estoy encapsulando lo suficiente. Si me abstraigo lo suficiente no debería importarme si el acceso agrega o no lógica alguna.

>2) Me parece útil poder retornar una variable de éxito cuando se trata de cambiar una propiedad, claro esto se podría hacer
>
>	myObjecto.myPropiedad = myNuevoValor
>	if myObjeto.myPropiedad # myNuevoValor
>		* Fallo
>	endif
Aquí estamos en desacuerdo. Para mi el inicializar un valor no deberia tener un retorno, porque no preserva la semántica de una acción. En todo caso, si fallara debería levantar una excepción, que me parece un método más limpio en este caso.

>Pero de nuevo estariamos llamando innecesariamente al myPropiedad.Access si lo hubiera.
>
>La ventaja (única?) que le veo a los métodos Access y Asign (bueno, son dos?) son la sintaxis que no cambia lo que agrega la posibilidad de crear estos métodos a código ya existente, pero... incluso no estoy tan seguro que tan bueno es esto...
>
>Bueno, ese es mi punto de vista que puede estar completamente equivocado y no se si tiene mucho sentido para ustedes.
>
>Por otra parte, Ricardo, yo nunca usaría propiedades públicas (solo las uso en las clases visuales)

¿Porqué no usar propiedades públicas con accesores? ¿Tus métodos Set y Get no son públicos a veces? Para mi es exactamente lo mismo a nivel de visibilidad, pero no semánticamente. Cambiar o leer un campo debería ser sólo eso, sin tener que disparar un comportamiento (método).

En esto prefiero .NET a Java. La implementación de propiedades me resulta más limpia, y en el caso de VFP es bastante buena si se la maneja apropiadamente. Definitivamente, me anoto del lado de Access y Assign.

Como siempre, es un placer discutir contigo.

Un abrazo,
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform