{"id":16,"date":"2014-07-22T12:17:29","date_gmt":"2014-07-22T12:17:29","guid":{"rendered":"http:\/\/www.codergears.com\/Blog\/?p=16"},"modified":"2015-09-04T23:23:31","modified_gmt":"2015-09-04T23:23:31","slug":"spring-the-art-of-using-grasp-patterns","status":"publish","type":"post","link":"https:\/\/codergears.com\/Blog\/?p=16","title":{"rendered":"Learn some basic design principles from GRASP: Spring case study."},"content":{"rendered":"

A design pattern is\u00a0a general reusable solution to a commonly occurring problem within a given context in software design. Patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.<\/p>\n

\u201cGang of Four\u201d patterns are maybe the most popular ones. However, there are some basic design principles not well-known by developers, it’s the\u00a0General Responsibility Assignment Software Principles, abbreviated\u00a0GRASP<\/a>.<\/p>\n

GRASP consists of guidelines for assigning responsibility to classes and objects in object-oriented design. In this article we will discover the use of \u00a0these principles in the Spring framework.<\/p>\n

Spring<\/a> is one of the most popular application development framework for enterprise Java.
\nThe Spring Framework does not impose any specific programming model, it has become popular in the Java community as an alternative to, replacement for, or even addition to the Enterprise JavaBean (EJB) model.<\/p>\n

Spring makes things easy for software designers, it gives them a good basis to have a well-designed projects. But what about Spring itself it\u2019s well designed as well?
\nTo try answering this question let\u2019s X-Ray some Spring jars with JArchitect\u00a0<\/a>and discover some of its\u00a0design facts.<\/span><\/p>\n

After the analysis here\u2019s the dependency graph between all Spring jars analyzed:<\/p>\n

\"\"<\/p>\n

The Matrix view<\/a> gives us more details about the dependency weight between these jars.<\/p>\n

\"\"<\/p>\n

GRASP Principles<\/h2>\n

Coupling<\/h2>\n

The loose coupling is desirable because a change in one area of an application will require less changes throughout the entire application. In the long run, this could alleviate a lot of time, effort, and cost associated with modifying and adding new features to an application.<\/p>\n

Using interfaces and abstract classes can improve the loose coupling and we can evaluate the abstractness of a defined module by the following metric:<\/p>\n

A = Na \/ Nc\r\nWhere:\r\n* A = abstractness of a module\r\nZero is a completely concrete module. One is a completely abstract module.\r\n* Na = number of abstract classes in the module.\r\n* Nc = number of concrete classes in the module.\r\n<\/pre>\n
Here\u2019s the abstractness of all Spring jars analyzed:<\/p>\n
\"\"<\/p>\n
Let\u2019s discover all interfaces of the jars analyzed, for that we can execute the following query:<\/p>\n
SELECT TYPES WHERE<\/span> IsInterface<\/p><\/blockquote>\n
\"\"<\/p>\n
With a good abstractness ratio, and many interfaces used we can say that Spring enforces low coupling, what\u00a0makes it very flexible.<\/p>\n
High cohesion<\/strong><\/h4>\n
The single responsibility principle states that a class should not have more than one reason to change. Such a class is said to be cohesive. A high LCOM value generally pinpoints a poorly cohesive class. There are several LCOM metrics. The LCOM takes its values in the range [0-1]. The LCOM HS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. A LCOM HS value highest than 1 should be considered alarming. Here are algorithms used to compute LCOM metrics:<\/p>\n