Zend Framework estandariza una convención de nomenclatura de clases mediante la cual los nombres de las clases se corresponden directamente con los directorios en los que se almacenan. El directorio de nivel raíz de la biblioteca estándar de Zend Framework es el directorio "Zend/", mientras que el directorio de nivel raíz de la biblioteca extras de Zend Framework es el directorio "ZendX/". Todas las clases de Zend Framework se almacenan de forma jerárquica bajo estos directorios raíz.
Los nombres de clase solo pueden contener caracteres alfanuméricos. Se permiten
números en los nombres de clase, pero se desaconsejan en la mayoría de los casos.
Los guiones bajos solo se permiten en lugar del separador de ruta; el nombre de archivo
"Zend/Db/Table.php" debe corresponderse con el nombre de
clase "Zend_Db_Table".
Si un nombre de clase está compuesto por más de una palabra, la primera letra de cada
nueva palabra debe ir en mayúscula. No se permiten letras mayúsculas consecutivas, por
ejemplo, una clase "Zend_PDF" no está permitida, mientras que
"Zend_Pdf" es aceptable.
Estas convenciones definen un mecanismo de pseudo-espacio de nombres para Zend Framework. Zend Framework adoptará la característica de espacios de nombres de PHP cuando esté disponible y sea factible que nuestros desarrolladores la utilicen en sus aplicaciones.
Consulta los nombres de clase en las bibliotecas estándar y extras para ver ejemplos de esta convención de nomenclatura.
![[Note]](images/note.png) |
Nota |
|---|---|
Importante: el código que debe desplegarse junto con las bibliotecas de Zend Framework pero que no forma parte de las bibliotecas estándar o extras (por ejemplo, código de la aplicación o bibliotecas que no son distribuidas por Zend) nunca debe comenzar con "Zend_" ni "ZendX_". |
En general, las clases abstractas siguen las mismas convenciones que las clases,
con una regla adicional: los nombres de las clases abstractas deben terminar con el
término "Abstract", y ese término no debe ir precedido de un guion bajo. Como ejemplo,
Zend_Controller_Plugin_Abstract se considera un nombre
inválido, pero Zend_Controller_PluginAbstract o
Zend_Controller_Plugin_PluginAbstract serían nombres
válidos.
|
Nota |
|---|---|
|
Esta convención de nomenclatura es nueva en la versión 1.9.0 de Zend Framework. Las clases anteriores a esa versión pueden no seguir esta regla, pero se renombrarán en el futuro para cumplirla. La razón de este cambio se debe al uso de espacios de nombres. A medida que nos acercamos a Zend Framework 2.0 y al uso de PHP 5.3, utilizaremos espacios de nombres. La forma más sencilla de automatizar la conversión a espacios de nombres es simplemente convertir los guiones bajos en el separador de espacio de nombres, pero con las antiguas convenciones de nomenclatura, esto deja el nombre de la clase simplemente como "Abstract" o "Interface", ambas palabras reservadas en PHP. Si anteponemos el nombre del (sub)componente al nombre de la clase, podemos evitar estos problemas.
Para ilustrar la situación, considera convertir la clase
namespace Zend\Controller\Request;
abstract class Abstract
{
// ...
}
Claramente, esto no funcionará. Sin embargo, bajo las nuevas convenciones de nomenclatura, esto se convertiría en:
namespace Zend\Controller\Request;
abstract class RequestAbstract
{
// ...
}
Seguimos conservando la semántica y la separación de espacios de nombres, mientras omitimos los problemas de palabras clave; al mismo tiempo, describe mejor la clase abstracta. |
En general, las interfaces siguen las mismas convenciones que las clases,
con una regla adicional: los nombres de las interfaces pueden terminar opcionalmente
con el término "Interface", pero ese término no debe ir precedido de un guion bajo.
Como ejemplo, Zend_Controller_Plugin_Interface se
considera un nombre inválido, pero Zend_Controller_PluginInterface
o Zend_Controller_Plugin_PluginInterface serían nombres
válidos.
Aunque esta regla no es obligatoria, se recomienda encarecidamente, ya que proporciona una buena señal visual a los desarrolladores sobre qué archivos contienen interfaces en lugar de clases.
|
Nota |
|---|---|
Esta convención de nomenclatura es nueva en la versión 1.9.0 de Zend Framework. Las clases anteriores a esa versión pueden no seguir esta regla, pero se renombrarán en el futuro para cumplirla. Consulta la sección anterior para más información sobre la razón de este cambio. |
Para todos los demás archivos, solo se permiten caracteres alfanuméricos, guiones bajos y el carácter guion ("-"). Los espacios están estrictamente prohibidos.
Cualquier archivo que contenga código PHP debe terminar
con la extensión ".php", con la notable excepción de los
scripts de vista. Los siguientes ejemplos muestran nombres de archivo aceptables para
las clases de Zend Framework:
Zend/Db.php Zend/Controller/Front.php Zend/View/Helper/FormRadio.php
Los nombres de archivo deben corresponderse con los nombres de clase como se describió anteriormente.
Los nombres de función solo pueden contener caracteres alfanuméricos. No se permiten guiones bajos. Se permiten números en los nombres de función, pero se desaconsejan en la mayoría de los casos.
Los nombres de función siempre deben comenzar con una letra minúscula. Cuando un nombre de función consta de más de una palabra, la primera letra de cada nueva palabra debe ir en mayúscula. Esto se conoce comúnmente como formato "camelCase".
Se fomenta generalmente la verbosidad. Los nombres de función deben ser tan verbosos como sea práctico para describir completamente su propósito y comportamiento.
Estos son ejemplos de nombres aceptables para funciones:
filterInput() getElementById() widgetFactory()
Para la programación orientada a objetos, los accesores de variables de instancia o estáticas deben ir siempre precedidos por "get" o "set". Al implementar patrones de diseño, como los patrones singleton o factory, el nombre del método debe contener el nombre del patrón cuando sea práctico para describir de forma más completa el comportamiento.
Para los métodos de objetos declarados con el modificador "private" o "protected", el primer carácter del nombre del método debe ser un guion bajo. Esta es la única aplicación aceptable de un guion bajo en un nombre de método. Los métodos declarados "public" nunca deben contener un guion bajo.
Las funciones en el ámbito global (también llamadas "funciones flotantes") están permitidas, pero se desaconsejan en la mayoría de los casos. Considera envolver estas funciones en una clase estática.
Los nombres de variable solo pueden contener caracteres alfanuméricos. No se permiten guiones bajos. Se permiten números en los nombres de variable, pero se desaconsejan en la mayoría de los casos.
Para las variables de instancia declaradas con el modificador "private" o "protected", el primer carácter del nombre de la variable debe ser un único guion bajo. Esta es la única aplicación aceptable de un guion bajo en un nombre de variable. Las variables miembro declaradas "public" nunca deben comenzar con un guion bajo.
Al igual que con los nombres de función (ver sección 3.3), los nombres de variable siempre deben comenzar con una letra minúscula y seguir la convención de mayúsculas "camelCaps".
Se fomenta generalmente la verbosidad. Las variables siempre deben ser tan verbosas
como sea práctico para describir los datos que el desarrollador pretende almacenar en
ellas. Los nombres de variable concisos como "$i" y
"$n" se desaconsejan en todos los contextos salvo en los
bucles más pequeños. Si un bucle contiene más de 20 líneas de código, las variables de
índice deben tener nombres más descriptivos.
Las constantes pueden contener tanto caracteres alfanuméricos como guiones bajos. Se permiten números en los nombres de constante.
Todas las letras utilizadas en un nombre de constante deben ir en mayúscula, mientras que todas las palabras de un nombre de constante deben separarse mediante caracteres de guion bajo.
Por ejemplo, EMBED_SUPPRESS_EMBED_EXCEPTION está permitido,
pero EMBED_SUPPRESSEMBEDEXCEPTION no lo está.
Las constantes deben definirse como miembros de clase con el modificador "const". Definir constantes en el ámbito global con la función "define" está permitido, pero se desaconseja firmemente.