开发者

Effectively changing constness of member variable in subclass

开发者 https://www.devze.com 2023-03-27 19:56 出处:网络
While developing a game I have designed a class that in normal operation has a const member variable like so:

While developing a game I have designed a class that in normal operation has a const member variable like so:

class Foo {
    /* ... */
protected:
    const boost::unordered_map<short, short> m_map;
};

However, in the accompanying game editor I would like to reuse the Foo class, but provide a way to edit this const member as it is used in rendering the game (and I would like to reuse the renderer for the editor). As such, I was planning on subclassing the Foo class in order to provide methods for changing various properties as well as serializing the data for saving the editor data. I'm wondering if there's an elegant way to do this while keeping the member as const or if there is a better design?

The options I have come up with so far are:

  • Remove the const keyword and simply provide no public interface for changing the variable
  • Change the renderer to use an interface and implement it separately in both Foo and the editor version of Foo
  • Reimplement the public interface of Foo to use a new, mutable map for the editor version of Foo
  • Something else entirely?

At first hand the interface path seems like the cleanest from a language perspective, but leads to an interface (abstr开发者_开发技巧act base class) for each and every class involved which is a decent effort. Suggestions and ideas welcome. (Note: I had a hard time coming up with a descriptive title; suggestions welcome for that also.)


If making your variable non-const and protected feels too intrusive perhaps you can have a design where the variable is non-const and private, and provide protected member functions to manipulate it with whatever constraints you had in mind when you made the variable const in the first place.


Are they two separate projects/targets? There are those who don't like to use the preprocessor so much, but if they're compiled separately then I'd just use a compiler flag to build it one way for the game and one way for the editor:

#ifdef __EDITOR__
     boost::unordered_map<short, short> m_map;
#else
     const boost::unordered_map<short, short> m_map;
#endif

If I remember correctly for GCC you'll want something like -D __EDITOR__, but all good IDEs will have a field in the project setup where you can specify compiler flags. It saves you a lot of refactoring or adding additional complications to your code base.


In my opinion your problem is a quite far-fetched. There is no reason in two classes with the same functionality. Do not repeat yourself. I suggest to create a single class with mutable attribute, add getter and setter, and do not use setter without necessity.

0

精彩评论

暂无评论...
验证码 换一张
取 消