Handling Server Responses

I'm not 100% sure this is the right place to post this. It is not about the specific code being written, but more about the design of the code. (Of course any constructive criticism is appreciated)

I have the following interfaces for dealing with talking to a server:

public interface IAction
{
    GatewayResponseHandlerResult Run();
}

public abstract class GatewayResponseHandler
{
    protected GatewayResponseHandlerResult Result = new GatewayResponseHandlerResult();

    private GatewayResponseHandlerResult Handle(GatewayResponse Response)
    {
        //specific handling code omitted
    }
}

The idea is each type of action (ex. Login, Logout) is its own class that implements the IAction interface. The action performs the call to the servers and passes the response to the GatewayResponseHandler.Handle() function which then passes back a GatewayResponseHandlerResult object. The specific IAction object then passes the GatewayResponseHandleResult object back to the caller.

This is the GatewayResponseHandlerResult class:

public class GatewayResponseHandlerResult
{
    public bool Succeeded;
    public bool Failed;
    public bool Errored;
    public object Result { get; set; }

    public void SetAsSuccess()
    {
        Succeeded = true;
        Failed = false;
        Errored = false;
    }

    public void SetAsFailure()
    {
        Succeeded = false;
        Failed = true;
        Errored = false;
    }

    public void SetAsError()
    {
        Succeeded = false;
        Failed = false;
        Errored = true;
    }
}

This is what an Action would look like:

```
public sealed class LoginAction : IAction
{
private string Username;
private string Password;

public LoginAction(string Username, string Password)
{
this.Username = Username;
this.Password = Password;
}

public GatewayResponseHandlerResult Run()
{
try
{
GatewayResponse LoginResponse = GatewayR

Having bool Succeeded, bool Failed and bool Errored as members of the GatewayResponseHandlerResult class is a very bad practice. Not to mention that all of them are public mutable so that any code can invalidate the result state, like setting all of them to true of false.

Use an enum for this, clean and elegant. It also removes the need of separate methods, as the enum can simply be passed in the constructor. The class should also be made immutable as I don't see a need to ever change a result once it's constructed.

I also don't see the Result property of GatewayResponseHandlerResult ever being used. Using only one instance of GatewayResponseHandlerResult and mutating it for each call is not thread safe. Feels like the entire GatewayResponseHandlerResult class can be replaced by the enum mentioned above.

As to Response, the code of the class is not provided but it seems to suffer from poorly named fields like result_code (C# uses CamelCase not snake_case).

Moving on to the actions, accepting IActionArgs arguments where the interface provides no information is no more useful than accepting a simple object. This part needs to be redesigned.

StackExchange Code Review Q#163345, answer score: 5