Обектно-ориентирано програмиране (КН, 2 поток) 2013/14

Отговорите на въпросите са по-долу:

• В класа Dictionary стойността на изтритите вече контакти с NULL ли трябва да се замества, или е по-добре да се реализира метод за изтриване на елемент (двойка ключ-стойност) от речника?
  • В задачата не е указано, следователно имате избор да го реализирате както намерите за добре.
• Не е ли по-смислено Contact да е структура вместо клас? Така няма да има нужда да се реализират селектори и мутатори за него.
  • Така е, но пък няма да може да се прави проверка за коректност, която би се правила със мутаторите, например. По-добре като клас.
• Кой е по-добрият вариант: класът ContactBook да е приятелски спрямо Dictionary с цел да може да му се достъпват член-данните (например за да се обходят ключовете и/или стойностите му), или да се реализират подходящи селектори за достъп до началото и края на масивите с ключове и стойности?
  • Не е добре ContactBook да е приятел на Dictionary. Има някакъв смисъл Dictionary да е приятел на ContactBook, но по-добре да се избегне, ако е възможно.
• Нали не е задължително имената на контактите да са уникални? Т. е. да е възможно няколко души да са с едни и същи имена, като номерата и идентификаторите им са различни? В такъв случай чрез речника за достъп по име ще може да се достъпи само един от контактите с еднакви имена (реших, че е най-смислено да е този с най-малкия идентификатор по лексикографска наредба).
  • Да, възможно е да има съвпадение на имената. Макар че не е указано какво се прави в случай на конфликт, варианти са: избиране на някой от тях (напр. най-малък по идентификатор) или връщане на всички по някакъв начин. Отново, реализирайте както намерите за добре.
• Грешка ли е, ако в класа ContactBook използвам претоварвания (overload-вания) на методите за намиране и премахване на контакт, приемащи като аргументи класовете Name, PhoneNumber и Id, наследяващи класа std::string, и едно претоварване, приемащо като аргументи std::string и параметър от изброен тип CONTACT_FIELD_TYPE, указващ дали въпросният std::string представлява име, телефонен номер или идентификатор?
  • Не е грешка, по-скоро ми се струва като интересно решение, макар и малко усложнено.
• При добавяне на нов контакт в книгата трябва ли да се прави проверка дали той вече съществува (и ако съществува, да не се прави нищо), или, ако съществува, направо да се замества с новия контакт? Все пак е възможно контактът да съвпада само по някои свои полета, а не по всички, например да се различава само по телефонен номер (въпросният човек си е сменил номера) или по име (номерът вече принадлежи на друг човек), така че е смислено да има начин контактите в книгата да може да се променят.
  • Не е изрично указано какво трябва да се прави в този случай, така че можете сами да изберете поведението, което ви се струва най-смислено.
• Щом методът за намиране на контакт не трябва да позволява промяната му, по-смислено ли е самият контакт да се връща като резултат (тип Contact), а не псевдоним към него (тип Contact&)?
  • Това не са единствените варианти за връщан резултат, така че да не се позволява промяна, има и по-добри решения. Със сигурност, връщането на Contact& е грешка, понеже позволява промяна.

По втората задача:

• Имаме ли право да ползваме стандартните библиотеки на C++ при парсването (десериализацията) (конкретно имам предвид <string> и <sstream> и класовете std::string и std::istringstream), или за токенизация да ползвам функцията strtok, а за преобразуване на низ към double - atof?
  • Да
• При обработката (десериализацията) на формулите взима ли се предвид приоритетът на операциите? В примерите, дадени в условието, всяка двуместна операция е оградена със скоби. Това винаги ли трябва да е така и трябва ли да се задължава потребителят да въвежда формулите по този начин?
  • Да, винаги двуместните операции са оградени със скоби, т.е. няма приоритет на операциите.
• Трябва ли да се грижа по някакъв начин за динамично заделената памет в рамките на функцията readFormula() (например да я сложа в клас, в който деструкторът да освобождава заделената памет, към която са запазени указатели, които са член-данни на класа)?
  • Добре е да се грижите за правилното управление на паметта за десериализацията.

Освен това, дали е възможно да добавяме допълнителна функционалност (методи, класове и т. н.), различни от указаните в условието (с цел улеснение)?

Разбира се, че е възможно :)