Principles of Agile Version Control: From OOD to TBD


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 first 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 (DIP) 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 or 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 sub-parts. This would translate into a version-control container assuming as little knowledge as possible about the content of other containers, including its own subparts.

DRY - Container Encapsulation

The DRY Principle would seem to translate directly to version control terminology: Each piece of version-control information should have a single unambiguous authoritative representation within the version-control system.

Interface Segregation - Promotion Leveling & Codeline Branching

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.