{"id":2421,"date":"2016-06-08T11:08:36","date_gmt":"2016-06-08T11:08:36","guid":{"rendered":"http:\/\/www.codergears.com\/Blog\/?p=2421"},"modified":"2018-04-04T13:30:57","modified_gmt":"2018-04-04T13:30:57","slug":"people-who-influenced-the-programming-world-series-uncle-bob","status":"publish","type":"post","link":"https:\/\/codergears.com\/Blog\/?p=2421","title":{"rendered":"People who influenced the programming world series : Uncle Bob."},"content":{"rendered":"

Robert C. Martin, known as\u00a0\u00a0Uncle Bob has been a software professional since 1970 and an international software consultant since 1990. In the last 40 years, he has worked in various capacities on literally hundreds of software projects. In 2001, he initiated the meeting of the group that created Agile Software Development from Extreme Programming techniques and served as the first chairman of the Agile Alliance.\u00a0 He is also a leading member of the Worldwide Software Craftsmanship Movement – Clean Code.<\/p>\n

Uncle Bob \u00a0Contributions:<\/strong><\/p>\n

I- OOP Metrics:<\/strong><\/p>\n

In 1994 Robert \u201cUncle Bob\u201d Martin proposed a\u00a0group of object-oriented metrics that are popular until now. Those metrics, unlike other object-oriented ones don\u2019t represent the full set of attributes to assess individual object-oriented design, they only focus on the relationship between packages in the project.<\/p>\n

Robert C.Martin wrote an interesting\u00a0article<\/a>\u00a0about a set of metrics that can be used to measure the quality of an object-oriented design in terms of the interdependence between the subsystems of that design.<\/p>\n

Here\u2019s from the article what he said about the interdependence between modules:<\/p>\n

What is it that makes a design rigid, fragile and difficult to reuse. It is the interdependence of the subsystems within that design. A design is rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules. When the extent of that cascade of change cannot be predicted by the designers or maintainers the impact of the change cannot be estimated. This makes the cost of the change impossible to estimate. Managers, faced with such unpredictability, become reluctant to authorize changes. Thus the design becomes rigid.<\/p><\/blockquote>\n

<\/span>
\nAnd to fight the rigidity he introduce metrics like Afferent coupling, Efferent coupling, Abstractness and Instability.<\/p>\n

Afferent Coupling<\/strong><\/p>\n

The number of types outside this project that depend on types within this project.<\/p>\n

Efferent Coupling<\/strong><\/p>\n

The number of types outside this project used by types of this project.<\/p>\n

Abstractness<\/strong><\/p>\n

The ratio of the number of internal abstract types (i.e abstract classes and interfaces) to the number of internal types. The range for this metric is 0 to 1, with A=0 indicating a completely concrete project and A=1 indicating a completely abstract project<\/p>\n

A = Na \/ Nc<\/p>\n

Where:<\/p>\n

A = abstractness of a module
\nZero is a completely concrete module. One is a completely abstract module.
\nNa = number of abstract classes in the module.
\nNc = number of concrete classes in the module.<\/p><\/blockquote>\n

Instability<\/strong><\/p>\n

The ratio of efferent coupling (Ce) to total coupling. I = Ce \/ (Ce + Ca). This metric is an indicator of the project\u2019s resilience to change. The range for this metric is 0 to 1, with I=0 indicating a completely stable project and I=1 indicating a completely instable project.<\/p>\n

I = Ce\/(Ce + Ca)
\nI represent the degree of instability associated with a project.
\nCa represents the afferent coupling, or incoming dependencies, and
\nCe represents the efferent coupling, or outgoing dependencies<\/p><\/blockquote>\n

Abstractness vs Instability Graph and the zone of pain<\/strong><\/p>\n

To have more details about this graph you can refer to the\u00a0Robert C.Martin article<\/a>.<\/p>\n

Here\u2019s the graph generated by JArchitect <\/a>for the Neo4j framework<\/p>\n

\"AbstractnessVSInstability\"<\/a><\/p>\n

The idea behind this graph is that the more a code element of a program is popular, the more it should be abstract. Or in other words, avoid depending too much directly on implementations, depend on abstractions instead. By popular code element I mean a project (but the idea works also for packages and types) that is massively used by other projects of the program.
\nIt is not a good idea to have concrete types very popular in your code base. This provokes some Zones of Pains in your program, where changing the implementations can potentially affect a large portion of the program. And implementations are known to evolve more often than abstractions.<\/p>\n

The main sequence line (dotted) in the above diagram shows the how abstractness and instability should be balanced. A stable component would be positioned on the left. If you check the main sequence you can see that such a component should be very abstract to be near the desirable line \u2013 on the other hand, if its degree of abstraction is low, it is positioned in an area that is called the \u201czone of pain\u201d.<\/p>\n

For example neo4j kernel has many classes depending on it, so it\u2019s positioned on the left and in this case it\u2019s preferable to be more abstract to leave the orange zone and goes to the green zone.<\/p>\n

What\u2019s important is to avoid the zone of pain, if a jar is inside this zone, any changes to it will impact a lot of classes and it became hard to maintain or evolve this module.<\/p>\n

II- Open Source Projects<\/strong><\/p>\n

Uncle Bob worked in many open source projects, the most popular one is maybe Fitness<\/a>.<\/p>\n

FitNesse<\/span>\u00a0is a tool for specifying and verifying application acceptance criteria (requirements). It acts as a bridge between the different stakeholders (disciplines) in a software delivery process. It’s wiki server makes it easy to document the software.It’s testexecution capabilities allow you to verify the documentation against the software, ensuring the documentation remains up to date and the software is not facing regression.<\/p>\n

III- Books<\/strong><\/p>\n

Mr. Martin has authored and edited many books including:<\/p>\n