Може и от твоята гледна точка да се направи. Определено ще се получи по-добре. Но не мисля, че е задължително.

Прав си, много по-добре е, ако батерията държи вида и издръжливостта си.

Не съм виждал досега подчертавките в полетата да са най-отзад. Виждал съм да са в началото на името на полето. Но не е добра практика да има nonalphanumeric символи в имената. По-добре свиквай без тях!

И още една забележка. Имената на полетата в CSharp са camelCase, а не се съединяват с долни тирета.

Това с подчертавките е deprecated code style и общо взето заместител на this спрямо четимост.

Абсолютно точно за този стил на писане направихте забележка, не се използва вече и слаша се слага отпред и така натам, аз обаче страшно се обърквам по стандартният начин :), тази писаница дето съм я направил наистина да не се гледа като стил, само да се проследи идеята. Обещавам че ще го роменя..в скоро време !

Еми ще пишем пак, каква ни е работата!

Колегите трябва да са свикнали с идеята че сме бета тестери и тези неща са нормални за този випуск :)

 bsdemon: Колега, това е симулация на реална ситуация, в която клиентът не знае какво иска и си променя заданието малко преди крайния срок. Случва се много често в IT индустрията. В реални условия това е повод да се предоговори цената на проекта, но тук просто остава да си пренапишем задачите и да се радваме, че ни подготвят за всичко, което може да ни сполети.

И аз мн му се чудих ... ама сигурно има логика (все някаква си ... :) )

Примерно като на HTML - правете header с таблици .... ама да знаете че не се прави така

Сигурно е повече за практика да не се чудим кое? как? защо? ако го срещнем някъде.

Аз лично ще карам по условие ...

Обаче при мен изниква др въпрос. 

Първо почнах да пера всичко е един фаил class Person, Main() и др. методи ги забих в един Program.cs.

После ми стана мн грозно така Person го направих в отделен файл. Сега се чудя методите за валидация на името и майла къде им е мястото .... при обекта, при Main() или в отделен file/class Methods ...  това нещо ми обягва

Ако валидацията ти е много голяма е добре да я изведеш в private метод, в класа където е пропъртито, към което принадлежи валидацията. Или ако валидираш email, то изнасяш private метод в класа Person. Този метод викаш в сетера на пропъртито Email.

За нашите задачи обаче валидациите са по две-три сравнения и се правят само в пропъртитата.

Да, тези които са точно за определено нещо ясно .... там при обекта

Но да кажем при мен сега в случея за името ...
Не мисля да използвам някакви регулярни изрази и т.н. , предпочитам да си ги правя с методи. Да кажем Името искам да е по дълго от два символа и да съдържа само символи от 'А' - 'Z' или 'а' - 'z' или 'а' - 'з' или 'А' - 'З' ... т.н. и за всяко едно може да е разбито на по отделно .... 

Мисълта ми е че когато методите за валидация можеш да ги ползваш за повече от един клас .... например ако имаш Човек, Куче, Място за разходка .... и трите ще си имат някакви имена напр.(Димитър, Жу, Борово око) .... за валидация искам да използвам един метод ... и на трите класа ли трябва да го пиша или да си направя dll за такива случай

Под optional означава, че или ги няма, или ги има. В C# една референтна променлива да я няма, означава да е null, а не да е празен стринг. Т.е. ако един стринг е празен, то той съществува, но няма стойност. Понеже числовите типове не могат да са Null, те се инициализират с 0;

За реализацията на optional reference параметри има два начина.

Първият: в конструктора им подаваш стойност по подразбиране null, напр. public Laptop(..., string ram=null,...) и (ако са повече от един) при извикването на конструктора ги подаваш(ако ти трябват) с наименовани променливи new Laptop(...,ram: someValue,...)

Другият начин е да направиш един конструктор само със задължителните стойности и в него да извикаш пълния конструктор със стойност null за незадължителните: напр пълен конструктор public Laptop(string model decimal price, string hdd, string ram,...){...}, непълен конструктор: public Laptop(string model, decimal price):this(model, price, null, null,...) {...}

При валидацията за незадължителните полета просто не правиш проверка дали са null, защото не е проблем да са null. Може обаче да проверяваш по други критерии. както в нашето условие е казано: параметърът е optional, но не може да е празен стринг означава може да е null, но ако не е null трябва да не е празен.

Числовите типове могат да са nullable 

Пример: int? num = null; 

Най-лесно и разбираемо мисля, че става с един конструктор(пълен), на който на незадължителните полета се задават стойности null, обаче целта на задачаите явно е да се упражни верижния конструктор, който вече е остарял според лекцията на Николай Костов от миналата година в курса по ОПП на Академията. Според него е добра практика да се използва наскоро въведения в .NET по-долу начин:

LINK

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

При ArgumentNullException и ArgumentOutOfRangeException ако ще подаваш само един параметър, той трябва да самото име на параметъра, който прави проблема, а не съобщението за грешка, както се прави примерно в ArgumentException.

Тук може да видиш конструкторите.

Благодаря за корекциите, радвам се като малко дете на коледа, защото вече ми се изясняват нещата.

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

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

Първо по това, което си написал разбирам, че подаваш стойността на полета, а не на пропъртита, или пък не именуваш правилно. Прието е полетата да са малка буква, а пропъртитата с голяма - например ако somePerson.age е поле -  somePerson.Аge ще е пропъртитито.

Полетата в общия случай са private и somePerson.age = 23 би трябвало да е невалидно извън класа (трябва да се използва somePerson.Аge).

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

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

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

Имам питане по Laptop Shop - защо в клас Battery имаш едно публично поле GeneralInfo и едно private? Не може ли да се мине само с едно публично?

Имам private поле и публично пропърти, което е сложено за валидация на подаваните данни :) Не виждам как ще стане само с пропъртито

Ooo, вярно, те като са едно под друго, съм взела пропъртито за поле...

Условието горе означава: ако value не е null , то хвърли грешка, ако е празен стринг или ако не съдържа @

Един вид, ако е различно от null и е празен ->хвърляй,
ако е различно от null и не съдържа @ -> пак хвърляй

По условие разрешените стойности са null или непразен стринг съдържащ @

Ако не сме дали стойност на email (email=null) не е необходимо да хвърляме грешка, защото email е optional

Ако имейл съществува (email!=null), то трябва да го проверим дали е празен и дали в него има @.

И това обяснение ме подсеща, че всъщност проверката за празен стринг може да отпадне, защото ако съдържа @, то значи не е празен :)

Благодаря за обяснението, сега схванах идеята! :)

Аз даже си мисля, че няма нужда да го проверяваме дали е празен стринга, а да го проверяваме само за това дали съдържа "@", защото ако стринга е празен той не съдържа "@".

Диляна, не претендирам, че това е правилният начин (т.к. сега ги уча тези неща и ще се радвам на коментар към подхода ми), но така ми се струва най-логично - в основния клас на програмата (Main) създаваш какъвто вид батерия ти трябва, а после генерираш всеки лаптоп с батерия по избор. Kак правя пропъртито - виж Laptop.cs:

LaptopShop

Това е по-правилният начин, от този който ни се показа на лекциите. Инициализация в конструктора по принцип е лош вариант. Въпреки, че точно в конкретния случай няма почти никаво значение дали е по начинът на Karlie или в конструктора :)

Но в друг случай би било от голямо значение:

Първо е важно, ентититата, които значат нещо, да бъдат реално такива - т.е. реални класове. Ако за всеки лаптоп правя new Processor("Intel"); То значи имам огромна нужда от клас, който се казва IntelProcessor.

Представете си абстрактен клас Processor. И два класа, които го наследяват - IntelProcessor и AmdProcessor.

Сега, ясно е - всеки лаптоп има нужда от процесор.

В конструктора на Laptop искаш да инициализираш нов процесор, но не си наясно той Интелски ли ще е или AMD. В такъв случай ще трябва да направиш някакво извращение, за да инстанцираш всички възможности и после да манипулираш точно тази, която ти трябва (абстрактен клас не може да се инициализира). Което е МНОГО ЛОШО решение.

Според LSP обект от тип IntelProcessor е също така и обект от тип Processor. Това означава, че ако някой метод очаква параметър от тип Processor и ти му подадеш негов подтип (IntelProcessor) всичко ще върви на шест точки.

В такъв случай, ето го и конструкторът на нашия Лаптоп клас:

public Laptop(Processor processor)

{

    this.Processor = processor;

}

Сега в main-a на LaptopShop класа правим следното:

Processor myLaptopProcessor = new AmdProcessor("4 GHz");

Laptop myLaptop = new Laptop(myLaptopProcessor);

Така имаме абсолютната гъвкавост да подадем какъвто подтип пожелаем, обектите да са независими един от друг, и в случай че искаме да направим някакви тестове, лесно можем да си направим mock object-и на съответните типове, в противен случай класът Лаптоп сам ще ги е инициализирал и не можем да ги заместим.

Pattern-ът се казва Dependency Injection и в обществото се води предпочитаният такъв.

Наистина е така... но си мисля че е абсурдно да сложим всички възможни компоненти на един лаптоп в отделни полета. Един лист от Компоненти или някакъв интерфейс който би ни свършил работа е по-удачния вариант. Много по лесно после боравим с данните. Иначе - this.processor + this.ram+this.....+this.card reader+this.wireless кофти става.