(See also SoftwareReuseBook.)
is about reusing software. You can also say CodeReuse
There is much misunderstanding about that topic in my opinion. Some think, CopyAndPasteProgramming
) is also a type of SoftwareReuse
. I disagree.
I think, that SoftwareReuse
starts with reusable software. Many people think, they can get the benefits of reuse just by grabbing any software and reusing it. This normally fails. The conclusion of many companies is that ReuseHasFailed
-- but I just think that CompaniesHaveFailedToReuse
Why do I not think, that CopyAndPasteProgramming
Because it is just CodeStealing?
. It leads to DuplicatedCode
. You may get a temporary benefit of this (like any thief has) but in the long term you run into trouble. I saw code that was cluttered with comments like "When changing this, please also update that ...". This ends up in MaintenanceHell?
A more elaborate discussion about reuse you can find in my article TheMythicalManMinute
(the good kind, where you never edit the generated code) seem to be reuse of another kind. The concept is a bit
tricky though and real understanding isn't all that common. Remember also: There Is NoSilverBullet
a type of reuse, whether you like it or not! The duplication is not an issue if you only have to maintain one copy. If the code is 'stolen' from a completely different software system, then the duplication does not add to the complexity of the software you are interested in. There is only a practical issue if you are charged with maintaining both software systems. There is only a moral issue if you are literally stealing copyright material. -- ChrisSteinbach
What is the difference between code use
and code reuse
? I think a lot of the discussion on ReuseHasFailed
could be helped if that was cleared up. Perhaps this is best looked at using examples:
1. Developer writes a GUI app and everyone else in the office uses it -- clearly use
2. Bunch of developers create an OS or web server or database server, and other developers use it to create their appliance or application -- use
3. A developer creates a library (e.g. standard C/Python/Java libraries) for other developers -- seems like use
to me, the library was written with that explicit purpose, and it had no original 'use', so you can't talk of it being 'reused'.
4. A developer copies a load of code from either
- a) an open source library or project or
- b) another project within his company, or another part of the same project,
modifying it as needed -- this is reuse
, but of an unfortunate kind, since it can be a maintenance nightmare, or at least it means you won't get the bugfixes to the original code.
5. A developer subclasses a HtmlParser?
class to create a HtmlParserWithPrettyPrinter?
class, possibly overriding some methods and adding others -- reuse
- the original code has now been made to do more than the author thought could be done, and we have a new thing, a 'HtmlParserWithPrettyPrinter?
' class without having to write the bulk of the code.
6. A developer finds some code in another project that does most of what they need. By some appropriate refactoring, they create a library of functions or classes (or even larger pieces such as executables or services), making them more generic if needed -- reuse
7. A developer realises that the code he is currently writing can be useful in other situations, and so is careful to structure so that it can be used without modification by subsequent projects -- sometimes risky, but if it works then it's reuse
8. Forking -- a new project that competes with or supercedes an old one, but comes from a common code base. You could argue this actually just use
-- the code is still doing the same job it was doing before. On the other hand, if you didn't write the original, you've got a huge amount of functionality for free, which you are able to reuse in your project, giving you a massive headstart on a competitor that decided to write from scratch, so in that case it's reuse
Am I thinking on the right lines? If so, the distinction seems to be based on whether the code had an original purpose or context, and whether it's now being used for that purpose. However, for number 3, in reality I think a library will almost always have had an original use, so this is really reuse
, and reuse of the best kind -- often so good that it is invisible, and we don't think of it as reuse. In fact, you can probably say the same thing about number 2 -- things like database servers have come about because people realised it's better to implement data storage once and well, rather than badly multiple times.
5 seems to be OO only, and I think it's the reason why people have claimed OOP leads to greater reuse -- but is 5 really different from 3? Many procedural or functional libraries will be used far beyond the imagination of the original author. 5 is also very hard to do in general, and it is often rather fragile -- encapsulating rather than inheriting is much easier, but your 'new thing' is an illusion -- it's only because OOP is noun-oriented that you seem to have created something new and big with very little effort. In the functional world, your new algorithm, while it may be built out of other algorithms, doesn't appear to be a new, bigger version of them.
A separate question is why
- why do we want to reuse software?
- to reduce development time (and cost)
- 3, 4 a) and 4 b), 5 and 6 work well here, 7 can be dangerous, 8 is fantastic if you dare (I'm thinking of Safari and KHTML)
- to reduce maintenance time (and cost)
- 3, 5, 6, and 7 work well. 4 a) and 4 b) are both bad, as you've added to the total amount of code you have to maintain, and 4 b) is especially bad, as you have to maintain both copies. 5 might be fine, but it might just break horribly on you, due to the flaws with subclassing (subclassing does not imply subtyping, and a mere change in implementation of a base class method might break your subclass). 8 can be disastrous if you don't realise what you've taken on.
So I guess which ones are really 'reuse', and which ones are good ways to do it, depends on your aims.