Argumentos opcionales

[jorgelujanm]

Existen los argumentos opcionales en las funciones (métodos) java?

[chuidiang]

Hola:

No existen en java. La única solución es definir el método varias veces, en cada una con parámetros distintos. El código sólo tienes que hacerlo en el que lleva más parámetros. Los otros métodos basta con que llamen al de más parámetros añadiendo los parámetros opcionales con su valor por defecto.

Se bueno.

[GreenEyed]

Ummm depende. A partir de Java 5 existen los varargs, asi que si tienes argumentos opcionales que son del mismo tipo y todos van al final del metodo... pues podría hacerse así.

Pero como reglar general, lo que dice chuidiang: no.

S!

[elAntonie]

Wenas

Si no tienes java 5 como dice greeneyed, no existe. Podrias simularlo pasandole un ArrayList con todos los parametros que necesites.

Pero eso es un poco mas complicado y dependiendo de la situacion te merecera la pena o no.

Saludos.

[jorgelujanm]

Muchas gracias a los 3, soy nuevo en java aunque no en programación ya que poseo más de 15 años en el tema. Por un lado soy programador en C y eso ayuda pero también desarrollo en VB lo que añade métodos poco elegantes a la programación.
(Disculpas a los fans de Microsoft).
Java es un excelente lenguaje y estoy seguro que aplicando patrones de diseño y una buena arquitectura se puede prescindir de los parámetros opcionales.
He notado que tampoco existen los Property sub o functions. Pero confío en la gente de sun Microsistems.
Desde ya les estoy muy agradecido a los tres. Thaks.

[otalvarocardona]

a mi me parece que un function o un sub se puede igualar completamente a un método en java

[jorgelujanm]

Hola otalva..., quizá me expresé mal.

En Visual Basic hay una estructura llamada "property" que se emplea como procedimiento de propiedad: Código de la clase "Persona" en Visual Basic:

' Miembro de privado
Private m_nombre as string

'Constructorn on parametrizado (ufa!!!)
Private Sub Class_Initialize()

m_nombre = "Juan"

End Sub

' Procedimiento de lectura (función)
Public property get nombre() as string

nombre = m_nombre

End Property

' Procedimiento de escritura (sub y opcional)
Public property let nombre(nuevo_nombre as string)

m_nombre = nuevo_nombre

End Property

' El siguiente código está en un módulo estándar (no hay en Java).
' que no es una clase pero puede ejecutar un procedimiento main
' Similar al static public void main(String args[]) pero en Visual Basic.

Public Sub Main()

' Declaración de referencia y creación de instancia
' Se puede hacer por separado y no existen constructore parametrizados...
' ... ojo!!! parametrizado.
Dim p as new Persona

' Mostrar el nombre en un cuadro o ventana
' Aquí se emplea el property get...
Msgbox p.nombre

' Modificar el nombre
' Aquí se emplea el property let
p.nombre = "Pedro"

End Sub

Si alguien sabe cuál es el costo de su empleo (a nivel de compilador y rendimiento en Run Time), estaría bueno. End Sub Bien, en Java no hay

Aclaro que no estoy despreciando a Java, al contrario. Pero me gustaría saber, como cosa personal, las razones por la cuales Java no cuenta con características como los procedimientos de propiedad. Aguante Java.

[GreenEyed]

En realidad la posibilidad de añadir este tipo de estructuras se esta discutiendo para Java 7, no esta decidido todavia si se incluira o no, pero el por que todavia no está...

Java intenta ser un lenguaje "claro" en todo momento para que sepas lo que estas haciendo, y en esta caso al ver p.nombre en realidad no sabes si estas accediendo a la propiedad directamente o si estas accediendo a traves del "setter", que es como se llaman en Java por que se usa, por convenio, setNombre().

Así que entre eso y que escribir setNombre(x) no es tan dificil comparando con .nombre = x, pues no está.

Es decir, la filosofia inicial de Java tendía más a "si ya hay una forma de hacerlo, no incluyas otra" y "no a las soluciones ambiguas", lo cual ayuda a la hora de hacer codigo robusto y mantenible, aunque es más "coñazo" de escribir. Ahora se esta perdiendo un poco esa filosofia, lo cual a mi personalmente me parece una pena.

Por cierto que Groovy, lenguaje dinamico derivado/relacionado con Java si tiene ese tipo de construcciones .

S!

[jorgelujanm]

Desde el punto de vista de notación, es más fácil x.nombre = "Juán" que x.setNombre("Juan");.

Desde el punto de vista de comprensión, el encapsulamiento nos dice que nadie tiene que saber si x.nombre es una variable o un setter. A los fines de la seguridad se oculta el qué del cómo.

Pero, al ver que en cosas tan importantes como las Interfaces (polimorfismo y esas cosas) no hay forma de implementar setters (en los lenguajes que lo tienen) se convierten en algo problemático.

Los que estudiemos diseño sabemos que las interfaces son los límites de los módulos y son las articulaciones que permiten implementar múltiples soluciones... aislan el qué del cómo y en eso no habría una alta cohesión y un bajo acoplamiento que es base del diseño.

Yo creo que debe ser por eso.

[GreenEyed]

Desde el punto de vista de notación, es más fácil x.nombre = "Juán" que x.setNombre("Juan");.

No digo que sea más o menos fácil. Sólo digo que a nivel practico no hay una gran diferencia (5 caracteres extra) y que como motivo para introducir ese cambio.... es pobre. Es puro "syntactic sugar".

Y no es cuestion de encapsulamiento o no lo que digo. Es por no saber si está encapsulado o no. con p.getXXX() sabes que esta encapsulado sin mirar nada mas. con p.XXX tienes que buscar si existe o no el metodo getXXX() o en caso contrario estas accediendo directamente a la variable sin encapsulamiento. Y eso es ambigüo y la ambigüedad no es deseable.

No entiendo a que te refieres con lo de las Interfaces.

[jorgelujanm]

Iniciado por GreenEyed

No entiendo a que te refieres con lo de las Interfaces.

Las interfaces son contratos con operaciones que las clases que implementan dichas interfaces deben cumplir. Son uno de los mecanismos que mejor garantizan los principios básicos de la programación orientada a objetos: El polimorfismo.

"Una interfaz múltiples métodos"

También, las Interfaces, son un mecanismo que permite garantizar el principio de Liskov; este principio del diseño dice que "Toda Generalización debe poder ser reemplazada por sus especializaciones" o "Toda superclase debe poder ser reemplazada por por sus sub-clases".

En cuanto a la diferencia entre x.nombre y x.getNombre() te paso a explicar una enorme diferencia: La construcción de árboles de objetos con raíz.

no es lo mismo colocar:

Empresa.Administracion.Deudas.Informes.imprimir()

Que:

Empresa.getAdministracion().getDeudar().getInforme s().imprimir();

Es decir,... que la notación en forma de getters y setters es más clara cuando se tiene que mantener la diferencia entre un objeto rama y un método de un objeto de esa rama.

Supongo, sin ofender, que no tenés mucha experiencia en ramas de objetos. Pero eso no es requisito para ser buen programador ni mucho menos. Sólo digo que en Java se debe implementar lo mismo de una forma diferente.

Básicamente, todo proyecto responde a dos conjuntos de requerimientos:

Funcionales: Necesidades puntuales y específicas tales cómo "alta de clientes, modificaciones, etc".

No funcionales: Esas son las peores: "Trazabilidad, velocidad, seguridad, persistencia, estabilidad, modularidad, extensibilidad, etc."

En el caso de los Requerimientos no funcionales, no importa qué tan bueno programador seas si no sabés diseño de sistemas y me refiero no a sistemas informáticos o software necesariamente. Y para garantizar esas cosas como la extensibilidad o la solidez se necesitan implementar mecanismos que van mucho más allá de los lenguajes. Por eso te recomiendo ver cosas como Liskov, Patrones de diseño y Abierto/Cerrado.

Mi paso por java (espero quedarme a vivir) apunta a utilizarlo en virtud de esos requerimientos que son los más importantes y por eso cuestiono las herramientas y mecanismos de java.

Disculpá lo extenso y seguiré aprendiendo Java que creo es uno de los pocos lenguajes que tienen los mecanismos necesarios para crear un buen sistema.

[chuidiang]

Hola:

Supongo que GreenEyed sabe lo que son las interfaces. Lo que creo que no entendía es esta frase

Pero, al ver que en cosas tan importantes como las Interfaces (polimorfismo y esas cosas) no hay forma de implementar setters (en los lenguajes que lo tienen) se convierten en algo problemático.

más que nada, porque a mí también me ha resultado extraña ... . No sé en qué impiden las interfaces poner setters y getters...

Por cierto, no sabía lo de los varargs...

Se bueno.

[jorgelujanm]

Perdón por no comprender entonces:

Aclaro la cita:

En ningún lenguaje que yo conozca (Java, C#, C, C++, Visual Basic, .net, etc) se permiten setters o getters en una interfaz.

[TolaWare]

Iniciado por jorgelujanm

Perdón por no comprender entonces:

Aclaro la cita:

En ningún lenguaje que yo conozca (Java, C#, C, C++, Visual Basic, .net, etc) se permiten setters o getters en una interfaz.

En realidad se permiten colocar, pero no se les puede implementar ya que los métodos de las interfaces son abstractos (y además porque la interfaz no tiene atributos, por lo que no habria que setear/getear).

Me parece que este hilo se fue totalmente de su tema inicial.

[jorgelujanm]

Estoy totalmente de acuerdo.

Este foro es genial.

[GreenEyed]

Iniciado por jorgelujanm

...Supongo, sin ofender, que no tenés mucha experiencia en ramas de objetos...

Naaaa... 11 años programando con Java y antes de eso algun tiempo con SmallTalk etc. así que apenas entiendo de que va la cosa.

Y los interfaces no es que no se permitan "implementar" setters o getters... es que no se puede implementar nada. Y si, como dice Chuidiang alguna idea tengo de que son los interfaces, es la frase esa a la que no le veia/veo el sentido.

Lo que pasa es que tanto principio teorico de diseño está muy bien para dar charlas, pero los sistemas hay que implementarlos en la realidad, ya que ahi es donde los sistemas han de funcionar. La tozuda realidad suele inyectarle a uno una buena dosis de pragmatismo .

S!

[TolaWare]

Iniciado por GreenEyed

Naaaa... 11 años programando con Java y antes de eso algun tiempo con SmallTalk etc. así que apenas entiendo de que va la cosa.

Y los interfaces no es que no se permitan "implementar" setters o getters... es que no se puede implementar nada. Y si, como dice Chuidiang alguna idea tengo de que son los interfaces, es la frase esa a la que no le veia/veo el sentido.

Lo que pasa es que tanto principio teorico de diseño está muy bien para dar charlas, pero los sistemas hay que implementarlos en la realidad, ya que ahi es donde los sistemas han de funcionar. La tozuda realidad suele inyectarle a uno una buena dosis de pragmatismo .

S!

Pienso que el diseño de software es necesario. Hoy en día estoy en un proyecto de software (en JSP) y justamente hoy detecte algunos bugs bastantes jodidos que se hubiesen evitado con un poco de diseño preliminar.

Vale aclarar que el único diseño que ahí, es el de diagramas de clase de negocio y está hecho porque yo lo llevo y mantengo.

Se pueden evitar muchísimos dolores de cabeza haciendo un diagrama de secuencia antes de programar un caso de uso. Muchos lo ven como una pérdida de tiempo, pero desde mi punto de vista es una inversión que inicial de tiempo que te ahorrará bastante tiempo en el futuro.

EL dilema está en que hay que saber hasta donde enroscarnos con el diseño. Hay que analizar que cosas es necesario analizar, que componentes del programa pueden ser críticos.

En resumen hay que encontrar un balance entre diseño e implementación. Como dijo chuidiang en el post anterior:

Lo que pasa es que tanto principio teórico de diseño está muy bien para dar charlas, pero los sistemas hay que implementarlos en la realidad, ya que ahí es donde los sistemas han de funcionar.

[GreenEyed]

No he dicho que el diseño no sirva o que no haya que hacerlo, valgame Dios. Sólo que las discusiones teóricas hay que despues adaptarlas a lo práctico y, como bien dices tú, hallar un equilibrio.

Aplicar patrones de diseño "por que sí" es tan malo como programar sin pensar y basta verlo en tus propias palabras. Crees que es bueno aplicar X por que te ahorrará dolores de cabeza... en el mundo real, no por que alguien escribiera en un libro que es lo mejor despues de la rueda así por que sí sin ninguna base.

S!

[elAntonie]

Ambos teneis razon, en parte.

Todo eso del analisis, diseño, captura de requisitos, documentacion ... si se llevar a cabo se ahorrarian muchos dolores de cabeza.

Pero ya sabeis cual es la frase que prima en este mundo "Tiene que estar para ayer".

El dia que me encuentre con un proyecto que tenga eso, hare puenting (y tengo vertigo)

Saludos.