UML Love

Claus Nielsen wrote on 2/25/2007 4:03 PM

Brilliant!

mono wrote on 2/28/2007 1:54 PM

¡Excelente! xD

golfman wrote on 3/2/2007 4:01 AM

Good developers have, for a very long time, been taught the value of having reduced coupling between interfaces. Unfortunately this is of benefit to only some projects and for many *real world* scenarios leaves many male developers on the scrap heap of life.

The aim of the project under discussion here is to go against the flow and increase the coupling between the <<interface>>man and the <<interface>>Female. The project is judged a success if the object implementing the man interface makes many frequent uses of the services provided by an object implementing the female interface.

At first glance the female interface appears to have a great architecture, looks to be well engineered and it's seems fairly easy to use but the business logic behind the provision of access rights is extremely complex and most developers simply will never understand it without some extensive reverse engineering - which is of course illegal and usually fruitless because the business logic uses self modifying code so something that granted you access to the interface today may not work tomorrow.

Unfortunately, due to the combination of a seemingly simple interface but an extremely complex encapsulation of business logic most developers never end up using the interface as they would like. They often end up using their concrete implementation of the man interface in the absence of an object implementing the female interface. To keep the project moving they will often use an abstract (non existent) implementation or a mock implementation (don't go there) of the female interface.
While these may be fine for unit testing they're no good if you want to build a complete system. There's no way you will never make it to production without a concrete implementation of the female interface.

golfman wrote on 3/2/2007 4:14 AM

(Cont'd from above)

Once you manage to instantiate an object implementing the female interface there is something you need to do to prevent it from being deleted. You're going to need to make sure you reference it often and have a very high 'uptime'.

To increase 'uptime' your going to have to make some adjustments: less pizza, less stress (leave that Hitler style boss you have) and more exercise and more healthy foods. You may also increase your chance of success with more 'chick flicks' and less 'arnie' movies. These requirements make many developers wonder if they should just stick to unit testing.

Another common problem developers have is that the female interface they would like to couple with gets used in an abstract way or via a proxy ie., some other object implementing the male interface gets to use the female interface exclusively (the female's existing boyfriend). With most operating systems exclusive female locking seems to be the mode supported although these days you might be able to find an implementation that supports the ACCESS_SHARED mode but this is always associated with the risk of crashing your whole system and you must then be careful of being exposed to Open Sores (a term borrowed with thanks from Hani).

These were just a few tips from the team leader. I hope it all works out for you and if it doesn't then don't stress out: just remember that thousands of developers around the world have the same problem trying to establish a relationship whereby female instances extend their private attributes.

Jean-Seb wrote on 4/24/2007 8:45 PM

Great! But forgot the interaction with the "Money" generality.

billybnugroho wrote on 4/26/2007 6:56 AM

I just can't believe how ridiculously entertaining this article is. On top of that is your comment, golfman - it's just as wicked as the article itself xD
But, golfman, I do have to say that your comment *does* provide an opening to a successful coupling, "... because the business logic uses self modifying code..."

*fingers crossed* let's just hope it modifies in your favor ;)