Two similar methods to process a queue of messages

I have two functions with loops that behave nearly identically, but with some key differences. As a consequence, most (but not all!) of the code in the functions is repeated. I can accept this repetition, but I would prefer to have the repeated code in a single place, so that I do not need to remember to change both if a modification of the logic is required.

These methods are contained in an abstract base class, and they are intended to provide functionality to clients that consume messages from a queue. Clients provide their custom functions (as Action or Func) and the base class handles interacting with the message queues and executing the custom functions. Some clients want to parse data contained in a queue and do nothing else, but other clients want to parse data contained in a queue and push resulting data along a workflow into another queue.

A concrete example for the first case (where nothing is passed along a workflow) is a logging queue. Applications send messages containing logs to the logging queue. The client reads those messages and inserts the logs to a DB (or wherever). The workflow terminates at this point.

A concrete example for the second case is an ETL process where the workflow has been separated into multiple queues. There would be an extraction queue, a transformation queue, and a load queue. The clients of the extraction queue need to read messages, perform some data processing, and then write messages containing the processed data into the transformation queue -- where the clients of the transformation queue will perform a similar process.

Here is the class. The two functions in question are the overloads of WorkQueueUntilEmpty

```
///
/// Basic functionality around a consumer that acts on message data
///
public abstract class BaseWorker : BaseActor
{
///
/// If set, the identifier of the queue to which data is written after this worker has finished working on it
///
protected string NextQueue;

///
///

I'm not sure if this would work as intended, but what if instead of not returning anything, you'd return nothing?

Think null object pattern: return an object that behaves "neutral" and doesn't do anything except moving along with the flock like any other regular object would do.

// This overload of WorkBatch returns void
WorkBatch(message.Data, workMethod);

What if you make this WorkBatch return an empty IEnumerable instead?

You can then feed it to Message.WithData() and it wouldn't do anything, because it operates on an empty list.

Of course this assumes that an empty IEnumerable is nothing that WorkBatch(message.Data, compositionFunction) would regularly produce or that would cause Message.WithData() to have some functionality that's different from it not being executed.

I guessEnumerable.Empty(); would do the trick of returning the empty IEnumerable.

StackExchange Code Review Q#126852, answer score: 2