Definicion de metodos

Definición de métodos

La firma del método la comprenden dos de los componentes de la declaración—el nombre del método y los tipos de parámetros.

Los únicos elementos requeridos de una declaración de método son su tipo de retorno, su nombre, una pareja de paréntesis, () y un cuerpo entre corchetes {}.

Las declaraciones de métodos tienen, en general, seis componentes, en este orden:

1. Modificadores, como public, private y otros que se comentarán más adelante.
2. El tipo de retorno, el tipo de dato del valor devuelto por el método, o void si el método no devuelve ningún valor.
3. El nombre del método—las reglas de nomenclatura de campos también se aplica a los nombres de métodos, pero el convenio difiere un poco.
4. La lista de parámetros entre paréntesis—una lista, separada por comas, de parámetros de entrada, precedidos por su tipo de dato, encerrado entre paréntesis (). Si no hay parámetros se deben utilizar paréntesis vacíos.
5. Una lista de excepciones—se verá más tarde.
6. El cuerpo del método, encerrado entre llaves—aquí va el código del método, incluyendo la declaración de variables locales.

Métodos de instancia

Los métodos pueden clasificarse en métodos de instancia y métodos de clase.
Los métodos de instancia operan sobre las variables de instancia de los objetos pero también tienen acceso a las variables de clase. La sintaxis de llamada a un método de instancia es:

idReferencia.idMetodo(parametros); // Llamada típica a un método de instancia

Todas las instancias de una clase comparten la misma implementación para un método de instancia. La instancia que hace la llamada al método es siempre un parámetro o argumento implícito. Dentro de un método de instancia, el identificador de una variable de instancia hace referencia al atributo de la instancia concreta que hace la llamada al método (suponiendo que el identificador del atributo no ha sido ocultado por el de un parámetro).

Métodos de clase
En principio, los métodos de clase no operan sobre las variables de instancia de los objetos.
Los métodos de clase pueden trabajar con las variables de clase pero no pueden acceder a las variables de instancia declaradas dentro de la clase. Los métodos de clase también pueden ser llamados precediéndolos con el identificador de la clase, sin necesidad de utilizar el de una instancia.

IdClase.idMetodo(parametros); // Llamada típica a un método de clase

La palabra static determina la declaración de un método de clase. Por defecto, si no se indica la palabra static, el método declarado se considera un método de instancia.

Los métodos de clase o estáticos se pueden considerar equivalentes a las rutinas (globales) de otros lenguajes de programación como Pascal o C. Las llamadas a estos métodos se realizan anteponiendo el identificador de la clase Math al identificador del método:
Math.sin(angulo)…

Modularidad

Un diseño modular se basa en la conocida estrategia de “divide y vencerás”. Descomponer de forma lógica y robusta el dominio de la aplicación.

Para conseguir la modularidad también debemos aplicar  las reglas de coherencia de métodos y clases que vimos con el principio de generalidad, es decir, hacer que nuestros componentes sean especialistas.

La modularidad facilita la reusabilidad y reduce costes, pero usada con prudencia.

Hay diversas condiciones que permiten llegar a la modularidad:

1.       Descomposición funcional. Ver cada módulo como un especialista (aplicación de la regla de la coherencia).

2.       Bajo acoplamiento. Además de ser especialistas tienen la mayor autonomía posible.

3.       Comprensibles para un observador externo. Esto es obvio, pero no es tan común como parece. El objetivo es que cada módulo sea comprensible de forma independiente (cómo mucho obligar a un somero repaso de otros módulos), para ello  los módulos deben obedecer a la lógica del dominio, ser legibles y estar bien documentados.

4.       De 1 y 3 se deduce la condición de la trazabilidad.

Cuando hablamos de un diseño modular hablamos de bajo acoplamiento o poca dependencia entre módulos. La regla del bajo acoplamiento implica:

• Interfaces pequeños: que los métodos públicos que intercambian información con otros módulos sean:

• El menor número posible.

• Pequeños. Pocos argumentos. Si un método tiene muchos parámetros, probablemente hay revisar el diseño o encapsular los parámetros en una clase.

                En el siguiente ejemplo tenemos dos versiones de un método. El segundo método no sólo tiene menos argumentos, además resulta más comprensible:

fabrica.solicitar_pedido( Fec, Hora, CodComer, Cantidad, PVP, ModoEntrega )

fabrica.solicitar_pedido( pedido nuevo_pedido )

• Regla de la continuidad modular: debemos diseñar y programas de tal forma que pequeños cambios en un módulo producen a lo sumo pequeños cambios en otro. Evidentemente, esto facilita la extensibilidad y minimiza los costes de mantenimiento.

• Regla de la protección modular: los errores en un módulo afectan como mucho a módulos adyacentes.

• Regla de la comunicación explicita: la comunicación entre módulos es clara. Normalmente por medio de interfaces con pocos parámetros y sin usar información global (que hace que la interacción quede oculta).

• Encapsular la implementación. También en los módulos hay que diferenciar lo público de lo privado. Un cambio en la parte privada no debería afectar al interfaz del módulo.

Antes dijimos que si  los módulos no obedecen a la lógica del dominio, no son legibles o no están bien documentados, entonces la descomposición es inútil y no permite la reusabilidad.

Cuando se dice que la descomposición de los módulos obedece a la lógica del dominio, se quiere decir que la mayoría de cada uno de  módulos debe ser una representación natural de entidades o relaciones del dominio (por ejemplo: cuenta, beneficiario, oficina, control de riesgo, etc.). Decimos la mayoría: ya que habrá módulos que no modelizan entes del dominio (pertenecen al dominio de la aplicación exclusivamente: interfaz gráfico, sentencia SQL, etc.).

Se debe representar la continuidad entre los conceptos del proceso de desarrollo.

La regla de la trazabilidad indica que cada conjunto lógico de entidades y relaciones del dominio tiene su correlato modular. Esto facilita la extensibilidad  y la reusabilidad.

Los métodos de Diseño orientado a facetas, orientados a aspectos o temas hacen énfasis en mejorar la trazabilidad de requisitos.

De todo lo anterior (coherencia, bajo acoplamiento, etc.) se deduce que gran parte de nuestras aplicaciones se descomponen en módulos que reflejan su especialización funcional:

• Interfaz con el usuario.

• Implementación. Se aplican cálculos y algoritmos específicos al dominio.

• Control. También implica conocimiento específico del dominio. Componentes que especifican el orden de las tareas y las condiciones de disparo (Si-entonces). Comprueban estados y errores. No tienen cálculos o algoritmos complejos. Por ejemplo, reglas de negocio del tipo: “Si el solicitante es cliente, entonces producir pedido; si no, solicitar registro de nuevo cliente”.

• Almacenamiento y conectividad. Módulos responsables de la interacción con la base de datos y otras aplicaciones.

En la práctica, sobre todo en aplicaciones que no son muy grandes,  se suelen reunir en un módulo las clases de implementación y de control.

Un ejemplo es la arquitectura en tres capas, tan usual en aplicaciones Web:

• Presentación

• Reglas de negocio

• Acceso a datos (almacenamiento y conectividad)