GUIA FINALFANTASY XV - ESPAÑOL, (SPANISH)

En esta entrada de DatoByte les comparto la URL de otro Blog quien compartio la guia completa de Final Fantasy XV, Esta vez en ESPAÑOL.

Sin mas que decir les comparto la URL de MEGAUPLOAD
LINK: Guia Español - No oficial

Cabe aclarar que esta guia no es la oficial, hasta el momento solo he conseguido la oficial en su version Ingles:  Guia Ingles

Guia Final Fantasy XV [English] - Proximamente Español

En esta entrada de DatoByte les comparto la URL de otro Blog quien compartio la guia oficial completa de Final Fantasy XV, por desgracia en Ingles, aun asi es de mucho interes tener a la mano esta Guia, el link de descarga lo encontraran al interior de la publicacion del otro blog.


https://nicoblog.org/strategy-guide/final-fantasy-xv-the-complete-official-guide-1-02-crown-update/

Publisher: Piggyback
Language: English
Pages in book: 320
PDF: 324 pages
Platform: PS4/One
Link: https://drive.google.com/open?id=0B3BDEuPtnYXMVFNQY2FxWnpHSlU

Tabla comparativa de patrones de desarrollo de software

En esta entrada de DatoByte les quiero compartir una tabla comparativa de desarrollo de software que he realizado uniendo la información de varios libros Incluyendo el famoso libro de "Gang of Four Design Patterns", en esta tabla encontraras informacion adicional incluyendo un conjunto de ejemplos en Java y .NET que te pueden brindar una mayor comprensión.

En el siguiente link les comparto el archivo para su descarga.

Tabla Comparativa

Recuerda compartir, comentar y dar +1 en la publicacion.

Bibliografia

"Gang of Four Design Patterns"

8 Causas comunes del rediseño de software

En esta entrada de DatoByte les quiero hablar acerca de una situación con la cual frecuentemente las personas involucradas en el desarrollo de software, específicamente en la etapa del desarrollo, pero con raíces en el análisis, ya que en ocasiones en las etapas iniciales no se visualiza el tamaño del software a construir y a medida que el tiempo llegan a surgir nuevas solicitudes en los requisitos , lo cual directamente conlleva un impacto en el desarrollo, por consiguiente nos lleva a rediseñar diversos objetos y/o componentes que ya se encuentran funcionando y posiblemente en un estado de producción. por ello voy a mencionar 8 causas comunes del rediseño de software que evidencian el uso de algunos patrones de desarrollo de software.

Tal vez te pueda interesar Tabla comparativa de patrones de desarrollo de software

1. Crear un objeto especificando su clase explicitamente.

Especificar el nombre de la clase al crear un objeto nos liga a una implementacion concreta en vez de a una interfaz. Esto puede complicar los cambios a futuro.

¿Como Evitarlo?
Crear los objetos indirectamente

Patrones de software que facilitan su solución
Abstract Factory, Factory Method, Prototype


2. Dependencia de operaciones concretas

Cuando especificamos una determinada operación estamos ligando a una forma de satisfacer una petición

¿Como Evitarlo?
Evitando ligar las peticiones al codigo, hacemos mas facil cambiar el modo de satisfacer una peticion, tanto en tiempo de compilacion como en tiempo de ejecucion

Patrones de software que facilitan su solución
Chain of responsability, Command


3. Dependencias de plataformas hardware o software

Las interfaces externas de los sistemas operativos y las interfaces de programación de aplicaciones(API) Varían para las diferentes plataformas hardware y software

¿Como Evitarlo?
El software que depende de una plataforma concreta sera mas dificil de portar a otras plataformas. Incluso puede resultar dificil mantenerlo actualizado en su plataforma Nativa. Por lo tanto es importante diseñar nuestros sistemas de manera que se limiten sus dependencias de plataforma

Patrones de software que facilitan su solución
Abstract Factory, Bridge


4. Dependencias de las representaciones o implementaciones de objetos

Los clientes de un objeto que saben como se representa, se almacena, se localiza o implementa, quizá deban ser modificados cuando cambie dicho objeto

¿Como Evitarlo?
Ocultar esta informacion a los clientes previene los cambios en cascada

Patrones de software que facilitan su solución
Abstract Factory, Bridge, Memento, Proxy


5. Dependencias algorítmicas

Muchas veces los algoritmos se amplían, optimizan o sustituyen por otros durante el desarrollo y posterior reutilización.

¿Como Evitarlo?
Los objetos que dependen de un algoritmo tendran que cambiar cuando este cambie. Por tanto, aquellos algoritmos que es probable que cambien deberian estar aislados.

Patrones de software que facilitan su solución
Builder, Iterator, Strategy, Template Method, Visitor


6. Fuerte acoplamiento

Las clases que están fuertemente acopladas son difíciles de reutilizar por separado, puesto que dependen unas de otras. El fuerte acoplamiento lleva a sistemas Monolíticos, en los que no se puede cambiar o quitar una clase sin entender y cambiar muchas otras. El sistema se convierte en algo muy denso que resulta difícil aprender, portar y mantener.

¿Como Evitarlo?
El bajo acoplamiento aumenta la probabilidad de que una clase pueda ser reutilizada ella sola y de que un sistemapueda aprenderse, portarse, modificarse y extenderse mas facilmente. Los patrones de diseño hacen uso de tecnicas coo acoplamiento abctracto y la estructuracion en capas para promover sistemas escasamente acoplados

Patrones de software que facilitan su solución
Abstract Factory, Bridge, Chain of responsability, command, Facade, Mediator, Observer


7. Añadir funcionalidad mediante la herencia

Particularizar un objeto derivando de otra clase suele ser fácil. Cada nueva clase tiene coste de implementacion. Definir una subclase también requiere un profundo conocimiento de la clase padre. Por ejemplo redefinir una operación puede requerir redefinir otra, o tener que llamar a una operación Heredada. Ademas la herencia puede conducir a una explosión de clases, ya que una simple extensión puede obligar a introducir un montón de clases nuevas.

¿Como Evitarlo?
La composicion de objetos en general y la delegacion en particular proporciona alternativas flexibles a la herencia para combinar comportamiento. Se puede añadir nueva funcionalidad de una aplicación componiendo los objetos existentesde otra forma en vez de definir subclases nuevas de otras clases existentes. No obstante tambien es cierto que un uso intensivo de la composicion de objetos puede hacer que los diseños sean mas dificiles de entender. muchos patrones de diseño `rpducen diseños en los que se pueden introducir nueva funcionalidad simplemente definiendo una subclasey componiendo sus instancias con otras existentes

Patrones de software que facilitan su solución
Bridge, Chain of responsability, Composite Decorator, Observer, Strategy


8. Incapacidad para modificar las clases convenientemente.

Aveces hay que modificar una clase que no puede ser modificada convenientemente. Quizas necesitemos el código fuente y no lo tengamos (Como puede ser el caso de una biblioteca de clase comercial)O tal vez cualquier cambio requeriría modificar muchas de las subclases existentes

¿Como Evitarlo?
Los patrones de diseño ofrecen formas de modificar las clases en tales circunstancias.

Patrones de software que facilitan su solución
Adapter, Decorator, visitor

Si esta entrada te ha parecido de interés recuerda comentar y/o compartir con tus amigos.