poo - La mejor forma de organizar la jerarquía de clase de PHP

php poo libro pdf

Question

Tengo un marco algo primitivo que he estado usando para la mayoría de mis proyectos, pero me vino a la mente un problema de diseño general que aún no he podido resolver. Para una aplicación determinada, ¿debo separar la estructura de clases específica de la aplicación de la estructura del marco o construir sobre el marco no tan malo?

Por ejemplo, supongamos que tengo un marco con una clase de controlador base y lo extendí para una parte determinada de mi aplicación. ¿Qué arreglo tiene más sentido y por qué?

Estructura de clase A:

• Intuitivo, fácil de encontrar archivos de origen cuando se depura.
• La nomenclatura de archivos / estructura de directorios refleja la jerarquía de clases.

- Framework_Control "Framework/Control.php" - Framework_Control_Index "Framework/Control/Index.php" - Framework_Control_Home "Framework/Control/Home.php" - Framework_Control_Contact "Framework/Control/Contact.php" - Framework_Control_About "Framework/Control/About.php"

Estructura de clase B:

• Mantiene el marco modular y fácil de reemplazar / actualizar.
• Agrega cierta complejidad a la estructura del directorio, el nombre de directorios / archivos ya no sigue la jerarquía de clases todo el tiempo.

- Framework_Control "Framework/Control.php" - Application_Control_Index "Application/Control/Index.php" - Application_Control_Home "Application/Control/Home.php" - Application_Control_Contact "Application/Control/Contact.php" - Application_Control_About "Application/Control/About.php"

Sé que, en general, se reducirá a las preferencias personales, pero quiero asegurarme de sopesar todos los pros y los contras antes de decidir qué camino tomar. Realmente se reduce a la nomenclatura de clases y la estructura del directorio, ya que la jerarquía real seguiría siendo la misma en ambos casos.

Answer 1

Lo que realmente se reduce a esto es qué vas a hacer cuando actualices Framework / Control.php en la Aplicación XYZ. ¿Volverás a la aplicación ABC y harás el mismo cambio? ¿Qué pasa si se trata de un error crítico?

Para la mantenibilidad de todos sus proyectos, iría con su segunda opción.

Answer 2

Le sugiero que vea su código fuente en dos categorías diferentes, dependencias externas o código que se usa en varios sitios y que no es nativo de ninguna de las dependencias nativas o el código que es nativo del sitio en particular en el que está trabajando. .

Parece que Framework / Control.php es parte de una dependencia externa más grande y debe ser administrado como tal, mientras que los archivos de Aplicación / Control son todos nativos del sitio web particular.

Usar esta diferenciación en nuestra estructura de código ha hecho que sea mucho más fácil reutilizar nuestro marco interno entre múltiples sitios muy fácilmente.

Como reflexión final, podría considerar analizar los principales marcos que existen, como Zend Framework, Symfony y otros. A pesar de que todo el marco puede ser más de lo que usted quiere, la estructura de los marcos puede proporcionar una gran cantidad de conocimientos sobre buenas prácticas comunes que están siendo utilizadas por los desarrolladores de PHP en todas partes.