Geek Answers Handbook

Class Design Suggestions: Class Extension and Code Reuse

The essence of this question is to expand the class, minimizing jam packaging in just one class and maximizing code reuse. After reading this question, please feel free to edit the title or description to make it more concise. Although the post looks long, I just try to be solid using a lot of examples.

Suppose I have a class:

class UsedByManyPeople { // ...has many fields };

As the name suggests, this class is used by many developers. I need to add 2 classes to this class:

  • a convert () that converts UsedByManyPeople to SomeOtherType
  • getFileName (), which returns a string

Both are specific to my department needs.

First try solution

At first, I thought of simply adding 2 new methods to UsedByManyPeople. Thus, the class will look like this:

 class UsedByManyPeople { // ...has many fields public: SomeOtherType const convert() const; std::string const getFileName() const; };

However, the two functions are actually specific to my use case for my department, while the other departments do not even have a SomeOtherType class definition and do not care about getFileName ().

Clearly, the above approach is not a good approach (?).

How would you extend this class?

Alternatives that came to my mind:

Subclass UsedByManyPeople and create my own class.

  • Link data and method together

For example,

 class ExtUsedByManyPeople : public UsedByManyPeople { public: SomeOtherType const convert() const; std::string const getFileName() const; };

Create helper classes, one for each method (yikes!) And implement it as static methods.

  • Separate data from methods, responsibility of one class.

For example,

 class UsedByManyPeopleToSomeOtherTypeConverter { public: static SomeOtherType const convert(UsedByManyPeople const&); }; class UsedByManyPeopleFileName { public: static std::string const getFileName(UsedByManyPeople const&); };

Create one Helper class with all the methods inside.

  • Separate data from methods, one class many responsibilities

For example,

 class UsedByManyPeopleHelper { public: static SomeOtherType const convert(UsedByManyPeople const&); static std::string const getFileName(UsedByManyPeople const&); };
+6
c ++ oop class-design
source share
4 answers

Especially if the methods are specific to your departments using a class that you must implement, as in: Create one Helper class with all the methods inside.

There are several reasons for this:

  • One helper class can be located in another logical project structure
  • If your new methods do not require access to the internal state of the class, this is explicit. It provides better encapsulation. (which you added const ref, which is considered to be a good style).
  • UsedByManyPeople should not be responsible for converting itself to another type. This violates SOLID
+3
source share

the last parameter will not affect anyone else and isolates your one-time needs in one class

+2
source share

You must not modify the existing UsedByManyPeople class. If your department has a preference for which templates to use, then stay in your department style. Otherwise, create a conversion helper class. If you see multiple conversions along the way, you can create a class for each conversion. For the getFileName extension, you can get a class (if this is a really useful extension) or add it to your helper.

Again, your department standard (if one exists) should help you with this. If you don't have a standard, now it's time to create one.

+1
source share

Although this is almost identical (at least for use) to a class with publicly available static methods, you can use the namespace to encapsulate the procedures you need (as mentioned earlier, this will only work if the calls can be made from publicly available data and source class methods).

 namespace MyDept { SomeOtherType const convert( UsedByManyPeople const& ); std::string const getFileName( UsedByManyPeople const& ); }

which provides a very similar interface for the caller as static calls from a class, e.g.

 overusedObjectAsSomeOtherType = MyDept::convert( overusedObject );

I would like to hear from other people who answered on this list that there are any real differences between this approach and the one that has been largely suppressed.

+1
source share

More articles:


All Articles