Loading ...
Sorry, an error occurred while loading the content.

RE: [XP] Separate Gui-components from the logic

Expand Messages
  • Charlie Poole
    Hi Roland, ... Almost all IDEs make this all too easy to do. It s wrong. Just resist. ... Who will create these objects? Having either one of them create the
    Message 1 of 4 , Jul 30, 2006
    • 0 Attachment
      Hi Roland,

      > Today I started work on a dialog in Attracs to separate logic
      > from the GUI-components. In Delphi it is very easy to write
      > code directly in eventshandlers for buttons and other
      > components as soon as something changes. It works well but I
      > guess it is not so good design and not easy to test.

      Almost all IDEs make this all too easy to do. It's wrong. Just resist.

      > The form TDeductionPriceForm have about 20 GUI-components,
      > some are readonly and some are editable. I have made a new
      > class TDeductPrice that is completely independent of
      > everything in Attracs to make this class testable. The plan
      > is to create an instance of TDeductPrice when
      > TDeductionPriceForm is created and destroy TDeductPrice when
      > the dialog closes.

      Who will create these objects? Having either one of them create the other
      will result in a dependency that makes things hard to test.

      > Each of those GUI-components have a current value that can
      > affect the logic in some way. Now there is a method
      > TDeductionPriceForm.ReCalcDeduction that collect those values
      > and then change values on others depending on conditions.
      >
      > If I now move the logic to the new class
      > TDeductPrice.ReCalcDeduction then I need to have a current
      > copy of all GUI-components values in that class before the
      > recalc. And after that I need some method like
      > TDeductPrice.GetUpdatedGUIValues to update the GUI components
      > in the form TDeductionPriceForm.

      Find a partner or two to work with and do a CRC exercise to figure out the
      responsibilities of these two classes. You'll probably end up with an MVP
      pattern, but you'll actually understand it if you invent it in this way.

      > I don't have the feeling that this is the smartest way to do this.
      > It's a lot of copying between the classes but I can't think
      > of another way.

      As you mentioned in a later post, Observer is your friend here.

      > I can't update the components directly from TDeductPrice as
      > this create a dependency to the rest of Attracs.
      >
      > What opportunities do I have?

      Read up on Model-View-Presenter. But first, try the CRC exercise I
      suggested. I believe you'll quite naturally find most of the wrinkles of the
      pattern.

      Charlie
    Your message has been successfully submitted and would be delivered to recipients shortly.