Classes et méthodes Abstract

[infosam76]

C'est assez rare quand je dois utiliser ce type de classe mais ici cela m'arrangerais bien dans la librairie que je voudrais écrire.

Pour situer le problème, je voudrais écrire une librairie qui contient un objet connexion qui en fonction d'un paramètre attaque la bonne DB. Style si je lui dis de ce connecter à Access, ben ok et avec un autre objet du même type me vla partis sur Oracle.

Pour ce faire j'utilise la classe System.Data.Common.DbConnection que je dérive pour créer les différents constructeurs dont j'ai besoin.

Cette classe est une classe abstraire, donc je dois écrire le code toutes les fonctions et propriétés déclarées dans cette classe comme étant également abstraites.

Pour le constructeur cela me donne un truc du genre :

Code :

1
2
3
4
5
6
7
8
public EmDbConnection2(EmDbTypeConnection pTypeConnection, string sFilename)
                : base()
            {
                TypeConnection = pTypeConnection;
 
                if (TypeConnection == EmDbTypeConnection.DBACCESS || TypeConnection == EmDbTypeConnection.DBSQLITE)
                    FileName = sFilename;
            }

Ce qui m'a fois n'est pas bien compliqué. EmDbTypeConnection représentant une enum contenant les différents types de Db auquel je voudrais pouvoir me connecter.

ou j'ai un peu plus de mal à comprendre comment je pourrais m'en sortir malgré les différents tuto que j'ai parcouru, c'est dans ce cas ci :

J'obtiens une liste d'erreur du même type que celle ci, ce qui est normal vu que ce sont des membres déclarés comme abstract et donc que je suis cencé implémenter :

'EmData.EmDbConnection2' n'implémente pas le membre abstract hérité 'System.Data.Common.DbConnection.BeginDbTransaction(System.Data.IsolationLevel)' D:\Dropbox\Développements\EmData\EmDbConnection2.cs 20 18 EmData

Mon problème se situe donc à ce niveau ou je voudrais donc implémenté cette propriété:

Code :

public abstract string ConnectionString

Donc je me dis je vais utilisé le mot cle override et utilisé le mot clé base pour accédé à la propriété ConnectionString de la classe de base.

Code :

1
2
3
4
5
6
7
8
 
public override string ConnectionString
{
   get
   {
       return base.ConnectionString;
   }
}

Dans ce cas ci je ne vois pas la propriété ConnectionString dans la liste proposé par le mot clé "Base". Je me demande donc si je dois utiliser le mot clé "this" à sa place.

J'ai déjà joué avec tout cela et je dois avoué qu'après 2 ou ans je patauge un peu au redémarrage.

La solution que j'ai trouvé" jusqu'a présent pour utiliser ma classe c'est un truc du style :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
 
Class Toto
{
       DbConnection cmd = null; 
 
       public void Open()
      {
             // Init de l'objet con avec les différents paramètres nécessaires   
             // puis l'appel de la fonction membre de ma nouvelle classe : 
             cmd .Open(); ... // Avec Try catch etc 
      }
}

Donc en gros réécrire toute la classe en la surclassant, ce que je ne trouve pas trop propre.En sachant que j'ai également besoin des classes DbTransact, DbReader, DBadapter , etc ....

Quelqu'un pourrait il rallumé ma lanterne SVP

[Pongten]

Bonjour,

En fait, je pense que ce que tu t'y prends mal pour ce que tu cherches à faire...

Je pense que plutôt que chercher à dériver la classe DBConnection, tu devrais faire en sorte que ta classe retourne un objet DBConnection dont c'est l'utilité première.

Exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
public DBConnection CreateConnection(TypeConnection typeConnection)
{
    DbProviderFactories factory = null;
 
    switch(typeConnection)
    {
        case SqlServer:
              factory = DbProviderFactories.GetFactory("System.Data.SqlClient");
              return factory.CreateConnection();     
        case ....
    }
}

L'intérêt que DbConnection soit de type abstract sera justement de masquer le type concret qui est derrière...

[infosam76]

En fait tu vas dans le sens de ma réflexion.

En effet ma classe connexion fait ce que tu dis la.

Mais je pense que j'ai voulu aller trop loin en essayant de réécrire toutes les classes (donc DBReader, DbAdapter, DbCommand) alors que finalement il suffisait que j'utilise ces classes dans mes applications principales, mais juste en passant par une classe dérivée pour DBConnexion.

[youtpout978]

Bonjour,
tu n'es pas obligé de tout rendre abstrait, si tu veux pouvoir surchargé des éléments de ta classe de base tu peux utiliser virtual (le faite d'utiliser abstract t'empêchera d'y accéder depuis une classe qui en hérite étant donné qu'elle n'est pas sensé avoir été implémenté dans la classe mère).

Donc dans ta classe de base utilise:

Code :

 public virtual string ConnectionString { get; set; }

Comme ça tu pourras y accéder depuis les classes qui en héritent et tu pourras la surcharger au besoin.

[infosam76]

Bonjour,

Tout à fait d'accord, mon plus gros problème est que la classe DbConnexion fait partie du Framework donc je ne l'ai pas créée. Ce qui m’intéressait à la base c'est de pas me retapé les ProviderFactory dans toutes mes applications.

L'erreur que j'ai faite et d'avoir voulu réécrire (en dérivant) les autres objets du style DbCommand etc etc ...

[youtpout978]

tu peux faire un peu comme j'ai fais pour initialiser mon contexte EnttityFramework sur mon appli avec une connection string passée en paramètre

Classe de base:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 public abstract class Repository
    {
        private crazyEntities context;
        public crazyEntities Context
        {
            get
            {
                return context;
            }
 
        }
 
        public Repository(string connectionString)
        {
            context = new crazyEntities(connectionString);
        }
 
    }

Classe qui en hérite:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
        public LogGSRepository(string connectionString)
            : base(connectionString)
        {
        }
 
        public bool ExistePourCetteDate(DateTime date)
        {
            return Context.GS.Any(g => g.DateGS == date);
        }
 
        public GS LireParDate(DateTime date)
        {
            return Context.GS.Where(g => g.DateGS == date).SingleOrDefault();
        }
 
        public List<DateTime> ObtenirDateLogGS()
        {
            return Context.GS.OrderByDescending(d => d.DateGS).Select(g => g.DateGS).ToList();
        }
 
        public void EcrireLogGS(GS gs)
        {
            Context.AddToGS(gs);
            Context.SaveChanges();
        }
    }

j'ai ma classe mère qui s'occupe d'initialiser mon contexte et je l'utilise directement dans les classes filles, après tu peux ajouter tout le code de gestion des erreurs.

[worm83]

Bonjour,

Je crois que tu fait une erreur sur les classes abstraite, elle doivent contenir au MINIMUM une méthode abstraite....

Concernant le this ou base, je te conseil la lecture du modificateur "virtual" http://msdn.microsoft.com/fr-fr/libr...=vs.80%29.aspx

Ensuite pour te faciliter la tache concernant l'instanciation de telle ou telle implémentation un petit tour du coté du design pattern "abstract Factorie" devrait t'aider
En francais

Cordialement

[Bluedeep]

Envoyé par binou76

C'est assez rare quand je dois utiliser ce type de classe mais ici cela m'arrangerais bien dans la librairie que je voudrais écrire.

Pour situer le problème, je voudrais écrire une librairie qui contient un objet connexion qui en fonction d'un paramètre attaque la bonne DB. Style si je lui dis de ce connecter à Access, ben ok et avec un autre objet du même type me vla partis sur Oracle.

Il y a l'implémentation du DP Factory de connexion de ADO.Net qui fait ça très bien. Tu es sur que tu ne réinventes pas l'eau tiède ?

[Bluedeep]

Bonjour

Envoyé par worm83

Je crois que tu fait une erreur sur les classes abstraite, elle doivent contenir au MINIMUM une méthode abstraite....

C'est faux; ce n'est absolument pas nécessaire.

C'est l'inverse : seules les classes abstraites peuvent contenir des méthodes abstraites.

Mais une classe peut parfaitement être abstraite sans contenir de méthodes abstraites; le fait qu'une classe soit abstraitre indique seulement qu'elle ne peut pas être instanciée et ne sert quà être héritée.

[worm83]

Envoyé par Bluedeep

Bonjour



C'est faux; ce n'est absolument pas nécessaire.

C'est l'inverse : seules les classes abstraites peuvent contenir des méthodes abstraites.

Mais une classe peut parfaitement être abstraite sans contenir de méthodes abstraites; le fait qu'une classe soit abstraitre indique seulement qu'elle ne peut pas être instanciée et ne sert quà être héritée.

Effectivement ce que je dit n'est vrai qu'en JAVA.
Effectivement ça compile en c#, mais bon au niveau design si je dérive d'une classe abstraite et que je n'ai aucune méthode à overrider je me pose des questions.....


Toutefois il est inutile d'avoir toute les méthodes abstraite contrairement a ce que faisait penser la question initiale.

[worm83]

Je viens de regarder plusieurs sources, et la définition d'une classe abstraite est en général une classe partiellement définie possédant au moins une méthode abstraite (ou méthode virtuelle pure).

Dans beaucoup de langage (dont JAVA) une classe définie comme abstract mais sans méthode abstraite ne compile pas, c# étant multiparadigme et ayant une implémentation privilégiant la performance plutôt que le design (par exemple le mot clé virtual obligatoire en c# pour avoir une méthode virtuel et éviter de se coltiner une vtable a chaque appel) j'aurais du me douter que ceci était possible XD.

[Bluedeep]

Envoyé par worm83

Je viens de regarder plusieurs sources, et la définition d'une classe abstraite est en général une classe partiellement définie possédant au moins une méthode abstraite (ou méthode virtuelle pure).

C'est la définition qu'on trouve dans wikipedia (et un définition avec un "en général " n'est pas vraiment une définition); or l'article est un peu sujet à caution car plus loin on lit :

Une classe ne possédant que des méthodes abstraites est appelée interface

Ce qui est réducteur dans la mesure où on peut avoir une classe abstraite avec que des méthodes abstraites mais des variables membres en plus et, dans ce cas, une telle classe ne peut être substituée par une interface.

Bref, l'article est un peu flou, au moins dans ces énoncés.

[worm83]

je ne parle pas que de Wikipedia, bien au contraire c'est même la dernière source que j'ai consulté, la seule qui différencie c'est la msdn, mais elle parle de l'implémentation spécifique de c# donc c'est normal.
Et effectivement une classe non instanciable, et, dont les méthodes ne sont pas définie est ...... une interface ( car une interface peut aussi avoir des propriétés ect).

Bien sure Blue Deep on ne parle que de design Poo et non de fonctionnalité. Car une classe abstraite peut avoir effectivement des membres, mais a quoi sert une classe qu'on ne peut instancié avec des membres auquel on ne peut accéder .... à rien, si ce n'est d'interface.

Ensuite ce qui fait le choix entre une classe abstraite et une interface et le choix entre la notion d'héritage ou la notion de service.

[Bluedeep]

Envoyé par worm83

. Car une classe abstraite peut avoir effectivement des membres, mais a quoi sert une classe qu'on ne peut instancié avec des membres auquel on ne peut accéder .... à rien, si ce n'est d'interface.

Rien n'empêche d'accéder aux membres d'une classe abstraite. Ce qui ne servirait à rien, c'est une classe abstraite avec uniquement des méthodes abstraites et des membres privés (pourtant, ça compile, mais bon ....).

[worm83]

Envoyé par Bluedeep

Rien n'empêche d'accéder aux membres d'une classe abstraite. Ce qui ne servirait à rien, c'est une classe abstraite avec uniquement des méthodes abstraites et des membres privés (pourtant, ça compile, mais bon ....).

Alors OK,vu comme ca c'est vrai tu as raison.
Mais alors la mon cher BlueDeep tu ne pourra pas me dire que c'est "propre", on peut le faire, mais doit on le faire ?
Et l'ENCAPSULATION ??????

[Bluedeep]

Envoyé par worm83

Alors OK,vu comme ca c'est vrai tu as raison, mais alors la mon cher BlueDeep tu ne pourra pas me dire que c'est "propre", on peut le faire mais doit on le faire ?
Et l'ENCAPSULATION ??????

Je ne vois pas ce que l'encapsulation vient faire ici.
Un membre protected dans une classe abstraite est tout à fait légitime.

[worm83]

Envoyé par Bluedeep

Je ne vois pas ce que l'encapsulation vient faire ici.
Un membre protected dans une classe abstraite est tout à fait légitime.

Je parlais d'encapsulation car en général on préfère exposer une propriété ou une méthode d’accès (quand pas propriété) plutôt que le membre en lui même. D'ailleurs existe t'il une seule classe dans le Framework .Net qui expose un membre plutôt qu'une propriété (par exemple) ?


On peut le faire ok, il y a peut être des cas concret ou ce design est utile (si t'as des exemple), et c'est d'ailleur un design qui est certe possible en c# (qui est moins rigide que JAVA par exemple) mais qui sera réimplanté dans d'autre langages sous la forme abstract class (avec au moins une méthode abstraite) ou une Interface.

http://design-patterns.fr/introducti...orientee-objet

[Bluedeep]

Envoyé par worm83

Je parlais d'encapsulation car en général on préfère exposer une propriété ou une méthode d’accès (quand pas propriété)plutôt que le membre en lui même.

Ce qui tout à fait logique pour un accès "par le monde extérieur" mais pas une contrainte justifiée pour un accès par les classes dérivées.

D'ailleurs existe t'il une seule classe dans le Framework .Net qui expose un membre plutôt qu'une propriété (par exemple) ?

Dans les classe dérivées de EventArg, tu dois trouver des membres readonly publiques, mais de toute façon , je n'ai pas parlé de membre publiques.

On peut le faire ok, il y a peut être des cas concret ou ce design est utile (si t'as des exemple),

En voici un que j'ai sous la main un peu par hasard, piqués dans un projet dont j'ai piloté le dév il y a 5 ou 6 ans chez ce même client où je suis à l'instant; il s'agit d'un ensemble de classe controller en client lourd, avec un DP assez semblable à un MVC.

En haut, tu as un ensemble de classes abstraites; ici par exemple, une classe controller abstraites pour des controleurs manipulant des listes d'objets. On a des membres protected commun à toutes les classes dérivées, et des membres publics mais qui sont uniquement des events. Pas mal de code implémenté sur des méthodes virtuelles.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
	public abstract  class ListControlBaseController<TObject, TControl> : IListControl<TObject>, IDisposable
		where TObject : class, new()	
		where TControl : Control	
	{
		#region Events Declaration
 
		public event EventHandler<ControlObjectEventArgs<TObject>> SelectedObjectChanged;
		public event EventHandler<ControlObjectCancelEventArgs<TObject>> DeleteRequested;
		public event EventHandler<ControlObjectEventArgs<TObject>> UpdateRequested;
		public event EventHandler RefreshRequested;
		public event EventHandler NewRequested;
 
		public event EventHandler DoubleClick;
 
		#endregion
 
		protected bool _allowDelete = true;
		protected bool _allowNew = true;
		protected bool _allowUpdate = true;
		protected bool _allowExport = true;
		protected bool _allowRefreshRequest = false;
 
 
		protected readonly TControl _control;
		protected TObject _selectedObject;
		protected IList<TObject> _objects = new List<TObject>(); 
 
/* ET DU CODE */

De là des classes dérivées; exemples :

Controleur de ListView :

Code :

1
2
	public partial class ListViewController<TObject> : ListControlBaseController<TObject, ListView> 
		where TObject : class, new()

Controleur de DataGridView :

Code :

1
2
3
4
5
6
7
8
	public class DataGridViewController<TObject> : ListControlBaseController<TObject, DataGridView>, IDisposable where TObject : class, new() 
	{
		#region Events Declaration
 
		public event EventHandler<ControlObjectEventArgs<TObject>> ObjectRemoved;
		public event EventHandler<ControlObjectEventArgs<TObject>> ObjectAdded;
 
		#endregion

[worm83]

Ok merci pour l'exemple, mais du coup, dans ton cas quelle différence avec un constructeur en protected ?

(Effectivement les membres public readonly sont un cas à part)

Edit : Âpres relecture la question est "brute", mais n'est-ce pas l'utilité du constructeur protégé ?

[youtpout978]

Est-ce que ceci est la bonne méthode pour ma classe repository comme on est sur le débat du abstract et des membres protected ...

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public abstract class Repository
    {
        protected crazyEntities ctx;
 
        public Repository(string connectionString)
        {
            ctx = new crazyEntities(connectionString);
        }
 
        public Repository()
        {
            ctx = new crazyEntities();
        }
 
    }