Foros aprenderaprogramar.com
Didáctica y divulgación de la programación

Hola Sniper, te indico las cosas a mejorar (que hay bastantes) en este código:

Clase CantanteFamoso

public void setNombre() { nombre = entrada(); }


La idea está bien y demuestra que tienes cierta soltura en el manejo de código. Sin embargo, aunque como idea pueda entenderse, desde el punto de vista de la programación no es algo adecuado. Oirás a muchos programadores hablar del principio KIS ó Keep it Simple. Otros lo alargar como principio KISS ó Keep it Simple Stupid (esto es más grosero). El asunto es que el código debe mantenerse simple.

El código que has planteado es un método que en realidad no hace otra cosa que llamar a otro método. Hay varias cosas que no son adecuadas en el planteamiento hecho: por un lado, ¿para qué tener un método que únicamente llama a otro? ¿No sería más lógico tener el código directamente sin tener que estar llamándolo?

Por otro lado contraviene otro principio básico de la programación: no inventar de nuevo la rueda. Este principio lo que dice es que hay muchas cosas que los programadores usan y alcanzan el nivel de "convención" entre los programadores, es decir, que todos los programadores trabajan igual porque es algo digamos que todo el mundo acepta.

Un método set, de acuerdo con el convenio tácito entre todos los programadores, es un método que recibe un parámetro para establecer el valor de un atributo. En el método que has planteado no se recibe un parámetro, por tanto va contra el convenio de la comunidad de programadores. No significa que esté mal, pero sí que estás yendo en contra de unos principios básicos de la programación que darían lugar a que cualquier programador que mirara tu código no lo valorara positivamente, es decir, transmitirías que no te atienes al convenio y eso genera rechazo. Tu jefe, o tu profesor, o quien fuera, te dirían... que no, que está bien tratar de innovar cuando se pueda, pero que eso lo corrijas.

En este otro método:

    public void setDiscoConMasVentas()
    {
     discoConMasVentas = entrada();
    }

Tenemos una repetición (también llama al mismo método). En algunas ocasiones, por ser necesario, se repite código. Pero en general también un buen programador mirará con mala cara la repetición de código.

Luego tenemos este método:

    public String entrada()
    {
      Scanner escaner = new Scanner(System.in);
      return escaner.nextLine();
    }

Tampoco encaja bien en la filosofía de la orientación a objetos. En POO cada objeto tiene sus responsabilidades delimitadas. ¿Es lógico que un objeto CantanteFamoso tenga un método que sirva para pedir, de forma genérica, una entrada de teclado? Más bien no, un objeto CantanteFamoso debe limitarse a almacenar la información de un cantante famoso y a tener métodos para gestionar y hacer cosas con dicha información. Pero entre sus responsabilidades no estará, normalmente, el pedir datos al usuario. Esta responsabilidad se debería delegar en otra clase, que podría denominarse EntradaTeclado ó GestorEntradasUsuario ó ... que sería un objeto cuyas responsabilidades, de forma lógica, incluirían el que pida una entrada de teclado.

En programación orientada a objetos tenemos objetos, cada uno con sus tareas... el programa se construye creando objetos y haciendo que interaccionen entre ellos.



Clase ListaCantantesFamosos

Tenemos el constructor:

    public ListaCantantesFamosos(String nombre, String discoConMasVentas)
    {
      listaDeCantantesF = new ArrayList<CantanteFamoso>();
      addObjetoCantante(nombre, discoConMasVentas);
    }

Si esto lo mira un programador no entenderá lo que tratas de hacer, o pensará que estás tratando de inventar la rueda. Un constructor sirve para inicializar los atributos. En este caso la tarea la cumple la primera línea. Si tuviéramos un constructor que recibe parámetros, el parámetro a recibir debería ser un ArrayList, precisamente porque ese es el atributo de la clase. No se atiene a la convención que en esta clase se reciban los datos de un elemento de un ArrayList y se añadan al mismo. Esto no es el objetivo de un constructor. Aquí estás mezclando ideas de un método con ideas de un constructor. La solución es hacer las cosas lo más simples posibles.

      public ListaCantantesFamosos()
    {
      listaDeCantantesF = new ArrayList<CantanteFamoso>();
    }

Con esto resuelto: más sencillo, tenemos que escribir menos, más elegante, y nos atenemos a la convención de la comunidad de programadores.

Aquí hay otra cosa que en cierta manera llama la atención:

      int i = 0; 
      for(CantanteFamoso datos : listaDeCantantesF)
      {
        System.out.println(i + ": " + datos.getNombre() + " - " + datos.getDiscoConMasVentas()); i++;
      }

Un for extendido es un bucle que no usa de índice para su recorrido. Sin embargo estás introduciendo el índice i. De esta manera se mezcla un bucle que no usa índice con un índice: extraño, no es que esté mal, pero llama la atención.

Si queremos usar un índice, lo lógico es usar un bucle con índice, algo así como:

for (int i=0; i<listaDeCantantesF.size(); i++) {
System.out.println(i + ": " + listaDeCantantesF.obtenerObjetoEnPosicion(i).getNombre() + " - " + listaDeCantantesF.obtenerObjetoEnPosicion(i).getDiscoConMasVentas());
}


Aquí otra cosilla a comentar:

      CantanteFamoso objeto;
      objeto = listaDeCantantesF.get(posicion);
      objeto.setNombre();

Podemos escribir:

listaDeCantantesF.get(posicion).setNombre();

Es decir, condensar tres líneas en una.



La clase con el método main no la he revisado, simplemente decirte que debes acortarla y repensarla. El método:

  private static String entradaNombre()//Crea una entrada personalizada para el campo nombre de un objeto tipo Cantante
  {
    System.out.println("Nombre: ");
    return entrada();
  }

¿Es un método para manipular el campo nombre de un objeto Cantante? No debe estar ahí ¿Por qué? Porque la responsabilidad de los campos es de las clases, por tanto la clase con el método main no tiene por qué tener un método para hacer algo que es responsabilidad de un objeto Cantante.

Veo más métodos con el mismo problema ¿están en la clase donde está la responsabilidad?

Ha sido un poco extenso, espero que al menos ayude a sacar algo positivo. Saludos

Tienes que tener en cuenta la versión de java con la que estés trabajando, Si usas Java 8 o superior, se recomienda el uso de las clases incluidas dentro del paquete java.time (http://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html), en versiones anteriores el trabajo con fechas puede resultar distinto. Según la versión que vayas a emplear tendrás que estudiar qué clases y métodos pueden resultarte útiles. Saludos.

Hola, para pegar código usa por favor el botón # del foro, una vez lo pulses pega el código entre las etiquetas [ code] ... [ / code] y pulsa previsualizar.

El error que comentas parece deberse a que estás introduciendo Strings sin comillas. Para usar un método set y pasarle información tienes que escribir entre comillas.

Por ejemplo "cadena" es correcto pero cadena no porque le faltan las comillas.

Saludos,

Hola, el programa está bien. Lo que no estás haciendo bien es pegar el código en el foro, una vez pulsas el botón # tienes que poner el código entre las etiquetas [ code ] ... [ / code]

Por ejemplo [ code ]  Aqui el codigo [ / code ]

Antes de publicar pulsa previsualizar y comprueba que se vea bien.

Saludos.

Hola, antes de nada comentarte que es preferible que publiques dos temas en el foro, uno para cada ejercicio, en lugar de incluir código comentado ya que hace más difícil el compilarlo y revisarlo.

Sobre el ejercicio CU00665B: está todo correcto, bien trabajado.

Sobre la duda:

lista1.verTodosLosNombresEnLaLista();//que desventajas tendria esta sintaxis: ? System.out.println(lista1.verListadoCompleto());

Ambas sintaxis serían aceptables. Me parece mejor la primera porque un método se encarga de realizar el trabajo y no dependes de una instrucción como System.out.println. Al no depender, es el propio objeto quien se encarga de resolver sus necesidades sin tener que ser ayudado por otras instrucciones auxiliares.

Hola, en el segundo menú parece que el efecto de retrasar la desaparición del menú se logra con este código:

        // A private function for delaying the mouseOut function
        var delay = function(ev,ob) {
            ob.hoverIntent_t = clearTimeout(ob.hoverIntent_t);
            ob.hoverIntent_s = 0;
            return cfg.out.apply(ob,[ev]);
        };

Que tal como indica "introduce un retardo en el evento mouseOut. La idea sería tratar de aplicar esta función al otro menú, pero si te fijas en el código del primer menú, está cargando jQuery desde internet con:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>

Tendrías que tener jQuery en tu servidor para modificar el código y crear el efecto deseado (habría que ver con calma cómo conseguirlo).

Sobre:

** Duda opcional **

En el primer menú se aplica el ID y CLASS a una capa <DIV>, y dentro de ella esta la etiqueta <Ul> que no tiene ningún ID y CLASS, si quiero poner ese ID y CLASS a la etiqueta "<UL>" deja de funcionar el menú.

Respuesta: es posible, depende de cómo esté programado el código. Si el código está programado para buscar un elemento UL dentro del elemento raíz (el dív) y tu cambias haciendo que el elemento raíz sea un UL, intentará buscar un UL dentro del raíz y no lo encontrará, por lo que no funcionará. Pero esto depende de cómo esté programado el código, puede que funcione de forma distinta a esta que te he comentado. Para comprobarlo tendrías que probarlo.

El segundo menú tiene un ID y CLASS en la etiqueta <UL> directamente sin DIVS, si pongo ese código en una etiqueta superior,"<DIV>" el menú no funciona más.

Respuesta: pasa exactamente lo mismo: depende de cómo esté programado el código.

Lo que dices de modificar el menú superfish, habría que estudiarlo con calma.

Saludos.

Hola Toni, todo correcto. A modo de curiosidad, para las personas que intenten compilar el código, cuando intentamos hacerlo con BlueJ se obtiene el siguiente mensaje (error package-name-invalid):
 
You have changed the package statement to a package which does not exist in this project. If you wish to move this class to another package you must create the destination package first. The package statement has been reverted back to its original form.

Que lo que viene a decir es que antes de incluir código declarando packages, hemos de crearlos previamente en BlueJ. Si no los creamos, BlueJ anula la declaración de packages o emite errores. A veces (sobre todo si se trata de una única clase) es irrelevante que BlueJ anule el package. En cambio, si se trata de distintos packages con clases interrelacionadas sí puede resultar relevante.

Para solucionar esto con BlueJ, hay que crear previamente la estructura de packages.

Saludos.

Sí, por eso, es que los sockets se usan para la comunicación cliente - servidor...

Hola, son atributos de clase tanto los tipos primitivos como los objetos. Y normalmente se establecen métodos get y set tanto para los tipos primitivos como para los objetos. En el caso de trabajar con objetos, los set reciben un objeto e igualan el atributo al objeto recibido. En el caso de los get, devuelven un objeto (el atributo).

Hay distitas variantes pero la idea general es esta, y esto sería lo que le falta a tu código.

Saludos.

Hola, el código no está bien planteado. Te recomiendo que vuelvas a leer las entregas del curso anteriores.

En una clase se almacena información en sus campos o atributos, y por otro lado se realizan operaciones con sus métodos. Tú estás mezclando indebidamente ambos conceptos, por ejemplo float HolaIntroduceDuracionDeCancion; estás diciendo que la clase almacena un número decimal que se llama HolaIntroduceDuracionDeCancion, pero esto no es información, esto será una operación que realice la clase, por lo tanto no debe ir declarada como atributo sino como método.

Por otro lado el ejercicio no te pide que generes el código de los métodos, sino tan solo la signatura e indicar si son procedimientos o funciones.

Revisa el concepto de signatura y revisa los conceptos previos.

Saludos.