Здравейте реших тоя изпит криво ляво, но на всичките тестове ми дава непълен брой точки, тестовете са затворени, и аз си нямам ни най малка идея защо. Ето ми го решението -> линк за сваляне

В първа фаза дава 90/120, във втора фаза дава 120/180 а в трета фаза дава 71/100. По принцип в тези по-стари изпити не се казва конструктора какво приема в какъв ред го приема, докато в по-новите изпити това е указано. Това защото джъдж е настроен с повече оверлоуди ли е или просто, рулетка . Другото което не ми е ясно е има моменти в които мога да направя логиката ми да се върти в класа например  в класа Driver може да се променя изотвътре горивото му и вътре да се проверява в класа дали е паднало до 0 и ако е паднало да задава, че не участва повече тоя шофьор като свойство на самия клас, мога да го направя и външно в RaceTower същите магии примерно + речник с ключ шофьора и стойност причината поради която е отпаднал... Какво се очаква да се направи за да е доволен джъдж. Отделно не ми е ясно като се изпреварва това изпреварване по кой от многото възможни начини става шофьора като изпревари 1x друг шофьор работата ясна ама ако са >?2броя какво става и двамата ли "бавнеят" щот са изпреварени или само първия изпреварен забавня а изпреварващия е и пред 2мата бивши предни... някак си разбирам условията многозначно в тоя изпит като ги чета... Също печелившия уинър може да се подава от рейс тауър може да се взима директно през енджин класа... кое е по-правдиво алах керим...И като цяло какво се прави като не излезе задачата с ненулеви тестове...

Като ги правиш тея неща,трябва да се съобразяваш с solid принципите. Примерно race tower-a работа ли му е да знае за горивото на състезателя. В конструктора винаги ти е описано какво ще има,сига по какъв ред също не е толкова важно вэпржса и как си ги приемаш ти вътре. На компилатора не му пука дали първото property ще приеме последния параметър или обратното.. на engine-a не му е работа да знае кои е победителя тои е просто warapper около race tower. Първите тестове за структера явно си сбъркал modifier или име на property да не ти излезе. А другите вече явно имаш грешки в логиката. А за 2мата състезатели всеки по отделно го проверяваш дали е по бавен и намалавяш там времето или както беше по задачата. Но я по-добре прочети пак за солид и encapsulation явно има нужда.

Абе съобразявам се аз... обикновенно гледам всичко да го капсулирам в поведението на класа обаче не винаги нещата са "правилно зачетени" по този начин. Давам пример този изпит е с решение от автора

Интересни са 2 момента.  Малко въведение за да е ясно за какво говоря: Има герои героите имат торба с айтеми в класа Character торбата е пропърти с поле и към него има поведение в което има метод Ползвай тоз айтем ; метод GiveItem(Character anotherInstance, Item someItem) както и UseItemOn(Character anotherInstance, Item someItem).. Интересното е че при действие от посочените видове което се вика през конзолата айтема не се проверява дали го има в метода на класа Character където е дейтвието с него а това е изнесено в класа-контролер отвън та каде са енкапсулацията и солид принципите "трябва ли му на контролер-класа да знае какво има в торбата на героите"?

2рия върховен момент е със стринг билдъра при контролера ако не се TrimEnd()- не стринга дето се връща от метода нещата са "Incorect Answer", да де ама аз примерно вместо тримЕнд обичам да казвам просто Console.Write(стринга без трим енд) и проблеми няма ... ама и точки няма.  Така, че не винаги като видим, че нещо не е 100/100 е от "солид принципи липса на енкапсулация" и неразбиране на материята... На компилатора за реда на параметрите е вярно, че не му пука, ама на джъдж му пука дали първия параметър е от тип стринг на дадения клас когато му се извика конструктора и като не си го намери става проблем.

Честно седни и чети дори ен разбираш какво се случва..

DungenMaster-a дава предмет на играча,и е нормално тои да провери дали има някакви items въобще в играта все пак тои пази списъка. Казах ти ен разбираш логиката, и след като го има героя не го интересува тои го е получил работа на торбата е да го съхрани и както виждаш character-a вика character.getItem -> извиква item.getitem

защо играча да проверява,дали го има предмета това е работа на dungeon master-a. A къде видя че мастер-а гледа в торбата на геройте? това са 2 различни неща.

А за изписването това е вече особеност на Judge защото очаква по определен начин нещата,и ако ти остане whitespace отзад и ще счупи. Явно console.Write не ги зачиства 

но затова ще разбереш повече на 2та част и unit tests.

A за конструктурите тея неща са описани,това беше моя редовен изпит и го помня много добре,беше дълъг но сравнително лесен за писане нямаше сложни щуротий.

Аз говоря едно ти разбираш друго. Мастъра следи за айтемите в пуула си хубаво. Обаче когато Играча има собствена лична, негова си торба която ако иска може и да е private дори . Когато играча може да дава да ползва да жонглира с айтемите които са В неговата си собствена лична раница. Каде е смисъла некав външен клас да гетва айтема от торбата на Играча и да му казва прави с тоз айтем тез магарии. Значи много по логично за мен е самия играч като има метод ползвай тоз айтем от своята си торба в самия му метод да провери има ли в торбата си айтема или го няма и да хвърля ексепшън ако го няма. Виждам, че идеята е да ме убедиш аз колко нищо не знам... Гледам, че си с раница затова ще ти задам въпроса така Ако аз съм един контролер а ти си чарактер и ти кажа дай си бутилката с водата от раницата на Генади, ти ли ще си ровиш в раницата или аз ще ровя в твойта раница вместо теб да ти кажа дали можеш да дадеш вода на Генади? След като аз ровя в твойта раница има ли смисъл ти да имаш метод с който даваш бутилка аз като я гетна мога да я дам и без твоя метод на Пешо...

public string GiveCharacterItem(string[] args)
        {
            var giverName = args[0];
            var receiverName = args[1];
            var itemName = args[2];

            var giver = this.FindCharacter(giverName);
            var receiver = this.FindCharacter(receiverName);

            var item = giver.Bag.GetItem(itemName);

            giver.GiveCharacterItem(item, receiver);
            return $"{giver.Name} gave {receiver.Name} {itemName}.";
        }
аз идеално ги разбирам но ти явно не, добре ето го примера за които мрънкаш какво се случва, абстракцията която ти държи героите и партито получава команда вземи от пешо дай на гошо еди кои си предмет, и виждаш в кода първо master-a използва своя метод findcharacter ако няма пешо или гошо ще хвърли exception, после намира и item-a ако го няма ще изгърми пак. А как го намира като Пешо през неговата чанта която е readonly list на предметите в private bag-a му вижда дали го има,и ако го има го два на Гошо. 

Сега ти се чудиш защо и така, да видим компилатора минава през кода ред по ред,ти опитваш да направиш реалния живот с код,ама колко и да се опитваме няма как да стане има ограничения. dungeon master-a никъде не пипа в геройте , тои само проверява дали ги има и после Пешо проверява дали има тая бутилка,и ако тези условия се изпълнят, тогава ще получи Гошо предмета, или както ти казваш бутилката с вода. Кода си е съвсем коректен и както трябва написан и като логика и като променливи. На Влади авторското решения е едно от най-добрите решения на изпит като цяло. Сега дали може да стане и по друг начин с events и тн да. Но тук имаш мастер-а тои ти следи за state-a на играта,и нищо друго не го интересува,тои получава командите какво се случва в рунда,от там нататък героите се грижат за останалите неща и мастъра накрая проверява дали играта е свършила. А самия engine които не знае какво правят герои и мастъра се грижи всичко да върви докато не се изпълни определено условие и така.

И ако Гетването на айтема е поместено в класа Character в body-то на метода GiveCharacterItem това е лошо и неправилно така ли?

да така нарушаваш принципа че един метод трябва да прави само едно единствено нещо.Strong cohesion loose coupling.

Ako го сложиш вътре в  GiveCharacterItem така метода ти прави 2 неща,и си вързваш методите един към друг, ако решиш да промениш getitem ще трябва да смениш не само него но и givecharacterItem ако смениш функционалноста много tight coupling стават нещата и генерално се избягват тея работи, това го правят в функционалното програмиране да си подават функций на функций но, ние избягваме да го правим.Примерно направиш getItem да връща bool вместо обект ще трябва да рефакторираш и него и после и giveitem а ако получаваш само предмета,метода не го бърка кои ще му го даде тоя предмет просто ще си добавиш новия метод и той ще ти хвърля предмета на getItem.