Spring != OO support ...

[jladd]

I don't think anyone will question the brilliance of Spring and how useful it is, however, a lot of what it does promotes a non-Object Oriented approach to software development, which can't be good.

My question is, doesnt this worry you or have I missed something and have the wrong opinion about Spring?

How can you support Object Oriented principles and still use Spring ?

Rgs, James.

[manifoldronin]

Inversion of Control/Dependency Injection is a key OO design concept and pretty much the core of Spring. So I'm not sure where the "non-OO'ness" approache came from.

You would probably get more relevant and concrete reponses by listing the things that Spring does and you think "promotes a non-Object Oriented approach."

[jladd]

manifoldronin, thanks for the reply.

Id be interested in any links you could provide that detail the Principles of Object Orientation and include a mention of dependency inject or inversion of control. There is dependency inversion but im not sure its the same thing especially when you have to break other principles to do it.

http://ootips.org/ood-principles.html

I do agree that having a few examples of how Spring breaks OO would be helpful in this discussion so here you go:

1. A principle of OO is encapsulation / data hiding and not exposing the implementation details of a Class. However, Spring needs public access to this information in order to do its 'thing'.

2. The Dependency Inversion Principle: "Depemd Upon abstractions. Do not depend upon concretions. Which is also broken by Spring as again it requires concrete implementations and doesnt work through abstractfactories.

3. Not an OO principle but a Joshua Block one:- How do you use spring and ensure a class is immutable ?

Maybe there are ways around these and the other principles broken by Spring but im not aware of them.

Again, I think Spring is great but Im wondering where it fits amidst the other things I need from my software like maintainability in the face of change.

Rgs, James.

[Colin Yates]

Id be interested in any links you could provide that detail the Principles of Object Orientation and include a mention of dependency inject or inversion of control. There is dependency inversion but im not sure its the same thing especially when you have to break other principles to do it.

Dependency injection, IoC and Depenency inversion are all variations of the same concept; classes are *given* their dependencies, they don't find them themselves.

1. A principle of OO is encapsulation / data hiding and not exposing the implementation details of a Class. However, Spring needs public access to this information in order to do its 'thing'.

Not true Classes can be wired up using constructor arguments just as easily as parameters:

<bean id="myBean" class="...."
  <constructor-arg>
    <bean class="some.collaborator.impl"/>
  </constructor-arg>
  <constructor-arg ref="someOtherCollaborator"/>
</bean>

2. The Dependency Inversion Principle: "Depemd Upon abstractions. Do not depend upon concretions. Which is also broken by Spring as again it requires concrete implementations and doesnt work through abstractfactories.

Not true again If I have a class which requires a collaborator to work then the class would expect the interface. Of course at run time it must be provided with an implementation, but it only expects the interface:

public interface MyDAO {
  void doSomething();
}

public class MyDAOImpl implements MyDAO {
  public final void doSomething() {
    ...
  }
}

public class MyClass {
  private final MyDAO dao;
  public MyClass(final MyDAO myDAO) {
    this.dao = myDAO;
  }

  void doMyMethod() {
    myDAO.doSomething();
  }
}

and

  <bean id="myDAO" class="MyDAOImpl"/>
  <bean id=myClass" class="myClass">
    <constructor-arg ref="myDAO"/>
  </bean>

Note; no setters

3. Not an OO principle but a Joshua Block one:- How do you use spring and ensure a class is immutable ?

See the above.

Maybe there are ways around these and the other principles broken by Spring but im not aware of them.

I still don't see which principles Spring breaks. To my mind, Spring actively encourages good practices

It is true that most of Spring utility classes prefer setters, but that is an old convention, and isn't enforced. I simply workaround it by passing all required collaborators via constructor and calling setters on the utility class.

HTH.

[jladd]

yatesco,

Thanks for the detailed reply.

"It is true that most of Spring utility classes prefer setters, but that is an old convention, and isn't enforced. I simply workaround it by passing all required collaborators via constructor and calling setters on the utility class."

I had intended to come back and edit my post to be more specific about Spring in that whilst it doesnt madate non-oo principles be used it also doesnt ensure they are not used. ie: You work around them.

Im a lot happier now that your post clears a lot up.

Thanks.

Rgs, James.

[Colin Yates]

There are a lot of other forum posts to do with benefits of Spring, but I cannot remember where they are

One than I can find of the top of my head:

http://forum.springframework.org/sho...pring+benefits

Try searching for "spring benefits" and have a perusal of the results

[jladd]

yatesco,

Thanks again for the reply.

Another thing I am curious about is the required visibility of classes.
If my concrete implementation classes are package scope,
can Spring see them or do they all have to be public ?

Personally I like to have all classes and methods with as little scopy/visibility
as possible.

Rgs, James

[Colin Yates]

Another thing I am curious about is the required visibility of classes.
If my concrete implementation classes are package scope,
can Spring see them or do they all have to be public ?

If your classes implement an interface (which they should) then by definition the implemented methods must be public

[wexwarez]

I think you are making some strong statements in this thread without backing them up. I have been coding in object oriented languages for a decade now and have been working with java for many years. I just recently started working with spring and I can only say that it has helped my programming style become more object oriented and structured. The whole idea of Ioc really enforces the idea of writing loosely coupled code and encourages design by interface first. In my mind this is the basis of good OO programming.

[jladd]

All,

Yes I did make some strong statements and that was intentional.
Mostly so that I could get strong answers and I have.

My first venture into spring wasnt by choice and the examples that were used and approach that was promoted required get/set for everything which made me cringe. yatesco - Pointed out that you could use constructors and I knew this and I was hoping that in the later versions of spring or somewhere in the doco there was something that said the constructor approach was preferred over get/set. I dont like get/set because it exposes the implementation of an object and doesnt help in keeping objects immutable.

yatesco whose replies I appreciate says that I should be using interfaces and I do and that the methods of the interface will be public and yes they are, as they can't be any other way.

My question is, does the class that implements the interface have to be public as well ? Id prefer to have its scope package only so they can not be created outside the package except by a 'factory'. Otherwise people might construct them themselves directly.

Please dont get me wrong, I think Spring is a great framework and its come a long way and has a lot of takeup. Maybe my question should be "is there a set of best practice guidelines for using spring ?" ie: spring 'can' be used in a very OO way, but what does it do to 'enforce' this ?

Thanks again for the replies.

Rgs, James.