POO EN D7

• Encontramos algunas similitudes en D7 con la POO
• Vamos a ver cosas en D7 que se parecen a la POO

Historia

• Hasta D7 no se usó POO por razones de eficiencia.
• PHP es interpretado, por eso usar POO pierdes eficiencia.
• PHP adoptó tarde la POO, lo mismo ha pasado con Drupal.
• D7 necesita PHP 5, por ello hay módulos que usan POO pero la mayoría no lo hacen.

Conceptos de POO usados en Drupal

Objetos

En Drupal usamos el concecto de objectos para los siguientes componentes:

• Modules, Themes, Nodes y Users

Nodes:

• Sirve para crear contenido.
• Métodos definido en node.module
• Usan bundles para crear tipos de nodos, pero todos pueden usar los métodos definidos en node.module

Modules y Themes:

• Siguen el Controller pattern en el sentido que usan sus propios funciones y definiendo Hooks.

Abstracción

La abstracción en D7 la conseguimos con el sistema de hooks. Los hooks se definen en el fichero *.api.php.

Para nodos es el fichero node.api.php

Encapsulación

La encapsulación se consigue usando namespaces de PHP. Cada módulo usa define funciones, pero para llamarlas hay que usar el namespace correspondiente.

El problema es que esto es una conveción y no es estricto.

Métodos Internos

Van precedidos por una barra baja.

Ejemplo:

_user_categories()

Métodos públicos

NO van precedidos por barra baja, sino que van precedidos por el nombre del módulo

user_save()

Polimorfismo

Los nodos usan polimorfismo al renderizarse. Cuando se va a renderizar un nodo, no se ve de la misma forma en un theme que en otro. Y no se ve de la misma forma un tipo de nodo que otro, todo eso gracias al polimorfismo

Herencia

En el caso de themes heredamos el base theme la manera en la que representamos los nodos. Si queremos cambiarlo podemos usar nuevos templates para romper esa herencia.

En el caso de modules todos heredean los hooks, y pueden implementar hooks para romper los métodos por defecto.

Patrones de Diseño en Drupal (Gang of Four)

Singleton / Instancia Única

Modules y Themes siguen este patrón. Sólo se instancian una vez.

Decorator / Decorador

Recordemos que El patrón Decorator responde a la necesidad de añadir dinámicamente funcionalidad a un Objeto. Esto nos permite no tener que crear sucesivas clases que hereden de la primera incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la primera.

Drupal usa mucho este patrón:

• Polimorfismo en el objeto node (visto antes)
• Sobre todo se ve en los hooks que permiten cambiar la funcionalidad existente. Ejemplos:
  • hook_node_load
  • hook_node_view
• El node por defecto tiene asociado ciertos datos (autor, título), y el hecho de poder añadir nuevos campos a nodos usa este patrón.

Observer / Observador

Este pattern se usa en los hooks. Cuando en tu módulo implementas un hook estás "observando" si se está ejecutando dicho evento.

Por ejemplo: hook_taxonomy_vocabulary_update()

Bridge / Puente

El database abstraction layer usa el Patrón puente ya que el mismo código core de drupal funciona con varios tipos de base de datos.

Chain of Responsibility / Cadena de Responsabilidad

En D7 el sistema de menús sigue toda una cadena de reponsabiliad

Cuando se hace un Request lo primero que se mira es si el link está dentro de la jerarquía de menús.

Si no se encuenta se mira si existe el padre (es decir si haces el request a /usuario/pepito pero pepito no existe entonces va a hacer el request contra /usuario). En este caso se llamará /usuario con variable de entrada pepito.

Además para cada Request se mira si el usuario que está accediendo a la URL tiene derecho a acceder a dicha URL.

Esto se realiza hacia "arriba" en la jerarquía hasta encontrar el GRANT o NO GRANT a dicho Request. En caso de tener el GRANT se ejecutan las funciones pertinentes.

Command / Orden

Recordemos que *Este patrón permite solicitar una operación a un objeto sin conocer realmente el contenido de esta operación, ni el receptor real de la misma. *

El sistema de hooks en sí usa este patrón, de modo que los módulos no tienen que definir cada hook, sino solo los que necesitan implementar.

Porque D7 no usa clases

• razones históricas
• prevenir complejidad en el sistema de theming
• facilidad para extender el sistema mediante hooks

A ser mejorado

• Módulos deberían encapsular mejor sus datos y definir si sus funciones son públicas o privadas
• Dificultad para hacer cambios drásticos en compartamientos del sistema si no tenemos un hook adecuado para ello.

Conclusión

• Drupal 7 sigue sin ser POO por haber usado un lenguaje no orientado a objetos pero usa muchos conceptos internamente de la POO.

• En Drupal 8 se hace un uso más intensivo de la Programación Orientada a Objetos que en versiones anteriores. Es por ello que debe conocerse a la perfección y controlarse de una forma fluida y natural.

• En D8 hay que conocer los siguientes conceptos de la POO:

  • Crear Clases y objetos
  • Constructores y destructores
  • Herencia de clases
  • Clases abstractas
  • Interfaces
  • Traits
  • Excepciones

• En cuanto a los patrones usados en D8 son los siguientes:

  • El patrón Factory method
  • El patrón Singleton
  • El patrón Adapter
  • El patrón Decorator
  • El patrón Strategy
  • El patrón Observer
  • El patrón Inyección de dependencias

https://www.srijan.net/blog/revisiting-php-design-pattern-concepts-in-drupal-8?utm_source=The+Weekly+Drop&utm_medium=email&utm_campaign=drupal-newsletter-20200416