Principles of Agile Version Control: From Object-oriented Design to Project-oriented Branching


In this article, the authors explore translation of object-oriented design principles to codelines, branching, and promotion. In addition, they expand on the concept of moving from task-based development (TBD) to project-oriented branching (POB).

 Last month we looked at several principles of object-oriented design and tried to translate them into principles of version-control for task-based development with workspaces, changes, and baselines. This month we extend our translation efforts from OOD principles to codelines, branching, and promotion. The result is that we expand our scope from task-based development to project-oriented branching.

Principles of Object-Oriented Design

The principles of object-oriented design (OOD) address the need to minimize the complexity and impact of change by minimizing dependencies through the use of loosely coupled and highly cohesive classes, interfaces, and packages. These are the logical containers of software functionality. These logical entities are realized in physical containers of version control (configuration elements) in the form of files, libraries, components, and are as follows: 

Principles of Class Design


The Single Responsibility Principle

A class should have one, and only one, reason to change.


The Open-Closed Principle

A class should be open for extension (of its behavior) but closed against modification (of its contents).


The Liskov Substitution Principle

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


The Dependency Inversion Principle

Depend on abstract interfaces, not on concrete details.


The Interface Segregation Principle

Make fine grained interfaces that are client specific.


The Law Of Demeter
(Principle of Least Assumed Knowledge)

Objects and their methods should assume as little as possible about the structure or properties of other objects (including its own subcomponents).


The DRY Principle

Don't Repeat Yourself! Every piece of knowledge should have one authoritative, unambiguous representation within the system

Principles of Package Design


The Release Reuse Equivalency Principle

The granule of reuse is the granule of release.


The Common Closure Principle

Classes that change together are packaged together.


The Common Reuse Principle

Classes that are used together are packaged together.

Principles of Package Coupling


The Acyclic Dependencies Principle

The dependency graph of packages shall contain no cycles.


The Stable Dependencies Principle

Depend in the direction of stability.


The Stable Abstractions Principle

Abstractness increases with stability.


About the author

About the author

CMCrossroads is a TechWell community.

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