Have objects delivered in terms of code reuse?

Question

I have often heard it said that objects have not delivered in terms of code reuse. Do you agree? If you believe that they haven't, why not?

Answer 1

No, not necessarily.

Objects deliver better semantics, organization of code/functionality and, possibly, ease-of-use.

Well designed libraries deliver on the promise of code reuse, not objects per se.

Answer 2

Honestly I'm not sure if "code reuse" is really what anyone is after (or at least, should be after). My philosophy is "software components", which means better maintainability through good interfaces and avoiding unnecessary coupling. "Code reuse" is one of the things that falls out of that sometimes -- unnecessarily duplicated code is a sign that you've organized things the wrong way and of course it's a pain to maintain.

To answer the question a little more directly, there's a collection of pretty good tools for avoiding repeating yourself: inheritance, traits, delegation, higher-order functions, etc. Of those, people tend to confuse inheritance with OO as a whole -- and they also tend to overuse it a bit, if you ask me. Maybe that's where some of the "OO sucks" vibe comes from: finding inheritance stuck where it has no natural right to be :)

Answer 3

No, "objects" haven't made code re-use any easier or more common. The same concerns that prevent code from being re-used in a modular program (designing, testing and documenting a general-purpose API requires considerably more up-front effort than writing a one-off routine, and the jack of all trades may be the master of none - logic intended to be re-used may not be well optimized for the uses it is actually put towards) apply to OO programs, with the added concern that a poorly-designed object model can hamper the re-use of otherwise reusable code.

OO is a handy abstraction for a good many problems, but be wary of '80s-'90s hype: it doesn't magically solve the fundamental problems of our trade any more than it makes waffles for you while you sleep.

Answer 4

I don't expect ALL objects to be reused but we do have a lot of object that we reuse on many different projects. We also have objects that just get reused on one project. We often will consume the same business objects (or data transfer objects) as well as business logic objects from a Click-Once desktop app, a web app and a phone app all for the same project.

Where have you heard that OO doesn't deliver on reuse? And what was the reasoning? Perhaps the design of their objects forced them into that situation...

Answer 5

Some Programmers will copy and paste in any language and style.

Really good programmers can avoid most copy and paste in nearly any language.

I find OO patterns tend to encourage reuse. I've seen Java code that was written in a non-OO style (where the data was separated from the code due to crappy ORM) and the reuse was truly miserable--but in OO the same programmers did a better job at design (and reuse).

Also in cases where we use non-oo patterns or oo anti-patters such as setters/getters, switch statements, anonymous inner classes, huge functions and the like I've seen code reuse go down and boilerplate go up...significantly.

ps. I know people will have problems with the previous paragraph, so I'll explain a bit.

Setters and getters cause OO problems because they allow you to operate on the members of an object (an object should manipulate it's OWN members) This distributes the code that operates on your class throughout other classes requiring you to copy the functionality around the setter/getter. This applies to Properties as well--just because Properties are easier doesn't make them "Good" in all situations.

The code in Anonymous inner classes can't be reused at all and people forget that many things (like listeners) can and should be full-fledged classes--this applies to closures as well! If you have used an anonymous inner class to implement something like a listener, you are much more likely to just copy and paste your implementation than to extract the code into a method or it's own class and call it instead. Closures can also improve reusability--just depends on how you use them.

In many cases the features available to you shape how you structure your code. OO is even more powerful when it comes to helping you visualize all your code and how it interacts, but that's another question.

Answer 6

Objects have no more ability to deliver code reuse than a stairclimber or other fitness equipment can deliver weight loss. Developers have to be motivated to use tools properly.

Once software teams place a higher value on reusing tested code than they do on keeping all the details in their head, you'll see far more fine-grained objects and methods and hence more code reuse.

Answer 7

Yes

OOP gives you more ways to reuse code

No

there is no silver bullet

It Depends

on what you put into it, and what you expected in return!

Answer 8

Yes. Good object oriented programming promotes separation of concerns, low coupling, high cohesion, and information hiding. These things are all critical to reusable code.

I would argue that the main benefit of OOP is modularity and modifiability, rather than reuse, but that's another question.

Answer 9

Objects enable code re-sue but as such is not the most technique for that. I think code re-use is promoted through object related techniques such as inheritance, polymorphism, overloading, and templates.

Answer 10

Yes, they do, the ability to extend (inherit) from a super class cleary contributes to code re-use, I am not sure how anyone could argue otherwise. You can simply extend a class and override one method, while using the rest from the super class, if this isn't aiding in code re-use then I don't know what is

Answer 11

If it is have they delivered on their promise of code reuse so far? Yes, if the programs written with OOP in mind apply design patterns wisely. Otherwise, mostly no. But looking at the popularity of large scale non trivial programs that Adobe systems, Google and the like write with C++ or Java or other OOP languages, I would say OOP has a long way to go before it phases out. That time will be far better suited to ask this question and could help in providing ground work for a new paradigm.