8791 sujets

Développement web côté serveur, CMS

Classe normale/méthodes static ou classe abstract/méthodes normales

Bonjour à tous,

J'espère que le sujet de ce post n'a pas déjà été traité, à priori je n'ai rien vu qui y réponde précisément. Je voulais avoir votre avis sur une question de POO entre abstract/static, je suis en train de développer une application php en n/tiers et je rencontre ce problème:

J’ai une classe utilisateurBLL qui appelle pour la persistance de l’utilisateur
une classe utilisateurDAL (celle-ci génére le SQL et instancie un objet de la classe mysql qui possède les infos de connexion et les méthodes d’accès).

J’ai mis toutes les méthodes de utilisateurDAL en statique car je n’ai à aucun moment besoin d’instancier cet objet.
Et du coup je me demande si je ne devrai pas plutôt mettre ma classe utilisateurDAL en abstract et remettre des méthodes normales, car je ne vois pas (dans ce cas de figure) de différence entre
a/ une classe normale avec toutes ses méthodes statiques et
b/ une classe abstraite avec toutes ses méthodes normales.
Existe-t-il une différence applicative entre les deux dans ce cas particulier ou suis-je à un degré extrême de masturbation intellectuelle xD Smiley sweatdrop ?
(je n’ai pas besoin ici d’utiliser le polymorphisme/override qui est pourtant au fondement du concept de classe abstraite).

Merci d'avance de vos réponses/solutions/avis
Cordialement
Modifié par renard_chenapan (17 Jul 2012 - 17:03)
Euh... une classe abstraite n'a pas pour vocation d'être utilisée directement. Ou alors il y a un truc que j'ai loupé dans ton raisonnement.
Merci de ta réponse,

donc la classe UtilisateurDAO étant utilisée directement par l'appel de méthodes concernant l'accès aux données, je ne peux pas (conceptuellement parlant bien sûr) la déclarer abstraite.
En revanche si j'ai bien compris, en créant 2 classes dérivées de utilisateurBLL: externeBLL et interneBLL et en n'instanciant que les classes enfants, il serait logique que je déclare ma classe parent utilisateurBLL en abstract Smiley murf

Accessoirement, c'est bien de faire cette démarche ou je perd mon temps à trop conceptualiser ?... Smiley confus

Cordialement.
ce sont deux classes dérivées de UtilisateurBLL (qui est abstract et ne peut donc être instancié). Il ne peut donc exister qu'un utilisateur interne ou un utilisateur externe, mais pas un utilisateur tout court xD.

Dans ce cas là, si j'ai bien compris, ma méthode viewAllUsers() sera déclarée et implémenté dans la classe parent abstraite (la UtilisateurBLL) pour me remonter tous les utilisateurs et elle sera surchargée/override dans les classes enfants pour ne remonter que les utilisateurs internes ou externes.....

Une classe abstraite doit-elle nécessairement avoir une méthode abstraite ? (il peut donc y avoir des classes abstraites sans méthode abstraite) ou est ce que la condition ne marche que dans l'autre sens (la définition dit: "si une méthode est abstraite alors la classe doit l'être aussi")

de même une classe abstraite doit-elle forcément faire l'objet d'un héritage (nécessaire pour la propriété de polymorphisme) ou pas (sans héritage on peut s'en servir uniquement pour sa propriété de non-instanciation)...... pfiouuu...

J'espère que je ne suis pas trop obscur dans la manipulation de ces concepts..

bien cordialement.
Salut,

j'ai l'impression que tu mélanges un peu tout; analyse bien ce qu'on te demande, regarde si tu as besoin d'avoir des instances de tes utilisateurs (interactions avec d'autres objets / modules ?). Si c'est le cas, il faut à priori éviter les classes utilitaires (ie statiques).

Après, si tu dois faire la différence au niveau traitement entre users internes et externes (utilisation du polymorphisme et/ou méthodes spécifiques ), l'héritage est à utiliser, sinon il n'a pas lieu d'être. (exemple: si tu distingues juste tes types utilisateur par un flag en BdD...)

Une classe peut être déclarée abstraite et ne comporter aucune méthode abstraite. Elle ne pourra simplement pas être instanciée.

Enfin, si une classe abstraite ne fait pas l'objet d'héritage, et bien, elle ne sert à rien, et ne devrait pas être dans ton projet : on ne peut pas l'instancier !
a écrit :
sans héritage on peut s'en servir uniquement pour sa propriété de non-instanciation

?? Si tu veux empêcher l'instanciation d'une classe (ex: classe avec le stéréotype utility ), tu ne la déclare pas en abstract, mais tu mets son constructeur en privé.
Merci de ta réponse Zed13

C'est bon du coup pour la partie UtilisateurBLL et ses 2 classes dérivées externe et interne.

Bien vu le constructeur privé, je n'y avait jamais pensé mais c'est effectivement le plus simple et logique, je vais jeter un oeil sur comment générer ça en php.

Quelle serait la construction la plus logique du coup pour ma classe UtilisateurDAO ?
normale avec des méthodes statiques (puisque je n'ai pas besoin d'objet instancié UtilisateurDAO) ? et si oui existe-t-il des classes statiques en php (je n'ai pas vu de documentation sur des classe statique en php sur google).


Cordialement.
Il n'y a pas de "construction la plus logique", tout dépend de ton projet : il faut peser le pour et le contre.

En php, tu peux faire des classes statiques de cette manière: 



  Classe Utilitaire {
    
    /**
    * Statique : instanciation impossible
    */
    private function __construct(){
    }  

    static public function f1(){
    }
     
    static public function f2(){
    }

  }
OK,

J'avais construit ma classe sur la même structure (sans le constructeur privé, d'où le post classe normal / méthodes static ),
C'est dommage qu'on ne puisse pas déclarer simplement

static class Utilisateur {

     public function load_utilisateur(){
     
     }

}


En tout cas merci de tes réponses Smiley smile

je pense qu'on peut cloturer le post ^^
Sujet clos
Aller à