May 13th, 2008
Here are the slides for our Spring Framework Developer Session this evening:
Spring Framework Presentation.ppt
I keep finding applications, frameworks, and general methods that have ‘Singleton-itis’ or ‘Static everything’. Ugh!
A static reference is a concrete class dependency
Concrete class dependencies give you transitive dependencies
ex:
-NiceNewClass_X has zero depends to start
-We decide it could reuse stuff in StaticHelperClass_Y
-StaticHelperClass_Y has depends on 9 classes
-So - NiceNewClass_X now has all of the depends that StaticHelperClass_Y has (10 depends now all told)
The better situation would be if NiceNewClass_X depended on interface IHelperClass_Y. Then this class would have 1 dependency - on an interface (and any types that it needs to take as arguments, return types (hopefully abstractions as well).
Static-singletons - vs container managed singletons
Lets differentiate clearly. Singletons that are coded as static-singletons are one thing. You code it as a singleton - and you access it via a static accessor. This is a singleton that gives you a concrete class dependency. A container managed singleton is only a singleton via configuration.
IoC
Inversion of control enables this - ‘newing’ in your class has the same coupling and transitive dependency problem that a static class has. It is a concrete class dependency. So - we elect to depend on interfaces or abstract classes if need be and allow those abstractions to be passed in via constructor or via setter. This minimizes our direct class dependencies. I NO LONGER have to know about how to build my children, and I do not have the cascading dependencies on my children’s children’s children etc.
This does come at a price - you kill encapsulation - sort of, unless you defer to a container to be the assembler. This is what Spring and all the other lightweight containers are for.
Statics are Globals
Globals - we all know they are bad. Statics are globals! c’mon now - admit it 
Statics are not testable
You cannot test singletons effectively. You also cannot mock out static references when you are testing other classes that depend on static-singletons. This is one of the worst parts - you cannot separate and test! So - static-singletons mess your testing methods up.
Separation of interface from implementation
Static singletons FORCE you to NOT separate interface from implementation. YOU CANNOT PROGRAM TO AN INTERFACE when using a static-singleton. This is a GREAT reason to use container managed singletons (as opposed to static-singletons)- you CAN substitute implementation. Static singletons are a violation of the ISP - interface segregation principal. YOU MUST SEPERATE INTERFACE FROM IMPLEMENTATION. Statics KILL this!!! Since you cannot substitute implementation - this is - IMHO a violation of the OCP - open closed principal. Your code should be ‘open for extension -but closed for modification’. Normally if you want to vary behavior - you pass in a different dependency. With a static-singleton - you cannot pass in varying dependencies. That being said - now if you want to vary the behavior of a static-singleton - you must OPEN THE CODE FILE AND CHANGE IT - thus violating the OCP.
When are statics OK?
I DO LIKE private static methods - just to illustrate that they are side effect free - no class member variables changed.
When used correctly - statics are fine - I just believe that static methods are OK - static fields are bad. I do NOT want my static methods to effect class state. Static factories are a prime example of static singletons that are alright. This is tricky - as I do like static ‘utility’ type functionality. I think that statics can be used - but I think that you must REALLY understand when NOT to use them 1st - then you can use your best judgment as you go.
Use a static-singleton when there REALLY IS PHYSICALLY ONLY ONE - like a COM port or something. CODE it as a singleton because there is PHYSICALLY only one. In many cases - people code singletons because ‘it seems like there should only need ever be one’ not because there REALLY IS or REALLY MUST BE only one. The truth is that often a pool of objects is better than a singleton in some cases. Sometimes you reach that conclusion later and YOU ARE ALREADY DEPENDENT on SINGLETONS STATICALLY across reams of code. THIS IS BAD. This is why singletons are bad - you are VERY bound to them and changing your mind later is hard.
The singleton-ness of objects
I believe the singleton-ness or non-singleton-ness of an object should be deferred to the container (eg; spring, etc). It is nice to be able to defer that decision and you are not bound to things being either singleton via discrete implementation. In any case - defer to the container! When you do this - you can decide that things should or should not be singletons as their usage pattern emerges.
WinForms and a static Main Form
I will always blabber about this one… One place I do NOT like it is especially when used in Win Forms apps for a ‘main form’ that is statically available. I cannot say why I hate it so much - but it just irks me and smells bad. I have heard the argument that it is convenient and therefore good. I just disagree - don’t do it These main forms are VERY stateful. You do not want to have a static-singleton FULL of state etc. Also - what happens when you want to use this ‘main form’ in a new MDI type version of your application. This main form -as it turns out is not REALLY the main form -now it is just a ‘type’ of form in your application - now you have to go - de-singleton it - touching ALL references to it - and seeing how to pass along the dependencies now… UGH!
One singleton to rule them all
I have heard Spring referred to as ‘one singleton to rule them all’. This is true to a degree. Spring must 1st be accessed as a static singleton - to get the app context. I try to do this ONE time in the startup file and THAT IS ALL. From there - you can just stop statically referring to the app context. In any case - the ‘container’ really is one singleton to own the singleton-ness (note- they are not static now - just singletons by configuration). So - the container really is the only true singleton that does rule them all.
Singletons != statics … not necessarily
So - you do not have to code everything as a singleton!!!! This is excess code that does not NEED to be in your software. Make your own plain-old-objects - and defer their singleton-ness to the container. You CAN have singletons that are that way via configuration - not implementation. Static-singletons are what you want to avoid.
De-Singleton-ing, or static-singleton purging
I have been on many missions to slay static-singletons. Take it upon yourself to do this - go kill static-singletons. Find the 100000 references to your static-singleton. Replace them with some interface reference. Figure out a concrete class that implements that interface or interfaces. Figure out how to get references to your dependent classes (hopefully via spring or the like).
Closing thoughts
I had a collegue that used to say to people in interviews - “Static-singletons are evil can you tell me why I might say that ?”. Good question I guess my thoughts on static-singletons are clear
My Best;
Chris
ALL good stuff in .net land
Working with Windows Messages in .NET
Debugging Visual Studio Designer Errors
An Extensive Examination of Data Structures Part 1: An Introduction to Data Structures
An Extensive Examination of Data Structures Part 2: The Queue, Stack, and Hashtable
An Extensive Examination of Data Structures Part 3: Binary Trees and BSTs
An Extensive Examination of Data Structures Part 4: Building a Better Binary Search Tree
An Extensive Examination of Data Structures Part 5: From Trees to Graphs
An Extensive Examination of Data Structures Part 6: Efficiently Representing Sets
-Chris
Wow - I have been a fan of Redgate for a while. I have used some of their tools in the past (Ants, Sql Compare). In the past I have liked Apex SQL Edit for my SQL Server specific SQL Coding. Well - now Redgate is offering a free SQL Editor here. This comes via my pal John.
Gotta love free stuff;
Chris
Well - the day has come - Resharper 2.0 is out of beta. It is out in the world.
Enjoy the new plug in features etc
Moved to articles section here.
Go google. Google released an AJAX/ Java framework to beta today. Nice work. The demos look pretty cool. There are lots of these AJAX frameworks popping up these days.
Check out this demo - prettry nice ‘desktop clone’.
On a related note; a few weeks ago a google recruiter called me and said that they were looking for Java people experienced with Spring, Hibernate and other open source tools. Great - any of you Java folks lookin’ for work - comment to this post with some contact info and I will get you the google person’s email to talk to him. ( I will also edit your post not to include your contact info )
Google Web Toolkit - Build AJAX apps in the Java language
-Chris
Since I have been upgrading an app to .net 2.0 - that happens to have lots of thread access violations - I have been thinking about this stuff a bunch. This is about the best description of the issues involved with marshalling calls across from background threads to the UI thread.
-Chris
I have been speaking with one of the gents over at SpringFramework.net. I am considering starting a project that would be in the same space as the Microsoft CAB - as a sub-project or sister project for SpringFramework.net . In short - CAB is fine - but I am not the biggest fan. I have spent the past several years working on so called ’smart client’ applications, ‘rich client’ applications, etc.
.Net applications are on the desktop. In most places on wall st - there are .net desktop apps with backends written in Java - this is how it is. That said, many applications still lack the fundamental framework or basic structure for abstracting constant features. They also lack the general seperation of concerns/ tiers that enable applications to scale out.
In no particular order - some important elements to an effective DAF (desktop application framework)
-Binding model objects to view elements
-Grid binding specifically with distinct ‘gridy’ features
-Client side data cache
-Plug in model
-Logging
-Object Factory/ service locator
-Common ways to work with menus
-Seperate persistence tier
-Add in mechanisms for views
-UI extention points
-Resource repository
-Workspace abstraction
-Model/View/ (presenter, controller, some variation of one of these many)
-Testability
I will continue to blog on this project as I am considering features to shoot for and some basic constructs.
RANDOM THOUGHTS…
Plenty more rambling to come as I am chattering about basic thoughts and trying to formulate my real goals.
-Chris
OK - I admit it - I am a ReSharper Zealot! I have been chomping at the bit to make add-ins to ReSharper - Soon - Resharper 2.0 will be production ready - and I will be ready!!!
Thanks to the RSharper OpenAPI. I am able to extend resharper where needed. The 1st 2 plug-ins I will work on are -
#1) Find unused public members at solution scope for a given class. and
#2) Find usages of type in Spring.net config files.
Fun - PS - I am EAGER for the supposed .net IDE that the JetBrains folks are working on!!!
-Chris
Well - I often like to point people to articles that explain programming-isms better than I could (which I must admit are many). In any case - threading is one of those things that fumbles peoples brains. In my morning reading - I stumbled across this clever post about monitors and general “when to do whats” regarding multi-threaded .net programming - good stuff. I recommend reading this for those of you who have ever wondered - to lock, to monitor enter, to pulse or not to pulse .. or when to pulse .. or anything else like these things
Of bathrooms, toilet paper, and thread synchronization.
It seems we have the ‘go ahead’ from Finetix management to have our 1st Developer Session at the new Finetix office space. Solomon has kindly volunteered to do the Java portion of our session. I am sure he will have lots good to say as he has been an avid SpringFramework user.
These sessions ARE OPEN TO THE PUBLIC
Spring Framework Developer Session
Lightweight container for .Net and Java
May 31st 6 - 8 PM
228 East 45th Street
6th Floor
New York, NY 10017
I have a few of these things in the planning - here are my current thoughts:
The Peer Frameworks Series - .Net and Java ‘
1) Spring Framework Developer Session - SpringFramework.net, SpringFramework.org
2) Test Drive Development Developer Session - NUnit, JUnit; Rhino Mocks in .net and Easy Mock in Java
3) Db4o Developer Session - Open Source Object Database in .net and Java
4) ORM Developer Session - Hibernate, NHibernate / IBatis
I will update the agenda as we finish planning it in the next few weeks. Mark from the SpringFramework.net team happens to be here in NYC also so I will be picking his brain a bit and planning the session with Solomon in the coming week or so
.If there are any requests - let me know.
-Chris
To help us estimate food etc - please email me at Spring-dev-session@chrisdonnan.com
