Имам коментар по 1-ва задача, козметични неща.

В ToString() за Person - прието е да се минава на нов ред след запетаята, която отделя форматирания стринг от параметрите. За имейла, понеже той няма как да е празен, може да е или null, или валиден мейл, може да ползваш оператора ?? (null-coalescing) вместо тернарния. Съкращава малко записа и върши същата работа.

На 2-ра задача, добавяш към лаптопа батерията и като отделно поле имаш battery life, което според мен е по-логично да е свойство на самата батерия. 

Като хвърляш ексепшъни е хубаво да слагаш информация кой параметър е изгърмял; особено в класа Лаптоп както има доста пропъртита, всичко може да изгърми с ArgumentNullException може да представлява затруднение.

Благодаря за КПК забележката! :) Не съм сетил за ?? оператора, но определено става по-късо и ясно с него.

Едит: За живота на батерията и аз си го помислих, логично е да е в батерията. Сигурно съм се подвел по примерния output, където батерията е отделно от живота на батерията...

Нито батерията е редно да наследява лаптопа, нито лаптопа да наследява батерията.

Когато даден клас наследява друг, това означава, че обектите от класа наследник са подмножество на обектите от класа родител. Например, бозайниците са вид животни, т.е. класа бозайник наследява класа животно. В случая нито лаптопа е вид батерия, нито батерията е вид лаптоп. Надявам се стана горе-долу ясно.

Фил го обясни по-добре от мен :)

Благодаря за забележките :)

полетата на батерията са ми протектед, защото като съм писал задачата преди няколко седмици толкова съм разбирал Сега като прегледах решението, от класа лаптоп съм искал да досътъпя батерията(batt) през класа Лаптоп директно, не през пропертито Batt - предполагам visual studioto е изпищяло, променил съм полетата от private на protected и VOALA :)

"a class Laptop holding an instance of class Battery", това пък аз тогава съм го разбрал лаптопа да наследява батерия, което ЯВНО не е така. Instance of class е просто вътре да има батерия в лаптопа, нищо повече - както Фил казва. :)

Ще взема да я преправя тая задача, че наистина е доста зле... :)

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

Преправих я втора и я направих като хората, отделени класове, чейнати конструктори, без безмислени наследявания и т.н..... :)

Много добре си ги направил задачите. Единствено в SULSTest е добре ламбдите да са всяка на нов ред - по-лесно четимо е :)

persons

     .Where(person => person is CurrentStudent)

     .OrderBy(person => ((Student)person).AvgGrade).ToList()

     .ForEach(p => Console.WriteLine(p.ToString()));

Може да зачистиш излишните using-и, общо взето се добавят такива само ако ти потрябват.

На 2-ра задача в класа батерия хвърляш: new ArgumentException("Invalid value for battery type!"). Малко е объркващо, по-описателно е да е ArgumentNullException и да кажеш, че стойността не може да е празна, иначе като кажеш само invalid това не помага особено. В другия клас, лаптоп, ексепшъните си ги направил по този начин (по-описателния).

Цените - decimal за предпочитане пред double. Това за 2-рата задача, в 3-та е направена с decimal.

За принтирането на цената в 3-та, в условието е казано, че трябва да ползваме български формат, т.е. да ръчнем културните настройки; точката става запетая, изписва се след това "лв." и др.

На 4-та задача си пропуснал за OnsiteStudent полето за брой присъствия.

Въобще не бях забелязал в условието полето за брой присъствия. Благодаря за коментарите и  препоръките. Мисля, че оправих нещата.

Имаш излишни using-и, които може да се махнат.

На места ползваш не особено добри имена на променливи - studNum, currCourse. Аз лично никога не съм виждал смисъл от такива съкращения, правя го само за по-стандартни неща, които са ясни за всички (average може да сменя с avg или нещо такова). За 4-5 спестени символа не си заслужава, а се увеличава рискът кодът да стане по-трудно четим.

Кодът не е форматиран на места, Ctrl+K,D е поне при мен шорткъта във VS. По-конкретно - имаш скоби на същия ред, което нарушава конвенцията в C#.

Допада ми идеята да се сложи списък с курсовете на трейнърите и методите за добавяне и премахване да вършат реално някаква функция. 

Никола, за какво се слага ? след името на типа променлива? Например от Лаптопа:

private int? ram = null;

Пак на лаптопа в override tostring метода - като има повече стрингове за слепване StringBuilder-a е доста по-бърз.

Тая проверка много ми хареса:

if (value != null && value.Trim() == "")

:)

https://www.google.bg/search?q=question+mark+after+the+variable+type

? се слага на променливи, които не могат да бъдат null (като int например), за да имат възможността да приемат стойност null.

За задачата с каталога:

По никакъв начин не се подсигуряваш, че това което се асайнва към някое поле е това, което очакваш. Т.е. това, което примерно ти се праща като ram в конструктора, задължително е от тип компонент, но нищо друго не е задължително, името му може да е CPU и пак ще го присвоиш към рамта.

Това което предлагам е да си направиш енумерация с възможните типове и може да я закачаш към поле "type" на компонента. А най-добре даже самите подкомпоненти да са наследници на Component, така можеш да се подсигуриш че нещо ще е от тип Ram.

Другото, което ще изникне като проблем, ако го направиш по този начин (то и сега го има този проблем) е, че за всеки нов компонент, който се измисли, например Лан карта, ще трябва да влезеш в класа Computer и да промениш аааадски много неща, като започнем от параметрите на конструктора, добавяне на ново поле в класа, пропърти към него и стигнем до промяна на ToString() метода.

Според мен трябва да имаш List от компоненти, който подаваш в конструктора на Computer. Така компонентите дори и да са сто - пак лесно ще се подадат като един цял Лист. Няма да ти трябва поле и пропърти за всяко и в ToString() просто ще итерираш през List-a.

P.S.: sb.AppendFormat("{0}\n", this.Motherboard.ToString()); мисля, че викането на ToString() е излишно тук. Щом извършваш стрингова операция, би трябвало да се invoke-не сам.

Да, това за каталога е така, обаче ме домързя вече, много писане става. И за всеки компонент да правя тип се сетих, ама пак много хамалогия. Май с лист от компоненти наистина ще стане най-добре.

Иначе за .ToString() - обичам да ги разписвам обикновено, по четим е кода така според мен.

Замислял ли си се да ползваш автоматични пропъртита, до момента в който не ти се наложи да правиш валидация? Доста излишно ми се вижда, ако нямаш логика в сетъра/гетъра да имаш полета и пропъртита, които просто ги гет/сет-ват

Да, прав си. Няма логика да само да гет/сет-ват. Е, поне се уча да пиша празни пропъртита :) Сега ще ги оправя.