Escritura de código, que es fácil de cambiar es el Santo Grial de la programación. Bienvenido al nirvana de programación! Pero las cosas son mucho más difíciles en la realidad: el código fuente es difícil de entender, punto dependencias en direcciones innumerables acoplamiento es molesto, y pronto siente el calor del infierno programación. En este tutorial, vamos a discutir algunos principios, técnicas e ideas que le ayudarán a escribir código que sea fácil de cambiar.
Algunos Conceptos de Orientación a Objetos
Programación orientada a objetos (POO) se hizo popular debido a su promesa de organización del código y reutilización, es absolutamente fracasado en este empeño. Hemos estado utilizando los conceptos de programación orientada a objetos desde hace muchos años, y aún así seguir aplicando repetidamente la misma lógica en nuestros proyectos. OOP introdujo una serie de buenos principios básicos que, si se utilizan adecuadamente, puede conducir a una mejor, código más limpio.
Cohesión
Las cosas que van de la mano debe mantenerse juntos, de lo contrario, deberían ser trasladado a otro lugar. Esto es lo que el término, la cohesión, se refiere. El mejor ejemplo de cohesión se puede demostrar con una clase:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| clase ANOTCohesiveClass { privado $ primerNumero ; privado $ secondNumber ; privado $ length ; privado $ width ; función __construct ( $ primerNumero , $ secondNumber ) { $ This - primerNumero> = $ primerNumero ; $ This -> secondNumber = $ secondNumber ; } función setLength ( $ longitud ) { $ This - Longitud> = $ longitud ; } función setHeight ( $ height ) { $ This -> width = $ height ; } función add () { devolver $ this -> primerNumero + $ this -> secondNumber; } función de resta () { devolver $ this - primerNumero> - $ this - secondNumber>; } función area () { devolver $ this -> longitud * $ this -> ancho; }} |
En este ejemplo se define una clase con campos que representan los números y tamaños. Estas propiedades, a juzgar sólo por sus nombres, no van de la mano. Entonces tenemos dos métodos,
add () yresta () , que operan sólo en las dos variables numéricas. Nos tienen además un área () método, que opera en la longitud y anchura de los campos.
Es obvio que esta clase es responsable de separar los grupos de información. Dispone de cohesión muy bajo . Vamos a refactorizar.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| clase ACohesiveClass { privado $ primerNumero ; privado $ secondNumber ; función __construct ( $ primerNumero , $ secondNumber ) { $ This - primerNumero> = $ primerNumero ; $ This -> secondNumber = $ secondNumber ; } función add () { devolver $ this -> primerNumero + $ this -> secondNumber; } función de resta () { devolver $ this - primerNumero> - $ this - secondNumber>; }} |
Esta es una clase altamente cohesivo . ¿Por qué? Debido a que cada sección de esta clase pertenece uno con el otro. Usted debe esforzarse para la cohesión, pero ten cuidado, que puede ser difícil de lograr.
Ortogonalidad
En términos simples, la ortogonalidad se refiere al aislamiento o eliminación de los efectos secundarios. Un método, de clase o módulo que cambia el estado de otras clases no relacionadas o módulos no es ortogonal. Por ejemplo, el cuadro negro de un avión es ortogonal. Tiene su funcionalidad interior, fuente de alimentación interna, micrófonos y sensores. No tiene ningún efecto sobre el avión en el que reside, o en el mundo exterior. Sólo se proporciona un mecanismo para grabar y recuperar datos de vuelo.
Un ejemplo de tal sistema no ortogonal es la electrónica de su coche. Para incrementar la velocidad de su vehículo tiene varios efectos secundarios, como aumento de volumen de la radio (entre otras cosas). La velocidad no es ortogonal al coche.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| clase Calculadora { privado $ primerNumero ; privado $ secondNumber ; función __construct ( $ primerNumero , $ secondNumber ) { $ This - primerNumero> = $ primerNumero ; $ This -> secondNumber = $ secondNumber ; } función add () { $ Suma = $ this -> primerNumero + $ this -> secondNumber; si ( $ suma > 100) { ( nuevo AlertMechanism ()) - tooBigNumber> ( $ cantidad ); } volver suma $ ; } función de resta () { devolver $ this - primerNumero> - $ this - secondNumber>; }}clase AlertMechanism { función tooBigNumber ( $ numero ) { echo $ numero . 'es demasiado grande!' ; }} |
En este ejemplo, la
calculadora clase de add () método muestra un comportamiento inesperado: se crea un AlertMechanism objeto y llama a uno de sus métodos. Este es un comportamiento inesperado y no deseado, los consumidores de la biblioteca nunca esperará un mensaje impreso en la pantalla. En cambio, sólo esperan que la suma de los números proporcionados.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| clase Calculadora { privado $ primerNumero ; privado $ secondNumber ; función __construct ( $ primerNumero , $ secondNumber ) { $ This - primerNumero> = $ primerNumero ; $ This -> secondNumber = $ secondNumber ; } función add () { devolver $ this -> primerNumero + $ this -> secondNumber; } función de resta () { devolver $ this - primerNumero> - $ this - secondNumber>; }}clase AlertMechanism { función checkLimits ( $ primerNumero , $ secondNumber ) { $ Suma = ( nueva Calculadora ( $ primerNumero , $ secondNumber )) -> add (); si ( $ suma > 100) { $ This -> tooBigNumber ( $ cantidad ); } } función tooBigNumber ( $ numero ) { echo $ numero . 'es demasiado grande!' ; }} |
Esto es mejor.
AlertMechanism no tiene efecto en Calculadora . En su lugar, AlertMechanism usa lo que necesita con el fin de determinar si una alerta debe ser emitido.Dependencia y acoplamiento
En la mayoría de los casos, estas dos palabras son intercambiables, pero, en algunos casos, un término se prefiere sobre otro.
Entonces, ¿qué es una dependencia ? Cuando el objeto
A necesita usar objeto B , con el fin de realizar su comportamiento prescrito, se dice que A depende de B . En OOP, las dependencias son muy comunes.Objetos con frecuencia trabajan con y dependen unos de otros. Así, mientras que la eliminación de la dependencia es una actividad noble, es casi imposible hacerlo. El control de las dependencias y la reducción de ellos es, sin embargo, preferible.Los términos, pesado acoplamiento- y -suelta de acoplamiento , por lo general se refieren a la cantidad de un objeto depende de otros objetos.
En un sistema de acoplamiento flexible, los cambios en un objeto tienen un efecto reducido sobre los otros objetos que dependen de él. En tales sistemas, las clases depende de interfaces en lugar de implementaciones concretas (hablaremos más sobre esto más adelante). Por ello, los sistemas débilmente acoplados son más abiertos a modificaciones.
Acoplamiento en un campo
Veamos un ejemplo:
1
2
3
4
5
6
| clase Display { privado $ calculadora ; función __construct () { $ This -> calculadora = nueva Calculadora (1,2); }} |
Es común ver este tipo de código. Una clase,
la pantalla en este caso, depende de la calculadora declase por referencia directa a esa clase. En el código anterior, Display 's $ calculadora campo es de tipo calculadora . El objeto que contiene el campo es un resultado de llamar directamente Calculadoraconstructor 's.Acoplamiento mediante el acceso a los métodos de la clase
Revise el código siguiente para una demostración de este tipo de acoplamiento:
1
2
3
4
5
6
7
8
9
| clase Display { privado $ calculadora ; función __construct () { $ This -> calculadora = nueva Calculadora (1, 2); } función printSum () { echo $ this -> Simulador-> add (); }} |
La
visualización de la clase llama la Calculadora objeto add () método. Esta es otra forma de acoplamiento, ya que una clase accede a la del otro método.Acoplamiento de Referencia de los métodos
Puedes par de clases con referencias a métodos, también. Por ejemplo:
1
2
3
4
5
6
7
8
9
10
11
12
| clase Display { privado $ calculadora ; función __construct () { $ This -> calculadora = $ this -> makeCalculator (); } función printSum () { echo $ this -> Simulador-> add (); } función makeCalculator () { volver nueva Calculadora (1, 2); }} |
Es importante señalar que la
makeCalculator () método devuelve una calculadora objeto. Esta es una dependencia.Acoplamiento de polimorfismo
La herencia es probablemente la forma más fuerte de dependencia:
1
2
3
4
5
| clase AdvancedCalculator extiende Calculadora { función sinusal ( $ valor ) { volver pecado ( $ valor ); }} |
No sólo puede
AdvancedCalculator no hacer su trabajo sin calculadora , sino que ni siquiera podría existir sin ella.Acoplamiento reductor de Inyección de Dependencia
Se puede reducir el acoplamiento mediante la inyección de una dependencia. He aquí un ejemplo de ello:
1
2
3
4
5
6
7
| clase Display { privado $ calculadora ; función __construct (calculadora calculadora $ = null) { $ This -> calculadora = $ calculadora ? : $ this -> makeCalculator (); }/ / ... / /} |
Mediante la inyección de la
calculadora de objeto a través de la pantalla 's constructor, redujimosDisplay 's dependencia a la Calculadora de clase. Pero esto es sólo la mitad de la solución.Acoplamiento reductor con interfaces
También podemos reducir el acoplamiento mediante el uso de interfaces. Por ejemplo:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| interfaz CanCompute { funcionar add (); función de resta ();}clase Calculadora implementa CanCompute { privado $ primerNumero ; privado $ secondNumber ; función __construct ( $ primerNumero , $ secondNumber ) { $ This - primerNumero> = $ primerNumero ; $ This -> secondNumber = $ secondNumber ; } función add () { devolver $ this -> primerNumero + $ this -> secondNumber; } función de resta () { devolver $ this - primerNumero> - $ this - secondNumber>; }}clase Display { privado $ calculadora ; función __construct (CanCompute $ calculadora = null) { $ This -> calculadora = $ calculadora ? : $ this -> makeCalculator (); } función printSum () { echo $ this -> Simulador-> add (); } función makeCalculator () { volver nueva Calculadora (1, 2); }} |
Usted puede pensar en ISP como un principio de cohesión de nivel superior.
Este código se introduce el
CanCompute interfaz. Una interfaz es tan abstracto como usted puede conseguir en programación orientada a objetos, sino que define los miembros que una clase debe implementar. En el caso del ejemplo anterior, Calculadora implementa la CanComputeinterfaz.Display constructor 's espera un objeto que implementaCanCompute . En este punto, la pantalla dependencia 's con calculadora está efectivamente roto. En cualquier momento, podemos crear otra clase que implementaCanCompute y pasar un objeto de esa clase de Pantallaconstructor 's. Display ahora sólo depende de laCanCompute interfaz, pero incluso esa dependencia es opcional. Si no pasa argumentos a la pantalla constructor @ s, sino que simplemente va a crear un clásico Calculadora objeto llamando makeCalculator () . Esta técnica se utiliza con frecuencia, y es extremadamente útil para desarrollo basado en pruebas (TDD).Los principios sólidos
SOLID es un conjunto de principios para escribir código limpio, que a su vez hace que sea más fácil de cambiar, mantener y ampliar en el futuro. Son recomendaciones que, cuando se aplica a código fuente, tienen un efecto positivo sobre la capacidad de mantenimiento.
Un poco de historia
Los principios sólidos, también conocidos como principios ágiles, fueron definidos inicialmente por Robert C. Martin. A pesar de que él no ha inventado todos estos principios, él fue quien los puso juntos. Usted puede leer más sobre ellos en su libro: Agile Software Development, principios, patrones y prácticas .Sólidos principios cubren una amplia gama de temas, pero voy a presentarlos en una forma tan simple como que soy capaz. No dude en pedir detalles adicionales en los comentarios, si es necesario.
Principio de responsabilidad individual (SRP)
Una clase tiene una responsabilidad única. Esto puede sonar simple, pero a veces puede ser difícil de entender y poner en práctica.
1
2
3
4
5
6
| clase Reportero { función generateIncomeReports (); función generatePaymentsReports (); función computeBalance (); función PrintReport ();} |
¿Quién crees que se beneficia de esta clase de comportamiento '? Bueno, un departamento de contabilidad es una opción (para el resto), el departamento de finanzas puede ser otra (para los informes de ingresos / pagos), e incluso el departamento de archivo puede imprimir y archivar los informes.
Hay cuatro razones por las que podría tener que cambiar esta clase; cada departamento pueden querer que sus respectivos métodos personalizados para sus necesidades.
La SRP recomienda romper esas clases en otras más pequeñas, beahvior clases específicas, teniendo cada uno una sola razón para cambiar. Tales clases tienden a ser altamente cohesiva y ligeramente acopladas. En un sentido, SRP es la cohesión se define desde el punto de vista de los usuarios.
Dependencia Principio Inversión (DIP)
Este principio establece que altos módulos no debe depender de módulos de bajo nivel, ambos deben depender de abstracciones. Las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones. En pocas palabras, usted debe depender de abstracciones tanto como sea posible y nunca en las implementaciones concretas.
El truco con el DIP es que se desea invertir la dependencia, pero quiere mantener el flujo de control.Vamos a revisar nuestro ejemplo de la OCP (los
interruptores y Luz clases). En la implementación original, que tenía un interruptor de controlar directamente una luz.
Como se puede ver, tanto la dependencia y el control de flujo de
interruptor hacia la Luz . Si bien esto es lo que queremos, no queremos depender directamente de la Luz . Así que hemos introducido una interfaz.
Es increíble cómo la simple introducción de una interfaz que hace que nuestro código respeto tanto DIP y OCP. Como se puede ver, no, clase depende de la aplicación concreta de
la Luz , y tanto la luz yinterruptor depende de la Conmutable interfaz. Hemos invertido la dependencia, y el flujo de control se mantuvo sin cambios.Diseño de Alto Nivel
Otro aspecto importante de su código es su alto nivel de diseño y arquitectura en general. Una arquitectura enredado que el código sea difícil de modificar. Mantener una arquitectura limpia es esencial, y el primer paso es comprender cómo separar las diferentes preocupaciones de su código.
En esta imagen, he tratado de resumir las principales preocupaciones. En el centro del esquema es nuestra lógica de negocio. Se debe estar bien aislado del resto del mundo, y ser capaz de trabajar y se comportan como se espera, sin la existencia de ninguna de las otras partes. Véanlo como ortogonalidad en un nivel superior.
A partir de la derecha, usted tiene su "principal" - el punto de entrada a la aplicación - y las fábricas que crean objetos. Una solución ideal sería conseguir sus objetos de fábricas especializadas, pero que es sobre todo imposible o poco práctico. Sin embargo, usted debe utilizar las fábricas cuando se tiene la oportunidad de hacerlo, y mantenerlos fuera de la lógica empresarial.
Luego, en la parte inferior (en naranja), tenemos la persistencia (bases de datos, accesos a ficheros, comunicaciones de red) para fines de información persistente. Ningún objeto de nuestra lógica de negocios debe saber cómo funciona persistencia.
A la izquierda es el mecanismo de entrega.
Un MVC, como Laravel o CakePHP, sólo debe ser el mecanismo de entrega, nada más.
Esto le permite intercambiar un mecanismo a otro sin tocar la lógica empresarial. Esto puede sonar extraño para algunos de ustedes. Se nos dice que nuestra lógica de negocios debe ser colocado en nuestros modelos. Bueno, estoy de acuerdo. Nuestros modelos deben ser "modelos de solicitud", es decir, objetos mudos de datos utilizados para pasar información de MVC a la lógica de negocio. Opcionalmente, no veo ningún problema incluyendo la validación de entrada en los modelos, pero nada más. La lógica de negocio no deben estar en los modelos.
Cuando nos fijamos en la arquitectura de la aplicación o de la estructura de directorios, debería ver una estructura que sugiere lo que el programa hace lo contrario de lo que marco o base de datos que utiliza.
Por último, asegúrese de que todas las dependencias punto hacia nuestra lógica de negocio. Las interfaces de usuario, fábricas, bases de datos son aplicaciones muy concretas, y nunca debe depender de ellos. Inversión de las dependencias para que apunten hacia nuestra lógica de negocio modulariza nuestro sistema, lo que nos permite cambiar las dependencias sin modificar la lógica de negocio.
