Code reuse: Difference between revisions

Revision as of 14:26, 26 June 2007

Revision as of 17:17, 26 June 2007

Line 7:

A very common example of code reuse is the technique of using a [[Library (computer science)|software library]]. Many common operations, such as converting information among different well-known formats, accessing external storage, interfacing with external programs, or manipulating information (numbers, words, names, locations, dates, etc.) in common ways, are needed by many different programs. Authors of new programs can use the code in a software library to perform these tasks, instead of "re-inventing the wheel", by writing fully new code directly in a program to perform an operation. Library implementations often have the benefit of being well-tested, and covering unusual or arcane cases. Disadvantages include the inability to tweak details which may affect performance or the desired output, and the time and cost of acquiring, learning, and configuring the library.

The software library is a good example of [[Abstraction (computer science)|abstraction]]. Programmers may decide to create internal abstractions so that certain parts of their program can be re-used, or may create custom libraries for their own use. Some characteristics that make software more easily reusable are [[Modularity (programming) | modularity]], [[Coupling (computer science) | loose coupling]], high [[Cohesion (computer science) | cohesion]] and [[information hiding]].

For newly written code to use a piece of existing code, some kind of interface, or means of communication, must be defined. These commonly include a "call" or use of a [[subroutine]], [[Object (computer science)|object]], [[Class (computer science)|class]], or [[Prototype-based programming|prototype]]. In organizations, such practices are formalized and standardized by [[Product Family Engineering|software product line]] engineering.

Line 23:

* Planned reuse - A team strategically designs components so that they'll be reusable in future projects.

Opportunistic reuse can be categorized further:

There are other ways to categorize reuse, considering a make vs. buy decision:

* Internal reuse - A team reuses its own components. This may be a business decision, since the team may want to control a component critical to the project.