---------------------------------------------- Clase ---------------------------------------------
Tipos de Métodos:
Aparte de los Constructores y Los Procedimientos un objeto suele tener: MÉTODOS CONSULTORES (GET) Y MODIFICADORES (SET):
a) Métodos modificadores:
Llamamos métodos modificadores a aquellos métodos que dan lugar a un cambio en el valor de uno o varios de los atributos del objeto.
b) Métodos consultores u observadores:
Son métodos que devuelven información sobre el contenido de los atributos del objeto sin modificar los valores de estos atributos.
¿Que es una Interface?
Toda esta información que describe qué hace la clase y cómo usarla (sin mostrar el código fuente o implementación) se denomina interfaz o interface de la clase. El código de implementación de la clase queda oculto (principio de ocultamiento de la información) y como programadores no vamos a tener acceso ni vamos a necesitar tener acceso a él.
La interfaz de clase nos muestra todos los constructores y métodos que se hayan definido como public en la clase. Por el contrario, no se van a mostrar aquellos constructores o métodos que se hayan definido como private.
en otras palabras:
El conjunto de signaturas de métodos y constructores públicos de una clase constituyen su interfaz o interface. En esencia, la interface es una abstracción que consiste en que conocemos la signatura de los métodos (qué hacen) pero no su implementación (cómo lo hacen). Muchas veces se hace referencia a la implementación como “parte privada de una clase” para distinguirla de la parte pública (interfaz). Esta forma de trabajar se dice que hace uso del principio de ocultamiento de la información y se ha demostrado que es beneficiosa para una buena programación.
¿Qué es y para qué sirve el Api de Java?
Al instalar Java (el paquete JDK) en nuestro ordenador, además del compilador y la máquina virtual de Java se instalan bastantes más elementos. Entre ellos, una cantidad muy importante de clases que ofrece la multinacional desarrolladora de Java y que están a disposición de todos los programadores listas para ser usadas. Estas clases junto a otros elementos forman lo que se denomina API (Application Programming Interface) de Java.
La mayoría de los lenguajes orientados a objetos ofrecen a los programadores bibliotecas de clases que facilitan el trabajo con el lenguaje.
Los siguientes esquemas, parte de la documentación de Java, nos dan una idea de cómo funciona el sistema Java y de qué se instala cuando instalamos Java (el paquete JDK) en nuestro ordenador.
Este esquema no nos interesa analizarlo en profundidad. Lo único que queremos mostrar es que cuando instalamos Java en nuestro ordenador instalamos múltiples herramientas, entre ellas una serie de “librerías” (paquetes) a cuyo conjunto solemos referirnos como “biblioteca estándar de Java”. Las librerías contienen código Java listo para ser usado por nosotros. Ese es el motivo de que podamos usar clases como System o String sin necesidad de programarlas.
¿Dónde se encuentra el código de estas librerías?
En los archivos que se instalan en nuestro ordenador cuando instalamos Java.
¿Podemos acceder al código de estas librerías?
La respuesta es que no. Las biblioteca estándar de Java se facilita como código cerrado, es decir, como código máquina. No podemos acceder al código fuente. Esto tiene su lógica porque si cada persona accediera al código fuente de los elementos esenciales de Java y los modificara, no habría compatibilidad ni homogeneidad en la forma de escribir programas Java.
¿Para qué nos sirve la biblioteca si no podemos acceder a su código fuente?
Aunque no podamos acceder al código fuente, sí podemos crear objetos de los tipos definidos en la librería e invocar sus métodos. Para ello lo único que hemos de hacer es conocer las clases y la signatura de los métodos, y esto lo tenemos disponible en la documentación de Java accesible para todos los programadores a través de internet o cds de libros y revistas especializadas. ¿Te acuerdas cuando hablamos de la definición de signatura e interfaz? Esto es ahora plenamente aplicable con el API de Java: tenemos disponible información de las clases, de qué hacen y cómo podemos trabajar con ellas, aunque no dispongamos del código fuente.
Saber usar la biblioteca y elegir las clases adecuadas es esencial para crear programas de forma rápida y eficiente. Es imposible conocer todas las clases y sus detalles (constructores, campos, métodos, etc.), ni siquiera sus nombres, pero gracias a internet lo tenemos todo “al alcance de la mano”.
Para programar en Java tendremos que recurrir continuamente a consultar la documentación del API de Java. Esta documentación está disponible en cds de libros y revistas especializadas o en internet tecleando en un buscador como yahoo, google o bing el texto "api java 8" (o "api java 6", "api java 10", etc.) según la versión que estés utilizando. La documentación del API de Java en general es correcta y completa. Sin embargo, en casos excepcionales puede estar incompleta o contener erratas.
Los nombres de las librerías responden a este esquema jerárquico y se basan en la notación de punto. Por ejemplo el nombre completo para la clase ArrayList sería java.util.ArrayList. Se permite el uso de * para nombrar a un conjunto de clases. Por ejemplo java.util.* hace referencia al conjunto de clases dentro del paquete java.util, donde tenemos ArrayList, LinkedList y otras clases.
Para utilizar las librerías del API, existen dos situaciones:
a) Hay librerías o clases que se usan siempre pues constituyen elementos fundamentales del lenguaje Java como la clase String. Esta clase, perteneciente al paquete java.lang, se puede utilizar directamente en cualquier programa Java ya que se carga automáticamente.
b) Hay librerías o clases que no siempre se usan. Para usarlas dentro de nuestro código hemos de indicar que requerimos su carga mediante una sentencia import incluida en cabecera de clase. Por ejemplo import java.util.ArrayList;
Esquema orientativo de la organización de librerías en el API de Java (ver página siguiente)
Abstracción y modularización en Java
Los programas informáticos suelen ser muy complejos como para abordarlos en su conjunto. Por ello han de usarse técnicas para dividir el problema (estrategia “divide y vencerás”) que nos permitan crear programas complejos a partir de partes más simples. Hablamos de abstracción para referirnos a partes complejas ensambladas a partir de partes simples.
Ejemplo:
Hablamos de modularización del software en alusión a dividir un programa en partes independientes que pueden ser construidas y probadas por separado para luego ensamblarlas formando un todo. De acuerdo con esta terminología “abstraer” sería subir de nivel o ensamblar, mientras que modularizar sería bajar de nivel o despiezar.
En programación orientada a objetos la abstracción la materializamos construyendo objetos que usan o son combinación de otros objetos más simples. De este modo podemos construir objetos de gran complejidad sin necesidad de crear un código largo y complejo.
Comparación entre objetos
Un objeto es una cosa distinta a un tipo primitivo, aunque “porten” la misma información.
Consideremos que cuando hacemos una petición a la memoria, esta puede ser de dos tipos:
a) Le pedimos un tipo primitivo. Equivaldría a decir directamente “Dame el bolígrafo 783”. Y esta información se nos sirve.
b) Le pedimos un objeto. Equivaldría a decir “Dame la caja que está en la posición 93282”. Y esta información se nos sirve.
Supongamos que mensaje7 es una variable apuntadora a una caja que contiene 2 bolígrafos, y que estudiante451 es otra variable apuntadora a una caja que contiene otros 2 bolígrafos. Vamos a plantear algunas preguntas:
PREGUNTA
RESPUESTA
RAZONAMIENTO
¿Es idéntico mensaje7 que estudiante451?
mensaje7 == estudiante451
No, no es igual.
False
El contenido de mensaje7 es “El objeto está en posición de memoria 08712”, mientras que el contenido de estudiante451 es “El objeto está en posición de memoria 93282”. Por tanto no son iguales.
¿Es igual el contenido de mensaje7 que el contenido de estudiante451?
mensaje7.equals(estudiante451)
Depende
Depende de qué consideremos ser igual. Si consideramos que por contener 2 bolígrafos el contenido es igual la respuesta es sí. Si consideramos que además hemos de comprobar que los bolígrafos sean de la misma marca y color, ahora mismo no sabríamos decir si los contenidos son iguales o no.
1) La comparación usando == no se debe usar para comparar el “contenido” de los objetos, sino únicamente para comparar la información de las variables apuntadoras. Usar == para comparar objetos es un error frecuente en programadores con poca experiencia.
2) Para comparar el contenido de los objetos hemos de usar, en general, un método especial del que disponen todos los objetos denominado equals. Equals se basa en una definición de igualdad que ha de estar establecida. Por ejemplo, podríamos definir que dos objetos son iguales si contienen el mismo número de bolígrafos, de la misma marca, modelo y color. Para algunos tipos de objetos, como los String, la definición de igualdad que viene incorporada en el API de Java nos va a resultar suficiente. Es decir, if (miCadena1.equals (miCadena2)) va a funcionar correctamente. Sin embargo, si hemos definido un tipo Deposito y tratamos de utilizar if (deposito1.equals (deposito2)) no obtendremos un resultado satisfactorio puesto que no hemos definido cuál es el criterio de igualdad.
PREGUNTA
|
RESPUESTA
|
RAZONAMIENTO
|
¿Es idéntico mensaje7 que estudiante451?
mensaje7 == estudiante451
|
No, no es igual.
False
|
El contenido de mensaje7 es “El objeto está en posición de memoria 08712”, mientras que el contenido de estudiante451 es “El objeto está en posición de memoria 93282”. Por tanto no son iguales.
|
¿Es igual el contenido de mensaje7 que el contenido de estudiante451?
mensaje7.equals(estudiante451)
|
Depende
|
Depende de qué consideremos ser igual. Si consideramos que por contener 2 bolígrafos el contenido es igual la respuesta es sí. Si consideramos que además hemos de comprobar que los bolígrafos sean de la misma marca y color, ahora mismo no sabríamos decir si los contenidos son iguales o no.
|
Generar JavaDoc
Para que java interprete que el comentario forma parte de el Java doc o documentación del método o clase se debe usar la siguiente notación:
/**
*
*/
Posibles etiquetas que permiten referenciar con más exactitud esta descripcion
/**
* @deprecated
* @param
* @see
* @serial
* @since
* @version
* @author
*/
@author nombre (desde la versión 1.0 del JDK/SDK)
Indica el autor de la clase en el argumento nombre. Un comentario de este tipo puede tener más de un autor en cuyo caso podemos usar tantas etiquetas de este tipo como autores hayan colaborado en la creación del código fuente o bien podemos ponerlos a todos en una sola etiqueta. En éste último caso, Javadoc inserta una (,) y un espacio entre los diferentes nombres.
@deprecated comentario (desde la versión 1.0 del JDK/SDK)
Añade un comentario indicando que este API no debería volver a usarse, aunque aun siga perteneciendo a la distribución del SDK que estemos utilizando, por estar desautorizado o "desfasado". No obstante, ésto es sólo una advertencia que nosotros damos a los usuarios de nuestras API's, al igual que las distribuciones de Sun hacen con nosotros. Realmente, lo que estamos haciendo al decir que una determinada API está desfasada es prevenir de que en un futuro podrán surgir incompatibilidades si seguimos usándolas ya que éste es el paso a previo a la desaparición del API en concreto. En la primera frase del comentario, que es la que la documentación nos la muestra en la sección del resumen de nuestra clase, deberíamos como mínimo poner desde que versión de nuestra API está desautorizada y por quién se debería sustituir. A partir de Java 1.2 podemos usar {@link} para referenciar por quién debemos hacer la sustitución.
@throws nombre-clase descripcion (desde la versión 1.2 del JDK/SDK)
Se añade una cabecera "Throws" a la documentación generada con el nombre de la excepción que puede ser lanzada por el método (nombre-clase) y una descripción de por qué se lanza.
@exception nombre-clase descripción (desde la versión 1.0 del JDK/SDK)
{@link nombre etiqueta} (desde la versión 1.2 del JDK/SDK)
Inserta un enlace autocontenido que apunta a nombre. Esta etiqueta acepta exactamente la misma sintáxis que la etiqueta @see, que se describe más abajo, pero genera un enlace autocontenido en vez de colocar el enlace en la sección "See Also". Dado que esta etiqueta usa los carácteres { } para separarla del resto del texto in-line, si necesitas emplear el caracter "}" dentro de la etiqueta debes usar la notación HTML } No existe ninguna limitación en cuanto al número de etiquetas de este tipo permitidas. Puedes usarlas tanto en la parte de la descripción como en cualquier porción de texto de cualquier otra etiqueta de las que nos proporciona JavaDoc.
@param parámetro descripción (desde la versión 1.0 del JDK/SDK)
Añade un parámetro y su descripción a la sección "Parameters" de la documentación HTML que generará. Por tanto, para cada método emplearemos tantas etiquetas de este estilo como parámetros de entrada tenga dicho método.
@return descripción (desde la versión 1.0 del JDK/SDK)
Añade a la sección "Returns" de la documentación HTML que va a generar la descripción del tipo que devuelve el método.
@see referencia (desde la versión 1.0 del JDK/SDK)
Añade un cabecero "See Also" con un enlace o texto que apunta a una referencia. El comentario de la documentación puede contener cualquier número de etiquetas de este tipo y todas, al generar la documentación, se agruparán bajo el mismo cabecero. Esta etiqueta se puede conformar de tres maneras diferentes, siendo la última forma la más utilizada.
@see "string"
En este caso, no se genera ningún enlace. La string es un libro o cualquier otra referencia a una información que no está disponible via URL. JavaDoc distingue este caso buscando en el primer carácter de la cadena las comillas dobles (").
Por ejemplo: @see "The Java Programming Language" que genera el siguiente texto HTML: See Also: "The Java Programming Language"
@see <a href="URL#value">label</a>
Añade un enlace definido por URL#value. Esta dirección puede ser relativa o absoluta. JavaDoc distingue este caso buscando en el primer carácter el símbolo "<".
Por ejemplo: @see <a href="spec.html#section">Java Spec</a> que genera el siguiente enlace: See Also: Java Spec
@see package.class#member texto Añade un enlace, con el texto visible texto, que apunta en la documentación al nombre especificado en el lenguaje Java al cual hace referencia. Aquí por nombre se debe entender un paquete, una clase, un método o un campo. El argumento texto es opcional, si se omite, JavaDoc nos dará la información mínima, ésto es, el nombre de, por ejemplo, la pareja paquete#método. Usa este campo cuando quieras especificar algo más, cuando quieras representarlo por un nombre más corto o simplemente si quieres que aparezca con otro nombre.
@since texto (desde la versión 1.1 del JDK/SDK)
Indica con texto desde cuándo se creó este paquete, clase o método. Normalmente se pone la versión de nuestra API en que se incluyó, así en posteriores versiones sabremos a qué revisión pertenece o en qué revisión se añadió.
@serialField field-name field-typefield-description (desde la versión 1.2 del JDK/SDK)
Documenta un componente ObjectStreamField de un miembro serialPersistentFields de una clase Serializable. Esta etiqueta se debería usar para cada componente ObjectStreamField.
@serialData data-description (desde la versión 1.2 del JDK/SDK)
Se emplea para describir los datos escritos por el método writeObject y todos los datos escritos por el método Externalizable.writeExternal. Esta etiqueta puede ser usada en aquellas clases o métodos que intervengan los métodos writeObject, readObject, writeExternal, and readExternal.
@version version (desde la versión 1.0 del JDK/SDK)
Añade un cabecero a la documentación generada con la versión de esta clase. Por versión, normalmente nos referimos a la versión del software que contiene esta clase o miembro.
---------------------------------- Fin de la Clase --------------------------------------------------
Ir a la ultima actualización de la clase: http://adf.ly/11350999/clase-06-de-poo-en-java
REVISA AQUÍ!!!! la descripción del vídeo para mas INFORMACIÓN y HERRAMIENTAS
Sus-Cri-Be-Te a este canal. o visitalo para ver las "listas de reproducción"
https://www.youtube.com/channel/UCJ70FExIXtnRE5cPI-P03vw
Recuerda seguirme en mis redes sociales:
twitter: @cusattic
Blogger: http://cusattic-java.blogspot.com/
comenta tus dudas, dime que te pareció y ¿que temas crees debería explicar?.
Gracias por ver el vídeo...
Espero hayas encontrado y aprendido lo que buscabas...
compártelo ya que "esto es para todos!!"
