What he's trying to do may have merit if there was a case where you want to preserve the original behavior of FormView, and you want to use ValidatedFormView as a special case in a different context. If that was the case, then yeah, it's fine if you introduce that as a derivative that lives alongside the original (base class).
However, it sounds like this is not the case here. He is trying to rework an existing component. And he uses that approach as some kind of version control within version control.
I don't quite see how he truly gets around potential merging issues with that approach, though.
His alternative derivative classes still need to be registered somehow with the main application, so something that uses and references those forms needs to be changed from:
It wouldn't make much sense to also introduce a ValidatedController.java based on Controller.java just to get around that merge issue. Where does that end? A complete rewrite of the entire application just to introduce a new feature?
Second of all: Let's assume he has it his way, and a new fix or feature extension needs to be slapped on his ValidatedFormView, what would be the name for that? Will class names grow longer and longer? Are we going to have:
FormView
ValidatedFormView
FixedValidatedFormView
AsynchronousFixedValidatedFormView
down the road, sitting there side by side?
I think your team probably needs some serious kind of discussion about establishing a standard for development workflows and integrating new features. Have it in writing, and make sure that everyone follows those rules.
When it comes to dealing with your colleague here, it sounds like he's actually afraid or unable to handle merge conflicts properly. There must be a reason for that which should be addressed. Maybe a lack of training or understanding of the available conflict resolution tools provided by Git.
Maybe your overall workflow causes merge conflict situations too frequently, and he acts out of frustration?
Those issues can be addressed. When a feature branch lives too long and diverges from the mainline branch too much, then make sure to rebase (or merge in mainline) often. At least once a week for example, so Git can do its automatic merge magic more easily, and in case of a merge conflict it's not too overwhelming to deal with in small doses.
If those conflicts happen in shorter periods of time, then try to coordinate work on certain parts of the system better. Make him the sole responsible person for FormView until his feature is ready, and no one else is allowed to touch it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What he's trying to do may have merit if there was a case where you want to preserve the original behavior of
FormView, and you want to useValidatedFormViewas a special case in a different context. If that was the case, then yeah, it's fine if you introduce that as a derivative that lives alongside the original (base class).However, it sounds like this is not the case here. He is trying to rework an existing component. And he uses that approach as some kind of version control within version control.
I don't quite see how he truly gets around potential merging issues with that approach, though.
His alternative derivative classes still need to be registered somehow with the main application, so something that uses and references those forms needs to be changed from:
to
It wouldn't make much sense to also introduce a
ValidatedController.javabased onController.javajust to get around that merge issue. Where does that end? A complete rewrite of the entire application just to introduce a new feature?Second of all: Let's assume he has it his way, and a new fix or feature extension needs to be slapped on his
ValidatedFormView, what would be the name for that? Will class names grow longer and longer? Are we going to have:FormViewValidatedFormViewFixedValidatedFormViewAsynchronousFixedValidatedFormViewdown the road, sitting there side by side?
I think your team probably needs some serious kind of discussion about establishing a standard for development workflows and integrating new features. Have it in writing, and make sure that everyone follows those rules.
When it comes to dealing with your colleague here, it sounds like he's actually afraid or unable to handle merge conflicts properly. There must be a reason for that which should be addressed. Maybe a lack of training or understanding of the available conflict resolution tools provided by Git.
Maybe your overall workflow causes merge conflict situations too frequently, and he acts out of frustration?
Those issues can be addressed. When a feature branch lives too long and diverges from the mainline branch too much, then make sure to rebase (or merge in mainline) often. At least once a week for example, so Git can do its automatic merge magic more easily, and in case of a merge conflict it's not too overwhelming to deal with in small doses.
If those conflicts happen in shorter periods of time, then try to coordinate work on certain parts of the system better. Make him the sole responsible person for
FormViewuntil his feature is ready, and no one else is allowed to touch it.