Modélisation de class en PHP

WRInaute accro
Bonjour

J'essaye de me familiariser avec le langage objet (PHP tend principalement vers la POO depuis un bon moment et pas moi ;/ ) et j'aurais quelques petites questions

J'ai créé les 2 class suivantes

La class Membre :

Code:
class Membre {
    
    protected $id_membre,
            $login_membre,
            $password_membre,
            $date_demande_pass,
            $nom_membre,
            $prenom_membre,
            $email_membre,
            $id_avatar,
	$nb_commentaires,
	$date_inscription,
	$date_connexion,
	...
	etc. (environ 28 attributs)
        
           
    public function __construct($valeurs=array())
    {
        if(!empty($valeurs)) //si on a spécifié des valeurs alors on hydrate l'objet
        {
            $this->hydrate($valeurs);            
        }       
    }
    
    public function hydrate($donnees)
    {
        foreach ($donnees as $attributs => $valeur)
        {
            $methode = 'set'.ucfirst($attribut);
            if (is_callable(array($this, $methode)))
            {
                $this->$methode($valeur);
            }           
        }
    }
    
    public function setId_membre($id_membre)
    {
        	$this->id_membre=$id_membre;        
    }
    
     public function getId_membre()
    {
        return $this->id_membre;        
    }
    
    public function setLogin_membre($login_membre)
    {
        $this->login_membre=$login_membre;        
    }
    
    public function getLogin_membre()
    {
        return $this->login_membre;        
    }       
 …..... 
…....
…....
etc.
    
 }


la class MembresManager :

Code:
class MembresManager
{
    protected $_connexion;
    
    const ORDER_LAST_MEMBRES = 1;
    const ORDER_ACTIFS_MEMBRES = 2;   
   
    public function __construct(PDO $bdd)
    {
        $this->setConnexion($bdd); 
    }
    
    function getListMembres($debut=0,$fin=10, $order=MembresManager::ORDER_LAST_MEMBRES) {

        $sql='select m.login_membre, m.date_inscr_membre, m.id_avatar, a.avatar'
        . ' from t_membres AS m'
        . ' INNER JOIN t_avatars AS a ON (a.id_avatar=m.id_avatar)';
              
        if($order==MembresManager::ORDER_ACTIFS_MEMBRES)
        {
            $sql .= ' order by m.nb_jours_actifs DESC ';
        }
        else
        {
            $sql .= ' order by m.date_inscr_membre DESC ';
        }
            
        $sql .= ' LIMIT :deb,:fin ';
        
        $requete = $this->_connexion->prepare($sql);
        $requete->bindValue(':deb',(int) $debut, PDO::PARAM_INT);
        $requete->bindValue(':fin',(int) $fin, PDO::PARAM_INT);
        
        $requete->execute();
        
        //retourne directement le résultat dans un objet de la classe Article. FETCH_PROPS_LATE lance le constructeur avant que PDO assigne les valeurs 
        $requete->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE, 'Membre');
        
        $listeMembres=$requete->fetchall();
             
        $requete->closeCursor();
        
        return $listeMembres;

    }
    
    protected function setConnexion(PDO $bdd){
        
        if($bdd instanceof PDO)
        {
            $this->_connexion=$bdd;            
        }         
    }   
}

On a bien une class, un rôle. Une class pour représenter le membre, une autre class pour gérer les membres.

J'ai 3 problèmes.

Problème 1 :


Dans ma class membre je me retrouve avec une 30aine d'attributs.
J'ai l'impression que ça fait beaucoup :/
Ce qui signifie que sur chaque page ou j'affiche la moindre info sur des membres, je crée des instances de la class Membre qui ont donc autant d'attributs. Peu importe la quantité d'info dont j'ai besoin sur la page concernant ces membres. Je trouve ça dommage et peu optimisé.

Exemple, sur la page d'accueil j'affiche les 10 derniers inscrits je fais ceci  :

Code:
$objMembresMg= new MembresManager($bdd);
	
$membres=$objMembresMg->getListMembres(0,10, MembresManager::ORDER_LAST_MEMBRES);

$membres est un tableau d'objets Membre.

Dans ma fonction getListMembres, chaque ligne retournée (soit les 10 demandées) crée un objet Membre avec seulement quelques attributs initialités (login, id_avatar, date_inscription...), les seuls attributs utiles pour ce genre de demande.

N'est-ce pas un peu lourd au niveau mémoire etc. de créer 10 objets avec autant d'attributs, alors que sur ma page d'accueil j'ai uniquement besoin d'afficher son image de profil (avatar), login et date d'inscription?

Problème 2 :

Si on regarde ma fonction getListMembre on voit que je fais une jointure avec une table t_avatars et que je récupère l'avatar du membre. Mais Voila une question me turlupine.

Dois je directement mettre l'attribut avatar (qui correspond au nom de l'image) dans la class Membre ou dois je crée un attribut objavatar qui sera une instance d'une class Avatar ?

En gros j'ai du mal à construire mes class lorsque des données se croisent (tables relationnelles : jointures)

Pour bien différencier les rôles, j'imagine bien une class Avatar et dans la class Membre je fais la fonction set suivante lorsque j'hydrate l'objet Membre :

Code:
    public function setAvatar($avatar)
    {
        $this->avatar= new Avatar(array(avatar => $avatar));        
    }

Un truc dans le genre ;)

Comment feriez vous ? Le problème avec ma solution, je créerais une dépendance assez forte entre ma class membre et la class Avatar (je ne sais pas si c’est vraiment un problème). Je crois que dans ce cas je crée une dépendance de type Composition, si j'ai bien compris.

Problème 3 :

Il s'agit en fait d'un problème que j'avais déjà énoncé dans mon topic concernant le patern MVC.
J'ai constaté qu'avec le langage objet on se retrouve très vite avec un grand nombre d'include (require) de fichiers. Sachant qu'il est généralement conseillé de créer un fichier pour une class.

Alors certes j'utilise l'autoloaded afin que ça charge automatiquement les fichiers (class) qui sont demandées sur la page (ceci évite également d'avoir a faire tous les includes sur les pages). Mais si je prend l'exemple de ma page d'accueil ou j'affiche les derniers membres inscrits, les derniers articles, les derniers commentaires etc. on fini très vite par inclure un bon paquet de class :

Membre
MembresManager
Article
ArtcilesManager
Commentaire
CommentairesManager
Avatar (si je prend cette solution)
AvatarsManager
etc...

le site est surement mieux structuré, et plus facilement maintenable avec ce système, mais d'un point de vue optimisation je n'arrive pas à être convaincu

Je me sers sûrement très mal de la POO :?
 
WRInaute accro
Tu px regarder comment les autres font:
http://www.doctrine-project.org/
http://propelorm.org/
http://redbeanphp.com/
[...]

Les relations se déclarent via des attributs ou des annotations.
Je ne pense pas que ce soit une bonne idée que les classes contiennent d'autres attributs des tables liées.

NB:
Pr coder plus rapidement tes setters et getters pr tous tes attributs, tu px utiliser la méthode magique __call(): http://www.php.net/manual/en/language.oop5.overloading.php#object.call

En général pour les setters, on met return $this; afin de pouvoir les chaîner:
PHP:
<span class="syntaxdefault">$user</span><span class="syntaxkeyword">-></span><span class="syntaxdefault">setUsername</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'noren'</span><span class="syntaxkeyword">)-></span><span class="syntaxdefault">setWebsite</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'http://example.com'</span><span class="syntaxkeyword">)-></span><span class="syntaxdefault">setGender</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'m'</span><span class="syntaxkeyword">);&nbsp;</span><span class="syntaxdefault"></span>
 
WRInaute accro
arf je maitrise déjà pas la POO, alors devoir fouiller et comprendre sur des sites qui parlent la langue de Shakespeare, ça va pas être de la tarte :mrgreen:

D'après ce que tu dis si j'ai les tables suivantes :

t_membres
Code:
id_membre
date_inscription
login
nom
prenom
email
id_avatar
...

t_avatars
Code:
id_avatar
avatar

dans ma class Membre je ne devrais pas avoir l'attribut avatar exact ?, mais uniquement les champs de la table t_membre, donc l'id_avatar (vu qu'il appartient bien a ma table t_membre), est-ce bien ça?

dans ce cas la je serais obligé dans mon contrôleur d’appeler ensuite une méthode d'une class que j'appellerais AvatarsManager pour récupérer les avatars des 10 membres qui ont été retourné par getListMembres. Exact?
ca me ferait quand même faire une requête de plus :/
ça rejoindrait mon idée que la POO c'est bien question organisation du code mais pas forcément au niveau optimisation des ressources.

je vais évidemment avoir le même problème avec ma class Commentaires, vu que dans ma table t_commentaires j'ai une relation avec un article (id_article) mais également avec un auteur (id_membre)
Dans ce cas la dans ma class Commentaire je n'aurais que les attributs id_membre et id_article et je devrais également me débrouiller via le controleur et d'autres class pour récupérer les auteurs et les articles associés à chaque commentaire?

De plus est-ce anormal de ce rendre compte pour le moment qu'on a pas besoin de faire d'héritage? :mrgreen:

Concernant les Set, cette solution me semble la plus adaptée lorsqu'on doit tester chaque attribut, avec des méthodes magiques. même si je l'accorde lorsqu'on a 30 attributs ca peut vite devenir très lourd :/
Dans les bouts de codes que j'ai mis je n'ai pas encore fait les différents test d’où l'apparence de Set totalement inutiles :wink:

par contre qu'en est-il de mon problème 1? :wink:
Est-ce "grave" de faire à chaque fois appel a des objets qui ont plus de 30 attributs alors que dans beaucoup de cas on en a besoin seulement de 4-5?
problème qui ne se poserait pas avec du procédural
 
WRInaute accro
noren a dit:
dans ma class Membre je ne devrais pas avoir l'attribut avatar exact ?, mais uniquement les champs de la table t_membre, donc l'id_avatar (vu qu'il appartient bien a ma table t_membre), est-ce bien ça?
oui

noren a dit:
ca me ferait quand même faire une requête de plus :/
Les ORMs génèrent des jointures pour le faire en 1 requête.

noren a dit:
De plus est-ce anormal de ce rendre compte pour le moment qu'on a pas besoin de faire d'héritage?
Ça viendra vite :)
Par exemple on px imaginer que tu voudrais un champ created/modified dans tous tes models.

noren a dit:
par contre qu'en est-il de mon problème 1? :wink:
Est-ce "grave" de faire à chaque fois appel a des objets qui ont plus de 30 attributs alors que dans beaucoup de cas on en a besoin seulement de 4-5?
problème qui ne se poserait pas avec du procédural
C'est normal.
 
WRInaute accro
spout a dit:
Les ORMs génèrent des jointures pour le faire en 1 requête.

Ça me donne l'impression de devoir sortir l'artillerie lourde pour faire quelque chose qui semble évident et très simple en procédural :/
 
WRInaute accro
Je reste ouvert à d'autres réponses :mrgreen:

Sans utiliser d'ORM (doctrine etc.) comment procéderiez vous pour la modélisation de vos classes lorsqu'il y a des relations (jointures) au niveau des tables.

je reprend l’exemple des 2 tables suivantes

t_membres
Code:
id_membre
login
password
....
id_avatar

t_avatars
Code:
id_avatar
avatar

Comment créeriez vous vos classes dans ce cas la?

Auriez vous une table une class :

Code:
class Membre
{
    attributs = champs de la table t_membres
    méthodes = setters et getters
}

class Avatar
{
     attributs = champs de la table t_avatars
    méthodes = setters et getters
}

et 2 class Manager de ces class (tables) :

Code:
class MembresManager
{
   méthodes pour : select, add, delete ... dans la table t_membres
}

class Avatarsmanager 
{
  méthodes pour : select, add, delete ...  dans la table t_avatars
}

et si oui comment et ou feriez vous la relation entre ces tables et rcuperer une liste de membres avec leurs avatars?

En procédural il suffirait d'une seule requête avec une jointure pour récupérer les données :

Code:
select m.login_membre, m.id_avatar, a.avatar from t_membres AS m INNER JOIN t_avatars AS a ON (a.id_avatar=m.id_avatar) ORDER BY ... LIMIT ....

une requête et le tour est joué :mrgreen:
Mais en programmation orientée objet (sachant qu'une classe = un rôle) ça ne va plus.
Si je suis la logique de la POO j'aurais dans la class MembresManager une méthode getMembres qui ferait seulement ceci

Code:
select login_membre, id_avatar ... from t_membres Order By .... LIMIT ...

et j'aurais dans AvatarsManager une méthode getAvatars qui ferait ceci :

Code:
select id_avatar, avatar from t_avatars Where id_avatar IN (liste id_avatar fournies en arguments de la méthode)

et c'est le contrôleur qui ferait la relation entre les données récupérées par les 2 méthodes

je trouve ça bien plus lourd qu'en procédural, le problme se poserait également pour des update, delete etc.
comment feriez vous en POO (sans passer par les ORM)?
 
WRInaute accro
WRInaute accro
oui pour SQL je compte utiliser PDO ;)

Mais disons que c'est un peu compliqué. Mon backoffice est assez vieux j'utilise mysqli, ma bdd est déjà en place et il était développé en procédural. Par contre pour mon front office (mes nouveaux sites) je passe par PDO et POO en général, ceci afin de commencer à me mettre à jour. J'envisage plus tard de mettre à jour mon back office pour également passer par PDO et POO. je sais c’est pas super propre mais pour le moment je n'ai pas vraiment le temps de faire autrement :wink:

j'utilise également myisam donc pas de gestion de clés étrangères etc. Donc il est préférable de bien nommer les id pour éviter toutes confusions .
Puis ces t_et id_ ces des conventions que j'utilise depuis des années. Il me semble pas qu'il y ai de norme a ce niveau la. Donc j'ai appliquée celle-ci et j'ai essayé de m'y tenir. Pourquoi ca peut poser problème?
En tout cas c’est des habitudes du procédural. J'ai effectivement l'impression qu'avec la POO faut avoir des habitudes différentes :/

Merci pour les liens je vais regarder ça :mrgreen:
 
WRInaute accro
Un truc que je comprend pas.

PHP tend de plus en plus vers un langage orienté objet
Le problème c'est que PHP est le plus souvent combiné avec une BDD MYSQL qui utilise le modèle relationnel.

Hors on constate très vite que la POO et le modèle relationnel ont quand même du mal a cohabiter. Ce qui est encore plus agaçant c’est que j'en ai bouffé des sites et des livres qui parlent de programmation objets et aucun ne faisait mention de cette problématique (ou alors très succinctement) qui me semble majeure.

On lit de bien beaux exemples de class "personnage, voiture, post" etc. mais dans un cas concret ou l'on doit modéliser en class une BDD relationnelle c’est une tout autre histoire.

Spout si tu ne m'avais pas parlé d'ORM (je t'en remercies) je n'aurais pas compris que le probleme venait justement de la "relation" entre le relationnel et l'objet. J'ai toujours pensé (et pourtant j'ai fait des études en informatiques il y a 15-20 ans) que le stockage des données (BDD) et leur traitement (programmation) étaient indépendants. Il faut croire que non.

maintenant je me retrouve bien emmer*é. D'un côté je n'ai pas forcément envie de faire une usine à gaz de mes sites étant donné que je serais le seul a les utiliser et administrer (donc je ne suis pas pas chauds par l'utilisation d'ORM et autres couches qui a mon sens alourdissent plus qu'autre chose) et d'un autre côté je ne voix pas comment je pourrais faire de la POO avec ma BDD relationnel (sans utiliser les ORMs) . D'autant plus que mon objectif était également de me familiariser avec la POO. Je suis resté trop longtemps, a tort, collé à la programmation procédurale.

je serais tenter de faire de l'objet allégé en créant uniquement des class Manager qui regrouperaient toutes les fonctions qui effectuent des requêtes

exmeple : MembresManager, AvatarsManager, ArticlesManager ..

Et je laisserait donc tomber les class "entité" : Membre, Article, Avatar
Mais c’est bien dommage et pas forcément très jojos d'autant plus que j'aurais toujours des methodes dans mes class Manager avec des jointures etc. :?
mais bon au moins je récuperes un tableau en sortie de chaque méthode et je traite ça a l'ancienne ;)

J'étais à mille lieux de penser que je bloquerais à ce niveau là.
Tout ceci donne l'impression que la combinaison PHP Mysql n’est pas forcément adapté pour faire du FULL POO
On peut uniquement se créer quelques petites class outils pour se simplifier certaines taches redondante ou alors on est obligé de se construire un véritable framework (dans ce cas effectivement autant passé par des frameworks déjà existants).

En tout cas si certains d'entre vous ont des astuces pour modéliser leur class en passant par une BDD relationnelle et sans passer par les ORMs je suis preneur (je vais quand même essayer de regarder de plus près les ORMs mais bon...). Même si il est vrai qu'on ne va pas réinventé la roue et que les ORMs sont pensés pour ça; mais qui sait peut être que certains auront quelques petites astuces intéressantes :wink:

PS : d'ailleurs quand on regarde sur la toile l'utilisation des ORMs semble également faire débat
 
WRInaute occasionnel
Bonjour,

Je n'ai pas forcément tout suivi, mais je peux répondre pour les jointures :)
c'est assez simple quand on y réfléchit.

partons tu principes 2 class
1 user
2 upload (image avatar par ex)

lors de la sortie de ta jointure tu va donc devoir appeler les entités des deux class et non mettre image dans user !
L'astuce serait de rajouter dans user une entité upload qui fait référence aux entité de la class upload.
en sortit $user->upload()->src(); par exemple

soit :
Code:
class User {
protected upload;
public setUpload([class ref chemin]Upload $upload) {
$this->upload=$upload;
}
public upload(){
return $this->upload;
}
}



et requete :

Code:
public function getUnique(...) {

		$requete = $this->dao()->prepare('***jointure***');
		$requete->bindValue(':...', $..., \PDO::PARAM_STR);
		$requete->execute();

		$data = $requete->fetch(\PDO::FETCH_ASSOC);
		$requete->closeCursor();	

		return $data ? new UserEntity([
						'id'				=> $data['id'],
						'upload'			=> new UploadEntity([
													'src'				=> $data['src'],
													
												]),
						
					]) :
				null;
	}



voilà un peu le principe...
Je sais pas si je suis clair ;)
Mais c'est 100% objet :)
 
WRInaute accro
A première vu ça ressemble à ce que j'avais proposé en 1er lieu :mrgreen:

Dois je directement mettre l'attribut avatar (qui correspond au nom de l'image) dans la class Membre ou dois je crée un attribut Objavatar qui sera une instance d'une class Avatar ?

Ce qui me dérangeais dans cette solution c'est la dépendance forte entre les différentes class. On a là une dépendance de type Composition, me semble t-il.
J'ai également l'impression à vue de nez que le traitement ensuite des objets créés de ces class entités peut vite devenir complexe.

Si on prend d'autres exemples et qu'on veut utiliser cette méthode ça peut donc vite se compliquer.

Exemple un article. En terme de relation un article est lié à une rubrique, à 0 ou plusieurs tags, un auteur.
Etant donné que la class ArticlesManager aurait des méthodes qui font des jointures avec les tables tags, membres et rubriques, dans ce cas la class entité Article se retrouverait donc avec 3 objets en attribut
- un objet rubrique
- un tableau d'objets tags
- un objet auteur

ma class Commentaire aurait en attribut
- un objet Membre
- un Objet Article

ça me semble en fin de compte pas bien normal comme structure, non ? :/

Tu as structuré tes class de cette façon?
c'est quand même étrange de voir que la plupart utilisent une modélisation relationnelle pour leur BDD et qu'on galère autant pour trouver des infos sur ce problème avec la POO

Autre inconvénient que j'ai souligné dans mon premier post, cela entrainerait un nombre important d'include, étant donné qu'on a un fichier par class. Même en utilisant l'autoload on se retrouve facilement avec une 20aine d'include, voir plus, par script (entre les class manager, entité et autres class de librairie).

C’est moi, ou la POO n’est pas forcément la meilleur solution d'un point de vue optimisation des ressources (memoire, hits etc.) ?
 
WRInaute accro
De plus si pour certaines requêtes on a des left join ça n'aide pas non plus. Sauf si dans tous les cas on crée un objet même vide
 
WRInaute occasionnel
Pour info, je n'ai pas de soucis lors de mon utilisation.
Oui, j'utilise comme cela et c'est très pratique. au moins l'objet existe toujours et tu peux limité les ressources de traitement de variable... après tout dépend de ton code comme en procédural...

Attention, j'ai pas dit que du devez mettre l'attribut avatar !
D'ailleurs une classe avatar et un peu bizarre...

il faut regarder les dépendances (oui, tu aimes pas, mais c'est normal pour moi)....
ex: représentation d'un class humain
tu pourrais avoir 2 enfants => femme vs homme
donc femme et homme dépend de humain
soit humain->femme et humain ->homme...

Quand tu gères des fichiers, c'est une class fichier (non avatar) ou tu trouves id, nom, extension, chemin......
donc si membre fait référence à un fichier, il est normal d'avoir pour moi une liaison..., c'est une alternative bien sur (abus même).
plutôt que de faire $user->avatar(); ça sera $user->fichier()->name();
Car avec fichier, tu pourras tout avoir...

pour les commentaires, il n'y aurait que membre en référence...
Après idArticle suffit...

Ensuite, les includes, c'est assez rapide avec php, si tu mais un accélérateur php...
Et attention, POO c'est une structuration des données pour facilité l'update par une équipe !
Chacun peut travailler sur une tâche, c'est un gain de temps énorme !

Mais niveau ressource... vu les machines de maintenant... cet aspect est pratiquement négligeable...
Après il faut faire attention au traitement... ta des astuces comme la mise en cache de méthode...
Ex
public get ($var){
if (isset($this->var[$var]))
return $$this->var[$var];

///sinon traitement///
}

Dans tous les cas, je trouve la POO super quand tu métrises, au début tu galères un peu, mais après ... :)
 
WRInaute accro
Arf je suis totalement embrouillé :)

Qu'entends tu par l'objet existe toujours? parle tu d'objets persistants? Qu'est-ce exactement? Je dois avoué ne pas avoir bien compris le concept après avoir effectué des recherche sur le net et dans les bouquins. D'ailleurs ca a l'air également étroitement lié avec les ORMs

Attribut avatar ou upload, j'arrive pas a voir la différence. sachant que mon attribut avatar serait une variable objet de la class Avatar
J’imagine que dans ton exemple tu as en fait une table fichier qui contient les champs que tu as intégré dans ta class Fichier non?
Si dans mon cas le seul fichier (nom de fichier) que je stocke dans la bdd c'est l'avatar et que j'ai une table t_avatar avec comme champ: id_avatar et avatar (correspondant au nom de l'image), ca revient au même?
Je pourrais avoir une class Avatar et également une class AvatarsManagers pour gérer l'ajout, la modification et la suppression d'avatars.
Dans ce cas là que je mette un objet Fichier dans la class Membre ou un objet Avatar ca revient au même? a moins que je n'ai strictement rien compris ce qui est fort possible :oops:

C’est vraiment pas facile de penser objet quand on a pas l'habitude. Soit disant la POO est plus naturelel d'un point de vue raisonnement :? c’est peut être a cause de mes vielles habitudes de programmation

Tiens d'ailleurs ces exemples de Class me surprennent un peu :

Class Animal

Class Chien extends Animal

Class Chat extends Animal

Je trouve ça étonnant d'avoir a créer autant de Class qu'il y a d'animaux, ça en fait du fichier et du code :/
La aussi il doit y avoir un truc qui m'échappe.

J’imagine un Zoo qui d'un coup doit ajouter 2 -3 espèces, cela veut dire qu'ils doivent ajouter directement dans leur code source 2-3 Class, avec des caractéristiques qui leurs sont propres, et les gérer dans tout leur code


Pour la class Commentaire, qu'entends tu par il n'y aurait que membres en référence? Tu veux dire qu'il n'y aurait qu'un Objet membre dans la class Commentaire?
Et pourquoi ca ne serait pas la même chose pour l'article? Pourquoi n'y aurait-il pas un objet Article dans la class Membre? parceque l'Article n'appartient pas vraiment au Membre, c’est ça? :mrgreen:

Alors que l'avatar appartient bien au membre d'ou la possibilité éventuellement d'ajouter un objet Fichier ou Avatar dans la class Membre?

Pour les include le problème ne vient pas forcément de la vitesse d’accès aux données du PHP, mais plus un problème de hits. Sur les hébergement mutualisés les hits sont limités :wink: En tout cas chez OVH

Par contre je ne connaissait pas la mise en cache de méthode, faudrait que je me penche également sur le sujet.

Oui c’est clair au début on galère grave je confirmes.
je pense faire un truc plutôt hybride pour le moment, mi objet mi molette ;) et j’améliorerais mon compte dans le temps. J'ai déjà fait un semi MVC (pas de contrôleur frontal : je me sens pas à l'aise avec le routage et l'url rewriting) je suis plus à ça près lol

L'important c'est qu'à l’arrivée les sites fonctionnent (enfin je pense) :mrgreen:
 
WRInaute occasionnel
On va dire que la POO en php et assez jeune même si cela fait des années que ça existe...
Peut être devrais-tu lire d'autre tuto sur le C par exemple...
Non pas pour apprendre, mais voir le fonctionnement.

J'ai commencé comme toi, procédural, mi-objet mi-poo et full POO et je découvre encore des techniques.
Le tout est de pratiquer.

Ensuite je parle de design patterns, des modélisations qui facilite le développement :)
Ex pour les BdD, le mieux est de garder la connexion ouverte tout le temps et pas a chaque appel de requête.

Ou encore, si tu utilises une class pour parse des paramètres que tu placerais dans un fichier.
Si tu veux tel paramètre, tu dois faire $param->get(NOM_PARAM);
->Get étant la fonction qui parse tes éléments. Tu dois donc trouver un moyen pour parse 1 fois, et apps à chaque appel.
Donc une pseudo mise en cache d'une variable. Un objet reste un objet :)

POO tout n'est qu'objet.
Class Animal
Class Chien extends Animal
Class Chat extends Animal

Tu es bien d'accord qu'un animal peut être un chien ou chat.
Donc chien et chat sont des enfants de animal.
Soit tu pourras dire, un annimal peux prétendre a tel méthod abstraite (ex:yeux, pattes...)
donc l'enfant devra avoir ces méthodes mais qui peuvent agir différemment...
C'est de la logique... mais pour expliqué...

Mais l'avantage est que pour une catégorie donné d'animal, tu peux intervenir ou faire ce que tu veux dessus.
Après ce n'est que des exemples, le mieux est de voir des exemples concrets... car si tu représentes la chose en BdD pour un Zoo, tu n'auras pas la même chose je pense, la gestion sera différente suivant les besoins ;)
La c'est pour montré l'héritage voir les interactions et dépendances.

comme pour un application.
tu vas avoir une class app background qui fera la liaison avec toute ton application et tu feras appel à d'autre class enfant comme application, backcontroller.... Le reste étant externe.

Pour ton avatar, il est un peu dommage d'utilisé une BdD que pour les avatars, quand tu peux gérer tous tes fichiers avec une seul et même base... après tout dépend de l'architecture et de ce que tu as besoin en effet.
Le tout est de comprendre ta jointure.
un membre fait référence à un fichier(avatar)... donc en php, class membre fait référence ou plutôt liaison avec fichier. (Logique non :) )

Pour tes commentaires, c'est indépendant pour moi.
Article -> membre ou plusieurs si tu fais du communautaire
commentaire (id_article pas besoin de jointure) -> membre unique
pas d'article dans membre, car c'est l'article qui a besoin d'un membre, pas le contraire ;)
objet article fait référence à un auteur (membre)

Je pense que pour des mutualisés, le problème c'est surtout les requêtes avec la BdD qui va poser problème. S'il y en a beaucoup et pas optimisé (avec l'exemple du dessus par ex, si tu ouvres une connexion à chaque fois, ou si tu ne clôtures pas une requête.).
La gestion fichier et assez rapide pour posé problème... surtout au début avec peu de visiteur...
Quand tu en auras 100 en instantané, tu pourras dire, vive le dédier ;)
Mais je pense que tu as de la marge :)
Puis tu as les caches html, ou requête sql...
Bref l'optimisation, peut être partout et fait simplement avec l'objet :)

Après fait ton système mais regarde et tente de comprendre symfony, cakephp...
Pour des approches plus général et d'autre façon de faire comme avec les routeurs, firewall...

Bon c'est la fin de la semaine, normal qu'on galère ;)
 
WRInaute accro
J'ai appris le C, C++, le Java etc. durant mes études, j'avais donc appris aussi le langage objet, mais n'ayant jamais pratiqué la POO, je suis resté avec des acquis du procedural (c'ets ce que je comprenais le mieux) durant de nombreuses années. Donc j'essaye de me mettre a jour en lisant beaucoup pour le moment (livres, sites) mais une fois sur le terrain, alors qu'on croit avoir comprit, on se rend vite compte qu'en faite il n'en est rien :mrgreen:

Et je n'ai encore pas trouvé de livres ou sites qui partent d'une BDD relationnelle (avec un exemple concret) pour développer derrière en POO. En gros de vrais exmeples concrets. Ou alors ca part dans l’extrême et ça devient très vite complexe (mini framework personnalisé)
On voit quasiment toujours les mêmes exemples de bases ou de la théorie assez facile àa comprendre.

idem pour les design patterns, j'ai également pas mal lu sur le sujet. J'ai compris par exemple le singleton etc.
Après j'ai du mal a trouver une bonne raison de les utiliser.
Exmeple pour le singleton, ca semble souvent utilisé pour une connexion a la BDD pour permettre de se connecter a la BDD une seule fois et pas a chaque fois qu'on instancie une class qui fait appel a la BDD. Pour moi un simple passage de l'objet PDO (créé une seule fois a chaque début de script) dans le constructeur et son stockage dans un attribut private me suffit.


pour l’exemple de la class animal et les class filles chien, chat etc. je comprend très bien le principe. mais je doute que dans la pratique c’est le genre de class que l'on met en place. J'imagine qu'il est préférable de mettre en place des class plus généralistes. Le but n'est surement pas d'avoir a créer des class a chaque fois qu'on ajoute un animal sur son site :mrgreen:

Je comprend très bien le raisonnement pour l'héritage. On doit toujours se poser la question : B est bien un A.
Un chien est bien un animal.

Mais la idem dans un cas concret pour un site d'information par exemple (avec dossiers, blog, espace membre, gestion de commentaires etc.) j'ai déjà beaucoup plus de mal a trouver une raison d'utiliser l'héritage ou du moins a le mettre en place.

oui ton exemple de la class background etc. me semble plus logique pour utiliser l’héritage que l'exmeple de l'anima,l c’est des class qui reste fixs dans le temps une fois mis en place. Mais la idem je ne suis pas encore au point de faire mon propre mini framework, mais j'essaye au moins d'avoir un code le plus propre possible (et réutilisable assez facilement), du moins par rapport a mon ancienne façon de coder :oops:

Concernant l'avatar, oui je comprend, je mettais également posé la question de savoir si je stockais tous les noms des images que j'upload en BDD ou non, puis j'ai fini par en tirer la conclusion que ça ne serait pas la peine, j'ai donc opté uniquement pour l'avatar afin de pouvoir les modérer plus facilement.

Pour le moment j'ai surtout utilisé le cache HTML, je n'ai pas contre jamais utilisé le cache des requêtes sql (c’est simple a mettre en place? suffit de mettre SQL_CACHE dans notre requete? ) ou l’accélérateur PHP .

Oui c’est prévu une fois que mes projets seront en place (je sais je fonctionne a l'envers par manque de temps :mrgreen: ) de regarder cakephp, symphony et même wordpress.

je vais essayer de pas rester sur des acquis erreurs que j'ai faites depuis des années et qui me joue des tords maintenant :wink:

Mon soucis actuel c'est que je veux essayer de faire un truc nickel et vite alors que je n'ai pas pratiqué depuis longtemps, et que j'ai beaucoup a ré-apprendre, voir apprendre.
 
WRInaute occasionnel
Re, retour de week réponse ;)

Pour ce qui est des cours, je peux pas vraiment t'aider.
Je suis autodidacte et je sors de master qualité chimie, donc rien a voir ^^
J'ai appris sur le tas, et j'ai toujours codé mes propres script.
ça permet de comprendre plus facilement, de coder plus vite, ce poser les bonnes questions (optimisation...)
Puis en cas de bug, tu peux facilement intervenir.
Je te rassure, depuis 2009, la programmation est devenu mon métier :p

Donc, je dirai qu'il n'y a pas vraiment de protocole pour apprendre, n'y même de façon de faire.
Tout dépend de ton projet et de ton raisonnement...
Puis c'est en pratiquant que tu découvres un peu le tout.

Après ton framework peut évolué en fonction du temps...
Le tout est de rester logique, et de faire en sorte tout prévoir.
Même si tu perds un peu de temps, le but est de ne pas toujours revenir en arrière.
Surtout niveau structuration des données en BdD par exemple, ou la structure de ton site web.
Le code pourra évoluer sans impacter le site ou l'application.

Pour un site, tu pourras avoir un héritage.
Mais sa dépendra une fois de plus du projet.
EX:
- un site que tu veux dégrouper en différent module.
=> ta le module réf, puis des déclinaisons....
- un site de news et astuce
=> la base est la même l'article, mais tu peux mettre en place une fonctionnalité en plus.. ex un lien téléchargement... si tu pousse l'optimisation, tu vas dissocier les tables, donc le code...
Même avec un espace membre... tu as toujours une base propre, que tu peux évolué dans tous les sens héritages
humain => {femme; homme} => {femme => {enfant}; homme} l'exemple et bison mais pour le principe...
Je sais pas si tu comprends la logique.

Le tout est de construire un projet avec des briques modulables.
Il ne faut plus pensé tout est lier... mais comment je peux dissocier pour tout ré-imbriquer...
je t'avoue, j'ai mi du temps à comprendre également ^^
Et suivre la régle d'or : 2 lignes identiques, c'est que j'ai mal codé ;)

en gros sur un site, tu peux avoir des dossiers et articles, donc la base... 2 BdD
donc après suivant le noeud (rubrique vs article) tu pourras créer des interactions différentes... (design, contenu...)


Le mieux pour les images, tu mets en BdD tous les images et documents.
tu sauvegardes avec l'id.
Avec une catégorie avatar, tu peux les distinguer..
Cela permet d'avoir les infos directement (poid, taille, largeur, hauteur, nom, extesion)
tu pourras donc modifier ou supprimer plus facilement après ou faire des crop ou modifié les propriétés... comme l'url...

Ben niveau optimisation tu as plusieurs choses.
- d'abord le code, ici php, donc l'accélérateur va compiler plus vite (pour faire simple)
- Le cache niveau apache (mais pour l'utilisateur)
- cache html via php ou apache
- cache sql avec php (tu peux aussi mettre en cache via mysql)
.... et surement d'autre technique :)

Après tout dépend du traffic de la machine, du code, et ton savoir.
Des fois, c'est rapide, des fois tout plante ^^

je pense que tu devrais regarder des tutos uniquement pour les autres cms ou framework ;)
histoire de voir ce que font les autres et justement ne pas rester dans ta bulle ;)
wordpress, ce n'est pas vraiment de l'objet pure ;)
tu peux regarder dans l'ordre de facilité : CodeIgniter, cake php et symfo ;)
Il y a plein de truc sympa à découvrir. ex les routes...


si besoin hésite pas ;)
Bon code
 
WRInaute accro
Je te remercies je regarderais tout ça :wink:

J'essaye effectivement de faire en sorte que j'ai le moins possible de doublon dans mon code, d'ailleurs c’est de cette façon qu'on se rend compte qu'indirectement on temps vers du MVC. Me reste a bien concevoir mes class, et a bien comprendre le front controller.

Mais ca reste assez complexe quand on a de mauvaises habitudes, Le soucis c’est que j'attaque directement des sites importants et que je veux bien faire. malheureusement il aurait fallu que je prenne le temps de me faire la main avec plusieurs sites bidons. je veux comprendre voir maitriser en quelques mois le MVC, la POO, le RWD etc. Ca fait un poil bcp :mrgreen:

La seule chose qui me reste a faire c'est de prévoir d'éventuelles améliorations du code même si pour le moment je ne fait pas du FULL MVC et POO. Je ne voix que ça. :)

Après l'important c’est que les sites fonctionnent et qu'on est donné le meilleur de sois même :mrgreen:
 
WRInaute occasionnel
En quelques mois, ça fait juste en effet...
C'est surtout la perte des anciennes habitudes qui est dure à tuer ^^
Mais bon un outil évolue toujours ;)

Le principal est de ne pas rester bloqué, de finir le projet et de revenir par petite dose pour que le noyaux soit 100% nickel :)
 
Discussions similaires
Haut