frankyjquintero/ParcialTDD

Stars
1
Language
C#
Created about 6 years ago
Updated about 6 years ago

frankyjquintero/ParcialTDD

frankyjquintero

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

DesignPatterns

Un design pattern o patrón de diseño consiste en un diagrama de objetos que forma una solución a un problema conocido y frecuente. El diagrama de objetos está constituido por un conjunto de objetos descritos por clases y las relaciones que enlazan los objetos. Los patrones responden a problemas de diseño de aplicaciones en el marco de la programación orientada a objetos. Se trata de soluciones conocidas y probadas cuyo diseño proviene de la experiencia de los programadores. No existe un aspecto teórico en los patrones, en particular no existe una formalización (a diferencia de los algoritmos).

InPort-DDD-CQRS-TDD

InPort => DDD - CQRS (Consistencia Inmediata) - TDD - Event Sourcing - Domain Notification - Domain Event

TDD_Clase1

Ejemplo de aplicación TDD clase 1 Diseño dirigido

docker-image-jenkins-agents-base

Imagen Docker Base para Agentes de Jenkins

EjemploPooInterfaces

Uso e interfaces para la comunicacion de formularios

Unit-Of-Work-Example

Unit Of Work, Services y Repository Pattern usando Net Core 2.0

teamcity-agent-android-build-box

GRASP-Indireccion

hello-world-nodejs-docker

Dockerizando un Node.js web app - Hola Mundo

TemplateMethod

Template Method Este sencillo patrón resulta útil en casos en los que podamos implementar en una clase abstracta el código común que será usado por las clases que heredan de ella, permitiéndoles que implementen el comportamiento que varía mediante la reescritura (total o parcial) de determinados métodos. La diferencia con la forma común herencia y sobreescritura de los métodos abstractos estriba en que la clase abstracta contiene un método denominado 'plantilla' que hace llamadas a los que han de ser implementados por las clases que hereden de ella.

FlyweightyFactoryPattern

Flyweight y Factory Pattern El patrón Flyweight está íntimamente ligado a otro de los patrones que ya hemos visto: el patrón factoría o Factory Pattern. El motivo no es otro que permitir que sea el objeto que implementa este patrón el que gestione la separación entre la parte “común” (denominada intrínseca) y la parte “privada” (denominada extrínseca), centralizando el proceso y evitando así que perdamos referencias por el camino si realizamos el proceso de una forma un poco más artesanal. Por lo tanto, dentro de un patrón Flyweight, distinguiremos entre estos dos tipos de datos: Intrínsecos: son los datos compartidos por todos los objetos de un subtipo determinado. Por norma general, son datos que no cambiarán a lo largo del tiempo, y si cambian, alterarán el estado de todos los objetos que hagan uso de ellos. Extrínsecos: se calculan “al vuelo” fuera del objeto Flyweight. Este cálculo suele realizarse a partir de los datos intrínsecos y de los parámetros recibidos por los métodos del objeto Flyweight. La idea detrás de los datos extrínsecos radica en que, o bien sean calculados a partir de los datos intrínsecos o bien ocupe una cantidad de memoria mínima en comparación a éstos.