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?
-
4I've never heard anybody say that...– TheLQSep 5, 2010 at 23:01
-
2@the I don't believe I've actually heard anyone say it, but I have read it.– George MarianSep 6, 2010 at 17:56
-
Re-usability is not the only advantage of OOP.– NobodyOct 12, 2010 at 15:02
-
2"Have objects delivered in terms of code reuse?" -> Only if you believed the OOP salespeople from back in the day (was that the 60s? I forget)– Steven EversOct 12, 2010 at 15:15
-
My answer to a similar question: programmers.stackexchange.com/questions/53521/…– kevin clineOct 22, 2011 at 7:57
11 Answers
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.
-
Well, yes. But have objects assisted library designers by providing them options that make their libraries easier to reuse? I would argue they have, and therefore objects have delivered improved reuse.– JulesJul 11, 2017 at 0:41
-
@Jules I, too, like to debate just for the sake of debating. I wouldn't argue that objects have not made designing libraries easier. I'm arguing that proper use of your tools is what leads to proper results. Jul 11, 2017 at 16:25
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 :)
-
Code reuse is definitely something to aim for, when you can avoid sacrificing code quality– CasebashSep 6, 2010 at 12:34
-
1Code reuse though is not a goal unto itself. Reuse is another word for coupling. As such, you must approach reuse carefully. Seems a lot of developers forget this. They want decoupled systems, but turn around and try to use an existing classes everywhere.– AndyOct 22, 2011 at 13:39
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.
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...
-
4Various articles. And from personal experience, making an object reusable isn't very easy at all– CasebashSep 6, 2010 at 20:46
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.
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.
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!
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.
-
4I agree that objects make code nicer, but unfortunately such a large proportion of my objects aren't reusable. To often, making an object reusable means oversimplifying the situation– CasebashSep 6, 2010 at 0:12
-
2@casebase +1 However, I would say that making objects reusable means overcomplicating the situation (object). Sep 6, 2010 at 3:15
-
Not everything is going to be reusable. Most things won't. However, low coupling, information hiding, etc, are all prerequisites for reuse, and object promote that. Sep 6, 2010 at 3:19
-
2@Fishtoaster: you might as well say that your car moving is a prerequisite to getting to work, and an incline driveway promotes that. It's technically true, but unlikely to make a difference outside of edge cases: if you need and want re-use, you'll get it, OO or no; if you don't, then having the prerequisites won't make it happen accidentally.– Shog9Sep 6, 2010 at 3:29
-
@Mr. C- I'm not sure I follow your point. I was merely stating that the things OOP fosters (modularity, etc) make it easier to make things like libraries. There are plenty of ways to make code reusable by separating concerns, etc- OOP is one, good method design is another, proper problem decomposition is another still. Sep 6, 2010 at 4:04
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.
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
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.