And why is it often talked about?
Like I know what OO programming is obviously... but people always say "Oh OO reuse is the biggest programming myth ever".
What exactly does this mean?
-
I think the real meaning is that inheritance is not the proper way to achieve code reuse - that's composition. stackoverflow.com/questions/4989670/… – wkl Mar 1 '11 at 17:51
-
2i think the real meaning is that a lot of people don't seem to understand proper forms of reuse, and thus blame inheritance. stackoverflow.com/questions/4989670/… – Steven A. Lowe Mar 1 '11 at 20:33
-
1A myth, that's what. – Ed S. Mar 1 '11 at 22:29
Add a comment
|
There was a belief (or at least there is a belief that there was a belief) that with OO we would have vast libraries of reusable objects that would make application development as easy as connecting boxes in a diagram. You may have noticed that this didn't happen.
In the mistaken belief that code can be written perfectly the first time, I have seen several projects attempt to first develop a "reusable" library, and then build applications using the library. All those projects subsequently failed, or ended up costing much more than a simpler top-down approach would have. Due to the Dunning-Kruger effect, many developers underestimate the difficulty of producing a usable library, while overestimating their own ability to do so. Worse, the developers who are drawn to build these libraries often believe themselves to be smarter and doing more important work than the application programmers, and consequently blame difficulties with the library on the users.
Most high-quality libraries have been created in one of two ways:
- Adapting another high-quality library to a new language.
- Extracting a library from a working application, and then continuously improving the library by using it to build other applications. This takes a while.
answered Mar 1 '11 at 21:07
-
3Couldn't agree more! Without the experience of proven, well documented designs or solid observations of existing code, any undertaking of creating reusable code is premature and doomed for disaster. – Filip Dupanović Mar 1 '11 at 21:16
-
2+1, and I lol'd at "vast libraries of reusable objects that would make application development as easy as connecting boxes in a diagram. You may have noticed that this didn't happen." – jmq Mar 1 '11 at 22:25
-
2Yeah, most OO code is not reusable. I would go as far as saying that is probably a good thing. If all of your projects contained objects that were reusable in the future you were likely over-engineering the thing to begin with and wasting a bunch of time on code you'll likely never need. – Ed S. Mar 1 '11 at 22:30
-
1I'd suggest that the base class libraries of a framework such as .NET (and others) have quite successfully provided 'vast libraries of reusable objects' that make application development easy (although not quite as easy as connecting boxes in a diagram!) – Matthew King Mar 2 '11 at 1:03
-
1@Joviee: it is definitely possible to provide useful class libraries. Most of the .NET classes provide services that have been available in other languages or operating systems for decades. Microsoft's attempts to invent novel APIs have not been uniformly successful. – kevin cline Mar 2 '11 at 5:11
I think people are referring to software projects that have failed to benefit from re-use. There are three reasons I can think of for this:
- Developers don't know that code is already written, so they can't reuse it
- existing code is hard to understand or poorly documented, so developers write their own implementations.
- Existing code runs on a different platform or is incompatible
However, these problems are not unique to OO.
-
1I disagree. The real problem is that it is very difficult to write code that is reusable in multiple projects because each project has it's own requirements which will vary, if even slightly. So, the old code may help get you started, but you almost always have to tweak it to get it working correctly for the current project. – Ed S. Mar 1 '11 at 22:43
To gain real benefits of object-oriented reuse, you must understand the different kinds of reuse-and where and how to apply them.
Good reads
Reuse is both a reality and a myth. Since I started programming we have always had reuse.
The reality is we do have extensive reuse without which we would not be able to do the projects we do. Reuse starts with the core libraries provided with the language, and continues through frameworks that greatly simplify development.
Inside organizations and projects reuse can be a myth more than a reality. Some of this is the fault of programmers who need a class to do X so they write a class to do X. The fact the organization has 20 such classes, and the project already has 5 of them doesn't enter into the programmers mind. This can extend into the libraries where we really do get reuse. DRY can be really useful to reduce this tendency, especially when applied on a project, team, or organization level.
Many organizations do not invest in reuse. It has been my experience that this is to their detriment. My first experience with designing for reuse allowed me to deliver a systems which I believe was underestimated at one year using the existing methodology in three months. That experience was pre-OO.
Where organizations are missing out on reuse is at the business object layer. SOA is one approach I believe can be used to gain reuse. However, the call-out implementation likely discourages its use were integrated functionality is desired. Creating some core service libraries which can be used by multiple applications, or have enforced usage in a project can have real benefits.
One drawback of reuse in an enterprise, is that changes may impact many systems. Without a good application portfolio, this can be difficult to track. However, it is my experience that the services which give most benefit are likely to be relatively stable and become more so the more they are used.
First of all, let me say that
- OOP is a very useful idea, and
- it was oversold, as many useful ideas are.
The overselling consisted of telling people (I certainly heard this) that developing software would amount to just combining pre-existing modules into new designs. The analogies used were: factories, mechanical assemblies, Legos, bridges, things like that.
As if those doing the selling knew the first thing about building bridges, etc.
Personally, I think a better concept is DSL (domain-specific-language). Every program is a string of code in a language. The nouns, verbs, and the ways you can combine them produce the most concise and maintainable code when they well-express the mental concepts in the problem being solved. That is a different approach than aping mechanical assembly.
Sometimes OOP (and leveraging pre-existing classes) is the right tool to use for parts of the job. It's far from the whole story.
answered Mar 1 '11 at 22:29
The real meaning is usually that the person saying this has an agenda, usually related to promoting a non-object-oriented language, and they think that a good way to accomplish their goal is by tearing down the competition. (Hey, it works well for politicians...)
Either that, or all of their experience with object-oriented programming has been in C++--which implemented almost every detail of OOP wrong and makes reuse far more difficult than it needs to be--and they aren't aware that better systems exist where reuse is quite common and actually works well.
answered Mar 1 '11 at 21:48
OO reuse is much the same as non-OO reuse. Most sensible languages allow writing of libraries, even C. Only we generally use the more sensible term "use". We use a library, saying reuse would sound dumb. Use of the phrase "OO reuse" probably indicates naïvety.
answered Mar 1 '11 at 21:53
