How/should I introduce a new pattern into my codebase [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

I have recently discovered the Builder pattern and the Step Builder pattern which are essentially just like object initialisers but with the Step Builder pattern you can add mandatory fields.

We have classes which have lots of constructors which have tons of parameters and each constructor is just a variation on what parameters are used so there is a lot of duplication and difficulty finding out which constructor is the right one to use. This gives us flexibility in creating our immutable object from lots of different places so I am not wanting to lose that. I believe that the step builder helps this because you can mandate particular fields and allow the flexibility that an object initializer gives.

However the team I am working in are not familiar with the builder pattern and cannot see its benefits. I don't really want to continue refectoring the code base just to be told its too complicated (because they can't see instantly how to us it) and I have to remove it, meaning that I have to spend another week or so working on it.

So my question is: How do you introduce a new pattern into an existing project while working in a team? Or even should I?

I know there are questions out there asking about how to introduce a new pattern in code but I specifically want to know how it affects a team and what I need to do to gain their buy in.

It might be worth noting that I am not a senior developer, if anything I am close to being a junior developer in terms of experience to the rest of my team.

Answer 1

If you are getting major push back from the rest of your team, you should probably stop writing/refactoring things into that pattern, and use/leave the prevailing style instead, at least until you can find a persuasive argument in favor.

In your issue tracking system, do you have a body of fixed bugs where the problem was in the area of confusion over multiple constructors? If there is, you can point to that. If there isn't, then there may well be no problem with the status-quo.

Learning to pick your battles is important in teamwork.