How should I implement this requirement following SOLID?

Question

Assume we had a User class which should hold references for all different kinds of request, let's say at the moment we only have 2 :RequestA and RequestB, both inherit from the base class Request.

Now we are told to create a class representing the new kind of request in our business. We then create a RequestC class that inherits from Request as well (and this cycle can goes on and on).

How should we design the relationship between User and the different kinds of Requests that our system has?

If we directly couple them (please ignore the poor encapsulation):

public class User
{
    public RequestA RequestA;
    public RequestB RequestB;
    public RequestC RequestC;

    // Foo calls methods from RequestA and RequestB
    public void Foo();
    
    // Boo calls methods from RequestC
    public void Boo();
}

Then, to my understanding, we are forever violating the open/close principle as we will be always modifying our User class when new kinds of Request are created.

Another solution I can think of is to create a collection of Request to hold all the requests there, and make downcasts to RequestA and RequestB inside our Foo method and to RequestC inside Boo and follow this in possible new methods and/or new request classes (assuming the downcast is valid, of course).

I have the feeling that the second approach is not correct either and that there could be a proper way to design such relationship.

That being said, how should we design this relationship (between users and the different types of requests) and keep following all the principles of clean code accepted in the community?

Answer 1

Prefer polymorphism to downcasts.

User is violating the Request abstraction by knowing which request it's talking to.

Now that doesn't mean Foo and Boo must use the same Request instance:

public class User
{
    public Request FooRequest;
    public Request BooRequest;

    // Foo calls Request methods on a FooRequest instance
    public void Foo();
    
    // Boo calls Request methods on a BooRequest instance
    public void Boo();
}

What each Request does when it's methods are called can be completely different based on which Request instance is called. That's polymorphism. User doesn't have to know what it's talking to. But it must know Request to know how to talk. User doesn't have to know what it will get.

This means FooRequest and BooRequest will have the same methods that can be called. As defined by Request. But what those methods do once called can be very different (A, B, C, or more). It might seem like User still knows which request it's talking to but it really doesn't. They look the same to User. All it really knows is it's either talking to the 1st Request it was handed or the 2nd. It doesn't know which kind it was handed.

For this to work the Request class must define everything Foo and Boo will call when calling methods on a Request instance. This falls apart if RequestC has new methods that didn't exist before. You can't follow the Open Closed principle if you're adding new methods to the Request interface. Prefer designs that let you instead add new implementations to the existing methods.

If you cant then look into the visitor pattern. It lets you add new methods without breaking old interfaces.

Answer 2

You don’t modify class User when a new Request subclass is created. You modify class User when there is a new business requirement, and that’s when you both can and must modify it.

Is there a reason why the request that seems to be needed has to be implemented as a subclass of RequestB? I’d define an interface for it, so you can call methods of that request based on the interface, and the caller is able to supply anything matching the interface.