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

Make all methods protected, not private #72

Open
manticorp opened this issue Jul 24, 2018 · 4 comments
Open

Make all methods protected, not private #72

manticorp opened this issue Jul 24, 2018 · 4 comments

Comments

@manticorp
Copy link

Hi there,

I've been using your deployer for a while now and its fantastic - but it would be great to make all of the methods in the DefaultDeployer protected instead of private - that way we can easily override them if we need to.

For example, I was having trouble with the doResetOpCache function.

Inserting a 1 second sleep between writing the file and wgetting the file has solved this problem, but I cannot override the class method!

Thanks!

@daFish
Copy link
Contributor

daFish commented Jul 24, 2018

You can implement your own deployer class by extending EasyCorp\Bundle\EasyDeployBundle\Deployer\AbstractDeployer. This way you have complete control over each method you need to customize.

@manticorp
Copy link
Author

While that's true, if I only want to change one method from the DefaultDeployer, then why rewrite the whole class?

What's the reason for wanting to keep the methods private?

The DefaultDeployer has a load of useful methods and it would be great to keep them.

@daFish
Copy link
Contributor

daFish commented Jul 25, 2018

The reason is the "open-closed-principle" which states that classes should be open for extension but closed for modification.

To make this happen more extension points are needed. Unless they are provided, you have limited options:

  • implement your own deployer class
  • fork this repo, modify it to your use, and you it
    Opting for the latter would also mean more maintenance at your side.

@maxkain
Copy link

maxkain commented May 30, 2022

The reason is the "open-closed-principle" which states that classes should be open for extension but closed for modification.

To make this happen more extension points are needed. Unless they are provided, you have limited options:

* implement your own deployer class

* fork this repo, modify it to your use, and you it
  Opting for the latter would also mean more maintenance at your side.

The extension point is protected method. The original class is not modifying. The principle is not violated.
Anyway, the application developer may decide how to do it by himself and the private method limits him. The bundle should give developer possibilities, but it should not dictate him how to write his code.

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

No branches or pull requests

3 participants