Klasy i obiekty w C#: pola, metody, new i referencje

Klasa to typ, który definiujesz sam: łączy dane (pola) z kodem, który na tych danych działa (metodami). Obiekt to jedna instancja klasy, tworzona w czasie działania programu przez new. Jedna klasa, wiele obiektów, każdy z własnymi wartościami.

Deklarowanie klasy i tworzenie obiektów

Deklaracja klasy wymienia jej składowe w nawiasach klamrowych. Pola przechowują dane, metody zachowanie. new ClassName() alokuje obiekt i daje ci referencję do niego.

using System;

class BankAccount
{
    public string Owner;
    public decimal Balance;

    public void Deposit(decimal amount)
    {
        Balance += amount;
    }

    public bool Withdraw(decimal amount)
    {
        if (amount > Balance) return false;
        Balance -= amount;
        return true;
    }
}

class Program
{
    static void Main()
    {
        BankAccount maya = new BankAccount();
        maya.Owner = "Maya";
        maya.Deposit(120.50m);

        var omar = new BankAccount();
        omar.Owner = "Omar";
        omar.Deposit(40m);

        bool ok = maya.Withdraw(200m);

        Console.WriteLine($"{maya.Owner}: {maya.Balance}");
        Console.WriteLine($"{omar.Owner}: {omar.Balance}");
        Console.WriteLine($"Withdraw 200 succeeded: {ok}");
    }
}

Wynik:

Maya: 120.50
Omar: 40
Withdraw 200 succeeded: False

Każdy obiekt ma własne Owner i Balance. Wewnątrz metody Balance oznacza "saldo obiektu, na którym wywołano tę metodę", dlatego maya.Deposit i omar.Deposit zmieniają różne liczby. Ten niejawny obiekt jest dostępny jako this, gdy trzeba go nazwać.

Pola, którym nie przypiszesz wartości, zaczynają od wartości domyślnej: 0 dla liczb, false dla bool i null dla napisów oraz innych typów klasowych.

Składowe są tu public, żeby Main miało do nich dostęp. Prawdziwe klasy zwykle trzymają pola jako private i udostępniają zamiast nich właściwości, a reguły opisuje strona o modyfikatorach dostępu. Klasa może też deklarować konstruktor, który ustawia pola przy tworzeniu obiektu; omawia to strona o konstruktorach.

Klasa jest typem referencyjnym

Zmienna typu klasowego nie zawiera obiektu. Zawiera referencję do obiektu, który żyje na stercie. Przypisanie zmiennej kopiuje referencję, więc dwie zmienne mogą wskazywać ten sam obiekt.

using System;

class Order
{
    public string Customer;
    public int Items;
}

class Program
{
    static void AddItem(Order order)
    {
        order.Items++; // changes the caller's object
    }

    static void Main()
    {
        var first = new Order { Customer = "Liam", Items = 1 };
        var second = first; // same object, second name

        second.Items = 5;
        Console.WriteLine(first.Items);

        AddItem(first);
        Console.WriteLine(second.Items);

        var lookalike = new Order { Customer = "Liam", Items = 6 };
        Console.WriteLine(first == second);
        Console.WriteLine(first == lookalike);
    }
}

Wynik:

5
6
True
False

Widać tu trzy konsekwencje:

• Zmiana obiektu przez second jest widoczna przez first, bo obiekt jest tylko jeden.
• Przekazanie obiektu do metody przekazuje referencję. Metoda może zmienić pola obiektu, a kod wywołujący to zobaczy. (Przypisanie nowego obiektu do parametru wewnątrz metody nie wpływa na zmienną kodu wywołującego; do tego potrzeba ref.)
• == na dwóch instancjach klasy domyślnie porównuje referencje: "czy to ten sam obiekt?", a nie "czy mają te same wartości?". lookalike ma identyczne dane, a mimo to jest innym obiektem.

Jeśli chcesz kopiowania przy przypisaniu i porównywania wartości, zajrzyj do struktur, które są typami wartościowymi, albo do rekordów, które porównują się po wartościach.

null i NullReferenceException

Zmienna referencyjna może przechowywać null, czyli "brak obiektu". Użycie składowej przez null rzuca NullReferenceException, najczęstszy wyjątek czasu wykonania w kodzie C#.

using System;

class Address
{
    public string City;
}

class Customer
{
    public string Name;
    public Address Address; // starts as null
}

class Program
{
    static void Main()
    {
        var customer = new Customer { Name = "Noa" };

        Console.WriteLine(customer.Address == null);
        Console.WriteLine(customer.Address?.City ?? "no city on file");

        try
        {
            Console.WriteLine(customer.Address.City);
        }
        catch (NullReferenceException)
        {
            Console.WriteLine("NullReferenceException: Address was never set");
        }

        customer.Address = new Address { City = "Lisbon" };
        Console.WriteLine(customer.Address.City);
    }
}

Wynik:

True
no city on file
NullReferenceException: Address was never set
Lisbon

Rozwiązaniem prawie nigdy nie jest łapanie wyjątku. Ustal, dlaczego referencja jest null, i albo utwórz obiekt wcześniej, albo sprawdź go przed użyciem, albo użyj operatora warunkowego null ?., który zatrzymuje się i daje null zamiast rzucać wyjątek. ?? dostarcza wtedy wartość zastępczą. Oba operatory są omówione w typach nullable.

Nadpisywanie ToString

Każda klasa dziedziczy po object, który udostępnia ToString(). Odziedziczona wersja zwraca pełną nazwę typu (razem z przestrzenią nazw, jeśli typ w jakiejś jest), a to rzadko jest to, co chcesz wypisać. Nadpisz ją:

using System;

class Plain
{
    public string Name;
}

class Product
{
    public string Name;
    public decimal Price;

    public override string ToString() => $"{Name} ({Price:F2})";
}

class Program
{
    static void Main()
    {
        Console.WriteLine(new Plain { Name = "Mug" });

        var mug = new Product { Name = "Mug", Price = 8.5m };
        Console.WriteLine(mug);
        Console.WriteLine($"In cart: {mug}");
        Console.WriteLine("Total line: " + mug);
    }
}

Wynik:

Plain
Mug (8.50)
In cart: Mug (8.50)
Total line: Mug (8.50)

Console.WriteLine, interpolacja napisów i + z napisem same wywołują ToString(). Pokazuje go też debuger, więc nadpisanie jest przydatne nawet wtedy, gdy sam nigdy nie wypisujesz obiektu.

Inicjalizatory obiektów

Inicjalizator obiektu ustawia publiczne pola i właściwości zaraz po utworzeniu obiektu, w tym samym wyrażeniu. Czyta się go lepiej niż listę przypisań i dobrze sprawdza się wewnątrz literałów kolekcji.

using System;
using System.Collections.Generic;

class Ticket
{
    public string Event;
    public string Seat;
    public decimal Price = 25m; // field initializer: the default for every new ticket
    public List<string> Extras = new List<string>();
}

class Program
{
    static void Main()
    {
        var tickets = new List<Ticket>
        {
            new Ticket { Event = "Concert", Seat = "A12" },
            new Ticket { Event = "Concert", Seat = "A13", Price = 40m, Extras = { "Parking", "Poster" } },
        };

        foreach (var t in tickets)
        {
            Console.WriteLine($"{t.Seat}: {t.Price} ({t.Extras.Count} extras)");
        }
    }
}

Wynik:

A12: 25 (0 extras)
A13: 40 (2 extras)

Dwa szczegóły w drugim bilecie. Price = 40m nadpisuje 25m z inicjalizatora pola, bo inicjalizator obiektu działa po zbudowaniu obiektu. Extras = { "Parking", "Poster" } nie ma new: wywołuje Add na liście, którą pole już przechowuje, zamiast ją zastępować.

Inicjalizator obiektu nie jest konstruktorem. Może ustawiać tylko składowe dostępne z kodu wywołującego i nie może wymusić, że składowa w ogóle zostanie ustawiona. Gdy obiekt bez pewnych wartości jest niepoprawny, wymagaj ich w konstruktorze.

Klasy częściowe

Słowo kluczowe partial dzieli jedną klasę na kilka plików. Kompilator łączy części w jedną klasę.

// Invoice.cs
public partial class Invoice
{
    public decimal Subtotal;
    public decimal Total() => Subtotal + Tax();
}

// Invoice.Tax.cs
public partial class Invoice
{
    private decimal Tax() => Subtotal * 0.2m;
}

Każda część musi mieć partial, być w tej samej przestrzeni nazw i w tym samym projekcie. Typowe zastosowanie to kod generowany: projektanty WinForms, generatory źródeł i niektóre ORM-y piszą jedną część, a drugą zostawiają tobie, więc ponowne generowanie nigdy nie nadpisuje twojego kodu. Dzielenie ręcznie pisanej klasy na pliki tylko po to, żeby była krótsza, zwykle ukrywa klasę, która powinna być dwiema klasami.

Częste błędy

• Używanie obiektu przed jego utworzeniem. Pole typu klasowego jest null, dopóki nie przypiszesz mu new .... Pierwszy dostęp do składowej rzuca NullReferenceException.
• Oczekiwanie, że przypisanie kopiuje. var b = a; dla klasy daje drugą nazwę tego samego obiektu. Gdy potrzebujesz niezależnego obiektu, utwórz nowy i skopiuj wartości.
• Porównywanie obiektów przez == w oczekiwaniu na porównanie wartości. Dla klas porównuje referencje, chyba że klasa przeciąża == (jak robi to string). Porównaj odpowiednie pola albo nadpisz Equals.
• Wypisanie obiektu daje nazwę jego typu. Nadpisz ToString().
• Deklarowanie wszystkiego jako public. Działa w małych przykładach, ale pozwala dowolnemu kodowi wprowadzić obiekt w niepoprawny stan, na przykład ujemne saldo. Trzymaj pola jako prywatne i zmieniaj je przez metody, które pilnują reguł.