Otra cosa:
La POO cuando es algo que debe venir de forma natural. Siempre me ha parecido que es un atentado a la educacion cuando a la gente en su curso introductorio le dan el tema del polimorfismo o de patrones y todo eso. Es como uno estar en un curso de cocina y que empiezen por explicarle las diversas famialias de frutas, verduras, carnes, condimentos y todo eso.
Lo unico que hay que saber para ser un "duro" con la programacion es esto:
* Los sustantivos son los nombres de las clases (ej: Ventana, Cliente)
* Los adjetivos, sus propiedades (Alto, Ancho)
* Los verbos son las acciones que:
- Si son verbos directos, metodos (Close)
- Sin son verbos preguntones, funciones (CanClose())
- Sin son verbos de "momentos" son eventos (WhenClose())
Usar nombres claros y directos. Si pones:
y lo documentarias como:
Cita:
|
Funcion que determina si el cliente es valido
|
entonces dejate de bobadas y cambialo por
y te ahorraste la documentacion
- Haz pedazos de codigo que sean concisos y se dedican a una sola cosa.
- Haz clases que se encargen de mover las acciones de un lado a otro. Clases de control (ej: Para mover un inventario). No mezcles clases que controlan con clases que informan o que definen una entidad simple a menos que haya muy poco que controlar.
- Haz codigo testeable. Metete en el asunto de TTD (Test Driven Desing). El resultado de un codigo testeable es casi sin equivocacion una excelente POO.
- Cuando creas que algo esta mal hecho, esta mal hecho.
- No uses ejemplos de Java o C* para aprender OO. Por regla general son muy complicados. Lee pascal, o python. Son los lenguajes que por regla general tienen las soluciones mas sencillas posibles
Leete y aprendete el Zen de python, y aplicalo en Delphi:
Cita:
* Bello es mejor que feo.
* Explícito es mejor que implícito.
* Simple es mejor que complejo.
* Complejo es mejor que complicado.
* Plano es mejor que anidado.
* Disperso es mejor que denso.
* La legibilidad cuenta.
* Los casos especiales no son tan especiales como para quebrar las reglas.
* Aunque la practicidad le gana a la pureza.
* Los errores nunca deberían dejarse pasar silenciosamente.
* A menos que hayan sido silenciados explícitamente.
* Frente a la ambigüedad, rechazar la tentación de adivinar.
* Debería haber una -y preferiblemente sólo una- manera obvia de hacerlo.
* Aunque esa manera puede no ser obvia al principio a menos que usted sea Holandés.
* Ahora es mejor que nunca.
* Aunque nunca es a menudo mejor que ya.
* Si la implementación es dificil de explicar, es una mala idea.
* Si la implementacion es fácil de explicar, puede que sea una buena idea.
|