Assemblies that don't satisfy the Abstractness/Instability principle
The Abstractness versus Instability Diagram identifies assemblies potentially painful to maintain (concrete and stable) and potentially useless (abstract and instable).
- Abstractness: many abstract types (interfaces, abstract classes), few concrete ones.
- Stability: types used by many types from other assemblies (painful to modify).
The normalized distance ([0.0 … 1.0]) from the idealized line A + I = 1 (main sequence) indicates the abstractness/stability balance; this rule warns above 0.7. Metric explained here: https://www.ndepend.com/docs/code-metrics#DitFromMainSeq Concepts introduced by Robert C. Martin in 1994: http://www.objectmentor.com/resources/articles/oodmetrc.pdf
- Abstractness: many abstract types (interfaces, abstract classes), few concrete ones.
- Stability: types used by many types from other assemblies (painful to modify).
The normalized distance ([0.0 … 1.0]) from the idealized line A + I = 1 (main sequence) indicates the abstractness/stability balance; this rule warns above 0.7. Metric explained here: https://www.ndepend.com/docs/code-metrics#DitFromMainSeq Concepts introduced by Robert C. Martin in 1994: http://www.objectmentor.com/resources/articles/oodmetrc.pdf
How to fix
The assembly is either potentially painful to maintain (massively used, mostly concrete: create abstractions to reduce coupling with concrete implementations) or potentially useless (mostly abstract, not used enough: review the design).
Severity is Low: this principle informs about code structure but is not actionable. Fixing actionable Architecture and Code Smells issues will push the scores in the right direction.
Severity is Low: this principle informs about code structure but is not actionable. Fixing actionable Architecture and Code Smells issues will push the scores in the right direction.
CQLinq source
This rule is written in CQLinq, C# LINQ over the NDepend code model. It ships with every new NDepend project: you can read it, adapt it, or use it as a starting point for your own custom rules.
// <Name>Assemblies that don't satisfy the Abstractness/Instability principle</Name>
// <Id>ND1407:AssembliesThatDontSatisfyTheAbstractnessInstabilityPrinciple</Id>
warnif count > 0 from a in Application.Assemblies
where a.NormDistFromMainSeq > 0.7
orderby a.NormDistFromMainSeq descending
select new {
a,
a.NormDistFromMainSeq,
Debt = 10.ToMinutes().ToDebt(),
Severity = Severity.Low
}
//<Expl>
// The *{0}* has a *Normalized Distance from the Main Sequence* metric equals to {1}.
// To understand this metric, its implications, and the necessary corrective actions,
// please read this rule description.
//</Expl>
//<Desc>
// The **Abstractness versus Instability Diagram** identifies assemblies
// **potentially painful to maintain** (concrete and stable) and
// **potentially useless** (abstract and instable).
//
// - **Abstractness**: many abstract types (interfaces, abstract classes),
// few concrete ones.
//
// - **Stability**: types used by many types from other assemblies (*painful
// to modify*).
//
// The *normalized distance* ([0.0 … 1.0]) from the idealized line
// **A + I = 1** (*main sequence*) indicates the abstractness/stability
// balance; this rule warns above 0.7. Metric explained here:
// https://www.ndepend.com/docs/code-metrics#DitFromMainSeq
// Concepts introduced by *Robert C. Martin* in 1994:
// http://www.objectmentor.com/resources/articles/oodmetrc.pdf
//</Desc>
//<HowToFix>
// The assembly is either *potentially painful to maintain* (massively used,
// mostly concrete: create abstractions to reduce coupling with concrete
// implementations) or *potentially useless* (mostly abstract, not used
// enough: review the design).
//
// Severity is **Low**: this principle informs about code structure but
// **is not actionable**. Fixing actionable **Architecture** and
// **Code Smells** issues will push the scores in the right direction.
//</HowToFix>
Open in the interactive Rules Explorer · All default rules
Architecture: all 13 items
- Avoid namespaces mutually dependent ND1400
- Avoid namespaces dependency cycles ND1401
- Avoid partitioning the code base through many small library Assemblies ND1402
- Enforcing Clean Architecture ND1412
- UI layer shouldn't use directly DB types ND1403
- UI layer shouldn't use directly DAL layer ND1404
- Assemblies with poor cohesion (RelationalCohesion) ND1405
- Namespaces with poor cohesion (RelationalCohesion) ND1406
- Assemblies that don't satisfy the Abstractness/Instability principle ND1407
- Avoid excessive class coupling ND1410
- Higher cohesion - lower coupling ND1408
- Avoid mutually-dependent types ND1409
- Example of custom rule to check for dependency ND9900