Comment concevoir une application de façon modulaire?
je suis à la recherche pour obtenir des conseils, des suggestions, des liens, des avertissements, des idées et même anecdotical comptes sur "comment concevoir une application de façon modulaire". Je vais utiliser python pour ce projet, mais les conseils ne doivent pas nécessairement se référer à ce langage, bien que je ne sois prêt à mettre en œuvre un design basé sur OOP.
voici un contexte pour comprendre d'où je viens et ce que j'essaie de faire atteindre...
Mon projet sera une petite application qui va consommer des services web et afficher les résultats dans une variété de façons, y compris:
- popup de notification contenant seulement le résultat de l'appel
- tab dans la fenêtre principale de l'application avec des graphiques tracés à partir des données brutes récupérées
- tampon de messages (visible sur domand) où les résultats provenant des différents services s'accumule
le application seront publiés sous forme libre (comme dans le discours) de logiciels, et pour cette raison je voudrais rendre vraiment facile pour les autres développeurs à écrire des plugins/modules qui va étendre la fonctionnalité de l'application principale sans avoir besoin de changer le code de base.
À ce point dans le temps, les plugins doivent essentiellement permettre à un développeur d'activer un nouveau service Web, en définissant le fournisseur, la manipulation des données (le cas échéant) et la façon dont les données seront présentées à l'utilisateur.
j'ai une vaste expérience en développement avec drupal qui a une approche modulaire puissante, mais qui suit également un design non orienté objet, donc je soupçonne que pour python, le design drupal ne serait pas la solution optimale.
si cela est important - le noyau sera développé nativement pour GNU/Linux.
je vous Remercie d'avance pour votre temps!
5 réponses
essayez de garder les choses vaguement couplées, et utilisez des interfaces généreusement pour aider.
je commencerais la conception avec le la Séparation des Préoccupations. Les principales couches architecturales sont:
- Problem Domain (alias. Moteur, Back-end) : les classes de domaines, qui font tout le travail réel, ont la connaissance de domaine mettre en œuvre le comportement de domaine
- persistance: gestion du stockage pour les classes de domaines, couche base de données/système de fichiers
- Interface Utilisateur: le GUI, qui parle à l'classes de domaine
- Interfaces système: communication avec d'autres systèmes, p. ex. mise en réseau, services web
les classes de domaines font le travail, mais ne savent pas à propos de L'interface utilisateur. La couche de persistance connaît les classes de domaines, assez pour enregistrer/charger selon les besoins. La couche d'interface système élimine les systèmes externes, ce qui vous permet de brancher un simulateur en arrière tout en testant. L'interface utilisateur devrait idéalement utiliser MVC, pour flexibilité.
sans mettre un point trop fin sur elle, on ne regarderait pas habituellement Drupal comme un exemple de bon design architectural. Il s'est développé de manière assez organique, et il y a eu de nombreux bouleversements de la conception, comme en témoigne la rupture régulière du plugin sur les mises à niveau du système.
je voudrais aussi faire écho à ce que MicSim a dit, concernant la conception soigneuse de l'interface du plugin et l'écriture de plusieurs plugins différents pour l'exercer. C'est la seule façon de vraiment chair les enjeux de la façon dont l'application et les plugins interagir.
comme vous allez fournir quelques fonctionnalités de base avec votre application, assurez-vous de coder la partie qui devrait être extensible/remplaçable déjà comme un plugin par vous-même. Vous devriez alors avoir une idée de l'apparence de votre API.
et pour prouver que L'API est bonne, vous devriez écrire un deuxième et un troisième plugin, car alors vous découvrirez que vous avez fait beaucoup de suppositions en écrivant le premier. Normalement les choses s'éclaircissent un peu après avoir fait ce 2nd et 3rd étape.
maintenant, vous devriez écrire un plugin de plus, parce que les derniers plugins que vous avez écrits ressemblent au premier en type, données d'entrée et présentation (peut-être encore un autre weather webservice). Choisissez quelque chose de totalement différent, avec des données absolument différentes, et vous verrez que votre API est encore trop adaptée. (Sinon vous avez fait du bon travail!)
eh Bien, probablement le premier endroit pour commencer est de s'asseoir et de comprendre ce que le plug-in pourriez avoir besoin pour remplir son but.
vous voudriez considérer deux aspects principaux dans votre conception.
- comment votre framework passera-t-il les demandes / recevra-t-il les réponses du plugiciel?
- quels cours ou modules d'aide pourraient être utiles à fournir?
et probablement aussi, puisque cela ressemble à un projet d'apprentissage.
- Ce n' vous voulez écrire vous-même, et ce que vous êtes tout simplement heureux de choisir d'une bibliothèque existante?
je recommande aussi de développer quelques plugins de base pendant la conception de l'API. L'expérience d'avoir à réellement utiliser ce que vous concevez vous permettra de voir où une approche donnée pourrait rendre les choses plus difficiles qu'elles doivent être.
- concevoir l'api pour votre application, avec soin (Comment Concevoir Une Bonne API et Pourquoi c'est important)
- tout faire, qui pourraient être utilisés indépendamment d'un module, puis de les regrouper et de construire de plus grandes pièces des pièces simples (KISS)
- ne pas se répéter (SEC)
- écrire / publier de la documentation courte fréquemment, pour vous-même et les autres (mantra open source) ...
examinez le schéma écouteur-abonné. Tôt ou tard, votre application sera assez complexe pour que vous ayez besoin d'implémenter des callbacks. Lorsque vous atteignez cette limite, utilisez listener-subscriber (il y a une implémentation dans wxPython).
par exemple, plusieurs modules voudront surveiller les nouvelles données provenant d'un certain nombre de flux. Les Modules qui sont reliés entre eux pourraient vouloir se mettre à jour, en fonction de nouvelles données.