Oh No! DTO! Should DTOs
Oh No! DTO! Should DTOs have public variables? Or should they have private variables with getters and setters?
Oh No! DTO! Should DTOs have public variables? Or should they have private variables with getters and setters?
I have been looking for a while for a refactoring tool that could improve the encapsulation of my code. More specifically, I want to be able to analyse a closure of code (like what JDepend does), and make methods private, package protected or protected as much as possible.
Of course, if it is to be useful, there has to be a good way of defining root classes and methods, ignored name patterns (getters/setters for those who are still addicted to those) etc.
If anyone reading this has seen such a tool, please let me know. Otherwise, I am considering writing one using something like RECODER. But there is a bit of a stiff learning curve ahead…
Martin Fowler has an excellent piece about MDA on his blog. Also be sure to check out Fowler’s link to Dave “Bederra” Thomas’ article on UML.
It seems like quite a few people who are knowledgeable about MDA dislike Fowler’s article quite a bit. I thought it was time someone who knows MDA and is not starry-eyed about it chipped in. Yeah, that would be me, your humble host ;-). I have worked quite a bit with Compuware’s tool OptimalJ, and presented this tool in many forums.
I think MDA’s concept of the Platform Independent Model (PIM) and Platform Dependent Model (PSM) captures a very important point. Application development involves both domain knowledge (platform-independent), and technical architecture (platform dependent). It is a Good Thing if the platform independent model could be created independent of the platform specific model. This is especially true for the numerous applications whose most substantial effort is in creating CRUD (Create Retrieve Update Delete) behaviour for straight-forward datatypes. This is not too much more advanced than the basic “powerbuilder way”. For applications where it is appropriate, it is extremely beneficial. So far, MDA is right on the money, and probably the smartest available investment you could make (IMHO, of course).
However, the next transformation in MDA is from the Platform Specific Model to the Code Model (or just code). Now this seems to me to be very wrong. The transformation from the PIM to the PSM is a change in semantics, as an application gets mapped to an architecture. But the transformation from PSM to code is just a different view of essensially the same model. This is the Together/Intentional Programming/Jackpot idea, and I think it is an idea that is going to be significant long MDA is forgotten. During the evolution of modern programming tools the logical structure of a program has become more and more visible as a part of the coding process. For a simple example of this, just notice how no self-respecting IDE would come without and outline view in this day and age. The tree structure contains a lot of the same information as an UML class diagram would. And it maps one-to-one to the code.
I get the impression that MDA and UML researchers are often too far removed from the day-to-day struggle of programmers to see what kind of tools and ideas catch on. I also get the feeling that focus on visual models that they tend to forget that the programming language source code is also a model. This is of course only partially true, as witnessed by tools like Eclipse’s Modeling Framework, which can use Java code as a PIM in MDA-like transformations. The book “MDA Explained” explicitly describes code as a model. I still feel MDA only pays lip service to the code model.
I do not share MDA’s enamorment with visual models. There are some things that can be adequately expressed visually, but many things that can’t. Martin Fowler has pointed repeatedly to the issue of visually representing behavior. Dave Thomas does the same in “UML2, OCL, MOF, EDOC - The Emperor Has Too Many Clothes“. I won’t belabor the point, but I want to remark that visual programming languages are by no means new. I have here a picture of topological sort in ProGraph. ProGraph was first developed in 1982 and is not in widespread use today. Looking at the example side by side with the same code in a textual language, this does not surprise me. On the other hand, a class model - or a tree navigator - can give an excellent overview of the structural relationships within a program.
My claim is then that visual languages are good at only a subset of the elements that makes up a complete program. At others, it is a step back relative to the precise textual description of source code. This is the most important reason why MDA as it is currently described will not be where we end up in ten years from now.
There are a few points I still want to make:
In closing, I must express that I am somewhat frustrated with intelligent people who criticize MDA without having seen it in action. Mostly, my frustration is in the fact that valid points get dismissed because said intelligent people don’t have enough knowledge about MDA. If you are such a person, and are in or around Oslo, Norway - or you’re coming to rOOts 2004 - I am more than willing to give you a lightning-quick demonstration of MDA so you can criticize it with some authority. Mail me at johannes (at) brodwall (dot) com. Thank you.
Permalink Comments off
I have been real bad about writing in my blog lately, but I am finally back. It’s been a crazy few months, including a new job, which of course takes up some time. I have now officially stopped working as a consultant, but I still take some projects on the side when time permits. My next interesting event will be Software 2004, where I am both a speaker at the .NET track (adoption of Java versus .NET from JavaZone), and for the eXtremeProgramming.no track (practical demonstration of pair programming and test-driven development). If you are in Oslo next week, I strongly urge you to join the eXtremeProgramming track. I am pretty sure it will be the first of its kind in Norway.