Object-oriented programming separates code into small modules of functionality. With proper design, these modules can be reused for other projects. For example, you might design a class that connects to the post office's Web site to look up nine-digit zip codes for a payroll system. However, because the class's internals are isolated and only a public interface is exposed, that same class can be reused next year in a new application that mails brochures to customers. More significant, if the old class does not do precisely what you need, you can subclass it, keeping those parts that are still useful and replacing those that are not. You will learn more about inheritance and subclassing later in this course.
Of course, it is possible to reuse code when you are doing procedural programming. Usually the code comes with a long list of instructions, remember to call open() before adding any transactions, do not pass a negative number to this method, that programmers may forget. An object-oriented approach builds the rules right into the code, so there's no need to remember so much.
Reusing code can make your development go a little more quickly, and that's always a good thing. But more important, it lets you focus your energies on the interesting new problems in this application, rather than repeating work you did earlier or that someone else has already done. Compared to cut-and-paste reuse, object-oriented reuse introduces far fewer bugs and is much easier to achieve.

There are ways that OO design and programming techniques can have a powerful impact on improving software reuse. In general, OO techniques enable reuse by enabling larger-grained abstractions and encapsulation mechanisms. OO practitioners have traditionally focused on the design and implementation of reusable components in terms of artifacts such as

1. classes,
2. class categories,
3. objects,
4. modules, and
5. subsystems.

Unfortunately, many OO reuse efforts have focused on language features (such as inheritance, polymorphism, generics, and exception handling) or design methods and notations (such as Booch vs. OMT vs. Shlaer/Mellor). One of the challenging issues is capturing and articulating the abstractions and components required to build widely reusable software in complex domains (such as real-time avionics, business data processing, telecommunications, on-line transaction processing, and distributed communication systems).
Developers and analysts need to translate their domain expertise into reusable software components. A number of approaches (such as transformational systems, expert systems, and domain-specific software architectures) have been advocated over the past decade. A major impediment is that many of these approaches do not integrate well into the development processes (or lack thereof) found in contemporary software organizations.