Ma conception intègre une petite abstraction de base de données, dans laquelle je implémente chaque base de données en tant que singleton (puits, un objet ), avec des méthodes personnalisées sur la base de données pour les appels de code (c'est principalement un analyseur de journal, dumping statistiques intéressantes à une base de données).
J'aimerais construire les classes de base de données Singleton si possible, de sorte que, à l'exécution, chacune est construite avec des valeurs de configuration (et ces valeurs restent constantes pour le reste du temps d'exécution du programme). Cela me permettrait de mieux tester le code (car je peux vous moquer des bases de données à l'aide de Mockito ou de certaines telles).
Je n'apprends toujours que Scala, mais il semble qu'il n'ya aucun moyen de joindre un constructeur à un singleton et apprécierait toute commission sur ce problème - y a-t-il une meilleure façon de faire ce que je fais? Y a-t-il une manière préférée de construire un singleton?
Cheers à l'avance pour toute aide.
3 Réponses :
Il suffit de mettre le code de constructeur dans le corps de la définition d'objet:
Merci tas pour la réponse rapide. Mon inquiétude est que je veux passer des arguments au constructeur. En pensant à ce que ce soit, je réalise ce qu'est un hachoir sale. Je devrai reconsidérer mon design.
Oui c'est un hack. Les singletons sont des états globaux et le point de Scala est de permettre un traitement parallèle invisible. Cela signifie que vous ne pouvez pas avoir d'état global.
@Frio, il peut être significatif de rappeler que le constructeur d'objet (corps) n'est pas exécuté tant que vous ne faites référence à l'objet ni à celui-ci (champs ou méthodes) qui vous permet de contrôler la construction de l'objet.
@fishtoprecords, l'objectif est d'autoriser un traitement parallèle invisible - je veux divers acteurs de traitement de journal pour accéder à une instance de base de données globale, donc je pensais que Singleton était un bon ajustement (plutôt que chaque suivi de la base de données séparément). Toutefois, pour la qualification, je souhaite que le singleton soit instancié avec une configuration particulière (donc au lieu d'une connexion, je peux transmettre une simule). Je pense que maintenant, je ferais mieux de laisser chaque acteur parler à la base de données individuellement. Ce serait bien si je pouvais trouver un moyen de partager un pool de connexion, mais ce n'est pas vraiment critique. Merci pour l'entrée :).
Plutôt que d'utiliser un singleton (qui est difficile à tester). Quiconque Création des acteurs pourrait créer une usine de session de base de données et la transmettre à chaque acteur, alors elle est toujours partagée ... et testable.
Ce n'est pas une mauvaise idée du tout. Je pense que la façon dont je suis installé est une classe d'abstraction DB individuelle pour chaque acteur (au lieu d'un singleton commun), et oui, en passant une usine au démarrage (bien que je pensais que Scala m'aiderait à laisser quelques modèles de GOF; ))). Merci Nigel.
Je ne sais pas si ceci est ce que vous recherchez, mais comme l'explique l'article, utilisez la méthode Appliquer sans étendre la classe de base
p>
case class Foo(name:String)
object Foo { def apply(name:String) = new Foo(name) }