CLASES - PRINCIPIO S.O.L.I.D PARA EL DISEÑO.

Las clases son los componentes básicos de la aplicación Java. Si estos bloques no son fuertes, su edificio (es decir, la aplicación) se va a enfrentar los momentos difíciles en el futuro. En esencia, esto significa que no es tan bien escrito puede llevar a situaciones muy difíciles en el ámbito de aplicación sube o aplicación se enfrenta a ciertos problemas de diseño, ya sea en la producción o mantenimiento.

Por otro lado, un conjunto de clases bien diseñadas y escritas pueden acelerar el proceso de codificación a pasos agigantados, al tiempo que reduce el número de errores en comparación.

En este post, voy a enumerar abajo de 5 principios de diseño más recomendados, usted debe tener en cuenta, al escribir sus clases. Estos principios de diseño se denominan S.O.L.I.D. También forman las mejores prácticas a seguir para el diseño de clases.

1. Single Responsibility Principle
2. Open Closed Principle
3. Liskov’s Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

Principio de Responsabilidad Individual

El nombre del principio lo dice todo:

"Una clase debe tener una y sólo una responsabilidad"

En otras palabras, usted debe escribir, cambiar y mantener una clase para un solo propósito. Si se trata de la clase del modelo, entonces debe representar estrictamente solo actor / entidad. Esto le dará la flexibilidad para hacer cambios en el futuro sin tener que preocuparse de los impactos de los cambios de otra entidad.

Del mismo modo, si usted está escribiendo clase de servicio / administrador, entonces debe contener sólo la parte de las llamadas a métodos y nada más. Ni siquiera las funciones globales de servicios públicos relacionados con el módulo.Mejor separarlos en otro archivo de clase globalmente accesible. Esto le ayudará en el mantenimiento de la clase especialmente con ese fin, y usted puede decidir la visibilidad de clase a sólo módulo específico.

Abrir Principio Cerrado

Esta es la segunda regla importante que usted debe tener en cuenta al diseñar su aplicación. Dice:

"Los componentes de software deben estar abiertas para la extensión, pero cerrado para la modificación"

¿Qué quiere decir? Esto significa que las clases deben ser diseñados de tal manera que cada vez que compañeros desarrolladores quiere cambiar el flujo de control en las condiciones específicas de aplicación, todo lo que necesitan para ampliar su clase y reemplazar algunas funciones y eso es todo.

Si otros desarrolladores no son capaces de diseñar el comportamiento deseado debido a las limitaciones planteadas por la clase, entonces debería reconsiderar el cambio de su clase. No quiero decir aquí que cualquiera puede cambiar toda la lógica de la clase, pero él / ella debería ser capaz de anular las opciones proporcionadas por el software en modo inocuo permitida por software.

Por ejemplo, si usted echa un vistazo a cualquier buen marco como arriostramientos y primavera, verá que usted puede cambiar su lógica de la base y el procesamiento de la solicitud, pero modificar el flujo de la aplicación deseada con sólo extender algunas clases y plugins en archivos de configuración.

De Liskov Principio de Sustitución

Este principio es una variación del principio discutido previamente cerrado abierto. Dice:

"Los tipos derivados deben ser completamente sustituibles por sus tipos base"

Esto significa que el compañero de clases desarrollador creado por la ampliación de su clase debe ser capaz de encajar en la aplicación sin fracaso. Es decir, si un compañero desarrollador mal extendido alguna 
parte de su clase y se inyecta en el marco / aplicación, entonces no debería romper la aplicación o no debería producir excepciones fatales.

Esto se puede asegurar mediante el uso estrictamente siguiendo primera regla. Si su clase base está haciendo una cosa en sentido estricto, el becario desarrollador anulará sólo una característica de forma incorrecta en el peor caso. Esto puede causar algunos errores en un área, pero la aplicación no va a hacer todo hacia abajo.

Interfaz Principio Segregación

Este principio es mi favorito. Es aplicable a las interfaces como principio de responsabilidad única mantiene a las clases.Dice:

"Los clientes no deben ser forzados a implementar métodos innecesarios que no van a utilizar"

Tomemos un ejemplo. Desarrollador Alex creó una interfaz “denunciable” y ha añadido dos métodos generateExcel () y generatedPdf (). Ahora el cliente “A” quiere utilizar esta interfaz, pero él tiene la intención de utilizar los informes sólo en formato PDF y no en excel. ¿Va a conseguir la funcionalidad fácilmente.

NO. Él tendrá que implementar dos métodos, de los cuales uno es carga adicional puesto en él por el diseñador de software. Porque o implementar otro método o dejarlo en blanco. Así que no son casos deseado, ¿verdad??

Entonces, ¿cuál es la solución? La solución es crear dos interfaces al romper la ya existente. Deben ser como PdfReportable y ExcelReportable. Esto le dará la flexibilidad para el usuario de utilizar únicamente sólo la funcionalidad requerida.

Dependencia Principio Inversion

La mayoría de nosotros ya estamos familiarizados con las palabras que se utilizan en el nombre de principio. Dice:

"Dependerá de las abstracciones, no en concreciones"

En otras palabras. debe diseñar su software de tal manera que los diferentes módulos se pueden separar entre sí mediante una capa de abstracción para atarlos juntos. El uso clásico de este principio de BeanFactory en Spring Framework . En el marco de la primavera, todos los módulos se suministran como componentes independientes que pueden trabajar juntos por dependencias simplemente inyectados en otro módulo. Están tan bien cerrados en sus fronteras que se pueden utilizar en otros módulos de software, aparte de la primavera con la misma facilidad.

Esto se ha logrado por la inversión de dependencia y abrir principios cerrados. Todos los módulos exponen sólo abstracción que es útil en la ampliación de la funcionalidad o complemento en otro módulo.

Estas fueron cinco principio de diseño de clase que hace que las mejores prácticas que deben seguirse para diseñar sus clases de la aplicación. Déjame saber de tus pensamientos.