Toutes sortes de mélanges existent. Vous avez des structures de données, qui ne sont pas associées à des algorithmes, des algorithmes, qui ne nécessitent pas de structures de données (réelles), mais le plus souvent, les deux viennent dans un seul paquet.
Edit: comme @Doval l'a correctement souligné, les structures de données en elles-mêmes n'ont aucune opération associée. L'acte de combiner la structure des données et l'algorithme forme un type de données abstrait.
Structures de données sans algorithmes
Considérons par exemple une structure de données pour stocker des coordonnées bidimensionnelles, appelée de manière appropriée Point
. Il n'y a pas grand-chose en termes d'algorithmes à faire pour un point et c'est vraiment juste un conteneur pour un x
et une y
valeur. Bien sûr, en donnant cette structure de données, vous pouvez maintenant ajouter toutes sortes d'algorithmes par-dessus (calcul de la distance, coques convexes, ce que vous avez).
Vous pouvez penser à de nombreuses structures de données, qui sont simplement une accumulation de données individuelles. Bien que ceux-ci se produisent fréquemment dans la pratique, ils ne constituent pas un bon matériel pédagogique, car il n'y a rien à en tirer, une fois que vous avez compris, que des éléments de données uniques peuvent être accumulés dans une nouvelle structure de données (comme ce que vous apprenez après l' Point
exemple ci-dessus , si je vous fournis cette impressionnante structure de données appelée Point3D
, qui peut faire la même chose pour un espace en 3 dimensions?)
Algorithmes sans structures de données (réelles)
"Réel", car évidemment chaque algorithme intéressant a besoin de types de données primitifs comme des entiers ou des booléens, et nous ne voulons pas les considérer comme des structures de données dans ce contexte. De la même manière que ci-dessus, ces algorithmes sont généralement assez simples. En particulier, ils ne viennent pas avec un état compliqué d'aucune sorte, car cela va généralement dans une structure de données (voir la section suivante).
Un exemple d'un tel algorithme serait de calculer le plus grand diviseur commun de deux nombres. Les algorithmes d'Euklid pour le gcd n'ont vraiment besoin que de deux entiers et les manipulent.
Une fois que les choses commencent à devenir plus intéressantes, vous entrez très bientôt dans le monde des types de données abstraits. Par exemple, le tamis d'Eratosthène est basé sur un tableau. Nous pourrions avoir une discussion maintenant, si un tableau est encore primitif, ou en fait, vous pourriez discuter si un entier n'est pas déjà une structure de données. De toute façon, les algorithmes qui existent complètement sans structures de données sont plutôt ennuyeux, même si vous acceptez leur existence isolée.
Algorithmes combinés avec des structures de données, aussi appelés types de données abstraits
Maintenant, ce sont les plus intéressants, mais pour deux raisons très différentes. En règle générale, vous pouvez les aborder dans deux directions: la structure des données d'abord ou l'algorithme d'abord.
Alors qu'un type de données abstrait est défini par la combinaison de structure de données + algorithmes / opérations, nous les considérons souvent avec un accent sur l'un de ceux-ci et considérons l'autre comme des catalyseurs.
Structure des données, puis algorithme
Vous rencontrerez des types de données abstraits, assez simples à utiliser, mais qui impliquent des algorithmes plus ou moins compliqués pour les faire fonctionner en interne. Par exemple, a HashMap
est trivial à utiliser, mais implique une fonction de hachage astucieuse et traitant des collisions de hachage à l'intérieur. Pourtant, de votre point de vue en tant qu'utilisateur, vous vous souciez de cela comme quelque chose qui contient des données pour vous, pas quelque chose qui fait quelque chose pour vous.
Contrairement au dernier groupe ci-dessous, ces structures de données n'exposent pas leurs utilisateurs à ces algorithmes. Vous n'avez pas besoin de connaître ni de vous soucier de HashMap
la fonction de hachage interne pour pouvoir l'utiliser. (Pour l'utiliser efficacement, vous voudrez peut-être savoir ces choses;)
Algorithme, puis structure des données
L'autre direction signifie que vous avez un algorithme, que vous voulez pouvoir utiliser simplement, mais qui a besoin de structures de données en interne pour le faire fonctionner comme prévu. Un exemple serait un algorithme de partitionnement d'espace binaire (BSP), que vous pouvez simplement demander pour les 2 dimensions Point
d'un grand ensemble de points qui est le plus proche d'un point de requête donné. Cependant, vous avez besoin d'une structure arborescente (et même d'algorithmes supplémentaires comme les calculs de distance) à l'intérieur pour réellement écrire l'algorithme.
En général, on peut dire que les algorithmes de ce groupe utilisent des structures de données impliquées pour leur représentation d'état interne. Je dirais que ce groupe d'algorithmes est le plus diversifié et vous en trouverez de nombreux différents qui correspondent à ce schéma général. En ce qui concerne le point de vue, nous les considérons comme intéressants, car ils font quelque chose (tri par exemple) pour nous, et ne se soucient pas autant de la partie contenant les données.
Structures de données et algorithmes étroitement liés
Enfin, vous disposez de structures de données, très proches des algorithmes qui leur correspondent directement. Un exemple typique est un arbre binaire qui, lorsque vous voulez faire quoi que ce soit de significatif avec lui, vous impose le sujet des algorithmes d'arborescence (profondeur d'abord, largeur d'abord, peu importe).
Pour ces cas, nous modifions de temps en temps notre vision des types de données abstraits résultants. Parfois, vous vous souciez de la structure de votre arbre, quelques minutes plus tard, vous vous souciez de pouvoir exécuter une opération de recherche sur celui-ci, puis vous vous interrogez sur la suppression d'un nœud, et tout de suite sur l'aspect de la structure par la suite. Bien que tout cela soit également vrai pour les autres sections ci-dessus, ce n'est pas quelque chose qui vous intéresse principalement, par exemple, lorsque vous stockez / récupérez des données vers / depuis un Map
, ou lorsque vous triez une liste liée.