Why is the logic for creating objects taken out separately from the Repository pattern?

Question

Problem-Based Design

I saw it many times in Laravel projects, in the application - they create a separate class that is responsible for creating objects and take it out separately. Why do they do this and not leave it in the repository class?

Answer 1

I think the principle of one responsibility comes into play here. Well, plus the factory pattern.
The repository class should be responsible for one task, I suppose these are actions on the repository. If he needs to get some object, he without hesitation takes the necessary factory and receives the object and then works with the object. The repository class does not need to know how an object is created and what is needed for this. He should only know that from such a factory you can get a class of objects that implement an interface or inherit a certain class. But already the factory should have an algorithm for creating an object.
This approach reduces cohesion and increases flexibility. If you need to change the code for creating objects, then only the factory class is edited and tested. All clients of this factory need only know that they are guaranteed to receive an object with a specific interface.