Generics And Specifics

Erecting a framework.

...most projects, particularly early in the development cycle, have a mix of novices and experts. Of course, even the novices are expected to come up to speed quickly and contribute to the project.

✥ ✥ ✥

Novices, even when mentored, tend to produce weak designs and cut and paste code.

One does not acquire design prowess overnight; it takes years of experience. Even expert designers look back on their early work and shudder at how bad it was. Design, like every other skill, requires practice to attain proficiency.

But we need the novices. Few projects have the luxury of being staffed entirely by highly experienced people. And even if it is possible, is that what we want? Novices come in with fresh ideas, unencumbered by narrow viewpoints honed through years of experience. And they will eventually become the experts; lack of novices now means a dearth of experts in a few years.

Like everyone else, novices do the best they can. They try to learn from what they see. Unfortunately, this leads to cutting and pasting code, a maintenance nightmare. And where there is no guidance from existing code, their designs tend to be weak.

Therefore:

Separate generic from specific parts of problems. Use an expert, a framework designer to design generic parts. Let the novice programmers design the specific parts.

GenericsAndSpecifics is derived from SubsystemBySkill, and SubclassPerTeam. It is applicable to any technology, such as object orientation, that permits plug-in frameworks.

A framework can provide a generic solution to a problem, which can be completed, extended or tailored in the specific by subclassing. The generic solution, residing at the higher level of the class hierarchy, is considerably more difficult to design than any one specific solution. Once programmed, it is considerably quicker and easier to complete than the specific solutions would be to design.

Therefore, use the experts' extra skill to design a generic framework solution, and use the novices to use and tailor it for a specific solution. This fits well with the SubclassPerTeam principle, since the expert will be optimizing using slightly different concerns than the novice.

✥ ✥ ✥

Generics were used in all the OO systems. In a UI system, it was used for generic displays, search collection, transaction backout, and error handling. In the domain, it was used for generic transaction, error, persistence and model behavior. In the infrastructure, it was used for error handling and the persistence mechanism. In each case, novices were able to use the generic/specific structure to accomplish their tasks in less time, and keep to a more subtle architecture than they would have thought up.

This pattern was originally written by Alistair Cockburn, in SocialIssuesAndSoftwareArchitecture [BibRef-Cockburn1998].