0

I am currently building a library in C++11, where I spent a lot of time trying to design a good interface. After some small redesigns along the way, I've ended up with a design that I am happy with. The main public interface only consists of two functions in a namespace (ignoring extra utility functions etc.).

Later I found that I needed to create some objects based on a bitflag parameter given in one of the functions. Both functions can be expected to be called very often (e.g. to process each frame of a video) where the flags are unlikely to change. So to avoid repeated object creation I made a utility function for reusing those objects based on the bitflag parameter (a simplistic object cache function with a static container of shared_ptr objects inside it if you're wondering). A cache class of some kind would probably be better, but I digress.

I now face the following design decision: Should I keep my functions or should I redesign my library around a main class instead?

I really like the simplicity of my two functions and creating an entire class feels like overengineering, and functions make more sense for the interface I feel. The main class would also have to coordinate processing calls (e.g. to process image frames), with subsequent getters to retrieve information.

On the other hand, a class will make reuse of objects more intuitive, do away with a bunch of function friend declarations, and better represent dependencies between multiple calls, whereas the functions would have a common dependency on object reuse which feels less intuitive since they are separate functions, but can perhaps work if designed correctly behind the scenes.

  • Why the aversion to classes? A class declaration isn't hard and beats the static globalness of free functions. As it stands, consumers of your code have to wrap it in an interface and class anyway not to ruin their testability (mocking) and DI. Free functions aren't evil, they have uses, but I wouldn't use them by default. – Nathan Cooper Oct 18 '15 at 23:44
  • It's not an aversion per say. I use classes all the time, but I just feel like the functions yield a cleaner interface in this particular case. You mean that users could derive from the class to mock it or use it for DI, right? – NordCoder Oct 19 '15 at 18:06
0

Neither.

Instead, consider making your code reentrant again:

  1. Put all the costly but reusable state in a class.
  2. Take that as an argument by reference, and clean up the interface to get rid of whatever you thus duplicated.
    (Whether you add a member forwarding to the free function is yours to decide.)
  3. Add a convenience-function encapsulating both steps with the same interface and name as the old function had to preserve API and ABI compatibility, maybe with a [[deprecated]]-mark if you consider removing it in the future.
  • Just to clarify: (1) E.g. a sort of config/state/options class (3) Encapsulating both previous steps: the creation of the class in (1) with the call of the refactored function? So you don't think a "main" class is the way to go? I like your suggestion nonetheless :) – NordCoder Oct 19 '15 at 18:16

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.