Les includes PHP vs OOP

Question

Je voudrais avoir une référence pour les avantages et les inconvénients de l'utilisation inclure fichiers vs objets(classes) lors du développement d'applications PHP.

Je sais que je serait à l'avantage d'avoir un endroit où aller pour cette réponse...j'ai quelques opinions de mon propre chef, mais j'ai hâte d'entendre les autres.

Un Exemple Simple:

Certaines pages de mon site ne sont accessibles qu'aux utilisateurs enregistrés.J'ai deux options pour la mise en œuvre (il y en a d'autres, mais nous allons limiter à ces deux)

1. Créer un authenticate.php fichier et de les inclure sur chaque page.Il tient de la logique pour l'authentification.

2. Créer un objet utilisateur, qui a une fonction authentification, référence de l'objet pour l'authentification sur chaque page.

Modifier J'aimerais voir d'une certaine façon de peser les avantages de l'un sur l'autre.Mon actuel (et de faibles raisons) suivre:

Comprend - Parfois une fonction est plus facile/plus court/rapide pour appeler Objets - Regroupement de fonctionnalités et propriétés conduit à long terme à l'entretien.

Comprend - Moins de code à écrire (pas de constructeur, pas de classe syntaxe) appelez-moi paresseux, mais c'est vrai.

Les objets - Force de formalité et une approche unique à des fonctions et à la création.

Comprend - Plus facile pour un novice de faire face avec Les objets - plus Difficile pour les novices, mais désapprouvée par les professionnels.

Je regarde ces facteurs au début d'un projet pour décider si je veux ne comprend ou d'objets.Ce sont quelques-uns des avantages et des inconvénients sur le dessus de ma tête.

Answer 1

Ce ne sont pas vraiment à l'opposé des choix.Vous devrez inclure le code de vérification de toute façon.J'ai lu votre question dans la programmation procédurale vsLa programmation orientée-objet.

L'écriture de quelques lignes de code, ou une fonction, et en l'incluant dans votre en-tête de page était de savoir comment les choses ont été faites en PHP3 ou PHP4.C'est simple, ça fonctionne (c'est comment nous l'avons fait dans osCommerce, par exemple, un e-commerce PHP de l'application).

Mais il n'est pas facile à maintenir et à modifier, comme de nombreux développeurs peuvent confirmer.

En PHP5 vous voulez écrire un objet utilisateur qui va effectuer ses propres données et méthodes pour l'authentification.Votre code sera plus clair et plus facile à maintenir car tout avoir à faire avec les utilisateurs et l'authentification sera concentrée dans un seul endroit.

Answer 2

Alors que la question porte sur un couple de très discutable questions (programmation orientée objet, l'authentification de l'Utilisateur) je vais passer par ceux-ci et la seconde Konrad commentaire à propos de __autoload.Toute personne qui connaît le C/C++ sait combien la douleur, y compris les fichiers peuvent être.Avec chargement automatique, une PHP5 outre, si vous choisissez d'utiliser la programmation orientée objet (ce que je fais presque exclusivement) vous avez seulement besoin d'utiliser certains de fichier standard convention de nommage et (je le recommande) en limitant à une seule classe par fichier et PHP fera le reste pour vous.Nettoie le code et vous n'avez plus à vous soucier d'oublier d'enlever comprend qui ne sont plus nécessaires (l'un des nombreux problèmes avec la comprend).

Answer 3

Je n'ai pas beaucoup d'expérience en PHP, bien que je l'utilise à mon travail actuel.En général, je trouve que les grands systèmes de bénéficier de la lisibilité et de l'intelligibilité que OO fournit.Mais des choses comme la cohérence (ne pas mélanger OO et non OO) et de vos préférences personnelles (bien que seulement vraiment sur des projets personnels) sont également importants.

Answer 4

J'ai appris à ne jamais les utiliser include en PHP, sauf à l'intérieur du noyau des bibliothèques que j'utilise et une centrale include de ces bibliothèques (+ config) dans l'application.Tout le reste est géré par un mondial __autoload le gestionnaire peut être configuré pour reconnaître les différentes classes nécessaires.Cela peut être fait facilement en utilisant approprié des conventions de nommage pour les classes.

Ce n'est pas seulement souple mais aussi très efficace et maintient l'architecture propre.

Answer 5

Pouvez-vous être un peu plus précis?Pour l'exemple que vous donnez, vous devez utiliser inclure dans les deux sens.Dans le cas 1-vous seulement inclure un fichier, dans le cas 2, vous devez inclure le fichier de classe (par exemple user.class.php) pour permettre l'instanciation de la classe Utilisateur.

Il dépend de la façon dont le reste de l'application est construite, est-elle OO?Utiliser OO.

Answer 6

Si vous le faites dans les classes ou dans un plus de style procédural, il vous suffit de vérifier que:

1. Il y a une session;
2. Que la session est valide;et,
3. Que l'utilisateur en possession de la session a les privilèges adéquats.

Vous pouvez encapsuler toutes les trois étapes en une fonction (ou d'une méthode statique dans une classe Session pourrait fonctionner).Essayez ceci:

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.
}