Software Architecture Cheat Blog 2: Single Responsibility Principle

Define Principle

Single Responsibility Principle (SRP) states that there should never be more than one reason for class to change.

Violation Example

Let's consider this sample class Customer.

public class Customer
    {
        public String Name { get; set; }
        public String Address1 { get; set; }
        public String City { get; set; }
        public String State { get; set; }
        public String Zip { get; set; }
        public String Email { get; set; }

        //Responsibility # 1 : save customer information
        public bool SaveCustomer()
        {
            if (ValidateCustomer())
            {
                //Save customer data
                SendWelcomeEmail();
            }

            return true;
        }

        //Responsibility # 2 : send email
        private void SendWelcomeEmail()
        {
            //send welcome email to customer
        }

        //Responsibility # 3 : validate customer data
        private bool ValidateCustomer()
        {
            //Check if the email is already registered

            return true;
        }
    }

While SRP principle states no class should contain more than one responsibility, Customer class itself carries three responsibilities, save data/validate data/email. If further we want to add additional validation rule, or need to update email function to facilitate admin email, we have to change the Customer class, thus violates SRP.

Resolution

To solve this, we have to break down each class respect to responsibility.

    public interface ICustomerInfo
    {
        String Name { get; set; }
        String Email { get; set; }
    }

    public class Customer: ICustomerInfo
    {
        public String Address1 { get; set; }
        public String City { get; set; }
        public String State { get; set; }
        public String Zip { get; set; }
        public String Name { get; set; }
        public String Email { get; set; }        
    }

    public class Emailer
    {
        public void SendWelcomeEmail(ICustomerInfo customerInfo)
        {
            //send welcome email to customer
        }
    }

    public class CustomValidator
    {
        public bool ValidateCustomer(ICustomerInfo customerInfo)
        {
            //Check if the email is already registered
            return true;
        }
    }

    public class CustomerManager
    {
        ICustomerInfo _custInfo;
        public void SaveCustomer()
        {
            _custInfo = new Customer();
            if (new CustomValidator().ValidateCustomer(_custInfo))
            {
                new Emailer().SendWelcomeEmail(_custInfo);
            }
        }        
    }

This makes ICustomerInfo independent of the Customer class which makes it easier to maintain and extend. Emailer and Validation now handles single responsibility and does not depend on the entire customer object. Further, we can modify validation rules, emailer logic as needed without effecting core Customer class.

CodeProject