Comment rendre le code modulaire?

Quelques Repères pour la modularité:

1. combien de fois Êtes-vous réécrire un code similaire pour effectuer une tâche particulière?
2. Combien de code avez-vous à restructurer le code dans le cas où vous changez quelque chose, quelque part dans une partie de votre programme?
3. sont les fichiers plus petits et plus facile de naviguer à travers ?
4. les modules d'application" 1519220920 fonctionnent-ils de façon adéquate et indépendante, selon les besoins?
5. comment moins désastreux est votre code? Est-ce que all hell break perd lorsque vous supprimez juste une fonction ou une variable? vous arrive-t-il d'avoir 20 erreurs en renommant une classe? (par exemple, vous pouvez mettre en œuvre un mécanisme d'empilage pour garder trace de tous les sauts dans votre application)
6. dans quelle mesure le code est-il proche de l'usage du langage naturel (c'est-à-dire que les modules et leurs sous-composants représentent des objets plus réels sans donner beaucoup d'importance à la taille du fichier net source).

Pour plus d'idées ça et celui sur qualité du logiciel

en ce qui concerne votre préoccupation sur rendre votre code plus modulaire vous devriez d'abord vous poser les questions ci-dessus, obtenir des réponses spécifiques pour eux, puis jeter un oeil à ce

la philosophie de base est de décomposer votre application en aussi petits fragments de code que possible disposés soigneusement à travers une multitude de layout de répertoire facilement compréhensible et accessible.

chaque méthode votre demande ne doit pas dépasser la quantité minimale de traitement nécessaire . La combinaison de ces méthodes dans des méthodes de plus en plus macro niveau devrait vous conduire à votre application

les points clés sont

• séparation des préoccupations
• cohésion
• Encapsulation (communique par interface)
• substituabilité
• réutilisable

un bon exemple d'un tel système de module est les pièces de voiture standard comme les freins à disque et la chaîne stéréo de voiture. Vous ne voulez pas construire voiture stéréo à partir de zéro lorsque vous construisez des voitures. Vous préférez l'acheter et de le brancher. Vous ne voulez pas non plus que le système de freinage affecte la chaîne stéréo de la voiture - ou pire, la chaîne stéréo de la voiture affecte le système de freinage.

pour répondre à votre question, "Comment puis-je décider qu'un code particulier est modulaire jusqu'à ce point," nous pouvons former des questions pour tester la modularité. pouvez-vous facilement remplacer vos modules par quelque chose d'autre sans affecter d'autres parties de votre application?

analyseurs XML pourraient être un autre exemple. Une fois que vous obtenez l'interface DOM, vous ne vous souciez vraiment pas quelle implémentation de L'analyseur XML est utilisée en dessous (par exemple Apache Xerces ou JAXP).

en Java, une autre question peut être: toutes les fonctionnalités sont-elles accessibles via interface s? L'Interface s'occupe à peu près de l'accouplement bas.

aussi, pouvez-vous décrire chaque module de votre système avec une phrase? Par exemple, une voiture stéréo joue de la musique et de la radio. Les freins à disque ralentissent le véhicule en toute sécurité.

(voici ce que j'ai écrit à Qu'est-ce que le développement basé sur les composants? )

selon Wikipedia, Component-Based Development est un alias pour Component-based software engineering (CBE) .

[It] est une branche de ingénierie, dont la priorité être la séparation des préoccupations à l'égard de la large gamme de fonctionnalités disponible dans un logiciel donné système.

C'est un peu vague, alors regardons plus de détails.

Un composant individuel est un logiciel paquet, ou un module, c' encapsule un ensemble de fonctions (ou des données).

Tous les processus du système sont placés dans séparé les composants de sorte que tous les les données et fonctions à l'intérieur de chaque composant sont sémantiquement liées (tout comme avec le contenu de classe.) En raison de ce principe, on dit souvent que les composants sont modulaire et cohérente .

donc, selon cette définition, Un composant peut être n'importe quoi tant qu'il fait une chose vraiment bien et une seule chose.

En ce qui concerne l'échelle du système coordination, communication des composantes avec l'autre via interfaces . [...] Ce principe conduit à des composants appelés encapsulés .

donc cela sonne de plus en plus comme ce que nous pensons de bonne API ou SOA devrait ressembler.

les interfaces fournies sont représentées par une sucette et les interfaces requises sont représentées par un symbole de douille ouverte fixé au bord extérieur du composant en UML.

alt text http://upload.wikimedia.org/wikipedia/commons/e/e1/Component-based-Software-Engineering-example2.gif

un autre attribut important de les composants, c'est qu'ils sont substituable , de sorte qu'un composant pourrait être remplacé par un autre (à moment de la conception ou de l'exécution), si le les exigences de la première composante (exprimées via les interfaces) sont satisfaites par le successeur de la composante.

la réutilisation est un élément important caractéristique d'une haute qualité composant logiciel. Logiciel le composant doit être conçu et mise en œuvre pour être réutilisée dans de nombreux programmes différents.

la substituabilité et la réutilisation sont ce qui fait qu'un composant est un composant. Alors, quelle est la différence entre ceci et la programmation orientée objet?

L'idée orientée objet la programmation (OOP) est ce logiciel devrait être rédigé selon un modèle mental du réel ou imaginé les objets qu'il représente. [...]

Component-based software engineering, en revanche, ne fait pas une telle les hypothèses, et déclare à la place que le logiciel devrait être développé par collage ensemble des composants préfabriqués comme dans le domaine de l'électronique ou de mécanique.

pour répondre à votre question spécifique de comment rendre le code plus modulaire, quelques approches sont:

• l'un des meilleurs outils pour la modularisation est la réutilisation du code spotting. Si vous trouvez que votre code fait la même chose exacte (ou très similaire) à plus d'un endroit, il est un bon candidat pour modulariser loin.

• déterminer quels morceaux de logique peuvent être faites indépendant, en un sens que d'autres logiques les utiliseraient sans avoir besoin de savoir comment ils sont construits. Ceci est quelque peu similaire à ce que vous à dans la conception OO, bien que le module/composant n'a pas nécessairement besoin de correspondre à un objet modélisé comme dans OO.

Hej,

voir ," comment encapsuler un logiciel (Partie 1), "ici:

http://www.edmundkirwan.com/encap/overview/paper7.html

Cordialement,

Ed.

Puisque ceci a été étiqueté avec "osgi", je peux jeter dans une perspective liée à OSGi.

la réponse courte est qu'il est possible de passer du code entièrement spaghetti à modulaire en petits pas; il ne doit pas être un Big bang. Par exemple, même le code spaghetti dépend d'une sorte de bibliothèque de journalisation bolognaise, donc dans un certain sens, il est déjà modulaire, avec juste une très grande Metball (désolé, module) dedans.

l'astuce est de briser le grand Boulette de viande en un petit morceau puis une boulette de viande un peu moins grosse et puis de nouveau. Il ne faut pas tout faire en une seule fois non plus; il suffit d'enlever un peu plus à chaque fois jusqu'à ce qu'il ne reste plus rien à enlever.

quant à OSGi, il est encore possible de mettre un Uber-jar dans un paquet. En fait, vous pouvez le faire sans changer les bits; soit en modifiant le Manifeste.MF en place, ou en l'enveloppant dans un autre POT et spécifier Bundle-ClassPath: metaball.jar dans le manifester.

à défaut, des outils comme BND peuvent vous aider à générer les bonnes données dont vous avez besoin, et ensuite elles peuvent être lâchées dans une exécution OSGi assez facilement. Mais méfiez - vous du code trop couplé, et les choses qui tourne en rond avec classloaders-ceux-ci vont vous faire trébucher.

en supposant que je comprenne votre question, que vous voulez savoir ce qui rend le code modulaire, puisque les modules de code auront évidemment besoin d'une certaine dépendance entre eux pour fonctionner. Voici ma réponse:

si vous pouvez décomposer votre système en modules, et que vous pouvez tester ces modules séparément, c'est une bonne indication qu'un système est modulaire.

comme vous dites modularité n'est pas une chose binaire, donc cela dépend de votre définition relative.

je dirais: pouvez-vous utiliser une méthode donnée dans n'importe quel programme où vous devez effectuer cette fonction? Est-ce la "boîte noire" où vous n'auriez pas besoin de savoir ce qu'il faisaient sous le capot? Si la réponse est non, c'est à dire la méthode ne fonctionne correctement dans ce programme, alors il n'est donc pas complètement modulaire.

la modularité est relative à qui développe le code. Mais je pense que le consensus général est que le code modulaire est du code qui a des portions qui peuvent facilement être échangées sans changer la plupart du code original.

IMHO, si vous avez 3 modules A B et C et que vous voulez changer ou remplacer complètement le module C, si c'est une tâche SIMPLE de le faire, alors vous avez du code modulaire.

vous pouvez utiliser un outil d'analyse de code tel que CAP pour analyser les dépendances entre les types et les paquets. Ils vous aideront à trouver et à supprimer toutes les dépendances cycliques, qui sont souvent un problème lorsque vous essayez de développer du code modulaire. S'il n'y a pas de dépendances cycliques, vous pouvez commencer à séparer votre code en bocaux discrets.

en général, il est de bonne pratique de coder aux interfaces si vous le pouvez, cela signifie généralement que votre code peut être plus facilement refactorisé et / ou utilisé dans différents contextes.

cadres D'injection de dépendance tels que ressort peut également aider à la modularité de votre conception. Comme les types sont injectés avec leurs dépendances par un processus de configuration externe, ils n'ont pas besoin d'une dépendance directe sur une implémentation.

l'idée package-by-feature aide à rendre le code plus modulaire.

de nombreux exemples vus sur le web divisent les applications d'abord en couches, pas en fonctionnalités

• modèles
• accès aux données
• interface utilisateur

il semble préférable, cependant, de diviser les applications en haut en utilisant des paquets de haut niveau qui s'alignent avec les caractéristiques , pas les couches .

voici un exemple d'une application web qui utilise package-by-feature. Notez les noms des paquets de premier niveau, qui se lisent comme une liste des caractéristiques réelles dans l'application. Notez également comment chaque paquet contient tous les éléments liés à une fonctionnalité - les éléments ne sont pas répartis partout; la plupart du temps, ils sont tous dans un seul paquet/répertoire.

Habituellement, la suppression d'un élément dans une telle application peut être mis en œuvre en une seule opération de suppression d'un répertoire unique.