Comments on: Spring’s Structure is “almost perfect” http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/ Fri, 23 Dec 2011 12:59:15 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Chris http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-47 Chris Thu, 15 Mar 2007 11:06:27 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-47 <p>Slava - I take your point, though my post refers to a different aspect of a code-base. The "structure" I talk about is a level above the language specifics. How is the code recursively organized into higher-level components, and are the inter-component dependencies nice and orderly? A clean structure in this sense does not imply elegant code-level design, nor vice versa.</p> Slava – I take your point, though my post refers to a different aspect of a code-base. The “structure” I talk about is a level above the language specifics. How is the code recursively organized into higher-level components, and are the inter-component dependencies nice and orderly? A clean structure in this sense does not imply elegant code-level design, nor vice versa.

]]> By: Slava Pestov http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-46 Slava Pestov Tue, 13 Mar 2007 08:53:52 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-46 <p>When evaluating a piece of code, you have to consider the language it is written in. Nothing written in Java can qualify as elegant or well-structured, because of Java's grave design flaws. The best you can say about a Java project is that it uses standardized copy and paste boilerplate ("design patterns") rather than something ad-hoc.</p> When evaluating a piece of code, you have to consider the language it is written in. Nothing written in Java can qualify as elegant or well-structured, because of Java’s grave design flaws. The best you can say about a Java project is that it uses standardized copy and paste boilerplate (“design patterns”) rather than something ad-hoc.

]]> By: Chris http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-45 Chris Wed, 22 Nov 2006 12:44:32 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-45 <p>Likewise, it's good that your experience matches the complexity numbers!</p> <p>No community version at the moment. There is a separate publisher however. With just one of these, you can "measure" as many projects as you like and then compare projects and track complexity over time through a web browser...</p> Likewise, it’s good that your experience matches the complexity numbers!

No community version at the moment. There is a separate publisher however. With just one of these, you can “measure” as many projects as you like and then compare projects and track complexity over time through a web browser…

]]> By: Paul Browne - TIPE http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-44 Paul Browne - TIPE Wed, 22 Nov 2006 12:27:28 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-44 <p>It's good to see that the 'gut feeling' I had about the quality of the Spring Framework being validated by some hard numbers.</p> <p>As an aside , is there a community version of your product (maybe without all the graphical reports, but enough to give an indication of the code complexity)?</p> It’s good to see that the ‘gut feeling’ I had about the quality of the Spring Framework being validated by some hard numbers.

As an aside , is there a community version of your product (maybe without all the graphical reports, but enough to give an indication of the code complexity)?

]]> By: Chris http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-43 Chris Thu, 20 Jul 2006 13:16:17 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-43 <p>Ok Chris, I'll put that on my list ;-). I have worked with Bob Martin's DMS metrics a fair bit and I'd say that they are often good indicators, especially at the macro level (like "components" rather than "packages"). In fact I've tried to use most "quality" metrics, and I keep coming back to the view that, for the vast majority of code-bases, the highest priority is to reign in the structural complexity. Once you've balanced the complexity, then it may make sense to consider Abstractness vs. Instablility or look at the OO metrics or afferent and efferent coupling or whatever. But until your structure is under control, you're just rearanging deck chairs.</p> Ok Chris, I’ll put that on my list ;-) . I have worked with Bob Martin’s DMS metrics a fair bit and I’d say that they are often good indicators, especially at the macro level (like “components” rather than “packages”). In fact I’ve tried to use most “quality” metrics, and I keep coming back to the view that, for the vast majority of code-bases, the highest priority is to reign in the structural complexity. Once you’ve balanced the complexity, then it may make sense to consider Abstractness vs. Instablility or look at the OO metrics or afferent and efferent coupling or whatever. But until your structure is under control, you’re just rearanging deck chairs.

]]> By: Chris Murphy http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-42 Chris Murphy Thu, 20 Jul 2006 03:37:21 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-42 <p>If you are interested in analysing open source code bases generally then take a look at www.strandz.org. You won't find any dependency cycles in it - JDepend has always been used to ensure this. It would be interesting to know if someone could relatively easily pinpoint some areas that need improvement. I must admit I have never really paid too much attention to the more detailed JDepend metrics (although I have read Robert C Martin's book), although perhaps I should!</p> <p>https://sourceforge.net/projects/strandz/</p> If you are interested in analysing open source code bases generally then take a look at http://www.strandz.org. You won’t find any dependency cycles in it – JDepend has always been used to ensure this. It would be interesting to know if someone could relatively easily pinpoint some areas that need improvement. I must admit I have never really paid too much attention to the more detailed JDepend metrics (although I have read Robert C Martin’s book), although perhaps I should!

https://sourceforge.net/projects/strandz/

]]> By: Chris http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-41 Chris Wed, 19 Jul 2006 13:16:02 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-41 <p>Controlling the structural complexity of a project won't in itself guarantee that the class/code-level decisions are optimal. Experience and Fowler-esque refactoring are still just as relevant. For a given implementation approach, however, a better structure will make the code-base easier to understand, change impact will be more localized, and development, test and release processes more efficient.</p> Controlling the structural complexity of a project won’t in itself guarantee that the class/code-level decisions are optimal. Experience and Fowler-esque refactoring are still just as relevant. For a given implementation approach, however, a better structure will make the code-base easier to understand, change impact will be more localized, and development, test and release processes more efficient.

]]> By: Antranig Basman http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-40 Antranig Basman Wed, 19 Jul 2006 13:06:55 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-40 <p>Yes to Andrew's comments. This code analysis of Spring is excellent, although it tends to miss complexity at the actual source-file level. I agree that Spring is the best open source codebase I have ever worked with, but it has a number of "fat wodges" of bulky stateful code, in particular AbstractAutowireCapableBeanFactory is a particularly bad offender, and its tight relationship with BeanWrapperImpl is exactly what prevented us from working with Spring directly when we needed a *much* faster implementation - RSAC attaches to Spring after having read the context definition but after this switches to a ground-up rewrite to actually operate the context. Naturally it sacrifices some of Spring's flexibility but most of this is typically only required in the longer-lived, enterprise-scale contexts at which Spring is based.</p> <p>I would criticise the validity of some of the complexity metrics, since for example the Spring Hibernate classes are not "complex" in the conceptual sense since they are actually fairly "wide and flat". Whereas AACBF *is* really quite complex and coupled to the general "Spring internal workflow" in all sorts of ways, but has not appeared on the metrics radar at all.</p> <p>Spring's isolation at the BeanDefinition, BeanFactory and ApplicationContext level is exemplary.</p> <p>You may want to look at the RSF source code base for comparison - its unit of composition is even more finegrained that Spring's, and naturally will have no dependency cycles at the class level since it is configured using Spring. <br /> In particular the average source file size in RSF at 56 lines is *massively* lower than in any other framework I have seen (compared with 155 for Spring, and ~200 for JSF and Wicket).</p> <p>RSF is much worse at the package level since I have made very little effort to remove cycles at that level. Any suggestions for refactoring would be most welcome :P</p> Yes to Andrew’s comments. This code analysis of Spring is excellent, although it tends to miss complexity at the actual source-file level. I agree that Spring is the best open source codebase I have ever worked with, but it has a number of “fat wodges” of bulky stateful code, in particular AbstractAutowireCapableBeanFactory is a particularly bad offender, and its tight relationship with BeanWrapperImpl is exactly what prevented us from working with Spring directly when we needed a *much* faster implementation – RSAC attaches to Spring after having read the context definition but after this switches to a ground-up rewrite to actually operate the context. Naturally it sacrifices some of Spring’s flexibility but most of this is typically only required in the longer-lived, enterprise-scale contexts at which Spring is based.

I would criticise the validity of some of the complexity metrics, since for example the Spring Hibernate classes are not “complex” in the conceptual sense since they are actually fairly “wide and flat”. Whereas AACBF *is* really quite complex and coupled to the general “Spring internal workflow” in all sorts of ways, but has not appeared on the metrics radar at all.

Spring’s isolation at the BeanDefinition, BeanFactory and ApplicationContext level is exemplary.

You may want to look at the RSF source code base for comparison – its unit of composition is even more finegrained that Spring’s, and naturally will have no dependency cycles at the class level since it is configured using Spring.
In particular the average source file size in RSF at 56 lines is *massively* lower than in any other framework I have seen (compared with 155 for Spring, and ~200 for JSF and Wicket).

RSF is much worse at the package level since I have made very little effort to remove cycles at that level. Any suggestions for refactoring would be most welcome :P

]]> By: Andrew Thornton http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-39 Andrew Thornton Wed, 19 Jul 2006 12:45:13 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-39 <p>There are only a few problem's I've ever had with Spring's internal structure:</p> <p>1. If you want to understand what ApplicationContext is doing, you'll hit lots of calls to self-referential Interfaces and a long tree of inheritance.</p> <p>2. BeanWrapperImpl: One of these is created per-property/construction setting. Just look at what happens during the creation of one of these objects. There simply has to be a better way... </p> <p>Apart from the above, Spring is easily one of the best written pieces -- if not the best written piece -- of software I've ever looked at.</p> <p>(Note to the above: We only spotted the above problems when we were looking at creating RSAC (a request scope AC)) </p> There are only a few problem’s I’ve ever had with Spring’s internal structure:

1. If you want to understand what ApplicationContext is doing, you’ll hit lots of calls to self-referential Interfaces and a long tree of inheritance.

2. BeanWrapperImpl: One of these is created per-property/construction setting. Just look at what happens during the creation of one of these objects. There simply has to be a better way…

Apart from the above, Spring is easily one of the best written pieces — if not the best written piece — of software I’ve ever looked at.

(Note to the above: We only spotted the above problems when we were looking at creating RSAC (a request scope AC))

]]> By: Chris http://www.headwaysoftware.com/blog/2006/07/springs-structure-is-almost-perfect/comment-page-1/#comment-38 Chris Wed, 19 Jul 2006 10:04:41 +0000 http://headway.structure101.com/blog/2006/07/springs-structure-is-almost-perfect/#comment-38 <p>Now that's interesting. I took a quick look at freemarker and it is structurally very complex! For example there is a single tangle of 176 classes spread out over 10 packages. This means that every class or package in the tangle is directly or indirectly dependent on every other. </p> <p>I'm guessing that the extension points are well designed and localized which is why you find it easy to customize (can you confirm this?). However I would expect a team updating the whole code-base to find it very hard to modify, since they would constantly need the latest versions of code that others were working on.</p> Now that’s interesting. I took a quick look at freemarker and it is structurally very complex! For example there is a single tangle of 176 classes spread out over 10 packages. This means that every class or package in the tangle is directly or indirectly dependent on every other.

I’m guessing that the extension points are well designed and localized which is why you find it easy to customize (can you confirm this?). However I would expect a team updating the whole code-base to find it very hard to modify, since they would constantly need the latest versions of code that others were working on.

]]>