I am developing a project in C++ that deals with converting an ASCII hexadecimal string representation into binary. The class also has utilities in it for extracting info from the string.

Right now my project contains ASCIIUtil.hpp/cpp and Parser.hpp/cpp and it seems to be working correctly. However, I feel like a class is overkill in this situation since I really do not need a specific instance of ASCIIUtil or Parser but rather just access to the methods in those classes.

Should I:

1) Leave the code as is?

2) Leave the code as is but make all the methods static?

3) Get rid of the classes altogether and put everything into a namespace?

4) Something else?...

I feel like the answer is #3 since I could keep the files I currently have but remove the class syntax and wrap both of them in a namespace. This seems like it would make more sense but I also have a few private helper methods which I do not really want to be accessible to users in the future.

Thanks in advance!

  • "...but I also have a few private methods which I do not really want to be accessible to users in the future" Commented Jul 13, 2016 at 17:38
  • They are really just small subroutines of larger functions so that I don't have duplicated code. Is that really enough to necessitate building a class? Commented Jul 13, 2016 at 18:13
  • What unit tests do you have, and what design considerations have you discovered whilst writing these test (for example, is separation between Parser and it's consumers useful when testing the consumers?)?
    – Nathan
    Commented Jul 13, 2016 at 18:33

1 Answer 1


I don't see where a conceptual object is involved in performing string-to-binary conversions. That's a process, and using an object for it doesn't make sense in the general case.

That being said, there are reasons for wrapping a process up in an object. But these primarily have to do with state. For example, if multiple executions of the process will update some shared state, perhaps to speed up later executions. Or if you need to build and manage large tables of state (on the order of 100+KB), then you might want an object to allow the user to manage the existence of such state.

For string conversion, the closest thing to such state you might have is a mapping table from characters to hexadecimal digits. And how big would that be? 32 bytes at the most?

So it seems to me that this is best done as a namespace-scoped function, not some kind of object.

  • 3
    Namespace-scoped functions have the additional advantage that private helper functions do not need to be declared in the header at all.
    – Sjoerd
    Commented Jul 13, 2016 at 19:11
  • @Sjoerd: To be fair, you don't have to declare private helper function in a class header either. Just make them static free functions in the .cpp, rather than actual members of the class. Commented Jul 14, 2016 at 14:08
  • Good point. Oh well, there are enough other reasons to prefer this solution anyway :)
    – Sjoerd
    Commented Jul 14, 2016 at 16:07
  • I ended up putting everything in a namespace, got rid of the class for ASCIIUtil but left the Parser as a class and made part of it private. But upon reading @Sjoerd 's comment I think I'll remove the Parser class as well since I can actually make private functions in a namespace. Commented Jul 14, 2016 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.