Вернуть вектор, зная, что он всегда будет содержать одну запись, чтобы соответствовать остальному интерфейсу? - PullRequest
Новая
       40

Вернуть вектор, зная, что он всегда будет содержать одну запись, чтобы соответствовать остальному интерфейсу?

0 голосов
/ 12 февраля 2011

Я пишу небольшое приложение для адресной книги и имею дилемму дизайна относительно интерфейса для источника данных / бэкэнда.

У меня есть следующий абстрактный базовый класс для классов источников данных: 

class DataSource
{
    private:

    public:
        virtual std::auto_ptr<Contact> getContact(int id) = 0;
        virtual ContactRecordSet getAllContacts() = 0;
        virtual bool addContact(const Contact& c) = 0;
        virtual bool updateContact(int id, const Contact& c) = 0;
        virtual bool deleteContact(int id)=0;
        virtual ~DataSource() {};

};

Ниже приведена моя структура записей, а набор записей tmy - это typedef для вектора STL этих объектов. 

class Contact 
{
    public:
        std::string firstName;
        std::string lastName;
        std::string phoneNumber;
        std::string address;
        std::string email;

};

typedef std::vector<Contact> ContactRecordSet;

Мой вопрос касается типа возвращаемого значения, используемого для метода DataSource :: getContact ()и метод DataSource :: getAllContacts () и метод поиска, который будет добавлен в ближайшее время, который будет получать записи на основе запроса.

DataSource :: getContact () вернет ноль или 1 запись, так как я ищу по уникальному идентификатору.DataSource :: getAllContacts () вернет ноль или более контактов.Предстоящий метод поиска вернет ноль или более контактов.

Теперь, когда у меня есть метод getContact (), он возвращает auto_ptr в Contact, потому что возвращать ContactRecordSet казалось расточительным, если я точно знаю, что ониникогда не может быть больше единицы, и это позволяет мне возвращать NULL, если нет записи с таким идентификатором.

Было бы лучше, если бы getContact () также возвращал ContactRecordSet, просто чтобы интерфейс оставался согласованным?

Часть меня возмущена идеей возврата структуры данных, подобной той, для одного объекта, но с другой стороны, она более последовательна, и семантика для проверки, было ли найдено значение для этого идентификатора, кажется болеев соответствии с общей абстракцией проекта (проверка длины возвращенного набора записей и проверка на наличие NULL auto_ptr).

Что вы все думаете?

(Примечание.Я, вероятно, чрезмерно инженерно для простого приложения адресной книги, но я хочу, чтобы было легко поменять местами разные бэк-энды (flв файл, SQL и т. д.), если они реализуют общий интерфейс.Цель состоит в том, чтобы попрактиковаться в правильном модульном проектировании и разделении проблем.)

ОБНОВЛЕНИЕ

Полагаю, я мог бы взглянуть с противоположной точки зрения и вернуть несколько методов записиauto_ptrs для объекта ContactRecordSet.Таким образом, а) это согласуется с тем, что вы всегда получаете указатель на объект, и б) у вас нет лишних затрат на возврат std :: vector, если набор записей пуст, просто возвращаете указатель NULL.

Ответы [ 2 ]

2 голосов
/ 12 февраля 2011

Что соответствует возвращению множественного типа для функции, не являющейся множественным?

Я думаю, вам нужно работать с другим определением "согласованности".

2 голосов
/ 12 февраля 2011

Я всегда следую принципу , возвращаю наименее сложную вещь, которая определяет ваш объект. Векторы предназначены для хранения списков вещей, а не одного элемента, и хотя это может сделать семантику симметричной, она, несомненно, будет неинтуитивнойдругому разработчику.

...