Question

Je travaille sur un projet à Java, qui communique avec deux dispositifs de port série utilisant la bibliothèque de port série de Suns. Je dois en quelque sorte garder les connexions aux appareils ouverts tout le temps et en gérer les événements (sur les données révolues ...). L'application interagit avec l'utilisateur (via SOAP) et est une application de console (plus tard, elle pourrait être déplacée vers un serveur d'applications, mais ignorez cela pour l'instant).

La question est de savoir comment gérer les appareils. Pour l'instant, j'ai une classe statique avec deux variables statiques qui renvoie des objets qui gèrent l'appareil. Dans le constructeur statique de cette classe, j'ouvre les connexions et je définis les paramètres initiaux, etc. Ensuite, chaque fois que j'ai besoin d'un appareil dans l'application, je l'obtiens par quelque chose comme: device.mydevice, périphérique. MyDevice2 etc ... y a-t-il une meilleure façon de faire cela ou est-ce que ce est OK?

N'oubliez pas que je n'ai pas de problèmes avec la connexion aux appareils, j'ai besoin de conseils architecturaux.

Merci

Était-ce utile?

La solution

Mon expérience a été que les constructeurs statiques peuvent être désordonnés. De plus, si vous vouliez tester la logique en écrivant des tests unitaires pour se moquer de la communication série, cette architecture rendrait la tâche difficile.

Une alternative serait d'avoir une classe de périphérique avec un constructeur qui prend certains arguments de configuration (quel port série utiliser, par exemple), et disposent des deux appareils réels avec lesquels vous vous connectez en tant que champs finaux statiques publics de la classe. Quelque chose comme ça:

public class Device {
    public static final Device Device1 = new Device(...);
    public static final Device Device2 = new Device(...);

    public Device( ... ) {

    }
}

Pour rendre les tests encore plus faciles, vous pourriez avoir une interface de périphérique que cette classe de périphérique implémente - il aide à rendre la boucle de développement plus serrée si vous pouvez tester la logique pour interagir avec les appareils sans traiter avec l'appareil lui-même.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top