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

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

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

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).

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

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

ОБНОВИТЬ

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

Источник

2 ответа

Решение

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

Источник

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

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

Источник
Другие вопросы по тегам