CODEWITHSUNDEEP
design-patternsarchitecture
John Gallagher
John Gallagher

Reputation: 6268

What should I call objects that coordinate different combinations of behaviours?

Background

I often have classes with single responsibilities:

but I need to perform a higher level task by coordinating between them. What should these objects be called?

Example 1 - Generating then Sending a Report

Example 2 - Generating then Sending a Report

My Crappy Solution

My Question

What should I call objects that coordinate different combinations of behaviours?

Is there a design pattern that can help me out here?

Upvotes: 3

Views: 80

Answers (4)

Massimiliano
Massimiliano

Reputation: 16990

Don't get stuck with the class names, it's not your only way to make a clean design. Make use of method names, method overloads, method argument types, method argument names, constructor overloads, constructor argument types and so on. Lots of tools in the language to help the user of your classes.

For example, since you're talking about some simple functions that would just combine existing classes you can make them static methods on a helper class (you can even make them extension methods for the Report class if you like):

public static class ReportHelper
{
    public static void SaveToFile(Report report, string path) {};
    public static void Send(Report report, string address) {};
}

If you'd like to go a bit more abstract and support more complicated behaviors, then the right name for the object encapsulating the behaviors would be a Workflow. 

public interface IReportAction 
{
    void Execute(Report report);
}

public class ReportWorkflow : IReportAction
{ 
    //Composite pattern to keep a list of actions and execute them one by one
}

public class SendReportAction : IReportAction {}
public class WriteReportAction : IReportAction {}

Having your workflow class you can create several instances of it and give them some business-oriented names. For example, what is the role of the workflow where you send the report? Maybe it is an EndOfDayReportWorkflow, so call it like this, inside it can format report, do something else to it and then send. You avoid bad names and you will code in high-level business terms.

Upvotes: 3

Gabriel Belingueres
Gabriel Belingueres

Reputation: 2985

This is a pure class naming issue. You have many little, single responsibility classes and want to abstract out a class that do something more useful, something you can use out of the box. I would name it a ReportUtil class. It could even have only static public methods.

Upvotes: 1

Aleksandr Dubinsky
Aleksandr Dubinsky

Reputation: 23515

ReportSendCoordinator and ReportSaveCoordinator (and assume that generating the report is part of sending/saving it. Eg, if I were to write a TODO to myself, I'd write Send Report to Susan, with the fact that most of the work is actually writing it being implied). Or if there are specific goals/uses for these reports, name them after those. Eg, TPSReportService will use ReportGenerator and ReportDumper.

Upvotes: 1

Yuriy Zubarev
Yuriy Zubarev

Reputation: 2871

ReportService would be most used name in the wild. The second place would go to ReportAgent. ReportWorker and ReportController would not be uncommon either.

It's not a pattern as much as naming convention within your organization.

Thus said, some suffixes usually carry a meaning as well. For example:

  • *Worker - multithreaded environment
  • *Controller - MVC environment
  • *Agent - queue listener
  • *Service - general aggregate of behavior

Upvotes: 1

Related Questions