Decision to use the Spring Framework

[benethridge]

Hi, Arthur.

Yeah, 90% is probably too high. It's just that most things I've personally seen done with FILE-BASED DI/Ioc are not all that profound, and down-side to the file-based (xml-based) is, kind of to tatvamasi's point, it's "data-driven", which is to say, you lose the protection of the compiler, a protection which is vastly under-rated in my opinion.

However, I'm relatively new to Spring, so I'm keeping an open mind about file-based DI/Ioc. I'm fully on-board now with what I'll call "code-based" DI/Ioc. I discussed this a while back under this thread:

http://forum.springframework.org/showthread.php?t=24569

...but it all really boils down to a few ancient fundamentals of programming:

(1) Encapsulate and hide the details from the caller, so that the called functionality is an "abstraction" to you, i.e. you can use the functionality as a black-box...at least until it breaks on you ...and then heaven help you if you can't reasonably debug into it or find someone who can (like, say, the Interface21 folks ...and...

(2) Never write the same chunk of code in more than one place, and

(3) Separate the things that change from the things that stay the same.

Note that (3) often involves predicting what you think MIGHT change, and every time you are wrong, there is a price to be paid for your unnecessary "code flexibility".

By the way, high-level, (1) and (2) are why I say that in some ways, we've gone backwards from the 80's. Neither our "modern" languages (C#, Java, VB) nor our operating systems allow us to reasonably do either.

Open-source, such as Spring, is, however, a step in the right direction, given the limitations of the language it's written in. At least, it's giving us a framework in which to do (1), (2) and (3).

Ben

[tatvamasi]

Hi Ben,

I agree on some of your points. I guess it is true that some people go crazy coding to interfaces and using dependency injection, but then don't take advantage of it because 1) they don't write mocks of the implementations for unit tests and 2) they don't every end up swapping in different implementations during the application lifecycle (or if they do, it's part of a major overhaul and preserving the code dependent on the interface doesn't happen).

The problem is not of coding DI, the problem is people misunderstanding DI, thinking DI is all about which component depends on which component instead of thinking which component depends on which "service" (be it J2EE resource or propritory service). Don't you think people pushed spring DI little too much and started using it as instantiation framework?

However, I disagree with your following quote in reference to situations in which you do want to use some form of IoC:That is one thing I have found great about Spring. Once you learn the Spring dependency injection way of doing things, coding to interfaces become so easy.

"coding to interfaces" that is a broad term to apply to only JUnit tests. You don't code to interface if you don't need the power of interface. it is a "good practice" but it is not the best practice.

I can honestly say that as a coder, I am too impatient to write a factory and read some properties file to serve this purpose. With Spring, I code to interfaces without even thinking about it, because it doesn't require much additional work.

sure it doesn't require much of additional work but it does require hell LOT OF work to train a new hire (given new hire doesn't have knoledge of THE Framework). However I do feel, having a factory in my codebase would allow anyone to read code more easily and effectively. Even people without proper knowledge of design patterns would be able to go through code easily(provided they have to good knowledge of java/j2ee and/or OO fundamentals).

[Arthur Loder]

Hi tatvamasi,

"coding to interfaces" that is a broad term to apply to only JUnit tests. You don't code to interface if you don't need the power of interface. it is a "good practice" but it is not the best practice.

I agree that coding to interfaces isn't done solely for unit testing purposes. I guess what I was saying was that I agree with Ben in that using Spring's IoC support blindly and without taking advantage of some of the perks that come with using it (e.g. ease in unit testing, which is only one example) can result in a lot of time spent for an inexperienced team, without reaping the benefits. Ben was correct: a different strategy implementation may never be swapped in during the application's lifetime.

My real point was that personally, if the decision to use some form of IoC was already decided, I would prefer to use Spring's dependency injection mechanism rather than write my own dependency pull via factory classes. I agree with you on one point: even though there is more code to write with the dependency pull way, it can be easier to understand for a developer new to Spring; I just think it is worth the effort of teaching him/her Spring.

-Arthur Loder

[tatvamasi]

I have used spring framework for my persistence in past. I think its hot in market why not use it, doesn't hurt to bump up my price by having that on my resume anyways(seriously).

[madtree]

The problem is not of coding DI, the problem is people misunderstanding DI, thinking DI is all about which component depends on which component instead of thinking which component depends on which "service" (be it J2EE resource or propritory service). Don't you think people pushed spring DI little too much and started using it as instantiation framework?

"coding to interfaces" that is a broad term to apply to only JUnit tests. You don't code to interface if you don't need the power of interface. it is a "good practice" but it is not the best practice.
sure it doesn't require much of additional work but it does require hell LOT OF work to train a new hire (given new hire doesn't have knoledge of THE Framework). However I do feel, having a factory in my codebase would allow anyone to read code more easily and effectively. Even people without proper knowledge of design patterns would be able to go through code easily(provided they have to good knowledge of java/j2ee and/or OO fundamentals).

First of all, programming to interfaces is really important because it is how you can achieve polymorphism in a statically typed language, which is one of the main tenet of OO. If you don't use polymorphism, you might consider using a procedural language instead of Java.

The problem when you program to interfaces, is how do you get the correct interface implementation without getting your code coupled to it. Not to mention the complexity involved in creating objects (initialization of his dependencies, state management, cache, ...). This is usually where factories come in. In fact, factories are so important that acccording to the very popular "Domain Driven Design" book, they are an integral part of any domain model and any applications will have several of them (I know it used to be my case). The problem is that writting factories is most of the time a time consuming redudant and somehow complex task. This is where DI comes to help you.

DI allows you to code to interfaces at basically no cost. You just need to add a little snippet of xml and tada you get the implementation injected for you. No need to code anymore lot of ad hoc factories (or evil singletons) using proprietary config files. Plus you don't need to think about how to store the objects instances, to manage their states, ... The creation code which can be quite complex ends up totally separated from your core business logic. The DI container take care of those details for you. DI is in fact a very nice creational design pattern removing most of the need for custom factories and promoting a very neat separation of concerns (separating objet creation logic from business logic).

Also don't overlook the fact that a componenent model à la Spring or EJB gives you the possibility to make your objects available easily to almost any protocol (rmi, web services, jmx, you name them, ...). It also allows you to decorate them transparently with infrastructural services (it can also be achieved using an AOP compiler).

[seabludude]

Well said, madtree.

In fact, Spring IoC is a big factory. It does more than instantiation, it also provides configuration, decoration and assembly, as described by Interface21.

[tatvamasi]

First of all, programming to interfaces is really important because it is how you can achieve polymorphism in a statically typed language, which is one of the main tenet of OO. If you don't use polymorphism, you might consider using a procedural language instead of Java.

Isn't that exactly what I said in my previous post? If I am not writing decoupled code, java or other OO technologies would not be my choice to solve the problem.

The problem when you program to interfaces, is how do you get the correct interface implementation without getting your code coupled to it. Not to mention the complexity involved in creating objects (initialization of his dependencies, state management, cache, ...).

Thank you, exactly my point, you don't code to interface if you don't need the power of it. specially if you are coding to interfaces just because you can mock the classes for your JUnit test.

This is usually where factories come in. In fact, factories are so important that acccording to the very popular "Domain Driven Design" book, they are an integral part of any domain model and any applications will have several of them (I know it used to be my case). The problem is that writting factories is most of the time a time consuming redudant and somehow complex task. This is where DI comes to help you.

I am not sure why you would say writing factory is somewhat a complex task. And I would not call it redundant though. May be how you store/create objects for a factory to return sure can be subjective.

DI allows you to code to interfaces at basically no cost. You just need to add a little snippet of xml and tada you get the implementation injected for you. No need to code anymore lot of ad hoc factories (or evil singletons) using proprietary config files. Plus you don't need to think about how to store the objects instances, to manage their states, ...

I can and have see/n people misuse singleton. but give me one good reason to call it evil.

The creation code which can be quite complex ends up totally separated from your core business logic. The DI container take care of those details for you. DI is in fact a very nice creational design pattern removing most of the need for custom factories and promoting a very neat separation of concerns (separating objet creation logic from business logic).

Are you saying people do implement their business logic into their factories? Humm, I sure am missing something. Well lets see, If I use a ServiceLocator that basically looks up a service for me and returns "interface" to calling object(not to mention classes that creates appropriate object). I have few extra classes in my codebase. If I use DI i have a configuration file(not to mention third party lib that operates on config and classes). pretty close, both have atleast few extra files. java code V/S configuration and third party lib. now when DI container loads object configuration I would assume it drops hooks on classes to make sure when they are instentiated the setter injection must be called for one or more services. and if you use service locator when object is instentiated don't do anything untill you need service. Now how service locator creates object is a different story altogether. Well I think I'll allow my JVM to have more free heap space regardless of whether all of my methods would need one or more services or not.

One thing I like to make clear, I am not out to bash spring framework so don't give me how spring is the best on the block, I already know that. I also know how clean my code looks with spring. I also know how it makes my code more unit testable. Not to mention other benefits of it.

[dejanp]

Thank you, exactly my point, you don't code to interface if you don't need the power of it. specially if you are coding to interfaces just because you can mock the classes for your JUnit test.

The power of interface is not only in the modeling/design decoupling it allows, but in proxies you can create over them (yes, I know, you can create class proxies with cglib, but my experiences with that are not really that great). When you can have proxies you can do anything you want. You can use AOP stuff transparently - for example decide you want to cache a certain method, or turn on performance monitoring, or make it transactional, etc...

Anyway... My experience says that it's very hard to say "I will never ever need to proxy this class for anything", so I prefer to be on a safe side and create an interface.

[tatvamasi]

The power of interface is not only in the modeling/design decoupling it allows, but in proxies you can create over them (yes, I know, you can create class proxies with cglib, but my experiences with that are not really that great). When you can have proxies you can do anything you want. You can use AOP stuff transparently - for example decide you want to cache a certain method, or turn on performance monitoring, or make it transactional, etc...

Don't you think "power of interface" is a very significant term that covers broad useages of interfaces? Also I strongly feel that proxies are very useful for making RPC based calls. And no way in the hell I will be exposing my core business components as RPC based services. I wouldn't mind wrapping it in to a facade and deploy that as a service and return a proxy for it.

Anyway... My experience says that it's very hard to say "I will never ever need to proxy this class for anything", so I prefer to be on a safe side and create an interface.

Reflact on your experience and see how many times throughout your career have you created proxies over your business logic? Like XP says DO not design too much upfront. Even if need arise I have no problem putting a big facade over my existing system.

[madtree]

Isn't that exactly what I said in my previous post? If I am not writing decoupled code, java or other OO technologies would not be my choice to solve the problem.

Thank you, exactly my point, you don't code to interface if you don't need the power of it. specially if you are coding to interfaces just because you can mock the classes for your JUnit test.
I am not sure why you would say writing factory is somewhat a complex task. And I would not call it redundant though. May be how you store/create objects for a factory to return sure can be subjective.

Writting a factory can be complex when you have to :
1) create objects necessiting complex creation logic.
2) needs to somehow cache the created objects.
3) manage objects states (although if we are speaking conceptually and not technically those are not factories but repositories)

I can and have see/n people misuse singleton. but give me one good reason to call it evil.

They are a disguised global variable, an anti OO concept. They promote tight coupling between classes and your dependencies end up hidden all over your code. A small change in the singleton can have a tremendous impact and they are quite hard to test.

Having to create a global variable instead of passing around the object as a parameter is a big smell in your design. There are always better way to achieve the same result (parameters, introducing a factory, ...).

Are you saying people do implement their business logic into their factories? Humm, I sure am missing something. Well lets see, If I use a ServiceLocator that basically looks up a service for me and returns "interface" to calling object(not to mention classes that creates appropriate object).

No I'm saying people often put creation logic into their business objects, especially when they are using service locators. I don't like the name "service locator", it infers that a factory is just a way of retrieving some objects. But in reality a factory has a lot more responsabilities and can be quite a complex beast. Saying they are only retrieving a service is an oversimplification in my opinion.

It's true you can use custom factories instead of DI and still be able to achieve the same results. But it requires you to write a lot of infrastructural code while you can get it for free when using DI. Not to mention that a mature DI container is specialized in this kind of task and has been thoroughly tested and optimized.

Another advantage is that DI is a push model so you don't need to scatter your code with calls to a factory. The code become much more clearer.