Discussion :

[_Fabien]

Bonjour,

J'ai un problème simple, qui est général en POO (C#, VB.Net, C++, etc.). J'ai une classe ID (identifiant unique de chaque objet) avec un membre id qui sert juste à "nourrir" les classes héritantes (Personne, voiture, Chambre, etc.). Donc elle est inutile dans mes vues/formulaires. Aussi je voudrais la rendre invisible (pour que mon code soit plus propre). Voici le code en VB.Net (rien de plus classique) :

Public Class ClasseID
private _id As Integer

Public Property id() As Integer
Get
Return _id
End Get
Set(ByVal value As Integer)
_id = value
End Set
End Property

(pas de constructeur)
End Class

Public Class Bidule
inherits ClasseId
(...)
end class

J'ai réussi en partie à résoudre mon problème comme ceci :

Public Class ClasseID
Friend _id As Integer
End Class


Ainsi dans mes formulaires ou un test de console, un objID.id n'est plus possible, mais on peut toujours faire :

dim objID as classeID

J'aimerais que classeID disparaisse des déclarations. Alors, j'ai fait un :

Friend Class ClasseID
Friend _id As Integer
End Class

Mais, mes classes héritantes grognent ! (erreurs)

J'espère que je me suis fait comprendre. En une phrase, je veux que ma ClasseID serve juste pour les classes héritantes, mais en dehors (formulaire, console), qu'elle n'apparaisse plus dans les déclarations (car inutile)

Désolé pour ce message long, mais je pense que la(les) réponse(s) (si vous souhaitez répondre) sera(seront) plus courte(s)

[tomlev]

déclare _id en tant que Protected
comme ça ce n'est pas accessible par le code externe à la classe, mais les classes héritées peuvent y accéder

[_Fabien]

Je te remercie pour l'info. Après il faudra que je regarde la différence entre protected et friend, car avec ce dernier ça marche aussi comme tu l'as dit.

Et pour la classe pour qu'elle n'apparaisse pas dans le module de test ou le formulaire, comment je dois m'y prendre ?

[tomlev]

La classe de base est obligée d'être au moins aussi visible que ces classes dérivées. Autrement dit, si tu as une classe A, et une classe B qui hérite de A, B ne pourra être publique que si A est publique aussi. De toutes façons, qu'est-ce que ça peut faire que A soit visible ? Rien ne t'oblige à la mentionner explicitement...
Ou alors j'ai pas compris ton problème...

[_Fabien]

C'était juste pour rendre plus "propre" mon programme. Comme la classe ClassID sert juste à "nourrir" les classes héritantes et rien d'autres, je voulais soustraire celle-ci aux programmes de console ou formulaire. Pourquoi rendre visible dans un formulaire une classe (ID dans mon exemple) qui ne sera jamais instanciée car pas de constructeur ou utilisée via les Get/set ?

Mais je pense que ce n'est pas la norme. De plus après ce que tu m'as dit dans ton dernier message, ça va compliquer le code plus que l'éclaircir. Je vais remettre ce membre private et rajouter les property Get/set.

Sinon, question subsidiaire : ça t'arrive/vous arrive souvent de déclarer des membres protected ou friend dans une classe, surtout que celle-ci est contenue avec d'autres classes dans une DLL ? Private est la norme si je puis dire ?

[tomlev]

Si ClassID n'est jamais instanciée, déclare là comme abstraite. Mais elle doit forcément être publique, sinon les classes dérivées ne peuvent pas non plus être publiques.

Sinon, question subsidiaire : ça t'arrive/vous arrive souvent de déclarer des membres protected ou friend dans une classe, surtout que celle-ci est contenue avec d'autres classes dans une DLL ? Private est la norme si je puis dire ?

Il n'y a pas de "norme", ça dépend de ce que tu veux en faire... perso je n'utilise jamais Friend (ou internal en C#), je trouve que c'est juste une verrue pour pallier une mauvaise conception. En général on peut se débrouiller avec Public/Private/Protected

[_Fabien]

Beh je te remercie pour le temps consacré. Bon je ne vais pas cliquer "Topic résolu" car je vais voir de plus près ce qu'est vraiment une classe abstraite (j'ai un doute).

[tomlev]

C'est simplement une classe qu'on ne peut pas instancier (généralement parce que certaines méthodes déclarées ne sont pas implémentées, mais ce n'est pas une obligation). Pour l'instancier il faut créer des classes qui en dérivent.
Le mot-clé correspondant en Visual Basic est MustInherit

[cinemania]

une classe abstraite est une classe qui ne peut en aucun cas être instanciée.

En fait elle sert d'interface commune entre les classes héritières, mais à l'inverse d'un "interface", elle peut contenir du code "commun" ou "par défaut", des constructeurs de base (attention à ce qu'ils soient protected !)
elle peut contenir des déclarations d'attributs privés (allocation mémoire donc).

Ce n'est pas juste un profil comme le serait un interface, c'est une classe a part entière, qui pour des raisons X ou Y n'a pas tout son code "défini".
En fait si tu veux voici un exemple bateau :

Quel est le dénominateur entre un chat et un chien ? ce sont tout deux des animaux, si on voulais modeliser nos compagnons a quatre pattes, on aurait donc une classe abstraite Animal, et 2 héritières Chat et Chien.
On pourrait meme y ajouter une troisieme héritière, Canard.
Et a ceci une méthde Courrir() dans la classe animal, car a priori, tous les animaux sont suceptible de courrir.
Cependant chaque animal se meut d'une façon différente, et défini des actions particulieres lorsqu'il cours.
La méthode Courrir sera donc une méthode abstraite, que chaque héritière DEVRA IMPERATIVEMENT implémenter.

Les notions de surcharge, sont toujours présentes, et même encore plus que dans le cas d'un héritage en provenance d'une classe normale.

Ensuite j'ai un peu de mal avec ton explication du besoin.
Un formulaire est un IHM... dans l'IHM tu est libre de faire apparaitre ce que tu souhaite non et disparaitre ce que tu ne souhaite pas.

Maintenant si tu parle de l'exposition des membres de ton assembly a des développeurs qui souhaiterais l'utiliser c'est tout à fait différent.
Cependant le fait que chacune des classes en question ai une id propre... la classe ClassID n'est pas fondamentallement une classe abstraite ni la racine de ton arbre hierarchique si tes identifiants sont représenté et totalement modélisé dans ClassID... dans ce cas il est préférable que cette classe devienne "friend/internal" à ton assembly et qu'elle soit utilisée comme propriété interne à ton assembly.
En revanche il faudra une classe abstraite qui déclare un champ private identifiant de type ClassId par exemple et une propriété pourquoi pas friend lisible//accessible uniquement dans ton assembly.

Exemple : si l'identifiant est un identifiant unique avec tant de bit pour ceci, tant de bit pour cela, tu peux souhaiter modéliser ton identifiant dans une classe ClassID.
Ensuite chacune des classes ayant un identifiant unique va avoir un membre de type ClassID pourquoi pas défini dans une classe abstraite à toutes ces classes héritières.

Enfin bon c'est ma vision et c'est dans le cas ou tu parle bien de l'exposition des interfaces de ton assembly au monde extérieur.
Parce qu'en ce qui concerne l'IHM peut importe comment tu programme, que tu cache ou non dans la déclaration de la classe, l'identifiant, si tu ne souhaite pas l'afficher dans un formulaire... tu es libre, c'est toi qui créer le formulaire après tout.

[_Fabien]

Wouaaaaahhh

Tout ce paragraphe pour moi, cinemania ! Merci beaucoup beaucoup. Sinon, j'ai lu vos messages depuis un moment, mais je ne savais pas quel commentaire apporter (et je ne sais toujours pas). Je suis dans la réflexion.

Sinon, quand tu parles de ton assembly, c'est quoi ? Le fichier "AssemblyInfo.vb" ou l'assemblage de mon projet (dll, vb, designer.vb, etc.) ? C'est pour mieux comprendre ton message

Une autre question facultative (je chercherai par moi-même sinon). Les classes abstraites existent bien en VB.Net ?

Ma classe est donc abstraite si j'ajoute :

Public MustInherits Class ClasseID
private _id As Integer

Public Property id() As Integer

Get
Return _id
End Get

Set(ByVal value As Integer)
_id = value
End Set

End Property

(pas de constructeurs)
(pas de méthodes)
End Class

Je me suis documenté sur MustInherits sur MSDN. Je complèterai mon message la semaine prochaine.

[tomlev]

d'après la MSDN:

assembly
A collection of one or more files that are versioned and deployed as a unit. An assembly is the primary building block of a .NET Framework application. All managed types and resources are contained within an assembly and are marked either as accessible only within the assembly or as accessible from code in other assemblies. Assemblies also play a key role in security. The code access security system uses information about the assembly to determine the set of permissions that code in the assembly is granted. See also: private assembly, shared assembly.

Dans la pratique, c'est généralement un exe ou une dll...

[_Fabien]

J'ai regardé aussi MSDN, version française, pour l'assembly, je n'ai pas compris grand chose, mais d'après une personne avec qui j'ai parfois des contacts, elle confirme ce que tu as dis : mes formulaires, mes DLL et le reste forment un assembly sous forme d'exécutable.

Ca me fait penser à l'édition de liens en C. Je mets tout çà entre parenthèse pour l'instant, j'y reviendrai ultérieurement. Merci à vous deux