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.
Too object-oriented
java;object oriented;teamwork;communication;maintainability