Decision to use the Spring Framework

[Arthur Loder]

I think the original intent of Ben's post was that Spring has some awesome features that warrant the hype. I think it was the swapping of strategy interface implementations in a production application that he was referring to when he said he didn't see the value (simply because he doesn't believe this happens or does not happen often enough to warrant the hype this side-effect of using Spring's DI support provides).

And yes, I realize that there are other advantages to using DI, such as ease in unit testing, cleaner code, etc.

Sorry to put words in your mouth Ben.

-Arthur Loder

[tatvamasi]

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)

Misuse of Factory would get you to #1. Creating V/S Assembling.... big difference...

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, ...).

They are not a disguised global variable as long as you use it for right purpose Singletons aren't designed for change. It is a creational pattern and not behavioral one. how you create your objects doesn't change often if not at all. If you use singletons for behavior............. Singletons are anti patterns because people use it as a place holder to save a trip to database.

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.

I will say Factory is not a service locator. One is implemented as singleton another is a static class. one retrieves services another creates instances. FACTORIES ARE NOT SERVICE LOCATORS. Locating a service V/S creating an instance are two different things. Factories do not have lot more responsibilities. It has only one responsibility to create a proper instance of a class for given scenario. even underlying structural pattern wouldn't have complex logic given right structural pattern was used.

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.

Interestingly, Why would I push something in my object assembly which I may or may not require for the task being executed?

[madtree]

Misuse of Factory would get you to #1. Creating V/S Assembling.... big difference...

Really? According to the dictionnary, assembly is "the act of constructing something (as a piece of machinery)". And what you do in a constructor usually? Assigning values right? Sound like assembling to me.

Also an object must enforce some invariants on its relationships at any moment or it'll end up in a incoherent state. So an object can't be considered constructed until it gets assembled correctly unless you don't care about invariants which is against OOP.

I'm not saying a factory is mandatory for each object. A simple constructor may be enough in a lot of cases but in some other cases where the creation logic is complex, it's better to delegate the work to a factory method or to a complete individual factory. If you program following the TDD approach, those cases are quite easy to spot and introducing a factory through refactoring is kind of easy.

They are not a disguised global variable as long as you use it for right purpose Singletons aren't designed for change.

I believe OOP true strength are clarity and allowing you to introduce changes easily through refactoring. Now have you ever tried to refactor and test some code using singletons? It is very hard to achieve because any code can get access to a singleton and you can't override a static method. In fact, a simple change can have a disatrous impact on your code base.

It is a creational pattern and not behavioral one. how you create your objects doesn't change often if not at all. If you use singletons for behavior............. Singletons are anti patterns because people use it as a place holder to save a trip to database.

If an object doesn't have behavior then it isn't a real object but a mere data holder. Hence, you are using a disguised procedural construct in a OO programming languague (with all disadvantages coming with it, see my comment above).

Creation behavior doesn't change often? I don't agree with that. Have you ever ported an existing application in a clustered environment? Face multi-threading problems? Good luck with those singletons. Of course, you won't face those problems if your objects are stateless but than again if a lot of your objects are stateless, you might use a procedural language as well.

I will say Factory is not a service locator. One is implemented as singleton another is a static class. one retrieves services another creates instances. FACTORIES ARE NOT SERVICE LOCATORS. Locating a service V/S creating an instance are two different things. Factories do not have lot more responsibilities. It has only one responsibility to create a proper instance of a class for given scenario. even underlying structural pattern wouldn't have complex logic given right structural pattern was used.

First, a factory or a service locator can be implemented technically the same way if you want so they aren't different in this point of view. A pattern can't be translated directly in code and can be implemented using a variety of different strategy.

However, I agree with you they are different conceptually. But you should usually wrap your service locator in a factory (or whatever creational pattern you choose to use) because a service locator is a technical mean to locate a service. When you use it directly, you expose infrastructure details to your domain model whereas a factory is an abstraction defined in terms of the domain model. Hence this is why I was saying service locators were a poor version of a factory.

Interestingly, Why would I push something in my object assembly which I may or may not require for the task being executed?

You can inject as many different instances of a class as you want so I don't see your point. You select what you want to be injected. If your code is higly conditionnal than a good old factory might be a better idea than using DI in this case.

[seabludude]

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.

Someone just wants to argue, and does not allow others to mention any benefits of Spring?

Following this thread seems a waste of time now...

[dejanp]

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.

I don't think I can count how many times I used proxies over my business interfaces. It's the business interface proxies that I use to define transactions, monitor performance, that need additional security aspects, transparent caching, jmx control/monitoring etc.

Spring makes the whole interface/implementation decoupling so easy that I'm not even considering it to be some kind of a overhead. It's a couple of minutes more work per class that will, sooner or later, allow me so much flexibility, in development, testing and production, that it's bound to pay off.

[tatvamasi]

Really? According to the dictionnary, assembly is "the act of constructing something (as a piece of machinery)". And what you do in a constructor usually? Assigning values right? Sound like assembling to me.

Creating different objects are creation of them where putting them together and make "something" out of them is assembling. In terms of patterns creational V/S Structural.

Also an object must enforce some invariants on its relationships at any moment or it'll end up in a incoherent state. So an object can't be considered constructed until it gets assembled correctly unless you don't care about invariants which is against OOP.

Again mix of Creational V/S Structural

I'm not saying a factory is mandatory for each object. A simple constructor may be enough in a lot of cases but in some other cases where the creation logic is complex, it's better to delegate the work to a factory method or to a complete individual factory. If you program following the TDD approach, those cases are quite easy to spot and introducing a factory through refactoring is kind of easy.

No, where you have one or more variants of a class thats where you will use factory effectively and not where creation logic gets complex.

I believe OOP true strength are clarity and allowing you to introduce changes easily through refactoring. Now have you ever tried to refactor and test some code using singletons? It is very hard to achieve because any code can get access to a singleton and you can't override a static method. In fact, a simple change can have a disatrous impact on your code base.



If an object doesn't have behavior then it isn't a real object but a mere data holder. Hence, you are using a disguised procedural construct in a OO programming languague (with all disadvantages coming with it, see my comment above).

I would have said business behavior. anyways what said is said. However I would again say if you use it for wrong purpose Shit happens. Factories are created singletons but not any structural or behavioral why? There is a reason for that.

Creation behavior doesn't change often? I don't agree with that. Have you ever ported an existing application in a clustered environment? Face multi-threading problems? Good luck with those singletons. Of course, you won't face those problems if your objects are stateless but than again if a lot of your objects are stateless, you might use a procedural language as well.

No I have not ported an application in a clustered env. Never saw need for it.

First, a factory or a service locator can be implemented technically the same way if you want so they aren't different in this point of view. A pattern can't be translated directly in code and can be implemented using a variety of different strategy.

Not really, Factory solely looks up given class from a class loader and create an instance of it. Service Locator locates an existing instance.

However, I agree with you they are different conceptually. But you should usually wrap your service locator in a factory (or whatever creational pattern you choose to use) because a service locator is a technical mean to locate a service. When you use it directly, you expose infrastructure details to your domain model whereas a factory is an abstraction defined in terms of the domain model. Hence this is why I was saying service locators were a poor version of a factory.

Not sure if i would wrap my locator in a factory, its more of a utility and should be a static class. Factories are created singletons as they require somekind of initialization before hand.

You can inject as many different instances of a class as you want so I don't see your point. You select what you want to be injected. If your code is higly conditionnal than a good old factory might be a better idea than using DI in this case.

Thats not what i meant what meant was if I am executing a method on an object which may or may not require defined injection (defined because some of the methods requires it) to complete the task. Don't you think I should think "go get it when I need it" and not "have it available so when needed its there"

[tatvamasi]

Someone just wants to argue, and does not allow others to mention any benefits of Spring?

Following this thread seems a waste of time now...

your choice.

[tatvamasi]

I don't think I can count how many times I used proxies over my business interfaces. It's the business interface proxies that I use to define transactions, monitor performance, that need additional security aspects, transparent caching, jmx control/monitoring etc.

Spring makes the whole interface/implementation decoupling so easy that I'm not even considering it to be some kind of a overhead. It's a couple of minutes more work per class that will, sooner or later, allow me so much flexibility, in development, testing and production, that it's bound to pay off.

Good for you. So you did have a need for coding to interface. you needed the power of interface. You did not code to interface just because........ Where is the disagreement.

[benethridge]

Why would I push something in my object assembly which I may or may not require for the task being executed?

This is the essential beef I have with file-base DI/IoC. It's the "may or may not" i.e. the conditional logic that I can write in java that I cannot write in the file. I had the same problem with Struts:

The "flexibility" gained for aspects which have a low probability of changing over the life of the app, bearing in mind that companies usually "throw out the baby (Spring) with the bathwater (the so-called "legacy" app)" ...this flexibility is not worth the price paid in (a) loss of protection of the compiler, and (b) the "flexibility" (spelled conditional logic) that I can write into the code. I'm thinking people are buying into the file-based DOI because it's "sexy" and "fun", whereas writing conditional logic POJOs is relatively boring? "Been there; done that; got that t-shirt" as Jimmy Buffett says.

Again, I'm keeping an open mind on the file-based DI. If someone can point me to a clear, solid payoff, from a Spring novice point of view, i.e. without further confusing the issue with deep, unexplained Spring techno-babble...I'm all ears.

I think the original intent of Ben's post was that Spring has some awesome features that warrant the hype. I think it was the swapping of strategy interface implementations in a production application that he was referring to when he said he didn't see the value (simply because he doesn't believe this happens or does not happen often enough to warrant the hype this side-effect of using Spring's DI support provides).

And yes, I realize that there are other advantages to using DI, such as ease in unit testing, cleaner code, etc.

Sorry to put words in your mouth Ben.

-Arthur Loder

Not a problem. That is essentially what I meant.

I hope this thread does not start to "go negative". Reading over your various posts, you all seem like smart, experienced designer/developers, whose design and coding philosophies, like mine, have been shaped by long years in this industry, which can be rather ruthless and unforgiving. Your philosophies seem vastly different from one another at times. One of the nice features of Spring is that it is not an "all-or-nothing" framework. You can usually take on just the parts that happen to fit with your philosophy, i.e. the parts that make sense to YOU.

In addition, one of the great values I see in Spring is in the support I get from the Spring team. Over the years, I remember working with support teams at DEC, HP, IBM, Sun, Microsoft and Oracle. Even though we were PAYING for support, and I mean big bucks sometimes, on the more difficult problems, it often took me 2-3 iterations of support calls, just to get to a person who actually knew what the f* they were talking about. Maybe it won't last forever, but with Spring, I'm working DIRECTLY with the people who designed and wrote the stuff! This is amazing! Argueably, the hottest technology in the java world today, and the CEO of the company backing the software is answering my questions!

I truly hope Interface21 is making money with this somehow, and that they can continue making money with this business model, and that other framework and API vendors can make money off this same business model. It gives me hope for the future of software development.

After all, the "bottom line" is the bottom line on the financial statement of the company for whom you work. Whatever your design/coding philosophy, if the software you design and write does not, at some point, make more money than it costs to produce, then you should be out the door. That is only fair in the world of business.

Ben

[dejanp]

Good for you. So you did have a need for coding to interface. you needed the power of interface. You did not code to interface just because........ Where is the disagreement.

Actually what I tried to say is exactly the opposite. I don't always know if I will need the interface or not, but the cost of it is practically zero, so the question is why not?