What is SOLID Principles?

A class should take one responsibility and there should be one reason to change that class. 

Now what does that mean? 

Now see this tool is a combination of so many different tools like knife, nail cutter, screw driver, etc. So will you want to buy this tool? I don’t think so. Because there is a problem with this tool, if you want to add any other tool to it, then you need to change the base and that is not good. This is a bad architecture to introduce into any system. It will be better if nail cutter can only be used to cut the nail or knife can only be used to cut vegetables.

public class ReportGeneration
{
     ///

     /// Method to generate report
     ///

     ///
     public void GenerateReport(Employee em)
     {
         // Report reneration with employee data.
     }
}

public class ReportGeneration
{
    ///

    /// Report type
    ///

    public string ReportType { get; set; }

    ///

    /// Method to generate report
    ///

    ///
    public void GenerateReport(Employee em)
    {
        if (ReportType == “CRS”)
        {
             // Report generation with employee data in Crystal Report.
        }
        if (ReportType == “PDF”)
        {
            // Report generation with employee data in PDF.
        }
     }
 }

public class IReportGeneration
    {
        ///

        /// Method to generate report
        ///

        ///
        public virtual void GenerateReport(Employee em)
        {
            // From base
        }
    }
    ///

    /// Class to generate Crystal report
    ///

    public class CrystalReportGeneraion : IReportGeneration
    {
        public override void GenerateReport(Employee em)
        {
            // Generate crystal report.
        }
    }
    ///

    /// Class to generate PDF report
    ///

    public class PDFReportGeneraion : IReportGeneration
    {
        public override void GenerateReport(Employee em)
        {
            // Generate PDF report.
        }
    }

So if you want to introduce a new report type, then just inherit from IReportGeneration. So IReportGeneration is open for extension but closed for modification.

public abstract class Employee
{
    public virtual string GetProjectDetails(int employeeId)
    {
        return “Base Project”;
    }
    public virtual string GetEmployeeDetails(int employeeId)
    {
        return “Base Employee”;
    }
}
public class CasualEmployee : Employee
{
    public override string GetProjectDetails(int employeeId)
    {
        return “Child Project”;
    }
    // May be for contractual employee we do not need to store the details into database.
    public override string GetEmployeeDetails(int employeeId)
    {
        return “Child Employee”;
    }
}
public class ContractualEmployee : Employee
{
    public override string GetProjectDetails(int employeeId)
    {
        return “Child Project”;
    }
    // May be for contractual employee we do not need to store the details into database.
    public override string GetEmployeeDetails(int employeeId)
    {
        throw new NotImplementedException();
    }
}

List employeeList = new List();
employeeList.Add(new ContractualEmployee());
employeeList.Add(new CasualEmployee());
foreach (Employee e in employeeList)
{
    e.GetEmployeeDetails(1245);
}

public interface IEmployee
{
    string GetEmployeeDetails(int employeeId);
}

public interface IProject
{
    string GetProjectDetails(int employeeId);
}

Now, contractual employee will implement IEmployee not IProject. This will maintain this principle.

public interface IEmployee
{
    bool AddEmployeeDetails();
}

public interface IEmployeeDatabase
{
    bool AddEmployeeDetails();
    bool ShowEmployeeDetails(int employeeId);
}

public interface IAddOperation
{
    bool AddEmployeeDetails();
}
public interface IGetOperation
{
    bool ShowEmployeeDetails(int employeeId);
}

And non-permanent employee will implement only IAddOperation and permanent employee will implement both the interface.

This principle tells you not to write any tightly coupled code because that is a nightmare to maintain when the application is growing bigger and bigger. If a class depends on another class, then we need to change one class if something changes in that dependent class. We should always try to write loosely coupled class.

public class Email
{
    public void SendEmail()
    {
        // code to send mail
    }
}

public class Notification
{
    private Email _email;
    public Notification()
    {
        _email = new Email();
    }

    public void PromotionalNotification()
    {
        _email.SendEmail();
    }
}

public interface IMessenger
{
    void SendMessage();
}
public class Email : IMessenger
{
    public void SendMessage()
    {
        // code to send email
    }
}

public class SMS : IMessenger
{
    public void SendMessage()
    {
        // code to send SMS
    }
}
public class Notification
{
    private IMessenger _iMessenger;
    public Notification()
    {
        _ iMessenger = new Email();
    }
    public void DoNotify()
    {
        _ iMessenger.SendMessage();
    }
}

Still Notification class depends on Email class. Now, we can use dependency injection so that we can make it loosely coupled. There are 3 types to DI, Constructor injection, Property injection and method injection.

public class Notification

}