On Jul 31, 2006, at 1:58 PM, Michael Babcock wrote:
> And by that you mean to be very interchangable and not get snagged
> on the different layers from which it may be called, if I
> understand that principle correctly. An example for folks not
> familiar with this would be where you program something using
> objects on a page, then later put them into some other container on
> a different level (say a page within a pageframe). If you've
> designed to the interface, everything should still function just
> fine instead of not being able to find the references correctly.
> That's another reason why it's good to put the code in the highest
> level (in this case, the custom form methods) instead of the
> button.clicks. Also allows for easier re-use if you really need
> it: like instantiating the form and calling it's custom object --
> that's a heck of a lot easier than instantiating the form and
> having to drive down 'n' levels into the object hierarchy to some
> button's click event!
>
> Just trying to help the lurkers...correct me if wrong.
That's one of the main reasons for not hard-coding paths to objects.
But no matter how you reference an object, you should always program
to interface, not to implementation.
The example I gave back when I used to give this topic at
conferences was a light switch in a room. In your app, you want to
control the lighting by turning the switch on and off. Now let's
imagine the switch is a typical mechanical switch with contacts that
are opened and closed when you flip the toggle. In code, you could
write oSwitch.contact1.Closed = .T., or oSwitch.TurnOn(), and either
code would work great. However, if at a later date the switch was
replaced by a mercury switch, or an electronic switch, or a dimmer
switch, the first example of code would probably fail, since it was
written to use an implementation detail of a particular switch,
instead of the public interface all switches are designed to use. By
coding to the public interface, such as the TurnOn() method, the code
will work no matter how the switch works internally.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
©2006 Ed Leafe |
