Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Declare getNewInstance as final in favor of alterNewInstance #6850

Merged
merged 1 commit into from
Feb 13, 2021

Conversation

VincentLanglet
Copy link
Member

Subject

I am targeting this branch, because BC.

There is an alterNewInstance for extensions, but not for the AbstractAdmin.
I think we should provide one instead of allowing to override getNewInstance.

Changelog

### Added
- Added `AbstractAdmin::alterNewInstance()`

### Deprecated
- Overriding `AbstractAdmin::getNewInstance()`

phansys
phansys previously approved these changes Feb 12, 2021
@VincentLanglet VincentLanglet requested a review from a team February 12, 2021 20:34
UPGRADE-3.x.md Outdated Show resolved Hide resolved
@phansys phansys requested a review from a team February 12, 2021 22:45
@OskarStark OskarStark merged commit a78f7ed into sonata-project:3.x Feb 13, 2021
@franmomu
Copy link
Member

IMHO getNewInstance should not be final, if someone uses a factory, a service or just has some mandatory parameters, should be able to override it.

@VincentLanglet
Copy link
Member Author

VincentLanglet commented Feb 16, 2021

IMHO getNewInstance should not be final, if someone uses a factory, a service or just has some mandatory parameters, should be able to override it.

He should override ModelManager::getModelInstance() then.

When the AbstractAdmin is calling an external service the best practice is to override the service and not the AbstractAdmin method. We promote this best practice by declaring the AbstractAdmin method as final.

@VincentLanglet VincentLanglet deleted the alterNewInstance branch February 16, 2021 12:06
@franmomu
Copy link
Member

Well, in this specific case, we are not promoting best practices with ModelManager::getModelInstance() since we "force" the user to create their objects empty (not usable with mandatory parameters in the constructor), but that's another story.

I was thinking that maybe there is no need for ModelManager::getModelInstance() since creating the object it's not really related to the persistence layer and the code of both persistence bundles is the same.

@VincentLanglet
Copy link
Member Author

Since our getNewInstance has some logic, I don't like the fact we're allowing to override it.

If you're doing

public function getNewInstance() {
   $object = $this->factory->create();
   
   return $object;
}

You'll losing the extension feature, the appendParentObject call and can have some bug.
I don't like the fact you have to know all the logic inside the method and copy it

public function getNewInstance() {
   $object = $this->factory->create();

   $this->appendParentObject($object);
   $this->alterNewInstance($object);

   foreach ($this->getExtensions() as $extension) {
       $extension->alterNewInstance($this, $object);
   }
   
   return $object;
}

Let's say one day we modify the getNewInstance to add/remove some code, in order to add a feature or remove a bug. You won't benefit of the feature/bugfix. It could even lead to a buggy behavior in your project.

What do you think about providing a protected createNewInstance method ?
We could add the logic of ModelManager::getModelInstance and deprecate the method in the persistence bundle.

@franmomu
Copy link
Member

Yeah, I meant if there was no need of ModelManager::getModelInstance, something else should replace it, I'll see if I can do it at the weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants