Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 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.

You see a coding style you don't like and you lost your temper? It sounds like the problem is with you. – Jesse Millikan Feb 17 '11 at 19:18
In my experience, OOP only yields some good result in small problem domains that can be well understood up front. At project/application level, the abstraction put in place by an earlier understanding quickly becomes the biggest obstacle for future development. I am not saying procedure code will do better in this scenario. I just want to say take it easy and don't assume OOP is the best. – Codism Apr 13 '11 at 17:55
Did you just say that OOP doesn't "scale" well? – Erik Reppen Jun 6 '12 at 12:47

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.

+1 for"not OO doesn't mean poorly designed" :) OO is not a silver bullet... especially in the mainstream languages... – Matthieu M. Apr 13 '11 at 17:43
When you say mainstream, I tend to think Java and C#. Writing in an either/or language, I'm in the "not everything has to be OOP" camp but when it's offered as a tool in a language that allows both, it's pretty hard to excuse not doing it properly or not using it at all, IMO. – Erik Reppen Jun 6 '12 at 13:14

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.


Not the answer you're looking for? Browse other questions tagged or ask your own question.