TPersistent.com

It’s been my experience that Delphi applications are often produced by a single developer or a very small team working largely independently to “get it done”.  You know…no in-line comments, design or requirement documentation, just the code.  Sometimes I have even been told that developers don’t write documentation because the code is self documenting.  While Pascal is very readable for most part there are times you still have to interface with raw APIs, and that code tends to be less readable.  The code itself also never documents assumptions made, how the class instances interact, or reasons for writing things certain ways some of which may no longer apply as RDBMS and other software depended upon, has evolved over time.

Very often these developers are self taught, and there are still many developers actively writing code who started before object oriented programming came into vogue, and design patterns, TDD and other software development best practices became known and proven (I’m one).

Sometimes people continue to develop in ways they are comfortable with, and are understandably more concerned about “getting it done”, than “doing it right”, or they simply haven’t taken the time necessary to hone their skills.  The problem is that eventually they code themselves into a corner where they can’t easily make any changes without risking breakage, and major changes require a rewrite because the code is so tightly bound together.  This “technical debt” can creep up rather quickly when you have cowboy coders, or management that is always pressing for new development to expand the business, and doesn’t understand that payments against technical debt must be made.

Just like the real world, the world of software development has become much more civilized.  You can start a product with cowboy coders, but the moment you want to build a company around it you need resources, and the cowboy coding methods just don’t work in a team environment.  Teams need documentation to disseminate information without requiring a senior (more experienced with the code) member to teach more junior ones (not necessarily junior in terms of technical skills).  This causes a kind of paralysis as you try to grow the team, resulting in significantly higher declining rates of return for the investment in new developers.

It’s never too late to change your ways, and turn in your six gun.  I am reading Working Effectively with Legacy Code by Michael Feathers, and although I’m not that far into it, I would already recommend it.

If you have never heard of DSharp, I would recommend taking a look. It provides a data binding mechanism, which unlike hcOPF’s does not require developers to create objects that descend from a specific base class.  Unlike LiveBindings introduced in XE2, there seem to be no significant unresolved issues (unless related to Delphi QC reports) and you can use it in versions as early as Delphi 2010 according to the repo.  In contrast, hcOPF’s bindings are available to users of Delphi 7 forward.

The TBindingGroup component is similar to hcOPF’s TUIObjectBinder, but is capable of binding multiple collections of disparate objects to controls. In hcOPF you need one instance of a ThcUIOIbjectBinder component per object class being bound. DSharp’s approach certainly provides additional functionality, but at the cost of less design-time validation. For instance, in order to bind a property you need to specify the SourcePropertyName. In the VirtualTreeviewSample if you drop down the list for the SourcePropertyName you will see a plethora of items, only one of which is remotely applicable (View) when you want to specify View.CurrentItem.LastName. If you select View, there is no assistance from the Object Inspector in guiding you to add the additional “.CurrentItem.LastName”.

DSharp also has presenters for the popular VirtualTreeView control, Developer Express controls as well as most of the stock VCL controls.  There is no documentation, but all the source is of course available.

TiOPF also has some binding capabilities (using the MGM pattern) in the current implementation.  I am not familiar with their implementation.

Why is data binding important?  It is the primary mechanism that allows the removal of code from your UI, enabling implementation of the MVVM and similar patterns.

Anyone know of any other binding frameworks or advanced MVVM implementations?