Професионална програма
Loading...
simeon_petrov avatar simeon_petrov 45 Точки

[C# -OOP Advanced] Exercises: Interfaces Как е по-добре да подам сет от елементи?

Въпросът ми е за Exercises: Interfaces, Problem 8. Military Elite.

Там: LeutenantGeneral – holds a set of Privates under his command

Генерала ще има: public HashSet<int> PrivatesIdUnderCommand { get; set; }

Информацията, която се подава в инпута е във вида: LeutenantGeneral: “LeutenantGeneral <id> <firstName> <lastName> <salary> <private1Id> <private2Id> … <privateNId>” where privateXId will always be an Id of a private already received through the input.

Въпросът ми е как е най-добре да се подаде този сет от номера на редници към генерала?

Вариант първи в майн метода преобразувам редицата от стрингове в HashSet<int> и така го подавам в конструктора на генерала.

Вариант втори подавам стрингчетата на конструктора и вътре в него се преобразуват в HashSet<int> ? Това не знам как ще стане, като броят на стринговете не е известен предваретелно и може да е много голям.

Вариант трети подавам стринговете касаещи Idтата на редниците като един стринг на конструктора и вътре в него те се Splitват и се преобразуват в HashSet<int>? Демек в майн метода сплитвам инпута по интервал и после събирам само Idтата в един стринг, който се подава на конструктора на генерала.

0
C# OOP Advanced
RoYaL avatar RoYaL Trainer 6847 Точки

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

private int age;

а неговията сетър да е стрингов

public string Age { get { return this.age.ToString() } set { this.age = int.Parse(value); } }

Публичните методи, пропъртита и конструктори на класа дефинират неговия програмен интерфейс (API). Ползвателите на АПИ-то трябва да се съобразяват с него. Ако АПИ-то очаква инт за сетър, ползвателите да се оправят да парсват. Ако очаква Set<> в конструктора, ползвателите да създадат този Сет (в случая ползвател е мейн метода ти) и да го подават.

Ако искаш да прикриеш това, че е Сет, може да приемаш params (variadic arguments), които в конструктора да wrap-неш в Set. (това ще има известен performance overhead, но често продаваме производителност за четимост и поддръжка).

 

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

1
mbencheva avatar mbencheva 52 Точки

Аз пък пазя Privates в LeutenantGeneral в List<Private> - private проперти, като имам публичен метод за добавяне на Private в листа.

По условие пише „privateXId will always be an Id of a private already received through the input“ и съответно разчитайки на това в мейна създавам LeutenantGeneral и по подадените Ид-а намирам съответния Private, който трябва да съществува вече и с публичния метод от LeutenantGeneral го добавям към private листа.

Не знам дали е добра идея или не...

0
RoYaL avatar RoYaL Trainer 6847 Точки

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

1
14/07/2016 12:38:18
kaloyannikov avatar kaloyannikov 531 Точки

Моя подход -> добре ли е на 1 място пазя всички privates , и в генерала взимам тая колекция и я филтрирам по idto github

0
Можем ли да използваме бисквитки?
Ние използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Можете да се съгласите с всички или част от тях.
Назад
Функционални
Използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Използваме „сесийни“ бисквитки, за да Ви идентифицираме временно. Те се пазят само по време на активната употреба на услугите ни. След излизане от приложението, затваряне на браузъра или мобилното устройство, данните се трият. Използваме бисквитки, за да предоставим опцията „Запомни Ме“, която Ви позволява да използвате нашите услуги без да предоставяте потребителско име и парола. Допълнително е възможно да използваме бисквитки за да съхраняваме различни малки настройки, като избор на езика, позиции на менюта и персонализирано съдържание. Използваме бисквитки и за измерване на маркетинговите ни усилия.
Рекламни
Използваме бисквитки, за да измерваме маркетинг ефективността ни, броене на посещения, както и за проследяването дали дадено електронно писмо е било отворено.