Discussion :

[Mr N.]

Où ça par référence ??

[sekaijin]

non la principale différence entre une fonction et une méthode c'est l'objet

en pseudo C

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
void rien () {
 return;
}

ceci est une fonction je n'ai besoin de rien pour m'en servir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
void main(argc, argv) {
  rien();
}

c'est ce programme marche sans problème car rien est une fonction

en pseudo C++

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class nulle {
  void rien() {
    retrun;
  }
}

ceci définit une classe avec une méthode rien
cette fois impossible d'utiliser la methode rien sans avoir un objet.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
void main(argc, argv) {
  rien();
}

ne marche pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void main(argc, argv) {
  moobjet new nulle();
  monojet.rien();
}

que la méthode retourne ou pas une valeur n'a rien a voir.

en pascal une fonction retourne une valeur un procédure non
en C il n'existe que des fonction et le type void pour ne rien retourner.

en php c'est comme en C sauf que tout fonction qui ne fait pas un return de quelque chose retourne implicitement null

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
function test(){
  ...;
}
function test(){
  ...;
  return;
}
function test(){
  ...;
  return null;
}

sont trois définitions exactement équivalentes


seules les méthodes statiques sont équivalentes à des fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class MyClass {
  static function myMethod () {
    ...;
  }
}
 
MyClass::myMethod () ;

se comporte comme si on avait défini la fonction suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 function MyClass::myMethod () {
  ...;
}
 
MyClass::myMethod () ;

l'usage se fait comme pour une fonction mais on bénéficie de l'héritage.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class MyClass1 {
  static function myMethod1 () {
    ...;
  }
}
 
class MyClass2 extends MyClass1 {
  static function myMethod2 () {
    ...;
  }
}
MyClass1::myMethod1 () ;
MyClass2::myMethod1 () ;
MyClass2::myMethod2 () ;

ces trois appels de fonction son correct

A+JYT

[nako]

ah, j'ai mal interprété alors ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$piece = piece_construit(); 
piece_bouge($piece, 25, 75); 
piece_affiche($piece); 
piece_detruit($piece);

Les 3 fonctions ne modifient pas la variable ?
ah ben non, peut-être pas.
Où sont les attributs de $piece ?
en variable dans le même fichier ?
Donc en fait, on modifie les variables (les attributs) mais pas "réellement" la variable $piece ? c'est ça la subtilité ?
Ok, je comprend, donc oui, ok pour ça.
En effet, le seul intérêt de l'objet dans un développement comme celuii-ci serait alors l'héritage ?

[Mr N.]

ah, j'ai mal interprété alors ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$piece = piece_construit(); 
piece_bouge($piece, 25, 75); 
piece_affiche($piece); 
piece_detruit($piece);

Les 3 fonctions ne modifient pas la variable ?
ah ben non, peut-être pas.

peut-etre que si en fait, ca dépend de la signature des fonctions

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

function pa(&$piece) {...

[Mr N.]

Où sont les attributs de $piece ?

$piece peut etre un tableau avec ces attributs en clés associatives

[nako]

Où sont les attributs de $piece ?

$piece peut etre un tableau avec ces attributs en clés associatives

C'est quand même un peu du bricolage tout ça, non ?
Enfin tout ça pour répondre à la question initiale qui est : quel est l'intérêt de l'objet, aux vues de tout ce qui est en train de se dire, je dirai que le gros avantage, c'est que c'est une méthodologie éprouvée depuis pas mal d'année, que si on peut l'utiliser et qu'on en sent le besoin, alors faisons le.

[Mr N.]

C'est tout a fait du bricolage et pour moi ca ne s'apparente pas vraiment à de l'objet. Chaqu'un son point de vue.
L'essentiel est de coder proprement afin d'avoir un code maintenable
par maintenable j'inclus lisible, évolutif, ...
Or il s'avère par ma petite expérience que les codes procéduraux demande une plus grande rigueur que les codes "objets" pour satisfaire ces critères.
Il s'avère aussi que les codes "objets" demande une plus grande rigueur que les codes procéduraux en terme de facilités de développement. On est un peu plus structuré, plus cadré et on a moins tendance à faire n'importe quoi. Avis ptout à fait subjectif bien entendu.

[siddh]

si php5, pas besoin de mettre le &, si pieces est un objet ca sera une reference

[Mr N.]

sauf que là justement la question était de faire du pseudo objet avec du code à l'ancienne.

D'ailleurs à ce propos qu'en est-il des passage par référence des types primitifs (array, int & co) sous php5 ?

[sanosuke85]

C'est tout a fait du bricolage et pour moi ca ne s'apparente pas vraiment à de l'objet. Chaqu'un son point de vue.
L'essentiel est de coder proprement afin d'avoir un code maintenable
par maintenable j'inclus lisible, évolutif, ...
Or il s'avère par ma petite expérience que les codes procéduraux demande une plus grande rigueur que les codes "objets" pour satisfaire ces critères.
Il s'avère aussi que les codes "objets" demande une plus grande rigueur que les codes procéduraux en terme de facilités de développement. On est un peu plus structuré, plus cadré et on a moins tendance à faire n'importe quoi. Avis ptout à fait subjectif bien entendu.

+1 là encore pour toi Le but reste toujours de produire quelque chose que quelqu'un d'autre puisse reprendre... Après chacun sa méthode pour que cela soit gérable (un code très sale mais bourré d'annotations ou un cahier technique - oui je sais déjà cité sur un autre post mais je pense que c'est vraiment important d'avoir ça en tête (avis personnel on se comprend))...

[siddh]

je suis d accord, l objet demande une plus grande rigueur et aussi une capacité a s'organiser.

L'intéret est surtout de pouvoir factoriser et reutiliser le code deja fais.

Quand tu te fais des fichiers avec des fonctions qui traitent a peu pres du meme sujet, tu fais presque de l aobjet sans le savoir.

par exemple, la personne qui se fais un fichier avec des fonctions pour lister des repertoires, des fichiers, les renommer, les supprimer, ....

C'est presque un objet, la demarche etant de mettre des fonctions relevant de la meme "responsabilité " ou du "meme metier" dans un objet fais pour.

[sanosuke85]

je suis d accord, l objet demande une plus grande rigueur et aussi une capacité a s'organiser.

L'intéret est surtout de pouvoir factoriser et reutiliser le code deja fais.

Quand tu te fais des fichiers avec des fonctions qui traitent a peu pres du meme sujet, tu fais presque de l aobjet sans le savoir.

par exemple, la personne qui se fais un fichier avec des fonctions pour lister des repertoires, des fichiers, les renommer, les supprimer, ....

C'est presque un objet, la demarche etant de mettre des fonctions relevant de la meme "responsabilité " ou du "meme metier" dans un objet fais pour.

Ah ! D'accord ! Là dessus on est donc un peu d'accord sur le fait que bien organiser ses parties de site avec des include() des fonctions etc c'est un peu dans la même méthodologie que l'objet

Le "un peu" étant mis bien sur en connaissance de cause

[siddh]

voila, le seul truc c'est que l objet t apporte des trucs en plus comme la possibilité d'hériter.

C'est comme si tu te fesais un fichier avec des fonctions de traitement pour les gifs par exemple et ensuite tu veux en faire un pour traiter les png.

Tu te fais un fichier ou tes fonctions savent gérer des images et les parties specifiques a chaque format tu les met dans d autres fichiers ou tu inclus ta partie generique.

Tu as une classe parente et deux dérivées en gros.

Mais la ou ca diffère, c'est que tu pourras, si tu le fais en objet, redefinir une de tes fonctions du fichier generique qui s'appliquera que pour les png par exemple.

Et il y a encore pleins d'autres concepts qui font que c est plus puissant que du "simple code" et que tu pourras reutiliser du code deja fais en le specialisant et l'adaptant.

[siddh]

D'ailleurs à ce propos qu'en est-il des passage par référence des types primitifs (array, int & co) sous php5 ?

alors pour les tableaux, je pense que ca doit etre des refs.
pour les autres c est par valeur.

C'est un modele objet tres proche de celui de java.

[sanosuke85]

Merci siddh je prends en note toutes tes remarques et réponses afin de les étudier plus en profondeur

(je voulais préciser pour que les gens sachent que quand je pose des questions ce n'est pas pour rien au contraire! )

[loufoque]

C'est quand même un peu du bricolage tout ça, non ?

C'est comme ça qu'on fait en C sauf qu'on utilise une structure à la place d'un tableau associatif.

[FFF]

J'ai parcouru ce thread avec attention.
Je débute en java, référence, d'après ce que j'ai pu en lire des langages orientés objet, et je trouve tout de même la programmation pure objet (utilisation récurante d'héritage, d'interface) relativement diffcile ! Ce que j'entends par difficile, ce n'est pas le fait d'utiliser des objets de l'api java (ici on n'a pas le choix d'utiliser l'héritage et ça se fait de façon naturelle) mais le fait d'organiser tout un programme de cette façon. Je viens de réaliser une application client serveur en java et je m'aperçois que je n'ai jamais utilisé la notion d'héritage (point fondamental de la prog objet) sur mes propres classe, mon prog ne s'y prète pas suffisamment, pourtant je suis sûr à en lire les exemples que c'est très util et très pratique !! mais concrètement la prog pure objet demande déjà bcp de rigueurs et je pense un certain recul sur l'application que l'on prog ce qui n'est pas forcément accessible aux débutants...
Qu'en pensez vous auriez vous des conseils à me donner pour "penser programmation objet" ? (bouquins, exemples de petites application...)

[Fladnag]

pour ton application client/serveur, je suppose que tu as une classe "client" et une classe "serveur" non ?

n'y a t'il aucune methode presente dans les classes qui se ressemble fortement ? => peut etre pourrait tu creer une classe "acteur" qui contient cette methode et qui serait la classe mere de client et serveur

les objets echangés entre ton client et ton serveur pourrait aussi etres des classes. Dans ce cas là, tu pourrait avoir une classe mere (qui est la classe réellement echangée par tes classes clients/serveurs) et des sous classe pour spécialiser et différencier les objets.

A noter que si tu as des methodes qui se ressemblent par leur signature mais qui n'ont pas le meme contenu, tu peux aussi creer une interface plutot qu'une classe mere, ou encore une methode abstraite si tu as des methodes contenant le meme code, et d'autres methodes dont seule la signature est identique.

Les puristes diront que je préconise de faire du procédural et ensuite de voir comment on peut le transformer en objet... mais c'est un moyen facile pour un débutant de commencer a "penser" objet. Ensuite, il reflechira avant de coder si des elements de ses classes risquent d'etre commun et necessitent une interface/classe mere/classe abstraite.

[Mr N.]

JJe viens de réaliser une application client serveur en java et je m'aperçois que je n'ai jamais utilisé la notion d'héritage (point fondamental de la prog objet) sur mes propres classe, mon prog ne s'y prète pas suffisamment, pourtant je suis sûr à en lire les exemples que c'est très util et très pratique !!

Et alors ? ce n'est pas une obligation, surtout dans les "petites" applis ! Donc il n'y a pas de reproche à te faire de ce côté là. Après il faudrait voir exactement la structure de ton appli, mais on sort de php là

...
mais concrètement la prog pure objet demande déjà bcp de rigueurs et je pense un certain recul sur l'application que l'on prog ce qui n'est pas forcément accessible aux débutants...

*10 (pour changer)
Bien sur qu'il faut un recul sur l'application ! Et c'est d'ailleurs le but. On a pas 36 fonctions qui font un certain traitement, mais 5 objets qui interagissent... Le concept, l'approche sont différents. C'est généralement mieux, et généralement plus difficile au début, mais après c'est roulez jeunesses ! 8)

[mathieu]

je trouve tout de même la programmation pure objet (utilisation récurante d'héritage, d'interface) relativement diffcile

ce n'est pas difficile c'est impossible !
le "pur objet" n'existe pas, c'est pour ça qu'on parle de Programmation Orienté Objet