Reuse Release Equivalence Principle
Reuse Release Equivalence PrincipleREP:
This means that in order to effectively reuse code it must arrive in a complete, black-box, package that is to be used but not changed. Users of the code are shielded from changes to it because they can choose when to integrate changes from the package into their own code. While this supports code ownership, and even promotes it, it does not enforce it.
Why isn't this just called the '~BlackBoxPrinciple?'?
I've seen this approach fail many times when used within a single organization. Is this only appropriate for companies developing a product to be reused outside of their organization? -- JimLittle
I've a suspicion that the point is to make smaller packages with explicit dependencies. Rely on some automatic dependency checking system to ensure that your packages are consistent. For example, you could adopt a system like TCL, where each package has a tuple <name, major, minor, patch> and a version-checking function that ensures compatibility with stated requirements. The interface is simple: InstallPackage?(tuple) and NeedPackage?(dependent_name, known_good_tuple) should suffice. Make your packages small and coherent, use a globally consistent versioning system that knows where each version can be found, and you'll do just fine.
[Yes, even a code package (e.g., a library) used within an organization cannot be used across multiple projects unless it is "released" as a black box. To release it doesn't necessarily mean an involved procedure. But it does need to be treated as a separate package, separately tested and versioned, and tracked by version in the projects in which it's used.]
See ObjectOrientedSoftwareConstruction
EditText of this page
(last edited September 11, 2013)
or FindPage with title or text search