OO Design, Hobgoblins and Foolish Consistency

I started using C++ over 15 years ago. I still use it every day on the job. I have picked up some other OO languages along the way as well. When I learned OO principles, there was a quote I heard often:

When an OO problem looks too difficult, add more objects.

It usually worked, but price was complexity. Simplification by adding complexity. After years of maintaining my own code, as well as other’s, I no longer believe in the philosophy of the quote. My current philosophy fits better with:

When an OO problem looks too difficult, stop using OO.

This works really well, I just had to stop feeling guilty about losing faith in OO. Nowadays I am a mentor to younger developers (for better or worse) and one of my big challenges is getting them to understand why foolish consistency to OO is a problem, not a solution. Over engineering is a real problem (not just with OO). I attribute much of my change to:

  • Using Agile processes that force me to ask “Am I going to need it?”. If I am not going to need it, why am I coding it?
  • Working with dynamic languages to get side projects completed quickly. What if all my projects worked as well as my side projects?
  • Realizing that code is just a means to provide value to a user. The user wants the value, not the code.
  • Discovering that code is suppose to be temporary, it’s the data that lives on. The code you wrote yesterday sucks, and it always will.
  • Understanding that simpler does not mean not as good. It never means complicated, but it can sometimes mean elegant or even robust.

If you think it’s hard to get young developers to understand these ideas imagine how hard it is to get experienced developers to accept them. There are signs all over the place, you just need to look for them.

SVG in IE (Update)

I made some changes to the IESVG behavior. I am trying to get better feature coverage without making the rendering too slow. I have been testing the code using some SVG images from different places, trying to figure out what parts of SVG seem to be more important than others. Recents chanegs include:

  • Basic support for gradient fills. It’s pretty weak and may have not SVG-correct.
  • Basic support for svg:g elements.
  • Switched code to use DOM methods (appendChild and replaceChild) instead of slower, string-based methods.

I plan to add more support for gradients. I also plan to add some scripting support. You can do scripting now, but you need to treat the elements as VML, not SVG. I plan to add some methods to the VML elements to make them appear more SVG-like when scripting.

Files can be downloaded from here. I added the SVG lion to the samples:

Sample files: lion.htm (IE), lion.xhtml (Firefox)

Update: Fixed 404 on link above.


Inspired by Emil’s emulation of the canvas tag in IE, I put together a simple SVG emulation behavior for IE. As with Emil’s code, I am making use of Internet Explorer’s VML support. The behavior will walk the SVG element structure and attempt to convert to appropriate VML elements. It’s far from complete, but it does a decent job. Supported features include:

  • Basic shapes: rect, ellipse, circle, polyline, polygon and path.
  • Simple fills commands (in attributes and CSS): fill and fill-opacity.
  • Simple stroke commands (in attributes and CSS): stroke, stroke-width, stroke-opacity and stroke-linejoin.

The behavior works on Inline-SVG, not standalone SVG files. Currently, the behavior only works on static SVG. You can’t use Javascript to interact with the SVG. Javascript can only access the VML elements. I plan to add support for and gradients (although this could be hard). I also want to eventually add support for scripting by adding SVG-like methods to the VML elements. You’ll notice that the SVG elements are in an explicit svg namespace. This seems to be a requirement for the behavior to work, but I am trying to remove the need.

Required files: iesvg.htc, iesvg.js

Sample files: iesvg_test.htm (IE), iesvg_test.xhtml (Firefox)

The sample files are exactly the same, only the extensions are different. Firefox must have Inline-SVG in an XHTML file. There is probably a way I can get Apache to trick Firefox into thinking the HTML file is an XHTML file (or get IE to think the XHTML file is an HTML file), but I haven’t got it working yet.

Update: Core files have been updated. Test files have gradient examples.

Live Clipboard & Open Laszlo

Two really cool announcements this week: Ray Ozzie’s Live Clipboard concept and Open Laszlo running on DHTML. I see both announcements having long term effects.

Live Clipboard is just so simple and useful, it has to get adopted, standardized and built into any serious web and non-web applications. That’s right, desktop applications and OS shells should also support Live Clipboard. Users will love it. Moving data between web and desktop applications should be as simple as copy/paste.

Applications built using Open Laszlo can now be run using Flash or DHTML runtimes. So those Laszlo guys were serious after all. They have a demo running on both runtimes. Very nice. This goes a long way toward platform and runtime independence. A trend I’d like to see continue. Maybe a XUL based runtime could happen too.