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?
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.
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.
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)
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.
I guess it is possible, but its hard to answer your in abstract terms (no pun intended). Give an example of over OO.
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.
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.
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
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.
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 .
Yes! Look out for Pseudo Classes and Quasi-Classes
I recommend idinews.com articles
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.
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.
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.
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.
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.