4

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" – Robert Harvey Jul 13 '16 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? – Petyr Panos Jul 13 '16 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 Cooper Jul 13 '16 at 18:33
3

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 Jul 13 '16 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. – Nicol Bolas Jul 14 '16 at 14:08
  • Good point. Oh well, there are enough other reasons to prefer this solution anyway :) – Sjoerd Jul 14 '16 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. – Petyr Panos Jul 14 '16 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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