Chapter07 en Es

Diseo de clases
Cmo escribir clases de una forma que sean fcilmente comprensible, fcil de mantener y reutilizable
4.0
Principales conceptos que se tratarn

Enganche Cohesin Responsabilidad diseo basado en Refactoring
Primeros objetos con Java - Una introduccin prctica usando BlueJ, David J. Barnes, Michael Klling
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 dcadas).
Cambiar o morir
Slo 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?
Cdigo calidad
Dos conceptos importantes para la calidad del cdigo:
Enganche Cohesin
Enganche
El acoplamiento se refiere a los vnculos 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 ledo los otros; cambiar una clase sin afectar a los dems. Por lo tanto: mejora la mantenibilidad.
Cohesin
Cohesin se refiere al nmero y la diversidad de las tareas que una sola unidad es responsable. Si cada unidad es responsable de una tarea lgica nica, es decir que tiene alta cohesin. Cohesin se aplica a las clases y mtodos. Nuestro objetivo para la cohesin alta.
10
La cohesin alta
Cohesin alta hace que sea ms fcil:
entender lo que una clase o mtodo hace; utilizar nombres descriptivos; reutilizar clases o mtodos.
11
Cohesin de mtodos
Un mtodo debe ser responsable de una y slo una tarea bien definida.
12
La cohesin de las clases

Las clases deben representar una entidad nica y bien definida.
13
Cdigo de duplicacin
Cdigo de duplicacin
es un indicador de mal diseo, hace ms difcil el mantenimiento, puede conducir a la introduccin de errores durante el mantenimiento.
14
Responsabilidad diseo basado en

Pregunta: Dnde deberamos agregar un nuevo mtodo (que clase)? Cada clase debe ser responsable de la manipulacin de sus propios datos. La clase que posee los datos deben ser responsables de su procesamiento. RDD lleva al bajo acoplamiento.
15
Localizacin de cambio
Uno de los objetivos de reducir el acoplamiento y el diseo de responsabilidad impulsado es localizar el cambio. Cuando se necesita un cambio, ya que algunas clases como sea posible deberan verse afectadas.
16
Pensando en el futuro
En el diseo de una clase, tratamos de pensar qu cambios podran hacerse en el futuro. Nuestro objetivo es hacer los cambios fcilmente.
17
Refactoring
Cuando las clases se mantienen, a menudo se agrega cdigo. Las clases y los mtodos tienden a ser ms largos. De vez en cuando, clases y mtodos deben ser refactorizado para mantener la cohesin y bajo acoplamiento.
18
Refactoring y pruebas
Cuando el cdigo de refactorizacin, separe la refactorizacin de hacer otros cambios. En primer lugar hacer la refactorizacin slo, sin cambiar la funcionalidad. Pon a prueba antes y despus de la refactorizacin para asegurarse de que nada se haba roto.
19
Cuestiones de diseo
Preguntas comunes:
Cunto tiempo debe ser una clase? Cunto tiempo debe ser un mtodo?
Ahora se puede responder en trminos de cohesin y acoplamiento.

20
Pautas para el diseo

Un mtodo es demasiado largo si lo hace ms de una tarea lgica. Una clase es demasiado complejo si representa ms de una entidad lgica. Nota: estos son directrices - Que todava dejan mucho abrir al diseador.
21
Los tipos enumerados

Una caracterstica del lenguaje. Usa enumeracin en lugar de clase introducir un nombre de tipo. Uso ms sencillo es definir un conjunto de nombres significativos.
Alternativa a la esttica int constantes.
22
Un tipo bsico enumerado

public enum CommandWord { / / El valor de cada palabra de comando, / / Ms 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.
23
Revise
Los programas estn continuamente cambiado. Es importante hacer este cambio posible. Calidad de cdigo requiere mucho ms que correcto desempeo de una vez. El cdigo debe ser comprensible y mantenible.
24
Revise
Cdigo de buena calidad evita la duplicacin, muestra alta cohesin, bajo acoplamiento. Estilo de codificacin (comentando, denominacin, presentacin, etc) es tambin importante. Hay una gran diferencia en la cantidad de trabajo necesario para cambiar el cdigo mal estructurado y 25 bien estructurado.

Chapter07 en Es

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Chapter07 en Es

Загружено:

Авторское право:

Доступные форматы

Diseo de clases

Principales conceptos que se tratarn

Software que no se puede mantener ser desechado.

Qu tiene que cambiar para hacer esto?

La cohesin de las clases

Responsabilidad diseo basado en

Ahora se puede responder en trminos de cohesin y acoplamiento.

Pautas para el diseo

Los tipos enumerados

Un tipo bsico enumerado

Cada nombre representa un objeto del tipo

Вам также может понравиться