I come from a strong OO background, and I have recently started working in an organization which, although the code is written in Java, has a lot less emphasis on good OO design than what I am used to. I have been told that I introduce "too much abstraction", and that I should instead code the way it has always been done, which is a procedural style in Java.
TDD is also not very much practiced here, but I want to have testable code. Burying business logic in static private methods in large "God-classes" (which seems to be the norm for this team) is not very testable.
I struggle in clearly communicating my motivation to my co-workers. Does anyone have some advice on how I can convince my coworkers that using OO and TDD leads to more easily maintained code?
This question about technical debt is related to my question. However, I am trying to avoid incurring the debt in the first place, as opposed to paying it down after the fact which is what the other question covers.