Java - aplicación informática para la gestión de una ebanistería que fabrica muebles

 
Vista:
sin imagen de perfil
Val: 15
Ha aumentado su posición en 4 puestos en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kymie (9 intervenciones) el 18/04/2019 11:50:13
Hola, ¿qué tal?

¿Podrían ayudarme con la resolución de este ejercicio? Estoy muy perdido.

Se necesita una aplicación informática para la gestión de una ebanistería que fabrica muebles. De los muebles quieren guardarse sus dimensiones (ancho, alto y profundo) en centímetros como números enteros. Los tipos de muebles que fabrican son mesas de oficina, mesas de taller y estanterías. De todas las mesas se quiere conocer si tienen cajonera o no pero de las mesas de oficina se quiere conocer el material con el que están hechas mientras que de las mesas de taller se quiere almacenar su grado de resistencia (un número del 1 al 10). De las estanterías se quiere guardar el número de baldas.


- Crear un diagrama de clases en el que se reflejen las clases de nuestro problema así como los atributos de las mismas y las relaciones de herencia y composición existentes en caso de haberlas.

- Implementar con Java el diagrama que has realizado (Nota: realiza un pequeño programa en Java donde se vea el uso de las clases que has implementado).





Agradezco mucho toda la ayuda que prestan, hacen un trabajo estupendo. ¡Gracias de antemano!
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder
Imágen de perfil de Kabuto
Val: 3.428
Oro
Ha mantenido su posición en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kabuto (1381 intervenciones) el 18/04/2019 12:37:44
Hola.
Es un ejercicio que no debería presentar ningún problema. Por el enunciado se intuye fácilmente que habrá una clase padre principal que se podría llamar Mueble. Se podría declarar como abstracta, aunque no es estrictamente necesario.
Esta clase tendría los atributos comunes a todas: alto, ancho y profundidad junto con sus correspondientes métodos getters y setters.

El resto de clases heredarán de esta clase dichos atributos y métodos. Estas clases hijas se podrían llamar MesaOficina, MesaTaller y Estanteria.

Cada una de estas clases aportan algunos atributos y métodos propios.

Te propongo un diagrama de clases UML que podría representar todo esto. A partir de él intenta escribir las clases en Java y si te atascar, muéstranos donde y te ayudamos a completarlo.


DiagMuebles
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 15
Ha aumentado su posición en 4 puestos en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kymie (9 intervenciones) el 18/04/2019 14:24:16
Eres muy amable, ¡gracias! A partir de ese diagrama, he hecho la clase abstracta Mueble y la clase Estantería (es la que más sencilla me resulta). En las clases MesaOficina y MesaTaller me lío. ¿Puedes echar un vistazo a lo que he hecho y corregirme, por favor?

Estanteria
Mueble
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de Rodrigo
Val: 2.041
Plata
Ha mantenido su posición en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Rodrigo (623 intervenciones) el 18/04/2019 15:18:32
El problema parece invitar a crear una clase abstracta Mesa de la que deriven las 2 mesas y que tenga cajonera al interior.

Podrias hacer todas las clases immutables y eliminar todos los metodos set de ellas.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar
sin imagen de perfil
Val: 15
Ha aumentado su posición en 4 puestos en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kymie (9 intervenciones) el 18/04/2019 17:37:14
Gracias por tu aportación, pero no sé muy bien qué son las clases inmutables. Se me hace más complicado el ejercicio.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de Rodrigo
Val: 2.041
Plata
Ha mantenido su posición en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Rodrigo (623 intervenciones) el 18/04/2019 18:18:28
Si eliminas los metodos setXxx no tienes forma de cambiar los valores internos, lo que hace a los objetos que creas immutables.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 15
Ha aumentado su posición en 4 puestos en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kymie (9 intervenciones) el 18/04/2019 19:04:43
Entiendo... Pero me resulta mucho más complicado hacerlo así, aunque seguro que no lo es. Estoy aprendiendo desde cero!

El diagrama de clases que escribió Kabuto lo veo relativamente claro, ahora me falta el código. Espero que alguien me pueda iluminar.

Un saludo y millones de gracias!!
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de Kabuto
Val: 3.428
Oro
Ha mantenido su posición en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kabuto (1381 intervenciones) el 18/04/2019 19:23:35
MesaOficina y MesaTaller serían muy similares a lo que has hecho con Estantería.

La única diferencia es que ambas van a tener un atributo común a ambas, el boolean de si tiene cajonera o no. Así que tendrás que escribir este atributo dos veces, una para cada tipo de mesa.

Por eso Rodrigo comentaba lo de hacer una segunda clase abstracta, por ejemplo llamada Mesa, que sería quien aportaría dicho atributo. Así Mesa heredaría de Mueble, y MesaTaller y MesaOficina heredarían de Mesa.

Mueble <-- Mesa <-- MesaTaller/MesaOficina

Imagina que tuvieras decenas de clases de tipo de mesa: MesaSalon, MesaCocina, MesaTetera, MesaRecibidor, MesaEscuela, MesaDespacho, MesaCamilla, MesaLaboratorio....

Para evitar tener que replicar en todas el atributo de cajonera (y sus correspondientes metodos set/get), tener una clase abstracta llamada Mesa que aporte este atributo es un gran ahorro de trabajo.
Así que aunque no lo puse en el diagrama, la verdad es que tendría mucho sentido.

Lo de hacerlos inmutables también tendría sentido para este ejercicio. Es decir, un mueble determinado una vez ha sido diseñado, se supone que no va a cambiar de medidas.
El modelo de Estantería "Kallax" de Ikea siempre tendrá el mismo ancho, el mismo alto, la misma profundidad, misma resistencia... por lo que los métodos set que alteran dichos atributos, no tendrían sentido...

O tal vez sí lo tengan... también hay que pensar en la posibilidad de que el usuario que va a usar nuestro supuesto programa para dar de alta en la base de datos los modelos de muebles, a lo mejor se equivoca al teclear el valor del ancho, o de la profundidad, ya sea por un despiste o porque le han pasado unas especificaciones erróneas.
Si resulta que las clases Mueble son inmutables y no tienen setters, no se podría corregir este atributo y el usuario tendría que borrar ese modelo de la base de datos y registrar uno nuevo ahora sí con los datos correctos.
Y esto en según que casos puede suponer ciertos problemas, porque el indice que tenía ese modelo de mueble en la base de datos, se pierde y ahora recibiría uno nuevo...

Total, que no ofrecer setters, a veces puede ser contraproducente... pero vamos, para ejercicios como este que básicamente están pensados para practicar y entender la herencia entre clases, no vale la pena pararse a pensar si los setters serían necesarios o no si estuvieramos programando para el mundo real.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Tom (1831 intervenciones) el 18/04/2019 20:50:33
De acuerdo con Kabuto, en este ejercicio (que parece que va solamente de herencia) es mejor no liarse con la inmutabilidad, que es difícil de conseguir en subclases y no puedes saber si va a ser conveniente.

Si los atributos de las clases abstractas que has definido son private no se heredarán en las subclases, así que tendrías que hacer setters (que tampoco podrían ser private) o constructores (tampoco private).

Yo recomendaría marcar los campos de las clases abstractas como protected.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de Rodrigo
Val: 2.041
Plata
Ha mantenido su posición en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Rodrigo (623 intervenciones) el 18/04/2019 22:47:53
Tom, parece contradictorio lo recomendado.

Si tienes setters no requieres cambiar private a protected.

private/protected no hace que se hereden (o no) los campos, sino que ellos sean visibles.
Los campos estan igual y puedes acceder a ellos a traves de los metodos que has generado junto a ellos.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Tom (1831 intervenciones) el 19/04/2019 10:23:25
No sé por qué te parece contradictorio. Tal y como el lo ha hecho, según la captura que ha pegado, está bien. Ha hecho privados los atributos y ha hecho setters.
Con lo cual no puede hacer el intento más simple de inmutabilidad, el que tú has propuesto, Rodrigo, ya que los setters han de ser públicos para que puedan usarlos las subclases (y cualquiera).
Así en realidad estás exponiendo un atributo privado a través de un método público.

Y añado que para el modelo simple que está haciendo, recomiendo cambiar private a protected, para que las subclases hereden los atributos de las abstractas y no sean necesarios los setters (y si quieres dejarlos ya no tendrán que ser públicos).
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de Rodrigo
Val: 2.041
Plata
Ha mantenido su posición en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Rodrigo (623 intervenciones) el 19/04/2019 15:21:43
Gracias por tomarte el tiempo de explicarlo mejor.

Como inicialmente estaba escrito parecia (para mi) que estabas apoyando la presencia de Setter y ademas el cambio de la visibilidad de private a protected.

Lo que aun no concuerdo, y has insistido en ello, es en la verbalizacion de lo que dices respecto al efecto de protected.
Dices que su efecto es que las clases derivadas "hereden los atributos". Este no es el efecto de ese modificador. El efecto de protected es que las clases derivadas puedan ver ese atributo.

El atributo sera heredado igual, y estara' usando espacio en memoria igual, sea visible o no. Las clases derivadas veran el atributo (o una copia de el) ya sea indirectamente con el metodo get (o cambiarlo con el set) o directamente, si este es public o protected, pero no dejaran de tenerlo dentro.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Tom (1831 intervenciones) el 19/04/2019 17:51:52
Bueno, Rodrigo, pero eso es como tú lo entiendas.
Copio y pego de dónde yo he sacado la información https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html (y me he permitido traducir "inherits" como "hereda"):

"A subclass inherits all of the public and protected members of its parent, no matter what package the subclass is in. If the subclass is in the same package as its parent, it also inherits the package-private members of the parent. You can use the inherited members as is, replace them, hide them, or supplement them with new members:"

"A subclass does not inherit the private members of its parent class. However, if the superclass has public or protected methods for accessing its private fields, these can also be used by the subclass.

A nested class has access to all the private members of its enclosing class—both fields and methods. Therefore, a public or protected nested class inherited by a subclass has indirect access to all of the private members of the superclass."

Puedes interpretar (o yo lo hago así) que, en el caso de Mueble y Estanteria, tal como los ha pegado Kymie, ancho es un atributo de Mueble (es privado), pero no de Estanteria. Por supuesto, Estanteria puede ver y/o asignar ancho a través de métodos de Mueble o del constructor de Mueble siempre y cuando no sean también privados (y, claro, si hay una estanteria hay un mueble y la memoria que ambos necesiten, no sé si eso viene al caso).
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 15
Ha aumentado su posición en 4 puestos en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kymie (9 intervenciones) el 22/04/2019 20:06:35
Hola de nuevo!! He estado intentando hacer la clase correspondiente a MesaOficina, pero debo fallar en algo y no encuentro el error. ¿Por favor, podrías ayudarme? Muchas gracias.

MesaOficina
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 755
Bronce
Ha mantenido su posición en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Yamil Bracho (2315 intervenciones) el 22/04/2019 20:13:35
Estas llamando setcajonera y el metodo lo definiste como setCajonera. Igual para setMaterial...
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 15
Ha aumentado su posición en 4 puestos en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kymie (9 intervenciones) el 22/04/2019 20:27:48
Gracias!!! No me había dado cuenta
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 15
Ha aumentado su posición en 4 puestos en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kymie (9 intervenciones) el 23/04/2019 12:06:00
Hola!! Ya tengo definidas las tres clases: MesaOficina, MesaTaller, Estanteria. También la clase abstracta Mueble. Ahora bien, el Main no sé resolverlo! No sé cómo llamar a los métodos, ni cómo lo tengo que utilizar. Por favor, ¿podríais decirme cómo hacerlo? A continuación os muestro lo que tengo hecho.

Main
MesaTaller
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de Kabuto
Val: 3.428
Oro
Ha mantenido su posición en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kabuto (1381 intervenciones) el 23/04/2019 23:59:45
El IDE se está quejando de que los imports NO son correctos.
¿Seguro que tienes un package llamado clase? ¿Seguro que esas clases están declaradas dentro de dicho package?

Otra cosa, aunque esto no es un error. En los constructores, para cada valor entero que le proporcionas haces un casting a (int).
Esto no es necesario, te lo puedes ahorrar.

Al escribir código Java, todo número entero que teclees, el compilador SIEMPRE lo va a considerar como un entero int, no hace falta "forzar" un cast a dicho tipo de datos.
Para Java, si pones un 5, siempre lo va a considerar un int.

Sería distinto si necesitarás pasar por constructor otro tipo de dato entero, por ejemplo un byte, entonces sí tendrías que especificarle al compilador que ese número entero, no va a ser un int, sino un byte --> (byte)5

Algo similar pasa con los números reales, es decir, lo que no son enteros.

Si tecleas un 5.0 , esto Java siempre lo va a considerar como un double, no sería necesario hacerle ninguna otra indicación.

En cambio si lo que necesitas es un float, y no un double, entonces sí tendrías que hacer, o un casting --> (float) 5.0 o también puedes indicarlo tecleando una f al final del número --> 5f

Pero bueno, esto es solo un apunte didáctico. Poner esos (int) en los constructores no te está causando ningún problema, simplemente no son necesarios.

Lo que parece que está dando problemas son los import, así que revisa en que package están realmente esas clases.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 15
Ha aumentado su posición en 4 puestos en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kymie (9 intervenciones) el 24/04/2019 13:46:03
Muchas gracias, Kabuto. Efectivamente, el package se llama "clases" y no "clase" como había puesto erróneamente.

En cuanto a los enteros de los constructores, gracias de nuevo por tu aportación. En verdad, pensé que eran necesarios, pero es totalmente innecesario ;)

Ahora sí, pongo cómo ha quedado el Main sin errores. Hasta aquí he sabido hacerlo, pero más allá no sabría continuar. ¿Cómo, cuándo y dónde debo llamar a los métodos para que me aparezca en pantalla todo lo que me piden? ¿Podrían ayudarme?

Muchísimas gracias por todo.


Main
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de Kabuto
Val: 3.428
Oro
Ha mantenido su posición en Java (en relación al último mes)
Gráfica de Java

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kabuto (1381 intervenciones) el 25/04/2019 00:40:38
Hola.

Puedes hacer una especie de menú donde preguntes al usuario que tipo de mueble quiere registrar y según lo que escoja, le pides el valor de los atributos correspondientes y lo das de alta en el ArrayList.

Si no quieres complicarte demasiado con el tema de crear menús y pedir opciones..., puedes recorrer tu listado de ArrayList que has puesto y modificar sus atributos.
Con comentarios en el código, puedes explicar porqué determinados métodos y atributos son accesibles tal cuál, y por qué otros no.

Es decir, ahora mismo tu Estantería, tus MesasMueble y tus MesaTaller, los que están en el ArrayList, están instanciados como clase Mueble para que puedas meterlos todos juntos en ese array.

Eso siginifica que puedes acceder a sus atributos ancho, alto, profundidad... porque son de la clase padre Mueble y son comunes a todos.
Pero por ejemplo no puedes acceder al atributo booleano de la cajonera, porque este es propio de las clases hijas, de solo dos de ellas además, y para poder acceder a él tendrías que reinstanciarlos a MesaTaller o a MesaOficina, según corresponda para cada objeto.

Para poder mostrar de forma rápida en pantalla sus atributos y mostrar como los vas cambiando, ayuda mucho sobreescribir para las clases hijas el método toString(), que TODAS las clases heredan de la superclase Object.
Este método consiste en que contruyes y retornas un String que sirva para describir al objeto, y así con un simple System.out podrás mostrar en pantalla sus datos.

Te pongo un ejemplo para la clase MesaTaller, tu construye el String como mejor te parezca. No es necesario usar la clase StringBuilder como he hecho yo.

1
2
3
4
5
6
7
8
9
10
11
12
@Override
	public String toString() {
 
		StringBuilder sb = new StringBuilder();
		sb.append("\nTipo de Mueble: Mesa Taller");
		sb.append("\nDimensiones: " + super.getAncho() +
				"x" + super.getAlto() + "x" + super.getProfundo() );
		sb.append(conCajonera?"\nCon Cajonera":"\nSin Cajonera");
		sb.append("\nIndice resistencia: " + resistencia);
 
		return sb.toString();
	}


Una vez tengas un método similar a este para cada clase hija, puedes crear un código como el que pongo a continuación, donde se modifica alguno de esos atributos y con comentarios se explica porque en unos casos no hay que reinstanciar los objetos y en otro sí.
De este modo se visualizan ejemplos de herencia de clases y también de polimorfismo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
public class Principal {
 
	static ArrayList<Mueble> muebles = new ArrayList<Mueble>();
 
	public static void main(String[] args) {
 
		muebles.add(new MesaOficina(136, 74, 107, true, "Madera"));
		muebles.add(new MesaTaller(110, 60, 45, false, 5));
		muebles.add(new Estanteria(90, 180, 40, 5));
 
		/*
		 * Ahora mismo todos los distintos tipos de muebles
		 * están instanciados como Mueble, que es la clase abstracta
		 * de la que todos heredan.
		 * 
		 * Si ahora queremos acceder al método toString() que hemos escrito
		 * en cada una de las clases hijas, se puede hacer sin tener que cambiar
		 * la instancia actual (Mueble) porque en realidad este método toString()
		 * se hereda de Mueble, que a su vez lo hereda de la superclase Object, que es 
		 * la clase padre de TODAS las clases en Java.
		 */
		System.out.println("\t\t\tListado de Muebles");
		for (Mueble m: muebles)
			System.out.println(m.toString());
 
		System.out.println("\nSe incrementará en 10 el ancho de todos los muebles...");
 
		/*
		 * Como el ancho es un atributo de la clase padre Mueble,
		 * también podemos acceder a él sin tener que cambiar la instancia
		 * de los objetos.
		 */
		for (Mueble m: muebles) {
			m.setAncho(m.getAncho() + 10);
		}
 
		System.out.println("\nAhora se intercambiarán los valores booleanos de los muebles"
				+ " que tienen cajonera...");
 
		/*
		 * Este atributo es própio y único de las clases hija,
		 * de hecho una de ellas, Estantería, ni siquiera lo tiene.
		 * Para acceder a este atributo, sí tendremos que reinstanciar
		 * los objetos Mueble del array.
		 * Por cada objeto, preguntaremos a que clase hija pertenece y lo
		 * reinstanciaremos para poder acceder a su atributo y modificarlo
		 */
 
		for (Mueble m: muebles) {
 
			//m.conCajonera()
			/*
			 * Esto daría error, este atributo es inaccesible si el objeto
			 * está instanciado como Mueble.
			 * Hay que reinstanciarlo.
			 */
 
			if (m instanceof MesaOficina) {
				MesaOficina mesaOfi = (MesaOficina) m; //Reinstanciamos
				mesaOfi.setConCajonera(!mesaOfi.conCajonera()); //Cambiamos el atributo booleano a su valor contrario
			}
			else if (m instanceof MesaTaller) {
				MesaTaller mesaTaller = (MesaTaller) m;
				mesaTaller.setConCajonera(!mesaTaller.conCajonera());
			}
			// Si no es MesaTaller ni MesaOfician, es Estanteria
			// en cuyo caso no hay que hacer nada, así que ni lo preguntamos...
		}
 
		//Listo, Volvemos a listar los cambios.
 
		System.out.println("\n\n\t\t\tListado de Muebles actualizado");
		for (Mueble m: muebles)
			System.out.println(m.toString());
 
	}
 
}


Esto da un resultado en consola como este:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Listado de Muebles
 
Tipo de Mueble: Mesa Oficina
Dimensiones: 136x74x107
Con Cajonera
Material Fabricación: Madera
 
Tipo de Mueble: Mesa Taller
Dimensiones: 110x60x45
Sin Cajonera
Indice resistencia: 5
 
Tipo de Mueble: Estantería
Dimensiones: 90x180x40
Número de Baldas: 5
 
Se incrementará en 10 el alto de todos los muebles...
 
Ahora se intercambiarán los valores booleanos de los muebles que tienen cajonera...
 
 
			Listado de Muebles actualizado
 
Tipo de Mueble: Mesa Oficina
Dimensiones: 146x74x107
Sin Cajonera
Material Fabricación: Madera
 
Tipo de Mueble: Mesa Taller
Dimensiones: 120x60x45
Con Cajonera
Indice resistencia: 5
 
Tipo de Mueble: Estantería
Dimensiones: 100x180x40
Número de Baldas: 5
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar

aplicación informática para la gestión de una ebanistería que fabrica muebles

Publicado por Kymie (9 intervenciones) el 29/04/2019 10:30:56
Muchas, muchas gracias!!! Al verlo así escrito, no me parece tan complicado!!! Gracias a todos por los consejos y las puntualizaciones. He aprendido un montón!!!

Un saludo!!!
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar