Функционални
Използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Използваме „сесийни“ бисквитки, за да Ви идентифицираме временно. Те се пазят само по време на активната употреба на услугите ни. След излизане от приложението, затваряне на браузъра или мобилното устройство, данните се трият.
Използваме бисквитки, за да предоставим опцията „Запомни Ме“, която Ви позволява да използвате нашите услуги без да предоставяте потребителско име и парола. Допълнително е възможно да използваме бисквитки за да съхраняваме различни малки настройки, като избор на езика, позиции на менюта и персонализирано съдържание.
Използваме бисквитки и за измерване на маркетинговите ни усилия.
Не е безсмислен, понеже може да искаш впоследствие да ограничиш някакви действия на база това дали служителят е обикновен или мениджър. Ако нямаш абстрактен клас ще трбява да проверяваш всичките му наследници. Тук не се добавят данни или поведение, но се слагат под една шапка няколко класа, което може да ти е необходимо впоследствие. Ако пишеш приложение с идеята да го разширяваш (например на екипен проект), хубаво е абстракцията да е на високо ниво, за да е гъвкаво. Абстрактен клас е излишен ако има само един наследник и няма изгледи да има повече.
Прав си. Не го бях поглеждал от тази гледна точка :)
Имам 3 въпроса от задача 3 към djc_bg2015
1.Интерфейсите ти се разширяват един с друг.Имаш и абстрактни класове ,които се наследяват един с друг?Защо тогава интерфейсите трябва да се разширяват?
2.В класа Manager:
(1) public IList<IEmployee> Employees => this.employees;
(2) public IList<IEmployee> Employees
{
get { return this.employees;}
}
(1) и (2) едно и също ли е?
3.Клас Manager пази списък от Employee.Не използваш конструктор,нито метод ,за да добавяш елементи в него.Как тогава ще се използва този списък?
Здравей,
1. Oсновно исках да потренирам наследяванията, не съм имал нещо конкретно предвид с наследяването на интерфейсите и след това и на класовете. Някой с опит в ООП може да хвърли светлина по върпоса кое е правилно и кое не в конкретния случай.
2. Дa, нарича се Expression body и е нововъведение от C#6
3. След като няма нищо конкретно написано в условието на задачата относно как да се добавя и премахва служител от този лист, оставих гетъра публичен, така че с .Add може да се добавя в листа и с .Remove да се маха. Иначе, би било правилно да имаме публични методи в класа за адване и премахване, а пропъртито да връща IEnumerable.
В коментар към друг въпрос бях писал относно екстендването на интерфейсите и наследяването на класовете. Накратко - да, трябва хем IEmployee да екстендва IPerson, хем Employee да наследява Person. Едното не замества другото.
djc_bg2015, Filkolev, абстрактният клас RegularEmployee според мен, наследявайки Employee - няма нужда да имплементира интерфейс IRegularEmployee, защото в последния не добавяме нищо и реално е IEmployee. Прав ли съм?
Ако няма какво да се добави в IRegularEmployee - не слагай такъв интерфейс. Може да имаш IEmployee и IManager който го екстендва, клас Employee : IEmployee, който се наследява от RegularEmployee и Manager : IManager. Клас или интерфейс, който не добавя нищо е излишен.
djc_bg2015, как става това в конструктура на Employee да сложиш this.Department = department, като то няма set-er в propety-то ?
И на мен това ми беше чудно, но е факт, че работи. Предполагам, защото Department e enum и така или иначе се избира една от константите му.
На C# 6 има едно нововъведение, че ако private set-er се ползва само в конструктора може въобще да не го пишем. Resharper го оцветява в сиво ако се сложи. Засега бих ви препоръчал да ги пишете изрично сетърите, за да е по-ясно за хората, които четат кода.
Мда, така е. Тъкмо щях да го пиша като отговор :)
На изпита ще можем ли да ползваме C# 6?
Да, джъджа поддържа C# 6 :)