1.

Poo
1.1. Polimorfismo
1.2. Encapsulamiento
1.3. Genericidad
2. Arquitectura
2.1. Aspect oriented programming
2.2. Software as a service
2.3. Monitorizacin: como la implementaras.
2.4. Certificados de servidor
2.5. Cifrado de ensamblados
3. Patrones y diseo
3.1. Deuda tcnica
3.2. Patrones y buenas prcticas conocidos
3.3. Stateless Stateful
3.4. DDD
3.5. REST
3.6. Cache
4. Testing
4.1. Fakes, Mocks y stubs
4.2. Caja Negra y caja blanca
4.3. Tipos de test
4.4. Alpha-Beta testing
5. Escalabilidad
6. Resistencia a fallos

Patrn singleton, strategy,Repository,IoC,Bridge

Patrn MVVM, MVC, MVP

Abstract Factory: proporciona una interfaz para crear familias de objetos o que dependen
entre s, sin especificar sus clases concretas.

Builder: separa la construccin de un objeto complejo de su representacin, de forma que el

mismo proceso de construccin pueda crear diferentes representaciones.

Factory Method: define una interfaz para crear un objeto, pero deja que sean las subclases
quienes decidan qu clase instanciar. Permite que una clase delegue en sus subclases la
creacin de objetos.

Prototype: especifica los tipos de objetos a crear por medio de una instancia prototpica, y
crear nuevos objetos copiando este prototipo.

Singleton: garantiza que una clase slo tenga una instancia, y proporciona un punto de
acceso global a ella.

Adapter: convierte la interfaz de una clase en otra distinta que es la que esperan los clientes.
Permiten que cooperen clases que de otra manera no podran por tener interfaces
incompatibles.

Bridge: desvincula una abstraccin de su implementacin, de manera que ambas puedan

variar de forma independiente.

Composite: combina objetos en estructuras de rbol para representar jerarquas de partetodo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los
compuestos.

Decorator: aade dinmicamente nuevas responsabilidades a un objeto, proporcionando una

alternativa flexible a la herencia para extender la funcionalidad.

Facade: proporciona una interfaz unificada para un conjunto de interfaces de un subsistema.

Define una interfaz de alto nivel que hace que el subsistema se ms fcil de usar.

Flyweight: usa el compartimiento para permitir un gran nmero de objetos de grano fino de
forma eficiente.

Proxy: proporciona un sustituto o representante de otro objeto para controlar el acceso a

ste.

Patrones de comportamiento

Chain of Responsibility: evita acoplar el emisor de una peticin a su receptor, al dar a ms

de un objeto la posibilidad de responder a la peticin. Crea una cadena con los objetos
receptores y pasa la peticin a travs de la cadena hasta que esta sea tratada por algn
objeto.

Command: encapsula una peticin en un objeto, permitiendo as parametrizar a los clientes

con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la
operaciones.

Interpreter: dado un lenguaje, define una representacin de su gramtica junto con un

intrprete que usa dicha representacin para interpretar las sentencias del lenguaje.

Iterator: proporciona un modo de acceder secuencialmente a los elementos de un objeto

agregado sin exponer su representacin interna.

Mediator: define un objeto que encapsula cmo interactan un conjunto de objetos.

Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros
explcitamente, y permite variar la interaccin entre ellos de forma independiente.

Memento: representa y externaliza el estado interno de un objeto sin violar la encapsulacin,

de forma que ste puede volver a dicho estado ms tarde.

Observer: define una dependencia de uno-a-muchos entre objetos, de forma que cuando un
objeto cambia de estado se notifica y actualizan automticamente todos los objetos.

State: permite que un objeto modifique su comportamiento cada vez que cambia su estado
interno. Parecer que cambia la clase del objeto.

Strategy: define una familia de algoritmos, encapsula uno de ellos y los hace
intercambiables. Permite que un algoritmo vare independientemente de los clientes que lo
usan.

Template Method: define en una operacin el esqueleto de un algoritmo, delegando en las

subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del
algoritmo sin cambiar su estructura.

Visitor: representa una operacin sobre los elementos de una estructura de objetos. Permite
definir una nueva operacin sin cambiar las clases de los elementos sobre los que opera.

a Programacin Orientada a Aspectos o POA (en ingls: aspect-oriented programming) es

un paradigma de programacin relativamente reciente cuya intencin es permitir una adecuada
modularizacin de las aplicaciones y posibilitar una mejor separacin de responsabilidades
(Obligacin o correspondencia de hacer algo).
Gracias a la POA se pueden encapsular los diferentes conceptos que componen una aplicacin en
entidades bien definidas, eliminando las dependencias entre cada uno de los mdulos. De esta forma
se consigue razonar mejor sobre los conceptos, se elimina la dispersin del cdigo y las
implementaciones resultan ms comprensibles, adaptables y reusables. Varias tecnologas con
nombres diferentes se encaminan a la consecucin de los mismos objetivos y as, el trmino POA es
usado para referirse a varias tecnologas relacionadas como los mtodos adaptativos, los filtros de
composicin, la programacin orientada a sujetos o la separacin multidimensional de competencias.

SaaS
Software como un Servicio. abreviadamente ScuS (del ingls: Software as a Service, SaaS) es un
modelo de distribucin de software donde el soporte lgico y los datos que maneja se alojan en
servidores de una compaa de tecnologas de informacin y comunicacin (TIC), a los que se
accede va Internet desde un cliente. La empresa proveedora TIC se ocupa del servicio de
mantenimiento, de la operacin diaria y del soporte del software usado por el cliente. Regularmente el
software puede ser consultado en cualquier computador, se encuentre presente en la empresa o no.
Se deduce que la informacin, el procesamiento, los insumos, y los resultados de la lgica de
negocio del software, estn hospedados en la compaa de TIC.
El software es un producto que se puede distribuir de varias maneras. De forma clsica se hace
mediante una instalacin directa en equipos del cliente. Normalmente, si alguien quiere usar una
aplicacin de ventas, compra el CD-producto de instalacin, ejecuta un programa de configuracin, da
sus claves y, de este modo, puede comenzar a utilizar el sistema. Pero si el usuario necesita que otra
persona al extremo del globo terrqueo consulte su lista de clientes, o de cobros pendientes, o de
precios, y los quisiera manipular con el mismo software, necesitara otro CD-producto, o necesitara
bajar ese programa ejecutable de la web, y generalmente necesitara otra licencia para ese producto,
o hacer uso de una VPN, o comunicarse mediante correo electrnico con la sede de operaciones. En
cambio, si el software est modelado como servicio, los requerimientos pueden ser mucho ms
simples.

REST
en la actualidad se usa para describir cualquier interfaz entre sistemas que utilice
directamente HTTP para obtener datos o indicar la ejecucin de operaciones sobre los datos, en
cualquier formato (XML, JSON, etc) sin las abstracciones adicionales de los protocolos basados en
patrones de intercambio de mensajes, como por ejemplo SOAP. Es posible disear sistemas de
servicios web de acuerdo con el estilo arquitectural REST de Fielding y tambin es posible disear
interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto (RPC), pero sin
usar SOAP. Estos dos usos diferentes del trmino REST causan cierta confusin en las discusiones
tcnicas, aunque RPC no es un ejemplo de REST.
Los sistemas que siguen los principios REST se llaman con frecuencia RESTful.
REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseos
fundamentales clave:

Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la informacin necesaria
para comprender la peticin. Como resultado, ni el cliente ni el servidor necesitan recordar ningn
estado de las comunicaciones entre mensajes. Sin embargo, en la prctica, muchas aplicaciones
basadas en HTTP utilizan cookies y otros mecanismos para mantener el estado de la sesin (algunas
de estas prcticas, como la reescritura de URLs, no son permitidas por REST)
Un conjunto de operaciones bien definidas que se aplican a todos los recursos de informacin: HTTP
en s define un conjunto pequeo de operaciones, las ms importantes
son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a las
operaciones CRUD en bases de datos (ABMC en castellano: crear,leer,actualizar,borrar) que se
requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema.
Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es
direccionable nicamente a travs de su URI.
El uso de hipermedios, tanto para la informacin de la aplicacin como para las transiciones de
estado de la aplicacin: la representacin de este estado en un sistema REST
son tpicamente HTML o XML. Como resultado de esto, es posible navegar de un recurso REST a
muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura
adicional.
Qu es la genericidad?
La genericidad nos permite pasar uno o ms tipos genricos, como parmetro a un mtodo, clase,
estructura o interfaz. O sea, este nuevo tipo (que llamaremos <T>), viene a sustituir al tipo object, que
es usado sobre todo en estructuras de propsito general, como son los arraylist, pilas (stack), colas
(queue) y otras que usamos frecuentemente, en las cuales todos los elementos deben ser de un
mismo tipo.
El polimorfismo se refiere a la propiedad por la que es posible enviar mensajes sintcticamente
iguales a objetos de tipos distintos. El nico requisito que deben cumplir los objetos que se utilizan de
manera polimrfica es saber responder al mensaje que se les enva. El modo de poder utilizar objetos
de manera polimrfica sea que compartan una raz comn, es decir, una jerarqua de clases, ya que
esto proporciona la compatibilidad de tipos de datos. Algunos lenguajes permiten que dos objetos de
distintas jerarquas de clases respondan a los mismos mensajes, a travs de las interfaces

Encapsulamiento
Es el ocultamiento del estado, es decir, de los datos miembros de un objeto de manera que slo se
pueda cambiar mediante las operaciones definidas para ese objeto.
Cada objeto est aislado del exterior, es un mdulo natural, y la aplicacin entera se reduce a un
agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados de un objeto
contra su modificacin por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios
e interacciones.

Testing
Unitarios
Integracin
Regresin
Humo
Sistema
Desempeo
Carga

Estrs
Volumen
Recuperacin
Escalabilidad
Pruebas de
localizacin

Usabilidad
Seguridad
Rendimiento
Mantenibilidad
Portabilidad

Test de regresin: Test que prueban la integracin de varios componentes unitarios

integrados entre s.
Test de regresin: smoke test, es un testing rpido que se realiza sobre aspectos
funcionales no tanto para encontrar bugs sino para asegurarse que la funcionalidad bsica
del software o de una parte del software se encuentre estable y responda al comportamiento
esperado.
Test de sistema: aseguran
Caja Negra y caja blanca
Qu es un Fake?
El verbo "to fake" en ingls es fingir, falsificar. Eso es lo que es un Fake: una falsificacin de
un objeto.
Mocks y los Stubs, elementos que fingen o simulan ser otros objetos.
Estos terminos fueron introducidos por Gerard Meszaros en su libro XUnit Test Patterns,
donde estos y otros elementos ms son englobados como Test Doubles.
Segun Meszaros:
- Los Stubs proporcionan respuestas predefinidas a ciertas llamadas durante los tests, sin
responder a cualquier otra cosa para la que no hayan sido programados.
- Los Mocks son objetos preprogramados con expectativas que conforman la especificacin
de lo que se espera que reciban las llamadas.
Estos elementos son a menudo confundidos y se suele usar los mocks como stubs y
viceversa, ya que pueden parecer lo mismo, sin embargo, la diferencia entre los dos, es que
los mocks se utilizan para verificar el comportamiento de un elemento y los stubs para
verificar el estado.

Alpha Testing

Beta Testing

Alpha testing performed by Testers who are

usually internal employees of the organization

Beta testing is performed by Clients or

End Users who are not employees of the
organization

Alpha Testing performed at developer's site

Beta testing is performed at client

location or end user of the product

Reliability and security testing are not

performed in-depth Alpha Testing

Reliability, Security, Robustness are

checked during Beta Testing

Alpha testing involves both the white box and

black box techniques

Beta Testing typically uses black box

testing

Alpha testing requires lab environment or

testing environment

Beta testing doesn't require any lab

environment or testing environment.
Software is made available to the public
and is said to be real time environment

Long execution cycle may be required for

Alpha testing

Only few weeks of execution are required

for Beta testing

Critical issues or fixes can be addressed by

developers immediately in Alpha testing

Most of the issues or feedback is

collected from Beta testing will be
implemented in future versions of the
product

Alpha testing is to ensure the quality of the

product before moving to Beta testing

Beta testing also concentrates on quality

of the product, but gathers users input on
the product and ensures that the product
is ready for real time users.

BB DD Relacionales

mejor uso de una base de datos relacional est organizando grandes cantidades de datos .
Bases de datos relacionales utilizan varias tablas para definir tipos diferentes de datos , a
diferencia de otras bases de datos . Las relaciones entre los puntos de datos especficos en
las dos tablas se enlazan mediante la definicin de esa relacin . Adems, permite una visin
ms sistemtica y clara de los datos sin tener que repetir la informacin . Cmo funcionan
las bases de datos relacionales

La base de datos relacional toma la informacin con dos partes bien diferenciadas y la coloca
en dos mesas separadas . Por ejemplo , si los datos se organizan los contactos de un grupo
de estudiantes y las calificaciones del examen de ese mismo grupo , la informacin de los
estudiantes se puede clasificar en dos tablas diferentes . Los grados de la prueba entraran
en una y la informacin de contacto a otro . Los datos se vincula con un cdigo seguro de que
aparece en ambas tablas que aparecen en la informacin de la misma persona.
Ventajas de la base de datos

bases de datos relacionales relacionales permiten que los datos sean claros de corte y
despejada . Los problemas surgen cuando todos los datos en el ejemplo anterior slo estn
contenidos en una tabla , a diferencia de una base de datos relacional . Debido a que cada
estudiante tiene mltiples grados , su informacin de contacto se entr varias veces a lo largo
de cada grado. Esto es innecesario y puede crear confusin en la bsqueda de la base de
datos . Al contar con ellos por separado , como en una base de datos relacional , la
informacin de contacto slo es necesario introducir una vez.
Desventajas de la Base de Datos Relacional

El principal problema a la hora utilizando una base de datos relacional es la complejidad que
surge cuando se crea por primera vez. Es absolutamente vital que las relaciones definidas
entre las tablas son correctas y que cada conjunto de informacin est vinculada a su pareja.
Aunque menos informacin tiene que ser ingresado en total que con otras bases de datos ,
asegurndose de que cada punto est configurado correctamente es un proceso lento. Por
otra parte, las relaciones pueden llegar a ser extremadamente complicado cuando una base
de datos relacional contiene algo ms que dos tablas.
Cundo utilizar una base de datos relacional

No siempre es necesario el uso de una base de datos relacional. Se puede ahorrar tiempo
ms adelante al analizar los datos en busca de patrones o especficos, pero, posiblemente,
puede obstaculizar el progreso en el principio. La creacin de una nica tabla se proporciona
suficiente organizacin si los datos son simple o si las piezas de datos slo deben
introducirse una vez. Para continuar con el ejemplo anterior , si slo una calificacin de una
prueba es organizada junto con la informacin de contacto, slo se necesitar una tabla. Es
slo cuando ciertos valores - como la direccin o el nmero de telfono - se estn repitiendo
que una base de datos relacional es til