Los paradigmas de programación son la forma, que determinan los métodos y las herramientas que un programador usara en la construcción de un software.
Mayormente los lenguajes de programación están basados en uno o más paradigmas, ha estos se les puede llamar multiparadigmas.
También menciona los diferentes tipos de paradigmas que se conocen, pero solamente se hace referencia a los mas importante ya que suelen haber muchos más que no se mencionaran en esta investigación.
Los paradigmas de programación son la forma, que determinan los métodos y las herramientas que un programador usara en la construcción de un software.
Mayormente los lenguajes de programación están basados en uno o más paradigmas, ha estos se les puede llamar multiparadigmas.
También menciona los diferentes tipos de paradigmas que se conocen, pero solamente se hace referencia a los mas importante ya que suelen haber muchos más que no se mencionaran en esta investigación.
Samuel Martín, Consultor Tecnológico de Autentia habla sobre el principio abierto/cerrado (open/closed principle), dentro de los workshops de Patrones de Diseño de Autentia.
Introducción al análisis estático de código en java para mejorar la calidad del software tomando como referencia mejores prácticas, estándares y optimización de código.
¿Cómo aplicar los principios SOLID a mi código?
Definición de los principios y ejemplos clásicos de buenas prácticas de Diseño Orientado a Objetos
Audio de la presentación:
http://archive.org/details/10.S.o.l.i.d.ComoLoAplicoEnMiCdigo-JuanJosFuchs
Samuel Martín, Consultor Tecnológico de Autentia habla sobre el principio abierto/cerrado (open/closed principle), dentro de los workshops de Patrones de Diseño de Autentia.
Introducción al análisis estático de código en java para mejorar la calidad del software tomando como referencia mejores prácticas, estándares y optimización de código.
¿Cómo aplicar los principios SOLID a mi código?
Definición de los principios y ejemplos clásicos de buenas prácticas de Diseño Orientado a Objetos
Audio de la presentación:
http://archive.org/details/10.S.o.l.i.d.ComoLoAplicoEnMiCdigo-JuanJosFuchs
Conjunto de principios, no son reglas, aplicados al diseño orientado a objetos. SOLID no es un framework, ni una tecnología, tampoco una librería y mucho menos una metodología. Su propósito es generar código fácil de entender y mantener. Representa cinco principios básicos de la programación orientada a objetos y el diseño.
Evolución Android: Del Framework a la supervivencia del más fuerteRubén Serrano Núñez
El software, como las especies, tiene que evolucionar para no extinguirse. Desarrollar para Android puede ser muy rápido una vez conoces el framework, pero a la larga, los mismos componentes que te permiten ir rápido al principo, pueden suponer el peor obstáculo para hacer crecer una aplicación. En esta charla veremos algunos de estos compenentes, cuáles son sus ventajas, cuáles son sus problemas más adelante, y algunas estrategias que podemos seguir para evitar que nuestro proyecto muera.
Las lámparas de alta intensidad de descarga o lámparas de descarga de alta in...espinozaernesto427
Las lámparas de alta intensidad de descarga o lámparas de descarga de alta intensidad son un tipo de lámpara eléctrica de descarga de gas que produce luz por medio de un arco eléctrico entre electrodos de tungsteno alojados dentro de un tubo de alúmina o cuarzo moldeado translúcido o transparente.
lámparas más eficientes del mercado, debido a su menor consumo y por la cantidad de luz que emiten. Adquieren una vida útil de hasta 50.000 horas y no generan calor alguna. Si quieres cambiar la iluminación de tu hogar para hacerla mucho más eficiente, ¡esta es tu mejor opción!
Las nuevas lámparas de descarga de alta intensidad producen más luz visible por unidad de energía eléctrica consumida que las lámparas fluorescentes e incandescentes, ya que una mayor proporción de su radiación es luz visible, en contraste con la infrarroja. Sin embargo, la salida de lúmenes de la iluminación HID puede deteriorarse hasta en un 70% durante 10,000 horas de funcionamiento.
Muchos vehículos modernos usan bombillas HID para los principales sistemas de iluminación, aunque algunas aplicaciones ahora están pasando de bombillas HID a tecnología LED y láser.1 Modelos de lámparas van desde las típicas lámparas de 35 a 100 W de los autos, a las de más de 15 kW que se utilizan en los proyectores de cines IMAX.
Esta tecnología HID no es nueva y fue demostrada por primera vez por Francis Hauksbee en 1705. Lámpara de Nernst.
Lámpara incandescente.
Lámpara de descarga. Lámpara fluorescente. Lámpara fluorescente compacta. Lámpara de haluro metálico. Lámpara de vapor de sodio. Lámpara de vapor de mercurio. Lámpara de neón. Lámpara de deuterio. Lámpara xenón.
Lámpara LED.
Lámpara de plasma.
Flash (fotografía) Las lámparas de descarga de alta intensidad (HID) son un tipo de lámparas de descarga de gas muy utilizadas en la industria de la iluminación. Estas lámparas producen luz creando un arco eléctrico entre dos electrodos a través de un gas ionizado. Las lámparas HID son conocidas por su gran eficacia a la hora de convertir la electricidad en luz y por su larga vida útil.
A diferencia de las luces fluorescentes, que necesitan un recubrimiento de fósforo para emitir luz visible, las lámparas HID no necesitan ningún recubrimiento en el interior de sus tubos. El propio arco eléctrico emite luz visible. Sin embargo, algunas lámparas de halogenuros metálicos y muchas lámparas de vapor de mercurio tienen un recubrimiento de fósforo en el interior de la bombilla para mejorar el espectro luminoso y reproducción cromática. Las lámparas HID están disponibles en varias potencias, que van desde los 25 vatios de las lámparas de halogenuros metálicos autobalastradas y los 35 vatios de las lámparas de vapor de sodio de alta intensidad hasta los 1.000 vatios de las lámparas de vapor de mercurio y vapor de sodio de alta intensidad, e incluso hasta los 1.500 vatios de las lámparas de halogenuros metálicos.
Las lámparas HID requieren un equipo de control especial llamado balasto para funcionar
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
En este documento analizamos ciertos conceptos relacionados con la ficha 1 y 2. Y concluimos, dando el porque es importante desarrollar nuestras habilidades de pensamiento.
Sara Sofia Bedoya Montezuma.
9-1.
4. Síntomas de un mal diseño
• Rigidez.
• Fragilidad.
• Inmovilidad.
• Viscosidad.
• Complejidad innecesaria.
• Repetición innecesaria.
• Opacidad.
5. ¿Qué es SOLID?
• Acrónimo mnemónico.
• Introducido por Robert C. Martin a comienzos
de la década del 2000.
• Son cinco principios básicos de la
programación orientada a objetos y el diseño.
• Ayudan a desarrollar un software de
calidad, legible, entendible y fácilmente
testeable.
7. Principios SOLID
SRP: Principio de Responsabilidad Única.
OCP: Principio Abierto-Cerrado.
LSP: Principio de Substitución de Liskov.
ISP: Principio de Segregación de Interfaces.
DSI: Principio Inversión de Dependencia.
8. Responsabilidad única
“Una clase debería tener una, y solo una
razón para cambiar”
Robert C. Martin
Principles of Object Oriented Design
9. Responsabilidad única
• Clase con 2 o más responsabilidades:
– Responsabilidades acopladas.
• + responsabilidades, + probabilidades de cambio!
• Síntomas:
– Código spaghetti.
– "God Class“.
– Comentarios: “si”; “y”; ”pero”; “excepto”; “cuando”.
• Ventajas:
– Es más fácil re-utilizar partes del código.
– Las clases grandes son más difíciles de leer y cambiar.
– Solucionamos el dilema del nombre de la clase.
12. Abierto-Cerrado
“Todo módulo debe estar abierto para la
extensión pero, cerrado para modificación”
Bertrand Meyer
Object Oriented Software Construction
13. Abierto-Cerrado
• Los cambios deben generar código nuevo,
no modificar el código viejo.
• La clave está en la abstracción!
• Strategy and Template method son las formas
más comunes de satisfacer OCP.
• Ningún diseño se puede cerrar a TODOS los
cambios.
16. Substitución de Liskov
“Si para todo objeto o1 de tipo S existe un objeto
o2 de tipo T tal que para todo programa P
definido en función de T el comportamiento de
P no cambia cuando o1 es substituido por
o2, entonces S es un subtipo de T”
Barbara J. Liskov
Keynote – Data abstraction and hierarchy (1987)
17. Substitución de Liskov
Traduciendo…
“Las funciones que usan punteros o referencias
a clases base, deben ser capaces de usar
objetos de clases derivadas sin saberlo”
Robert C. Martin
18. Substitución de Liskov
• Es la base de poder del polimorfismo.
• Los subtipos deben ser substituibles por sus
tipos base.
• No podemos validar un modelo aisladamente.
– La validez depende del contexto (sus clientes).
• La violación de LSP es una violación latente de
OCP
20. Substitución de Liskov
• Un cuadrado puede ser un rectángulo….
– Pero el objeto cuadrado NO es un objeto rectángulo.
– El comportamiento no es igual!
21. Substitución de Liskov
• Diseñar basándose en comportamientos
• Pensar en “Sustituible por” y no en “Es un”-
• Diseño por contrato:
– Las pre-condiciones de los métodos de la sub-
clase no deben ser más fuertes que las de la clase
base.
– Las post-condiciones de los métodos de la sub-
clase no deben ser más débiles que las de la clase
base.
24. Segregación de Interfaces
“Los clientes no deben de ser forzados a
depender de interfaces que no utilizan.”
Robert C. Martin
25. Segregación de Interfaces
• Apunta a evitar las interfaces “gordas”.
• Les falta cohesión.
• No importa la cantidad de métodos, sino que
todos sus clientes las utilicen.
• Síntoma: “Unimplemented method”.
• Inadvertidamente podemos acoplar clientes
que usan ciertos métodos con otros clientes
que no los usan.
28. Inversión de dependencia
A) “Los módulos de alto nivel no deben de
depender de módulos de bajo nivel. Ambos
deben depender de abstracciones.”
B) “Las abstracciones no deben depender de
detalles. Los detalles deben depender de
abstracciones.”
29. Inversión de dependencia
• ¿ Por qué depender de una abstracción?
– El objeto cliente se desacopla de la
implementación.
– Podemos intercambiar la implementación (OCP!!)
• Problemas dependencias directas:
– ¡Las dependencias son transitivas!
• Ventajas dependencias indirectas:
– Desacoplamiento.
– Aislamiento.
– Reusabilidad.
32. SOLID - Comentarios Finales
• Definen lineamientos, no son reglas estrictas.
• Hay que comprender su motivación y aplicarlos
con criterio.
• No crear complejidad innecesaria!
• No es posible escribir código perfecto…
– TAMPOCO ES NECESARIO!
• No gastar recursos donde no es necesario.
• Con TDD, podemos refactorizar después!
33. SOLID - Comentarios Finales
“El elemento más volátil en los proyectos software
son los requisitos. Vivimos en un mundo de
requisitos cambiantes, y nuestro trabajo es estar
seguros de que nuestros software puede sobrevivir
a esos cambios, así que no culpes a los requisitos
cambiantes por los fallos en el software.”
Robert C. Martin