ü Readability (names, sizes, modularity, etc.) ü Dependency injection (use parameters), ü separation of concerns (patterns), ü Low Coupling (use, has, is, et al)
Write tests § Writing test cases drive to Single Responsibility (SRP), dependency injection (DI), and interfaces. § Writing test cases minimize coupling because tight coupling makes it difficult to write tests. § Refactoring: increase cohesion, decrease coupling, separate concerns, modularize, shrink functions and classes, choose better names, and so on. § Having tests eliminates the fear that cleaning up the code will break it.
Eliminate duplication § Duplication (LOC or methods) represents additional work, risk, and unnecessary complexity. § Use Inheritance à overloading § Common mistake: get our code working and then move on to the next problem. Take care of what you have created!
Ensure Expressiveness § The majority of the cost is in long-term maintenance. § It is critical to understand what the system does. § Select good names, keep items small, use patterns (observer, visitor, command, interpreter, mediator, decorator, adapter, singleton, factory, etc.). § Tests should also be expressive. § Common mistake: get our code working and then move on to the next problem. § Take care of what you have created!
Minimize the number of items § Do not end with a program that have too many tiny classes and methods. Keep classes and methods counts low. § Dogmatism vs Pragmatism. § This rule is lowest priority compared with the other principles and rules. But, it is a rule. Do not ignore it.
Definition § Cycled components can only be used together: they can only be tested, reused, deployed and understood together. § Every node on a cycle depends on any other.
Dependencies Principle § Avoid dependency cycles § Tangle. A subgraph with at least two nodes, where each node is reachable from each other. § Tangled metric. values greater zero indicate cyclic dependencies.
of a Package § Express the portion of contained abstract types. § It is a value 0 to 1: 0 (only concrete classes) to 1 (only interfaces and abstract classes)
of a Package § Indicates whether the package is mainly used by other artifacts (stable – hard to change) or if it mainly depends on other artifacts (instable – changeable). § It is a value 0 to 1: 0 only incoming dependencies to 1 (only outgoing dependencies)
of a Package § Indicates whether the package is mainly used by other artifacts (stable – hard to change) or if it mainly depends on other artifacts (instable – changeable). § It is a value 0 to 1: 0 only incoming dependencies to 1 (only outgoing dependencies)
Dependency Principle § Every dependency between modules should terminate on a module whose Instability metric is less than or equal to the depending module's Instability metric. § Every dependency between modules should terminate on a module whose Abstractness metric is greater than or equal to the depending module's Abstractness metric.
public class Foo { Bar b= new Bar(new Car()); public Foo (Car c) { c.doIt(b); } public void m (Delta d) { d.action(b); } } public class System { public ... main ( ...) { Foo f = new Foo(); //... } }
public class Foo { Bar b= new Bar(new Car()); public Foo (Car c) { c.doIt(b); } public void m (Delta d) { d.action(b); } } public class System { public ... main ( ...) { Foo f = new Foo(); //... } } • Tangled: • ISystem = • IFoo = • IBar • Afoo • Any candidate for “painful” zone:
1. Download and install STAN https://stan4j.com Stand alone or Eclipse plug-in 2. Review your “Robert C. Martin” metrics: Ca, Ce, I, A, D. 3. Review “Violations” report 4. Review “Distance” plot 5. Review Dependency / Composition Graph
javiergs
grapecity_dev
sters
sansuke05
takara9
masui_masanori
gernotstarke
hyodol2513
pirosikick
larsrh
lovee
joergneumann
lara
nonsquared
3n
wjessup
paulrobertlloyd
danielanewman
gr2m
marktimemedia
samlambert
bkeepers
addyosmani
jnunemaker
