9 REGLAS DE LA PROGRAMACION ORIENTADA A OBJETOS

1. Utilice slo un nivel de sangra por mtodo. Si necesita ms de un nivel, es necesari

o crear un segundo mtodo y llamarlo desde el primero. Esta es una de las limitaci
ones ms importantes en el ejercicio.
No est permitido:
if() {
for(){
}
}

2. No utilice la palabra clave 'else'. Prueba una condicin con una instruccin if y
salga de la rutina si no se cumple. Esto evita if-else encadenado,
y cada rutina hace una sola cosa.
No est permitido:
if(){
}else{
if(){
}else{
}
}
3. Envuelva todas las primitivas y Strings. Esta se dirige directamente a la "ob
sesin primitiva." (ver Code smell). Si desea utilizar un nmero entero, usted prime
ro tiene que crear una clase (incluso una clase interna) para identificar que es
verdadero papel. As que los cdigos postales son un objeto no un nmero entero, por
ejemplo. Esto hace que para el cdigo mucho ms claro y comprobable.
http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/mon
ey/KentBeck_TDD_byexample.pdf
4. Utilice slo un punto por cada lnea. Este paso le impide llegar a profundizar en
otros objetos para llegar a los campos o mtodos, y por lo tanto conceptualmente
romper la encapsulacin. (Ley de Demeter) http://certified-es.blogspot.com.es/2010
/08/no-hables-con-extranos-o-la-ley-de.html
http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/de
meter.pdf
na variable es un nombre que se asocia con una porcin de la memoria del ordenador
, en la que se guarda el valor asignado a dicha variable. Hay varios tipos de va
riables que requieren distintas cantidades de memoria para guardar datos.
Todas las variables han de declararse antes de usarlas, la declaracin consiste en
una sentencia en la que figura el tipo de dato y el nombre que asignamos a la v
ariable. Una vez declarada se le podr asignar valores.
5. No abrevie los nombres. Esta restriccin evita la verbosidad de procedimiento q
ue se crea por ciertas formas de redundancia, si usted tiene que escribir el nom
bre completo de un mtodo o variable, es muy probable que pasar ms tiempo pensando
en su nombre. Y usted evitar tener objetos llamados Orden con mtodos que tengan de

recho nave Orden (). En su lugar, el cdigo tendr ms llamadas como Order.ship ().
6. Mantenga las entidades pequeas. Esto significa no ms de 50 lneas por cada clase
y no ms de 10 clases por paquete. Las 50 lneas por cada clase de restriccin es cruc
ial. No slo la fuerza concisin y mantener clases enfocadas, pero significa que la
mayora de las clases pueden caber en una sola pantalla en cualquier editor / IDE.
7. No use ninguna clase con ms de dos variables de instancia (VARIABLES). Esto es
quizs la coaccin ms difcil. Con ms de dos variables de instancia, hay casi seguramen
te una razn de subagrupar algunas variables en una clase separada.
8. Use colecciones de primera clase. En otras palabras, cualquier clase que cont
enga una coleccin no debera contener ningunas otras variables del miembro. La idea
es una extensin de la obsesin primitiva. Si necesita una clase esto es subsumir l
a coleccin, entonces escrbalo as.
9. No utilice setters, getters o propiedades. Este es un enfoque radical a la ap
licacin de la encapsulacin. Tambin se requiere la aplicacin de enfoques de inyeccin d
e dependencia y la adhesin a la mxima de "decir, no preguntes." Utilice 'Tell, D
on't Ask'
http://java.dzone.com/articles/defining-tell-dont-ask-well
http://msdn.microsoft.com/es-es/magazine/cc947917.aspx
********************************************************************************
********
VARIABLES
Una variable es un nombre que se asocia con una porcin de la memoria del ordenado
r, en la que se guarda el valor asignado a dicha variable. Hay varios tipos de v
ariables que requieren distintas cantidades de memoria para guardar datos.
Todas las variables han de declararse antes de usarlas, la declaracin consiste en
una sentencia en la que figura el tipo de dato y el nombre que asignamos a la v
ariable. Una vez declarada se le podr asignar valores.
Java tiene tres tipos de variables:
de instancia
de clase
locales
Las variables de instancia o miembros dato como veremos ms adelante, se usan para
guardar los atributos de un objeto particular.
Las variables de clase o miembros dato estticos son similares a las variables de
instancia, con la excepcin de que los valores que guardan son los mismos para tod
os los objetos de una determinada clase. En el siguiente ejemplo, PI es una vari
able de clase y radio es una variable de instancia. PI guarda el mismo valor par
a todos los objetos de la clase Circulo, pero el radio de cada crculo puede ser d
iferente
class Circulo{
static final double PI=3.1416;
double radio;
//...
}
Las variables locales se utilizan dentro de las funciones miembro o mtodos. En el
siguiente ejemplo area es una variable local a la funcin calcularArea en la que
se guarda el valor del rea de un objeto de la clase Circulo. Una variable local e
xiste desde el momento de su definicin hasta el final del bloque en el que se enc
uentra.

class Circulo{
//...
double calcularArea(){
double area=PI*radio*radio;
return area;
}
}
En el lenguaje Java, las variables locales se declaran en el momento en el que s
on necesarias. Es una buena costumbre inicializar las variables en el momento en
el que son declaradas. Veamos algunos ejemplos de declaracin de algunas variable
s
int x=0;
String nombre="Angel";
double a=3.5, b=0.0, c=-2.4;
boolean bNuevo=true;
int[] datos;
Delante del nombre de cada variable se ha de especificar el tipo de variable que
hemos destacado en letra negrita. Las variables pueden ser
Un tipo de dato primitivo
El nombre de una clase
Un array
********************************************************************************
********

CODE SMELL.A QU HUELE TU CDIGO?

Algunos dirn que a nada, como las nubes ;-) Sin embargo, el olor que desprende tu
cdigo, el llamado "CODE SMELL", trmino acuado por Kent Beck (uno de los padres del
Extreme Programming), puede darte pistas sobre problemas existentes en el mismo
y alertarte ante situaciones no deseadas.
El concepto es parecido a los antipatrones de programacin, aunque funcionan a un
nivel todava ms sutil, pues no describe situaciones completas sino indicios. De he
cho, el uso de esta metfora sensorial respecto a un cdigo, es decir, que ste despre
nda cierto tufillo, indica que sera conveniente realizar una revisin en profundida
d para ver si hay que refactorizar, pero no implica que necesariamente haya algo
incorrecto. Adems, dado que trata de algo tan personal y especfico como el cdigo f
uente, a veces las seales son bastante subjetivas y dependientes de lenguajes y t
ecnologas concretas.
Existen multitud de listas y clasificaciones, aunque es muy interesante la reali
zada por Mika Mntyl, investigador de la universidad de Helsinki, ha creado una tax
onoma que agrupa code smells relacionados en cinco categoras en funcin del efecto q
ue pueden provocar:
The bloaters (los infladores), que agrupa 'aromas' que indican el crecimiento ex
cesivo de algn aspecto que hacen incontrolable el cdigo.
*Long method (mtodo extenso) que precisa de su reduccin para ser ms legible y man
tenible.
*Large class (clase larga), con sntomas y consecuencias muy similares al caso a
nterior.

*Primitive obsession (obsesin por tipos primitivos), cuyo sntoma es la utilizacin

de tipos primitivos para almacenar datos de entidades pequeas (por ejemplo,
usar un long para guardar un nmero de telfono).
*Long parameter list (lista de parmetros larga), que incrementan la complejidad
de un mtodo de forma considerable.
*Dataclumps (grupos de datos), o uso de un cunjunto de variables o propiedades
de tipos primitivos en lugar de crear una clase apropiada para almacenar los da
tos, lo que a su vez provoca el incremento de parmetros en mtodos y clases.
The Object-Orientation Abusers (los maltratadores de la orientacin a objetos), qu
e aglutina code smells que indican que no se est aprovechando la potencia de este
paradigma:
*Switch statements (sentencias Switch), que podran indicar una falta de utiliza
cin de mecanismos de herencia.
*Temporary field (campo temporal), que se salta el principio de encapsulamient
o y ocultacin de variables haciendo que stas pertenezcan a la clase cuando su mbito
debera ser exclusivamente el mtodo que las usa.
*Refused bequest (rechazo del legado), cuando una subclase 'rechaza' mtodos o p
ropiedades heredadas, atentando directamente contra uno de los principales pilar
es de la OOP.
*Alternative Classes with Different Interfaces (clases alternativas con distin
tos interfaces) indica la ausencia de interfaces comunes entre clases similares.
The change preventers (los impedidores de cambios)
*Divergent Change (cambio divergente), que hace que sean implementadas dentro
de la misma clase funcionalidades sin ninguna relacin entre ellas, lo que sugiere
extraerlas a una nueva clase.
*Shotgun surgery (ciruja de escopeta), ocurre cuando un cambio en una clase imp
lica modificar varias clases relacionadas.
*Parallel Inheritance Hierarchies (jerarquas de herencia paralelas), paralelism
o que aparece cuando cada vez que se crea una instancia de una clase es necesari
o crear una instancia de otra clase, evitable uniendo ambas en una ncia clase fin
al.
The Dispensables (los prescindibles), pistas aportadas por porciones de cdigo inn
ecesarias que podran y deberan ser eliminadas:
*Lazy class (clase holgazana), una clase sin apenas responsabilidades que hay
que dotar de sentido, o bien eliminar.
*Data class (clase de datos), cuando una clase slo se utiliza para almacenar da
tos, pero no dispone de mtodos asociados a stos.
*Duplicate code (cdigo duplicado), presencia de cdigo duplicado que dificulta en
ormemente el mantenimiento.
*Dead code (cdigo muerto), aparicin de cdigo que no se utiliza, probablemente pro
cedente de versiones anteriores, prototipos o pruebas.
*Speculative generality (generalizacin especulativa), ocurre cuando un cdigo int
enta solucionar problemas ms all de sus necesidades actuales.
The couplers (Los emparejadores), son code smells que alertan sobre problemas de
acoplamiento componentes, a veces excesivo y otras demasiado escaso.
*Features envy (envidia de caractersticas), que aparece cuando existe un mtodo d
e una clase que utiliza extensivamente mtodos de otra clase y podra sugerir la nec
esidad de moverlo a sta.
*Inappropriate intimacy (intimidad inapropiada), ocurre cuando dos clases de c
onocen demasiado y usan con demasiada confianza, y a veces de forma inapropiada,
sus miembros (en la acepcin POO del trmino ;-))
*Message Chains (cadenas de mensajes), aroma desprendido por cdigo que realiza

una cadena de llamadas a mtodos de clases distintas utilizando como parmetros el r

etorno de las llamadas anteriores, como A.getB().getC().getD().getTheNeededData(
), que dejan entrever un acoplamiento excesivo de la primera clase con la ltima.
*Middle man (intermediario), que cuestiona la necesidad de tener clases cuyo ni
co objetivo es actuar de intermediaria entre otras dos clases.
Aunque agrupadas bajo otros criterios, existe una interesante relacin de code s
mells y la refactorizacin a aplicar en cada caso, que ayuda a determinar las acci
ones correctivas oportunas una vez se haya comprobado que hay algo que no va bie
n.
VER TAMBIN. http://trainedchimpanzees.blogspot.com.es/2010/08/code-smells-obses
ion-primitiva.html