Delegat zwracający bool w C# – pułapka o jeden znak

private static bool IsAdult(int age) => age >= 18;
private static bool IsAdultWrong(int age) => age > 18;

Dwie metody. Identyczna sygnatura – (int) → bool. Jedna sprawdza „18 i więcej”, dokładnie tak, jak sugeruje jej nazwa. Druga sprawdza „więcej niż 18” – jeden znak różnicy w kodzie źródłowym.

Podepnij obie pod ten sam delegat i wywołaj rule(18). Pierwsza zwróci true. Druga zwróci false. Kompilator nie zgłosi ani jednego ostrzeżenia w żadnym z tych dwóch przypadków.

To jest sedno delegatów zwracających bool: mechanika przypisania i wywołania jest identyczna jak przy każdym innym typie zwracanym, ale kompilator sprawdza wyłącznie sygnaturę, nigdy operator porównania w środku metody.

Delegat, który podejmuje decyzję

Do tej pory delegat w tej serii albo coś robił (void), albo coś zwracał (string, int). Delegat zwracający bool robi coś nowego: odpowiada na pytanie.

using System;
namespace BeginnerDelegateAgeGateExample;

// 1. Definicja delegata – przyjmuje int, zwraca bool (decyzję)
public delegate bool AgeRule(int age);

public class Program
{
    public static void Main()
    {
        int[] goscie = { 15, 20, 40, 70 };

        Console.WriteLine("=== STREFA DLA DOROSŁYCH (18+) ===");
        // KROK 1: Podpinamy regułę dla dorosłych
        AgeRule rule = IsAdult;
        CheckAccess(goscie, rule);

        Console.WriteLine("\n=== STREFA SENIORA (65+) ===");
        // KROK 2: Pod TĘ SAMĄ zmienną podpinamy inną regułę
        rule = IsSenior;
        CheckAccess(goscie, rule);

        Console.WriteLine("\n=== STREFA VIP (własna reguła “w locie”) ===");
        // BONUS: Reguła zdefiniowana lambdą, bez osobnej metody
        rule = wiek => wiek >= 21 && wiek <= 60;
        SprawdzGosci(goscie, rule);
    }

    // Metoda pomocnicza – nie wie NIC o konkretnej regule,
    // po prostu woła przekazany delegat dla każdego gościa
    private static void CheckAccess(int[] goscie, AgeRule rule)
    {
        foreach (int wiek in goscie)
        {
            // 🔥 Wywołujemy delegat – on decyduje, nie ta metoda!
            bool wpuszczony = rule(wiek);
            string status = wpuszczony ? "✅ WPUSZCZONY" : "⛔ ODRZUCONY";
            Console.WriteLine($"Wiek {wiek}: {status}");
        }
    }

    // Metoda #1 pasująca do delegata AgeRule (int -> bool)
    private static bool IsAdult(int age) => age >= 18;

    // Metoda #2 pasująca do delegata AgeRule (int -> bool)
    private static bool IsSenior(int age) => age >= 65;
}

Definicję czytamy jak zawsze od prawej do lewej: (int age) – przyjmuje jedną liczbę całkowitą; bool – zwraca decyzję tak/nie; AgeRule – tak nazywa się nowy typ. Metoda CheckAccess pilnuje dwóch zupełnie różnych stref, nie zmieniając ani jednej własnej linijki, zmienia się tylko reguła podpięta pod rule.

Zasada: 
delegat zwracający bool wstawia się dokładnie tam, gdzie zwykły warunek logiczny w if, w &&, w operatorze ?:. 
rule(wiek) zachowuje się jak każdy inny wyrażenie logiczne w Twoim kodzie.

Wywołanie jako warunek

W poprzednim wpisie o delegacie z wieloma parametrami wynik wywołania trafiał do zmiennej i był wypisywany. Tutaj wynik steruje przepływem programu:

if (rule(20))
{
    Console.WriteLine("Wejście dozwolone.");
}

Nie ma tu nic magicznego – rule(20) zwraca bool, więc if traktuje je jak każdy inny warunek. Różnica względem zwykłej metody bool polega wyłącznie na tym, że konkretna reguła stojąca za rule może się zmienić w trakcie działania programu, bez zmiany kodu, który ją wywołuje.

Pułapka #1: zła granica warunku daje zły wynik bez błędu

private static bool IsAdultWrong(int age) => age > 18;

AgeRule rule = IsAdultWrong;
bool wynik = rule(18);

IsAdultWrong przyjmuje int i zwraca bool – sygnatura pasuje idealnie do AgeRule. Kompilator nie ma żadnego powodu, żeby zaprotestować.

Różnica jest w jednym znaku: > zamiast >=. Dla wieku dokładnie 18 ta metoda zwraca false – osoba, która właśnie skończyła 18 lat, zostaje odrzucona, mimo że reguła w założeniu miała brzmieć „18 i więcej”.

To jest trzecia odsłona tej samej rodziny błędów, którą znasz z poprzednich wpisów tej serii: w delegacie zwracającym wartość ginął cały wynik, w delegacie z wieloma parametrami zamieniały się nazwy parametrów, tutaj myli się granica warunku. Za każdym razem kompilator widzi wyłącznie sygnaturę – int na wejściu, bool na wyjściu – i nigdy logikę schowaną w środku.

Zasada: 
Poprawna sygnatura nie oznacza poprawnej reguły.
Przy delegatach zwracających bool sprawdź granice porównań osobno
– kompilator tego za Ciebie nie zrobi.

Pułapka #2: liczba parametrów to wciąż część sygnatury

private static bool HasAccessLevel(int age, int minLevel) => age >= minLevel;

AgeRule bad = HasAccessLevel;
// ❌ CS0123: No overload for 'HasAccessLevel' matches delegate 'AgeRule'

Dwa parametry zamiast jednego. Ta sama zasada, którą znasz z wcześniejszych wpisów, tam różnica wynosiła zero kontra jeden albo trzy kontra dwa, tutaj dwa kontra jeden. Liczba parametrów zawsze musi się zgadzać co do joty, niezależnie od tego, co delegat zwraca.

Pułapka #3: typ zwracany nadal się liczy

private static void PrintIsAdult(int age) => Console.WriteLine(age >= 18);

AgeRule bad2 = PrintIsAdult;
// ❌ CS0407: 'void Pulapki.PrintIsAdult(int)' has the wrong return type

PrintIsAdult wypisuje decyzję, ale jej nie zwraca, dokładnie ta sama różnica, co przy PrintSum i PrintGreeting z wcześniejszych wpisów tej serii. Delegat zwracający bool nie akceptuje metody zwracającej void, nawet jeśli „w praktyce robi to samo”.

Ściągawka na code review

Po co to, skoro mogę po prostu napisać if?

Tak samo jak przy poprzednich wpisach w tym przykładzie faktycznie nic nie zyskujesz, dopóki cała logika siedzi w jednej metodzie Main.

Wartość pojawia się, gdy reguła jest wybierana dynamicznie, na przykład na podstawie konfiguracji albo typu użytkownika, tak jak w przykładzie z ochroniarzem: ten sam kod pilnujący wejścia obsługuje strefę dla dorosłych, strefę seniora i dowolną inną strefę, o ile dostanie odpowiednią regułę.

Ten kształt – jedno wejście, decyzja na wyjściu – to dokładnie to, co w nowoczesnym C# reprezentuje gotowy Predicate<int>: ten sam kontrakt (T) → bool, tylko bez własnej definicji delegate. To również fundament pod metodę .Where() w LINQ, która woła dokładnie taki predykat dla każdego elementu kolekcji.

Podsumowanie

• Delegat zwracający bool wstawia się dokładnie tam, gdzie zwykły warunek logiczny – w if, &&, ?:. Mechanika przypisania i wywołania się nie zmienia.
• Poprawna sygnatura nie oznacza poprawnej reguły. Kompilator sprawdza typy, nigdy operator porównania w środku metody: > zamiast >= przechodzi bez ostrzeżenia.
• To trzecia odsłona rodziny błędów bez komunikatu kompilatora w tej serii: ginący wynik, zamienione parametry, zła granica warunku.
• CS0123 i CS0407 wracają w tej samej roli co przy delegatach void, string i int z wcześniejszych wpisów.
• Predicate<int> to ten sam kontrakt co własny delegate bool AgeRule(int age), tylko bez własnej definicji typu i fundament pod .Where() z LINQ.

📂 Kod źródłowy: github.com/dev-hobby/CSharpDelegates — projekt DevHobby.L05-AgeGate
📘 Darmowa roadmapa Junior .NET Developer: dev-hobby.pl/lista-vip

Zadanie na 5 minut: 

zdefiniuj delegate bool AccessRule(int age, bool hasPermission);,
napisz metody AllowAdults (tylko pełnoletni) i AllowWithPermission (pełnoletni lub ma pozwolenie), a potem przypisz obie kolejno do tej samej zmiennej i wywołaj dla minimum trzech zestawów danych. Napisz w komentarzu, dla którego zestawu danych obie metody dają różny wynik.

Zobacz

• Delegat z wieloma parametrami w C# – pułapka bez ostrzeżenia kompilatora, cz. 2
• Delegat zwracający wartość w C# – pułapka bez ostrzeżenia kompilatora, cz. 1
• Delegat z parametrem w C# – dlaczego nazwa parametru nic nie znaczy, dopóki nie ma z czym jej pomylić
• LINQ w C# – kompletny przewodnik – Predicate<T> i .Where() w akcji

📦 Kod źródłowy tego artykułu: zobacz na GitHub