Spring != OO support ...

[manifoldronin]

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.

I actually agree with you there. I think it's mostly because it's a lot easier and less error-prone with the get/set approach than with constructors, in which case you have to worry about matching the parameters either to the exact types or the exact indices. And most of the time people working on those examples just want to get to the fun "look at this cool thing Spring can do" part, and don't usually give serious thoughts to whether a particular getter/setter makes sense were the object being designed to be a serious domain object.

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.

Agreed again. I too think excessive use of getters/setters is a prevailing problem. On the other hand, though, I don't think it's Spring's responsibility to tell people which approach is the "best" practice. As matter of fact, if I were to pick one single thing I like the most about Spring, it would be that it always tries to be as non-prescriptive as possible. Comparing to the all-your-base-are-belong-to-us EJB paradigm, Spring promotes best practices, but does not dictate your design in particular.

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.

AFAIK, no, an implementation class does not have to be public.

[jladd]

Jing Xue,

Thanks for you reply and not just because we have agreement on some items.
Im keen to work with spring again and some of the Spring-MVC stuff is going to help a lot.

Personally I would like some "best-practice" doco but this doesnt have to make it into the product itself.

Now Ill put the advice to the test and see how Spring fits in with a strick OO approach and report back. Im sure the report will be glowing.

Rgs, James.

[smv]

When I first starting playing with Spring MVC in 2004, I started with the sample applications and found them to be horrible designs filled with accessors. However, I believe the point of the sample applications aren’t to show proper design but to show the simplicity of mapping from Hibernate to the web.

In terms of using Spring to wire my service layer, I only use constructor-based initialisation. I believe the InitializingBean interface is a kluge to the setter-based initialisation as it can have the same problems as using the setters in the first place… did I call that method to set XXX? did I add that validation for XXX to the afterPropertiesSet method? I don't believe that you need to ask an object if its valid.

I use Holub’s Builder pattern by adding exporter and importer methods to my domain objects which read/write to an interface the domain layer knows about. The advantages are outlined in Holub’s articles and his book (look for ‘Getters are Evil’) so I won’t reiterate them here. The only difference that I make is that my importer is public instead of protected as shown in Holub’s examples. The advantage of the importer is that it’s a single point of entry to update the domain object. This allows me to validate and ensure that private attributes are set in a specific order without having to use an external Validator or call a validate method on the domain object (see my reasons above regarding the InitializingBean interface).

Since the importer uses an interface for publishing data, the service layer also uses the interface. This frees the client layer to implement this in any fashion (DTOs, Swing Documents, etc).

Finally for the Spring MVC presentation layer, I use DTOs which implement the domain object’s exporter/importer interfaces. The Spring controllers map to these DTOs and commands are sent to the service layer. Since the DTOs are in their own package (as is the rest of the webapp part of the application) they are free to have whatever presentation attributes that are necessary to fulfill the usecase.

Micheal

[jladd]

Micheal,

Wow, thanks for the great response.
Would it be possible to see an example either privately or publicly ?

I am a big fan of Holub and I use the builder pattern too.

I look forward to your response.

Rgs, James.

[cepage]

There are a lot of smart people who get concerned about the mutators, and I'd love to have a better understanding why.

With good OO design, you should be accessing classes through their interfaces, and not through their concrete implementations, and Spring does a great job of helping you to implement your applications this way.

For injected dependencies, I don't put mutators in the public interface. Period. Yes, there is a public setter method, but if your code is accessing the bean through its interface, then for all practical purposes it is private.

Sure, Spring doesn't 'enforce' private access to the mutator, but the only way you could get to it is by directly invoking the class's concrete constructor (or casting to a concrete class), and that's a no-no.

If you can't get your team to reference classes through injected interfaces, rather than invoking concrete constructors, then you aren't going to be able to 'enforce' OO principles anyway, and Spring can't do anything about that.

[Spring Guy]

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.

You can still have a class with package level access and create a factory to inject it into other classes.
There are numerous factory classes that you can use, especially look into API for MethodInvokingFactoryBean
http://static.springframework.org/sp...api/index.html

I really don't see which part of OO principle does Spring violate...
Setters are infact very useful because they enforce the design requirements of the class. One of the best books i have read was Object-Design..by Rebecca, it clearly states that it's an object responsibility to document its requried collaborators, role(s), responsibilities, and after-effects of using it...
So setters really give an idea about the object's collaborator's and doesn't disclose what the object is really doing... though they recommend that objects should be able to perform their responsibilities with less dependency..

Anyway, what i am trying to say here is setters aren't really bad, it all depends upon how design it. If you have more than 6 setters that means your object dependency on others is really high...

Regarding immutability, it applies more to domain objects than service objects. Service objects are really neutral and perform actions on the domain objects.. Service objects collaborate with other objects to achieve a certain goal [like use-case scenario etc]....
Domain objects should be the one to enforce immutability depending upon the state they are in...
I am using combination of AOP and factory classes to really hide the implementation...[but i made sure i have good documenation for it]

[jladd]

Thanks Everyone,

I knew there would be a way to ensure that Spring could be used in an OO way. I was very interested in bringing this out and hence the rather 'bold' statement.

I will use all the excellent responses to shape an OO use of Spring

Thanks.

Im still keen to see responses even though I am sold
and Spring == OO

Rgs, James.

[wexwarez]

There are a lot of smart people who get concerned about the mutators, and I'd love to have a better understanding why.

With good OO design, you should be accessing classes through their interfaces, and not through their concrete implementations, and Spring does a great job of helping you to implement your applications this way.

For injected dependencies, I don't put mutators in the public interface. Period. Yes, there is a public setter method, but if your code is accessing the bean through its interface, then for all practical purposes it is private.

Sure, Spring doesn't 'enforce' private access to the mutator, but the only way you could get to it is by directly invoking the class's concrete constructor (or casting to a concrete class), and that's a no-no.

If you can't get your team to reference classes through injected interfaces, rather than invoking concrete constructors, then you aren't going to be able to 'enforce' OO principles anyway, and Spring can't do anything about that.

Good point.
I don't think the access level quesiton applies directly to spring but to design in general.

In terms of the instantiation question of setter injection vs constructor i do think this is a valid issue. When I started learning spring i spent a significant amount of time reading on it and this was one of the things that stuck out in my mind. Why on earth would people use setter injection to initialize dependencies when that doesn't enforce a clear contract of the dependencies?
Instead the user is responsible for making sure they are fully aware of the class api and what required dependencies are. But as I read i noticed most of the big sping advocates also seem to choose initialization through setters as a best practice. So, i tried both techniques thoroughly and my conclusion is that initialization through setter injection is just more natural when working with spring Ioc both from the actual configuration files to the idea of it. I don't think it is any more than that. Sometimes setter injection is nice to avoid constructors with way too many parameters. I also know people suggest it being usefull when working with interfaces that define dependencies using setters, but i don't think interfaces should define dependencies in most normal cases anyways.

As someone else pointed out, one great thing about spring is that it gives you choices. When I started using spring at first i was trying to pin point best practices and didn't really make much progress. So instead I just started using it and on issues like this where you just aren't sure of a best practice, try both options spring offers in your application and you will soon figure out what you like best and maybe how certain techniques can be used better in different cases.

[Colin Yates]

So, i tried both techniques thoroughly and my conclusion is that initialization through setter injection is just more natural when working with spring Ioc both from the actual configuration files to the idea of it. I don't think it is any more than that.

Why are setters more natural? You can autowire by name with setters (and not constructors) but IIRC you can autowire constructors by type....

Sometimes setter injection is nice to avoid constructors with way too many parameters.

I would suggest this is probably a code smell anyway If you have two many collaborators it *probably* implies that your class is doing too much....

I think this is a really interesting thread, and just wanted to understand your POV a bit more

[cepage]

Why are setters more natural? You can autowire by name with setters (and not constructors) but IIRC you can autowire constructors by type....

Setter Injection can actually be used in most application situations. Autowiring by type falls apart as soon as you have two dependencies that implement the same interface. Constructor injection is out when you want to wire an object (Webwork Action, Hibernate-persisted object) that is instantiated by a third party.

But I take the point about constructors offering a more explicit component contract.