CRUD (create, read, update and delete)

El software debe permitir al usuario:

  1. Crear o añadir nuevas entradas
  2. Leer, recuperar, buscar, o ver las entradas existentes
  3. Actualizar o editar las entradas existentes
  4. Eliminar / desactivar entradas existentes

 

Operation                          SQL              HTTP(Rest)
Create                             INSERT               POST
Read (Retrieve)          SELECT                GET
Update (Modify)        UPDATE       PUT / PATCH
Delete (Destroy)         DELETE            DELETE 

Anuncios
CRUD (create, read, update and delete)

SOLID

S (Single Responsibility Principle / Principio de Responsabilidad Única )
Establece que cada clase debe tener una responsabilidad individual, y que la responsabilidad debe ser completamente encapsulado por la clase. Todos los servicios deben estar estrechamente alineados con esa responsabilidad.

O (Open/Closed Principle / Principio de Abierto/Cerrado)
Las entidad de software (classes, módulos, funciones, etc.) deben estar abiertas para la extensión, pero cerradas para la modificación.

L (Liskov Substitution Principle / Principio de sustitución de Liskov)
Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas. En lenguaje mas formal: si S es un subtipo de T, entonces los objetos de tipo T en un programa de computadora pueden ser sustituidos por objetos de tipo S (es decir, los objetos de tipo S pueden ser sustitutos de objetos de tipo T), sin alterar ninguna de las propiedades deseables de ese programa (la corrección, la tarea que realiza, etc.) Más formalmente, El Principio de Sustitución de Liskov (LSP) es una definición particular de una relación de subtipificación, llamada tipificación (fuerte) del comportamiento

I (Interface-segregation Principle / Principio de segregación de Interfaces)
“Los clientes no deben estar obligados a implementar una interfaces que luego no usarán”
La primer forma de hacer una interfaz pesada es crear una interfaz con mucha funcionalidad que solo usa una implementación y que las otras la heredan pero no hacen nada o como mucho elevan una excepción del estilo “Esto no esta permitido”.
Otra forma de hacer una interfaz “pesada” es que tenga mas información de la que necesita.

D (Dependency Inversion Principle / Principio de Inversión de Dependencias)
Los módulos de alto nivel no deben depender de los módulos de menor nivel. Ambos deben depender de sus abstracciones.
Las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones.
Este principio es la guinda del postre. Es decir, no es posible hacer este principio sin cumplir con los anteriores.

Fuentes: wikipedia, danielmazzini.

SOLID

Principio de Pareto

(Texto sacado de la wikipedia)
En el mundo de la Ingeniería del Software el principio de Pareto puede ser enunciado de diferentes formas:
* Así por ejemplo cuando hablamos de los costes de desarrollo podríamos decir que “el 80% del esfuerzo de desarrollo (en tiempo y recursos) produce el 20% del código, mientras que el 80% restante es producido con tan sólo un 20% del esfuerzo”
* Si hablamos de Pruebas de Software, el principio nos dice que “el 80% de los fallos de un software es generado por un 20% del código de dicho software, mientras que el otro 80% genera tan solo un 20% de los fallos”.
Además existen algunas particularizaciones o instancias conocidas del principio, como la Regla del noventa-noventa cuyo enunciado dice que “El primer 90% del código ocupa el 10% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo.”
Principio de Pareto