A reference discussing all the Design Patterns used inside Spring?

[markmc]

I hope this is not a silly question.

I like Spring because it helps me to produce code that just "feels right". Unfortunately I learnt how to program in Java without due reference to design patterns so I'd like to better understand what Spring is doing that makes it so productive to work with.

I understand that Spring implements lots of good design pattern practice. I regularly see references to IoC, MVC, AOP, DAO, Domain Models, Factories and Templates. I even understand many of these! I appreciate that there is not really a definitive list of design patterns (and some have multiple names etc.). However, is there a book, reference or comprehensive tutorial that catalogues and discusses all of the design pattern approaches used inside Spring?

I think this would be really useful.

Mark

[Colin Yates]

Good question.

You might find the books listed here:http://www.springframework.org/bookreview and the documentation listed here:http://www.springframework.org/documentation useful

[Andrew Swan]

I don't know about an exhaustive list of patterns used within the framework (not sure it would be worth anyone's while to write one), but often the JavaDoc for a specific class will explain any key patterns in use. For example, the JavaDoc for org.springframework.web.servlet.mvc.AbstractContro ller explains that it uses the "Template Method" design pattern.

I suggest you simply keep using the framework as you are, and investigate any new patterns as you come across them.

Personally (and this is not directed at you of course), I like to see a developer master the basics of coding before getting too fancy-shmancy with patterns. Too many people try to run before they can walk, by applying (and mis-applying) patterns just because they look cool on one's resume. The best solution is always the simplest one (as long as it's maintainable and where necessary, extensible).

[Colin Yates]

Personally (and this is not directed at you of course), I like to see a developer master the basics of coding before getting too fancy-shmancy with patterns. Too many people try to run before they can walk, by applying (and mis-applying) patterns just because they look cool on one's resume. The best solution is always the simplest one (as long as it's maintainable and where necessary, extensible).

The other point to make along the same lines is avoid "design pattern bingo" where you absolutely *must* use all the latest design patterns

Remember, design patterns are solutions to a distinct problem.....if you don't have that particular problem, the solution (pattern) will be useless. Some (none core) design patterns actually promote quite poor practice.

Take ValueObjects (some would argue it isn't strictly a pattern, but....), they are about as un OO as you get , however they are preferable to making a network call for every property on an Entity Bean. If you don't have that problem, don't use VOs. The number of projects I have seen that use VOs, but when questioned reply "well, it is good practice....isn't it?" is scary.

HTH

[tatvamasi]

Take ValueObjects (some would argue it isn't strictly a pattern, but....), they are about as un OO as you get ,

Hummm, I missed the point here, Are you refering to "anemic domain model" terminology by Fowler here? If so than how are VOs different than "DTOs"? Although my core question is how are they un-OO?

however they are preferable to making a network call for every property on an Entity Bean.

Not only that they are prefered to pass data from one component to another.

If you don't have that problem, don't use VOs. The number of projects I have seen that use VOs, but when questioned reply "well, it is good practice....isn't it?" is scary.
HTH

Are you suggesting that Business components should maintain data in itselves? If so than how it is different than procedural programming? If not than again how would you keep your business and data saperate?

[Marten Deinum]

Are you suggesting that Business components should maintain data in itselves? If so than how it is different than procedural programming? If not than again how would you keep your business and data saperate?

Assuming that with business compoment you mean domain object.

For me a domain object contains data and it is responsible for it's own state and behavior. This is also ofcourse one of the core concepts of OO. However now if we create only objects which contain data, create a component (often called Service or Manager) which contains our business logic we have created the "anemic domain model".

We are getting way off the original question here

[Colin Yates]

Hummm, I missed the point here, Are you refering to "anemic domain model" terminology by Fowler here? If so than how are VOs different than "DTOs"? Although my core question is how are they un-OO?

Kind of. ValueObjects/DataTransferObjects/DataObjects etc. are all data carriers. As I originally mentioned, they all came about to reduce the cost of making a network call for every attribute of a class. For more info I suggest you read http://java.sun.com/blueprints/corej...ferObject.html.

Given that OO is all about defining objects that represent behaviour *and the data that behaviour works on*, value objects are definately not a "good thing".

The anaemic domain model is a model in which the domain model is split into chunks of data and stateless services which operate on that data.

[quote]
Not only that they are prefered to pass data from one component to another.
[/quotev]
Not sure what you mean by "component".... can you explain.

Are you suggesting that Business components should maintain data in itselves? If so than how it is different than procedural programming? If not than again how would you keep your business and data saperate?

I don't think I understand your objection.....OO is all about marrying data and behaviour...procedural programming is the exact opposite. An anaemic domain model is an example of procedural programming.

Again, I recommend you read http://java.sun.com/blueprints/corej...ferObject.html and http://www.martinfowler.com/bliki/An...mainModel.html.

[tatvamasi]

Kind of. ValueObjects/DataTransferObjects/DataObjects etc. are all data carriers. As I originally mentioned, they all came about to reduce the cost of making a network call for every attribute of a class. For more info I suggest you read http://java.sun.com/blueprints/corej...ferObject.html.

Given that OO is all about defining objects that represent behaviour *and the data that behaviour works on*, value objects are definately not a "good thing".

Point well taken, I still do not understand why value objects are not a good thing.

The anaemic domain model is a model in which the domain model is split into chunks of data and stateless services which operate on that data.

I understand that very well. You are saying VO are chunks of data, are you? if you are then read on.

[qb]
Not only that they are prefered to pass data from one component to another.
[/qb]
Not sure what you mean by "component".... can you explain.

What you describe "representing behavior" thats what i meant by component.

I don't think I understand your objection.....OO is all about marrying data and behaviour...procedural programming is the exact opposite. An anaemic domain model is an example of procedural programming.

Let me give you a simple example. You have a comma delimeted file with the personal information of employees that you want your system to operate on. As you described in your earlier post, you have seen lots of projects using "VOs", standard case, people would start analysing what kind of information is in that file and how they can map it to fields in the database. So the objects being created are FileParser, Employee (VO) where FileParser operates on file and creates list of Employee. thats how they define their VO(Anemic domain model!) to be used by their "stateless services" or business components. While object "biggots" would say File has lines and Lines has fields therefore File need to know how to parse itself in lines, Line needs to know how to parse itself in fields and to me information at its most generic level Field becomes VO or DTO or whatever you want to call it Which identifies what it is. So the objects are being defined are File, Line, Field and a transaction script (service) which would initiate File to do the rest of the job. So to me DTO or VO are not necessarily a bad thing depending on how you define them.

[devijvers]

I appreciate that there is not really a definitive list of design patterns (and some have multiple names etc.). However, is there a book, reference or comprehensive tutorial that catalogues and discusses all of the design pattern approaches used inside Spring?

I think this would be really useful.

I totally agree, this would be very useful. Some people consider Spring as the best structured code base in the world. It's more than likely the way design patterns are used contribute to this feat.