Hum, je m'en vais = return null et en parrallèle, je goto LePlusLoinPossible. D'ailleurs, en l'absence de return, PHP return null par défaut
Je vois pas trop la différence entre le vous et le te... Puisqu'au milieu du vous, il y avait le te?!
D'ailleurs, les cellules biologiques sont en "vous", elles ne s'adressent pas directement à une autre cellule précise.
Pour l'uploader:
Ce qu'on veut:
• Sélectionner un dossier pour l'uploader dans le logiciel
• Lors de l'upload d'un dossier, n'uploader que les fichiers validés
• Un fichier est validé s'il s'agit d'un PDF, d'un DXF, ou d'un DWG
Conditions supplémentaires tombées à postériori (ben oui, en environnement industriel, les mecs changent souvent d'avis >.<)
• Chaque fichier va être rattaché à une structure de nom précise, qui indiquera dans quelle catégorie uploader le fichier ("NumeroDeCategorie_Dateyyyy-mm-dd_Revision_NomQuelconque.extension")
• Si j'upload deux PDF pour la même catégorie et révision, ils ne sont pas validés (aucun n'est uploadé, un message me le dit)
• Un DXF ou un DWG (nommé NumeroDeCategorie_NomQuelconque.dxf/dwg) ne peut être uploadé que si un PDF est uploadé pour cette catégorie
• Du coup, si un deux PDF sont uploadés pour une même catégorie (donc, ces deux PDF sont invalides), aucun DXF ni DWG n'est uploadable
Comment le faire (début d'esquisse):
Perso, en essayant East là dessus, j'ai vite terminé en un immonde sac de noeuds...
Parce qu'au fond, ce que je veux, c'est savoir si le fichier est un PDF, et je fais confiance à File via isPdf pour me le dire... Ca me semble bien suffisant comme approche, cela respecte la notion de message et de boite noire (okay, cela requiert que l'appelant sache que l'appelé reconnait le message isPdf, sans argument), sans pour autant être sur-poussé au East.
Je vois bien que East oblige aux messages, mais l'OOP classique (là encore, sans voir les getter/setter comme des écraseurs/lecteurs d'attribut) me semble satisfaire à la même chose. En fait j'ai l'impression que tu refais, au niveau utilisateur du langage, ce que le langage lui-même fait déjà.
D'ailleurs, je ne suis pas d'accord avec The thing about messaging is data becomes irrelevant.: quand on envoie le message vers son destinataire, les data s'y trouvent (final string DirectorName). De même, public Movie[] moviesDirectedBy(String arg), pour moi, c'est "je veux la liste des Movie pour un réalisateur (et sous forme d'un array, là, on passe à coté du I de SOLID), et je te fais confiance pour me la donner". C'est bien du what, pas du how.
Ah au fait: en East, ta callstack va finir par creuver les plafonds, non, puisqu'il n'y a pas de retour possible vers l'appelant?
Je vois pas trop la différence entre le vous et le te... Puisqu'au milieu du vous, il y avait le te?!
D'ailleurs, les cellules biologiques sont en "vous", elles ne s'adressent pas directement à une autre cellule précise.
Pour l'uploader:
Ce qu'on veut:
• Sélectionner un dossier pour l'uploader dans le logiciel
• Lors de l'upload d'un dossier, n'uploader que les fichiers validés
• Un fichier est validé s'il s'agit d'un PDF, d'un DXF, ou d'un DWG
Conditions supplémentaires tombées à postériori (ben oui, en environnement industriel, les mecs changent souvent d'avis >.<)
• Chaque fichier va être rattaché à une structure de nom précise, qui indiquera dans quelle catégorie uploader le fichier ("NumeroDeCategorie_Dateyyyy-mm-dd_Revision_NomQuelconque.extension")
• Si j'upload deux PDF pour la même catégorie et révision, ils ne sont pas validés (aucun n'est uploadé, un message me le dit)
• Un DXF ou un DWG (nommé NumeroDeCategorie_NomQuelconque.dxf/dwg) ne peut être uploadé que si un PDF est uploadé pour cette catégorie
• Du coup, si un deux PDF sont uploadés pour une même catégorie (donc, ces deux PDF sont invalides), aucun DXF ni DWG n'est uploadable
Comment le faire (début d'esquisse):
Code :
Class DirectoryUpload {
FileUploader[] FileUploaders;
File[] filesToUpload
uploadFolder(Directory dir) {
for file in dir.files do
for fileuploader in FileUploaders
fileupload->thereIsAFileToUpload(file, filesToUpload);
}
}
Class PDFUploader implements FileUploader {
thereIsAFileToUpload(File file, File[] files) {
if (File.isPdf()) // Bon, là, déjà, y'a du return, mais on fait comment sans return?
files.thereIsAValidFileToUpload(file);
}
}
Class DXFUploader implements FileUploader {
thereIsAFileToUpload(File file, File[] files) {
if (FileUploader.isThereAPdfForThisDxf(file)) // Et là, sans "getter", comment on fait?
files.thereIsAValidFileToUpload(file);
}
}
Perso, en essayant East là dessus, j'ai vite terminé en un immonde sac de noeuds...
Parce qu'au fond, ce que je veux, c'est savoir si le fichier est un PDF, et je fais confiance à File via isPdf pour me le dire... Ca me semble bien suffisant comme approche, cela respecte la notion de message et de boite noire (okay, cela requiert que l'appelant sache que l'appelé reconnait le message isPdf, sans argument), sans pour autant être sur-poussé au East.
Je vois bien que East oblige aux messages, mais l'OOP classique (là encore, sans voir les getter/setter comme des écraseurs/lecteurs d'attribut) me semble satisfaire à la même chose. En fait j'ai l'impression que tu refais, au niveau utilisateur du langage, ce que le langage lui-même fait déjà.
D'ailleurs, je ne suis pas d'accord avec The thing about messaging is data becomes irrelevant.: quand on envoie le message vers son destinataire, les data s'y trouvent (final string DirectorName). De même, public Movie[] moviesDirectedBy(String arg), pour moi, c'est "je veux la liste des Movie pour un réalisateur (et sous forme d'un array, là, on passe à coté du I de SOLID), et je te fais confiance pour me la donner". C'est bien du what, pas du how.
Ah au fait: en East, ta callstack va finir par creuver les plafonds, non, puisqu'il n'y a pas de retour possible vers l'appelant?