I'm working on a project which heavily uses OOP Design principles. But, one of my colleague tends to do everything in procedure oriented manner. I gets irritated by seeing procedure oriented code wrapped in a class and lose my temper. But, losing temper won't make anything better. I need some ideas, advices and tips on how to make people think in terms of objects.
migration rejected from stackoverflow.com Dec 16 '13 at 1:58
This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.
closed as too broad by gnat, GlenH7, MichaelT, Bart van Ingen Schenau, Dynamic Dec 16 '13 at 1:58
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.
Not that I think everyone else is necessarily wrong, but having been "that guy" before, I'll play devils advocate for a moment.
You should talk to him and find out the rationale for why he's writing code the way he is. It may be that he doesn't know how, or doesn't want to use sound OO principles. On the other hand, maybe he's re-using existing code and packaging it in an OO wrapper to fit in with the design of the project, or else trying to avoid over-engineering.
Is the code that he's writing part of the main application, or is it a library that's going to be used? If it's the latter maybe he doesn't feel as constrained by the design principles of the core application's codebase and didn't figure that anyone would mind.
Consistency is important, so I'm not saying that you shouldn't address his style, but keep in mind that (regardless of how strongly most people on programmers/SO would disagree with me) just because code isn't OO doesn't mean that it's poorly designed; likewise just making him use objects won't magically make the code better. Understand why he made the decisions he made and try to come to an understanding from there.
Feelings are based on assumptions. In your case probably "procedural code is bad, because XYZ".
What is XYZ for you? Explain your reasoning to him.