of object-oriented design.
Principles of Object-Oriented Design
The principles of object-oriented design [1] 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. Classes, interfaces and packages are the logical containers of software functionality. These logical entitities are realized in “physical” containers of version control (configuration elements) in the form of files, libraries and components, and are as follows:
| Principles of Class Design | ||
|---|---|---|
|
SRP |
A class should have one, and only one, reason to change. |
|
|
OCP |
A class should be open for extension (of its behavior) but closed against modification (of its contents). |
|
|
LSP |
Derived classes must be substitutable for (require no more, and ensure no less than) their base classes. |
|
|
DIP |
Depend on abstract interfaces, not on concrete details. |
|
|
ISP |
Make fine grained interfaces that are client specific. |
|
|
LOD |
The Law Of Demeter |
Objects and their methods should assume as little as possible about the structure or properties of other objects (including its own subcomponents). [3] |
|
DRY |
Every piece of knowledge should have one authoritative, unambiguous representation within the system. [4] |
|
| Principles of Package Design | ||
|
REP |
The granule of reuse is the granule of release. |
|
|
CCP |
Classes that change together are packaged together. |
|
|
CRP |
Classes that are used together are packaged together. |
|
| Principles of Package Coupling | ||
|
ADP |
The dependency graph of packages shall contain no cycles. |
|
|
SDP |
Depend in the direction of stability. |
|
|
SAP |
Abstractness increases with stability. |
|
We wish to derive similar principles for version control using the logical containers of change-based versioning and task-based development:
- Changes
- Workspaces (sandboxes)
- Versions (labels/tags)
- Configurations (builds & baselines)
- Streams (codelines)
The resulting version control principles should address the need to minimize the complexity and impact of change by minimizing dependencies through the use of loosely coupled and highly cohesive, correct and consistent changes, versions and codelines. We must be very mindful of the notion of time when deriving these principles in order to properly and accurately translate their meaning from the domain of classes and packages to the domain of version control.
In addition to terms like “classes” and “packages”, we will also need to translate the meaning of terms like “abstract,” “interface” and “stability” into the domain of version control:
- Classes & packages might correspond to any of the aforementioned types of entities (changes, workspaces, versions, configurations, codelines). An instance of a particular class is an "object." And each object has its own behavior, state (its data or contents) and unique identity. Our version control objects are "containers" that have their own state, contents and unique identifier. Previously published notions of container-based/component-based SCM are a precedent for this frame of thinking (see [5]-[8]).
- An “ interface” might be some set of identifying characteristics or acceptance criteria that is common to a set of items (e.g., instances of configurations), or to a particular state of an item.
- Abstraction/Abstractness is somewhat different from the above. The more broadly "used" a container is, the more it serves as basis for subsequent ongoing evolution (just as the more "abstract" a class is, the more it serves as a basis for subsequent derivation). This relates to the “liveness” or "velocity" of the flow of change/activity for an item's contents. A
About the author
Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.
About the author
Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.
