Forum Programmation.autre Modularité

Posté par  .
Étiquettes : aucune
0
13
juil.
2004
Bonjour à tous,

je suis à la recherche d'un tutorial qui expliquerait les bases de ce que j'appelle la modularité.

Plus concrètement, je développe un site en PHP. Je souhaites qu'il soit constitué d'un noyau et qu'ensuite on puisse facilement en étendre les fonctionnalités en rajoutant des plug-in.

Savez vous ou trouver un tutorial qui explique ce à quoi il faut penser pour ce genre de programmation ?

Il serait préférable d'éviter que le texte se rapporte à un langage précis. Quelque chose de théorique est plus intéressant. Dans le cas contraire, le PHP est particulièrement bienvenue. Je maîtrise aussi C/C++.

Merci.

  • # Modularité ?

    Posté par  (site web personnel) . Évalué à 1.

    Pour le peu de sites que j'ai fait, j'ai essayé de les rendre modulaires. Tout simplement, chaque module était une entité PHP qui était ensuite inclue (require_once) au sein de la page "mère". Je ne vois pas beaucoup d'autres possibilités de "modularité". Si j'ai rien compris dites le moi ;-) !

    • [^] # Re: Modularité ?

      Posté par  . Évalué à 2.

      Prenons l'exemple de Firefox.

      Il est facile de rajouter des extensions. Les extensions agissent sur le fonctionnement global du navigateur (interface, rendu des pages...).

      Comment faut il penser le fonctionnement de ce type de programme ?

      Je n'ai pas la prétention de faire quelque chose d'aussi évolué mais c'est ce type de fonctionnalité que je vise.

      • [^] # Re: Modularité ?

        Posté par  . Évalué à 1.

        Les extensions c'est un peu différent.

        La modularité, c'est des groupes de fonctions (ou classes ou modules ou l'équivalent de base dans ton langage) regroupés en un tout cohérent et auxquels on accède par une interface publique. Les groupes s'utilisent les uns les autres, ce qui permet d'en changer un sans effet sur le reste pourvu que l'interface ne change pas. Ou si on change l'interface il n'y a que ces appels à changer, ce qui, de l'autre côté est un peu pénible mais pas autant que si ça n'avait pas été modulaire.

        Pour des extensions, il faut partir de la même idée mais avec des services que ton extension doit fournir (callbacks), il s'agit de donner quelques points d'entrée. L'extension se sert d'une interface bien définie du logiciel principal (d'où des extensions qui ne marchent plus d'une version à l'autre, quand l'interface a changé).

        La base c'est comme toujours les types abstraits, si tu comprends les types abstraits tu étends l'idées à des portions plus conséquentes de programmes.

    • [^] # Re: Modularité ?

      Posté par  . Évalué à 1.

      Pour la modularité tu peux prendre exemple sur le framework Copix. Au menu modules, plugins, internationalisation ...

      http://forum.copix.org/(...)

  • # voir

    Posté par  . Évalué à 3.

    du coté des "containers" et des "interfaces"

    Il y a plein de doc, livres, exposés dessus

    • [^] # Re: voir

      Posté par  (site web personnel) . Évalué à 2.

      Tout à fait, faire une application modulable ce n'est pas vraiment compliqué, le seul travail est de bien spécifier les rôles de chaque module et donc celà force à faire une architecture carrée, et c'est pas plus mal. En gros :
      - tu définis ce que ton module doit pouvoir faire et de quoi il a besoin pour le faire
      - tu définis une interface pour que les fonctionnalités demandées puissent être accessible depuis ton application
      - tu fais du chargement "dynamique" de module au lancement de l'appli pour trouver les modules, vérifier l'interface qu'ils implémentent, et zou tu les utilises.
      - quelqu'un qui veut faire un module implémente l'interface correspondante et s'arrange pour que son code/exécutable/librairie soit accessible depuis ton application.

      Exemple à l'arrache en français (je veux faire des modules pour supporter plusieurs format de fichiers dans mon application) :

      interface FileReader :

      propriétés :
      string nom_du_module
      string[] formats_supportés

      méthodes :
      ouvrir(string url) retourne fichier
      lire_car(fichier fich) retourne car
      fermer(fichier fich) retourne bool

      Après un langage object est bien entendu pratique pour vérifier qu'un morceau de code implémente telle ou telle interface, mais tu peux toujours te baser sur une description d'interface définie dans un document XML, mais c'est moins "carré" au sens où il est possible que le document XML ne colle pas au module (tu essai alors d'appeler une méthode qui n'existe pas, et bonjour les dégâts)

      voilà voilà, amuse toi bieng.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.