Pros & cons of a callback (std::function/std::bind) vs an interface (abstract class)

Question

I'm creating a server application in C++11 using Boost.Asio. I've created a class, Server, which takes care of accepting new connections. It's basically just:

void Server::Accept() {
  socket_.reset(new boost::asio::ip::tcp::socket(*io_service_));
  acceptor_.async_accept(*socket_,
                         boost::bind(&Server::HandleAccept, this, boost::asio::placeholders::error));
}

void Server::HandleAccept(const boost::system::error_code& error) {
  if (!error) {
    // TODO
  } else {
    TRACE_ERROR("Server::HandleAccept: Error!");
  }
  Accept();
}

I've found two ways (I'm sure there are more) to "fix" the TODO comment, i.e. to move the socket to wherever it should go. In my case I just want it back to the class instance that owns the Server instance (which then wraps it in a Connection class and inserts it to a list).

1. Server has a parameter in its constructor: std::function<void(socket)> OnAccept which is called in HandleAccept.
2. I create an abstract class, IServerHandler or whatever, which has one virtual method OnAccept. Server takes IServerHandler as parameter in its constructor and the class instance owning the server instance extends IServerHandler and constructs Server with *this as parameter.

What are the pros and cons of option 1 vs option 2? Are there any better options? I'm having the same problem in my Connection class (OnConnectionClosed). Also, depending on how I decide to design the system, it might need a OnPacketReceived and OnPacketSent callback.

Answer 1

I strongly prefer the first way for several reasons:

• Representing concepts/functionality via interfaces/class hierarchies makes the code base less generic, flexible, and then more difficult to mantain or scale in the future. That kind of design imposes a set of requirements on the type (the type implementing the required functionality) which makes it difficult to modify in the future, and most prone to fail when the system changes (Consider what happens when the base class is modified in this type of designs).

• What you called the callback approach is just the classic example of duck typing. The server class only expects a callable thing which implements the required functionality, nothing more, nothing less. No "your type must be coupled to this hierarchy" condition is required, so the type which implements handling is completely free.

• Also, as I said the server only expects a callable thing: It could be anything with the expected function signature. This gives the user more freedom when implementing a handler. Could be a global function, a bound member function, a functor, etc.

Take the standard library as an example:

• Almost all standard library algorithms are based on iterator ranges. There is no iterator interface in C++. An iterator is just any type which implements the behaviour of an iterator (Being dereferenceable, comparable, etc). Iterator types are completely free, distinct, and decoupled (Not locked to a given class hierarchy).

• Another example could be comparators: Whats a comparator? Is just anything with the signature of a boolean comparison function, something callable which takes two parameters and returns a boolean value saying if the two input values are equal (less than, bigger than, etc) from the point of view of a specific comparison criteria. There is no Comparable interface.

Answer 2

What version of boost are you using? The best way IMHO is using coroutines. The code will.be eeasier to.follow. It will look like synchronous code but now I cannot give a comparison since I am writing from a mobile device.

Answer 3

Just to mention that in many cases you do PREFER binding to a specific type.
Therefore in this case declaring that your class MUST have a IServerHandler helps you and other developers understand what interface they should implement in order to work with your class.
In future development when you add more functionality to IServerHandler you force your clients (i.e. derived classes) to keep up with your development.
This might be the desired behavior.

Answer 4

It all boils down to your intentions.

On one hand, If you want to expect that an functionality belongs to a specific type, then it should be implemented in terms of it's hierarchy, such as a virtual function, or a member pointer, etc. Limitation in this sense is good because it helps to makes your code easy to use correctly, and difficult to use incorrectly.

On the other hand, if you just want some abstract "go here and do this" functionality without having to bother with any burden of it being tightly coupled to a specific base class, then clearly something else will be more appropriate like a pointer to a free function, or an std::function, etc.

It's all about which is more fitting to the specific design of any specific part of your software.