Les Classes : une Drogue DURE pour Nicolas et moi qui suivait

Au fur et à mesure que le projet grossissait, malgré notre acharnement à garder le code source le plus clair et structuré (Unit) possible, il est arrivé un moment où il devenait impossible de s'y retrouver, et pour nous et pour le compilateur sans doute. Ceci était la conséquence d'une utilisation massive de structures qui, pour un souci de mémoire, étaient passées en paramètre sous forme de pointeur. De plus, qui dit 'utilisation massive de pointeurs' dit 'récupération massive de SegFault', ce qui complique donc le débogage. Il était donc difficile de lier structure, économie, rigueur et fiabilité.
Mais dans le fond, on se doutait bien qu'une solution efficace serait d'utiliser les classes. Malgré les quelques unes présentes dans le code source (par exemple, les Threads), il n'était pas facile de les exploiter efficacement du fait de notre connaissance limitée dans ce domaine.
Il arriva donc un jour où, lassé de voir planter notre projet, nous avons ouvert un manuel de Delphi. C'est en tombant par hazard sur une implémentation du type 'Pile' sous forme de classe que nous avons alors décidé d'y appliquer le même sort à notre file sécurisée, ce qui fut un franc succès. Il nous prit donc l'envie, 'je dirais même mieux la rage', de tout classifier, de tout transformer afin de simplifier l'utilisation de certaines parties du code, de réduire le nombre de variables, de procédure et de fonctions globales; jusqu'à obtenir une architecture intelligente pour ranger l'ensemble de nos données et nos fonctions. Et l'invasion des classes commençaient...
Après notre type file, ce fut le tour de l'ensemble des fonctions concernant la création et la modification de paquets, ce qui, on ne vous le cache pas, a provoqué d'énormes changements dans l'ensemble du projet, un basculement sans retour dans l'univers des classes. Maintenant, il est très facile de construire un paquet, notamment pour le trace-route et le scanner de ports, à l'aide des multiples constructeurs dont nous avons pourvu notre classe.
Justement, pour le scanner de ports et le trace-route, l'utilisation de notre classe de manipulation des paquets n'était pas suffisante. En effet, il aurait fallu rajouté à celle-ci des fonctions qui ne sont d'aucune utilité dans le cas générale. Nous avons donc créé une classe pour le scanner (respectivement trace-route), héritant de la classe originale de manipulation des paquets à laquelle on a ajouté les fonctions particulières au scanner (respectivement trace-route).
Et c'est ainsi que l'invasion des classes atteint notre structure de configuration du système. La configuration était auparavant un enregistrement qui contenait toutes les informations nécessaires, c'est-à-dire des tableaux de ports, des booléens, les interfaces... Notre structure de configuration était très souvent utilisée et il devenait contraignant de la passer en paramètre à chaque utilisation. L'apparition d'une classe de configuration soulagea cette continuelle utilisation des informations souvent utilisées.
Ensuite, c'est notre filtre qui reprit forme. Le filtre devenait de moins en moins clair : en plus de vérifier la conformité de chaque paquet, il devait rediriger les réponses ARP et TCP ou ICMP concernant le scanner et le trace-route. Ainsi, l'utilisation d'une classe pour le filtre entraîna une structure de code beaucoup plus lisible et surtout l'élimination de tests devenant inutiles.
Enfin, et aussi le plus important, la création d'une classe de sniffer fut très importante. Cette classe est père de plusieurs autres classes (filtre, scanner, trace-route, classe de paquet).
Au final, l'utilisation des classes simplifie vraiment la construction et la destruction d'un objet, et surtout, réduit le nombre d'arguments à passer en paramètres.