Announcement Announcement Module
Collapse
No announcement yet.
Static methods for business services Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Static methods for business services

    We are currently in the design phase of our new project. Personally I like the spring approach of interface based design. But I could not convince my lead architect about using interfaces (afterwards I can talk about using spring) and he thinks it is a overkill. His view is to keep it simple and to have static methods for business methods like saveCustomer, getCustomers, saveContacts. He prefers static methods for data access and all over the project.
    Is there any obvious disadvantages of using static methods for business services? When do we need to go for interfaces?

  • #2
    are you sure they are business methods and not persistence ones?

    Comment


    • #3
      Static methods do not lend to inheritance. So you would not be able to use the power of OOP at all.

      Comment


      • #4
        Ease in Unit Testing

        Hi surya,

        Well one thing you gain is ease in testing. If you have a manager class that relies on some database service method, such as saveCustomer, then you want to test the manager class in isolation. For instance, assume the following:

        Code:
        public class UserManagerImpl implements UserManager {
        
          public saveUser(String username, String emailAddress) throws UserCreationException {
             User user = new User();
             user.setUsername(username);
             user.setEmailAddress(emailAddress);
             
             // static method call
             try {
               UserDao.saveUser(user);
             } catch (Exception e) {
               throw new UserCreationException("Could not create user: " + user);
             }
        
          }
        
        }
        In this case, you cannot (easily) write a unit test to ensure that the UserManager implementation class behaves as specified.

        Now if you do use interface design and instead depend only on the UserDao interface:

        Code:
        public class UserManagerImpl implements UserManager {
        
          private UserDao userDao;
        
          public void setUserDao(UserDao userDao) {
            this.userDao = userDao;
          }
        
          public saveUser(String username, String emailAddress) throws UserCreationException {
             User user = new User();
             user.setUsername(username);
             user.setEmailAddress(emailAddress);
             
             try {
               this.userDao.saveUser(user);
             } catch (Exception e) {
               throw new UserCreationException("Could not create user: " + user);
             }
        
          }
        
        }
        Now you can write mock implementations of the UserDao interface for testing purposes, so that you can concentrate on making sure the manager class behaves correctly. For instance, you could write a test to ensure that when an exception is thrown during the save operation, the UserManager implementation correctly throws a UserCreationException. You could also hard-code your mock implementations to return data so that you do not rely on your database (which would be more of an integration test than a unit test).

        Of course there are other advantages as well!

        -Arthur Loder

        Comment


        • #5
          [are you sure they are business methods and not persistence ones?]
          Yes these are all business methods. I will you a better method as example, like completeCustomerEntry(). This method does whole bunch of things like creating tasks, running rules and validations etc.,.

          Comment


          • #6
            The downside of static business methods is that you are limited to exactly one implementation of your business object per JVM. With an interface and non-static implementation, you have the opportunity to create several objects which uses the same business class but is initialized with different implementations of its collaborators (like DAOs). Perhaps that isn't an issue... until it is. And you are stuck creating hacks and duplicating code. Keeping it too simple can make modifying the system later more complicated than if you had used more interfaces.

            One of the nice things I like about interfaces is they give you a solid idea of what the service methods are which are seperate from the implementation methods. This is probably most important for Spring based objects because your implementations often have public setters for easier configuration.

            But I've seen non-Spring situations where not using interfaces creates a lot of confusion about what is part of the service interface and what is the implementation.

            Plus interface based non-static objects allow for easier unit testing. If an object has a collaborator is which is an interface, you can just mock it for the unit test.

            If unit testing isn't a concern of your architect, then I believe you will have a tough time convincing him that interfaces will be better. Because without unit tests most code has one and only one use until it doesn't. And by then its too late. But with unit tests (and integration tests as well) it shows the value of being to mock objects right at the beginning because the code has at least two uses: production and unit/integration testing.

            Take a look at the Spring jpetstore sample. One of the things I was really impressed about that sample is how it exposed 4 methods of remotely accessing the main service object and how trivial it was for the client code to access the service through each one of those methods. It was almost complete a matter of configuration (there was one other server side class because JaxRpc requires some sort of wrapper around the business object like EJB does). Interfaces made such flexibility possible.

            If you use static methods, I think the only AOP you can use is AspectJ which is overkill for simple things like tracing, transactions, caching, etc.

            In my opinion static methods are good for utility classes which represent algorithms that only operate on the arguments they are passed. But as soon as you have some sort of local resources (ie data access) then static implementations are too limiting. You can fix that with some sort of service locator to vary the implementation. But then the use of a service locator becomes an implementation detail. Where in a non-static object situation where you use dependency injection instead of service locator; which implementation used is a matter of configuration, and your actual objects don't know the difference. They could be proxies making remote calls or local objects or even some services wrapped in a cache.

            It does create more complexity. And it looks like overkill until you need the flexibility a more flexible approach affords you.

            Comment


            • #7
              Originally posted by sabarish
              Static methods do not lend to inheritance. So you would not be able to use the power of OOP at all.
              Good point.
              Thanks Sabarish.

              Comment


              • #8
                Thanks Arthur.

                I fully agree that one of the important advantage of using interface based design is ease of unit test.

                Thanks for the detailed explanation.

                Comment


                • #9
                  Originally posted by wpoitras
                  The downside of static business methods is that you are limited to exactly one implementation of your business object per JVM. Keeping it too simple can make modifying the system later more complicated than if you had used more interfaces.
                  ....
                  Plus interface based non-static objects allow for easier unit testing. If an object has a collaborator is which is an interface, you can just mock it for the unit test.

                  If unit testing isn't a concern of your architect, then I believe you will have a tough time convincing him that interfaces will be better. ... But with unit tests (and integration tests as well) it shows the value of being to mock objects right at the beginning because the code has at least two uses: production and unit/integration testing.

                  If you use static methods, I think the only AOP you can use is AspectJ which is overkill for simple things like tracing, transactions, caching, etc.
                  ... But then the use of a service locator becomes an implementation detail. Where in a non-static object situation where you use dependency injection instead of service locator; which implementation used is a matter of configuration, and your actual objects don't know the difference. .

                  Well said wpoitras.
                  I will use these points and try convincing my architect about using interfaces. Will keep you posted.
                  Thanks

                  Comment

                  Working...
                  X