clase objeto y la clase string

que son las dos clases principales de Java, porque Java tiene muchas, pero son las dos
principales sobre las cuales nos vamos a basar para crear, digamos, programas un poco más
complejos.

[01:21] ¿Que más vamos a ver? vamos a ver cómo organizar nuestro código en la estructura
que usa Java por patrón, en este caso los llamados paquetes. ¿Qué más vamos a ver? Cómo
documentar el código. Es muy importante tener documentación del código para que otros
programadores sepan lo que hace el código, la funcionalidad que debería tener y no romperla
cuando agreguen futuros features.

[01:47] ¿Y finalmente qué más vamos a ver? Cómo personalizar, digamos nuestros objetos,
para que sean accesibles, para que nuestros atributos sean accesibles desde otros objetos
usando modificadores de acceso.

Usando Paquetes

en el mundo real los proyectos pueden tener 200, 300 clases entre interfaces y clases
propiamente dichas.

[02:50] Entonces, ¿se imaginan tener aquí 500 clases, 500 archivos? Es muy complicado
después organizar toda esa información, si tienes que hacer un mantenimiento, una cosa así,
es muy complicado identificar dónde es que tienes que trabajar.

Lo primero que queremos hacer es organizar nuestras clases, digamos de negocio en una
carpeta, en un lugar y nuestras clases de test en otro lugar. Para eso vamos a venir aquí a
bytebank, que digamos, es nuestra carpeta base. Le vamos a dar un clic derecho, new, y no
quiero un proyecto, no quiero un ejemplo, quiero otra cosa.

[05:36] Y aquí en general, algo así que creó un folder. Le doy a next y a este folder, yo le voy a
poner modelo. ¿Por qué modelo? Normalmente nos referimos por modelo a las clases que
representan cada entidad de nuestro negocio. Un cliente, un contador, un funcionario son
entidades que representan cómo sería sistemáticamente esa parte del negocio.
¿qué es lo primero que voy a hacer? En modelo voy a copiar todas las clases que no sean test.
En este caso, ¿cuáles son? Administrador, autenticable, todas, hasta sistema interno. Si se dan
cuenta, lo único que he hecho hasta ahora es crear solamente una carpeta más, carpeta, folder,
es lo mismo.

y ahora en el lado de aquí, vemos que salieron muchos errores.

Pero fíjense algo curioso que está aquí abajo, aquí abajito. Ahora tenemos un
bytebank.modelo.

[07:04] Tenemos un paquete bytebank y un paquete bytebank.modelo. ¿Y por qué se forma

esta estructura? Por lo que les comenté antes, en Java esta estructura, esta jerarquía de
carpetas, en otros lenguajes de programación siguen siendo carpetas, folders, pero en Java nos
referimos a esto como paquetes.

Actualizando Clases
¿por qué no crear una carpeta test para organizar mis pruebas ahí adentro? Vamos a repetir el
proceso: clic derecho, new, other. Y vamos a crear otro folder y ese folder, ¿cómo se va a
llamar? Test. Le damos a finish. Y de la misma forma que hicimos anteriormente, copiamos
todo esto dentro de texto. Y está listo.

Y vemos que en la línea 1 ya me está dando un error, me lo está subrayando color rojo. ¿Qué es
lo que me dice este error? Este error me dice el paquete declarado bytebank no coincide con el
paquete esperado, bytebank.modelo. Entonces, ¿qué significa esto?

[01:57] En Java la declaración del paquete va a ir a línea 1 y toda clase pertenece a un paquete.
Si recordamos el paquete, antes se llamaba solamente bytebank. Pero ahora ya no se llama
bytebank, ¿cómo se llama? Bytebank.modelo. Entonces, ¿a qué se debe el error en esta clase
administrador?

Él me dice: "Yo no sé cuál es el paquete bytebank. Yo no conozco un paquete bytebank, yo

conozco un paquete bytebank.modelo, porque yo estoy dentro de este paquete
bytebank.modelo. Entonces, si yo escribo bytebank.modelo y si se dan cuenta Eclipse ya me
está sugiriendo aquí bytebank.modelo, le doy doble clic y automáticamente desapareció el
error.

La línea 1 es la declaración del paquete, la ubicación de esta clase. Esa es

pregunta de examen de certificación.
Vamos a dejarlo por ahí por el momento y nos vamos a ir aquí a las pruebas para ver cuál es el
error aquí en los test, porque creo que hay otra cosa que no estamos viendo aún, y es esto de
acá. Vamos a ver aquí.

[04:23] Bueno, el error de la primera línea ya lo conocemos. Y en este caso ya no es modelo, es

test. Solucionado, pero aquí tenemos otro error con el gerente. La clase gerente aquí aún tiene
error. Voy a entrar aquí. Sí, la clase gerente aún tiene error, lo voy a solucionar. Perfecto. La
clase de gerente tiene errores, ya no tiene errores, perfecto. Volvemos aquí a test de gerente y
vemos que gerente sigue sin funcionar.

¿por qué el test del gerente no puede acceder al gerente? Vamos a ver qué nos dice aquí
Eclipse. Eclipse nos dice: "gerente no puede ser resuelto como un tipo".

[05:16] ¿Qué opciones tenemos? Importar gerente, que está dentro de bytebank.modelo, crear
una clase gerente, crear un interfaz gerente. ¿Entonces, qué es lo primero que tenemos que
ver aquí?

Todos los archivos a nivel de carpeta, vamos a volver aquí a nuestra vista de navigator, todo
archivo que esté dentro de esta carpeta de aquí, de test, y quiera acceder a cualquier archivo
que esté en esta carpeta de aquí, modelo, necesita conocer el nombre específico del archivo al
cual quiere acceder. ¿A qué me refiero con el nombre específico del archivo?

[05:58] Si ahora el paquete se llama bytebank.modelo, en Java el nombre de estas clases no es

solamente el nombre como tal. El nombre de una clase en Java está compuesto del paquete
con el nombre de la clase. Es decir, en Java, para yo poder usar aquí el gerente en este test voy
a cerrar además los demás archivos. Yo tendría aquí que decirle exactamente la ubicación de
dónde está ese gerente que yo quiero traer.

Sería como decir bytebank.modelo.Gerente y vemos que aquí ya compila. Y aquí de igual
manera, bytebank.modelo. Voy a copiar, voy a pegar aquí y vemos que él ya compila. ¿Por qué?
Porque él ya tiene la información de dónde buscar este gerente. ¿Y por qué tiene que ser así en
Java?

Porque en Java, de repente yo tengo un gerente en algún paquete y en otro paquete de otra
librería tengo otro gerente, entonces digamos que es como una estructura del tipo nombre y
apellido. Lo primero que tenemos que ver aquí, voy a poner comentario, es package, que es
paquete en inglés, más el nombre de la clase: package + classname.

Importando Clases
¿Qué pasaría si, por ejemplo yo estoy trabajando con otros equipos, con otras empresas,
necesito integrar con otro banco? Digamos que Byte Bank es un banco conocido, pues a nivel
mundial y tenemos sedes de Byte Bank en Brasil, Perú, Argentina, Chile, México, todos los
países. ¿Qué sucedería? Cada uno crearía su proyecto y cada uno tendría su gerente. Entonces
cada clase se llamaría bytebank.modelo.Gerente.

Y si yo necesito integrar con ellos, ¿será que puedo tener dos clases con el mismo nombre?
Porque ya sabemos que es este nombre y apellido, según lo que les expliqué en la estructura
anterior. ¿Pero pueden haber dos personas con el mismo nombre y apellido? Sí pueden haber,
en el mundo real pueden haber dos personas con el mismo nombre y apellido.

[01:21] Pero en el mundo de Java, en el mundo del sistema, eso no es permitido, incluso eso no
es permitido a nivel ya de sistema operativo.

Entonces, volviendo al primer caso que les planteé hace un momento, ¿qué sucedería si yo
tengo, si yo trabajo en una empresa, puede ser a nivel mundial y tengo que integrar mis
módulos y me voy a encontrar sí o sí con objetos con el mismo nombre, clases con el mismo
nombre, mismo nombre y el mismo apellido?

En Java se dieron cuenta que podía haber este conflicto de nombres, y por lo
tanto se estableció una convención. ¿Qué es una convención? Es una es una
regla, digamos que no está escrita en piedra, es una regla que no está en
ningún lugar, pero que es aceptada por la comunidad de desarrolladores de
Java.

[03:54] Esa es la convención, entonces, ¿cuál es la convención en este caso para nombrar
paquetes? ¿Y qué es lo que se hace para nombrar un paquete? Bueno, vamos a darle new
package. ¿Y cuál va a ser el nombre del paquete? Lo primero que se ve en el nombre del
paquete es el país. Y el país puede ser Perú, puede ser Argentina, pero es un nombre largo.
¿Entonces qué es lo que se hace?

Es la extensión del dominio del país. ¿A qué me refiero con eso? Si la página es una página
solamente de Argentina, la extensión del dominio va a ser .com.ar, si es de Brasil, .com.br, si es
de Mexico, .com.mx.
Esto ya me dice que no pueden haber entonces dos bytebank.modelo.Gerente que vengan del
mismo país, de Brasil. ¿Que más dice esta convención? Esta convención también dice que
después, dependiendo del tipo de empresa que tienes, si es compañía u organización, tenemos
un diminutivo para esto.

[05:37] Que es el mismo que se aplica en los dominios de las URL de internet, que puede
ser .com, .org, entonces en este caso Alura es una compañía, entonces com, .br.com de
compañía. Punto. ¿Y qué es lo que sigue ahí? El nombre de la empresa como tal, que en este
caso es bytebank, perfecto

pero recuerden que si están haciendo un proyecto para un país en específico, entonces la
extensión de dominio de ese país va en primer lugar para que identifique a qué país hace
referencia ese proyecto, esa compañía, esa organización

Vemos en la vista de navigator para que entiendan cómo él ha creado a nivel de carpetas
nuestros paquetes. Es una carpeta base com, una carpeta hija bytebank y otra carpeta hija
modelo. Esto es en la vista de explorador de Windows, explorador normal de archivos.
Estructura de Clases
Y volviendo al problema, ¿será que entonces necesito especificar todo este nombre largo cada
vez que yo estoy llamando a cliente? No, ¿por qué? porque Java se dio cuenta de esto y nos
ofreció una forma rápida de poder usar el cliente. ¿Y qué forma es esa? Eso se llama
importación. ¿Qué es una importación? Tenemos otra palabra reservada aquí, que es import.

import nos permite traer clases de otros paquetes directamente a nuestro archivo actual

respetando el orden que Java me ha definido para lo que es package import y la clase como
tal. Esa es pregunta de examen de certificación también.

yo no puedo importar directamente el paquete, lo que yo importo son los elementos dentro
del paquete. Y para eso Java me ofrece lo que es un white card, un comodín, que es el
asterisco. ¿Y el asterisco qué me indica? Importa todo lo que esté adentro de
com.bytebank.modelo. Todo.

Entonces tenemos que ahora diferenciar cuándo necesito el comodín, el asterisco, y cuándo
necesito especificar el nombre exacto de la clase. Normalmente por buena práctica, si yo
solamente voy a trabajar con gerente en este archivo, importo específicamente en la clase
gerente, pero si voy a trabajar con cinco clases o más que estén incluidas en el mismo
paquete, entonces, ahí ya es un poco mejor importar directamente todo el paquete entero.