Now someone help me out, I'm starting to see posts about Test Driven Development (TDD) where they're talking about creating lots of interfaces. Is this true? Tell me it isn't so! I need some education on this topic... [Russel Beattie Notebook]
oy!
Start writing JUnit tests to make your code more thoroughly tested and you'll see the value of interfaces right away. If you've got some code that jumps through hoops - you should be able to instrument your code to make it jump through those hoops. If you can't do it easily - you've probably designed your code to be too difficult.
Interfaces are a necessary evil in Java because of the static typing and the lack of message passing a'la Smalltalk (or in my case Objective-C).
If you want to stub out a mock object in Java it's difficult - actually impossible - to invoke the same method signatures against 2 different class instances unless they share at least one common interface.
You don't have this problem in dynamically bound languages because you simply just say something like this in Objective-C:
[myObject methodToInvoke];
If your object happens to respond to a message (or in Java-speak responds to a method) - stuff happens. You can extract interfaces from implementations later - something that's difficult in Java if you're not working in IDEA.
Are interfaces ugly in Java? I think so. You should get a compiler warning when you don't know if the target object can correctly respond to a message, but it shouldn't be an error. At the least, you should get a no-op.
One nice way around the whole factory/interface/new problem is the use of a thinned down context interface a'la EJB or enviromental acquisition a'la Zope.
You basically need 2 pieces of code to do this:
A ContextSupport interface to set/get a context
A Context interface which basically works like a glorified chained hashtable. You just want to be able to get/put instances of classes into this thing. On construction - you take in an existing context - or a null context.
The idea is simple: stick things into your context like this:
myContext.put(TextDecorator.class, new HTMLDecorator());
where TextDecorator is an interface and HTMLDecorator is a concrete class.
get things out of your context like this:
Arrange your application like a tree of classes that implement ContextSupport and you can chain your contexts and overload key/value pairs of interface/implementation as you move down your class tree.
The advantage here is that once you've created something, you just interact with it through the interface and through a context. Classes don't even need to know that implementations are generated by a factory - they just need to know that an object 'should' exist and obtain it.
What does this have to do with testing? Hey - you can just replace implementations with MockObjects and test your application with a lot of 'production' code and replace branches with mock objects as needed.
You can have a reference test that does this:
myContext.put(TextDecorator.class, new HardCodedDecorator());
Now just use the interface and you've got some benchmark for what your code should do. Rinse and repeat with your 'live' class. Instant regression tests!
Or - you can just write your code really really simply and just instrument class instances with JUnit.
Whatever - testing is good. Interfaces are absolutely necessary when testing code in Java.
10:09:36 PM
Seeing as I've pretty much finished off the Canada411 channel - here's my not-so-uninformed 2 bits:
First off - the mailing list is where you should go if you want to get anything done.
The documentation for Sherlock is handy, but it is by no means complete. The nice thing with the mailing lists is that actual engineers from Apple are there and they do respond.
The SDK itself is ... pretty awful.
I can do some neat things with it since it does support web standards, but there is no decent way of debugging your code. If you make the slightest syntax error, your function or trigger code will not execute at all. No error, just an effective no-op.
The bright side is that since it does support XPath/XQuery, you don't need to write too much code, but hey - functions that don't run at all are not pleasant.
It means you can't write very much code without getting scared and then wanting to test right away. Mind you - this may be some twisted way of enforcing religious testing. I just don't like it.
Having to code in JavaScript and XQuery is a pain. I would have liked to see something more like Python or Ruby used as the scripting language- both are built into OS X anyway.
Thread support is awkward at best in the current SDK.
All threads are implicitly executed on the developers behalf, you just say I want to notify trigger "x, y and z" and then the runtime fires off 3 threads to run those triggers concurrently.
The upside is that you don't worry too much about synchronization and dead lock.
The downside is that you have very little control if you know what you're doing. For example, it would be nice to be able to fire N threads and retrieve N webpages back from a target server.
The problem with trigger notification method is that the only thing you can do is:
DataStore.Notify("DATA.action.myTrigger");
That's just not good enough. Sometimes you want to pass state information in the message. You just can't do it using the current SDK.
That said, there are a lot of good things going for Sherlock.
1. Standards
It uses XPath and XQuery. Proper W3C standards so the things you learn aren't proprietary and ill thought out (or at least not horrendous)
2. Autoupdates
Anything I deploy in Sherlock is automagically updated on the client side if I update the server. This is nice - just like Java applets.
3. An active live community.
The sherlock-channel-de mailing lists that apple hosts actually has people who know what they are doing and can respond to most questions. It's hard to describe, but the Mac community 'feels' like the Python community. People actually like to help each other out.
Double click now opens Canada411 to show full address information
Proper error handling when the Bell server is overloaded.
Record counts come back much faster now
This will probably be the last release of the Canada411 Channel. It works 'good enough' for me that I don't have an interest in making it any better.
You can find the full source code and english/french NIB files here: http://homepage.mac.com/vng1 under the 'Source Code' section of my homepage.
All code is released under the GPL.
There is currently one big bug in the program - the directions don't quite work. I have the code to fetch the directions page, and to rip out the directions, distance and the ETA times from mapquest, but I can't figure out how to skip over 'dead' space in a table.
If you feel like hacking up my code, go ahead.
12:23:19 PM
I don't understand people who stick the dock on the right side or the bottom of the screen. It doesn't make any sense on OS X.
It's the NeXTStep place to put it.
So what? It made sense under NeXT because the scrollbars were placed on the left hand side of a window (which still makes more sense than placing the scroll on the right). Putting the dock on the same side as your scroll bar forces a user into choosing to use the scrollbar or the dock, but not both.
On that note - why the hell are the close, minimize and maximize buttons located next to each other in OS X? They really should be placed like the old NeXT/Windowmaker layout. Does anyone actually use the toolbar minimize button?
I'm no usability expert, but I can tell you when I can't click on something because it's too small, when I click on something by accident when nothing else should be around... it pisses me off.
Industrie Toulouse
11:02:37 AM
