Why Outlook Sucks: Part 1 of 900,000
Let’s find an email from Toni regarding her party next weekend. There appears to be a search box in the toolbar.
Wait.. that seems to be only for contacts. Nevermind.
There’s a find button to the left which brings up a toolbar, but it appears to search only the Inbox. Unfortunately I have a bazillion folders and rules and have no idea where the message is located, so I’ll go over to the “Options” menu (of all places) and start an “Advanced Find”.
Uh.. ok. I have no idea why I need “More Choices” or “Advanced”, and apparently I’m still searching only the Inbox. Let’s “Browse”..
Now that we’ve systematically selected every possible place the email could be–which could apparently be in my Calendar or Contacts–we can click OK and go back to the “Advanced Find†dialog and click ‘From..’
Great.. the engineers decided to reuse the same old contact finder dialog. There are a lot of people with a ‘Toni’ in their name, so we’d better embark on a separate sub-find quest to identify the correct contact record. Make sure you click ‘Find Now’ and not ‘New Search’ when you’re done.
When we come back from a coffee break, we see Outlook proudly presenting a result set, sorted by date, most recent first. That’d be great, except that if I’d received it recently, I probably wouldn’t need to use an ‘Advanced Find’ to locate it, would I? The results are also displayed within the dialog for some reason instead of the main window, so I guess I’ll have to keep this up on my second LCD, which I’ll now repurpose as the “Dedicated Advanced Search Dialog Monitor”. Whatever.
Just for shiggles, let find an email in Apple’s Mail.app.
Holy freaking crap. I typed in ‘toni party’, and it gave me emails from Toni about her party, sorted by likely relevance. It was immediately clear how to search and the results took less than a second to display, despite the fact the PC is apparently faster spec-wise and I have magnitudes more email on my MacBook Pro. Huh.
Update: Part 2 of 900,000
Tags: microsoft, outlook, rant
. 23 Feb 07 | Computer | Comments (19)
Singletons Cause Cancer
It’s been said before. I’ll say it again. The singleton pattern sucks. From a pragmatic point of view, it has two primary drawbacks: reuse and testability.
Reuse
A public static getInstance() method is, by definition, statically bound at compile time. Since you can’t override static methods, reusing singleton code via inheritance means you’ll need to create a new getInstance2() method. No matter how creative you get with this method name, you have to accept that users of your code will periodically call the parent types public getInstance() method instead of your spiffy new getInstance2(). Working off an interface largely becomes a moot point since the developer must know the exact type of singleton they want to use at compile time in order to invoke the correct getInstance() method.
How do you configure a singleton without a parameter to getInstance(), which would not be consistent with the intentions of the pattern? Since the instance is constructed internally using a non-publically-accessible constructor, there isn’t a convenient way of introducing configuration information before it’s created.. unless the singleton is aware of a configuration source at compile time with yet more static binding. This makes the code very inflexible, as developers intending to reuse it will be at the mercy of your pre-chosen configuration mechanism, which may not be appropriate for their circumstances, or even unit testing.
Testability
Unit tests generally require control over the lifecycle of the class under test to fully validate proper state transition and contractual validity. Since you, the master of the known universe, are writing the software, you’ll certainly write negative scenarios into your unit tests to assert proper failure handling. If intentionally introducing a negative test results in an irrecoverable state, how do you throw out the singleton and start the next case with a new one? You can’t. What if your test case is creating a tricky concurrency scenario emulating multiple systems within the sandbox of a single JVM? You can’t (trivially). What happens when you discover you need multiple instances of the singleton within your application? You can’t. Time to refactor.
Additionally, unit testing of code using static singleton dependencies has a high potential of awkwardness due to an inability to swap out implementations for mock objects. Under the principle of designing for testability, quality and maintainability, hackishness is not a quality to aspire to.
Conclusion
Singletons can be hazardous to your health, seriously jeopardize your family’s safety, and have been classified as ‘terrorist patterns’ by the U.S. government. The fact that an application only needs one instance of something does not mean the object should be designed that way, and there aren’t very many scenarios where singletons are appropriate. Do as the Jedi do and use them with consideration and responsibly.
Tags: architecture, design, pattern, rant, singleton, software
. 11 Jul 06 | Computer | Comments (10)