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?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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:
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:
However, these problems are not unique to OO.
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
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.
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.