Должна ли определенная доля членов распределяться между базовыми и производными классами?

Question

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

Причина структуры этих классов заключается в том, что я создаю программу чтения RSS и намереваюсь, чтобы эти два класса содержали данные в каналах. Первый будет содержать данные о самом фиде, например, исходный URL-адрес, расположение файла rss.xml в локальном хранилище, когда фид последний раз обновлялся и т. Д. Второй будет содержать информацию о статьях, содержащихся в фид, такой как дата / время публикации и целочисленный индекс, основанный на дате публикации, который будет использоваться для хронологической сортировки статей.

class feed
{
    string title;
    string description;
    string feed_url;
    string local_location;
    string channel;
    bool feed_is_changed; // This is a flag that will be raised and lowered
      // when the feeds are being refreshed
    double last_updated; // The last update date/time will be converted to a
      //standardised double value
}

class feed_item
{
    string title;
    string description;
    double pub_time;
    double pub_time_in_sec; // I'm separating the seconds so they can be used
      // for a 'sub-index' when there are multiple feeds with the same pubtime
      // (there are restrictions on the data types we are allowed to use
      // (concocting work-arounds will aid in understanding, etc))
    double pub_date;
    int pub_year;
    int order_in_list; // The index that will be calculated from pub_time,
      // pub_date, etc
}

Приведенный выше код не завершен, в настоящее время я только идентифицирую переменные и функции, и биты private / public появятся, как только они будут завершены. Как видно из приведенного выше кода, только две переменные, к которым предоставлен общий доступ, - это title и description.

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

Answer 1

Элемент feed_item не является каналом, поэтому он не соответствует принципу замены Лискова и не должен быть подклассом. Я должен проверить ваши уши - эта пара классов не звучит так, как будто они должны быть подклассами.

Иногда (очень, очень редко) наследование реализации является хорошей идеей, но обычно это лучше сделать, выделив разделяемые части в отдельный класс и используя его в обеих реализациях. Здесь это абсолютно ужасная идея - нет большого обмена кодом, поэтому преимущества в лучшем случае расплывчаты. Сохраняйте свой код простым!

Answer 2

Если вам действительно нужен базовый класс:

struct NamedItem {  // or maybe just "Item"
  string title;
  string description;
};

struct Feed : NamedItem {/*...*/};
struct FeedItem : NamedItem {/*...*/};

Или, как правило, предпочтительнее и лучше подходят в этом случае, используйте ограничение:

struct ItemInfo {
  string title;
  string description;
};

struct Feed {
  ItemInfo info;
  //...
};
struct FeedItem {
  ItemInfo info;
  //...
};

В частности, еслине знаю, как вы будете использовать «NamedItem», не зная самого производного типа, нет смысла использовать наследование.

Answer 3

Всего один производный класс? Тогда почти наверняка наследование - это неправильный дизайн.

Наследование является ограничением, и эти ограничения часто не появляются, пока позднее решение не станет еще дороже.

Мое эмпирическое правило - избегать наследования до тех пор, пока я не смогу привести ясные и убедительные аргументы в пользу его использования.