Aucune contrainte Ta classe reste une classe et la constante c’est juste une instance globale.

Si la classe a un constructeur public pas de problème. Tout dépend de ton code pas de la technique

Pour ma part je trouve inutile de sécuriser les classes au niveau de leur constructeur… le pattern singleton c’est avant tout la centralisation d’une instance unique et globale.

Sinon avec l’IoC (avec VEGAS par exemple) suffit d’utiliser dans la fabrique une définition d’objet singleton d’un objet du type de ta classe et plus besoin de se prendre la tête…

factory.getObject(« mysingleton »)

Plus de méthode getInstance() verbeuse dans les classes et plus de soucis pour tester les classes si on les laisse simple et public (unit test de meilleur qualité)

eKA+

Merci pour ton conseil judicieux.
Je rajoute cela de suite dans mon framework pour la gestion Singleton du Logger. Tellement simple que je n’y avais pas pensé…

Par contre pour le singleton à partir d’une classe simple et d’une constante du type de la classe, cela n’empêche pas d’instancier directement la classe ?
Ce qui peut être génant dans certains cas, il peut arriver qu’il soit obligatoire de passer par le singleton, et sans pouvoir instancier la classe directement.

/////////
package com.utils
{
public class MyClass {}
}

package com.utils
{
public const singleton:MyClass = new MyClass() ;
}
//////////

Je trouve cela plus élégant Par exemple pour ton exemple au dessus tu utilises le système de log de VEGAS pour ma part dans mes applications je crée un singleton de type ILogger :

http://code.google.com/p/astr/source/browse/trunk/AS3/trunk/src/astro/logging/logger.as

package astro.logging
{
import vegas.logging.ILogger;
import vegas.logging.Log;

/**
* The logger of the application.
*/
public const logger:ILogger = Log.getLogger( « myApplication ») ;

}

Comme cela plus de soucis pour utiliser des logs partout dans l’application avec ce singleton.

EKA+