chapter07.en.es

Diseño de clases

Cómo escribir clases de una forma que sean fácilmente

comprensible, fácil de mantener y reutilizable

4.0

2 Primeros objetos con Java - Una introducción práctica usando BlueJ, © David J. Barnes, Michael Kölling

Principales conceptos que se tratarán

• Enganche• Cohesión• Responsabilidad diseño basado

en• Refactoring


Cambios en el software

• El software no es como una novela que se escribe una vez y luego se mantiene sin cambios.

• Software se extiende, corregir, mantener, adaptadas, adaptado ...

• El trabajo es realizado por personas diferentes en el tiempo (a menudo décadas).


Cambiar o morir

• Sólo hay dos opciones para el software:– O bien se mantiene continuamente– o se muere.

• Software que no se puede mantener será desechado.


Mundial de Zuul


Un ejemplo

• Agregue dos nuevas direcciones para el 'World of Zuul':• hasta• abajo

• ¿Qué tiene que cambiar para hacer esto?


Código calidad

• Dos conceptos importantes para la calidad del código:– Enganche– Cohesión


Enganche

• El acoplamiento se refiere a los vínculos entre las unidades separadas de un programa.

• Si hay dos clases dependen en gran medida muchos detalles de la otra, decimos que son estrechamente unida.

• Nuestro objetivo para acoplamiento flexible.


Acoplamiento flexible

• El acoplamiento flexible hace posible:– entender una clase sin haber leído

los otros;– cambiar una clase sin afectar a los

demás.– Por lo tanto: mejora la

mantenibilidad.


Cohesión

• Cohesión se refiere al número y la diversidad de las tareas que una sola unidad es responsable.

• Si cada unidad es responsable de una tarea lógica única, es decir que tiene alta cohesión.

• Cohesión se aplica a las clases y métodos.

• Nuestro objetivo para la cohesión alta.


La cohesión alta

• Cohesión alta hace que sea más fácil:– entender lo que una clase o método

hace;– utilizar nombres descriptivos;– reutilizar clases o métodos.


Cohesión de métodos

• Un método debe ser responsable de una y sólo una tarea bien definida.


La cohesión de las clases

• Las clases deben representar una entidad única y bien definida.


Código de duplicación

• Código de duplicación – es un indicador de mal diseño,– hace más difícil el mantenimiento,– puede conducir a la introducción de

errores durante el mantenimiento.


Responsabilidad diseño basado en

• Pregunta: ¿Dónde deberíamos agregar un nuevo método (que clase)?

• Cada clase debe ser responsable de la manipulación de sus propios datos.

• La clase que posee los datos deben ser responsables de su procesamiento.

• RDD lleva al bajo acoplamiento.


Localización de cambio

• Uno de los objetivos de reducir el acoplamiento y el diseño de responsabilidad impulsado es localizar el cambio.

• Cuando se necesita un cambio, ya que algunas clases como sea posible deberían verse afectadas.


Pensando en el futuro

• En el diseño de una clase, tratamos de pensar qué cambios podrían hacerse en el futuro.

• Nuestro objetivo es hacer los cambios fácilmente.


Refactoring

• Cuando las clases se mantienen, a menudo se agrega código.

• Las clases y los métodos tienden a ser más largos.

• De vez en cuando, clases y métodos deben ser refactorizado para mantener la cohesión y bajo acoplamiento.


Refactoring y pruebas

• Cuando el código de refactorización, separe la refactorización de hacer otros cambios.

• En primer lugar hacer la refactorización sólo, sin cambiar la funcionalidad.

• Pon a prueba antes y después de la refactorización para asegurarse de que nada se había roto.


Cuestiones de diseño

• Preguntas comunes:– ¿Cuánto tiempo debe ser una clase?– ¿Cuánto tiempo debe ser un

método?

• Ahora se puede responder en términos de cohesión y acoplamiento.


Pautas para el diseño

• Un método es demasiado largo si lo hace más de una tarea lógica.

• Una clase es demasiado complejo si representa más de una entidad lógica.

• Nota: estos son directrices - Que todavía dejan mucho abrir al diseñador.


Los tipos enumerados

• Una característica del lenguaje.• Usa enumeración en lugar de clase introducir un nombre de tipo.

• Uso más sencillo es definir un conjunto de nombres significativos.– Alternativa a la estática int

constantes.


Un tipo básico enumerado

public enum CommandWord{ / / El valor de cada palabra de comando, / / Más uno de los comandos no reconocidos. GO, QUIT, AYUDA, UNKNOWN;}

• Cada nombre representa un objeto del tipo enumerado, por ejemplo, CommandWord.HELP. • Objetos enumerados no se crean directamente por el programador.


Revise

• Los programas están continuamente cambiado.

• Es importante hacer este cambio posible.

• Calidad de código requiere mucho más que correcto desempeño de una vez.

• El código debe ser comprensible y mantenible.


Revise

• Código de buena calidad evita la duplicación, muestra alta cohesión, bajo acoplamiento.

• Estilo de codificación (comentando, denominación, presentación, etc) es también importante.

• Hay una gran diferencia en la cantidad de trabajo necesario para cambiar el código mal estructurado y bien estructurado.

chapter07.en.es

Documents