The Ancient Art of Programming

Conversions: All in a Day’s Work

Back in the day, when I was a C++ Developer on the Microsoft platform, it always struck me as weird that half of my code base consisted of String conversions¹. The reason for all this conversion fun was that there were at least half a dozen string types in Microsoft C++: there is the plain char*, the Unicode wchar*, LPSTR and friends (LPCSTR, LPWSTR, LPCWSTR, LPTSTR, LPTSTR, LPCTSTR, and LPCTSTR), the MFC CString, the STL basic_string, the Visual Basic BSTR, and its C++ wrappers _bstr_t and CComBSTR. And I’m probably forgetting quite a few. Each library used a different string, so conversion was all in a day’s work.

Imagine my joy when I started programming in Java, some 10+ years ago. “Woohoo! Just one string type! And garbage collection too! No more conversions, I am going to be so productive! Finally, I will have time for a Real Life!”

Fast-forward to the present, and I still don’t have that Real Life I wanted. I wonder what went wrong. As it turns out, conversion is still all in a day’s work. The only thing that has changed is the types we’re converting.

If you look at the classic architecture of an Enterprise Application, it will look something like this:

I am counting eight conversions in this picture. Granted, you can skip the Data Transfer Objects by using Domain Object directly, and the SQL can be generated by using an ORM tool. However, using an ORM tool does not mean that there is no conversion at all; it is just a higher-level abstraction. You still have to define the metadata (Hibernate mappings, JPA annotations, etc.) to do this conversion, of course.

In my experience, a typical Enterprise application consists of very little “Business Logic”², but mostly Conversion Logic, so I suppose that conversions are still all in a day’s work.

Guess I’ll never have that Real Life.

<hr/>

1 - The other half consisted of reference counting and releasing. Makes you wonder what’s left.<br/> 2 - An most of the Business Logic is hardly logical.<br/>

This entry was posted on Thursday, January 10th, 2008 at 13:15 and is filed under .NET, Java. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

6 Responses to “Conversions: All in a Day’s Work”

1. Wouter Says:
   January 10th, 2008 at 19:39

   Welk een tranentrekkende tragiek! De treurnis schreit ten hemel! Never that REAL LIFE (twee hoofdletters zijn eigenlijk onvoldoende voor het echte leven…). Snif!

2. Uri Boness Says:
   January 11th, 2008 at 0:09

   Brilliant

3. Alef Arendsen Says:
   January 12th, 2008 at 16:04

   Now we’re always arguing that those conversions should be there to make our software more maintainable, et cetera and that we should just take them for granted.

   Now the real question is: does not having a Real Life bring the world anything in terms of app maintenance or should we just skip all the conversion and start pumping stuff directly from the HttpServletRequest into the database :).

4. Paul Gielens Says:
   January 15th, 2008 at 17:07

   Join the dark side

   A common theme throughout all modern application architectures is a need to transform data from one form to another to have it in the right form for the task at hand. Today’s applications sport a number of data transformers. A common transformation usually encapsulated as a proprietary data access layer inside applications is designed to minimize the impedance mismatch between application objects and relational rows. However, other mappings to navigate object-xml, and relational-xml exist. This impedance mismatch is not unique to applications. As SQL Server has evolved as a product, it has had to add a number of these modeling and mapping mechanisms across the services it provides within the product. Most of these mappings are produced in a point-to-point fashion and each requires a different means to describe the point-to-point transformation.

   http://www.microsoft.com/indonesia/msdn/nxtgenda.aspx

5. Mats Helander Says:
   January 21st, 2008 at 13:34

   It’s a really good point.

   First, for some reason, “they” thought we cared about the multiple possible underlying representations for our strings (cue the assembly level objections about how this can save 5 cycles and a rant about bloat in modern applications).

   Now, for apparently similar reasons, “they” seem to think we care about the multiple possible underlying representations for our entities (cue the relational objections about how this can save 5 cycles and a rant about the bloat of object oriented programming).

   The “they” in question, as we both know, are the hooded figures living on the dark side of the moon, spending every waking minute conspiring against us to thwart any opportunity we might have for a Real Life.

   /Mats

6. Bob Bane Says:
   January 31st, 2008 at 1:32

   When I started out programming in Java, the “conversions” were the first thing I noticed. Depending on the level of brain-damage in the libraries you’re using, you’re either upcasting when removing objects from a generic container, or saying new X (new Y (z)).xMethod(new A(b, new C(d))).

   Bleah.