How to spawn objects?

Good evening everyone!

So, the question which torments me already some time ago, but the answer is never found.
Example, there are two entities: Transport and Wheel. (Transport Wheel)
In between there is the relationship: one-to-many, i.e. one vehicle may have many wheels.

As correct to create a new Wheel?
The idea is that I can generate a new object, the Wheel:
  1. The usual challenges
    $wheel = new Wheel();
    Continue to exhibit all the properties manually
  2. Through the factory as a service, for example, /model/WheelFactory
    $wheel = $wheelFactory->createWheel($someKindOfTransport);
  3. Through the implementation of the method in the class createWheel Transport
    $car = new Transport();
    $wheel = $car->createWheel();

Question - how logical is it to do? Given the fact that in essence the Wheel by default, you need to install the NEK-parameters which depend on the parameters of the parent, i.e. the Transport entity.

The patterns of the Creator of the GRASP of principles, the Transport object is a container for collections of objects Wheel and has the data to initialize them.
Accordingly, the third option is suitable more than ever. Not whether it intersects with any of best practises or other paddhati?
July 8th 19 at 11:43
2 answers
July 8th 19 at 11:45
In this case, you have a wheel must know something about transport, and not Vice versa.
Abstraction should not depend on details. In this case, the transport abstraction.
("Wheel by default, you need to install the NEK-parameters which depend on the parameters of the parent")
So look to the side
new Wheel(TransportInterface $transport);

If the wheels will not depend on transportation and they can build anywhere, then just some kind of factory.

Well, since the transport may be without wheels (boat) and wheels can build anywhere, then there is some Creator that will collect the boat on wheels and jeeps skid
*Abstraction should not depend on details* - as I understand it, it's about interface implementation instead of a specific implementation of Dependency Inversion. From the point of view of design - I agree, right. (Although for me yet with the fog - as I'm mappit related entities, to specify in KACH-ve targetEntity interface?)

If not difficult explain how to do the next case:
An entity can exist independently and be derived from any parent entity (and stored in the collection). In the first case, the default properties must be alone in the second - determined by the parent.
Maybe to make the factory with a pair of methods (`fabric::create()` and `fabric::createFromParentEntity(ParentEntity $parentEntity`)?

Ideally I want to create a single entry point to create a entity to the client code could just call `$newEntity = new Entity();` - joanie4 commented on July 8th 19 at 11:48
: Do not bother you so much with this theory. Make the beginning to work. And how come the problem is still to optimize and expand onto it. All the problems you then will not need to try to make a perfect system. Distribute a couple of interfaces and start with them.
Just think that we need a factory, then try and use it... Let the transport then all those involved.

Tell. There is a certain system. Literally 1 class. Worked nearly a year, brought happiness. And here it was necessary to add some type and just extend. If not for a certain situation in the project and the mechanism of operation of some other related systems, the creation of one simple essence and one activity increased 3 interface, 1 factory, 15 individual children, 1 delegator. (All from class 1) Again - it all depends on the task. In my case that would be no problem "outside" not were, would be stupid to add one method. - Uriel_Tow commented on July 8th 19 at 11:51
thank you, example often is the place to be) There is not so much you need to consider the architecture as not to step on the rake obvious in the design.

I have the same thing in that project is very large, the sawing of the box CRM core entities under fifty. Still the same our new. Try as best you can to think over. Because then it's all to maintain, and not only me, but the team's middle and Junior.
It would have been 5 entities could refactor easily later.

Comrade above, for example, argues that the transport should not lead to the wheel. Partly true, this will lower connectivity. Then there's this idea that, for example, when creating the wheel I need to injecting a couple of services in creation method (e.g. a search for suitable caps). Then the class of transport will know too much about what he needs will increase connectivity. In the end, the principle Creator of the same set of GRASP contrary to the principle of Low coupling. A compromise is needed

Probably do to stay in the factories and in the README.MD to add red text that other ways of generating'm going to take your hands. - joanie4 commented on July 8th 19 at 11:54
July 8th 19 at 11:47
1. Norms.
2. Norms.
3. Bad transport should not create the wheel.

Question - how logical is it to do? Given the fact that in essence the Wheel by default, you need to install the NEK-parameters which depend on the parameters of the parent, i.e. the Transport entity.

First create the wheel (through new or through the factory, as you prefer), and configure the settings that are not dependent on transport:
$wheel = new Wheel();

Then add a wheel for transport:

The Wheel parameters that depend on the Transport, determined in the method Transport::addWheel() or Wheel::setTransport():
public function addWheel(Wheel $wheel)
I agree, thank you. Answer the following speaker developed the idea abstracted from the implementation and using the dependence on the interface. Question mark there in the comments - joanie4 commented on July 8th 19 at 11:50

Find more questions by tags PHPDoctrine ORMOOPSymfony