基类和派生类之间是否应该共享特定比例的成员?

发布于 2024-09-30 16:30:03 字数 1415 浏览 1 评论 0原文

我目前正在为我为课程编写的应用程序设计类,我有两个类,听起来好像它们应该是基派生类对,并且确实共享两个成员变量,我的问题是它们每个都有七个成员变量并且没有任何操作。

这些类的结构的原因是我正在构建一个 RSS 阅读器,并且我打算让这两个类保存提要上的数据。第一个将保存提要本身的数据,例如源 URL、本地存储中 rss.xml 文件的位置、上次更新提要的时间等。第二个将保存提要中包含的文章的信息。 feed,例如发布日期/时间以及基于发布日期的整数索引,该索引将用于按时间顺序对文章进行排序。

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
}

上面的代码并不完整,我目前只是识别变量和函数,私有/公共位将在最终确定后出现。正如您从上面的代码中看到的,唯一共享的两个变量是 titledescription。

我不确定是否值得将它们设为实体库配对并停用五个不相关的变量,如果让它们完全独立的类更有效,或者如果这完全是情境问题,并且可以以任何一种方式争论。我担心的是,代码可能会变得难以维护和扩展,但一种方法或另一种方法可能会存在固有的执行开销。对此的任何想法和建议将不胜感激。

I'm currently designing the classes for an application I'm writing for my coursework, and I have two classes that sound as if they should be a base-derived class pair, and do indeed share two member variables, and my problem is that they each have seven member variables and no operations.

The reason for the structure of these classes is that I am building a RSS reader and I intend to have these two classes hold data on the feeds. The first one will hold the data on the feed itself, for example the source url, the location of the rss.xml file on local storage, when the feed was last updated, etc. The second will hold information on the articles contained within the feed such as the publication date/time and an integer index based on the publication date that will be used to chronologically sort the articles.

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
}

The above code is not complete, I'm currently only identifying variables and functions, and the private/public bits will come once they're finalised. As you can see from the above code, the only two variables that are being shared are title and description.

I'm not sure if it's worth making them an entity-base pair and just deactivating the five irrelevant variables, if it's more efficient to just make them completely separate classes, or if this is an entirely situational concern, and that it can be argued either way. My concerns are that the code may become difficult to both maintain and scale, but that there may be execution overhead inherent in one method or the other. Any thoughts and advice on this would be most appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

如此安好 2024-10-07 16:30:03

feed_item 不是 feed,因此它不符合里氏替换原则,并且不应该是子类。我应该检查一下你的耳朵——这对类听起来绝对不应该是子类。

偶尔(非常非常偶尔)实现继承是一个好主意,但通常最好将共享部分提取到一个单独的类中并在两个实现中使用它。在这里,这绝对是一个糟糕的主意——没有很好的代码共享,所以好处充其量也很模糊。保持你的代码简单!

A feed_item isn't a feed, so it fails the Liskov substitution principle and shouldn't be a subclass. I should check your ears — this pair of classes absolutely doesn't sound like they should be subclasses.

Occasionally (very, very occasionally) implementation inheritance is a good idea, but it's usually better done by extracting shared parts into a separate class and using it in both implementations. Here, it's absolutely a terrible idea — there's no great sharing of code, so the benefits are at best vague. Keep your code simple!

雪花飘飘的天空 2024-10-07 16:30:03

只有一个派生类?那么几乎可以肯定继承是错误的设计。

继承是有限制的,而这些限制通常直到后来才会出现,从而使决策变得更加昂贵。

我的经验法则是避免继承,除非并且直到我可以提出一个明确且令人信服的案例来使用它。

Just one derived class? Then almost certainly inheritance is the wrong design.

Inheritance is limiting, and those limits often don't appear until later making the decision even more expensive.

My rule of thumb is to avoid inheritance unless and until I can make a clear and compelling case to use it.

眼趣 2024-10-07 16:30:03

如果您确实想要一个基类:

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”,那么它不会使用继承没有意义。

If you really wanted a base class:

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

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

Or, usually preferred and a better fit in this case, use containment:

struct ItemInfo {
  string title;
  string description;
};

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

In particular, if you have no idea how you'll use a "NamedItem" without knowing the most derived type, it doesn't make sense to use inheritance.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文