Walki z projektem ciąg dalszy. Chyba nie zdążę przed końcem wakacji zrobić wszystkiego, co planuję :(
Mam dość poważne problemy z duplikacją kodu. Niestety, choć staram się to ograniczać (o ile tylko owo ograniczanie nie zatrzyma mnie zbyt mocno), copypasty jest tam nadal zdecydowanie za dużo. Nie wszędzie mam rozsądne pomysły, jak się tego pozbyć.
Weźmy na przykład public class Block : IAction. Mój oryginalny pomysł był taki, że utrzymywanie bloka (a) kosztuje niewielką ilość Staminy na turę, jeśli Staminy nie ma to blok jest zdejmowany; (b) natychmiast, gdy przeciwnik ukończy swój ruch, blok jest zdejmowany. Interfejs IAction wymaga metody execute - świetnie zatem, niech Block implementuje execute w ten sposób, że zabiera nieco Staminy, sprawdza, czy przeciwnik jest wolny i jeśli tak, zdejmuje się.
Działa. Ale! Oprócz Block mam jeszcze i Dodge, które działa bardzo podobnie, tyle że zamiast blokowania ataku przeciwnika (pewne zmniejszenie obrażeń o % wynikły ze stosunku Power walczących) usiłuje wykonać unik (przyjęcie albo 0% albo 100% obrażeń w zależności od RNG, szansa zależy od stosunku Speed obu walczących). No i obie klasy duplikują kod odpowiedzialny za zdejmowanie się wskutek braku Staminy albo wskutek faktu, że przeciwnik zakończył już swój ruch.
Co gorsza: Za chwilę okazuje się, że jednak Block oraz sposób jego nakładania i zdejmowania to są dwie różne rzeczy. No bo teraz np. chcę zrobić taki ruch jak Ram. Działa on tak: user podbiega do przeciwnika, blokując podczas podbiegania, następnie atakuje i zdejmuje bloka. No i mam problem. Jak to zrobić bez duplikacji kodu? Duplikowanie całej klasy Block oprócz kodu odpowiedzialnego za zdejmowanie to już przesada, nawet dla mnie.
Chcę wielodziedziczenia! Wtedy, myślę, dałbym sobie klasę Block, klasę Dodge, klasę RequireStaminaPerTurn, klasę UntilEnemyFinishesMove, klasę UntilEndOfChannel. I teraz niech NormalBlock dziedziczy po Block, RequreStaminaPerTurn, UntilEnemyFinishesMove. I niech NormalDodge dziedziczy po Dodge, RequireStaminaPerTurn, UntilEnemyFinishesMove. I wreszcie niech ChannelBlock dziedziczy po Block, RequireStaminaPerTurn, UntilEndOfChanel. Wszystko. Teraz nawet można (teoretycznie, nie zrobiłem tego) dać postać, która będzie miała taki passive, że będzie mieć bez przerwy założonego bloka bez żadnych kosztów Staminy.
Niestety! Wielodziedziczenie jest be i nie ma go w C#. Coś jednak muszę wymyślić! Z jednej strony nie chcę duplikować kodu ponad miarę, a z drugiej strony, nauczony tym doświadczeniem, chcę wprowadzić i utrzymać zasadę, że żaden efekt mający wpływ na grę nie odpowiada za swoje własne zdejmowanie i nakładanie.
W końcu wymyśliłem. Block nie implementuje już IAction. Zamiast tego pojawiły się takie klasy, jak: public class PlaceEffect: IAction, public class RemoveEffect : IAction, taki interfejs: public interface RequireSetup : IEffect { List<IAction> onPlacement { get; } List<IAction> onRemoval { get; } List<IAction> onFailure { get; } } itepe, itede.
Biorąc pod uwagę fakt, że dodatkowo jeszcze, celem umożliwienia, by tury wykonywały się jednocześnie (w sensie, obaj gracze dają polecenia i wtedy wykonuje się tura, nie ma znaczenia który gracz wykonuje swą turę jako pierwszy) wprowadziłem wymóg, by każda IAction implementowała property o nazwie priority - no zrobiło mi się spaghetti. Te wszystkie priority, getPriority, PlaceEffect, onBlahblah => { new List<IAction> { new PlaceEffect(_priority: yaddayadda, _effect: new JakiśtamEfekt(_onFailure : new List<IAction> {new RemoveEffect(plepleple.... nie chce mi się kończyć otwartych nawiasów i tym podobne... Wydaje mi się że brzydkie, obawiam się że błędogenne, i co gorsza podobne ruchy powtarzają ten niemiły kod czyli i tak mamy copypasty.
No ale idziemy dalej. Teraz implementuję sobie damage over time. Na pierwszy ogień idzie Hurricane i Conflagration. Te efekty odnoszą się do całego Field, toteż atakują obu graczy. No i tu już mamy problem, gdyż to ma działać jako efekt "stackowalny", tj: wykonanie ruchu Hurricane nakłada stack efektu Hurricane który to stack zostanie zdjęty po czasie zależnym od statystyk gracza nakładającego ten stack. Tak samo Conflagration. Co więcej, Hurricane i Conflagration razem tworzą kombo FieryTornado. I wreszcie, Hurricane, oprócz damage over time, nakłada jeszcze na obu graczy taki debuff, że każdy ich ruch kosztuje nieco więcej Staminy.
Zaimplementowane. Mam klasę Weather : IExecutable<Field>, IOnTire. Implementowanie IExecutable<Field> jest po to, by mogła nakładać obrażenia każdej tury. Implementowanie IOnTire jest po to, by mogła zwiększać zużycie Staminy. W niej klasy: PlaceWeatherStack : PlaceEffect, RemoveWeatherStack : RemoveEffect (ich zadanie: nakładanie / zdejmowanie instancji klasy Weather do zbioru efektów na Field kiedy tylko zostanie nałożony jakiś stack Hurricane lub Conflagration / kiedy ostatni stack zostanie zdjęty); no i oczywiście klasy HurricaneStack, ConflagrationStack. Klasa Weather, wywołana, sumuje sobie wszystkie stacki i na tej podstawie zadaje obrażenia / zwiększa użycie Staminy. Powinno działać. (Jeszcze nie przetestowałem).
Niestety. Klasa Weather, ze wszystkimi klasami zagnieżdżonymi, to jest sporo kodu. Więcej, niżbym przewidywał. 200 linii z hakiem.
A teraz nadchodzą kolejne dwa efekty: ToxicSpores i BurningSpores. Także zadają damage over time, ale już tylko na przeciwników. Nie mają także dodatkowych efektów takich jak IOnTire. Mimo to... duplikacja kodu pomiędzy tymi klasami a Weather jest straszna. Nieakceptowalna nawet dla mnie.
Ale przecież nie chcę! zrobić klasy bazowej, choćby abstrakcyjnej, która by zawierała w sobie zduplikowany kod! Przecież nie ma wielodziedziczenia, a pojedyncza klasa bazowa to przepis na powrót problemów, na jakie natknąłem się przy Block. W końcu (chyba) udało mi się wydzielić część zarządzania stackami:
public class PlaceStackedEffect : PlaceEffect
{
public interface IStackedEffect : IEffect
{
List<IStackManager> managers { get; }
void prepare(Species affected);
IStackedEffect accumulate(IStackedEffect eff, IStackedEffect acc);
}
public interface IStackManager : IEffect
{
void update(IEffectStorage storage);
}
public IStackedEffect eff;
public PlaceStackedEffect(IStackedEffect _eff, List<IEffect> _others, List<int> _priority = null, IEffectStorage _target = null) : base(_others.Prepend(_eff), _priority, _target)
{
eff = _eff;
}
public override void execute(Species affected)
{
foreach (IStackManager required in eff.managers)
if (!target.ownEffects.OfType<IStackManager>().Any(eff => eff.GetType().IsAssignableFrom(required.GetType())))
target.ownEffects.Add(required);
eff.prepare(affected);
base.execute(affected);
foreach (IStackManager manager in target.ownEffects.OfType<IStackManager>().Where(sm => eff.managers.Any(required => sm.GetType().IsAssignableFrom(required.GetType()))))
manager.update(affected);
}
public class RemoveStackedEffect : RemoveEffect
{
IStackedEffect eff;
public RemoveStackedEffect(IStackedEffect _eff, List<IAction> _onRemove = null, List<int> _priority = null, IEffectStorage _target = null) : base(_eff, _onRemove, _priority, _target)
{
eff = _eff;
}
public override void execute(IEffectStorage affected)
{
base.execute(affected);
foreach (IStackManager required in eff.managers)
foreach (IStackManager manager in target.ownEffects.Where(eff => eff.GetType().IsAssignableFrom(required.GetType())))
manager.update(affected);
}
}
}
Wciąż nie usuwa to znacznej części duplikacji... np. sumowanie damage jest analogiczne we wszystkich 3 przypadkach, ale tego nie chcę wydzielać do IStackedEffect, bo łatwo wyobrazić sobie taki efekt, który by się zupełnie inaczej agregował. Tak samo analogiczny jest kod odpowiadający za dispelowanie stacków, ale znowu: boję się powrotu problemów spod znaku Block (tj. duplikacja kodu wymuszona brakiem wielodziedziczenia). No bo co, jeśli jakiś inny efekt stackowalny będzie inaczej dispelował stacki i co więcej, tak jak w przypadku Block / Dodge, jego inne dispelowanie też winno być dziedziczone po iluśtam innych efektach?
Przyznaję, że ten projekcik jest dla mnie solidną lekcją pokory.
Modliszka
@endrius: to może odezwij się do nich żeby Cię usunęli z bazy i po kłopocie? Przy obecnym prawie większość firm jest o wiele bardziej restrykcyjna i ostrożna