Messages with status codes

If status code of a message does not change during the lifecycle of Message instance, you probably can do a Replace Conditional with Polymorphism refactoring. Thus you will get an hierarchy of classes that exposes common fields. The consumers of Message class will be working with a base class, unaware of exact implementation. Exact message classes could be created via Factory Method in a base class. This approach lets you give your message classes meaningful names which would be appreciated by the future developers as they will not have to guess what that mysterious 112 status code means. Please see example below:

public abstract class MessageBase
{
    public Guid ID { get; set; }
    public string MessageIn { get; set; }
    public string MessageOut { get; set; }
    public int StatusCode { get; set; }

    public static MessageBase CreateMessage(int statusCode)
    {
        switch (statusCode)
        {
            case 12:
            case 13:
            case 22:
            case 120:
                return new MessageA();
            default:
                return new MessageB();     
        }
    }

    public virtual bool IsDeletable
    {
        get { return false; }
    }

    public virtual bool IsEditable
    {
        get { return false; }
    }

    public virtual string Message
    {
        get
        {
            return string.Empty;
        }
    }
}

public class MessageA : MessageBase
{
    public override bool IsDeletable
    {
        get { return true; }
    }

    public override bool IsEditable
    {
        get { return true; }
    }

    public override string Message
    {
        get { return MessageOut; }
    }
}

public class MessageB : MessageBase
{
    public override bool IsDeletable
    {
        get { return true; }
    }

   public override string Message
    {
        get { return MessageIn; }
    }
}

To adhere to the Open/Closed Principle for this class, you can either:

1. Change StatusCode to a class with bool IsEditable, bool IsDeletable, and bool?UsesOutMessage gettable only properties, generating the instances via a factory class, OR
2. Pass Func<bool, StatusCode> IsEditable, Func<bool, StatusCode> IsDeletable, and Func<bool?, StatusCode> UsesOutMessage functions into StatusCode's constructor.

I don't see any other SOLID principles being broken in your original code, but it can be hard to tell out of context.

EDIT

If you went with option 1, StatusCode would be a class:

class StatusCode
{
    private bool isDeletable;
    private bool isEditable;
    private bool? usesOutMessage;

    public StatusCode(bool isDeletable, bool isEditable, bool? usesOutMessage)
    {
        IsDeletable = isDeletable;
        IsEditable = isEditable;
        UsesOutMessage = usesOutMessage;
    }

    public bool IsDeletable
    {
        get { return isDeletable; }
        set { isDeletable = value; }
    }

    public bool IsEditable
    {
        get { return isEditable; }
        set { isEditable = value; }
    }

    public bool? UsesOutMessage
    {
        get { return usesOutMessage; }
        set { usesOutMessage = value; }
    }
}

Your code above would become:

public class Message
{
    public Guid ID { get; set; }
    public string MessageIn { get; set; }
    public string MessageOut { get; set; }
    public StatusCode StatusCode { get; set; } //EDIT could be changed during message lifecycle

    public bool IsDeletable
    {
        get
        {
            return this.StatusCode.IsDeletable;
        }
    }

    public bool IsEditable
    {
        get
        {
            return this.StatusCode.IsEditable;
        }
    }

    public string Message
    {
        get
        {

            if (this.StatusCode.UsesOutMessage.HasValue)
            {
                if (this.StatusCode.UsesOutMessage.Value)
                {
                    return this.MessageOut;
                }
                else
                {
                    return this.MessageIn;
                }
            }
            else
            {
                    return string.Empty;
            }
        }
    }
}

The factory class would still need to do something like:

StatusCode redAlert = new StatusCode(false, true, null);
StatusCode amberAlert = new StatusCode(false, false, true);
StatusCode chartreuseAlert = new StatusCode(true, true, false);

It looks like this is just moving the logic out of MessageBase into a factory, but this adheres to the Open/Closed principle for MessageBase. MessageBase and its unit test now no longer need to be modified when new status codes are added, removed, or modified. It just works now matter how the status codes change.

This approach also keeps the logic in one place: the factory. Everything that needs to be known about status codes can be found in the factory rather than spread across multiple classes which use status codes.

When ever you encounter multiple conditions that you see growing, that should be a clear indication that a strategy pattern could help. You start by doing the following.

Create a simple enum for your status codes.

public enum MessageStatusCodes{
 case12= 12,
        case13= 13,
        case22 = 22,
        case120 = 120
}

Create your interface that will instruct your concrete strategy classes how to handle your messages

public interface IMessageStrategy{
void Process(Message);

}

Here your Message class will become your context object.

public class Message
{
public Guid ID { get; private set; }
public string MessageIn { get; private set; }
public string MessageOut { get; private set; }
public MessageStatusCodes StatusCode { get; set; } //EDIT could be changed during message lifecycle
public Message(Guid id, string messageIn, string messageOut, MessageStatusCodes statusCode){
ID=id;
MessageIn=messageIn;
MessageOut=messageOut;
StatusCode = statusCode;
LoadStrategies();
}

private static Dictionary<MessageStatusCodes, IMessageStrategy> messageStrategies;
private void LoadStrategies()
{
    messageStrategies = new Dictionary<MessageStatusCodes,IMessageStrategy>();
    messageStrategies.Add(MessageStatusCodes.case12, new DeleteMessageStrategy() );

}

 public void Process()
{     
        return messageStrategies[StatusCode].Process(this);
}
}

Then you start by creating your concrete classes that implement the different actions or strategies that you want to perform for each condition. For example, the Delete message action could be a strategy.

public class DeleteMessageStrategy : IMessageStrategy {

public void Process(Message){
//do something based on delete status code
}
}

Then you call your Message like so

Message message = new Message(....);
message.Process();

And then your code will process the message with respect to the status code passed in.

When you're ready to expand, you implement new strategies and add those new strategies to your Message class so its aware of them.

You can really expand on this template I have shown here. Take a look at my post, I did something very similar and had questions and came to codereview for answers

My Code Review Question