CSC/ECE 517 Fall 2012/ch1 1w7 am

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.

OVERVIEW

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 metaprogramming.

HISTORY

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.

There are many dimensions along which we can trace the history of reuse: Software Development Life Cycle (SDLC) Model Prototyping, Iterative, ESP, etc. Requirements/Specification Method Business Model Implementation technology dimension - concentrating on source code and later life cycle objects

e.g. Mid 1980’s Mature Third Generation Programming Languages Late 1980’s Early Object Oriented Languages and SQL DB Early 1990’s Mature OO Languages, Source Code Libraries Mid 1990’s Early DIAE Component Packaging Late 1990’s Mature DIAE Components, Cross-Protocol Bridges 2000-2005 Early Service Oriented Architecture Products

Best practices

It is not difficult to write reusable code. It is really a matter of how you approach the problem. If you understand how to create and use class modules, then you already know a great deal about how to approach writing reusable code.

The first consideration when you are writing reusable code is writing code that uses a consistent naming convention, that is formatted properly, and that contains useful comments.

Examine your existing code to make sure that your procedures have a single, specific purpose. Can you describe your procedures in a short, plain sentence? For example, "This procedure accepts an SQL string as an argument and returns a Recordset object containing the records described by the string." If you are unable to describe a procedure simply and clearly, it probably does too many things. Break down complicated procedures into smaller ones that do one thing each. Procedures should contain only code that clearly belongs together. Avoid making specific reference to named application objects. For example, the following code makes a specific reference to a combo box control and a text box control on a Microsoft® Access form:

strEmployeeName = Forms!frmEmployees!cboEmployeeName
strSQL = "SELECT * FROM Employees WHERE LastName = '" & Mid(strEmployeeName, InStr(strEmployeeName, " ") + 1) & "'"
Set rstAddresses = dbs.OpenRecordset(strSQL)
Forms!frmEmployees!txtHireDate = rstAddresses!HireDate

Function GetDataFromField(strTableName As String, strFieldName As String, strCriteria As String) As Variant
   ' Returns a value from the field specified by strFieldName
   ' in the table specified by strTableName according to the
   ' criteria specified by strCriteria.
   Dim rstFieldData    As New ADODB.Recordset
   Dim strSQL          As String
   On Error Resume Next
   strSQL = "SELECT " & strFieldName & " FROM " & strTableName & " WHERE " & strCriteria
   rstFieldData.Open strSQL, DATA_CONNECTSTRING & DATA_PATH
   If Err = 0 Then
      GetDataFromField = rstFieldData(strFieldName)
   Else
      GetDataFromField = ""
   End If
End Function

Try to minimize the number of arguments in a procedure and pass in only what is actually required by the procedure. In addition, make sure your procedures use all the arguments passed to them.

Group related procedures and the constants they use together in the same module, and where appropriate, consider grouping related procedures together in a class module with a clearly defined interface.

Keep procedures in standard modules and not in modules behind forms or documents. The code in form modules should be only that code that is tied directly to the form itself and the code required for calling general procedures stored in standard modules.

Communicate between procedures by passing data as arguments to the procedures. Persist data by writing it to disk or to the Windows registry. Avoid using a procedure to write to a global variable so another procedure can read data from that global variable. Avoid communicating with another procedure by passing data out of the application, for example, using one procedure to write data to a disk file, .ini file, or the registry so another procedure can read that data.

TECHNIQUES

Functions, procedures, subroutines, DRY, Mixin, methods, libraries, Object orientation, inheritance, generators, Reusable code is code that can be used, without modification, to perform a spectific service regardless of what application uses the code.

There are everyday objects that perform a specific service in different circumstances all around you. Think of a calendar. It gives you the ability to look up days and dates. You can use it to determine that this year your birthday falls on a Tuesday, or that Thanksgiving is on the 25th, or that there are two extra days to file tax returns because April 15 is on a Saturday. When you are building software, objects are created in code, and reusable objects that perform specific services in different circumstances are called components. Some characteristics that make software more easily reusable are modularity, loose coupling, high cohesion, information hiding and separation of concerns. 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, class, or prototype. In organizations, such practices are formalized and standardized by domain engineering aka software product line engineering.

Practical problems

Hidden cost of code reuse - Building reusable objects requires extensive analysis and design. "You really need to understand what the generalities are," says Kerth. Then, you will need to invest extra time in testing and quality assurance, optimization, and documentation. All this takes time and labor, which increases the cost of the code. IT departments must also add to the payback equation the cost of tools to support reuse, such as version control and repositories. Finally, the cost of administering an ongoing reuse program must be considered. With all these elements, it becomes apparent that reuse doesn't come cheap. Reusable Components

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

Reusable GUI objects reduce development time and improve quality and consistency but provide only modest payback in terms of overall application development costs. Server-side components that constitute reusable business logic can provide significant payback but require extensive up-front analysis and design. They also require an architectural foundation but may experience a short shelf life. Infrastructure components and services frameworks are generic services for transactions, messaging, security, and database connectivity. They eliminate the need to repeatedly build infrastructure that all applications use, but require extensive analysis and design, and complex programming. These standards-based components can often be purchased off-the-shelf. High-level patterns allow organizations to achieve design reuse and identify components with high reuse potential, but developers must build or acquire the components. Packaged applications provide the only guaranteed form of reuse, letting user companies acquire functionality for significantly less than the cost of building it themselves. However, these applications may not offer the exact functionality an organization needs; the subsequent customization that's required will add to the cost.