Parte 4 – WordPress y Programación Orientada a Objetos: Un Ejemplo de WordPress – Diseño

En este punto, tenemos requisitos claramente definidos, tal como se describieron en la Parte 3 de esta serie (consúltelo aquí si se lo perdió).

¡Ahora es el momento de comenzar a pensar en el diseño de nuestro nuevo y mejorado complemento!

Nos gustaría recordarle que este paso puede llevarle mucho tiempo cuando lo pruebe en sus propios proyectos. Probablemente tampoco lo hagas todo bien la primera vez. Lo más probable es que se le ocurra un diseño, comience a implementarlo y luego se dé cuenta de que necesita volver atrás y repensar su enfoque.

Sin embargo, vale la pena el esfuerzo, así que tómate todo el tiempo que sea necesario para que todo salga bien. Un proyecto bien estructurado hará que sea más fácil mantenerlo y ampliarlo, e incluso reutilizar su código en otros proyectos, por lo que a la larga es un buen uso del tiempo.

A continuación, nos centraremos en algunas partes clave del complemento y discutiremos cómo se nos ocurrió nuestro diseño.

Disección de la página de configuración

Echemos un vistazo más de cerca a la página de administración del complemento.

Notará que hay un título ("Limitar configuración de intentos de inicio de sesión"), varias secciones que contienen algunos campos y un botón "Cambiar opciones" en la parte inferior de la página.

Cada sección consta de un título, como "Estadísticas", y algunos campos.

Cada campo tiene un título a la izquierda, y el resto de su contenido a la derecha. Hay campos de texto, botones de radio y casillas de verificación y, algunos de ellos, como "Bloqueos totales", solo muestran información y no pueden ser modificados directamente por el usuario administrador.

Algunos campos también incluyen una descripción, como el campo "Conexión del sitio", pero no todos.

Teniendo en cuenta lo anterior, tenemos que descomponerlo en piezas conceptuales que luego se convertirán en clases.

La API de configuración de WordPress nos permite registrar páginas de configuración, secciones dentro de esas páginas y campos dentro de las secciones:

Páginas → Secciones → Campos

Pensamos, ¿por qué no agregar una "capa" más, los Elementos, para que nuestro complemento sea más fácil de extender en el futuro?

Páginas → Secciones → Campos → Elementos

Entonces, las Páginas y las Secciones son lo que ya explicamos anteriormente, y los Campos contendrán Elementos de cualquier tipo de contenido en el lado derecho.

Tomando en consideración todos estos diferentes tipos de elementos, elegimos una clase Element y varias clases, ampliándola, para las casillas de verificación, botones de radio, números, etc. que generarán resultados diferentes.

Es posible que también necesitemos agregar más páginas y secciones en el futuro. Por lo tanto, es probable que necesitemos ampliar estas clases de secciones y páginas de administración.

Lo mismo ocurre con los campos. Las clases para "Bloqueos totales", "Bloqueos activos", etc. extenderán la misma clase (principal).

Aquí hay una imagen simplificada que demuestra esas relaciones:

Por supuesto, no todos los "componentes" están incluidos en el diagrama.

Una estructura como esta hace que el complemento sea más fácil de extender; podemos agregar fácilmente un campo, elemento o sección si surge la necesidad. Podremos agregar fácilmente más componentes (campos, elementos o secciones) creando nuevas clases secundarias, sin tener que modificar las existentes.

Pensar y abstraer

Ahora es un buen momento para comenzar a pensar en lo que hacen los diversos componentes de nuestro complemento. Durante la fase de diseño, no tenemos que entrar en muchos detalles sobre cómo funciona algo.

Por ejemplo, considere todos los elementos, tablas, estadísticas y casi cualquier otra cosa que se le muestre al usuario. Pueden ser componentes separados sin nada en común, pero eventualmente generarán algún resultado. Por lo tanto, alguna funcionalidad será común para componentes que de otro modo no estarían relacionados. Por supuesto, esto se extiende también al resto de nuestros componentes.

En la imagen anterior, vemos cómo varias clases implementan una interfaz de interfaz de usuario.

Preste atención al hecho de que la interfaz de la interfaz de usuario está implementada por las clases Estadísticas, Registros de bloqueo, Tabla y Elemento, a las que se hace referencia como clases principales . No es necesario que las clases de elemento Radio/Number/Checkbox implementen la interfaz directamente, ya que heredan todas las interfaces de su clase principal. Sin embargo, una clase secundaria podría anular un método de su clase principal.

Como sabemos que nuestro complemento se ocupará de la configuración, podemos asumir con seguridad que leeremos y escribiremos sus valores. Es decir, poder obtener , establecer y eliminar opciones.

Todas estas acciones se agruparán en una clase. Probablemente almacenaremos nuestras opciones en la base de datos de WordPress o algo así. Por ahora, no tenemos que preocuparnos por cómo o dónde almacenaremos nuestros datos.

Podemos mantener la abstracción de las opciones obtener/establecer/eliminar en nuestras mentes, simplificando las cosas conceptualmente y seguir diseñando nuestro complemento.

Archivo de complemento principal

Aquí, proporcionaremos información sobre el complemento para WordPress a través del comentario del encabezado y realizaremos algunas inicializaciones. Organizaremos nuestro código, envolviendo todo en una clase pequeña.

Dependiendo de cómo las clases de nuestro complemento funcionen juntas, la clase principal tendrá que instanciar la mayoría de ellas. Hasta donde sabemos, esto incluirá clases relacionadas con opciones, páginas de administración, reintentos y bloqueos.

Clases potenciales

Nos tomamos un tiempo para tratar de averiguar qué clases vamos a necesitar y terminamos con una lista de la siguiente manera:

• reintentos
• bloqueos
• Galletas
• Error de mensajes
• Notificaciónes de Correo Electrónico
• Avisos de administración
• Botones
• Registros de bloqueo
• Bloqueos activos/totales
• dirección IP

Tenga en cuenta que no existe una sola forma "correcta" de estructurar su complemento. Como ocurre con la mayoría de las cosas en el desarrollo de software, existen múltiples formas igualmente válidas de resolver un problema.

En la sección “General”, por ejemplo, las relaciones entre nuestras clases se verían así:

La sección "Estadísticas" será similar a esto:

Finalmente, los “Registros de bloqueo” serán muy similares a las “Estadísticas”:

Conclusión

Hasta ahora definimos nuestros requisitos y pensamos en un diseño para nuestro complemento nuevo y mejorado. Explicamos cómo creamos nuestra estructura y también proporcionamos algunos diagramas simples que muestran cómo se relacionarán nuestras clases entre sí.

Haga clic aquí para leer la Parte 5 de nuestra Serie de Programación Orientada a Objetos

Ver también

• WordPress y la programación orientada a objetos: una descripción general
• Parte 2 – WordPress y Programación Orientada a Objetos: Un Ejemplo del Mundo Real
• Parte 3 – WordPress y Programación Orientada a Objetos: Α Ejemplo de WordPress – Definición del Alcance