Obejście zasad w Czarodziejach i Wojownikach

W tej serii postów na blogu Eric Lippert opisuje problem z projektowaniem obiektowym, wykorzystując jako przykład kreatorów i wojowników:

abstract class Weapon { }
sealed class Staff : Weapon { }
sealed class Sword : Weapon { }

abstract class Player 
{ 
  public Weapon Weapon { get; set; }
}
sealed class Wizard : Player { }
sealed class Warrior : Player { }

a następnie dodaje kilka zasad:

• Wojownik może używać tylko miecza.
• Czarodziej może używać tylko laski.

Następnie demonstruje problemy, na które napotykasz, gdy próbujesz egzekwować te reguły za pomocą systemu typu C # (np. Czyniąc Wizardklasę odpowiedzialną za upewnienie się, że czarodziej może korzystać tylko z personelu). Naruszasz Zasadę zastępowania Liskowa, ryzykujesz wyjątki w czasie wykonywania lub kończysz się trudnym do rozszerzenia kodem.

Rozwiązanie, które wymyślił, polega na tym, że klasa Player nie dokonuje weryfikacji. Służy wyłącznie do śledzenia stanu. Następnie zamiast dać graczowi broń:

player.Weapon = new Sword();

stan jest modyfikowany przez Commands i zgodnie z Rules:

... tworzymy Commandobiekt o nazwie, Wieldktóry przyjmuje dwa obiekty stanu gry, a Playeri a Weapon. Kiedy użytkownik wydaje polecenie systemowi „ten czarodziej powinien dzierżyć ten miecz”, wówczas polecenie to jest oceniane w kontekście zestawu Rules, który tworzy sekwencję Effects. Mamy taki, Rulektóry mówi, że kiedy gracz próbuje użyć broni, efektem jest to, że istniejąca broń, jeśli taka istnieje, zostaje upuszczona, a nowa broń staje się bronią gracza. Mamy kolejną zasadę, która wzmacnia pierwszą zasadę, która mówi, że efekty pierwszej reguły nie mają zastosowania, gdy czarodziej próbuje użyć miecza.

Zasadniczo podoba mi się ten pomysł, ale mam obawy, jak można go wykorzystać w praktyce.

Wydaje się, że nic nie stoi na przeszkodzie, aby deweloper omijał Commandsand Rule, po prostu ustawiając Weaponna Player. WeaponNieruchomość musi być dostępny przez Wieldkomendę, więc nie może być wykonana private set.

Więc, co ma zapobiec deweloper z tej operacji? Czy muszą tylko pamiętać, żeby tego nie robić?

Cały argument, do którego prowadzi seria postów na blogu, znajduje się w części piątej :

Nie mamy powodu, aby sądzić, że system typu C # został zaprojektowany tak, aby miał wystarczającą ogólność, aby zakodować zasady Dungeons & Dragons, więc dlaczego w ogóle próbujemy?

Rozwiązaliśmy problem „gdzie idzie kod, który wyraża reguły systemu?” Dotyczy obiektów reprezentujących reguły systemu, a nie obiektów reprezentujących stan gry; troska o obiekty państwowe polega na tym, aby ich stan był spójny, a nie w ocenie reguł gry.

Broń, postacie, potwory i inne przedmioty w grze nie są odpowiedzialne za sprawdzanie, co mogą, a czego nie mogą zrobić. Odpowiedzialny za to jest system reguł. CommandObiekt nie robi nic z obiektami gry albo. To po prostu próba zrobienia z nimi czegoś. System reguł sprawdza następnie, czy polecenie jest możliwe, a kiedy to jest, system reguł wykonuje polecenie, wywołując odpowiednie metody na obiektach gry.

Jeśli deweloper chce stworzyć drugi system reguł, który robi rzeczy z postaciami i bronią, na które pierwszy system reguł nie zezwala, mogą to zrobić, ponieważ w C # nie możesz (bez nieprzyjemnych hacków refleksyjnych) dowiedzieć się, skąd pochodzi wywołanie metody od.

Obejściem, które może działać w niektórych sytuacjach, jest umieszczenie obiektów gry (lub ich interfejsów) w jednym zestawie z silnikiem reguł i oznaczenie dowolnej metody mutatora jako internal. Wszelkie systemy wymagające dostępu tylko do odczytu do obiektów gry byłyby w innym zestawie, co oznacza, że ​​miałyby dostęp tylko do publicmetod. Pozostawia to lukę w obiektach gry, które nazywają się metodami wewnętrznymi. Ale zrobienie tego byłoby oczywistym zapachem kodu, ponieważ zgodziliście się, że klasy obiektów gry powinny być głupimi posiadaczami stanów.

Oczywistym problemem oryginalnego kodu jest to, że wykonuje modelowanie danych zamiast modelowania obiektowego . Należy pamiętać, że absolutnie nie ma wzmianki o rzeczywistych wymaganiach biznesowych w powiązanym artykule!

Zacznę od próby uzyskania rzeczywistych wymagań funkcjonalnych. Na przykład: „Każdy gracz może atakować innych graczy, ...”. Tutaj:

interface Player {
    void Attack(Player enemy);
}

„Gracze mogą władać bronią użytą w ataku, czarodzieje mogą posługiwać się laską, wojownikami mieczem”

public class Wizard: Player {
    ...
    public void Wield(Staff weapon) { ... }
    ...
}
public class Warrior: Player {
    ...
    public void Wield(Sword sword) { ... }
    ...
}

„Każda broń zadaje obrażenia zaatakowanemu wrogowi”. Ok, teraz musimy mieć wspólny interfejs dla broni:

interface Weapon {
    void dealDamageTo(Player enemy);
}

I tak dalej ... Dlaczego nie ma go Wield()w Player? Ponieważ nie było wymogu, aby każdy gracz mógł używać dowolnej broni.

Mogę sobie wyobrazić, że byłby wymóg mówiący: „Każdy Playermoże próbować władać dowolnym Weapon”. Byłoby to jednak coś zupełnie innego. Modelowałbym to może w ten sposób:

interface Player {
    void Attack(Player enemy);
    void TryWielding(Weapon weapon); // Throws UnwieldableException
}

Podsumowanie: modeluj wymagania i tylko wymagania. Nie rób modelowania danych, to nie jest modelowanie oo.

Jednym ze sposobów byłoby przekazanie Wieldpolecenia do Player. Następnie gracz wykonuje Wieldpolecenie, które sprawdza odpowiednie reguły i zwraca Weapon, z którym Playernastępnie ustawia własne pole broni. W ten sposób pole broni może mieć prywatnego setera i można je ustawić tylko poprzez przekazanie Wieldpolecenia graczowi.

Nic nie stoi na przeszkodzie, aby programista to zrobił. Właściwie Eric Lippert wypróbował wiele różnych technik, ale wszystkie miały słabości. Taki był sens tej serii, że powstrzymanie programisty od zrobienia tego nie jest łatwe, a wszystko, czego próbował, miało wady. W końcu zdecydował, że należy użyć Commandobiektu z regułami.

Za pomocą reguł możesz ustawić Weaponwłaściwość a Wizardna Swordale, ale kiedy poprosisz o to, Wizardaby władać bronią (Miecz) i zaatakować ją, nie będzie to miało żadnego skutku, a zatem nie zmieni żadnego stanu. Jak mówi poniżej:

Mamy kolejną zasadę, która wzmacnia pierwszą zasadę, która mówi, że efekty pierwszej reguły nie mają zastosowania, gdy czarodziej próbuje użyć miecza. Skutkami tej sytuacji są „wydać smutny dźwięk puzonu, użytkownik traci akcję w tej turze, żaden stan gry nie jest mutowany

Innymi słowy, nie możemy egzekwować takiej reguły poprzez typerelacje, które próbował na wiele różnych sposobów, ale albo jej się to nie podobało, albo nie działało. Zatem jedyne, co powiedział, że możemy zrobić, to zrobić coś z tym w czasie wykonywania. Zgłoszenie wyjątku nie było dobre, ponieważ nie uważa go za wyjątek.

W końcu zdecydował się na powyższe rozwiązanie. To rozwiązanie zasadniczo mówi, że możesz ustawić dowolną broń, ale jeśli ją oddasz, jeśli nie jest to właściwa broń, byłaby zasadniczo bezużyteczna. Ale nie zostanie zgłoszony żaden wyjątek.

Myślę, że to dobre rozwiązanie. Chociaż w niektórych przypadkach wybrałbym też wzór try-set.

Pierwszym odrzuconym rozwiązaniem autora było przedstawienie reguł według systemu typów. System typów jest oceniany podczas kompilacji. Jeśli odłączysz reguły od systemu typów, nie będą one już sprawdzane przez kompilator, więc nic nie stoi na przeszkodzie, aby programista popełnił błąd sam w sobie.

Ale ten problem napotyka każdy element logiki / modelowania, który nie jest sprawdzany przez kompilator, a ogólną odpowiedzią na to pytanie jest testowanie (jednostkowe). Dlatego zaproponowane przez autora rozwiązanie wymaga silnej uprzęży testowej, aby obejść błędy programistów. Aby podkreślić, że potrzebna jest silna wiązka testowa dla błędów wykrywanych tylko w czasie wykonywania, zapoznaj się z tym artykułem autorstwa Bruce'a Eckela, który stanowi argument, że należy wymienić mocne pisanie na silniejsze testowanie w dynamicznych językach.

Podsumowując, jedyną rzeczą, która może zapobiec popełnianiu błędów przez programistów, jest zestaw testów (jednostkowych) sprawdzających, czy przestrzegane są wszystkie reguły.

Mogłem tu pominąć subtelność, ale nie jestem pewien, czy problem dotyczy systemu czcionek. Może to konwencja w języku C #.

Na przykład możesz uczynić ten typ całkowicie bezpiecznym, Weaponchroniąc seter Player. Następnie dodać setSword(Sword)i setStaff(Staff)na Warriori Wizardodpowiednio, że wezwanie chroniony seter.

W ten sposób relacja Player/ Weaponjest sprawdzana statycznie, a kod, który go nie obchodzi, może po prostu użyć a, Playeraby uzyskać Weapon.

Co więc powstrzymuje programistę przed zrobieniem tego? Czy muszą tylko pamiętać, żeby tego nie robić?

To pytanie jest w istocie takie samo w przypadku dość świętej wojny o nazwie „ gdzie umieścić walidację ” (najprawdopodobniej również ddd).

Zanim odpowiesz na to pytanie, zadaj sobie pytanie: jaki jest charakter zasad, których chcesz przestrzegać? Czy są wyryte w kamieniu i definiują byt? Czy złamanie tych zasad powoduje, że jednostka przestaje być tym, czym jest? Jeśli tak, wraz z utrzymaniem tych zasad w sprawdzaniu poprawności poleceń , umieść je również w encji. Jeśli więc programista zapomni o sprawdzeniu poprawności polecenia, twoje podmioty nie będą w niepoprawnym stanie.

Jeśli nie - cóż, z natury rzeczy oznacza to, że reguły te są specyficzne dla poleceń i nie powinny znajdować się w jednostkach domeny. Naruszenie tych reguł skutkuje więc działaniami, które nie powinny były mieć miejsca, ale nie były w stanie nieprawidłowego modelu.