Homework - Принципи на ООП - част I


4

Здравейте, днес и утре са лекциите за Принципите на ООП (част 1) и съответно за домашното по темата.

Ето ги моите решения.

Задачите са интересни и дават бегла представа какво ни очаква на изпита. :)


в C# OOP от baretata (934 точки)


Отговори



3
Ето и моето разбиране за нещата как да си разцепвам логиката. Наистина тази и следващата лекция (респективно и домашните към тях) са много интересни и покриват целия C#.

от g.yonchev (2087 точки)


2
Моите - ТУК :)

от dentia (12519 точки)


1

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

1. Не е ли по-добре да имаме един базов абстрактен клас SchoolObject, от когото да наседаваме методите и пропъртито за коментара. Интерфейсите реално задължават всички да имат такова пропърти и методи за коментари, но реално кодът се повтаря в абсолютно всички обекти. Пък и доколкото разбрах интерфейсите са по-подходящи в случайте когато искаме даден тип да отговаря на изискване на определено поведение, а не да се гарантира наличие на някакви полета (като това за коментара). По-скоро интерфейсите трябва да съдържат методи? Ще съм Ви много благодарен ако хвърлите маалко светлина върху този проблем.

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

3. Мисля, че сте пропуснали да дефинирате клас за Студентите?


от todorm85 (1347 точки)

4

Здравей :)

Discipline.cs e е класът студент. Явно обаче в бързането съм допуснала правописна грешка и вместо disciple съм написала дисциплина. Ще бъде поправено :)

Интерфейсите гарантират, че всеки клас, който ги имплементира, има някакъв набор от функции, качества - според MSDN (An interface contains only the signatures of methodspropertiesevents or indexers.). В случая не ми се вижда толкова грешно използването му. Разбира се, може и да греша. Иначе - да, абстрактият клас също не е лош подход.


от dentia (12519 точки)



2

Вариант и от мен - тук

Нищо по-специфично няма, като че ли, в решенията. Задача 1: йерархия на хора, колекции от обекти, където има връзки, с методи за добавяне, съответно премахване на обект от тях, и един интерфейс за коментарите, наследяван от тези, които имат коментари. Задача 2 и 3: най-обикновено наследяване + рандом генератор за тестовете. Вероятно има място за подобрение. :)


от svetlai (1438 точки)


0
Ето и едно от мен :)

от wnvko (3123 точки)


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

Някой има ли идея как името на курса и номерът на студента от първа задача трябва да се проверят дали са уникални. Понеже изрично е казано: "Classes have unique text identifier. Students have name and unique class number."

Доколкото виждам, никой от колегите не го е направил в домашните си и ме интересува възможно ли е?

от dilyantraykov (1005 точки)


0
Супер въпрос, наистина това ми е убягнало. Предполагам един начин би бил чрез статично частно поле, което при всяко инстанциране на нов клас или студент се увеличава с единица. След това присвояваш тази стойност за идентификатор на текущата инстанция. Така си гарантираш, че всяка следваща инстанция ще има идентификатор с 1 по-голям от предходната. Разбира се докато не прехвърлиш макс на типа променлива :). Благодаря, за забележката!

от todorm85 (1347 точки)

1

За да ги направиш уникални, трябва да си пазиш някъде създадените обекти, за да можеш да проверяваш сред тях дали вече не се съдържа новата стойност. Вариант е да имаш статична pritave колекция с номерата на студентите, съответно идентификатори на курсовете, в която да ги добавяш при всяко създаване на нов студент/курс, и да правиш проверките в нея преди всяко създаване.

Това би трябвало да свърши работа в конкретния случай. В някакъв момент, когато се намесят бази данни и Entity Framework, решението се опростява до добавянето на един атрибут [Index("PropertyName", IsUnique = true)] над съответното пропърти. ;)


от svetlai (1438 точки)



1

от topalkata (6442 точки)


1

Доста се позабавлявах с това домашно. :) Определено най-приятното от всички до момента. А и адски много неща чак сега ми се изясниха. Горещо препоръчам всеки да си го направи с максимално старание. :)

И сега едно въпросче относно override-ването на ToString-а. Във втора задача имам абстрактен клас Human, който override-ва ToString метода на object. След това имам класове Student и Worker, които наследяват Human. Пробвах да им направя new метод ToString, който искам да използвам само когато работя със Student и Worker (за да изписва в допълнение към имената им съответно класа, в който са, или парите, които изкарват на час), а когато ги upcast-вам към Human, искам да използвам базовия метод ToString (на Human-а), който изписва само двете имена. Нещата обаче нещо не ми се получават. Или винаги се изписват само двете имена (когато използвам new при Student и Worker), или винаги се изписват заедно с конкретните им специфики (когато overridе-вам ToString-а и при Human, и при Student и Worker). От това, което изчетох, останах с впечатлението, че когато използваме ключовата дума new само "скриваме" базовия метод, но позволяваме той да се използва, когато upcast-нем съответния обект. А когато override-ваме даден метод изцяло "изтриваме" базовия и съответния обект вече си вижда само собствения. Така ли е или май по-скоро нещо пропускам? /В каченото домашно си намерих друго решение на проблема, но не ми харесва. Във варианта, който мъчех, при merge-ването на двата листа upcast-вах всеки Student и Worker към Human и ги добавях към нов лист, който после подавах на метода PrintResult<T>(IEnumerable<T> collection)/.


от IlianaB (1137 точки)


0

Може да погледнеш видеото на Ники Линк от 02 часа и 29 мин нататък

Решението е с abstract method, който се изпълнява от ToString() 


от c.l.angelov (510 точки)

0

c.l.angelov,

можеш ли да ми го покажеш нагледно това, с код





0

от antoanelenkov (1047 точки)


2

Ето и от мен.

@baretata, При конструктурите на животинчетата подаваш тру/фолс. Не погледнах, но предполагам, че така им избираш пола. Принципно, ако в кода си имаш различни методи и им подаваш булева стойност да избереш функционалност става доста объркващо. Аз лично използвах енумерация и в конструктора подавам SexType.Male/Female.


от apomarinov (378 точки)


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

от baretata (934 точки)


0
Решения и от мен.