[Homework] OOP - Defining Classes - Януари 2015 - Софтуерен университет

velio84 241 Точки

[Homework] OOP - Defining Classes - Януари 2015

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

Ето го моето първо домашно:

На 3-та задача имам 2 класа в 1 файл, знам (вече) че не се прави така, но домашното го писах преди 2 седмици, а сега не ми се занимаваше да преправям.

4-та задача я написах днес, след като изгледах половината курс. Не ми се занимаваше да преправям override ToString на класовете, затова като сортирах само CurrentStudent-ите в нов масив, заедно с това направих и нови анонимни обекти като им взимам които пропертита искам (ред 21-35). C# изкарва анонимните обекти подобно на JavaScript, достатъчно добре ми се стори за целите на задачата :)

Също за 4-та ме мързеше да пиша и пропертита с проверки за различните елементи, затова само съм сложил get-ъри и set-ъри.

Тагове:

24/01/2015 00:28:26 C# OOP Basics 24/01/2015 16:48:30

Filkolev 4482 Точки

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

Според мен за живота на батерията има два логични варианта:

1) Да е поле на самата батерия. Все пак това е нейно свойство най-вече.

2) Да се изчислява динамично на база характеристиките на батерията и добавените компоненти, т.е. да е едно пропърти, което има само гетър.

Колегата е коментирал, че според него би трябвало да е второто и до някъде съм съгласен, че една и съща батерия може да има различен живот в различни машини.

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

Вие как сте подходили? Повечето домашни, които видях тук, бяха възприели първия вариант.

29/01/2015 15:57:00

RoYaL Trainer 6849 Точки

"до някъде съм съгласен, че една и съща батерия може да има различен живот в различни машини."

Tight coupling. Не трябва да е така. Обектът Батерия може да съществува, без има обект Компютър (или Машина). Както в реалният живот можеш да си купиш батерия, така и в пограмирането можеш да кажеш колкото си искаш пъти "new Battery()" без да си създал преди това инстанция на обекти от тип Машина/Компютър.

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

Позволено е само обратното. Да не можеш да създадеш компютър, ако не си му подал компоненти. Но далеч не е правилно да не можеш да правиш компоненти, когато нямаш компютър. Нарушава се така наречения Law of Demeter

29/01/2015 16:41:21 29/01/2015 16:43:33

Filkolev 4482 Точки

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

29/01/2015 16:48:54

RoYaL Trainer 6849 Точки

Да, нещо такова би свършило работа, но пак не е съвсем правилно.

Това по-скоро на абстрактно ниво би представлявало:

- Нещо от тип машина, което задължително приема нещо от тип Зареждащо се устройство, и задължително има свойство до колко е заредено.

Изразено по някакъв подобен начин: http://pastebin.com/u6ce8ZkX

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

29/01/2015 17:15:10 29/01/2015 17:22:01

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

gpetr 12 Точки

Колеги, срокът за оценяване на домашното трябваше да е до днес 23:59:59, обаче вече е закрито. Какво става?

30/01/2015 13:34:11

alex.mitev 20 Точки

Здравейте, искам да питам нещо.

Искам батерията да има batteryTypes , които да са само 2 - Li-Ion ili Ni-Mh.

Идеята ми е да направя enum batteryTypes { 1, 2};

искам v battery batteryType da e string, но setter-a да приема еnum - ако е едно, да връща Li-Ion, ако е 2 - Ni-mh.

В c# обаче как да направя setter-a да приема аргумент?

Мисля, да направя сеттер-а private, no da napraя public setBatteryType( приема enum)

{

туk proverqvam enum 1 ili 2 e , и викам private setter-a, който ще присвои съответният string.

}

в правилна посока ли разсъждавам?

23/04/2016 00:52:26

Filkolev 4482 Точки

Енумерацията си прави номерирането, по-добре си кръсти опциите както са видовете батерии и си ги ползвай така, иначе е криптично:

enum BatteryType
{
    LiIon,
    NiMh
}

23/04/2016 08:54:15

alex.mitev 20 Точки

Ок, а относно въпроса за връщането на стринг, чрез публичен метод, който извиква private setter - удачно ли е?

23/04/2016 09:03:01

Filkolev 4482 Точки

Дай пример с код, не съм сигурен, че разбирам какво точно искаш да направиш.

25/04/2016 14:00:09

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

maria_ruskova 15 Точки

Аз много се оплетох с тази 4-та задача и нямам представа какво бъркам. Знам, че съм избрала някакъв безумен начин за решаване, но още не мога да се ориентирам добре с ООП-то и не се сетих как иначе. Дава ми 40 от 100. Това сътворих: https://github.com/mariyaVR/OOP/blob/master/DefiningClasses/4/Program.cs

25/06/2016 22:57:35