Stateless service classes and method decomposition

Question

I like implementing service classes as stateless. However, I also like to decompose my logic into more, simple methods or functions. In some scenarios it seems like the two are somewhat against each other. Consider the following two examples.

I have an entity object called House, implemented something like this.

public class House {
  public string Address { get; set; }
  public List<Room> Rooms { get; set; }

  ...

  public IEnumerable<Furniture> GetAllFurnitures() {
    return Rooms.SelectMany(e => e.Furnitures);
  }

  ...
}

1. Stateful implementation

Pros: cleaner code, no parameter hell

Cons: one service per one House, makes Dependency injection harder because of constructor parameter

public class HouseCleaner {

  private readonly House _house;

  public HouseCleaner(House house) {
    _house = house;
  }

  public void Clean() {
    vacuumClean();
    cleanBathroom();
    cleanToilettes();
    cleanKitchen();
    wipeFloor();
  }
}

2. Stateless implementation

Pros: the service instance can be shared, makes Dependency injection easier

Cons: need to pass probably many parameters to all simple methods and functions to share the current state

public class HouseCleaner {

  public void Clean(House house) {
    vacuumClean(house);
    cleanBathroom(house);
    cleanToilettes(house);
    cleanKitchen(house);
    wipeFloor(house);
  }
}

Which one do you feel more appropriate considering that this is a simplified example. In reality there could be several service dependencies, and other parameters too.

Answer 1

There are arguments for both. The choice as it is said "depends". The first approach can be scaled, because you can create many instances of service (i.e. multithreaded service) - but the service must be lightweight. The second approach on the other hand is better suited for "fat" services that take time to instantiate. It is better to share them. As for the cons for it you've mentioned, it can be applied to both variants. But it can be overcome using aggreagates. As Mark Seeman states in his book "Dependency injection in .NET" - you should find or create a more aggregated class that would combine the desired classes, providing a wider meaning.

Answer 2

I don't see this as a question of technical pros and cons. It depends on the lifecycle of a HouseCleaner, what it is semantically, and how it relates semantically to a House.

Suppose you were dealing with a Car and a Wheel. It wouldn't make a lick of sense of re-inject Car into Wheel into each other every time the Car needed to move. The Car simply has four Wheel objects, and each of those Wheel objects is attached to that single Car until otherwise relocated. Conceptually, semantically, it's a long-lived, "permanent" relationship.

Contrast that with a HoneyBee and a Flower. The interaction between those two things is short-lived or transient: scoped down to single interactions.

As far the dependency injection: I don't believe it's "harder" either way. You get to inject the dependency in both cases. They differ primarily in when and how often you need to inject that dependency.

---

^{If your model is clean and you've come to the point of scrupulizing over whether it's OK to keep "state" on the service-side; you mostly just need to weigh the cost of loading state from memory or a database against the cost of sending it over the wire (a much longer and congested wire than there is between the service and the database) -- and then reassembling it and validating it.}

Answer 3

Across the question and answers I see it all hitting around the bullseye - The Visitor Pattern.

DoFactory, with a C# example, says:

Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Wikipedia says:

the visitor design pattern is a way of separating an algorithm from an object structure on which it operates. A practical result of this separation is the ability to add new operations to extant object structures without modifying the structures. It is one way to follow the open/closed principle.

In essence, the visitor allows adding new virtual functions to a family of classes, without modifying the classes.

I generally like SourceMaking.com

• Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

• The classic technique for recovering lost type information.

• Do the right thing based on the type of two objects.

• Double dispatch