Principles of Agile Version Control: From OOD to TBD

the things that changed should have been very closely-related. This an extremely generic statement and would probably be a lot easier to understand if we broke it down by the various kinds of containers to which it may apply. We'll do that later, for now, let's press onward.

Open-Closed ~ Identity Preservation

The Open-Closed Principle for OOD says that a class should be “open for extension, but closed for modification.” Translating this into version-control terms is a little bit tricky. "Extension" corresponds to deriving or evolving a new entity from an existing entity. If we add to the existing entity we create a new one that reuses the essential characteristics of the original. But I shouldnt have to modify the original entity in order to do it? What does that mean?

The original entity or container corresponded to a particular meaning at a certain point in time. Evolving it into a new "thing" shouldnt destroy the existence or history of what it evolved from. The evolved result may be "new", but this is version control, and the "thing" that evolved must somehow maintain its "identity" or "essence." This is a statement about Identity Preservation :

A container should be open for evolution, but closed against redefinition.

What does this mean? We'll, say more about that later too. Onward again!

Liskov Substitution ~ Evolution Integrity

The Liskov-Substitution Principle for OOD says that “derived classes should be substitutable for their base classes.” In this context, “substitutable” means “requires no stronger pre-conditions, and ensures no weaker post-conditions.” In version-control terms this means that:

Derived containers must be substitutable for (require no more, and ensure no less than) their base containers.

This is a statement of Evolution Integrity , but we need to determine what a "derived container" is. Within the flow of a codeline, the current configuration is "derived from" it's predecessor configuration, as suggested by Anne Mette Hass in [9]. A derived container might also mean a branch, which "inherits" it's initial content from its branchpoint.

Dependency Inversion ~ Container-based Dependency

The Dependency Inversion Principle for OOD says to “depend upon abstractions, not concretions” or equivalently “abstractions should not depend upon details; details should depend upon abstractions.” This is a statement about separating policy from mechanism to depend in the direction of increasing abstraction (or decreasing detail).

In the case of "abstraction", a version control "abstraction" might be a baseline or a codeline, which abstracts and encapsulates a single or “current” configuration from the details of its content. A “detail” would be a detail about the composition (content) of the configuration, or of a particular change. So DIP would mean we should depend upon a specific codeline or labeled configuration, and not upon their specific contents or context. This gives us:

Depend upon named containers, not upon their specific contents or context.

This is the version control equivalent of saying "program to an interface, not to an implementation." It is closely related to the Principle of Least Assumed Knowledge or "Law of Demeter."

Least Assumed Knowledge ~ Evolution Insulation

The Law of Demeter is not one of the principles from [1]. It is actually a separate "principle" that is really more of a style rule for "structure shyness" in object-oriented programming. In its more general form, it simply says that objects should assume as little knowledge as possible about the structure and data/attributes of other objects (including of its own subparts). This would translate into something like:

A version-control container should assume as little knowledge as possible about the content of other containers (including its own subparts).

DRY ~ Container