为什么要在这里麻烦继承?据我所见,所有 Chips 实例的行为都是相同的。这种行为是风味由序列号定义。
如果序列号只改变了几件事,那么您可以使用简单的映射在运行时基于序列号注入或查找行为(std::function)(为什么要复杂化!)。这种方式通过它们的序列号映射在不同的芯片之间共享常见的行为。
如果序列号改变了很多东西,那么我认为你的设计有点倒退。在这种情况下,您真正拥有的是定义芯片配置的序列号,您的设计应该反映这一点。像这样:
class SerialNumber {
public:
// Maybe use a builder along with default values
SerialNumber( .... );
// All getters, no setters.
string getFlavour() const;
private:
string flavour;
// others (package colour, price, promotion, target country etc...)
}
class Chips {
public:
// Do not own the serial number... 'tis shared.
Chips(std::shared_ptr<SerialNumber> poSerial):m_poSerial{poSerial}{}
Chips(int shelf, SerialNumber oSerial):m_poSerial{oSerial}, m_nShelf{shelf}{}
string GetFlavour() {return m_poSerial->getFlavour()};
int GetShelf() {return m_nShelf;}
protected:
std::shared_ptr<SerialNumber> m_poSerial;
int m_nShelf;
}
// stores std::shared_ptr but you could also use one of the shared containers from boost.
Chips pringles{ chipMap.at("standard pringles - sour cream") };
这样,一旦您为您的产品设置了一组序列号,那么产品行为就不会改变。唯一的变化是封装在序列号中的“配置”。意味着Chips
类不需要改变。无论如何,有人需要知道如何构建类。当然,您也可以使用基于模板的注入,但您的代码需要注入正确的类型。
最后一个想法。如果SerialNumber
ctor 接受一个字符串(例如 XML 或 JSON),那么您可以让您的程序在运行时读取配置,在它们由经理类型人员定义之后。这将使业务需求与您的代码分离,这将是一种面向未来的稳健方式。
哦...我建议不要使用匈牙利符号。如果您更改对象或参数的类型,您还必须更改名称。更糟糕的是,您可能会忘记更改它们,而其他人会做出不正确的假设。除非您使用 vim/notepad 进行编程,否则 IDE 将以更清晰的方式为您提供该信息。
@ user1158692 - 实例化的一方Chips
只需要了解SerialNumber
我提议的设计之一,并且该提议的设计规定SerialNumber
该类用于配置Chips
该类。在这种情况下,Chips
由于他们的亲密关系,使用的人应该知道 SerialNumber。类之间的亲密关系正是它应该通过构造函数注入的原因。当然,如果需要,可以非常简单地更改它以使用 setter,但由于表示的关系,这是我不鼓励的。
我真的怀疑在不知道序列号的情况下创建芯片实例是绝对必要的。我想这是一个应用程序问题,而不是课程设计所要求的问题。此外,如果没有 SerialNumber,该类不是很有用,如果您确实允许在没有 SerialNumber 的情况下构建该类,您将需要使用默认版本(需要 Chips 知道如何构造其中一个或使用全局引用!)或者您最终会通过大量检查来污染班级。
至于您对 shared_ptr 的投诉……您到底是如何建议澄清所有权语义和责任的?也许原始指针将是您的解决方案,但这是危险且不清楚的。shared_ptr 清楚地让设计人员知道他们不拥有该指针并且不对它负责。