Chaque type de capteur produit des données dans son propre format, avec des protocoles uniques, des besoins d'étalonnage et des modèles de communication. La gestion de cette hétérogénéité devient de plus en plus complexe à mesure que le système grandit et que de nouvelles technologies de capteurs sont intégrées. Le modèle de méthode Factory offre une solution architecturale éprouvée pour traiter diverses données de capteurs avec flexibilité, évolutivité et maintien. Lorsqu'il est combiné à un CMS sans tête comme Directus pour stocker les configurations et métadonnées des capteurs, le modèle devient encore plus puissant, permettant l'enregistrement dynamique des capteurs et l'ingestion de données sans dépendances codées durement.

Comprendre le modèle de méthode d'usine

La méthode Factory est un modèle de conception créative qui définit une interface pour la création d'un objet mais permet aux sous-classes de décider quelle classe doit être instantanée. Cette approche favorise le couplage lâche en transférant la responsabilité de la création d'objets du code client vers des sous-classes d'usine dédiées. Dans la programmation, cela signifie que vous pouvez écrire du code qui fonctionne avec un type de produit abstrait et se fier aux méthodes d'usine pour produire des instances concrètes à l'exécution.

Le modèle est particulièrement utile lorsqu'un système doit supporter plusieurs variantes d'un produit sans modifier la logique de base. Il suit le principe : un système est ouvert pour l'extension (nouveaux produits) mais fermé pour la modification (le code existant reste inchangé). Pour la gestion des capteurs, cela se traduit par la possibilité d'ajouter du support pour de nouveaux types de capteurs en créant simplement une nouvelle classe de capteurs et son usine correspondante – aucun changement n'est nécessaire dans le moteur de traitement des capteurs ou le pipeline de données.

Les principaux éléments du modèle sont les suivants :

  • Produit – l'interface abstraite que tous les produits concrets doivent mettre en œuvre (p. ex. .
  • ConcreteProduct[ – une implémentation spécifique de l'interface produit (par exemple, ).
  • Créateur – une classe ou une interface abstraite déclarant la méthode d'usine qui renvoie un objet .
  • ConcreteCreator – une sous-classe qui prime la méthode d'usine pour injecter un .

En isolant la logique de création, le modèle de méthode Factory simplifie également les tests et facilite l'injection de dépendance. Vous pouvez échanger les implémentations de capteurs sans affecter le reste du système.

Application du modèle à la gestion des données du capteur avec Directus

Dans un système IoT d'ingénierie typique, les capteurs sont répartis sur une installation, chaque donnée en continu à travers une passerelle ou un périphérique de bord. Le moteur doit interpréter les données brutes, appliquer la validation et les stocker pour analyse. Un défi commun est que chaque type de capteur peut exiger un gestionnaire différent pour analyser sa sortie. Le codage dur de tous ces gestionnaires dans la logique d'ingestion est fragile et inmaintainable. Le modèle de méthode d'usine s'attaque à cela en déléguant la création de gestionnaires de capteurs aux usines qui peuvent être sélectionnées en fonction du type de capteur ou de la configuration.

Pour rendre le système encore plus dynamique, nous pouvons utiliser Directus comme dépôt de configuration central. Directus est un CMS sans tête open source qui fournit une couche de données flexible avec les API REST et GraphQL. Les définitions de capteurs – comme le type, le protocole de communication, le format des données, les coefficients d'étalonnage, et même le nom de la classe de gestionnaire Python ou Java correspondante – peuvent être stockées dans les collections Directus. Lorsque le système démarre (ou lorsqu'un nouveau capteur enregistre), il lit ces configurations et utilise le modèle de méthode Factory pour activer le gestionnaire approprié en vol.

Cette combinaison donne une architecture fortement découplée où l'ajout d'un nouveau type de capteur est réduit à:

  1. Création d'une nouvelle classe de gestionnaire qui implémente l'interface standard du capteur.
  2. Créer une nouvelle usine de béton qui retourne ce gestionnaire.
  3. Enregistrement du gestionnaire de cartes dans Directus (par exemple, une nouvelle entrée dans une collection "sensor types").

Aucun code existant ne doit changer, et le système peut réagir aux nouveaux types de capteurs au moment de l'exécution.

Définition de l'interface du capteur

La première étape consiste à définir le produit abstrait – l'interface de capteur que tous les gestionnaires de béton doivent mettre en œuvre. Cette interface déclare les méthodes de base pour la récupération des données et, en option, pour la configuration ou la déclaration des métadonnées.

public interface Sensor {
 /**
 * Retrieves the latest sensor reading.
 * @return a Data object containing timestamp, value, and unit.
 */
 Data getData();

 /**
 * Returns the sensor's unique identifier.
 */
 String getSensorId();

 /**
 * Returns the type of sensor (e.g., "temperature", "pressure").
 */
 String getSensorType();
}

Pour un système de production, vous pouvez également inclure des méthodes d'initialisation, des vérifications diagnostiques et la récupération d'erreurs. L'interface doit être maintenue petite pour le rendre facile à mettre en œuvre pour tout type de capteur.

Création de classes de capteurs de béton

Chaque type de capteur obtient sa propre classe de béton qui implémente . Ces classes encapsulent la logique pour communiquer avec le capteur physique, analyser sa sortie et la convertir en objet standard .

public class TemperatureSensor implements Sensor {
 private final String sensorId;
 private final String deviceUrl; // e.g., Modbus address or HTTP endpoint

 public TemperatureSensor(String sensorId, String deviceUrl) {
 this.sensorId = sensorId;
 this.deviceUrl = deviceUrl;
 }

 @Override
 public Data getData() {
 // Implementation: read from sensor via Modbus, MQTT, or HTTP
 // Convert raw value to Celsius, wrap in Data object
 return new Data(sensorId, System.currentTimeMillis(), value, "°C");
 }

 @Override
 public String getSensorId() { return sensorId; }

 @Override
 public String getSensorType() { return "temperature"; }
}

public class PressureSensor implements Sensor {
 private final String sensorId;
 private final String mqttTopic;

 public PressureSensor(String sensorId, String mqttTopic) {
 this.sensorId = sensorId;
 this.mqttTopic = mqttTopic;
 }

 @Override
 public Data getData() {
 // Subscribe to MQTT topic, parse JSON payload
 return new Data(sensorId, System.currentTimeMillis(), pressureValue, "bar");
 }
 // ...
}

En gardant les détails de communication dans la classe béton, vous isolez le reste du système du code spécifique au protocole. Si vous remplacez plus tard un capteur de température Modbus par un capteur I2C, vous n'avez qu'à modifier ; le code d'usine et le code client restent intacts.

Incorporer Directus pour la configuration des capteurs

Plutôt que de les coder dur, nous pouvons les stocker dans les collections Directus. Par exemple, une collection nommée peut contenir des champs comme:

  • (UUID)
  • (chaîne ‐ « température », « pression », « humidité »)
  • (chaîne de caractères – nom de classe entièrement qualifié, p.ex., «com.example.sensors.TemperatureSensor»)
  • (objet JSON avec paramètres spécifiques au protocole)

Lorsque le système initialise, il récupère la liste des capteurs actifs de Directus et utilise le champ pour sélectionner l'usine appropriée. Vous pouvez aussi stocker la classe d'usine directement. Cette approche rend la flotte de capteurs entièrement configurable via Directuss admin UI ou API, permettant aux non-développeurs d'ajouter, de supprimer ou de modifier des capteurs sans toucher aucun code.

Mise en œuvre de la méthode de l'usine

Maintenant, nous définissons le créateur abstrait – le – qui déclare la méthode d'usine . La méthode d'usine peut accepter les paramètres nécessaires aux capteurs en béton (comme l'ID et la configuration du capteur).

public abstract class SensorFactory {
 /**
 * Factory method – subclasses implement this to create specific sensors.
 * @param sensorId the unique identifier for the sensor
 * @param config additional configuration (e.g., device URL, MQTT topic)
 * @return a Sensor instance
 */
 public abstract Sensor createSensor(String sensorId, Map<String, Object> config);

 /**
 * Optional: method to validate configuration before sensor creation.
 */
 public boolean validateConfig(Map<String, Object> config) {
 return true; // subclasses can override
 }
}

Les classes de béton industriel remplacent pour initier le gestionnaire de capteur approprié. Chaque usine sait quelle classe doit initier et comment interpréter la carte de configuration générique.

public class TemperatureSensorFactory extends SensorFactory {
 @Override
 public Sensor createSensor(String sensorId, Map<String, Object> config) {
 String deviceUrl = (String) config.get("device_url");
 // Could also extract other parameters like polling interval
 return new TemperatureSensor(sensorId, deviceUrl);
 }

 @Override
 public boolean validateConfig(Map<String, Object> config) {
 return config.containsKey("device_url");
 }
}

public class PressureSensorFactory extends SensorFactory {
 @Override
 public Sensor createSensor(String sensorId, Map<String, Object> config) {
 String mqttTopic = (String) config.get("mqtt_topic");
 return new PressureSensor(sensorId, mqttTopic);
 }
}

Enregistrement et recherche d'usines

Pour rendre le modèle de méthode d'usine pratique, vous avez besoin d'un mécanisme pour sélectionner la bonne usine à l'exécution. Une approche courante est de maintenir un registre qui mapait les chaînes de type de capteur vers les instances d'usine. Ce registre peut être peuplé au démarrage en balayant un paquet pour les classes d'usine, ou – mieux – en lisant la cartographie de Directus.

public class SensorFactoryRegistry {
 private Map<String, SensorFactory> factoryMap = new HashMap<>();

 public void registerFactory(String sensorType, SensorFactory factory) {
 factoryMap.put(sensorType, factory);
 }

 public SensorFactory getFactory(String sensorType) {
 SensorFactory factory = factoryMap.get(sensorType);
 if (factory == null) {
 throw new IllegalArgumentException("No factory registered for sensor type: " + sensorType);
 }
 return factory;
 }
}

Lorsque le système démarre, il interroge Directus pour la liste des types de capteurs disponibles et le nom de classe d'usine correspondant. Il inactive ensuite chaque usine et l'enregistre dans le registre. Ensuite, le traitement d'une nouvelle lecture de capteur est aussi simple que:

// Example: handling an incoming sensor registration message
String sensorType = message.getType();
String sensorId = message.getId();
Map<String, Object> config = message.getConfig();

SensorFactory factory = registry.getFactory(sensorType);
Sensor sensor = factory.createSensor(sensorId, config);
// Use sensor to start reading data...

Ce modèle maintient le code client (le moteur d'ingestion de données) totalement indépendant des classes de capteurs en béton. Vous pouvez introduire un nouveau type de capteur en écrivant un nouveau gestionnaire, une nouvelle usine, et en mettant à jour la configuration de Directus.

Utilisation de la méthode de l'usine dans la pratique

Imaginez un plancher d'usine avec des capteurs de température, pression, humidité et vibration. Au départ, seules la température et la pression sont nécessaires. Vous implémentez et avec leurs usines respectives. La collection Directus contient deux entrées :

  • ,
  • ,

Votre code de démarrage lit ces entrées, inactive chaque usine en utilisant la réflexion (ou par un simple commutateur si vous préférez), et les stocke dans le registre. Lorsqu'un capteur de température envoie une demande d'enregistrement (par exemple via MQTT), le système recherche l'usine --température, appelle avec l'ID du capteur et la configuration de Directus, et ajoute l'objet résultant à une boucle de sondage ou d'abonnement. Tout fonctionne bien.

Un mois plus tard, l'usine installe des capteurs de vibrations. Un développeur écrit et , puis ajoute une nouvelle entrée dans Directus pour . Sans arrêter le système, le code de démarrage (ou une fonction de recharge en direct) prend la nouvelle usine. Maintenant, le système peut traiter les données de vibrations aussi bien – pas de changement au moteur d'ingestion, pas de redémarrage, pas de redéploiement.

Gestion de la configuration et de l'injection de dépendance

Dans un système de production, les usines ont souvent besoin d'accéder à des dépendances externes telles que les connexions de base de données, les courtiers de messages ou les clients de l'API Directus. Le modèle de méthode Factory peut être étendu pour supporter l'injection de dépendance en passant un contexte ou un conteneur aux usines.

public abstract Sensor createSensor(String sensorId, Map<String, Object> config, SensorContext context);

L'objet fournit des ressources partagées comme la logage, les mesures et la persistance des données. Les usines de béton peuvent ensuite les transmettre aux gestionnaires de capteurs. Cela permet de garder le modèle souple tout en assurant que les instances de capteurs ont accès aux services nécessaires sans recourir à des monotones globaux.

Intégration avec Directus Data Flow

Directus peut également servir de moteur de stockage pour les données du capteur lui-même. Après la création d'un gestionnaire de capteur, le gestionnaire peut lire les données et les écrire dans Directus via son API REST ou GraphQL. Par exemple, la méthode pourrait pousser la lecture à une collection dans Directus. Cela crée une séparation nette : le gestionnaire de capteur ne sait que se procurer les données, tandis que le CMS gère le stockage, le contrôle d'accès et la présentation.

De plus, vous pouvez utiliser des crochets d'événements Directus ou des webhooks pour déclencher le traitement en temps réel lorsque des données de capteur sont ajoutées. Le modèle de la méthode Factory garantit que le système reste extensible à mesure que la flotte de capteurs évolue.

Avantages de l'utilisation du modèle de méthode d'usine

L'avantage principal d'appliquer le modèle de méthode d'usine à la gestion des données des capteurs est l'encapsulation de la logique de création []. Au lieu de reliure de votre code d'application principal avec des énoncés conditionnels comme , vous délèguez cette décision à la hiérarchie de l'usine.

  • Extension sans modification – De nouveaux types de capteurs peuvent être ajoutés en créant de nouveaux produits et usines, sans modifier le code client existant. Le principe ouvert/fermé est maintenu.
  • Raccordement réduit[ – Le code client dépend uniquement de l'interface et de la classe abstraite . Il n'a aucune connaissance des implémentations concrètes, ce qui facilite la refactorisation et le test du système.
  • Reconnaîtabilité des usines – Les usines peuvent être réutilisées dans différentes parties du système. Par exemple, le même peut être utilisé à la fois par le service d'ingestion et par un outil de simulation.
  • Configuration centralisée – Lorsqu'elle est combinée avec Directus, la cartographie sensor-type-to-factory est stockée à l'extérieur, permettant une reconfiguration dynamique sans changement de code.
  • Simplification des tests – Vous pouvez simuler ou piéger des usines de capteurs dans des tests unitaires, en isolant la logique sous test des dépendances matérielles réelles.
  • Gestion du cycle de vie cohérente[ – Les usines peuvent imposer une logique d'initialisation et de validation cohérente. Si une configuration de capteur n'est pas valide, l'usine peut la rejeter avant la création de tout objet de capteur, évitant ainsi les états semi-initialisés.

Inconvénients et atténuations potentiels

La méthode d'usine peut entraîner une explosion de classes (un produit + une usine par type de capteur). Dans un système avec des centaines de types de capteurs, cela peut devenir lourd. Les stratégies d'atténuation comprennent:

  • Utilisation d'une méthode d'usine paramétrée qui renvoie différentes implémentations de capteurs basées sur une chaîne de type (une approche simplifiée de -Simple Factory) lorsque le nombre de types est petit et stable.
  • Tirer parti de la charge dynamique de classe (réflexion) pour réduire la plaque de chaudière – mais être attentif à la sécurité et aux performances du type.
  • Grouper des capteurs similaires sous une seule usine (par exemple, un qui crée à la fois des capteurs thermocouple et des capteurs de RDT) et utiliser la configuration pour différencier.

Dans l'ensemble, les avantages l'emportent généralement sur la complexité accrue des systèmes qui devraient évoluer et se développer.

Meilleures pratiques de mise en œuvre

1. Gardez l'interface produit focalisée

Une interface de capteur ne doit déclarer que les méthodes essentielles pour l'acquisition et l'identification des données. Évitez de le gonfler avec des méthodes d'utilité ou des détails spécifiques au protocole.

2. Use factories for Complex Construction

Si un gestionnaire de capteur nécessite de multiples dépendances (client de communication, sérialiste de données, calcul de calcul), l'usine est l'endroit idéal pour les assembler.

3. Valider les configurations dans les usines

Les usines doivent valider que la carte de configuration contient toutes les clés requises et que les valeurs sont du type correct. La validation précoce empêche les pannes d'exécution et facilite le débogage.

4. Gérer le cycle de vie de l'usine

Si tel est le cas, assurez-vous qu'ils sont correctement initialisés et éliminés. Envisagez d'utiliser cadres d'injection de dépendance[ (comme Spring ou Guice) pour gérer les cycles de vie des usines et des capteurs dans les systèmes plus grands.

5. Intégrer la surveillance et l'exploitation forestière

Dans un système d'ingénierie, il est essentiel de savoir quels capteurs ont été mis en place et quelles usines sont actives. Ajoutez la connexion dans les méthodes d'usine pour enregistrer les événements de création de capteurs, et exposez les mesures (par exemple, le nombre de capteurs par type) à travers un outil de surveillance comme Prométhée.

6. Cartographies de l'usine à l'extérieur

Utilisez Directus ou un magasin de configuration similaire pour tenir la cartographie au lieu de la coder dur. Cela permet des mises à jour d'exécution et donne aux non-développeurs la capacité de gérer les types de capteurs.

Exemple réel du monde : Construire un système de gestion des capteurs de flotte avec Directus

Pour illustrer l'approche complète, envisagez un système qui gère des capteurs sur plusieurs sites. Le système utilise Directus comme moteur pour :

  • Stocker les définitions de capteur (type, classe de gestionnaire, config JSON).
  • Des relevés de capteurs.
  • Fournir une interface utilisateur de tableau de bord aux opérateurs.

Le moteur Java/Spring Boot commence par récupérer depuis Directus tous actifs . Pour chaque type, il instancie l'usine en utilisant la réflexion (le nom de classe d'usine est stocké dans la base de données). Il crée alors un haricot contenant toutes les usines disponibles.

Lorsqu'un nouveau capteur physique est en ligne, il envoie un message d'enregistrement via MQTT. Le moteur reçoit le message, extrait le type de capteur et l'identifiant, recherche l'usine correspondante depuis le registre et appelle avec l'identifiant et la configuration (également récupérés de Directus). L'objet résultant est stocké dans un clé par l'identifiant du capteur. Une tâche programmée appelle alors périodiquement sur chaque capteur actif et affiche la lecture à Directus.

Cette architecture s'est avérée extrêmement résistante au changement. Lorsqu'un nouveau type de capteur est développé, l'équipe n'a besoin que d'écrire le gestionnaire et l'usine, puis d'ajouter un enregistrement dans Directus. Le système le reprend automatiquement sur le prochain cycle de rafraîchissement (ou à la demande via un paramètre REST).

Ressources extérieures

Pour plus de détails sur le modèle de la méthode d'usine et son application dans les systèmes d'ingénierie, il convient d'examiner ces articles:

Conclusion

Le modèle de méthode Factory offre une solution éprouvée dans le temps pour gérer la création d'objets dans des systèmes qui doivent supporter une variété de types de capteurs. En découplant la logique d'instantialisation de l'implémentation du gestionnaire de capteurs, les ingénieurs peuvent construire des systèmes ouverts à l'extension mais fermés pour modification.

Combiné à une plate-forme de données flexible comme Directus, le modèle atteint tout son potentiel. Directus agit comme un magasin de configuration dynamique qui conduit la sélection d'usine à l'exécution, permettant des ajouts de capteurs à code zéro et une gestion centralisée de l'ensemble de la flotte de capteurs.

Que vous construisiez une plateforme IoT pour une usine intelligente, un réseau de surveillance environnementale ou un système d'acquisition de données de laboratoire, le modèle de méthode Factory – associé à Directus – fournit la base architecturale dont vous avez besoin pour gérer les données de capteurs de manière efficace et flexible.