Buenas tardes, siguiendo con mi linea de ideales de PHP Component Model, voy a hablar sobre las reglas básicas de PCM, pero antes tengo que hacer una breve reseña de la estructura general de PCM.
Hablaremos sobre los componentes, y sobre PCM y sus dos divisiones.
Esto incluye también una breve reseña de ComponentLibrarySystem.
pero antes mi texto de siempre :P
La estructura
PHP Component Model (PCM) se divide en dos grandes partes, Components y ComponentLibrarySystem.
A su vez, los Components se dividen en otras 3 partes (4 en realidad pero la 4º es opcional), Object (objeto), Interface, ComponentLibrary.
La primera parte (Components) hace referencia a cada componente en si, como había dicho previamente, éste modelo trata de crear componentes que sean extensibles y reusables, como dije en previas entradas de mi blog, para que algo sea reusable no alcanza con que copies el código y lo uses para ótro programa del mismo estilo, para que algo sea reusable, el código no debe cambiar cuando el contexto cambie, además el tema de la extensibilidad es bastante más complejo que agregar funcionalidad a un código, pero dejando de lado las explicaciones que ya había hecho en entradas anteriores, la idea de los componentes es crear código extensible y reusable, para lo cual tiene que reunir como minimo las siguientes características:
Cada componente debe poder evolucionar separadamente del sistema que lo use, en otras palabras para que el lector pueda hacerse con una idea, el componente puede ser modificado, mejorado, y extendido sin depender del sistema en el que se ejecute.
Para que eso ocurra es necesario que, por medio de la interfaz, el sistema que use dicho componente acepte cualquier tipo de cambio en el componente, sin dejar de funcionar ni dar problemas de compatibilidad.
Para que dicho componente sea válido debe tambien cumplir con Encapsulación, Ocultamiento de Información y criterios de modularidad (descomposición modular, composición modular).
El componente debe utilizar el ComponentLibrary, diseñado para poder interactuar con el sistema que lo use, y especificar datos como la versión del componente, y la posibilidad de ejecutar o no ejecutar ciertas funciones.
El componente debe siempre tener una version con las mejoras pertinentes para no hacer uso de funciones dadas de baja por los creadores de PHP, y además el componente NO debe usar funciones experimentales, ni funciones que tengan una ejecución errática o inestable.
Los componentes deben preveer las siguientes situaciones como minimo:
No implementadas funciones de seguridad.
Mala instanciación o manipulación de la clase.
Mal uso de parametros de funciones.
Mal extención de la clase (con esto hago referencia específicamente al método extends de php, que permite cosas como sobreescritura de funciones, de modo que el desarrollador del componente tiene que preveer la reescritura de funciones cuando no se debiera, y evitarlas).
Los componentes NO deben tener dependencias hacia el contexto, (por ejemplo dependencia de un motor de base de datos, o de una estructura de una tabla, por eso se exige que no se trabaje con bases de datos dentro de un componente, salvo que el mismo sea específicamente para manejo simplificado de bases de datos, otro ejemplo podría ser depender de un archivo fuera de la carpeta del componente).
Los componentes deben de funcionar en cualquier situación o contexto sin requerir modificaciones, por ejemplo, si un componente parseador de BBCode, se le quiere agregar un bbcode especial, no se debe tener que editar el código del componente.
Bajo ninguna circunstancia éste modelo admite la edicion del componente por parte de terceros, únicamente se admite la edición del propio autor del componente, para agregar funcionalidades o arreglar bugs.
Si un componente no cumple con cualesquiera de las características explicadas en éste texto, no se puede asegurar la correcta funcionalidad del componente, y en los peores casos puede afectar parte del sistema que utilize el componente.
Los componentes deben ser entregados y utilizados dentro de una carpeta con el nombre del componente, para las siguientes explicaciones, daremos el ejemplo de un componente llamado MensajesPrivados.
La carpeta del componente debe ser llamada MensajesPrivados.
Los components están internamente divididos en 4 partes, la primera parte es el componente en si, una clase que tenga las funciones y el código que ejecuta dicho componente (el archivo debe ser llamado con el prefijo Component, quedando en el ejemplo: ComponentMensajesPrivados.php)
La segunda parte es la interface, en la cual se definen las funciones públicas y atributos accesibles ya sean de solo lectura o de lectura y escritura, deben hacer uso del constructor del lenguaje PHP llamado Interface (puede leer la documentación de php sobre interface).
La tercera parte es el ComponentLibrary, que debe ser un TRAIT (para mas información puede leer la documentación de php sobre traits), que especifique ciertas cosas para que el ComponentLibrarySystem pueda registrar el componente satisfactoriamente (el archivo debe ser llamado ComLib.php).
La cuarta parte es opcional y representa extensiones, si por cuestion de orden o lo que usted decee necesita crear otro archivo con funcionalidades extras, otra clase, o traits que sean necesarios para el componente, usted puede crear una extension, obviamente con el prefijo Extension (en el ejemplo: ExtensionNombre.PHP)
La segunda parte de PHP Component Model, es el ComponentLibrarySystem, un sistema diseñado para registrar, y evaluar los componentes que se deceen cargar, para resolver si el componente es válido, si tiene algún error, y si la versión es compatible con la versión especificada), además debe llevar un registro de los componentes y poder dar de baja componentes sin afectar al sistema que usa dicho componente.
Por supuesto debe generar un log de errores que si llega a ocurrir un problema con el componente el programador pueda saber qué es lo que ocurre.
en entradas futuras se dará más detalles hacerca de las divisiones explicadas en esta publicacion.
Hablaremos sobre los componentes, y sobre PCM y sus dos divisiones.
Esto incluye también una breve reseña de ComponentLibrarySystem.
pero antes mi texto de siempre :P
ADVERTENCIA: probablemente
mucha gente esté en desacuerdo con lo que expreso en las entradas de mi
blog, la idea del blog siempre fue, como todo blog, la de presentar
textos que muestren un poco de mi "día a día", en mi caso en el mundo de la programación y la informática.
No obstante, todos mis textos están basados en la normativa vigente, y en toda mi experiencia hasta el momento, aquellos que estén en desacuerdo, probablemente sea por ignorancia o desconocimiento, y también podríamos mencionar engreimiento, creer que saben todo, pero tampoco podemos dejar de lado que quizá esté equivocado en algunas cosas, pero con el tiempo me daré cuenta y lo aclararé en nuevas entradas al blog.
No obstante, todos mis textos están basados en la normativa vigente, y en toda mi experiencia hasta el momento, aquellos que estén en desacuerdo, probablemente sea por ignorancia o desconocimiento, y también podríamos mencionar engreimiento, creer que saben todo, pero tampoco podemos dejar de lado que quizá esté equivocado en algunas cosas, pero con el tiempo me daré cuenta y lo aclararé en nuevas entradas al blog.
La estructura
PHP Component Model (PCM) se divide en dos grandes partes, Components y ComponentLibrarySystem.
A su vez, los Components se dividen en otras 3 partes (4 en realidad pero la 4º es opcional), Object (objeto), Interface, ComponentLibrary.
La primera parte (Components) hace referencia a cada componente en si, como había dicho previamente, éste modelo trata de crear componentes que sean extensibles y reusables, como dije en previas entradas de mi blog, para que algo sea reusable no alcanza con que copies el código y lo uses para ótro programa del mismo estilo, para que algo sea reusable, el código no debe cambiar cuando el contexto cambie, además el tema de la extensibilidad es bastante más complejo que agregar funcionalidad a un código, pero dejando de lado las explicaciones que ya había hecho en entradas anteriores, la idea de los componentes es crear código extensible y reusable, para lo cual tiene que reunir como minimo las siguientes características:
Cada componente debe poder evolucionar separadamente del sistema que lo use, en otras palabras para que el lector pueda hacerse con una idea, el componente puede ser modificado, mejorado, y extendido sin depender del sistema en el que se ejecute.
Para que eso ocurra es necesario que, por medio de la interfaz, el sistema que use dicho componente acepte cualquier tipo de cambio en el componente, sin dejar de funcionar ni dar problemas de compatibilidad.
Para que dicho componente sea válido debe tambien cumplir con Encapsulación, Ocultamiento de Información y criterios de modularidad (descomposición modular, composición modular).
El componente debe utilizar el ComponentLibrary, diseñado para poder interactuar con el sistema que lo use, y especificar datos como la versión del componente, y la posibilidad de ejecutar o no ejecutar ciertas funciones.
El componente debe siempre tener una version con las mejoras pertinentes para no hacer uso de funciones dadas de baja por los creadores de PHP, y además el componente NO debe usar funciones experimentales, ni funciones que tengan una ejecución errática o inestable.
Los componentes deben preveer las siguientes situaciones como minimo:
No implementadas funciones de seguridad.
Mala instanciación o manipulación de la clase.
Mal uso de parametros de funciones.
Mal extención de la clase (con esto hago referencia específicamente al método extends de php, que permite cosas como sobreescritura de funciones, de modo que el desarrollador del componente tiene que preveer la reescritura de funciones cuando no se debiera, y evitarlas).
Los componentes NO deben tener dependencias hacia el contexto, (por ejemplo dependencia de un motor de base de datos, o de una estructura de una tabla, por eso se exige que no se trabaje con bases de datos dentro de un componente, salvo que el mismo sea específicamente para manejo simplificado de bases de datos, otro ejemplo podría ser depender de un archivo fuera de la carpeta del componente).
Los componentes deben de funcionar en cualquier situación o contexto sin requerir modificaciones, por ejemplo, si un componente parseador de BBCode, se le quiere agregar un bbcode especial, no se debe tener que editar el código del componente.
Bajo ninguna circunstancia éste modelo admite la edicion del componente por parte de terceros, únicamente se admite la edición del propio autor del componente, para agregar funcionalidades o arreglar bugs.
Si un componente no cumple con cualesquiera de las características explicadas en éste texto, no se puede asegurar la correcta funcionalidad del componente, y en los peores casos puede afectar parte del sistema que utilize el componente.
Los componentes deben ser entregados y utilizados dentro de una carpeta con el nombre del componente, para las siguientes explicaciones, daremos el ejemplo de un componente llamado MensajesPrivados.
La carpeta del componente debe ser llamada MensajesPrivados.
Los components están internamente divididos en 4 partes, la primera parte es el componente en si, una clase que tenga las funciones y el código que ejecuta dicho componente (el archivo debe ser llamado con el prefijo Component, quedando en el ejemplo: ComponentMensajesPrivados.php)
La segunda parte es la interface, en la cual se definen las funciones públicas y atributos accesibles ya sean de solo lectura o de lectura y escritura, deben hacer uso del constructor del lenguaje PHP llamado Interface (puede leer la documentación de php sobre interface).
La tercera parte es el ComponentLibrary, que debe ser un TRAIT (para mas información puede leer la documentación de php sobre traits), que especifique ciertas cosas para que el ComponentLibrarySystem pueda registrar el componente satisfactoriamente (el archivo debe ser llamado ComLib.php).
La cuarta parte es opcional y representa extensiones, si por cuestion de orden o lo que usted decee necesita crear otro archivo con funcionalidades extras, otra clase, o traits que sean necesarios para el componente, usted puede crear una extension, obviamente con el prefijo Extension (en el ejemplo: ExtensionNombre.PHP)
La segunda parte de PHP Component Model, es el ComponentLibrarySystem, un sistema diseñado para registrar, y evaluar los componentes que se deceen cargar, para resolver si el componente es válido, si tiene algún error, y si la versión es compatible con la versión especificada), además debe llevar un registro de los componentes y poder dar de baja componentes sin afectar al sistema que usa dicho componente.
Por supuesto debe generar un log de errores que si llega a ocurrir un problema con el componente el programador pueda saber qué es lo que ocurre.
en entradas futuras se dará más detalles hacerca de las divisiones explicadas en esta publicacion.
0 comentarios:
Publicar un comentario