The gist of this question is about extending a class, minimizing jam-packing everything into a single class, and maximizing code re-use. After reading this question, please feel free to edit the title or description to make it more succinct. Though the post looks long, I am just trying to be thorough by using a lot of examples.
Suppose I have a class:
class UsedByManyPeople
{
// ...has many fields
};
As the name implies, this class is used by a lot of developers. I have to add 2 features to this class:
Both of them are specific to my department's needs.
At first I thought about simply adding 2 new methods to UsedByManyPeople.Thus, the class will now look like:
class UsedByManyPeople
{
// ...has many fields
public:
SomeOtherType const convert() const;
std::string const getFileName() const;
};
However, the 2 features are actually specific to my department's use case, and other departments do not even have the class definition of SomeOtherType nor do they care about the getFileName().
Clearly, the above approach is not a good approach (?).
How would you extend this class?
Alternatives that came to my mind:
For example,
class ExtUsedByManyPeople : public UsedByManyPeople
{
public:
SomeOtherType const convert() const;
std::string const getFileName() const;
};
For example,
class UsedByManyPeopleToSomeOtherTypeConverter
{
public:
static SomeOtherType const convert(UsedByManyPeople const&);
};
class UsedByManyPeopleFileName
{
public:
static std::string const getFileName(UsedByManyPeople const&);
};
For example,
class UsedByManyPeopleHelper
{
public:
static SomeOtherType const convert(UsedByManyPeople const&);
static std::string const getFileName(UsedByManyPeople const&);
};
Especially if the methods are specific to your departments use of the class you should implement them as in: Create a single Helper class, with all the methods inside.
There are several reasons for this:
UsedByManyPeople
shouldn't
be responsible for converting itself
into another type. This violates
SOLID