Question

The single responsibility principle has a big impact on adaptability of code. Provide an explanation supported with detailed examples

Answer 1

Answer:

The Single Responsibility Principle is the key software engineering principle which determines how we should modularise code in object oriented programming.Single Responsibility Principle (SRP) and its importance cannot be overstated. I would even argue that it is a necessary and sufficient condition for good code. In fact, in any code that is badly written, you can always find a class that has more than one responsibility containing a few thousand lines of code is not something that rare to come by and all of us probably have seen or done it.

example:

public class OrderController
{
...

        public ActionResult CreateForm()
        {
                /*
                * View data preparations
                */

                return View();
        }

        [HttpPost]
        public ActionResult Create(OrderCreateRequest request)
        {
                if (!ModelState.IsValid)
                {
                /*
                * View data preparations
                */

                return View();
                }

                using (var context = new DataContext())
                {
                   var order = new Order();
                    // Create order from request
                    context.Orders.Add(order);

                    // Reserve ordered goods
                    …(Huge logic here)...

                   context.SaveChanges();

                   //Send email with order details for customer
                }

                return RedirectToAction("Index");
        }

... (many more methods like Create here)
}

Notice in the snippet of code above how the controller knows too much about “placing an order”, including but not limited to storing the Order object, sendings emails, etc. That is simply too many jobs for a single class. For every little change, the developer needs to change the entire controller’s code. And just in case another Controller also needs to create orders, more often than not, developers will resort to copy-pasting the code. Controllers should only control the overall process, and not actually house every bit of logic of the process.

Let us first extract all business logic from the controller and move it to a OrderService class:

public class OrderService
{
    public void Create(OrderCreateRequest request)
    {
        // all actions for order creating here
    }
}

public class OrderController
{
    public OrderController()
    {
        this.service = new OrderService();
    }
    
    [HttpPost]
    public ActionResult Create(OrderCreateRequest request)
    {
        if (!ModelState.IsValid)
        {
            /*
             * View data preparations
            */

            return View();
        }

        this.service.Create(request);

        return RedirectToAction("Index");
   }

With this done, the controller now only does only what it is intended to do: control the process. It knows only about views, OrderService and OrderRequest classes - the least set of information required for it to do its job, which is managing requests and sending responses.