Resumen Capitulo 13

Una superclase define el comportamiento común de las subclases relacionadas. Se puede usar una interfaz para definir un comportamiento común para las clases, incluidas las clases no relacionadas).

13.2 Clases abstractas

No se puede usar una clase abstracta para crear objetos. Puede contener métodos abstractos, que se implementan en subclases concretas. A veces, una superclase es tan abstracta que no se puede usar para crear instancias específicas. Las clases abstractas se denotan usando el modificador abstract en el encabezado de la clase. Son como las clases regulares, pero no puede crear instancias de clases abstractas utilizando el nuevo operador.

El constructor en la clase abstracta se define como protegido, porque solo lo usan las subclases.

public abstract class GeometricObject

13.2.2 Puntos interesantes sobre las clases abstractas

Algunas características:

– En una subclase no abstracta extendida desde una clase abstracta, todos los métodos abstractos deben implementarse. Los métodos no son estáticos.

– No se puede crear una instancia de una clase abstracta utilizando el nuevo operador, pero aún puede definir sus constructores, que se invocan en los constructores de sus subclases.

– Una clase que contiene métodos abstractos debe ser abstracta. Sin embargo, es posible definir una clase abstracta que no contenga ningún método abstracto. En este caso, no puede crear instancias de la clase utilizando el nuevo operador. Esta clase se usa como una clase base para definir subclases.

– Una subclase puede anular un método de su superclase para definirlo como abstracto.

– Una subclase puede ser abstracta incluso si su superclase es concreta.

– No puede crear una instancia a partir de una clase abstracta utilizando el nuevo operador, pero se puede utilizar una clase abstracta como tipo de datos.

13.3 Estudio de caso: la clase de números abstractos

Number es una superclase abstracta para clases de contenedor numérico, BigInteger y BigDecimal. La clase Number es, por lo tanto, una clase abstracta.

13.4 Estudio de caso: calendario y calendario gregoriano

GregorianCalendar es una subclase concreta de la clase abstracta Calendario. java.util.Calendar es una clase base abstracta para extraer información detallada del calendario. El método add es abstracto en la clase Calendar, porque su implementación depende de un sistema de calendario concreto. Para obtener la cantidad de días en un mes, use calendar.getActualMaximum (Calendar.DAY_OF_MONTH).

13.5 Interfaces

Una interfaz es una construcción de clase que contiene solo constantes y métodos abstractos. En muchos sentidos, una interfaz es similar a una clase abstracta, pero su intención es especificar un comportamiento común para objetos de clases relacionadas o clases no relacionadas. Por ejemplo, puede usar una interfaz como tipo de datos para una variable de referencia, como resultado de la conversión, etc. Al igual que con una clase abstracta, no puede crear una instancia desde una interfaz utilizando el nuevo operador.

Puede usar la interfaz Edible para especificar si un objeto es edible. Esto se logra dejando que la clase para el objeto implemente esta interfaz utilizando la palabra clave implements.

Nota

Como todos los campos de datos son públicos estáticos finales y todos los métodos son públicos abstractos en una interfaz, Java permite omitir estos modificadores. Por lo tanto, las siguientes definiciones de interfaz son equivalentes:

13.6 La interfaz comparable

La interfaz comparable define el método compareTo para comparar objetos. El método compareTo determina el orden de este objeto con el objeto o especificado y devuelve un entero negativo, cero o un entero positivo si este objeto es menor, igual o mayor que o. Las clases Byte, Short, Integer, Long , Float, Double, Character, BigInteger, BigDecimal, Calendar, String y Date implementan la interfaz Comparable.

13.7 La interfaz clonable

A menudo es deseable crear una copia de un objeto. Para hacer esto, debe usar el método de clonación y comprender la interfaz clonable. La interfaz clonable en el paquete java.lang se define de la siguiente manera:

package java.lang;

public interface Cloneable {

}

Esta interfaz está vacía. Una interfaz con un cuerpo vacío se denomina interfaz de marcador.

Una interfaz de marcador no contiene constantes ni métodos. Se utiliza para denotar que una clase posee ciertas propiedades deseables. Una clase que implementa la interfaz Cloneable se marca cloneable, y sus objetos se pueden clonar utilizando el método clone () definido en la clase Object. Son diferentes objetos con el mismo contenido.

13.8 Interfaces vs clases abstractas

Una clase puede implementar múltiples interfaces, pero solo puede extender una superclase.

Java permite solo una única herencia para la extensión de clase, pero permite múltiples extensiones para las interfaces. Por ejemplo,

Una interfaz puede heredar otras interfaces usando la palabra clave extend. Dicha interfaz se llama subinterfaz. Por ejemplo, NewInterface en el siguiente código es una subinterfaz de Interface1,. . . y InterfaceN.

Una interfaz puede extender otras interfaces, pero no clases.

Una variable de un tipo de interfaz puede hacer referencia a cualquier instancia de la clase que implemente la interfaz. Si una clase implementa una interfaz, la interfaz es como una superclase para la clase. En general, se prefieren las interfaces a las clases abstractas porque una interfaz puede definir un supertipo común para clases no relacionadas. Las interfaces son más flexibles que las clases.

13.9 Estudio de caso: la clase racional

Un número racional tiene un numerador y un denominador en la forma a / b, donde a es el numerador y b el denominador. Por ejemplo, 1/3, 3/4 y 10/4 son números racionales. Para obtener el resultado exacto, debemos usar números racionales.

Se usa long cuando la variable de número es racional. La clase racional es inmutable.

13.10 Pautas de diseño de clase

Las pautas de diseño de clase son útiles para diseñar clases de sonido.

13.10.1 Cohesión

Una clase debería describir una sola entidad, y todas las operaciones de la clase deberían encajar lógicamente para apoyar un propósito coherente.

13.10.2 Consistencia

– Siga el estilo de programación estándar de Java y las convenciones de nomenclatura.

– Elija nombres informativos para clases, campos de datos y métodos. Un estilo popular es colocar la declaración de datos antes del constructor y colocar los constructores antes que los métodos.

– En general, siempre debe proporcionar un constructor público sin argumentos para construir una instancia predeterminada.

– Si una clase no admite un constructor sin argumentos, documente el motivo.

– Si no se definen explícitamente constructores, se supone un constructor público sin argumentos con un cuerpo vacío.

– Si desea evitar que los usuarios creen un objeto para una clase, puede declarar un constructor privado en la clase, como es el caso de la clase Math.

13.10.3 Encapsulación

Una clase debe usar el modificador privado para ocultar sus datos del acceso directo de los clientes. Esto hace que la clase sea fácil de mantener. Proporcione un método getter solo si desea que el campo de datos sea legible, y proporcione un método setter solo si desea que el campo de datos sea actualizable.

13.10.4 Claridad

La cohesión, la consistencia y la encapsulación son buenas pautas para lograr la claridad del diseño. Además, una clase debe tener un contrato claro que sea fácil de explicar y fácil de entender. Los usuarios pueden incorporar clases en muchas combinaciones, órdenes y entornos diferentes.

Los valores de estas propiedades se pueden establecer en cualquier orden. Los métodos deben definirse intuitivamente sin causar confusión.

No debe declarar un campo de datos que pueda derivarse de otros campos de datos.

13.10.5 Integridad

Las clases están diseñadas para ser utilizadas por muchos clientes diferentes. Para ser útil en una amplia gama de aplicaciones, una clase debe proporcionar una variedad de formas de personalización a través de propiedades y métodos.

13.10.6 Instancia vs. Estática

– Una variable o método que depende de una instancia específica de la clase debe ser una variable o método de instancia. Una variable compartida por todas las instancias de una clase debe declararse estática.

– Siempre haga referencia a variables y métodos estáticos desde un nombre de clase (en lugar de una variable de referencia) para mejorar la legibilidad y evitar errores. No pase un parámetro de un constructor para inicializar un campo de datos estático.

– Se puede invocar una variable o método estático desde un método de instancia, pero una variable o método de instancia no se puede invocar desde un método estático.

13.10.7 Herencia vs. Agregación

La diferencia entre herencia y agregación es la diferencia entre una relación is-a y has-a. Por ejemplo, una manzana es una fruta; por lo tanto, usaría la herencia para modelar la relación entre las clases Apple y Fruit. Una persona tiene un nombre; por lo tanto, usaría la agregación para modelar la relación entre las clases Persona y Nombre.

13.10.8 Interfaces vs clases abstractas

Ambas interfaces y clases abstractas se pueden utilizar para especificar un comportamiento común para los objetos. En general, una relación es-un fuerte que describe claramente una relación padre-hijo debe modelarse utilizando clases. Por ejemplo, dado que una naranja es una fruta, su relación debe modelarse utilizando la herencia de clase. Una relación débil de es-una, también conocida como una relación de tipo, indica que un objeto posee cierta propiedad. Una relación débil de is-a se puede modelar usando interfaces.

Las interfaces son más flexibles que las clases abstractas, porque una subclase solo puede extender una superclase, pero puede implementar cualquier cantidad de interfaces. Sin embargo, las interfaces no pueden contener métodos concretos. Las virtudes de las interfaces y las clases abstractas se pueden combinar creando una interfaz con una clase abstracta que la implemente. Luego se puede usar la interfaz o la clase abstracta, lo que sea conveniente.

Referencia

Liang, Y. (2013). Introduction to Java programming (10th ed., pp. 495-525). Boston: Pearson.

Deja un comentario

Diseña un sitio como este con WordPress.com
Comenzar