Pamiętacie Artura? Młody przedsiębiorca - freelancer IT, który wyszedł z problemów finansowych dzięki inviPay.com. W kwietniu otrzymał propozycję pracy nad projektem mechanizmu podzielonej płatności w jednym z banków działających w Polsce. Artur zgodził się na kontrakt, w którym miał zapewnione wysokie wynagrodzenie, ale dopiero 60 dni po ukończeniu i przetestowaniu prac. Artur stwierdził "Maćkowi i Konradowi zapłacę własnymi środkami, a po ukończeniu prac otrzymam swoje pieniądze". Wszyscy byli zachwyceni możliwością pracy nad wdrożeniem innowacyjnego rozwiązania jakim jest split payment.

Niestety to, co zawodowo okazało się interesującym zadaniem, biznesowo przyniosło masę problemów. Artur po oddaniu prac, wystawieniu faktury i odczekaniu 60 dni był zaskoczony, że przelew do niego nie dotarł. Zdziwiony zadzwonił do banku i załamany usłyszał: "Panie Arturze, od 1 lipca płatności wykonujemy split paymentem, a Pan posiada tylko rachunek osobisty". Artur w związku z intensywnością prac całkowicie zapomniał o zmianie swojego rachunku osobistego na firmowy. Co prawda, będąc przedsiębiorcą prowadzącym jednoosobową działalność gospodarczą, nie miał obowiązku posiadania rachunku firmowego, ale niestety to płatnik decydował o formie rozliczenia. Bank chcąc działać według nowych regulacji zrealizował płatność nowym, podzielonym mechanizmem i przelew został odrzucony.

Załamany Artur ponownie stracił płynność finansową. Na domiar złego przekroczył termin zapłaty kwartalnych podatków i fiskus zaczął się o nie upominać.

Tym razem Artur wiedział jak szybko zareagować. Udał się do banku, założył rachunek firmowy i w porozumieniu z bankiem wystawił nową fakturę. Niestety z nowym terminem płatności 60 dni. Dzień po wystawieniu Artur zadzwonił do Pani Magdaleny z inviPay.com, żeby pomogła mu odzyskać kontrolę nad swoimi finansami. Pani Magdalena wyjaśniła ze szczegółami wszystkie elementy mechanizmu podzielonej płatności. Artur następnego dnia otrzymał środki na konto za pomocą split payment, dzięki czemu mógł od razu przelać zaległe podatki do urzędu skarbowego i odzyskał płynność finansową.

A czy Ty wiesz co to split payment? Zadzwoń pod 22 295 15 05 - odpowiemy na wszystkie Twoje pytania.

Cała moja firma na jednym zdjęciu

Coś dla pisarzy Java. OpenJDK Community Update: A Year in the Life with Mark Reinhold.
https://youtu.be/15s5xP5BRxk

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.

Dziś skończyłem pisać ostatni post na moim blogu na temat interpretera Brainfucka pisanego w C. Program ten skończyłem pisać już trochę czasu temu i już nawet zająłem się nowym projektem, ale z racji, że ciężko mi się oderwać od kodu to po prostu odkładałem pisanie tych artykułów. :) Od czasu mojego ostatniego wpisu tutaj napisałem jeszcze bodajże trzy posty. Jeśli jesteście zainteresowani jak poradziłem sobie z napisaniem tego interpretera od początku do końca to zapraszam - https://shizz3r.blogspot.com/

Dodam, że teraz tworzę usługę serwera FTP + klienta w oparciu o programowanie asynchroniczne w Pythonie. Postaram się opisać również i ten projekt także jeśli jesteście ciekawi to śledźcie bloga. :)

Oczywiście zaznaczam, że nie jestem ekspertem dlatego wszelka konstruktywna krytyka jest mile widziana. :)