SOLID Principle In Laravel with Repository Pattern

If you're going ahead the way you've shown, i suggest you to use a single controller for your quotations and use a Factory design pattern to create your $quotation objects

For example, with a simple factory like this:

//FACTORY CLASSabstract class QuotationFactory{    /** return QuotationInterface */    public static function createQuotation($type)    {        switch($type)        {            CASE "private":                return new PrivateQuotation();            break;            CASE "commercial":                return new CommercialQuotation();            break;            }    }}

you could use the factory from you controllers' methods:

//YOUR CONTROLLER'S METHODpublic function store(Resource $resource){       $inputs = $resource->all();    //delegate objects creation to factory class    $quotation = QuotationFactory::createQuotation( $inputs['type'] );    $this->repo->save($inputs, $quotation);}

This way you are not going to violate the open/closed principle in your controllers, because as you add quotations, you'll only need to modify the method of the factory (adding cases to the switch statement ), and it will return a QuotationFactory object wherever needed.

This will also keep your code DRY and SOLID because you don't have to repeat the if/else statements to create your objects in your controller's methods as you delegate the responsability of the objects' creation to a specific factory class

As correctly pointed ount in the comments below, the Simple factory is going to help you avoiding the Open/Closed Principle in your controllers but be ware that, from a more general point of view, the Simple Factory itself is inherently violating the OCP as it uses a switch case.

Anyway, from what i see of your application, the Simple factory could be a good solution, as your primary concern is to build in many places instances from a variable type. Thus, using the Simple factory you can 'hide' this process of creating objects into the factory and get the instances you need in your controllers. So you are violating the OCP only inside the factory in the switch case, but i think this could be a beareble trade-off

I think this mostly depends on the scope of your application. In the PHP world these days, people are so angry with if/else statements :). However, if that works for your application and seems reasonable in the scope of YOUR context, I think that's fine.

Businesses change and Business changes aren't always easy to plan for. You can only try to make those changes easier when they arise.

That being said, classes are cheap and I think that having separate classes at this point (and in the future) is very reasonable. If the requirements for each type of quotation expand, you'll be in good footing and I don't think you're abstracting so far that you're code will be difficult to understand.

I know it's late, but i hope my comment helps more people searching your issue.

You should follow the following principle:

"If you have a conditional like that you should do it in the low level abstraction not in the high level"

so the design should be:

abstract class Quotation{       abstract public function save(array $data);    public static function createQuotation($type)    {        switch($type)        {            CASE "private":                return new PrivateQuotation();            CASE "commercial":                return new CommercialQuotation();            default:                throw new InvalidTypeException("Invalid type code.");        }    }}

The above refactoring called "Replace conditional/type code with polymorphism".

If there're no new types in the future you should follow "Replace Parameter with explicit methods" refactoring, it would improve the readability.

For more you should read a book called "Refactoring: Improving the Design of Existing Code" by Martin Fowler.