You must read this blog post from François Piette. Great simple advice on separating GUI concerns from the processing logic and wrapping these processes into classes.

-
You must read this blog post from François Piette. Great simple advice on separating GUI concerns from the processing logic and wrapping these processes into classes.

Unfortunately the "RAD" approach may be the quickest path to development but it does not lead to manageable and maintainable code for the future.
http://francois-piette.blogspot.com.au/2013/02/application-design-ideas.html

Comments

  1. Stefan GlienkeMarch 1, 2013 at 1:05 AM

    RAD is the path to the dark side (in terms of clean and testable code)!

    ReplyDelete
  2. Lars FosdalMarch 1, 2013 at 1:50 AM

    It's unfortunately also a pattern that is very hard to unlearn for those that started out with RAD.

    ReplyDelete
  3. Stefan GlienkeMarch 1, 2013 at 1:56 AM

    Even more unfortunately that Embarcadero encourages people to use that pattern (cough LiveBindings cough).

    ReplyDelete
  4. Lars FosdalMarch 1, 2013 at 1:58 AM

    The LivingDeadBindings...

    ReplyDelete
  5. Colin JohnsunMarch 1, 2013 at 2:24 AM

    Maybe I'm old school but I prefer to "wire-up" my bindings in code rather than use some fancy wizard or graphical tool.

    It's harder to debug and troubleshoot when your data bindings and expressions are all hidden inside a component. It's also easier to track the history and intent of the code explicitly in source control than when it is stored implicitly in a DFM file.

    ReplyDelete
  6. Colin JohnsunMarch 1, 2013 at 2:26 AM

    Lars Fosdal "LivingDeadBindings"? Care to explain? :-)

    ReplyDelete
  7. Lars FosdalMarch 1, 2013 at 2:33 AM

    I also prefer doing it in code.  

    I even prefer to explicitly hook event handlers in code, and that is actually because the f'ing DFMs have so much Explicit junk that screws with the contents.  You should NOT have changes to a DFM by simply viewing it.  Long story short, with three people working on the same forms - DFM linked event handlers sometimes gets lost on commits as you assume it is just a set of Explicit junk changes and resolve the conflict by using your version instead of theirs.

    ReplyDelete
  8. Lars FosdalMarch 1, 2013 at 2:38 AM

    I have felt for some time that the whole late binding through RTTI is a stroll down the wrong road.  When we write that code, we already explicitly know the root class and the properties and methods that we are setting up for later.
    That we can't have a type strong, compile time validated wrapper with run-time hooking, but have to resort to RTTI enumeration and identification via string literals, just feels wrong.

    ReplyDelete
  9. Colin JohnsunMarch 1, 2013 at 2:50 AM

    Lars Fosdal Yep, all of this RTTI hook-up is just there to facilitate a "RAD" way of binding properties for those who don't like to code.

    This is the reason, we end up inheriting crappy code. It's because programmers brought up in the "RAD" style of programming never learn to program properly and end up being cargo cult programmers. You only need to follow Nick Hodges code rants to understand the pain :-)

    ReplyDelete
  10. Stefan GlienkeMarch 1, 2013 at 2:50 AM

    Lars Fosdal Actually for a compiler vendor compile time safe binding would be super easy to implement because all the parts are there. They could work similar to how events work.

    ReplyDelete
  11. Lars FosdalMarch 1, 2013 at 2:56 AM

    Stefan Glienke - Precisely.

    ReplyDelete
  12. Stefan GlienkeMarch 1, 2013 at 3:37 AM

    I think one difference between a Delphi'ish compile time safe binding and as it is done by RTTI is that the RTTI way is more like duck typing.

    If I bind to the FirstName property it does not matter of what type the instance is I bind to as long as it has the FirstName property (same goes for invoking methods the RTTI way).

    The compiler would be more strict about it if you for instance define a property and say this is for the TPerson.FirstName property. It would not work with another type that also has a FirstName property but is not inherited from TPerson.

    ReplyDelete
  13. Lars FosdalMarch 1, 2013 at 3:41 AM

    Considering the duck typed reference also could mean that the referenced fields have same name but different types - I could very much live with that strictness.  I'd still be able to use RTTI explicitly if I wanted to duck type.

    ReplyDelete
  14. François PietteMarch 1, 2013 at 10:20 AM

    Building classes for every concet in your application doesn't totally shut RAD down. If you build non visual components, you can still use many RAD features easily. I do that frequently.

    ReplyDelete

Post a Comment