Ir al contenido principal

Los principios pigbar para la Programación Orientada a Objetos (OOP)

Puede sonar pretencioso, y lo es, pero este es un resumen de una serie de normas o reglas que se deben imponer a los equipos de desarrollo con respecto al diseño o construcción de sus clases. No negociables.



  1. Toda clase debe implementar una interface.
  2. Toda clase o es final o es abstracta.
  3. Todas las propiedades son privadas.
  4. Todas las propiedades son final.
  5. Todos los métodos son públicos.
  6. No existen clases sin métodos reales o funcionales (getter y setter no son métodos reales).
  7. No existen clases sin propiedades.
  8. Toda clase debe tener al menos un constructor primario.
  9. Todos los constructores secundarios deben invocar al primario.
  10. Toda clase debe tener como máximo ocho propiedades.
  11. Toda Interface debe declarar como máximo ocho métodos.
  12. Toda clase debe ser lo más inmutable posible.
  13. No existen propiedades estáticas.
  14. No existen métodos estáticos.
  15. No se admiten Setters.
  16. Los Getters no se recomiendan.
  17. No se recomiendan las Anotaciones.
  18. No existen referencias a NULL.
  19. No existen métodos retornando o recibiendo NULL.
  20. No existen DTOs (deriva de las reglas 6 y 7).
  21. Todos los métodos deben retornar un valor no nulo.
  22. Dígale al objeto qué hacer, NO le pida los datos al objeto para hacer Ud las cosas.

Los equipos de desarrollo no son una democracia. Deben ser comandos de élite dirigidos por líderes competentes y donde las decisiones de arquitectura, si bien se discuten, son tomadas por el arquitecto y tienen carácter Final.

Comentarios

Entradas populares de este blog

El Melange todavía corre

Ese era el estribillo de un capítulo de unas de mis series favoritas de la infancia, Meteoro o Speed Racer. En ese capítulo un auto “fantasma” el X-3, aparecía de imprevisto y dejaba a todos asombrados con su rendimiento y prestaciones y volvía a desaparecer. Traigo ese episodio a colación puesto que recientemente sostuve una amena charla con un querido amigo, en la que el me manifestaba como los Mainframes habían muerto, o mejor dicho, el concepto de la computación distribuida basada en Mainframes había desaparecido. Para variar, yo no estuve de acuerdo, y le dije que por el contrario, el modelo de computación basado en Mainframes está mas vigente que nunca. Estos fueron mis argumentos:

Primeros pasos con Camunda BPM – Modelando un Proceso BPMN 2.0

Tenemos entre manos la tercera publicación de nuestra serie sobre la Plataforma de BPM de Camunda .  El día de hoy vamos, por fin, a empezar a modelar o construir nuestro primer proceso sencillo en notación BPMN 2.0. Para ello vamos a usar el modelador o editor que ya hemos instalado en nuestra primera publicación , y vamos a guardarlo en la sección de recursos del proyecto Maven Java que configuramos en la segunda publicación . Así que, como ya es costumbre, manos a las sobras…

Como configurar jBPM para usar nuestra propia Base de Datos en un sólo paso

Llevo un buen rato trabajando con jBPM en su serie 6.x, y mi opinión sobre este producto en la versión mecionada no ha mejorado para nada. Es una herramienta plena de funciones y caracteristicas avanzadas, pero tambien está llena de Bugs y es realmente inestable, sobre todo en el ambiente de modelamiento.  Así mismo, debo decir que tiene una muy aceptable API REST y que el motor de procesos y la consecuente ejecución de los procesos es estable y bastante rápida. En esta publicación daré inicio a una serie de artículos que hablan sobre ciertas configuraciones comunes e importantes que se hacen con jBPM. Hoy iniciamos con la configuración de jBPM para que use nuestra base de datos favorita. Esto tiene sentido porque el producto viene con la base de datos H2 por omisión, la cual es excelente para pruebas y evaluaciones rápidas de la herramienta, pero es completamente inaceptable en un ambiente de desarrollo, QA o producción cualquiera. Así que manos a l