Odpowiedź.

W Visual Basic właściwość (Property) może być zadeklarowana na dwa sposoby:

• Pełna właściwość (z własnymi blokami Get/Set): pozwala kontrolować dostęp do danych, wykonywać dodatkowe sprawdzenia lub działania podczas odczytu/zapisu wartości.
• Automatyczna właściwość (auto-implemented): skrócona notacja, w której Get/Set nie są pisane jawnie, a automatycznie tworzone jest prywatne pole:

' Automatyczna właściwość
Public Property Name As String

' Pełna właściwość
Private _age As Integer
Public Property Age As Integer
    Get
        Return _age
    End Get
    Set(value As Integer)
        If value < 0 Then Throw New ArgumentException("Wiek nie może być ujemny")
        _age = value
    End Set
End Property

Niuanse przy użyciu Set:

• Słowo kluczowe Value to pseudoparametr, który odnosi się do przypisywanej wartości.
• Wewnątrz Set można przeprowadzać walidację, logowanie, uruchamianie zdarzeń.
• Zmieniając anonimowe pole przy automatycznej realizacji, nie można kontrolować.

Kiedy używać:

• Automatyczne właściwości — gdy potrzebny jest najprostszy „pojemnik”.
• Pełne właściwości — gdy przy ustawianiu/odbieraniu potrzebna jest logika (walidacja, powiadomienia, obliczenia).

Pytanie z haczykiem.

Jakie są konsekwencje błędu przy pisaniu Set(ByVal value As Integer) zamiast Set(value As Integer) w VB.NET? Dlaczego nie warto tak pisać?

Odpowiedź: Składnia VB.NET nie wymaga (i nie wspiera) jawnego deklarowania parametru ByVal w Set — używaj po prostu Set(value As Type). Jeśli napiszesz Set(ByVal value As Integer), doprowadzi to do błędu kompilacji.

Przykład błędnego kodu:

'Set(ByVal value As Integer) — błąd kompilacji
Public Property Prop As Integer
    Set(ByVal value As Integer)
        ...
    End Set
End Property

W klasycznym VB6 taka składnia była dopuszczalna, ale w VB.NET wymagana jest dokładnie Set(value As Type).

---

Historia

Na dużym projekcie podczas automatycznego przenoszenia kodu z VB6 do VB.NET dodano ByVal w Set — kompilator zgłaszał tajemnicze błędy, których długo nie mogli zlokalizować, ponieważ linters nie pokazywał wyraźnej przyczyny.

Historia

W projekcie z obsługą dużych zestawów danych używano automatycznych właściwości do przechowywania danych, a potem pojawił się problem: trzeba było śledzić, czy właściwość się zmienia, aby automatycznie rejestrować każdą zmianę. Konieczne było zmienienie automatycznych właściwości na pełne — w efekcie straciliśmy dużo czasu na refaktoryzację, ponieważ początkowo nie uwzględniono, że może być potrzebna dodatkowa logika w Set.

Historia

Przy kopiowaniu obiektów referencyjnych przez automatyczne właściwości zapomniano zaimplementować deep copy przez Get/Set. W rezultacie otrzymano duplikaty referencji do tego samego obiektu; zmiana w jednej instancji prowadziła do zmiany w drugiej.