style - psr2 php

PHP incluye vs OOP

Question

Me gustaría tener una referencia de los pros y los contras del uso de archivos de inclusión vs objetos (clases) al desarrollar aplicaciones PHP.

Sé que me beneficiaría tener un lugar al que acudir para esta respuesta ... Tengo algunas opiniones propias, pero espero escuchar otras.

Un ejemplo simple:

Ciertas páginas de mi sitio solo son accesibles para los usuarios que inician sesión. Tengo dos opciones para la implementación (hay otras, pero limitémoslas a estas dos)

1. Cree un archivo authenticate.php e inclúyalo en cada página. Tiene la lógica para la autenticación.

2. Cree un objeto de usuario, que tenga una función de autenticación, haga referencia al objeto para la autenticación en cada página.

Editar Me gustaría ver de alguna manera sopesar los beneficios de uno sobre el otro. Mis razones actuales (y débiles) siguen:

Incluye: a veces, una función es más sencilla / más corta / más rápida para llamar a Objetos: agrupación de funcionalidad y propiedades potenciales para un mantenimiento a más largo plazo.

Incluye - Menos código para escribir (sin constructor, sin sintaxis de clase) llámame flojo, pero esto es cierto.

Objetos - Formalidad de la fuerza y ​​un enfoque único para las funciones y la creación.

Incluye - Más fácil para un principiante para tratar con objetos - Más difícil para los principiantes, pero mal visto por los profesionales.

Miro estos factores al inicio de un proyecto para decidir si quiero incluir u objetos. Esos son algunos pros y contras de la parte superior de mi cabeza.

Answer 1

Estas no son realmente opciones opuestas. Deberás incluir el código de verificación de todos modos. Leí su pregunta como programación procedural vs. programación OO.

Escribir algunas líneas de código, o una función, e incluirlo en el encabezado de su página era cómo se hacían las cosas en PHP3 o PHP4. Es simple, funciona (así es como lo hicimos en osCommerce , por ejemplo, una aplicación PHP de comercio electrónico).

Pero no es fácil de mantener y modificar, como muchos desarrolladores pueden confirmar.

En PHP5 escribiría un objeto de usuario que llevará sus propios datos y métodos para la autenticación. Su código será más claro y más fácil de mantener ya que todo lo que tenga que ver con los usuarios y la autenticación se concentrarán en un solo lugar.

Answer 2

No tengo mucha experiencia PHP, aunque la estoy usando en mi trabajo actual. En general, considero que los sistemas más grandes se benefician de la legibilidad y la comprensibilidad que ofrece OO. Pero cosas como la coherencia (no mezclar OO y no-OO) y sus preferencias personales (aunque solo en proyectos personales) también son importantes.

Answer 3

Si bien la pregunta toca un par de cuestiones muy debatibles (OOP, autenticación de usuario), omitiré esos y el segundo comentario de Konrad sobre __autoload. Cualquiera que conozca C / C ++ sabe cuánto puede causar dolor, incluidos los archivos. Con autoload, una adición de PHP5, si eliges usar OOP (que hago casi exclusivamente), solo necesitas utilizar una convención de nomenclatura de archivo estándar y (lo recomendaría) restringir una sola clase por archivo y PHP hará el resto por ti. Limpia el código y ya no tiene que preocuparse de recordar eliminar elimina que ya no son necesarios (uno de los muchos problemas que incluye).

Answer 4

Ya sea que lo haga en clases o en un estilo más de procedimiento, simplemente necesita verificar que:

1. Hay una sesión;
2. Que la sesión es válida; y,
3. Que el usuario en posesión de la sesión tenga los privilegios adecuados.

Puede encapsular los tres pasos en una función (o puede funcionar un método estático en una clase de sesión). Prueba esto:

class Session
{
  const GUEST = 0;
  const SUBSCRIBER = 1;
  const ADMINISTRATOR = 2;

  public static function Type()
  {
    session_start();

    // Depending on how you use sessions on
    // your site, you might just check for the
    // existence of PHPSESSID. If you track
    // every visitor with sessions, however, you
    // might want to assign some separate unique
    // number (that you can track in a DB) to
    // authenticated sessions
    if(!$_SESSION[''uniqid''])
    {
      return Session::GUEST;
    }
    else
    {
      // For the best security, don''t store the
      // user''s access permissions in the $_SESSION,
      // but rather check against the DB. This will
      // ensure that recently deleted or downgraded
      // administrators will not be able to make use
      // of a previous session.

      return THE_ACCESS_LEVEL_ACCORDING_TO_THE_DB
    }
  } 
}


// In your files that need to check for authentication (you
// could also do this in a controller if you''re going MVC

if(!(Session::Type() == Session::ADMINISTRATOR))
{
  // Redirect them to wherever you want them to go instead,
  // like a log in page or something like that.
}

Answer 5

puedes ser un poco mas especifico? Para el ejemplo que le da debe usar include en ambos sentidos. En el caso 1 solo incluye un archivo, en el caso 2 necesita incluir el archivo de clase (por ejemplo, user.class.php) para permitir la creación de instancias de la clase User.

Depende de cómo se construya el resto de la aplicación, ¿es OO? Use OO.

Answer 6

Aprendí a no utilizar include en PHP excepto dentro de las bibliotecas centrales que uso y una central de estas bibliotecas (+ config) en la aplicación. Todo lo demás lo maneja un controlador global __autoload que se puede configurar para reconocer las diferentes clases necesarias. Esto se puede hacer fácilmente usando las convenciones de nomenclatura apropiadas para las clases.

Esto no solo es flexible sino también bastante eficiente y mantiene la arquitectura limpia.