Java - Funciones con Retorno y Parametros

Que tal colegas del foro, siguiendo los pasos de principiante en esto de java, tengo otra duda que es la Orientacion a Funciones, les expongo el problema:

Elabora un programa, utilizando funciones que realice
las siguientes conversiones:

1. pesos a dolares
2. dolares a euros
3. euros a libras
4. pesos a yen

para la primera opcion utilice un funcion con parametros
y sin retorno. la codicion para la conversion son cantidades
positivas y no mayores a 5000.

la segunda opcion se implementa como funcion con retorno y con
parametros. la conversion se realizaran si la cantidad de dolares
se encuentra entre 50 y maximo 7000.

la tercera opcion es una funcion sin parametros y con retorno.Solo
cantidades postitvas son aceptadas.

la ultima funcion se implementa sin paraemtro y sin retorno la cantidad
de pesos debe estar en entre 700 y 15000.

el muenu debe repetir hasta que el usuario seleccione la opcion salir,
para terminar el programa.

Mi programa mal empezado lo tengo asi a lo poco de lógica dado el problema: Siento que esta mal estructurado
Como siempre agredezco a quien me ayuda y a los que toman parte de su tiempo para leer.

Hola. En mi opinión hay varias cosas que deberías tomar en cuenta. La primera es saber la diferencia entre variables y atributos propios de la clase. Yo no pondría entrada, cantidad y opcion como atributos ya que no son de la propia lógica del problema (al menos opcion y entrada son de interfaz) y cantidad es un parámetro a nivel de funciones. Lo otro que veo es que mezclas el codigo propio del problema con la entrada de datos ya que en cada función tomas (o intentas tomar) valores de la consola. Estas dos cosas deben separarse bien para que no haya dependencia entre ellas (imagina que mañana en vez de consola lo tomas de una GUI con campos de entrada, ya habría que cambiar la implementación de las funciones cuando en primera instancia la responsabilidad de las funciones es realizar conversiones, no capturar datos y realizar conversiones (te recomiendo el principio de diseño one rule one place). Te pongo un código a partir del tuyo. Aquí no he tomado en cuenta temas de validación ni factores de conversión y en el switch faltan otros casos que se completan de forma análoga a lo que puse. Además la entrada de datos puede mejorarse con saltos de línea, etc. Es para que tengas una mejor estructura para seguir :). Saludos y suerte!!!

Gracias por contestar Alain y tienes razón por eso comente que tenia mal estructardo el código. Pero aun me falta aprender cuando una variable se convierte en instancia. Se me es muy confuso java, pero me gusta y entramos en materia con objetos se me hace mas entendible.


Nada tengo un duda porque en la parte de la instancia de la clase menuConversion esta en Private y no Public, aun no se la diferencia de una a la otra, entiendo que son clases privadas y publicas per en si su funcion cual es. Gracias por despejar mi duda.

practicare tu código y pondre en practica lo que me aconsejas buena noche.

Hola Felipe, modifiqué un poco el código de ayer para ver si logro despejar algunas de tus dudas.
Lo primero que hice, siguiendo la línea que te comentaba ayer, fue separar el programa en 2 clases: una clase llamada ConversionDivisas encargada de la lógica del problema y otra llamada Principal encargada de entrada/salida de datos, igual por consola. Ventajas de este enfoque: separación de responsabilidades. Mientras que la clase Principal se ocupa de la entrada/salida de datos, la clase ConversionDivisas tiene un solo propósito: realizar las conversiones. En algún momento la clase Principal "pedirá ayuda" a la clase ConversionDivisas para que se haga la conversión del dinero (puesto que no es su responsabilidad) y poder mostrar el resultado por consola. Es lo que se conoce en la Programación Orientada a Objetos (POO) como "paso de mensajes". Si mañana la entada/salida de datos se hace mediante una GUI la clase ConversionDivisas no se ve afectada, solo Principal. De forma análoga si mañana hay que cambiar algo en la lógica del problema (un factor de conversión por ejemplo) la clase Principal no se ve afectada. En este ejemplo puede que no le veas la utilidad pero en sistemas más grandes sí que se hace necesario tener componentes con bajo acoplamiento (Separation of concerns y Single responsability son dos principios de diseño en los que se basa esto). Igual esto ya lo sabes :).

Te pongo el código:

public class ConversionesDivisas {

public double PaD(double cantidad){
return cantidad; //multiplicar por el factor de conversion
}

public double DaE(double cantidad){
return cantidad; //multiplicar por el factor de conversion
}

public double EaL(double cantidad, double factorConversion) {
return cantidad * 24.63;
}

private double PaY(double cantidad, double factorConversion){ //lo puse private para que entiendas la diferencia, debe ser public
return cantidad * 0.17;

}
}

import java.io.IOException;
import java.util.Scanner;

public class Principal {

private static void menuConversion(String opcion, Scanner scanner, ConversionesDivisas conversion){
double cantidad, valor = 0;

switch(opcion){
case "1":
{
System.out.println("Indique la cantidad de pesos");
cantidad = scanner.nextDouble();
valor = conversion.PaD(cantidad);// aqui invoco un metodo publico de la clase ConversionesDivisas
System.out.println("La cantidad de dolares es:" + valor);
}
break;
}
}

public static void main (String[] Args) throws IOException{
String opcion = " ";
ConversionesDivisas objeto= new ConversionesDivisas(); //aqui estoy creando una instancia de la clase ConversionDivisas
Scanner scanner = new Scanner(System.in);
do {

System.out.println("Qué deseas realizar");
System.out.println("1- Conversión de Pesos a Dolares");
System.out.println("2- Conversión de Dolares a Euros");
System.out.println("3- Conversión de Euros a Libras");
System.out.println("4- Conversión de Pesos a Yen");
System.out.println("S- Salir");
//System.out.println("Ingrese un dato válido");

opcion = scanner.next();
menuConversion(opcion, scanner, objeto);

}while (!opcion.equalsIgnoreCase("S"));

System.out.println("Adios");
}

}

Verás que en uno de los comentarios en la clase Principal te puse cómo se creaba un objeto en Java (para este caso en específico no era necesario pero para ilustrar). Notarás que en la clase ConversionDivisas he quitado el modificador static de los métodos de conversión, porque no tienen sentido si se va a acceder a ellos mediante una instancia y no desde la propia clase, como en el código que puse. No obstante he notado que algunos colegas programadores tienden a ponerlo mucho y me atrevería a decir que no saben cuál es su uso o cuándo es mejor usarlo (te recomiendo tener claro esto). En otra de las líneas te puse una invocación a un método público de la clase ConversionDivisas usando la instancia creada (lo que te comentaba anteriormente de paso de mensajes). Aquí aprovecho para aclarar que si en la clase ConversionDivisas el método hubiera estado como private no era posible invocarlo (como es el caso de PaY puesto a propósito).
Por qué habría de ser un método private? Pues precisamente por eso, porque no forma parte de la interfaz de comunicación de la clase, es decir, no se va a invocar desde otro punto en el programa que no sea la propia clase donde está implementado.
Siempre todas las funciones/métodos no se invocan desde otro punto del programa? No. En este ejemplo menuConversion solamente se va a usar en la clase Principal, por eso lo declaré private.
Si lo declaro public está mal? No.
Y qué ventajas me da private sobre public? Pues que si tú quieres que un método no se pueda invocar desde otra clase, pues lo declaras como private y si desde otra parte escriben "instancia." (en el ejemplo: conversion.PaY) va a dar error (recuerda que no siempre trabajas sólo, pueden haber otros programadores que no sepan que ese método no se debe utilizar fuera de su clase). Java también tiene otros modificadores de visibilidad que te recomiendo eches un vistazo, tanto a nivel de funciones como de clases (por cierto las clases en Java no son private). Te lo recomiendo porque igual algunos programadores tienden a poner todo public sin saber. Hay un principio de la POO bastante relacionado con esto que es el encapsulamiento (o encapsulación también lo he visto con ese término).

Creo que no se me ha quedado nada de tus dudas. Espero haberte ayudado. Saludos y ánimo!!!!

Muchisimas gracias Alain con esto acabas de aclarar mis dudas de una manera más clara, algo que el maestro no lo hizo y eso que el no dio todo lo relacionado a Funciones, porque ahora el maestro que nos da POO nos hizo un examen similar a este y pues si andabamos perdidos y fue lo que menciono que necesitamos saber diferencias las calses,objetos,funciones/atributos e instancias porque si no ibamos a valer queso.

Pero con lo que me acabas de decir se me aclaro mucho, solo falta amprenderlo y saber en que meomento puedo aplicar las instancias y demas cosas.Muchas gracuas nuevamente buen día.