The other day, Microsoft released a CTP for the Managed Extensibility Framework (MEF). According to Brad Abram's blog:

Many people have noted that the industry has not yet achieved the level of code reuse the Object Oriented Design promised. One of the reasons for this is the tight coupling that most OO systems tend [to] allow. Over the last few months (and for some of us, years) we have thought deeply about how we can encourage more reuse. We believe MEF is part of the solution.

Indeed, code reuse as a benefit of Object-Oriented Design has been a panacea that has not been realized much since its inception. With this release of the MEF Microsoft clearly believes this is a problem of the difficulty or lack of support in its tools. I disagree.

What Is Code Reuse Anyway?

According to Wikipedia:

Code reuse also called software reuse, is the use of existing software, or software knowledge, to build new software.

Not obvious, but implicit in this definition, is that the existing code should not be modified for its new role. Doing so would cause the product in which the code is currently used to be regression tested, new client roll-outs done, etc., all incurring cost, and eating into the savings of reusing preexisting code.

Lack of Technology?

Many object-oriented languages (such as C#) provide the fundamental building blocks necessary for an object-oriented design: classes, interfaces, abstraction, and polymorphism. Concepts such as interfaces and abstract classes provide the foundation on which reusability is formed; the idea being create abstract classes or interfaces and inherit more concrete classes from those building blocks. Even though many systems are built on hundreds of abstract classes and/or interfaces, the concrete classes are often never reused in another project.

Beyond Technology

In addition to language features, much more abstract and fundamental ideas relating to reuse have come to the fore such as design patterns. Design patterns promote code reuse through abstraction of a problem. The generalized design patterns state a software engineering problem and the solution to that problem in a very abstract way. If one is going to be able to reuse anything, it would be the pattern solution for a common problem. While design patterns come a lot closer to actual reuse in that the problem behind the design pattern is usually of a somewhat common nature (although some deal with very obscure problems), the actual concrete code written to solve the problem is usually not exactly the same as the pattern describes. This is often because each problem is different. Though it may share a common general nature with some other problem, the exact implementation of the solution will be different. And therein lies the main problem with code reuse.

Nostradamus We Are Not

True code reuse requires the architect to know, flat-out know how the code will be used in the future. Without knowing for sure, it is extremely likely some kind of design decision will be made that will make the code unusable for a future solution, cause some amount of redesign and refactoring to occur, or, at the least, to be unlikely to solve any future problem.

I don't see this as a big deal, per se. Smart architects will generally have a good feel for how a software product will mature and will design an architecture that is open and malleable and easily maintainable. Since the large majority of the cost of a software project is incurred in the maintenance phase this only makes sense for the prudent architect. However, what the architect cannot do today is fathom what problem (or shade of a problem) the software will have to solve tomorrow.

So What's My Point?

What Microsoft's MEF does is provide a framework for modifying an existing codebase in the least invasive way possible. To that end, I think it works. What it does not do, however, is permit tacit code reuse simply by its implementation in your project. Code reuse requires the work of smart, seasoned, human software architects utilizing tried and true methods.