Reusing code

Make an early architectural decision about how much you will tradeoff performance, seamlessness, reuse, code flexibility, and so on. If your clients shout for little functional enhancements every day (something that is typical for in-house financial trading software), optimize the underlying communications and infrastructure but leave the business model pristine. But if your software will be embedded in a million car engines for 10 years, optimize for performance. 

Reuse code by generalizing from existing work to make pluggable components. 

Extent of reuse metric (SU) reused code is expected to have a positive impact on reliability because this reused code was part of an application that performed correctly in the field. Two cases need to be considered (1) The reused code is to be used in an application of the same type as the application from which it originated. (2) The reused code is to be used in an application of a different type requesting different interfaces and so forth. In each case S [7 is a factor obtained empirically, which characterizes the impact of reuse on reHabiUty. 

Program a Task Once and Reuse Your Code Everywhere 12... 

The key to making a large variety of software products in a short time is to make one piece of development effort serve for many products. Reuse does not mean that you can cut-and-paste code The proliferation that results, with countless local edits, rapidly becomes an expensive maintenance nightmare. 

Chapter 16, How to Implement a Component, describes how to do the internal design of a component. Chapter 10, Components and Connectors, discusses how to define component designs abstractly and precisely and Chapter 11, Reuse and Pluggable Design Frameworks in Code, discusses the design of pluggable class and component frameworks. 

Whenever any action is specified, it implicitly defines an effect. That effect can be referred to from another action. Sometimes you want to say, This operation does the same as that, but also. .. —in other words, to reuse the specification of another action. Specifications can be quoted within others postconditions (this is analogous to calling subroutines in code). However, you need not do this too eagerly. Specifications must be clearly understandable, and abstract attributes and effects can be used quite freely it is the implementations that must use careful encapsulation and hiding.16... 

Pattern 6.2, The Golden Rule versus Other Optimizations This is the pattern to use when stringent requirements about reuse, performance, or flexibility keep you from maintaining the most straightforward continuity to code. 

The same business model can be used for many projects within the same business. As a result, more of the code can also be generalized and reused. 

Moreover, there is little flexibility and reuse at the level of individual problem domain objects. Each object plays roles in different collaborations a far more likely unit of reuse is the collaboration or its manifestation as a framework in code (see Chapter 11, Reuse and Pluggable Design Frameworks in Code). 

Packages are the containers for all development work, from models to documentation to code and test (see Figure 7.27). Packages define units of versioning, configuration management, and reuse. 

This part is about the reuse of implementation code and discusses approaches to designing and building components so that they can be readily extended or adapted for use in different contexts. 

Chapter 11, Reuse and Pluggable Design Frameworks in Code, discusses the design and development of pluggable components, including how it affects the development process. 

Components are software artifacts and represent the work of software developers and their tools objects are identifiable instances created in running systems by executing code that is a part of some component. So, in that strict sense, an object is not a component. It is the component code that is reused—the calendar package, perhaps with some customizable properties—rather than a specific calendar instance and its state. 

A framework can be only a specification or can also include code implementation (see Chapter 11, Reuse and Pluggable Designs Frameworks in Code). The latter requires more investment in its design and may run slower. Pure specification frameworks help you build a spec, and then you must implement the result it does not have the same runtime overhead of pluggability. 

Code reuse is a sought-after goal, but it does not happen automatically. It costs money, and it requires explicit attention at the level of design and in the structure of the development process within and across projects. 

What should you reuse The executable Source code Interface specifications Problem domain models ... 

Reuse Law 1 Don t reuse implementation code unless you intend to reuse the specification as well. Otherwise, a revised version of the implementation will break your code. 

Naturally, the organization that measures developer productivity in terms of lines of code written has some rethinking to do before reuse can succeed. Suitable incentives schemes should be based more on the ratio of code reused to new code written. 

In object-oriented design and programming, the concept of a framework has proven to be a useful way to reuse large-grained units of design and code while permitting customiza-... 

Table 11.1 summarizes the contrast between the approaches in terms of factoring of code, degree of reuse, and consistency of resulting designs. These differences are summarized in Figure 11.7, which show the contrast between base and application levels in the two approaches. 

Inheritance was initially touted as the preferred object-oriented way to achieve reuse and flexibility. In the early days of Smalltalk (one of the earliest popular OO programming languages), several papers were written promoting programming by adaptation. The principle was that you take someone else s code, make a subclass of it, and override whichever methods you require to work differently. Given, for example, a class that... 

Reuse of software is not simply a matter of cut-and-paste it should involve the reuse of interface specifications before implementation code is reused. Successful reuse poses many organizational challenges (culture, development processes, and so on) as well as technical ones (designing components that are adaptable to many different contexts and devising techniques for plugging in the adaptations). 

The framework approach to code reuse provides a concrete, yet incomplete, implementation of the architecture The rules and policies about how application objects interact are codified and enforced by the framework itself. Frameworks can be both white-box—a template method in the superclass must be overriden by a subclass after understanding the calls made in the superclass implementation—and black-box, in which interfaces for the plug-in calls are explicitly specified and implemented according to the spec. 

Are you going to reuse the old code or only the old design ideas or only the old business model In general, each of these elements can be reused using appropriate techniques. In each case, it is essential to capture the existing concepts first (using the modeling notation in earlier chapters) and, separately, to document where you d like to be. 

Chapter 11 Reuse and Pluggable Design Frameworks in Code... 

---