Reprise du message précédent :
Si tu n a aucun héritage, c est pas de la programmation objet, c est similaire à un script utilisant des arrays (concept, maintenance, performance).

mais qu'est ce que tu  veux que j'hérite quand j'ai un objet contenant des méthodes de stockage, d'analyse, et d'insertion dans une bdd, toutes utilisées dans le même script et uniquement dans celui-ci ^^
 
Et on a jamais dit que c'était mal de faire de l'héritage. Juste qu'on concevait pas nos classes en fonction d'un affichage.

C'est une blague?

ha oui j'aurais pu le dire comme ça aussi ^^

tu peux faire un objet sans héritage par contre il ne faut pas faire toute une application en objet sans qu'il y ait d'heritage. S'il y a heritage de façon liniaire ça ne sert à rien.

ah ? et pour quelle raison ? on va en enfer si jamais on fait ca ?

 
Conceptuellement, je vois pas ce qui l'empêcherais. Néanmoins, on sens que dans la vraie vie, ce type de cas ,'arrive jamais

Oui tu brulera dans les flammes du nawak .  
Dans le "il ne faut pas" je voulais dire par là que c'est null de dev ainsi et puis quand j'y pense en vb il y a pas de notion d'héritage  

L'héritage, il ne faut l'utiliser que quand on en a besoin.
Je ne vois pas l'intéret de rajouter un coup d'héritage juste pour dire "a oui, mais il en faut toujours un peu dans une application".
 
C'est vrai en général, on a toujours des éléments pouvant hérité d'une classe comune, mais il peut aussi arriver que ca ne soit pas le cas, notament dans les petites applications.

Oui je suis daccord avec toi. Il ne faut pas que cela devienne systematique. Je me rappelle a mes debut dans les mêmes periode que l'autre developpeur qui faisait une classes gros papa de 3 kilo  lignes (voir plus haut) . Dans la boite il y avait une idée qui était que une application en objet devait au final hérité d'une meme classe. En gros que c'était un arbre. Il peut y avoir une classe pour gérer les fichiers/repertoires et une classe qui gere les acces a une db ben si tu remontais les classes qu'elles héritaient il avait une classe commune au final alors que l'acces à la db et la gestion des fichiers n'ont pas de rapport. En gros les classes était forcement issus de la meme famille La reine quoi .
 

 
Pour ceux qui se pose la question de "a quel moment j'hérite" "a quel moment il y a message" il y a deux chose à ce dire :
Est un , A des.
 
Un repertoire est un fichier d'un type particulier : La classe Repertoire hérite de la classe fichier
Un repertoire a des fichiers : Il y a une liaison entre la classe Répertoire et la classe fichier. Néanmoin elle (repertoire) hérite toujours de la classe fichier.

 
C'est le cas en Java : toutes les classes héritent de Object. C'est logique puisque toute les classes ont en commun des mecanismes comme la serialisation, le GC, l'égalité ou la copie.
 
Par ailleurs, concernant les discussions plus haut, je ne vois pas le soucis à dire qu'une page est une classe. Une page est une vue, et une vue est une classe. Tout peut être representé par un objet : une personne, une voiture, une vue, une application, une connexion à la DB etc... L'utilisation des classes n'est pas restreinte à la logique métier. Encore heureux sinon le MVC n'existerait pas.

Même si ca se voit pas, il me semble qu'en php aussi tous les objets ont quelques comportements comuns tels que la sérialisation.
 

Faire un objet par vue en considérant qu'une page est une vue, c'est une chôse.
Faire tous les objets en fonction de l'affichage de chaque page au mépris des relations entre les données, s'en est une autre.
 
Au cours de la discution qu'il y a eu au dessus, j'ai eu l'impression qu'on était en présence du second cas et non pas du premier.

+1

 
Probablement
 

 
C'est pas vraiment ce que tu disais plus haut :

Une vue est un objet purement graphique qui a une raison d'être : c'est donc un objet. Les classes ne sont pas reservées à la logique métier.

Heuu non, en termes d'architecture MVC, les vues sont des éléments logiques, pas graphiques, ce sont les points d'entrée/sortie de l'application

 
"logique" oui mais pas "logique métier" : faut apprendre à lire les phrases en entier  

Je peux te retourner le compliment, omega2 parlait uniquement de logique, pas de logique métier
 
Et la première partie de ton post n'en est pas moins totalement fausse: une vue n'est en rien quelque chose de "totalement graphique"

Alors c'est omega qui raconte des conneries, pour moi un objet purement graphique c'est une image
 
Su tu veux t'amuser à jouer sur les mots, ça peut durer longtemps  

Faudrait savoir  

Ben voyons  

 
Je reprenais la formulation de omega, c'est trop dur à comprendre ? Ca me fait "delirer" ces mecs qui prennent une conversation en route sans lire le contexte.
 

 
Si tu veux t'amuser inutilement à jouer sur les mots, fais gaffe, je suis bien + fort que toi à ce petit jeu.

enfin bon, concevoir les objets de sa logique métier en fonction des pages affichées, je vois pas l'intérêt.
Après on a jamais dit qu'un objet ne pouvait pas gêrer une vue.

C'est très probable, mais faut encore que tu bosses sur la compréhension de texte

Ca c'est clair.

la prochaine fois que tu viens pourrir un thread, pense à le lire en entier avant...

Merci pour toutes ces réponses. Tout n'est pas clair, mais je vais essayer de voir ou je peux aller avec ça.
 
Une autre chose cependant, doit-on obligatoirement instancier la classe parent dans la classe enfant ?
 
Je serais tenté de répondre oui, car sinon on ne peut pas utiliser la classe parent. Mais alors cela ne revient-il pas au même de faire une seule classe car si il y a instanciation du parent dans l'enfant les deux classes sont chargé en mémoire, non ?
 
Ou est alors l'intéret de l'héritage, à part d'un point de vue d'organisation de fichier ?

Si tu instancier un class enfant le parent est là quand même et tu bénificies toujours de ses methodes et propriétés donc non c'est pas la peine.
Par contre si tu places quelque chose dans le constructeur de la class parent tu dois appeler cette fonction.  
Exemple
 

 
 
Sans Parent::Fichier(); le constructeur n'est pas executé dans les classes enfants.

Très PHP4 ... En php5, c'est quand même bien plus beau
Pour reprendre l'exemple de la doc:

Oui j'ai pas precisé que c'est en php 4
Mais pour en revenir à la question principal. Non tu n'as pas à instancier la classe mere.

Evidemment, quel co.., j'ai confondu l'instanciation et le constructeur. Merci.
 
P.S. Super ta signature. Le monde se divise en deux catégories ceux qui aiment les vrais films et ceux qui ont des gouts de chiot...

Toujours dans un objectif d'optimisation des classes, qu'est ce qui est le moins lourds en terme de ressource machine, créer une varibale membre rempli à l'initialisation pour stocker une valeur qu'on appel dans plusieurs méthodes ou utiliser un fonction pour calculer cette valeur à chaque appel.
 
Ex : pour utiliser le montant TTC d'une commande,
 
Solution 1 (variable membre) :

 
Solution 2 (fct de calcul) :  

Ca irait très bien dans une propriété (tu stockes le prix HT non?), mais pas dans une variable membre (ou alors il faut la mettre à jour à chaque maj du prix HT, c'est lourd). Et vu comment les propriétés fonctionnent en PHP, je dirais de passer par des getter/setter

Qu'entends-tu par propriété ?
 
pour ma part je ne connais que les variables local ou membre.
 
En gros j'ai deux 'schéma' d'utilisation, soit j'utilise le mode commande ou tous les prix sont calculer dynamiquement, soit j'utilise le mode état ou il ne s'agit que d'afficher des valeurs (sans calcul).

Ce sont des variables membres "virtuelles".
 
En fait, ça permet de cacher de petites fonctions derrière des appels de variables membres, genre ce genre de petits trucs à la con, mais c'est super mal fait en PHP donc c'est mort.  
(En ruby c'est bien mieux fait, je mettrais une petite démo en fin de post)

 
Exemple de propriétés en Ruby:
 
Imaginons que je crée une classe Item avec une variable membre prixHT, mais que je veuilles aussi pouvoir afficher son prix TTC (c'est 19.6 en france non?) ça va donner un truc comme ça:

class Item # je crée ma classe
    def initialize(prix_ht) # "constructeur" en Ruby, équivalent à __construct
        @prix_ht = prix_ht # le préfixe "@" indique une variable membre
    end
 
    def prix_ttc
        return @prix_ht * 1.196
    end
end

Et maintenant, je peux faire un truc du style

 
Ca permet de créer des "variables membres" calculées dynamiquement quand tu y accèdes quoi.

heu c'est comme les accesseur en vb, non ? je vois pas en quoi c'est mal fait en php à la différence c'est qu'avec ce derniere nous savons de suite que c'est une fonction pas possible de le déguiser en variable "screde"    
Dans la finalité cela revient à la meme chose à moin que j'ai loupé quelque chose.

Vas voir les méthodes magiques __get et __set

Ca me fait un peu mal au cul de mieux connaitre le langage que toi alors que je tente au possible de ne jamais l'utiliser

Désolé, mais perso je trouve beaucoup plus simple et lisible d'écrire

que

De plus ce genre de trucs permet de facilement modifier le comportement de l'objet sans changer son interface externe e.g. de transformer une variable membre publique (accessible) en propriété quand on se rend compte qu'il faut modifier l'implémentation.
 
L'absence de propriétés fait, par exemple, qu'en java ou en PHP si on veut pouvoir faire évoluer ses objets sur le long terme on est obligé de planquer tous les membres derrière des getters/setters inutiles et redondants.

Mais je ne remet pas en cause ce que tu dis et je m'en rend bien compte actuellement car je fais du c# et je me suis heurter à ce probleme le faite de passer par des accesseurs à chaque fois et qui fait qu'il y avait une certaine régidité. En java je savais que c'étais pas possible mais je ne pensais pas que ces tocards de chez m$ reprendrais la même chose.

Je m'étais toujours demandé pourquoi en delphi je voyais souvent des "pseudo variables" qui ne servaient qu'a appeller une fonction quand on lui affecte une valeur et à en appeller une autre quand on lui demande sa valeur.
Certe, le coup du "on poura modifier l'objet sans changer l'interface publique de l'objet" est alléchante, mais je me pose toujours la question suivante : a partir de quel moment est ce qu'on abuse de cette méthode là?

À partir du moment où les fonctions appelées ont un effet de bord important.
 
Les propriétés sont vues comme des variables membres, donc du point de vue de l'appelant elles ne doivent pas effectuer de trop gros trucs (pas de calculs qui font tomber la machine, rien qui prend 15 ans à s'exécuter, ...).
 
Après ça dépend aussi des langages, en Smalltalk (et en Ruby) les parenthèses pour appeler une méthode sont optionnelle donc les propriétés dérivent simplement de la syntaxe du langage, donc le point ci-dessus n'en est pas vraiment un, en Python (pour delphi je sais pas) ce sont des constructions séparées donc il tient

en delphi, tu définis tes deux fonctions et ensuite tu crés une propriété grace à la syntaxe :

 
EDIT : Les "...", c'est juste pour dire qu'on peut mettre plusieurs paramettres. Quand aux crochet, c'est la syntaxe du langage qui les demande. Ca ne veut pas dire que le contenu est optionel.

ok