Home > Projects Analysis > Spring: The art of using GRASP Patterns

Spring: The art of using GRASP Patterns

When we search for design pattern articles, we found essentially documentation concerning “Gang of Four” patterns, they are very useful and contribute to well design application.

But when I discovered GRASP principles , I advise anyone interested to improve his skills design to look at these principles, it gives a design fundamental rules.

In this article we will discover some GRASP principles used by Spring, and the advantages of using them.

Spring is one of the most popular application development framework for entreprise Java.
The 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.

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’s well designed also?
To try answering this question let’s X-Ray some Spring jars with JArchitect and discover some designs facts.

After analysis here’s the dependency graph between all jars analyzed:


And the Matrix view gives us more details about the dependency weight between these jars.


GRASP principles


Low 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.

Using interfaces and abstract classes can improve the low coupling and we can evaluate the abstractness of a defined module by the following metric:

A = Na / Nc


* A = abstractness of a module
Zero is a completely concrete module. One is a completely abstract module.
* Na = number of abstract classes in the module.
* Nc = number of concrete classes in the module.

Here’s the abstractness of all Spring jars analyzed:

Let’s discover all interfaces of jars analyzed, for that we execute the following request:


And to have a better idea of Spring interfaces, the treemap view give us an alternative way to see visually the code elements concerned by a request.

Having a lot of interfaces is not sufficient to be sure that low coupling is enforced, the question is these interfaces are used? For that let’s search for the most used types inside Spring:

All most used types are Class utilities, exceptions or interfaces, and when it concerns a logic layer the interface is used.

With a good abstractness ratio, and many interfaces used we can say that Spring enforce low coupling, that’s make it very flexible.


When we use interfaces, one interesting question is: who is responsible of creating concrete implementations? Spring provides a good solution using dependency injection, but it’s not the way used inside Spring itself.

Spring use Factories to do this job, and as you can see it contains many factory classes:

High cohesion

The single responsibility principle states that a class should have one, and only 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 LCOMHS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. Note that the LCOMHS metric is often considered as more efficient to detect non-cohesive types.

LCOMHS value higher than 1 should be considered alarming.

SELECT TYPES WHERE LCOMHS > 0.95 AND NbFields > 10 AND NbMethods >10

Only 4 classes are considered as no cohesive.

Information Expert
Information Expert is a principle used to determine where to delegate responsibilities. These responsibilities include methods, computed fields and so on.
Using the principle of Information Expert a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored.

The Efferent Coupling metric can be an interesting metric to evaluate if some types are more responsibilities, and if they are candidate to be refactored.

The Efferent Coupling for a particular type is the number of types it directly depends on.


These types have a high efferent coupling, and maybe there are candidate to refactoring.


According to Polymorphism, responsibility of defining the variation of behaviors based on type is assigned to the types for which this variation happens. This is achieved using polymorphic operations.

Let’s search for all polymorph methods, for that we can execute the following CQL request:


The treemap view gives us a good idea of using polymorphism inside Spring:

Protected Variations

The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

The “Abstractness vs Instability” graph can be useful to detect projects that will be difficult to change.
This following post describe the utility of this graph and how to exploit it to improve the design.

Almost all jars are inside green zone, it’s a good point when changes are needed for maintenance or evolution.


Spring use all GRASP principles, that makes it simple to understand and maintain, and developers can learn many things when discovering and analyzing Spring source code.

So give a look inside the source and enjoy with all design best practices implemented.

About these ads
Categories: Projects Analysis
  1. October 29, 2011 at 1:33 pm | #1

    Hello author…

    Very good article and great work in analyzing spring using the JDepends plugin and very useful conclusions indeed.

    Personally, if you could change the word “pattern” with “principle” in the following two statements….that would clear up a lot of confusion for a lot of the readers….

    “But when I discovered GRASP patterns , I advice any one interested to improve his skills design to look at these patterns, it gives a design fundamental rules.

    In this article we will discover some GRASP patterns used by Spring, and the advantages of using them.”

    • October 29, 2011 at 3:02 pm | #2

      Thanks for your feedback, and you are right it’s better to talk about principles than patterns.
      just one remark Spring was analyzed by JavaDepend and not with JDepends :)

      • October 30, 2011 at 2:07 pm | #3

        sorry…i meant to write JavaDepend…..thanks…anil

  2. Rob
    November 3, 2011 at 11:53 am | #4

    Hi there,

    nice article, very interesting. The link to JavaDepend is broken, maybe you should fix that :)


  3. November 3, 2011 at 1:14 pm | #6


    This was a very interesting article, especially all of the concrete metrics and the nice screen shots from JavaDepend. I wasn’t familiar with GRASP to begin with and had to do a Google search to get to the Wikipedia on it.

    All in all, it was awesome enough for me to write a short summary and link to you on my blog, Hacker’s Valhalla (http://bit.ly/tQ6Tam).

    Thanks for writing it,
    Michael Gower

    • November 3, 2011 at 1:32 pm | #7

      Thanks for your feedback, I just add a link to GRASP wiki page.

  4. November 5, 2011 at 3:08 pm | #8

    nice one, very interesting.

  5. November 14, 2011 at 1:49 pm | #9

    Need one fix: Definition of SRP is wrong in ‘High cohesion’ para.

    • November 14, 2011 at 1:55 pm | #10

      This is the definition that I got from wikipedia http://en.wikipedia.org/wiki/Single_responsibility_principle.
      And here’s the definition of SPR by Martin:
      “Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change.”

      • November 14, 2011 at 3:59 pm | #11


        Let me quote SRP from “High cohesion” para:
        “The single responsibility principle states that a class should have more than one reason to change.”

        I think you want to say like this:
        “The single responsibility principle states that a class should *NEVER* have more than one reason to change.”

      • November 14, 2011 at 4:44 pm | #12

        Yes Sure :) I modified it, Thanks for your feedback.

  6. Ranajit
    November 14, 2011 at 5:35 pm | #13

    Very good Insight. Thank you for sharing.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: