Is it possible to over OO?

My question is simple; is it possible to over object-orient your code?

How much is too much? At what point are you giving up readability and maintainability for the sake of OO?

I am a huge OO person but sometimes I wonder if I am over-complicating my code....

Thoughts?

From stackoverflow Mike Fielden

• is it possible to over object-orient your code

  Yes

  Simucal : I love that this was the accepted answer.
  From viggity

• If you find that the time needed to fully implement OO in your project is needlessly causing missed deadlines, then yes.

  There has to be a trade off between releasing software and full OO fidelity. How to decide depends on the person, the team, the project and the organization running the project.

  From Peter Ritchie

• Yes, of course there is :-) object oriented techniques are a tool ... if you use the wrong tool for a given job, you will be over complicating things (think spoon when all you need is a knife).

  To me, I judge "how much" by the size and scope of the project. If it is a small project, sometimes it does add too much complexity. If the project is large, you will still be taking on this complexity, but it will pay for itself in ease of maintainability, extensibility, etc.

  Brian Warshaw : Better yet, think knife when you need a spoon :-)

  Unkwntech : or even better yet, a butcher knife when you are trying to spread butter.

  gbjbaanb : isn't it ironic when you're trying to reduce complexity using objects you end up making things more complex. I think that lyric was cut from the album :)
  From Joel Martinez

• Yes, it's definitely possible -- common, either. I once worked with a guy who created a data structure to bind to a dropdown list -- so he could allow users to select a gender. True, that would be useful if the list of possible genders were to change, but they haven't as yet (we don't live in California)

  From Danimal

• My advice is not to overthink it. That usually results in over or under doing SOMETHING (if not OO). The rule of thumb that I usually use is this: if it makes the problem easier to wrap my head around, I use an object. If another paradigm makes it easier to wrap my head around than it would be if I used an object, I use that.

  That strategy has yet to fail me.

  From Jason Baker

• I guess it is possible, but its hard to answer your in abstract terms (no pun intended). Give an example of over OO.

  From Dan

• Yes. See the concept of the "golden hammer antipattern"

  From Anthony

• I think there are times when OO design can be taken to an extreme and even in very large projects make the code less readable and maintainable. For instance, there can be use in a footware base class, and child classes of sneaker, dress shoe, etc. But I have read/reviewed people's code where it seemed as though they were going to the extreme of creating classes beneath that for NikeSneakers and ReebokSneakers. Certainly there are differences between the two, but to have readable, maintainable code, I believe its important, at times, to expand a class to adapt to differences rather than creating new child classes to handle the differences.

  From Timothy Carter

• If you think more objects is more object-oriented then yes.

  When doing object oriented design there are a couple of forces you have to balance. Most of OO design is about reducing and handling complexity. So if you get very complex solutions you're not doing too much OO but you're doing it wrong.

  From Mendelt

• Yes, just as one can over-normalize a database design.

  This seems to be one of those purist vs. pragmatic debates that will never end. <:S

  From Stu Thompson

• A lot of people try to design their code for maximum flexibility an reuse without considering how likely that will be. Instead, break your classes up based on the program you're writing. If you will have exactly one instance of a particular object, you might consider merging it into the containing object.

  From Kyle Cronin

• Yes, and it's easy. Code is not better simply because it's object-oriented, any more than it's better simply because it's modular or functional or generic or generative or dataflow-based or aspect-oriented or anything else.

  Good code is good code because it's well-designed in its programming paradigm.

  Good design requires care.

  Being careful takes time.

  An example for your case: I've seen horrific pieces of Java in which, in the name of being "object oriented", every class implements some interface, even when no other class will ever implement that interface. Sometimes it's a hack, but in others it really is gratuitous.

  In whatever paradigm or idiom you write code, going too far, partaking of too much of a good thing, can make the code more complicated than the problem. Some people will say, when that point is reached, that the code isn't even really, for example, object-oriented anymore.

  Object-oriented code is supposed to be better organized for the purpose of being simpler, more straight-forward, or easier to understand and digest in reasonably independent portions. Using the mechanisms of object oriented coding antithetically to this goal does not result in object oriented design .

  From Thomas Kammeyer

• Yes! Look out for Pseudo Classes and Quasi-Classes

  I recommend idinews.com articles

  From epatel

• I think the clear answer is yes, but depending on the domain you are referring to, it could be REALLY yes, or less so yes. If you are building high level .Net or Java apps, then I think this is the latter, as OO is basically built into the language. On the other hand if you are working on embedded apps, then the dangers and likelihood that your are over OO'ing are high. There is nothing worse than seeing a really high level person come onto a embedded project and over complicate things that they think are ugly, but are the most simple and fast ways to do things.

  From $pageUsers[$post.author].name

• I think your question should read, "Can you over Architecture your application?"

  And of course the answer is yet. OO is just an approach to design. If you spend your time building unnecessary complexity into a system because "Polymorphism Rocks!". Then yes maybe you're over OOing.

  The very XP answer is that Regardless of what approach you favor (OO, procedural, etc.) the design should only be as complex as is demonstrably necessary.

  From Allain Lalonde

• Yes, you can. As an example, if you find yourself creating Interfaces or abstract classes before you have two subtypes for them, then you're over-doing it. I see this kind of thinking often when developers (over)design up front. I use Test-Driven Development and Refactoring techniques to avoid this behavior.

  From Bill the Lizard

• is it possible to over object-orient your code?

  No. But it is possible to over complicate your code. For example, you can use design patterns for the sake of using design patterns. But you cannot over object-orient your code. Your code is either object-oriented or it is not. Just as your code is either well designed or it is not.

  dsimcha : In a multi-paradigm language, where the exact definition of OO code is blurred, what if some subproblems are better solved procedurally and others with an OO style?
  From blowmage

• I think anything can be "overdone". This is true with nearly every best practice I can think of. I've seen inheritance chains so complex, the code was virtually unmanageable.

  From Kilhoffer