Въпреки, че не съм компетентен как точно става оценяването, според това, което се коментираше от упражненията във вторник, когато се показваха добри, средни и лоши решения, мисля че идеята е била да се обединят абстрактните AbstractHardware и AbstractSoftware (които да имат общо име примерно). Но като цяло всички сме получили по едно изречения за всичките 4 критерии за оценяване - класова йерархия, полиморфизъм, енкапсулация и други фактори, като структура на кода, къде колко неща има в Main метода. Ако искаш погледни видеото за да видиш горе-долу по-подробни коментари за даден вид грешки - https://www.youtube.com/watch?v=61NWbKhM7J0 . Като цяло кода ти ми изглежда много спретнат, и въпреки че бонус задачата не е имплементирана, гледам че си имаш Command Intrepreter, доста интерфейси, което също би трябвало да е дало поне малко бонус точки.

Не знам кой пише коментарите и кой оценява, но може би няма да е зле да има възможност за отговори или въпроси директно към самите оценяващи, тъй като те, надявам се, най-добре знаят какво са имали предвид.
Отдавайки значимото на усилията, които са положили за оценяването, все пак очевадната езикова неграмотност и стил на изказване правят доста лошо впечатление и навеждат на мисълта за не съвсем сериозно отношение (нещо си е "горе-долу", друго не било "като хората", еди кво си "куца" и т.н.) Дори на домашните, които сами си оценявахме преди известно време, коментарите бяха по-нормални.   

"Структурата на класовете е горе долу добра."
Означава, че начинът по който са структурирани и направени класовете е добър, показва че конкретния човек е разбрал смисъла на курса, лекциите и материала който се преподава в него, но е изпуснал 1-2 неща които го делят от отлична имплементация на класовата структура.

"Енкапсулацията куца - има прекалено много публични setter-и в property-тата на класовете. "
Означава, че почти нявсякъде по property-тата в класовете, са поставени публични setter-и, и външния потребител, който пише код по приложението, може да постави каквато и да е била стойност на конкретното property, и тя да не мине през никаква валидация, което като цяло не е правилно според Енкапсулацията. Или с други думи конкретното поле от класа, не е енкапсулирано, почти никак.

"Полиморфизма е използван добре, като принцип. "
Означава, че конкретния човек се е справил добре с този принцип. Разбрал го е, и го е използвал правилно в контекста на задачата.

"Направен е опит за имплементация но в крайна сметка, бонус задачата не е имплементирана."
Означава, че конкретния човек се е опитал да имплементира бонус задачата, но не е успял да изкара точки в Judge, на 2-та, специално направени за тази задача, нулеви тестове. Ако не са изкарани точки на 2-та нулеви теста, бонус задачата се счита за неимплементирана, което означава че конкретния човек не получава точки за бонус задачата.

Рецензията върху изпитите е кратка и цели да покаже на хората повърхностно какво са сбъркали и да ги насочи съвсем абстрактно към техните грешки. Оценяващите не целят да кажат на хората къде точно са сбъркали, а да им кажат какво точно са сбъркали, за да могат хората да се концентрират върху поправянето на грешките си на глобално ниво. С други думи - щом Енкапсулацията ми куца, трябва да ида и да си изгледам лекциите за Енкапсулация на ново, да си направя упражненията на ново, и да видя какво съм пропуснал и какво не съм направил като хората. Ако трябва оценяващите да обясняват и конкретизират на всеки човек, точно, какво, кога, къде и защо, има хора на които 2 дни няма да стигнат да им обясним точно какво са сбъркали... В такъв случай, е логично да напишем, примерно, че ООП-то на човека куца като цяло... Все пак целим да доставим оценките на хората възможно най-бързо.