Archive for January 2010
Yes it’s true… there in is a framework that acts just like mockito for javascript: jsMockito!
The stubbing action looks pretty cool, and I’ll try in depth later when I’m home. But here’s a quick sample to whet your appetite:
var mockedObject = mock(Array);
when(mockedObject).get(1).thenReturn("hello world");
No tags
Or am I? 
Today I did something that made me step back and recall a time long long ago when I was working with SOAP on a project. See, I had to integrate a PHP application with a SOAP service and used a utility to generate all the client objects and stubs I needed, then ran into a weird problem. One of the fields in the response object contained a string… of xml. This meant I had to go and parse data manually out of that field by hand rather than having a nice object model created by the utility I used.
“Those stupid morons! Why can’t they learn to embrace the technology they’re using!”
Why did they have to go and embed xml inside a cdata tag!? Why couldn’t they just import the namespace for it (it was schema-less anyway) and include it in the SOAP body??
Anyway, what triggered this recollection? I was working on a SOAP service that returns, in addition to some information used by the application, a binary attachment that is read into a 3rd party library on the client side. Let’s say it’s a PNG or something. Anyway, we decided to try out some different image adapters on the server end and I discovered that I could change the format to SVG and not only would the 3rd party library used on the client be able to parse it… I wouldn’t even have to change ANYTHING on the client side because the 3rd party library automatically detected the type. So I switched the output to SVG and reran the client app… perfect! It worked fine. Then I looked at the raw soap packets it produced while testing it with SoapUI:
<image><!CDATA[[<?xml version="1.0"> <svg width="100%" height="100%" version="1.1" xmlns="http://www.w3.org/2000/svg"> ...]]></image>
*Facepalm* 
I suppose to my credit, it’s not as if the client app itself is meant to parse the SVG data itself anyway.
No tags
No tags
-
How to use git svn with apache projects
No tags
8
Why I Hate Classical Singletons
2 Comments · Posted by James Carr in Object Design, Thoughts
Recently a colleague asked me why I’m so against using singletons… why do I think they’re so bad. The answer is quite simple… when you use a singleton you’re essentially saying that your object accepts this dependency and only this dependency, it will take no substitutes. Since the dependency isn’t substitutable, it’s difficult to swap it out with a different dependency without modifying the code.
This is a direct violation of the Open/Closed principle, and ensures that whenever behavior needs to be changed you’ll need to go in and modify that object. By favoring IoC over using a singleton you can make it easy to swap the dependency for something else to change the behavior.
Of course, this is what I call the “classical singelton pattern” … you access it via something like
FooBar foo = FooBar.getInstance();
That’s bad in more ways in one. However, a lot of times singletons are used because developers wish to have one and only one instance of an object used throughout the application. IoC supports this because you have control over how many instances are created and wired throughout the application, and frameworks like Spring and Guice create singleton scoped beans by default. But make no mistake, even without any kind of injection framework I’d still use dependency injection over singletons any day.
No tags
