Did you ever feel any downside of using OOP as a developer?
Do you think over-usage of OOP concepts could lead to something like over-normalized database structures?
Where do you think we should draw a line while applying OOP concepts in our design?
Cross-links:
Yes, see: code smells.
Also, there are other valid ways of doing the same thing... actually some problems are really hard in OOP and easy in other paradigms -- see functional languages like Lisp or Prolog.
I think the only way OOP can be a bad thing is if you do it wrong. A lot of amateur programmers seem to grasp the concepts of procedural or functional programming pretty well, but it takes a very different mindset to learn to use OOP effectively.
Yes, it gets to a point where everything is so abstracted that simply navigating the code becomes a pain.
For example, CruiseControl.NET uses interfaces exclusively, and it can take me 10-15 minutes to track down the actual concrete class used in a situation, so I can find where I want to make a one line code change...That is OOP overkill in my opinion.
The main abuse of "OO" that I've experienced is when design patterns are used like recipes. Nothing replaces thinking through what the right solution is for your problem.
An overnormalized database structure doesn't have to follow from OOP in a database-based application. Even if you use something like an ActiveRecord pattern, you could still have a a domain layer of transient objects that applies OO concepts.
One code smell I've found in much OO-code I've read (and even written) is the usage of objects with an overly complex and ill-defined state.
no - there is no downside to using OOP as a developer, when it is the appropriate paradigm for the solution
no - over usage of OOP concepts is a red herring, you can 'over-use' the concepts in any paradigm; again this comes back to the developer and the solution space. Correctly designed objects tend to be in third normal form.
As an aside, complaints about "over-normalized" are often a big red flag for "lazy programmer". I have never seen an over-normalized database design, but i've seen a lot of un-normalized databases. I've also seen OO designs with excess interfaces, abstract classes, namespaces, etc., but then again I've also seen procedural programs littered with one-line functions used exactly once. It all depends on the developer's understanding of the problem, solution, and paradigm.
"it's a poor carpenter that blames his tools" ;-)
The only downside of OOP is that it might make you more likely to over-engineer in the sense of preparing for more future extensions and contingencies. If those never show up, you can end up feeling that you wasted an effort that you would have not got into with a less flexible paradigm.
Yes. The basic concept of an object, or perhaps more precisely a class, is a unit of code that encapsulates data and behavior. In cases where you have only data or only behavior, object orientation forces those ideas into the same bucket. Naive views of object orientation cause separate problems, where overuse of inheritance causes duplicated code. That said, well-designed object oriented languages, such as Ruby, have concepts that allow you avoid some of those problems. For example, in Ruby you have the concept of a module, which is more or less abstract behavior that can be added to any model.
Some denormalized data structures are troublesome. They tend to require more code and more thought when you have to update something in more than one place. I wouldn't link that to object orientation however. Over-normalized is a problem too. 3rd normal form is a good compromise.
Just as with normalisation, you can abuse OOP, making it less worthwhile, but I don't see why that's a valid answer... These pitfalls don't exist because OOP (or DBs) force you to write poor code, rather because the programmer isn't good enough.
If you wrote poor code that crashed all the time, you could hardly blame the compiler, the editor or the command line for your inadequacies, so leave Brittany OOP alone!
Did you ever feel any downside of using OOP as a developer?
Of course. There's always a downside, anyone who claims otherwise is either lying or has a problem moving their neck. Readability, maintainability, performance... can both benefit and suffer from the application of OO concepts. The trick is to use OO when the upside trumps the downside, and avoiding it otherwise.
...And to ignore the shrill lot who see OOP as the only hammer in the toolbox.
Do you think over usage of OOP concepts could lead to something like over normalized database structures?
Well, let's clarify: over-normalization isn't a concrete concept. If your level of normalization results in a schema that is too slow or too cumbersome for your needs, then for you it is over-normalized. Similarly, if your application of OO results in an object model that is obtuse, cumbersome, slow... you've over-done it, used the wrong tool for at least part of the job.
IMHO, OO vs. non-OO is a red herring, thrown out by folks who want all-or-nothing systems/platforms. Truth is, there's a big place for pure procedural code within most OO systems, and plenty of room for objects within procedural systems.
And they both benefit from a generous dash of functional code...
Object oriented code can be hard to read, hard to reuse and result in a complex program state which is hard to manage. Object orientation can also be elegant, but you asked for downsides.
In more detail:
Object orientation means you need to understand the classes in the program and libraries you are looking at, on top of the standard language types. Often this means that you need to know significantly more about the program to read one line of code than you would do in non-object oriented code. For instance, when you are reading code and you see a call it is important to be able to easily find the code that will be called. In object oriented programming, you need to know the class hierarchy, and what particular instances you are looking at; often you can't be sure just reading the code( because of polymorphism). If your object oriented code uses operator overloading then someone looking at one line of code has to understand any overloading going on, and that again means knowing all the classes.
Sometimes you'll get more code reuse with functional programming than object oriented programming, since functions can be kept small, self contained and conceptually simple even if they are used in complex modules.
If your program instantiates many objects which contain references to each other then it becomes hard to be sure garbage collection is going to work, and it can be difficult to serialise the program state (e.g. to display in a debugger). Generally the program state can be hard to manage. Compare this to code using functional programming, which is either just passing state as arguments and results, or grabbing state from a database and explicitly updating it,
It can be hard to figure the costs of creating objects and disposing of objects. I heard of a Java program that turned out to be spending more than half of it's time creating Gregorian Calendar objects. Re-use of objects can create other problems. I know of a web program that, on the first test, commingled data from one account with another account because objects were being reused without being cleared of data. OOP is not a natural match to recursion.
I think there is a difference between modularity as a concept and OOP as a programming style. OOP is credited with added modularity, but it's not the best way to implement modularity in every circumstance.
The major pitfall is when OOP is misinterpreted as a good design decision for every circumstance, OOP is a tool, and as such must be used appropriately and is not appropriate for all situations.
I've use a programming style where each object is instantiated only once for all functionality and then multidimensional arrays to store all information for the instances of that object. In this way I've separated functionality from information in my programs. I've dumped classic OOP for this model because it's much simpler to understand and update the code.
The most visible downside of OOP is you need more experienced developers. With novice programmers program easily become a piece of mess that goes nowhere near the aim of OOP. I have seen people writing database abstraction classes and still uses a query to access database.
Yes, over-use of inheritance forces solutions to be too tightly coupled. Better pass in dependencies or features.