Ingeniería de Software II SOLID

Ingeniería de Software II (S.O.L.I.D.) es un acrónimo: Principios de diseño destinados a hacer que los diseños de software sean más comprensibles, flexibles, robusta y mantenibles. Principios de diseño destinados a hacer que los diseños de software sean más adaptables, comprensibles, flexibles y mantenibles. Principios de diseño destinados a hacer que los diseños de software sean más comprensibles, flexibles y mejora continua.

Ingeniería de Software II (S.O.L.I.D. - Ventajas) de las ventajas de aplicarlo son: 1. Facilitar el mantenimiento del código. 2. Reducir la complejidad de añadir nuevas funcionalidades. 3. Aumentar la reusabilidad de piezas y componentes. 4. Mejorar la calidad del código y su comprensión. 1. Facilitar el mantenimiento del código. 2. Reducir el costo de software 3. Aumentar la reusabilidad de piezas y componentes. 4. Siclo de vida comprensible. Ninguna.

Ingeniería de Software II (S.O.L.I.D.) Los cinco principios: Principio de responsabilidad único (SRP). Principio abierto - cerrado (OCP). Principio de sustitución de Liskov (LSP). Principios de segregación interfaz (ISP). Principios de inversión de dependencia (DIP). Todas las anteriores.

Principio de responsabilidad único (SRP). Establece que un módulo de software debe tener una y solo una razón para cambiar. Esta razón para cambiar es lo que se entiende por responsabilidad. El acoplamiento es el grado en que los módulos de un programa dependen unos de otros. La cohesión se refiere al grado en que los elementos de un módulo permanecen juntos.1​ Por lo tanto, la cohesión mide la fuerza de la relación entre las piezas de funcionalidad dentro de un módulo dado. Todas las anteriores.

Principio de responsabilidad único (SRP). Una clase debe tener solo una razón para cambiar. Un método debe tener solo una razón para cambiar. Una clase debe tener varias razones para cambiar.

Principio de responsabilidad único (SRP). Baja cohesión alto acoplamiento. Alta cohesión alto acoplamiento. Baja cohesión bajo acoplamiento. Alta cohesión ajo acoplamiento.

Open/closed (OCP)– Principio de abiertos y cerrados. Abierto para la extensión: esto significa que el comportamiento del módulo puede extenderse. A medida que cambian los requisitos de la aplicación, podemos ampliar el módulo con nuevos comportamientos que satisfagan esos cambios. En otras palabras, podemos cambiar lo que hace el módulo. Cerrado por modificación: un módulo estará cerrado si dispone de una descripción (interface) estable y bien definida. Extender el comportamiento de un módulo no debería afectar al código ya existente en el módulo, es decir, el código original del módulo no debería verse afectado y tener que modificarse. Todas las anteriores. Ninguna.

Open/closed (OCP)– Principio de abiertos y cerrados. 1. Las clases deben estar abiertas a la extensión, a las modificaciones que pueden ocurrir cuando plantean nuevos requerimientos 2. Las clases deben estar cerradas a la modificación. No se puede cambiar el código fuente de una clase. 1. Las clases deben estar cerradas a la extensión, a las modificaciones que pueden ocurrir cuando plantean nuevos requerimientos 2. Las clases deben estar abiertas a la modificación. No se puede cambiar el código fuente de una clase. Ninguna.

Principio de substitución de Liskov -(LSP). La sustitución de Liskov nos dice que los objetos de un programa deberían ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del programa. Si en alguna parte de nuestro código estamos usando una clase, y esta clase es extendida, tenemos que poder utilizar cualquiera de las clases hijas y que el programa siga siendo válido. Esto nos obliga a asegurarnos de que cuando extendemos una clase no estamos alterando el comportamiento de la clase padre. Todas las anteriores.

Principio de substitución de Liskov, una clase que hereda de otra debe poder usar como su padre sin necesidad de conocer las diferencias entre ellas. Este principio nos ayuda a utilizar correctamente la herencia ya que los objetos de nuestra subclase se debe comportar de igual manera que los de la superclase. Las precondiciones no pueden ser mas restrictivas en un subtipo. Las postcondiciones no puede ser manos restrictivas en un subtipo. Las variantes establecidas por el superior deben ser mantenidas por los subtipos.

Interface segregation (ISP) - Principio de interfaz de segregación: El principio de segregación de interfaces establece que muchas interfaces cliente específicas son mejores que una interfaz de propósito general. Esto se consigue separando las interfaces en otras más pequeñas y específicas. Todas las anteriores.

Interface segregation (ISP) - Principio de interfaz de segregación. Seleccione mas de uno. Cuando creamos interfaz debemos estar segurios de que la clase que va implementar va a poder implementar todas las clases. Por lo general siempre será preferible muchas interfaces pequeñas a una gran interfaz con muchos métodos. El principio de segregación de interfaces defiende que ninguna clase debería depender de métodos que no usa. Por lo general siempre será preferible una interfaz pequeña a una gran interfaz con un solo método.

Dependency inversion (DIP)- Principio de inversión de dependencia nos dice: seleccione mas de uno. Que las entidades de software deben depender de abstracciones, no de implementaciones. A su vez, los módulos de alto nivel no deberían depender de los de bajo nivel. Ambos deberían depender de abstracciones. Lo que se pretende es que no existan dependencias directas entre módulos. Los módulos pueden ser más fácilmente reutilizables. Es fundamental que la abstracción se defina en base a las necesidades del módulo o cliente y no en las capacidades de la implementación, de lo contrario, la abstracción estaría bastante acoplada a la implementación teniendo así menos flexibilidad. Ninguno.

Dependency inversion (DIP)- Principio de inversión de dependencia Ventajas: seleccione mas de uno. Mayor flexibilidad haciendo testing. Reduce el acoplamiento. Código limpio, legible y mantenible. Posibilidad de elegir en tiempos de ejecución la implantación adecuada. Fuerte acoplamiento.

Unir según corresponda. Hace el código más mantenible. Evitar la repetición de lógica permite que si alguna vez cambia la funcionalidad en cuestión, no lo tengas que hacer en todos los lugares en los que lo repetiste. Reduce el tamaño del código. Esto lo hace más legible y entendible porque hay menos código. Ahorra tiempo. Al tener pedazos de lógica disponibles para reutilizarlos, en el futuro, estamos más preparados para lograr lo mismo en menos tiempo. Divide el problema en muchos pequeños problemas. Cada problema debe poder resolverse en una o muy pocas clases. Mantener los métodos pequeños, donde cada método nunca debe tener más de 30-40 líneas. Cada método sólo debería resolver un pequeño problema, no muchos casos de uso. Si tiene muchas condiciones en su método, dividirlas en métodos más pequeños. • Los dos puntos anteriores deben mantenerse tan simple como sea posible mientras codificas. No se deben agregar funcionalidades extras hasta que no sea necesario. No tratar de implementar cosas porque tú crees que a lo mejor van a suceder, o que la aplicación va a necesitar.