9.4 Relación entre las superclases y las subclases 

399

(es decir, métodos que no sean 

private

) y no en la implementación de datos de la superclase. Si hay variables de 

instancia

protected

 en la superclase, tal vez necesitemos modifi car todas las subclases de esa superclase si cambia 

la implementación de ésta. Por ejemplo, si por alguna razón tuviéramos que cambiar los nombres de las variables 
de instancia 

primerNombre

 y 

apellidoPaterno

 por 

nombre

 y 

apellido

, entonces tendríamos que hacerlo para 

todas las ocurrencias en las que una subclase haga referencia directa a las variables de instancia 

primerNombre

 y 

apellidoPaterno

 de la superclase. En tal caso, se dice que el software es 

frágil

 o 

quebradizo

, ya que un pequeño 

cambio en la superclase puede “quebrar” la implementación de la subclase. Es conveniente que el programador 
pueda modifi car la implementación de la superclase sin dejar de proporcionar los mismos servicios a las subclases. 
(Desde luego que, si cambian los servicios de la superclase, debemos reimplementar nuestras subclases). Un tercer 
problema es que los miembros 

protected

 de una clase son visibles para todas las clases que se encuentren en el 

mismo paquete que la clase que contiene los miembros 

protected

; esto no siempre es conveniente.

Observación de ingeniería de software 9.6

Use el modifi cador de acceso 

protected

 cuando una superclase deba proporcionar un método sólo a sus subclases y 

a otras clases en el mismo paquete, pero no a otros clientes.

Observación de ingeniería de software 9.7

Al declarar variables de instancia 

private

 (a diferencia de 

protected

) en la superclase, se permite que la im-

plementación de la superclase para estas variables de instancia cambie sin afectar las implementaciones de las sub-
clases.

Tip para prevenir errores 9.1

Siempre que sea posible, no incluya variables de instancia

protected

 en una superclase. En vez de ello, incluya 

métodos no 

private

 que accedan a las variables de instancia 

private

. Esto asegurará que los objetos de la clase 

mantengan estados consistentes.

9.4.5 La jerarquía de herencia 

EmpleadoPorComision

-

EmpleadoBaseMasComision

 mediante el uso de variables 

de

instancia private

Ahora reexaminaremos nuestra jerarquía una vez más, pero ahora utilizaremos las mejores prácticas de ingeniería 
de software. La clase 

EmpleadoPorComision3

 (fi gura 9.12) declara las variables de instancia 

primerNombre

,

apellidoPaterno

,

numeroSeguroSocial

,

ventasBrutas

 y 

tarifaComision

 como 

private

(líneas 6 a 10) y

proporciona los métodos 

publicestablecerPrimerNombre

,

obtenerPrimerNombre

,

establecerApelli-

doPaterno

,

obtenerApellidoPaterno

,

establecerNumeroSeguroSocial

,

obtenerNumeroSeguroSocial

,

establecerVentasBrutas

,

obtenerVentasBrutas

,

establecerTarifaComision

,

obtenerTarifaComision

,

ingresos

y

toString

 para manipular estos valores. Observe que los métodos 

ingresos

(líneas 85 a 88) y

toString

 (líneas 91 a 98) utilizan los métodos 

obtener de la clase para obtener los valores de sus variables de 

instancia. Si decidimos modifi car los nombres de las variables de instancia, no habrá que modifi car las declara-
ciones de 

ingresos

 y de 

toString

; sólo habrá que modifi car los cuerpos de los métodos 

obtener y establecer que 

manipulan directamente estas variables de instancia. Observe que estos cambios ocurren sólo dentro de la super-
clase; no se necesitan cambios en la subclase. La localización de los efectos de los cambios como éste es una buena 
práctica de ingeniería de software. La subclase 

EmpleadoBaseMasComision4

 (fi gura 9.13) hereda los miembros 

no

private

de

EmpleadoPorComision3

 y puede acceder a los miembros 

private

 de su superclase, a través de 

esos métodos.

La clase 

EmpleadoBaseMasComision4

 (fi gura 9.13) tiene varios cambios en las implementaciones de sus 

métodos, que la diferencian de la clase 

EmpleadoBaseMasComision3

 (fi gura 9.10). Los métodos 

ingresos

(fi gu-

ra 9.13, líneas 31 a 34) y 

toString

 (líneas 37 a 41) invocan cada uno al método 

obtenerSalarioBase

 para 

obtener el valor del salario base, en vez de acceder en forma directa a 

salarioBase

. Si decidimos cambiar el 

nombre de la variable de instancia 

salarioBase

, sólo habrá que modifi car los cuerpos de los métodos 

estable-

cerSalarioBase

y

obtenerSalarioBase

.

El método 

ingresos

de la clase 

EmpleadoBaseMasComision4

 (fi gura 9.13, líneas 31 a 34) redefi ne al méto-

do

ingresos

 de la clase 

EmpleadoPorComision3

 (fi gura 9.12, líneas 85 a 88)para calcular los ingresos de un 

09_MAQ_CAP_09.indd399

4/19/081:24:36AM