4.3 DECLARACIÓN DE INTERFACES

CLICK AQUI PARA REGRESAR AL ÍNDICE

 DECLARACIÓN DE INTERFACES

Cuando se crea una interface, se está definiendo un “contrato” por el cual se establece lo que una clase puede hacer, sin hacer mención de como la clase lo hará.

Por ejemplo, puedes crear una interface llamada Bounceable, y todas las clases que implementen estar interfaz tienen que tener codificada todos los métodos definidos en esta clase.

Las interfaces pueden ser implementadas por todas las clases de cualquier árbol de herencia. Esto te deja tener clases radicalmente diferentes y darles un comportamiento común.

Por ejemplo puedes tener dos clases, una llamada Balon y otra llamada Neumatico, ninguna de estas clases viene de las misma línea de herencia, ni existe relación entre ambas, por ejemplo Balon es una subclase de la superclase Juguete y Neumatico es una subclase de java.lang.Object. Pero haciendo que las clases Neumatico y Balon implementen la interface Bounceable, se está diciendo que ambas clases Neumatico y Balon, son cosas que pueden rebotar (sino sabias Bounceable es el inglés de rebotable, es decir la capacidad de algo de rebotar :D).

La siguiente figura ilustra la relación entre las clases y las interfaces:

Se debe pensar en un interface como en 100% clase abstracta, ya que como una abstract class una interface define métodos abstractos con la siguiente forma:

Abstract void rebotar();  //Termina con un punto y coma en vez de con corchetes

Pero mientras una class abstract puede defibir tanto métodos abstractos como métodos no-abstractos, una interface solo puede definir abstract metódos.

A continuación se muestran algunas reglas para definir una interface:

• Todos los métodos de las interfaces son public y abstract.
• Todas las variables definifas en una interface deben de ser public, static y final, en otras palabras solo se puede declaran constantes, no variables de instancia.
• Los métodos de una interface no deben de ser nunca static.
• Ya que los métodos de una interface son abstract, ellos no pueden ser marcados con final, strictfp o native (Estos modificadores se verán después)
• Una interface solo puede extender de otras interface.
• Una interface no puede implementar ninguna otra clase o interface.
• Una interface debe ser declarada con la palabra reservada interface.
• Los tipo interface pueden ser usados polifórmicamente (Se verá más adelante)

La siguiente es una correcta declaración de un interface:

public abstract interface Rollable { }

Tipear abstract es considerado redundante, ya que por definición una interface es abstract, ya sea se ponga el modificador o no. Entonces la declaración podría ser también:

Public interface Rollable { }

Ahora para hacer un poco más interesante el código agreguemos algunos métodos:

public interface Rollable {
public abstract void bounce();
public abstract void setBounceFactor();
 }

Pero otra vez poner public  y abstract en la declaración de un método dentro de una iinterfaz, es redundante ya que por definición un método en una interface es abstract y public. Entonces la declaración podría ser también:

public interface Rollable {
void bounce();
void setBounceFactor();
 }

Ejemplos de otras declaraciones correctas para métodos en una interface:

void bounce();
public void bounce();
abstract void bounce();
abstract public bounce();

Ejemplos de otras declaraciones incorrectas para métodos en una interface:

final void bounce();
static void bounce();
private void bounce();
protected void bounce();

DECLARACION CONSTANTES EN UNA INTERFACE

Se permite poner constantes en una interface, ya que haciendo eso se garantiza que todas las clases que implementan la interface tengan acceso a las mismas constantes declaradas ahí.
La única regla que debes recordar es que las constantes en una interface, son siempre:

public static final

Sin importar si pones esos modificadores o no, en la declaración de las constante.

Como ejemplo te dejo declaraciones de constantes en una interface, todas son correctas y son la misma declaración:

public int x = 1; // No parecen ser static o final, pero lo son
int x = 1; // No parecen ser static, public o final, pero lo son
static int x = 1; // No se muestra final o public
final int x = 1; // No se muestra static o public
public static int x = 1; // No se muestra  final
public final int x = 1; // No se muestra static
static final int x = 1 // No se muestra public
public static final int x = 1; //Declaración correcta pero redundante

4.2 Declaración de Clases y Modificadores

CLICK AQUI PARA REGRESAR AL ÍNDICE

El siguiente código es la mas simple declaración de una clase:

class MyClass {  }

Este código compila correctamente, pero tu puedes ademas agregar modificadores antes de la declaración de la clase. Los modificadores caen en dos categorías:

• Modificadores de Acceso: public, protected, private

• Modificadores de No-Acceso (incluyen strictfp, final, y abstract)

1. ACCESO A UNA CLASE (CLASS ACCESS)

• Crear un instancia de la clase B.

• Extender la clase B (en otras palabras, convertirse en una subclase de la clase B)

• Acceder a ciertos métodos y variables dentro de la clase B, dependiendo del acceso que tengan esas variables y métodos.

Primero veremos los Modificadores de Acceso, donde aprenderas como restringir o permitir el acceso a una clase que hayas creado. 

Los Modificadores de Acceso son un poco tramposos en Java, pues hay cuatro controles de acceso (niveles de acceso), pero solo existen tres modificadores de acceso. El cuarto nivel de control de acceso (llamado default o package access) es cuando no usas ninguno de los tres modificadores de acceso, es decir cuando dejas en blanco el modificador de acceso de la clase.

Pero tenemos que tener en cuenta que para una clase, solo se pueden usar dos modificadores de acceso, el public y el default access.

¿Que significa acceder a una clase?

     Cuando decimos que el cogido de una clase A tiene acceso a otra clase B, esto significa que la clase A        puede hacer tres de las siguientes cosas:

2. MODIFICADORES DE ACCESO PARA UNA CLASE

2.1 DEFAULT ACCESS

Una clase con default access no tiene modificadores precediéndola en su declaración. Piensa en default access como un acceso de nivel de paquete, porque una clase con default access  puede ser solo vista por clases dentro del mismo paquete.

Por ejemplo, si una clase A y una clase B están en diferentes paquetes, y la clase A tiene default access, la clase B no podrá crear instancias de la clase A, o incluso declarar una variable o retornar una tipo clase A.

Observa en siguiente fragmento de código:

package cert;      

class Beverage {  }

Ahora observa el segundo código fuente:

package exam.stuff;

import cert.Beverage;

class Tea extends Beverage {  }

Como puedes ver, la superclase (Beverage) está en un paquete diferente de la subclase (Tea). La sentencia import al principio del archivo Tea está tratando (con los dedos cruzados) de importar la clase Beverage. El archivo Beverage compila perfectamente, pero cuando se trata de compilar el archivo Tea obtenemos algo como lo siguiente:

Can’t Access class cert.Beverage. Class or interface must be public, in same package or an accesible member class.

El archivo Tea no compila porque su superclase Beverage, tiene default access y está en un paquete diferente.

2.2 PUBLIC ACCESS

Una clase declarada con la palabra reservada public le da a toda las clases de todos los paquetes , acceso a esta public class. En otras palabras, todas las clases del Universo Java (JU) tienen acceso a una public class. No se debe olvidar que para usar una clase publica en un paquete diferente de donde la public class  se encuentra, se debe de importar esta public class usando la sentencia import.

En el ejemplo de la sección anterior, nosotros podemos no querer poner la subclase en el mismo paquete que la superclase, entonces para hacer que el código funcione, necesitamos agregar la palabra reservada public delante de la declaración de la superclase (Beverage). Como se muestra:

package cert;

public class Beverage {  }

Este cambio hace que la clase Beverage pueda ser accesible por todas las clases de todos los paquetes. Y de esta forma ambos archivos compilaran perfectamente.

3. OTROS (Nonaccess) MODIFICADORES DE CLASES

Puedes modificar la declaración de una clase usando las palabras reservadas final, abstract, o strictfp. Esos modificadores son una adición a cualquier control de acceso de una clase, entonces puedes por ejemplo, declarar una clase con los modificadores public y final y no habría ninguna problema. Pero no siempre se puede combinar los Modificadores Nonacces. Puedes combinar strictfp con final, por ejemplo, pero nunca debes marcar una clase con final y abstract. Veraz por que más adelante.

No necesitas conocer como trabaja strictfp, asi que nos centraremos únicamente en los modificadores final y abstract. Para el examen solo necesitas saber que strictfp es una palabra reservada que puede ser usada como modificador en una clase o un método, pero nunca en una variable.

3.1 MODIFICADOR FINAL PARA CLASES

Cuando se usa en una declaración de una clase, la palabra reservada final esto significa que esta clase no puede tener subclases. En otras palabras ninguna otra clase puede nunca extenderse (heredar) de una final class, y cualquier intento de hacerlo, solo terminara en un error de compilación.

Pero entonces, ¿por qué marcar a una clase con final? Después de todo, ¿eso no viola el paradigma Orientado a Objetos en cuento a la herencia? Bueno tú debes marcar una clase con final, únicamente si necesitas una absoluta garantía de que ninguno de los métodos de esa clase será sobrescrito (overridden). Si tú dependes profundamente de la implementación de ciertos métodos, entonces usando el modificador final te dará la seguridad de que nadie podrá cambiar la implementación hecha por ti.

Modifiquemos nuestra clase de ejemplo Beverage, agregando la palabra reservada final en la declaración:

package cert;

public final class Beverage { 

            public void unMetodoImportantisimo() {  }

}

Ahora, si tratamos de compilar la clase Tea:

package exam.stuff;

import cert.Beverage;

class Tea extends Beverage {  }

Obtendremos un error algo así:

Can´t subclass final clases: Class

cert.Beverage class Tea extends Beverage {

1 error

3.2 MODIFICADOR ABSTRACT PARA CLASES

Una clase abstracta nunca puede ser instanciada. Es su único propósito, misión en la vida, ser extendida (que otras clases hereden de ella).

¿Entonces por qué una haríamos una clase si no podemos crear objetos de ella? Porque la clase probablemente sea demasiada abstracta. Por ejemplo, imagina que tienes una clase Car, con métodos genéricos y comunes para todos los vehículos. Pero en realidad no se quiere que alguien pueda crear objetos genéricos y abstractos de la clase Car, porque simplemente es demasiado abstracto.

Observa el siguiente fragmento de código de una clase abstracta:

Abstract class Car{

           

            private double price;

            private double model;

private double year;

public abstract void goFast();

public abstract void goUpHill();

public abstract void impressNeighbors();

public void goBackHome(){

            int variebleSample;

}

}

El código anterior compilara perfectamente. Ademas, si intentamos instanciar un objeto de la clase Car en otro fragmento de código, se obtendrá un error de compilación, como el siguiente:

AnotherClass.java: 7: class Car is an abstract class.

It can’t be instantiated.

            Car x = new Car();

1 error

Nota que los métodos marcados con abstract terminan en un punto y coma, en lugar de corchetes.

Si un método de una clase esta marcado como abstract, entonces la clase entera debe ser marcada com abstract, sino se obtendrá un error de compilación. Además como se ve en el ejemplo, dentro de una clase abstracta pueden ir métodos no abstractos, para de esta forma poder hacer uso de la herencia en los métodos. Todo esto se verá más adelante en detalle.

4.1 Reglas de declaración del código fuente

CLICK AQUI PARA REGRESAR AL ÍNDICE

Antes de profundizar en la declaración de clases, hagamos una rápida revisión de las reglas asociadas con declarar clases, las sentencias import, y las sentencias package en un código fuente.

• Solo puede existir una clase pública (public class) por cada archivo del código fuente.

• Lo comentarios pueden aparecer tanto en el principio como en el final de cualquier línea de código en un archivo del código fuente. Los comentarios son independientes de las reglas y posiciones dispuestas aquí.

• Si hay una clase pública (public class) en un archivo, el nombre del archivo debe ser el mismo que el nombre de la clase.
Por ejemplo. Si declaramos una clase llamada Dog{} dentro de un archivo, este archivo debe tener el nombre Dog.java

• Si la clase es parte de un paquete (package), la sentencia package debe de estar en la primera línea del código fuente del archivo, antes de cualquier sentencia import, si hubiese alguna.

• Si hubieran sentencias import, ellas debes de estar entre la sentencia packagey (si hubiese una) y la declaración de la clase. Si no hubiese una sentencia package, entonces la(s) sentencia(s) import deben estar en la primera línea del código fuente del archivo. Si no hubiese sentencias import, la declaración de la clase debe ser la primera línea del código fuente del archivo.

• Las sentencias import y package se aplican a todas las clases dentro de un código fuente de un archivo. En otras palabras no hay forma de tener múltiples clases en un archivo y tenerlas en diferentes packages, o usar diferentes imports.

• Un archivo puede tener más de una clase no pública (nonpublic class).

• Los archivos que contengan clases no públicas (nonpublic classes) pueden tener un nombre diferente al de las clases en el archivo.

ÍNDICE GENERAL DEL CURSO

Asumimos que porque estas planeando ir por una certificación, tu ya conoces lo básico de Java, Si eres completamente nuevo en el lenguaje, se te hará mas difícil comprender los temas que vienen a continuación. 

INDICE

1.       Repaso de Java - Objetos y Clases

2.       Repaso de Java - Identificadores, Keywords, Herencia e Interfaces

3.       Identificadores y JavaBeans

        3.1 Identificadores Legales en Java
        3.2 Java Code Conventions
        3.3 JavaBeans Standards

4.     Declarar Clases y sus modificadores

       4.1   Reglas de declaración del código fuente
 4.2   Declaración de Clases y Modificadores
 4.3 Declaración de Interfaces

3.3 JavaBeans Standards

CLICK AQUI PARA REGRESAR AL ÍNDICE

Las especificaciones de JavaBeans intentan ayudar a los desarrolladores a crear componentes Java, que puedan fácilmente ser usadas por otros desarrolladores Java en un Entorno de Desarrollo Integrado (IDE), como NetBeans o Eclipse. Como un programador de Java, tú debes estar dispuesto a usar componentes de la Java API, pero sería fabuloso si tú pudieras además comprar el componente Java que tú quieres de algún otro desarrollador. Y una vez tú tengas los componentes, te gustaría poder accesarlos atravez de una herramienta de desarrollo y no tener que desarrollarlos desde cero. Por eso usando reglas de nombramiento, la especificación JavaBeans ayuda a garantizar que esas herramientas pueden reconocer y usar esos componentes construidos por otro desarrollador.

Primero, JavaBeans son clases de Java que tienen propiedades. Para nuestro propósito, piensa en propiedades como una variable de instancia private. Desde que ellas son privadas, la única manera de que ellas se han accedidas por otras clases de afuera es a través de los métodos en la clase original. Los métodos que cambian propiedades son llamados métodos setter, y los métodos que regresan el valor de una propiedad son llamados métodos getter.

Las reglas de nombramiento JavaBeans que debes conocer son:

1.       JavaBean Property Naming Rules.

·         Si la propiedad no es booleana, el prefijo del método getter debe ser get.

Por ejemplo, getSize() es un valido nombre getter JavaBeans para una propiedad llamada size.

Ten en mente que no necesitas tener una variable de nombre size. El nombre de la propiedad es inferida por el método getter o setter no a través de alguna variable en tu clase. Lo que regreses de getSize() depende solo de ti.

·         Si la propiedad es un booleano, el prefijo del método getter puede ser cualquiera de las dos get o is.

Por ejemplo, getStopped() o isStopped().

·         El profijo para métodos setter debe ser set.

Por ejemplo, setSize()

·         Para completar el nombre de un método getter o setter, cambia la primera letra del nombre de la propiedad a mayúscula, y luego concatena el prefijo apropiado (get, set o is).

·         Los métodos setter deben ser marcados con public, con un valor de retorno tipo void y un argumento que represente el tipo de propiedad.

·         Los metodos getter debes ser marcados con public, sin argumentos, y deben tener un tipo de retorno que empareje con el argumento del método tipo setter para la misma propiedad.

2.       JavaBean Listener Naming Rules

 Las especificaciones de JavaBeans soportan events, los cuales permiten a los componentes notificar a cada uno de los otros cuando algo ocurre. El modelo event es usado frecuentemente en las aplicaciones de GUI (Interfaz Grafica de Usuario), cuando un evento como un click del mouse es emitido a muchos otros objetos, que probablemente tengan que hacer cosas cuando el click ocurre. Los objetos que reciben la información de que el evento ocurrió son llamados listeners.

Para el examen necesitas saber que los métodos que son usados para agregar o eliminar listeners  de un evento, tienen además que seguir el nombramiento estándar JavaBeans.

Las reglas vendrían a ser las siguientes:

·         Los nombres de los metodos listener usados para registrar un listener con un evento deben de usar el prefijo add, seguido por el tipo del listener.

Por ejemplo, addActionListener(),  es un nombre valido para un método de un evento que tendrá que permitir registrar Action events.

·         Los nombre de los métodos listener usados para remover un listener debe usar el prefijo remove, seguido del tipo de listener.

·         El tipo de listener que serán agregados o removidos deben de pasar como argumentos del método.

·         Los nombres de métodos listener deben terminar con la letra “Listener”.

_____________________________________________________________________________

Ejemplos validos de métodos JavaBean son:

public void setMyValue( int v )

public int getMyValue()

public boolean isMyStatus()

public void addMyListener(MyListener m)

public void removeMyListener(MyListener m)

Ejemplos inválidos de métodos JavaBean son:

void setCustomerName(String s)                      //debe de ser public

public void modifyMyValue(int v)                     //no se puede usar ‘modify’

public void addXListener(MyListenet m)          //no hay concordancia de tipos

3.2 Java Code Conventions

CLICK AQUI PARA REGRESAR AL ÍNDICE

A continuación se muestran los nombres estándar: 

·         Clases e Interfaces.

La primera letra debe estar en mayúscula, y si hubiera varias palabras unidas juntas para formar un nombre, la primera letra de cada palabra unida debe estar en mayúscula.

Para clases, los nombres típicamente deben ser sustantivos. Por ejemplo:

Dog

Account

PrintWriter

Para interfaces, los nombres deben ser típicamente adjetivos. Por ejemplo:

Runnable

Serializable

·         Métodos

La primera letra debe estar en minúscula, y si hubiera varias palabras unidas juntas para formar un nombre, la primera letra de cada palabra unida debe estar en mayúscula.

Se agrega, los nombre deben ser típicamente verbos-sustantivos. Por ejemplo:

getBalance

doCalculation

setCustomerName

·         Variables

Son las mismas reglas que para los métodos. Se recomienda que el nombre sea corto, y el nombre tenga significado, que suene bien para nosotros. Por ejemplo:

buttonWidth

accountBalance

myString

·         Constantes

Las constantes en Java son creadas haciendo a las variables static y final. Ellas deben ser nombradas usando solo letras mayúsculas con un guion bajo ( _ ) como separador de las palabras. Por ejemplo:

MIN_HEIGHT

MAX_LENGTH

3.1 Identificadores Legales en Java

CLICK AQUI PARA REGRESAR AL ÍNDICE

Identificadores Legales.

Técnicamente un identificador legal debe de estar compuesto por solo caracteres Unicode, números, simbolos de moneda, y caracteres conectores (como el guion bajo). Los exámenes para la certificación no profundizan en los detalles de cuales rangos de los caracteres de Unicode son considerados para calificar como letras o números. Por lo tanto, por ejemplo, no necesitas saber que rangos de dígitos tibetanos aceptables.

Pero aquí tienes las reglas que debes de conocer:

• Identificadores deben empezar con una letra, un símbolo de moneda ($), o un carácter conector ( _ ). Los identificadores no deben empezar con números.
• Después del primer carácter, los identificadores pueden contener cualquier combinación de letras, símbolos de monedas, caracteres conectores, o números.
• En la práctica, no hay límite de número de caracteres que un identificador puede contener.
•  No se puede usar Java Keywords (palabras clave de Java) como un identificador, al final de este documento se muestras las palabras clave de Java hasta la versión 6 de Java.
• Los identificadores en Java con case-sensitive, foo and FOO son diferentes identificadores.

Ejemplos de legales e ilegales identificadores, primero los identificadores legales:

int _a;

int $c;

int ________2_w;

int _$;

int este_es_un_muy_detalllado_nombre_para_un_identificador;

Los siguientes son identificadores ilegales (es tu trabajo reconocer por qué):

int :b;

int –d;

int e#;

int .f;

int 7g;

_________________________________________________________________

Lista completa de las palabras reservadas en Java, es decir las Keywords.

Lista de Keywords en Java hasta la versión Java 6