0

Lets imagine some vendor code that we want to extend on our project level

protected function getDefaultFormClasses() {
    return [
        new FormClassA(),
        new FormClassB(),
        new FormClassC(),
        ...
        new FormClassZ()
    ]
}

On project level we want exactly what this function will return as our form classes collection, except of one, it should not be in our default form collection.

Lets say FormClassK() should be absent, and we want to add another one, lets say FormClassNew()

There are two possibilities known to me to solve this:

  1. Override the parent class, list everything again except the one you don't want and also add the new one

  2. Call the parent method and remove the one you don't want and add the new one

Regarding the first: Seems a lot of code duplication, so ... don't do it? -> DRY?

Regarding the second: Thinking of further code extensions (for example based on my project implementation) it would be really confusing, when every child does adding and subtracting to their parents collection to get the final result ... Also: Somebody who reads the code might have a hard time to aggregate the final collection in his mind, at least if he do not debug it.

This is just a simple example but i encountered this type of extension really often and also get very different philosophies here ...

But I am interested in facts not in preferences.

So what are the pros/cons using one method over the other? Are there even principles that gets violated here?

Is there a thumb rule or even a best practise when a complete rewrite of the parents method makes more sense than extending and "bend" it to the actual requirements?

Other suggestions are also welcome.

1
  • 2
    Let's says the vendor adds more new forms to the list returned by "getDefaultFormClasses" in the next version of the framework. Do you (1) want to get these new forms automatically, or do you (2) first want to check which new forms are available and pick them explicitly? Both (1) and (2) can be sensible, depending on the case. So no, there is no braindead "principle" which can unburden you from making deliberate design decisions.
    – Doc Brown
    Jun 3, 2021 at 7:52

1 Answer 1

3

If you work with vendor code, you don't RY because it wasn't you who wrote the original code :-) So don't make your life harder than it needs to be.

Regarding the subtractive extension vs. keeping a modified version: both variants are possible, and as the vendor apparently didn't provide a preferred method of doing this in customer-specific extensions, it's yours to decide. Whatever you choose, as soon as the vendor ships a new version of their code and you want to migrate, you'll need to check whether your extension is still valid anyway.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.