Bonjour,

Etant complètement un inculte de la POO je voudrais quand même m'y mettre un peu...
Ce que j'ai retenu en gros :

- Un objet doit être générique
- On va du gros vers le détail

Donc pour cet objet fichier je me suis dit : Un fichier c'est quoi ? C'est un document physique sur un serveur... Déjà premier doute : Peut-on considérer un repertoire comme un fichier ? Question quand même utille puisque je voudrais pouvoir lister un dossier. N'ayant pas la réponse j'ai laissé ça de côté.

Voilà en gros à quoi ressemblerais ce début d'objet :

class fichier
{
	private $nom, $type, $poid, $DateCreation, $DateModification;
	public function __construct()
	{
		$this->nom = NULL;
		$this->type = NULL;
		$this->poid = NULL;
		$this->DateCreation = NULL;
		$this->DateModification = NULL;
	}
	// Méthode suppression
}
class FichierTexte extends fichier
{
	// Méthode lecture
	// Méthode écriture
}

Voilà je sais pas si pour l'instant mon raisonement est bon :

- On a les attributs de base d'un fichier comme le nom, le poid, etc...
- La méthode de suppression, qui quel que soit le fichier se déroule de façon identique

Mais pour la lecture d'un fichier ou sont écriture cela peut varier.
Voilà pourquoi j'ai créé une sous classe pour les fichiers de type texte ( qui peuvent être aussi HTML, PHP ect... )

Après on peut avoir une autre sous classe pour les fichiers XML par exemple dont les méthode d'écriture et de lecture sont differentes d'un fichier texte.

J'ai juste pour l'instant ?
Merci d'avance

à mon humble avis la programmation objet présente un certains nombres de désavantages:

-lourdeur et pertes de perfs
-perte en maintenabilité quand la logique appliquée n'est pas assez uniforme

ton exemple en soi n'est pas mauvais du point de vue conceptuel déja c'est un bon point, en revanche je ne pense pas qu'il y ai un réel besoin d'exprimer un fichier (ou répertoire) en tant qu'objet dans le code d'une application, l'objet en php est plus utile pour exprimer les contraintes métier de l'application. De plus si tu crée une instance de ton objet par fichier et que tu fais beaucoup de traitement d'objet (afficher le contenu d'un répertoire par exemple) tu va considérablement alourdir la charge système. Il faut toujours garder à l'esprit que la programmation objet est un outil et non pas une obligation.

En espérant que ça t'aidera, notes bien que c'est mon avis personel sur la question beaucoup de dévelopeurs te diront sans doute le contraire, en avançant que les systèmes actuels disposent de bazilions de rams et que c'est correct de faire du tout objet, pour ma part je crois que l'équation n'a pas à prendre en compte les capacités du système, ce qui compte c'est que le code ne soit pas alourdi inutilement parcequ'en fin de compte si l'appli est très utilisée plus de personnes pouront l'utiliser avant que la charge maximale du système ne soit ateinte.

Il faut regarder un tout. Dans le développement d'une application, ce qui est perdu en performances est gagné et maintenabilité. On pourrait croire que cela n'a rien à voir mais l'unité de mesure est exactement la même : l'euro...
A savoir qu'en entreprise, un serveur 20 à 50% plus performant, pour répondre à la surcharge produite par un développement objet, ne sera pas hors de prix. Alors que la nécessité de passer deux à dix fois plus de temps pour modifier un comportement simple (stocker des données en base plutôt qu'en fichiers par exemple), cela coûte très cher en ressources humaines. Je connais ton opinion sur la "lisibilité" immédiate d'un code procédural mais dans la mesure où tout un pan de mon stage porte sur ce sujet, je sais pertinamment que si le code avait été structuré correctement, j'aurais déjà complètement terminé cette partie alors qu'actuellement on se demande encore comment on va gérer cela...

je crois qu'il faut arrêter d'avoir le réflexe code procédural = code crade, c'est aussi vrai que de dire code php = code crade. Pour avoir codé des intranet en procédural et en objet je peut te dire qu'il n'y a guère de différence tant que le développeur fait gaffe. Faire de l'objet pour faire de l'objet est un mauvais choix technologique il faut avoir des raisons et mixer le procédural et l'objet au besoin.

Le pauvre supercanard qui voulait juste:

quand même m'y mettre un peu

à relancé un débat sans fin. Oui l'Objet n'est pas incontournable mais c'est quand même l'avenir (voir le présent) de la programmation pro. En caricaturant, pour développer seul un site relativement simple pas besoin d'objet, par contre pour développer une appli de grande envergure ou plusieur développeurs travail en même temps et qui devra etre documenté, maintenu et qui est suceptible de beaucoup évoluer je ne pense pas que le procédurale soit un choix judicieux...

Mais bon chacun développe selon ses contraintes et goûts, alors "pleeeeeeeease" ne cherchez pas à inciter tout le monde à faire de l'objet sans en comprendre l'interet mais ne les découragez pas non plus de s'y former parce que ca ne leur est pas nécessaire sur le moment.

Il en vas de même avec tout les concepts plus ou moins récent de framework, MCV et autre qui apporte beaucoup pour les gros dev en therme de lisibilité, maintenabilité, sécurité et tout ce que vous voulez mais ne sont pas toujours nécessaire.

Pour résumé faut informer, pas faire de la propagande .



PS: Nagol, Sékiltoyai je dit pas ca pour vous mais parce que ce genre de sujet dérive souvent comme ca

PS2:supercanard: - Je croit qu'en effet tu a bien saisie la structure des class et le concept de l'extends
- Pour ce qui est du rep qui est un dossier ou non si je ne me trompe pas ca dépend de l'OS c'est a vérifier mais je croit que sous linux tout est fichier alors que pour les autre OS ce n'est pas le cas mais c'est a confirmer.

mais je croit que sous linux tout est fichier alors que pour les autre OS ce n'est pas le cas mais c'est a confirmer.

Sous Unix, tout est fichier, nuance, sous les autres en effet (à savoir Windows), c'est faux. Je crois qu'il est plus correct du coup de dire que seul sous Windows, un dossier n'est pas un fichier...

Merci à tous =)

Le débat était intéressant, ça ne me gène pas du tout dailleur que ça parte en débat, tant mieux je dirais même.

Quelques précisions quand même :
En fait je ne veut pas me mettre à la POO sans raison.
Le procédural me vas très bien mais je vais être amené à travailler sur des projets développé en POO dans ma boite, c'est donc inévitable que je commence m'y intéresser.
Mais je suis accord avec les réactions d'un peu tout le monde.
Et sinon pour cet exemple, peut être que faire un objet pour gérer des fichier n'est pas nécessaire, mais je vois surtout l'avantage de pouvoir réutiliser cette classe au besoin et d'étendre ces possibilités au fur à mesure.

@vince_weed : Ah merci pour l'info sur les rep je ne savais pas. Finalement je me disais quand même que j'allais séparer fichier / dossier

Je penses que l'idée est bonne, ça aura pour but de "classer" les fonctions, on pourrait faire de même pour les tableaux, biensûr, la perte de performance est présente, comme dis le proverbe : "voulez-vous perdre du temps ou de l'argent", je préfert la POO, mais, et c'est un avis personnel, pour limiter la perte de performance, coder tout ça en C/C++...

Ca sort un peu du cadre, je sais...

par contre pour développer une appli de grande envergure ou plusieur développeurs travail en même temps et qui devra etre documenté, maintenu et qui est suceptible de beaucoup évoluer je ne pense pas que le procédurale soit un choix judicieux...

je vois pas le soucis, tout est affaire de qualité d'organisation du code. rien ne t'empeche de remplacer les fichiers de classes par des équivalent remplis de fonctions par exemple.

pour ce qui est du futur ou du présent les termes sont extremement mals choisis, il s'agit je le redis d'un tool qu'on l'utilise ou pas, ce n'est jamais un besoin.

Je crois que pour resumer :

Ce n'est pas une obligation de coder en POO, mais si l'on est contraint un jour de toucher à un projet codé de cette manière, il faut pouvoir s'adapter.

oui
le plus dur à mon avis c'est de se soucier plus de la qualité du résultat final que de ses propres préférences, parfois ce genre de logique marche parfois ça ne marche pas.

Question quand même utille puisque je voudrais pouvoir lister un dossier

Si tu veux lister un dossier il me semble que tu auras à un moment donné besoin de son arborescence donc d'un chemin absolu ou relatif.

Soit ton objet = un fichier auquel cas c'est un des attributs de ton objet soit tu auras besoin d'un objet pour manier des collection de fichier (plusieurs occurance de ton objet) mais je te le conseil pas pour débuter.

Saeveas, je ne fait pas te cacher que je n'ai pas vraiment tout compris.

J'ai déjà commencé un peu du concret, mais bon à mon avis il y a des choses à redire. J'espère quand même ne pas avoir tout faux de A à Z... :

<?php
class repertoire
{
	public $rep;
	public $ListeFichiers;
	public function __construct( $rep )
	{
		$this->rep = $rep;
		$this->ListeFichiers = array();
	}
	public function InfosRep()
	{
	}
	public function ListerRep()
	{
		$dh = opendir( $this->rep );
		while( $f = readdir( $dh ) )
		{
			if ( is_file( $f ) )
			{
				array_push( $this->ListeFichiers, $f );
			}
		}
		//print_r( $this->ListeFichiers );
	}
}

class fichier
{
	public $nom, $poids, $DerniereModif, $donnees;
	public function __construct($f)
	{
		$this->nom = $f;
		$this->poids = round( filesize( $f ) / 1000 );
		$this->DerniereModif = filemtime( $f );
		$this->donnees = NULL;
	}
	// Méthode suppression de fichier à rajouter
}
class FichierTexte extends fichier
{
	public function LireFichier( $url )
	{
		if ( file_exists( $url ) )
		{
			$fichier = fopen( $url, 'r' );
			$this->donnees = fread( $fichier, filesize( $url ) );
			fclose ( $fichier );
		}
	}
	public function EcrireFichier( $donnees )
	{
		$fichier = fopen( $this->nom, 'w+' );
		fwrite( $fichier, $donnees );
	}
}
echo '---------- On liste un repertoire et on affiche ce que l\'on trouve dedans<br>';
$rep1 = new repertoire( 'class_fichier/' );
$rep1->ListerRep();
echo 'Objet repertoire ( construct ) : '.$rep1->rep.'<br>';
foreach( $rep1->ListeFichiers as $f )
{
	$fichier = new FichierTexte( $f );
	$fichier->LireFichier( $rep1->rep.$fichier->nom );
	echo 'Objet fichier ( ListerFichiers ) : '.$fichier->nom.' '.$fichier->poids.' '.$fichier->DerniereModif.'<br>';
	echo 'Objet fichier ( LireFichier ) : '.$fichier->donnees.'<br>';
}
echo '---------- On créé ou on écrase le fichier et on affiche son filemtime<br>';
$fichier2 = new FichierTexte( 'class_fichier/toto.htm' );
$fichier2->EcrireFichier( 'oooooooooooooooooooooooooooo' );
echo 'Objet fichier2 ( construct ) :'.$fichier2->DerniereModif;
?>

Cet exemple exécuté m'affiche donc cela :

---------- On liste un repertoire et on affiche ce que l'on trouve dedans
Objet repertoire ( construct ) : class_fichier/
Objet fichier ( ListerFichiers ) : toto.htm 0 1217537932
Objet fichier ( LireFichier ) : oooooooooooooooooooooooooooo
---------- On créé ou on écrase le fichier et on affiche son filemtime
Objet fichier2 ( construct ) :1217538556

Ce dont je parlais c'est justement ce que tu as fait, un objet qui gère un ensemble. tu l'as fait sous forme de liste via un array. C'est un bon début, tu entendras dire qu'il faut faire comme ci ou comme ca mais la POO pour un langage orienté web n'a pas pour but d'être aussi strict que pour du logiciel.
Tu verras de toi même des amélioration ou d'autre façon de faire, cela viendras avec le temps et de la pratique ^^

Par contre je me rend compte d'une erreur :

Je n'aurais pas du faire un if if_file, parce que après tout je devrais aussi pouvoir gérer les sous repertoire....
En fait si il faut bien un if is_file, mais aussi un else. Dans le premier cas je retourne un type "fichier" et dans le deuxième un type "repertoire".
Comme ça si dans mes résultat je trouve un type "repertoire" je peut le lister à son tour.

Mais je ne sais pas si ce serais bien "propre" de retourner un tableau du style ? :
$fichier = array('nom' => 'toto.htm, 'type' => 'fichier ( ou dossier )' );