3 votes

Différence entre C# et VB.NET pour les valeurs par défaut des membres privés

En C#, j'ai le code suivant :

  1. une classe de base avec une fonction virtuelle InitClass()
  2. une classe enfant qui remplace la fonction InitClass(). Dans cette fonction, je définis une variable privée
  3. une propriété publique exposant mon champ privé

    namespace InheritenceTest
    {
        class Program
        {
            static void Main(string[] args)
            {
                ChildClass childClass = new ChildClass();
                Console.WriteLine(childClass.SomeString);
                Console.ReadLine();
            }
        }
    
        public class BaseClass
        {
            public BaseClass()
            {
                InitClass();
            }
    
            protected virtual void InitClass()
            {
                // Do Nothing here
            }
        }
    
        public class ChildClass: BaseClass 
        {
            private string _someString = "Default Value";
            public ChildClass()
            { 
            }
    
            protected override void InitClass()
            {
                base.InitClass();
                _someString = "Set in InitClass()";
            }
    
            public string SomeString
            {
                get { return _someString; }
                set { _someString = value; }
            }
        }
    }

La sortie de la console de ce programme est "Set in InitClass()".

Maintenant, j'ai converti ce morceau de code en VB.NET.

Imports System
Imports System.Collections.Generic
Imports System.Text

Namespace InheritenceTest
    Module Program
        Public Sub Main(ByVal args As String())
            Dim childClass As New ChildClass()
            Console.WriteLine(childClass.SomeString)
            Console.ReadLine()
        End Sub
    End Module

    Public Class BaseClass
        Public Sub New()
            InitClass()
        End Sub

        Protected Overridable Sub InitClass()
            ' Do Nothing here 
        End Sub
    End Class

    Public Class ChildClass
        Inherits BaseClass
        Private _someString As String = "Default Value"
        Public Sub New()
        End Sub

        Protected Overrides Sub InitClass()
            MyBase.InitClass()
            _someString = "Set in InitClass()"
        End Sub

        Public Property SomeString() As String
            Get
                Return _someString
            End Get
            Set(ByVal value As String)
                _someString = value
            End Set
        End Property
    End Class
End Namespace

Le résultat de ce programme VB.NET est "Valeur par défaut".

En regardant le code lors du débogage (le code VB.NET), vous voyez que lorsque le constructeur a fini de faire son travail, la valeur par défaut est définie, alors qu'en C#, c'est l'inverse (la valeur par défaut est d'abord définie, puis le constructeur est appelé).

Quelqu'un peut-il m'expliquer pourquoi c'est le cas ? Et laquelle des deux langues est "correcte" ?

5voto

JaredPar Points 333733

Les 2 langues diffèrent simplement dans leur façon d'aborder ce problème particulier.

Pour savoir pourquoi cela se fait de cette manière en C#, vous devriez consulter la série de blogs d'Eric sur le sujet.

Quant au pourquoi de VB.Net. Je ne sais pas vraiment pourquoi VB.Net a choisi cette approche particulière. Je pense qu'il s'agit d'un problème de compatibilité avec VB6, mais je ne suis même pas sûr que VB6 ait eu des scénarios similaires.

1voto

Akash Kava Points 18026

En plus de @JaredPar

La seule raison pour laquelle VB.NET a un schéma d'initialisation différent est que VB a été conçu comme cela depuis le passé, s'ils changent cette séquence dans VB.NET, les programmeurs qui migrent de VB à VB.NET auront des difficultés et certains problèmes de compatibilité pourraient survenir car vous pouvez toujours importer la plupart de votre ancien code VB dans VB.NET.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X