Zut,

du coup, j'hésite ...

Note que c'est pas bête non plus … C'est plus un push qu'un pull, mais c'est pas bête.

classe CourrierFormulaire
{
  public static inputTitre(Courrier $o_courrier)
  {
    // Le code affichant l'input pour saisir le titre
  }

  public static inputCorps(Courrier $o_courrier)
  {
    // Le code affichant l'input pour saisir le corps
  }
}

Je verrais plus une classe comme ça

[php]classe CourrierFormulaire
{
public static inputTitre(Courrier $o_courrier)
{
// Le code affichant l'input pour saisir le titre
}

public static inputCorps(Courrier $o_courrier)
{
// Le code affichant l'input pour saisir le corps
}
}[/php]

J'en pense que c'est ce que j'ai dis au début ;-) (à quelque chose prêt).
Et je pense que ça répond aussi à ton problème.

Class Courrier {

// membres
private $form;
// méthodes

Public function GetMyForm();
  $this->form = new CourrierFormulaire($this);
}

Class CourrierFormulaire() {
  public function __construct($courrier) {
   // appeler toutes les méthodes internes pour chaque champ/propriété de courrier  
  // retourner l'objet
 }
 
}

Alors,

je commençais à penser un peu comme ça, en mettant une classe CourrierFormulaire. Problème : redéclarer chaque propriété de courrier. Du coup, je songe à ça :


[php]Class Courrier {

// membres
private $form;
// méthodes

Public function GetMyForm();
$this->form = new CourrierFormulaire($this);
}

Class CourrierFormulaire() {
public function __construct($courrier) {
// appeler toutes les méthodes internes pour chaque champ/propriété de courrier
// retourner l'objet
}

}[/php]


Vous en pensez quoi ?

C'est plus clair pour moi.

Et je vais persister dans ma voie ;)

Tu conserves ta classe Courrier qui contient tout les comportements métiers de ta classe (Traitement, sauvegarde, ...)
Et tu crées une classe CourrierFormulaire qui pourrait être statique (du moins chaque méthode serait statique) et qui prend l'objet courrier à chaque fois que tu veux utiliser une méthode, soit qui pourrait être instancée et qui prendrait un objet Courrier en attribut.
Et c'est cette seconde classe qui se chargerais de l'affichage des champs du formulaire.

Sachant que je pense que la classe statique qui prend l'objet à chaque appel me parait beaucoup plus propre.

[quote="zeus"]Bonjour,

Alors là ... j'ai pourtant compris la question ... mais maintenant que j'ai lu la réponse d'[b]Hywan[/b], je n'en suis plus sûr :?

Sinon, avant de noyer [b]mcorgnet[/b] sous la POO (même si je pense qu'il a pied ;) ), j'aurais envi de rester au niveau abstrait.
Si j'ai bien compris, tu as une notion (une classe) qui regroupe des comportements liés à la notion, et tu voudrais savoir où mettre des comportements tels que l'affichage du formulaire liés, ...

Selon moi, la présentation d'un objet ne doit pas être le travail de l'objet lui-même.
Que tu ais une classe qui contient le travail de présentation de l'objet, pourquoi pas, mais il ne faut pas mélanger la partie métier de la partie présentation ;)

Voilà, en espérant ne pas avoir répondu HS[/quote]

Disons que là, j'ai compris :d

Non, en fait, je veux déléguer certaines tâches, ne pas les faire directement dans ma classe. En gros, j'aurai une classe qui contiendra mes champs de formulaire pour mon objet A. Le problème, pour moi, en fait, c'est de lier mes deux classes.

En fait, je veux déléguer des tâches à d'autres classes.

Mon objet est un courrier.

$courrier = new Courrier();

Je peux lui définir des propriétés, et j'ai des méthodes pour bosser dans la BD.
Maintenant, je veux lui définir des champs de formulaire, parce que je les utilise souvent, dans différentes pages de mon programme. Donc, je songe à faire faire ce travail à autre chose qu'à la classe Courrier elle même. Là, je me suis dit : "délégation" ... Ce que j'essaie de savoir, c'est si il y a une manière précise de s'y prendre en php, ou s'il faut juste créer une méthode dans ma classe courrier, qui va instancier l'objet FormulaireCourrier, ou RechercheCourrier.

Mon but, c'est d'avoir un objet Courrier avec ses propriétés quand j'ai juste besoin de les définir et de les afficher. Ensuite, quand j'ai besoin de le modifier, je veux l'objet CourrierFormulaire, puisqu'à cet instant, j'ai besoin de ces propriétés. Pareil quand je veux rechercher ...

Pourquoi ?

Si je suis sur une page qui me permet de modifier, je ne veux pas accéder aux propriétés de recherche. De plus, ma recherche ne se fait pas sur toutes les propriétés.

En fait, en y réfléchissant, il me semble qu'il faudrait presque des délégations spécifiques :

mon objet courrier
une classe spécifique à cet objet pour les opérations de base de données
une classe spécifique pour les opérations de formulaire
une classe spécifique pour les opérations de recherche ...

Bref, question de concept, est-ce une bonne idée, et surtout : quelle est la meilleure méthode ?

J'arrive à être clair là ?

Mais d'après ce que tu me dis, tes objets n'ont pas de rapport entre eux, alors pourquoi en créer un ?

Et Zeus a raison en disant de ne pas mélanger la partie métier (modèle ou contrôleur) et présentation (vue).

Ca n'a pas l'air de correspondre à ce que j'ai ...

J'ai une classe A, qui, actuellement, fait ceci :

définition de ses propriétés
enregistrement en base de données

Je veux en plus :
définir des champs de formulaire pour cette classe
effectuer une recherche sur les propriétés

Je me suis laissé dire que le mieux, c'était de laisser d'autres classes faire ce travail. Je chercher juste la meilleure solution.

Bonjour,

Alors là ... j'ai pourtant compris la question ... mais maintenant que j'ai lu la réponse d'[b]Hywan[/b], je n'en suis plus sûr :?

Sinon, avant de noyer [b]mcorgnet[/b] sous la POO (même si je pense qu'il a pied ;) ), j'aurais envi de rester au niveau abstrait.
Si j'ai bien compris, tu as une notion (une classe) qui regroupe des comportements liés à la notion, et tu voudrais savoir où mettre des comportements tels que l'affichage du formulaire liés, ...

Selon moi, la présentation d'un objet ne doit pas être le travail de l'objet lui-même.
Que tu ais une classe qui contient le travail de présentation de l'objet, pourquoi pas, mais il ne faut pas mélanger la partie métier de la partie présentation ;)

Voilà, en espérant ne pas avoir répondu HS

Hey :),

Tu me dis si je trompe. Tu as un objet dans l'attribut d'un autre objet. Des classes héritent de l'objet qui contient l'objet. Hmm … On a un objet Handler qui est contenu (instancié) dans A. On a B, C et D qui hérite de A. Via un getter dans A, tu peux retrouver Handler et faire des opérations dessus.

Si tu veux que Handler soit remplaçable, pense au polymorphisme (classe abstraite, interface …).

Bonjour,

j'ai une classe qui travaille sur un objet, et j'ai différentes tâches à effectuer sur cet objet. J'aurais voulu, pour des questions de lisibilité, séparer les tâches en question dans d'autres classes.

Par exemple, je veux créer un formulaire spécifiquement pour cet objet, effectuer des recherches dessus également, je me disais qu'il pouvait être intéressant de déléguer à des classes spécifiques ...

Mais comment faire, en php, dans les grandes lignes ?

Merci à vous.