Изпитът по ООП

kenderov.emil 6 Точки

Изпитът по ООП

Здравейте колеги,

Датата за изпита наближи. Честно казано, притеснен съм, защото не знам дали съм достатъчно подготвен. Това, че писах и предавах домашни не ме успокоява много. Има и добри новини, които научих, че нямало да има скелет, а сам ще си пишеш кода(започвайки от 0). И тук ми възникнаха някои въпроси:

1. Една задача ли се пада или няколко?

2. Ако е една, какъв е минимума/на какви условия трябва да отговаря решението за да минеш?

3. В случай, че реша да не се явя(или пък да не успея), има ли поправка и кога?

Благодаря предварително.

Тагове:

13/12/2015 16:46:07 C# OOP Basics

alevtodorov 29 Точки

Здравей,

Задачата ще е една.

За минимума - мисля, че и с 3 се минава, но трябва да имаш поне 5 за да ти се издаде сертификатът за професия C# програмист по-късно(ако не греша).

Ако не се явиш, ще има поправка, но не зная кога ще е. Може да е съвсем скоро след изпита, а може би в края на модула фундаменталс. Доколкото знам, ще имаме 1 месец преди да почнат FE-да или BE-да, за поправки или повишаване в края на това ниво. Трейнарите ще кажат как са нещата.

Поздрави.

13/12/2015 17:30:02 13/12/2015 17:32:38

Filkolev 4482 Точки

Относно поправките, в края на всеки модул: https://softuni.bg/faq#question-76

Задачата ще е една, като в рамките на тази задача ще има различни таскове, да ги наречем. В общи линии достатъчно за взимане на изпита би било да се направи някаква смислена ООП структура от класове - с наследяване и т.н. Оттам нататък добрата абстракция, decoupling и други са неща, които добавят към оценката, но не считаме за задължителни, за да приемем, че даден човек знае ООП на някакво минимално изискуемо равнище (демек за тройка).

Липсата на скелет е нож с две остриета. На мен лично ми отнема повече време да решавам задачи от новия формат, защото има много boiler-plate код, който трябва да се изпише, докато при наличието на скелет много неща са спестени и е по-лесно да се допишат класове в съществуваща структура. При дадени интерфейси и готова голяма част от приложението също се спестяват множество въпроси около това как би трябвало различните модули да комуникират помежду си. Подозирам, че за повечето хора промяната е по-скоро положителна, но давам пример (със себе си), че не за всички ще е така.

13/12/2015 18:41:20

RFilipov 136 Точки

Не е лошо да давате малко повече обяснения в условията. Колкото по-малко свободен текст толкова по-добре.

13/12/2015 20:02:14

Filkolev 4482 Точки

Ако даваме подробни инструкции кое как да стане се губи смисълът до голяма степен. Ако кажем "направете интерфейс IEngine с метод Run(), интерфейс IBuilding с методи ProduceUnit() и ProduceResource()" няма как да разберем дали човек може сам да построи някакво приложение с прилична структура. Ще е един вид да дадем скелет в писмен вид без да даваме проекта.

В задачата Empires например какво би добавил като допълнителни обяснения? Става дума за нещо, което да доизясни заданието без да дава упътване за конкретнен подход. Защото подходи има много и верните са повече от един.

Ясно е, че има енджин, сгради, като една сграда произвежда две неща през определени периоди; има юнити с някакви характеристики и ресурси. Това е описание на задание, което може някакъв клиент да даде - той иска функционалност, но не го интересува отдолу как точно е структурирано цялото нещо, понеже не разбира от понятия като loose coupling, dependency inversion и т.н.

Наемаш си примерно майстор да ти налепи плочки в кухнята, казваш му какво искаш като резултат и очакваш останалото той да го свърши според собствената си преценка, за да е качествено. Не върви да му висиш на главата през цялото време и да даваш акъл, което ще е същото ако дадем повече насоки в условието. Може да му кажеш примерно, че ще слагаш някакъв шкаф в оня ъгъл и фурна в другия, така той ще може да вземе някакви решения, които да позволят да си направиш нещата, както си планирал. Аналогично казваме, че има някакви конкретни ентитита, но искаме енджинът да работи с всякакви и че е възможно в бъдеще да бъдат добавени нови юнити и сгради. Т.е. ти може да направиш някакакво кофти решение, което работи в момента, но в перспектива да навлече големи неприятности. И това е свобода, която е нужно да бъде дадена, за да преценим кой студент знае принипите на ООП за 4-ка и кой за 6-ца.

Тук идва мястото на свободния текст - дали от такова описание може да съобразиш моделите и техните връзки и поведение (т.е. дали може да мислиш обектно-ориентирано), или ти трябва упътване стил лаб със скрийншоти. Първото е програмист, второто е code monkey, а СофтУни се стреми да създава първото.

13/12/2015 20:35:07

RFilipov 136 Точки

Задачата Empires е горе долу ок. Отне около 2.5 часа.

Обаче Capitalism с дървото на заплатите и служителите в различните отдели е интересен случай (говоря за първоначалното условие преди nerf-a).

Ако искам да създам нов служител, а такъв вече съществува ? Махам го от съществуващия му отдел и го преназначавам на друг? А ако този служител е мениджър ? Отдела остава без мениджър? И за тези неща не беше упоменато в условието дали да се дава някаква грешка дали не. Такива разни неяснотии имах предвид иначе Capitalism е интересна задача с такъв вид построяване на отдели, заплати и т.н., ама ако я дадете на изпит ще останете замислени.

13/12/2015 21:03:21

Покажи всички коментари

Cocolino 36 Точки

Относно точка 3 на колегата, бих искал да питам, ако не се явим на 20-ти, какво е нужно да направим за поправката? Подава ли се някакво заявление, че няма да се явим на първата дата или просто не се записваме за място в залата и/или не присъстваме на изпита? След това, подава ли се друго заявление, за явяването на поправката и заплаща ли се такса от 20 лв. в този случай?

14/12/2015 10:10:50 14/12/2015 10:11:10

RoYaL Trainer 6849 Точки

Просто не се записваш за изпита. А за да се запишеш за поправката говори с колежката от фронт офиса да ти обясни процедурата и да координирате с нея. Можеш по телефон, имейл или на място в университета да проведеш разговора.

14/12/2015 11:47:21

Cocolino 36 Точки

OK, благодаря ти!

14/12/2015 12:11:27