Please the perfect object stand up!!

-

I al­ways thought: why peo­ple write this very long posts? Here you have it.

 

How do I de­sign my ob­jects? What is the set of con­straints that dic­tate my de­sign de­ci­sions? People talk about ob­jects in very dif­fer­ent con­texts. A cer­tain amount of con­fu­sion de­rives from not iden­ti­fy­ing the con­texts for our ob­jects.

 

First, kings of them all, there are busi­ness ob­jects. My li­brary is full of OO books that de­scribe how to de­sign these guys. We have pat­terns and anti-pat­terns. Everybody is out there pro­mot­ing their own method­ol­ogy. But if we go deep enough, the most im­por­tant de­sign task in cre­at­ing them is as­sign­ing re­spon­si­bil­i­ties. This con­cept is as old as OO it­self; it finds its roots in CRC cards. But I di­gress. Once again, when you de­sign your busi­ness ob­jects you have to be very care­ful to as­sign re­spon­si­bil­i­ties to the ob­jects that have the right in­for­ma­tion to per­form them.

 

It would be nice if this was all you have to code. A crazy bigot (like me) would think that all the rest is in­fra­struc­ture (ala naked ob­jects). But we live in the real world, so let’s get down to it.

 

A sec­ond cat­e­gory of ob­jects I of­ten en­counter are net­work ob­jects. These are the guys you use to com­mu­ni­cate data across tiers (logical, phys­i­cal, web­ser­vices). They are usu­ally quite dumb ob­jects, not too much logic in them (if any), and your ap­pli­ca­tion cre­ates them by fill­ing their prop­er­ties from the more no­ble busi­ness ob­jects. Something along the line of the value ob­ject pat­tern. Is as­sign­ing re­spon­si­bil­i­ties a very im­por­tant task here? Heck no!! They don’t even have meth­ods!! The most im­por­tant char­ac­ter­is­tic they have is band­width op­ti­miza­tion; you want to re­trieve a whole bunch of stuff in one sin­gle round trip. More of­ten than not you sac­ri­fice every­thing else (manageability, good de­sign) to achieve that.

 

This is why I don’t be­lieve the quite com­mon ideal of re­mot­ing your busi­ness ob­jects. The set of con­straints you use to de­sign them is com­pletely dif­fer­ent (often op­po­site) to the con­straints needed to go over the wire. When any­thing goes over the wire it be­comes just data. Moreover not all of your busi­ness state needs to go on the net­work, but this is an­other story

 

Another com­mon ob­ject cat­e­gory is data­base ob­jects. There is a big de­bate if they are the same as busi­ness ob­jects or not. I dont’ want to go there, but If you want them to be the same you usu­ally prag­mat­i­cally sac­ri­fice a bit of OO pu­rity to make them more sim­i­lar to the data­base ta­bles (you don’t want to fight your ob­ject re­la­tional map­ping layer, you want to help it out). To say this in a more pos­i­tive way, you de­sign your do­main model with an eye on how you are go­ing to per­sist it. If, on the other end, you are will­ing to cre­ate a sep­a­rate set of ob­jects to rep­re­sent data com­ing from the data­base, then the main con­straint for these guys is the same as your data­base ta­bles: nor­mal­iza­tion. This is not sur­pris­ing as they are mir­rors of your data­base. Again as­sign­ing re­spon­si­bil­i­ties and be­ing net­work friendly take the back seat in this case.

 

There are many other ob­ject cat­e­gories I of­ten found use­ful (i.e. façade ob­jects). I don’t want to dis­cuss all of them here. Things are al­ready bor­ing as they are. The cen­tral point is that it is very hard to de­fine generic guide­lines that work well in all the dif­fer­ent con­texts. You got to think about your con­text first.

 

The funny thing is that I work in a place where we are sup­posed to de­sign fea­tures that are gener­i­cally in­ter­est­ing in all these sce­nar­ios. You use C# to code all of them. Oh well, de­sign is the art of choos­ing trade offs

Tags

2 Comments

Comments

Luca Bolognese s WebLog Please

2009-05-31T19:48:40Z

PingBack from http://​woodtv­s­tand.info/​story.php?id=694