Discussion :

[labraise]

Bonjour à Tous,

J'ai une question théorique à vous soumettre.

Venant de VBA j'ai toujours fonctionné en Procédural, maintenant que je suis sur VB.net je suis intéressé par la POO mais je n'en vois pas l'intérêt fonctionnel.
Mais je suis victime de collègues qui ne jurent que par la programmation Objet et j'aimerais comprendre pourquoi

Prenons un exemple concret, volontairement simplifié

La majorité des applis que je développe tourne autour du principe suivant :
- un fichier excel "Source"(extract d'un ERP)
- une fichier Excel de mapping

En VB.net Procédural:

- j'ouvre le fichier Source, je colle dans un Array TAB_Source, je ferme le fichier excel
- idem avec le fichier de mapping = TAB_Mapping

- je redim preserve TAB_Source pour y ajouter les colonnes de mapping et d'analyse
- je mappe les infos de Mapping dans TAB_Source
- j'analyse les infos mappées pour calculer des statuts par ex.

- je colle le TAB_Source dans un fichier Excel que je sauvegarde



Je ne vois pas bien à quoi peux me servir de faire des classes pour réaliser les tâches décrites?
Pour le mapping? ou autres?
Je ne vais pas créer une classe pour mon fichier Source et créer une instance pour chq ligne, je pense que travailler dans un array est bcp plus rapide?


Si une bonne âme adepte de la POO peut en quelques mots simples m'expliquer quels sont les avantages dans mon cas précis.
Je suis prêt à changer d'avis si je me trompe mais à l'heure actuelle je ne comprends pas bien cette secte du tout objet qui veut éradiquer le procédural

merci pour vos réponses.

[wallace1]

Bonsoir ,

C'est un long débat et si tu es déjà réticent alors il est clair que je ne m'improviserai pas pasteur pour que tu rejoignes la communauté ...^____^

Voilà en sommes les raisons qui nous poussent vers ce concept (pas besoin de longs discours):

http://www.felixgers.de/teaching/oop/oop_intro.html


Ce qui m'a pousser à faire de la POO :

- avant toute chose, j'aime que tout soit rangé, contenant/contenu, attribuer des rôles à chaque élément, leurs interactions, ...etc......
- cette faculté à pouvoir découper un problème en plusieurs sous problème afin d'en faciliter la résolution
- la réutilisation de certaines classes dans d'autres projets. Un gain de temps considérable
- reprendre un projet derrière quelqu'un est un jeu d'enfant grâce à des librairies commentées, modifiables et réutilisables à souhait
- la maintenance du code est d'autant plus simple car le fait de modifier une portion n'impacte pas systématiquement que l'on doit tout reprendre de zéro !
- ....and so on......

........

Je souligne également qu'on n'instancie pas impérativement un objet depuis une classe et qu'il n'existe pas que ce genre de type, les structures, énumérations, etc...sont tout aussi utile que le reste.


Breffff la POO c'est comme l'évolution technologique, tu n'en ressent pas le besoin aujourd'hui mais quand tes enfants t'en parleront dans quelques années alors tu te sentiras complètement en marge de tout ce qui a pu se faire depuis ce temps........ A toi de voir..... car je ne suis pas la pour te convaincre mais juste là pour aiguiser ta curiosité.

PS : vivons avec notre temps.


A+

[labraise]

Bonsoir,

Merci pour ta réponse détaillée.

Je me suis surement mal exprimé mais je ne veux pas relancer un débat qui agitent les développeurs.
Je ne suis absolument pas réticent à évoluer bien au contraire. Je suis d'ailleurs en phase avec tous les arguments avancés : structure, facilité de maintenance, réutilisation d'un projet à un autre,...
J'ai d'ailleurs lu pas mal de bouquins sur la question et j'y vois un intérêt au niveau du code et du développement.

Mais mon problème est que pour les applications que je développe, majoritairement de la production de fichiers (agrégation de données et analyse), je ne vois pas comment utiliser la POO.

Dans l'exemple que j'ai donné : (volontairement simpliste)
un fichier Source mappé à partir d'un autre fichier pour produire un fichier final
je ne vois pas comment faire autrement qu'un procédural???


Si qqun peut en 4/5 lignes explicative me donner l'approche, je me ferais un plaisir d'essayer.
(je précise que je ne demande pas un code clefs en mains, au contraire même)

D'avance merci pour votre aide.

[Uranne-jimmy]

Bonjour,

Je travail beaucoup sur la conception de modèle Excel, qui a pour principe de trier des données de formulaires et de les organisés correctement, en rajoutant une partie de mapping. Je ne suis pas très très rigoureux sur l'utilisation de la programmation objet, je fais mon petit hybride personnel.

En gros pour excel, je me suis créé quelques petites fonctions qui me simplifie grandement la vie, surtout des fonctions qui travailleront sur l'apparence, et en plus de ça, j'aime a mettre sous forme d'objet les éléments que je dois traiter, pour qu'ils soient définit et récupérable facilement et de façon indépendante, et que le tri se fasse de façon claire.

En définitif, la partie POO de mon mode de fonctionnement est orienté sur les données à traiter.

Je sais pas si ça t'aide beaucoup ce que je te dis mais en espérant ^^

[Pol63]

ton cas ne s'y prête pas vraiment en effet, mais ce n'est pas vraiment un programme, pour 30 lignes de code on peut se passer des grands principes

néanmoins la POO permet d'avoir moins de code, et une plus grande maintenabilité (mieux rangé, plus simple à modifier ...)
ca offre aussi plus de simplicité dans la coupure entre le code et l'interface permettant l'évolution de l'un des deux sans modifier des lignes parmis quelques milliers de lignes de code d'un form et avec donc moins de chance de créer un bug
et quand on connait bien la POO on écrirait surement ton code en POO sans se poser de questions aussi

en POO on utilise jamais de redim preserve, et donc peu de tableau
en POO on a des classes, des propriétés et des collections

Code :

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

1
2
3
4
 
tab(15) = (tab(7) + tab(8)) / (tab(10) + tab(11))
 
instance.moyenne = (instance.prixMachin + instance.prixTruc ) / (instance.NbVenduMachin + instance.NbVenduTruc)

je te laisse deviner avec lequel de ces 2 codes le gars qui passera après toi sur ce code comprendra rapidement, et là c'est un exemple simple
imagine la même chose sur 30 lignes de code
au final ca fait la même chose certes, mais au sein d'une entreprise les programmes peuvent vivre longtemps et plusieurs personnes sont amenées à se succéder sur un programme
donc pour l'entreprise c'est mieux

dans le cas d'un déplacement de colonne, avec ton tableau tu dois faire du replace partout de tab(7) en tab(6) etc... alors qu'en POO la propriété reste la même il y a juste à changer l'unique ligne de code qui la remplie



si tu veux un exemple de ce que ca donnerait en poussant l'utilisation du concept je vais rajouter une contrainte imaginaire qui fait que l'erp cracherait des fichiers dans différents dossiers selon ce qu'il exporterait

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 
public enum TypeFichier ' une enum pour les types
  fichierClient
  fichierFournisseur
  fichierProduit
end enum
 
public interface FichierBase ' interface décrivant le fonctionnement d'un traitement de fichier
   sub LectureFichier(filepath as string)
   sub TraitementDonnees
   sub ExporteNewFile(filepath as string)
end interface
 
public class FichierTraitementFactory ' classe permettant de créer les instances (pattern fabrique de classe)
 
  public shared function Create(tf as TypeFichier)
     select case tf
         case fichierClient
             return new FichierClientTraitement
         case fichierClient
             return new fichierFournisseur
         case fichierClient
             return new fichierProduit
     end select
  end function
 
end class
 
 
public class FichierClientTraitement ' classe de traitement d'un fichier
   implements FichierBase
 
   private _Clients as new List(of Client)
 
   public sub LectureFichier(filepath as string) implements FichierBase.LectureFichier
        'transformation du fichier excel en instances de Client
        'je te passe le code technique qui permet de ne pas se taper 50 lignes de code
   end sub
 
   sub TraitementDonnees implements FichierBase.TraitementDonnees
        parallel.foreach(_Clients,sub(c as Client)
                                                 c.machin = c.truc + c.autre
                                                  'etc
                                        end sub)
   end sub
 
   sub ExporteNewFile(filepath as string) implements FichierBase.ExporteNewFile
         ' code qui recréé le fichier de destination
   end sub
 
end class
 
public class Client ' classe contenant les données d'une ligne de fichier excel
   ' properietes : une propriété par colonne utile du tableau source + une propriété par nouvelle colonne en sortie qui sera calculée
end class

on fait donc un fichier .vb par type contenant la classe de données et la classe de traitement
c'est bien séparé on sait quoi modifier (rajouter une propriété, modifier le set d'une autre)

et pour la gestion des fichiers, un dictionnaire of TypeFichier, Parametre
la classe parametre ayant le dossier source, le dossier de destination, et une recopie de la valeur d'enum
au démarrage des .add dans le dictionnaire, puis un for each qui instancie un filesystemwatcher
pour chaque fichier créé avec les paramètres sous la main il n'y aura qu'à faire

Code :

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

1
2
3
4
dim i = FichierTraitementFactory.Create(valeur_d_enum)
i.LectureFichier(filepathLecture)
iTraitementDonnees
i.ExporteNewFile(filepathSortie)

pas de question à se poser sur le type, les instances aillant leur type la bonne méthode sera appelée naturellement
et pas de code à modifier dans cette section dans le temps

et en gros pour l'ajout d'un nouveau type de fichier, tu ajoutes une valeur dans l'enum, 2 lignes dans le factory, un ligne pour l'ajout dans le dictionnaire au démarre de l'appli, une classe pour les données et une classe pour le traitement

en cas de modification sur un traitement existant tu as un fichier à ouvrir et à modifier (classe traitement et/ou classe données)


si on connait les principes techniques de la POO et ce qu'on peut en faire on imagine alors plus vite comment coder avec
à la place de l'interface on peut aussi faire de l'héritage, ca permet en plus d'avoir du code générique à tous les types sur la classe de base

[mactwist69]

Bon, j'me lance, car je ne jure QUE pas la POO. Et je pense que tout le monde est pour une fois qu'il y a compris son intérêt.

Je vais te donner 2-3 intérêts et l'appliquer à ton exemple.

Intérêt 1 : Réutilisation de ce que tu as écris
Intérêt 2 : Simplification du code et sa lecture
Intérêt 3 : Qualité assurée du code déjà produit

Avec ton exemple, moi tu me poses le problème, je vois direct les classes à faire :

Classe 1 : Une classe qui s'occupe d'UN fichier excel. Encapsulation oblige, dans cette classe, tu auras 4 procédures publique : Ouvrir, lire (renvois les colonnes), enregistrer, fermer
Classe 2 : Mapping (qui ne concerne QUE ton cas particulier de ton fichier), avec quelques procédures : le constructeur avec les colonnes en entrée, une procédure qui te retourne les colonnes mappé

Donc, Tu écris ta classe 1 qui gère le fichier, tu l'écris une seule fois, elle marche, tu l'as tester dans tout les sens, y'a aucune erreur, et elle est indépendante. Tu ne la touche plus jamais. Tu écris classe 2 , jusque là, tu ne vois toujours pas trop l’intérêt.

SAUF QUE :
- Le jour ou tu dois mapper deux fichiers Excel différent : Tu n'écris que une deuxième classe de la classe de type 2, tu réutilise la classe1 en étant sur qu'elle marche. (Pas de copier coller du code complet, pour finalement retrouver au milieu les lignes a changer).

- Tu peux te faire une interface graphique qui va utiliser les deux classes.... MAIS, tu peux aussi créer dans la foulé, et en rien de temps, une page web, un WPF ou un Windows Service, qui vont faire le même boulo, tu n''auras que l'interface a faire.

- Pour debugger, rien de plus facile, tu n'as QUE l'interface a degugger comme tes classes sont sûres.

A contrario, si tu fais en procédurales, certes, tout est sur une procédure.... Mais si tu dois faire un autre mapping, tu va faire quoi : copier coller ton code, bidouiller pour faire quelque changement... au bout du dixième copier coller, tu te rends compte que ton code faire 10 fois la taille qu'avec la solution POO, mais bon admettons.

Et là, ton chef te dis, on a supprimer la première colonnes de tous les fichiers. Tu dois retourner dans tes 10 procédures pour faire le changement. Changement, a la lecture, a l'écriture au mapping... T'es pas a l'abri d'erreurs. En POO, tu vas juste modifier LA classe concerné, tu ne touche pas aux autres.

Ensuite ton chef te dis... Ou mais j'aimerai bien que les données mappées on les mette en BDD... T'as déjà ta classe 1 pour lire, ta classe 2 pour mapper, tu te créer une classe supplémentaire qui lit et enregistre n'importe quelles colonnes en base, le boulo est terminé. Cette classe 3, tu te la mets de côté, tu pourras la réutiliser...

Ensuite il te dis, je veux mapper des colonnes de BDD, pas de problèmes, tu as déjà les 2 classes dont tu as besoin : la 2 et la 3. T'as presque rien a faire.

Et ainsi de suite.


Moi qui ait bosser en procédurale longtemps (on m'a forcé), j'ai vu le code : Des procédures de 1 km, sans rire... avec du code retravailler par une douzaines de personnes, chacun a bidouiller son truc, sans commentaires... Parfois les variables étaient utiliser deux fois, pour de choses différentes... Si on modifiait 1 truc, tout plantait... On passait 80% du temps a corriger les erreurs créer par des mises à jour. Et le code était illisible.

Un autre exemple : Toutes les procédures procédurales indépendantes était "organisées" dans des fichiers VB (qu'on ne peut pas appeler classe finalement). Le premier a écris sa procédure pour lire un info en BDD avec les colonnes qu'il aime bien... Un deuxième, avait besoin d'une donnée en plus... Mais plus possible de toucher a la première procédure sans risque de bousiller le code existant. Donc il en créer une deuxième avec quasi le même nom... Au bout d'un an : on se retrouve avec une bibliothèque de 500 procédures qui se ressemble, avec des noms impossibles... Si bien qu'il était impossible de retrouver une procédure qu'on cherche... donc on les recréer plusieurs fois. Chacun les siennes. Alors que en POO, on aurait réfléchis a faire 1 classe, qui peut lire n'importe quel table : C'est du Générique ! C'est réutilisable et c'est sûr !

En plus, je trouve qu'avec la POO tout est plus rapide, dans le sens, ou t'as pas 1 procédure avec 150 objets en mémoire, en POO une fois l'objet utilisé et détruit, la mémoire est libéré. Tu te traîne pas un truc du début à la fin.


Donc pour conclure, pour écrire une procédure comme la tienne, évidemment, on ne voit pas l'intérêt de se creuser le cerveau... Mais il faut regarder sur le plus long terme.

[DonQuiche]

@labraise
Bonjour.

Je trouve difficile de répondre à la question. Je suis trop peu familier du développement Excel et je ne vois pas du tout à quoi peuvent ressembler les scripts actuels que tu peux écrire (un exemple serait bienvenu et rendrait la discussion plus concrète). Si toutefois ceux-ci ne font que quelques dizaines de lignes, il y a effectivement peu de chances que la POO apporte quoi que ce soit. Au-delà en revanche, il y a sans doute des concepts qui se prêtent à des abstractions objet.

[labraise]

Bonjour,

Merci à vous 2 pour vos réponses extrêmement détaillées, c'est tout à fait ce dont j'avais besoin.

Je vais mettre en pratique tout ça, car l'intérêt semble effectivement évident.


Avoir une classe qui permet de traiter chaque fichier (ouvrir, acquisition des données, fermer) m'intéresse .
Elle serait évidement réutilisable dans bcp de projets et serait extrêmement simple à lancer : new(avec les paramètres : emplacement, onglet, range)


Point théorique sur lequel je "bloque" pour l'instant : l’acquisition des données.

Pol63,
tu me conseilles la transformation du fichier excel en instances de Client.
en gros chaque ligne/colonne de mon fichier deviendrait en sortie
client1.colonne1
client1.colonne2
client1.colonne3
client1.colonneàcalculer (vide pour l'instant)

puis de balayer tous les clients à l'aide de Parallel.foreach (fonction que je ne connaissait pas) ou je remplirais c.colonneàcalculer

pour créer mon fichier final, je devrais donc rebalayer tous les clients pour remplir ligne à ligne un fichier Excel
et ma question est là,
est-ce réellement au moins aussi rapide qu'avec un Tableau (ou la copie dans un fichier est instantanée et en une ligne)?


Mais je comprends l'idée et je vais essayer.



mactwist69,
Historiquement, quand je collais les données d'un fichier dans un Tableau, j'indexais les colonnes et les lignes dans des Dictionnaires spécifiques.
ce qui me permettait de ligne le tableau :
TAB(DIc_Lignes("Client1"), DIC_Colonnes("Adresse")
ainsi je passais outre le pbm des colonnes déplacées et manquantes.
Mais je me retrouvais effectivement avec 150 Tableaux et 300 dictionnaires...

si j'ai bien compris,
Dans ta classe1, la partie Lire équivaut comme Pol63 à créer des instances d'une classe pour chaque lignes
Dans la classe2, ajouter des attributs (.colonneàmapper par ex) et les calculer


Merci encore pour votre aide.

[labraise]

@labraise
Bonjour.

Je trouve difficile de répondre à la question. Je suis trop peu familier du développement Excel et je ne vois pas du tout à quoi peuvent ressembler les scripts actuels que tu peux écrire (un exemple serait bienvenu et rendrait la discussion plus concrète). Si toutefois ceux-ci ne font que quelques dizaines de lignes, il y a effectivement peu de chances que la POO apporte quoi que ce soit. Au-delà en revanche, il y a sans doute des concepts qui se prêtent à des abstractions objet.

Bonjour,

Pour te donner une exemple de ce que je fais pour chaque fichier

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
        'Acquisition File_Integration
        Afficher_PGB(12, PG_Step)
        XL_WB = XL_App.Workbooks.Open(File_Integration, False, True)
        XL_WS = XL_WB.Sheets("DATA")
        With XL_WS
            XL_Range = .Range(.Cells(2, 1), .Cells(.Cells(65356, 1).End(XlDirection.xlUp).Row, .Cells(2, 255).End(XlDirection.xlToLeft).Column))
            TAB_Integration = XL_Range.Value
        End With
        'Fermeture du classeur Excel et Désallocation mémoire
        XL_WB.Close(False)
        XL_WS = Nothing
        XL_WB = Nothing
        'Créer DIC_Colonnes_Integration
        For i = 1 To TAB_Integration.GetUpperBound(1)
            DIC_Colonnes_Integration.Item(TAB_Integration(1, i)) = i
        Next i
        'Créer DIC_Lignes_Integration
        For i = 2 To 0
            DIC_Lignes_Integration.Item(TAB_Integration(i, 1)) = i
        Next i

Après je travaille avec mes différents TAB en les lisant par TAB(DIC_Lignes(xx),DIC_Colonnes(yy))

[Pol63]

Pol63,
tu me conseilles la transformation du fichier excel en instances de Client.
en gros chaque ligne/colonne de mon fichier deviendrait en sortie
client1.colonne1
client1.colonne2
client1.colonne3
client1.colonneàcalculer (vide pour l'instant)

puis de balayer tous les clients à l'aide de Parallel.foreach (fonction que je ne connaissait pas) ou je remplirais c.colonneàcalculer

pour créer mon fichier final, je devrais donc rebalayer tous les clients pour remplir ligne à ligne un fichier Excel
et ma question est là,
est-ce réellement au moins aussi rapide qu'avec un Tableau (ou la copie dans un fichier est instantanée et en une ligne)?


Mais je comprends l'idée et je vais essayer.

c'est à tester oui ^^
parallel.foreach équivaut à une boucle qui sera multithreadée, donc gain de temps sur un serveur avec des dizaines de coeurs
et si tu n'utilisais pas de multithreading avant ma solution même si elle était plus lente irait plus vite ^^
enfin je pense que ce n'est pas réellement plus lent
de plus l'instruction la plus lente du monde s'il y en a une c'est bien redim preserve, ca créé un nouveau tableau, puis ca copie tout le tableau de base dans le nouveau
donc ca en brasse des données en ram
les collections n'ont pas ce soucis (enfin entre jamais et beaucoup moins souvent)

pour la lecture des données tu peux faire une enum avec valeur, genre

Code :

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

1
2
3
4
5
public enum ColonnesClient
  nom = 0 ' index de la colonne
  adresse = 3
  '...
end enum

et avec un peu de reflection tu peux faire une boucle de 3 lignes qui lit les données et les ranges dans les bonnes propriétés de manière dynamique
avec les expressions tu peux même faire la même chose en aussi performant que si tu avais écrit une ligne de code par propriété, mais c'est plus complexe à écrire, et les performances maximales ne sont pas forcément nécessaires (le mieux serait l'ennemi du bien parait il ^^)

[Pol63]

Pour te donner une exemple de ce que je fais pour chaque fichier
(...)

aussi, pour la lecture/écriture d'un fichier excel OleDb est beaucoup plus performant que l'interop que tu utilises
donc se poser la question des performances de ce que disent les autres c'est bien, mais autant se poser des questions sur ce qu'on fait
(oledb ne permet pas la mise en page en écriture, mais il y a l'openxml sdk qui devrait être plus rapide je pense)


pour tester les performances, il y a system.diagnotics.stopwatch (chronomètre)
attention, la 1ère exécution d'un morceau de code est toujours significativement plus lente que les autres (temps de compilation nécessaire)

[mactwist69]

Historiquement, quand je collais les données d'un fichier dans un Tableau, j'indexais les colonnes et les lignes dans des Dictionnaires spécifiques.
ce qui me permettait de ligne le tableau :
TAB(DIc_Lignes("Client1"), DIC_Colonnes("Adresse")
ainsi je passais outre le pbm des colonnes déplacées et manquantes.
Mais je me retrouvais effectivement avec 150 Tableaux et 300 dictionnaires...

Bon je continue mon extrapolation alors (surement que tu devras adapter)
Déjà il y a un truc que tu n'as pas encore en tête c'est tous les types d'objet .NET ! Il y en a beaucoup et des très utiles. Comme la datatable.

Classe 1 : La gestion du fichier excel (classe technique, elle ne sait pas a qui elle va servir)
Dans ta classe tu as un objet Excel, et un objet Datatable
le Constructeur prends le nom d'un fichier ET il le charge direct dans l'objet excel, voir rempli en même temps ta datatable.
Datatable disponible en publique par exemple.
Au chargement du fichier, la procédure va aussi mettre les noms de colonnes d'excel vers les noms de colonnes de la datatable.
Voilà ta classe1 : Excel->VB

Si en plus tu crées un 2ème constructeur qui prends le nom du fichier excel (de destination) ET une datatable en entrée,
Tu auras aussi une procédure pour enregistrer la datatable vers un fichier excel.
Du coup tu peux faire l'inverse : VB->Excel

Classe 2 : Mapping (classe métier, unique a ton job)
Lui connait les noms de colonnes à mapper
Il prends en entrée une datatable
et une procédure permet de retourner une datatable mappée
(Il y aura peut être d'autres procédure pour plus tard, vérification etc...)


Et dans le code, interface utilisateur, tu vas tout simplement utiliser ces objets.

1) Tu créer ExcelSource type classe1, ExcelDestination Classe1, un objet MAP classe2
2) Tu construit ExcelSource (et le charge avec un fichier)
3) Tu construit ExcelDestination vide.
4) Tu utilise MAP pour remplir la datatable de ExcelDestination avec la datatable de ExcelSource
5) tu enregistre ExcelDestination avec un nom de fichier

Si le mapping change, t'as juste a créer une classe cousine de classe2, le reste ne change pas.
Tu change de source de données, tu créer une classe cousine a classe1 qui fera SGBD-Datatable ou XML-datatable ou etc...

[rv26t]

Bonjour,

Tu va vite voir en quoi l'approche de Pol63 est très intérressante.
Dans le cas de la fabrique, on peut aller encore plus loin
L'exemple pour la fabrique est très bien et permet de bien voir le principe pour la création d'instance

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
public enum TypeFichier ' une enum pour les types
  fichierClient
  fichierFournisseur
  fichierProduit
end enum
 
public class FichierTraitementFactory ' classe permettant de créer les instances (pattern fabrique de classe)
 
  public shared function Create(tf as TypeFichier)
     select case tf
         case fichierClient
             return new FichierClientTraitement
         case fichierClient
             return new fichierFournisseur
         case fichierClient
             return new fichierProduit
     end select
  end function
 
end class

Code :

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

1
2
3
4
dim i = FichierTraitementFactory.Create(valeur_d_enum)
i.LectureFichier(filepathLecture)
iTraitementDonnees
i.ExporteNewFile(filepathSortie)

Cet ensemble pour la fabrique peut être remplacer par

Code :

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

1
2
3
4
5
6
7
public class FichierTraitementFactory ' classe permettant de créer les instances (pattern fabrique de classe)
 
    Public Shared Function Create(Of T As {New})() As T
        Return New T
    End Function
 
end class

L'appel restant quasiment identique, on passe juste le type de classe que l'on veut créé

Code :

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

1
2
3
4
dim i = FichierTraitementFactory.Create(of FichierClientTraitement)
i.LectureFichier(filepathLecture)
iTraitementDonnees
i.ExporteNewFile(filepathSortie)

Ce qui simplifie : tu as moins de ligne de code, et surtout tu n'as même plus à te soucier à gérer la création des instances.
Lors de la création d'un nouveau traitement de fichier tu n'as qu'a te préoccuper des fonctionnalités lié à ce fichier, le reste est déjà en place.

Donc

néanmoins la POO permet d'avoir moins de code, et une plus grande maintenabilité (mieux rangé, plus simple à modifier ...)

Après une bonne utilisation de la POO et de tous ces avantages ne se fait pas en un jour.
[Edit]Des messages sont passés pendant que j'écrivais.

[mactwist69]

J'avoue, l'approche Factory est beaucoup plus élaborée que mes petits exemples. (Surtout pour les gros projets)
On peut aussi utiliser l'héritage avec le polymorphisme... Ça peut permettre de factoriser le code commun, si les classes sont assez proches.

De toute façon il y a toujours x solutions, faut voir jusqu'où on veut aller.