CSC/ECE 517 Fall 2012/ch1 1w7 am

From PG_Wiki
Jump to: navigation, search

Code Reuse - This page describes what is code reuse, how to achieve it and discusses the advantages and disadvantages of code reuse.



Code reuse is the way in which an existing code can be used to perform a specific service regardless of the application in which it is used.[1] It involves the use of some previously constructed software artifacts like source code, library, components, etc. An example of it can be the design patterns in a new context or in a new development project.

Software reuse is the process of creating software systems from existing software rather than building software systems from scratch.[2]

Overview [1]

Code reuse is the idea that a partial computer program written at one time can be, should be, or is being used in another program written at a later time. The reuse of programming code is a common technique which attempts to save time and energy by reducing redundant work.

The software library is a good example of code reuse.

Programmers may decide to create internal abstractions so that certain parts of their program can be reused, or may create custom libraries for their own use.

The general practice of using a prior version of an extant program as a starting point for the next version, is also a form of code reuse.

Some so-called code "reuse" involves simply copying some or all of the code from an existing program into a new one. While organizations can realize time to market benefits for a new product with this approach, they can subsequently be saddled with many of the same code duplication problems caused by cut and paste programming.

Many researchers have worked to make reuse faster, easier, more systematic, and an integral part of the normal process of programming. These are some of the main goals behind the invention of object-oriented programming, which became one of the most common forms of formalized reuse.

A somewhat later invention is generic programming.

Another, newer means is to use software "generators", programs which can create new programs of a certain type, based on a set of parameters that users choose. Fields of study about such systems are generative programming and meta programming.


Ad hoc code reuse has been practiced from the earliest days of programming. Programmers have always reused sections of code, templates, functions, and procedures. Software reuse as a recognized area of study in software engineering, however, dates only from 1968 when Douglas McIlroy of Bell Laboratories proposed basing the software industry on reusable components. [1]

There are many dimensions along which we can trace the history of reuse: [3]

History of software reuse based on implementation technology dimension [3]

Third generation languages were more portable than the earlier machine specific languages; even though source code still had to be language, OS and platform specific. However they did achieve limited source code reuse for high value. e.g. math libraries.

Introduction of object oriented languages like Common Lisp Object System (CLOS), C++ interpreter, etc provided encapsulation and packaging technology.Packaging and common object models promoted development of language “bindings”. Systematic and repeatable object oriented development processes were also introduced during this time. Although most portability constraints remained as they were, some reuse success was achieved in the form of high value data structure libraries (e.g. GRACE and Booch parts). The first successful reusable service of SQL RDBMS was developed during this period.

This era saw development of mature OO languages like Smalltalk, ANSI CLOS, C++ compilers, GUI and Event Driven Programming Libraries and portable compiled software packages like Shared Libraries, Dynamic Link Libraries, etc. Significant reuse research was carried out during this period(e.g. SPC CoE for Reuse/ARPA contract) which gave birth to early software reuse driven processes and reuse libraries (like management systems, not just content)

Dynamically Integrable Autonomously Executable Components that are compiled and linked separately, integrate at run time, and run independent of each other were developed during this period. (e.g. COM and CORBA). Distributed systems which formed the foundation for Web Services and Component Based development processes were introduced. Advances like these also gave rise to commercially successful code generators like Netron, Frame Technology and reusable component vendors like Infragistics.

Along with introduction of Cross Protocol Bridges which allow COM and CORBA systems to participate in the same system, Light weight integration protocols like SOAP were introduced in this period. New reusable component packaging mechanisms were invented. Reuse based development processes matured with time and specialized reusable component market got established.

This era saw rise of Service Oriented Architecture and rediscovery of reuse research like Software Reuse (Asset) Management Systems, Domain Specific Reuse, Domain Languages (Software Factories), etc. It was understood that reuse must reuse more than just code and it would require drastic process changes. Design patterns were also created during this time. Reuse Successes during time include - Microsoft .Net Framework, SRMS: Flashline and LogicLibrary.

Techniques [4]

In re-using code, we have several levels of granularity

Single lines of code

For example, in Ruby to print an array containing 5 elements we simply use the following

[ 'Sam', 'John', 'Gita' ].each {|name| print name, " " }

outputs : Sam John Gita.

Procedures, Macros

Procedures and macros are the low level code reuse techniques A macro is a group of repetitive instructions in a program which are codified only once and can be used as many times as necessary.

Position MACRO Row, Column 
MOV AH, 02H 
MOV DH, Row 
MOV DL, Column 
MOV BH, 0 
INT 10H 

A procedure is a collection of instructions to which we can direct the flow of our program, and once the execution of these instructions is over control is given back to the next line to process of the code which called on the procedure.

Adding Proc Near ; Declaration of the procedure 
Mov Bx, 0 ; Content of the procedure 
Mov B1, Ah 
Mov Ah, 00 
Add Bx, Ax 
Ret ; Return directive 
Add Endp ; End of procedure declaration 


For example, in Ruby a method can be written as follows

def convert_to_farenhite(temperature_in_celcius)
result = temperature_in_celcius * (9/5) +32
return result


When you are building software, objects are created in code, and reusable objects that perform specific services in different circumstances are called components. When you use Microsoft® Office to build custom applications, you write code that leverages the power of Office components. Using an Office component means you are not only excused from writing the code yourself, but you are using a component that has been tested and found reliable in different conditions.

Object orientation [5]

High level languages also come with effective abstractions to build and share "abstract data types" and other "reusable libraries". Source code components are generally intended to be used as black-boxes: a public interface of usage is announced, formally or not (ruby has not equivalent of java interfaces, for example), while the realization of this interface is kept hidden (or at least intended to be). Think to C libraries, java's .jars, python's modules, ruby's gems, and so on. In many languages, "find a component, download it, and go" has become a reality!


A Java package is a mechanism for organizing Java classes into namespaces similar to the modules of Modula. Java packages can be stored in compressed files called JAR files, allowing classes to download faster as a group rather than one at a time. Programmers also typically use packages to organize classes belonging to the same category or providing similar functionality. A package provides a unique namespace for the types it contains. Classes in the same package can access each other's package-access members.


Modules are a way of grouping together methods, classes, and constants. An example of a Ruby module is as follows

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
def Trig.cos(x)
# ..


In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, parent classes or ancestor classes. The resulting classes are known as derived classes, subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy. The basic mechanism of subclassing is simple. The child inherits all of the capabilities of its parent class — all the parent’s instance methods are available in instances of the child. Let’s look at a trivial example and then later build on it.

Here’s a definition of a parent class:
class Parent
def say_hello
puts "Hello from #{self}"

p =

Output: Hello from #<Parent:0x0a40c4>

and a child class that inherits from it:

# Subclass the parent...
class Child < Parent
c =

Output: Hello from #<Child:0x0a3d68>

The parent class defines a single instance method, say_hello. We call it by creating a new instance of the class and store a reference to that instance in the variable p. We then create a subclass using class Child < Parent. The < notation means we’re creating a subclass of the thing on the right; the fact that we use less-than presumably signals that the child class is supposed to be a specialization of the parent. Note that the child class defines no methods, but when we create an instance of it, we can call say_hello. That’s because the child inherits all the methods of its parent. Note also that when we output the value of self — the current object - it shows that we’re in an instance of class Child, even though the method we’re running is defined in the parent.


Source code generation is the act of generating source code based on an ontological model such as a template and is accomplished with a programming tool such as a template processor or an IDE. These tools allow the generation of source code through any of various means. A macro processor, such as the C preprocessor, which replaces patterns in source code according to relatively simple rules, is a simple form of source code generator. Parser generators (lex & yacc, antlr, rats!, treetop, pyPEG, and so on.) are probably the best-known examples of application generators. Other examples include wizards that one can find in Integrated Development Environments (to design and generate code of user interfaces, for example), tools that generate classes from UML class diagrams, generators of database schemas, report generators, etc.

Software architectures

Software architectures are large-grain software frameworks. In contrast with source code components which are often black-boxes, software architecture are designed as grey-boxes: they are intended to be extended and provide specific extension points for this. We have a lot of reusable frameworks nowadays. Probably the most common are web frameworks (Ruby on Rails, django,, ...), integrated development environment (IDE, Eclipse is worth mentioning due to its architecture), service oriented architectures (SOA), and so on.

Design and code scavenging

Design and code scavenging is simply a form of "find, copy-paste, adapt". The well-known design patterns provide an organized form of design scavenging, by providing catalogs for applying such kind of reuse. Even if invented in the context of the object-oriented programming, design patterns had a great impact far beyond that programming paradigm.

Code scavenging is less organized as few such catalogs exists. Every day however, the web gives users better ways to apply reuse techniques such as google code search, github's gist, pastie, and so on.

Transformational systems

Transformational systems are the holy grail of computer science, nothing less! In that paradigm, software developers actually describe the behavior of the software using a high-level specification language (related to VHLL described before). In a second phase, the specifications are transformed in order to produce an executable system. The transformations are meant to enhance efficiency without changing the semantics.

Transformational systems emphasizes the what instead of the how. They actually bet on the concision of declarative statements over procedural ones to achieve effective reuse. While general purpose transformation systems remain mostly research topics, notable results have been achieved in some specific domains: relational systems come with effective query optimizers, some rapid prototyping approaches using transformations from high-level descriptions down to code, etc.

Very High Level Languages (VHLL)

Very High Level Languages, also known as executable specification languages, are languages with very high level of abstraction. They are somewhat difficult to capture precisely and may lead to software reuse that is very specific to specialized domains. However, the recent advent of Domain Specific Languages (DSLs) and good support for them in dynamic languages (ruby, python, clojure, ...) and can be seen as promoting and helping building VHLLs.

Best practices [7]

Here are some of the best practices to be followed to make sure that the code that is being written is reusable.

Advantages [3]

Trade-offs for code reuse at various levels of components [8]

Different types of application code require varying levels of investment to achieve successful reuse

Practical problems [3]

Although software reuse provides many benefits for the developers, there are some disadvantages.

Disadvantages for developers who reuse the code

Disadvantages for developers who develop reusable code

With all these elements, it becomes apparent that reuse doesn't come cheap.


The only way you can avoid code depreciation is through reuse but you need to be disciplined and follow a strict process. Reuse enables you to do more with less.

See also


  1. 1.0 1.1 1.2
  3. 3.0 3.1 3.2 3.3
Personal tools