"Too object-oriented"

Question

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.

Answer 1

You didn't complain about it being unmaintainable, just not to your liking. If it's a deliberate style choice, it may just be a case of irreconcilable creative differences, and you should adjust your style to fit, or find somewhere that fits your preferred style.

People can and do write modular, efficient, well-abstracted, relatively bug-free code in a procedural style all the time. Java is an odd choice of language for such a shop, but I can see it happening if external factors decided the language, like needing to develop for Android, for example.

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. — Albert Einstein

If it was a deliberate choice, you can't really judge them by how well they adhere to good object-oriented design principles, you should judge by how well they adhere to good procedural design principles, and also refactor accordingly. Java doesn't let you write code outside a class, so the mere presence of one doesn't mean they intended a module to be object-oriented.

On the other hand, if the code is a mess in either paradigm, you should probably just cut your losses.

Answer 2

Reading your question, I remembered one tip of book Pragmatic Programmer.

One of its tips is Be a Catalyst for Change:

You may be in a situation where you know exactly what needs doing and how to do it. The entire system just appears before your eyes—you know it's right. But ask permission to tackle the whole thing and you'll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called "start-up fatigue."

It's time to cook Stone Soup. Work out what you can reasonably ask for. Develop it well. Once you've got it, show people, and let them marvel. Then say "of course, it would be better if we added…." Pretend it's not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.

So, I think If you start to do a good job with your OO and TDD knowledge, soon they'll start to look and ask about your job.

Answer 3

To sell new ways to work, you need to show obvious benefits. Writing more layers of abstraction, without a clear benefit but a vague: "it can be beneficial for the future" won't work.

Make factories where the factories make more then one type of object. Use dependency injection, where it immediately shows benefits. Make interfaces that are actually going to be implemented by more then one class.

What I see too often in "true OO" is that advanced techniques are used to solve really simple problems in an overly complex way.

How can you show the benefit of a factory if it is only ever going to make the same object? Find a problem in your code that benefits from advanced techniques and shows your point and work from there.

Wars are won one battle at a time.

Answer 4

You can only convince them by taking on a small chunk of code and implementing TDD and better OO practices on it to realize the benefits. You have lead them to the promised land, not just show nice post cards of it.

Certainly, I think there are cases of over abstraction in use in many code bases today. Only put in what you need, and that includes abstractions as well.