Using Interfaces Versus Event Definitions?

What’s the general rule of when to use Interfaces versus creating new event definitions and using RaiseEvent [MyEventDefName] ?

I’m not sure if I should move to using Interfaces or creating event definitions in my custom classes.

I think I can accomplish a better design model where my custom thread class object runs and then when it’s done it can either call its pWindowReference.ThreadFinished() method (using interfaces) or do a ‘RaiseEvent’ ThreadFinished, which is then implemented in the window that it exists.

Using interfaces seems easier but still not ideal. Defining Events and then using RaiseEvents EventName seems to be the more “Right Way” of doing it. I’ve used both in previous projects, but obviously I’m still a bit hazy on them.

Suggestions, Recommendations?

Raise an Event, that’s the OOP way to do it.

If you have otherwise unlike classes that need to share common methods and may be called interchangeably in like circumstances, use Interfaces. A good example are the Readable and Writable Interfaces where the thing being read from or written to may be wildly different but still need to be called in the same way. The calling code doesn’t need to know where the data is coming from or going to, only that it needs to read or write it.

It’s a little hard to answer your question directly because these aren’t mutually exclusive, nor are they even interchangeable.

Thanks Kem, that actually helps with clarification of their intended uses.

Norman makes an important point that I’d like to underscore: Events are the only way for a super to communicate with a subclass, not only to send information, but retrieve it as well.

That probably doesn’t impact you, Justin, but I just wanted that here for posterity. :slight_smile:

[quote=57430:@Kem Tekinay]Norman makes an important point that I’d like to underscore: Events are the only way for a super to communicate with a subclass, not only to send information, but retrieve it as well.

That probably doesn’t impact you, Justin, but I just wanted that here for posterity. :)[/quote]

Well I’m new to XOJO, but if I needed to have a super class obtain data or behavior from a subclass I would have used a virtual method which the subclass would overwrite to provide it’s own implementation…

[quote=57430:@Kem Tekinay]Norman makes an important point that I’d like to underscore: Events are the only way for a super to communicate with a subclass, not only to send information, but retrieve it as well.

That probably doesn’t impact you, Justin, but I just wanted that here for posterity. :)[/quote]

Virtual methods as well.

Norm -

Excellent points. Understood on the differences of interfaces versus events.

The reason that I’m mixing Interfaces and Events in this thread is that I’ve seen a few examples now from Xojo folks that use Interfaces for things that I thought could have been done with events instead, like the ‘WindowUpdaterInterface’ example that was posted here in the forum, and an example in Aaron Ballman’s “Ramblings on REALBasic” book with the use of the “MessageReceiver” interface in tandem with threads.

Technically true, I guess you could design it that way. I just don’t know why you would. (For the purpose of passing information to and from a subclass, I mean.)

James, I’d recommend Events over virtual methods for this purpose. If you go back to code months later and create a new subclass, you won’t have to remember to override the method. Events provide a specific visual cue.

I think what you’re missing is the fact that in both scenarios you outlined in your original post, you aren’t getting around the “cannot update the UI from a thread” restriction. Both the event and the method call are still part of the thread. What things like WindowUpdaterInterface and MessageReceiver do (not directly but through the broader implementation) is remove the action from the thread context. Normally by using a timer.

I like using events. For a comparison of techniques (inheritance with methods, inheritance with events, and interfaces) check out User Guide Book 1: Fundamentals, Chapter 5: Classes, Sections 2, 3 and 5.

Ah, right … The running thread context is the issue.

I like events for some things
But I’ve seen people completely use events for EVERYTHING from object creation, initialization, etc.
And that works against some of how Xojo works natively.
But you can do it.

[quote=57466:@Norman Palardy]I like events for some things
But I’ve seen people completely use events for EVERYTHING from object creation, initialization, etc.
And that works against some of how Xojo works natively.
But you can do it.[/quote]

That’s the kind of issue that I think some Xojo developers struggle with: When to use what and where: Interfaces, threads, timers, events, modules, etc. I tend to use modules too much versus using classes.

Sounds like a perfect topic for a future Xojo Webinar: When to use what and why.

Paul? :wink:

[quote=57469:@Justin Elliott]Sounds like a perfect topic for a future Xojo Webinar: When to use what and why.

Paul? ;-)[/quote]
Heh. More like a 20 hour college course on object-oriented design!

This is on the topic list, though!

Well having had a quick look at the documentation on this it appears to me that there is very little difference between an event and a virtual method except for:

  • Events give you a better visual presentation, but the price is that once it has been implemented in a sub class, it must be redefined in that class if it is to permeate down to any sub class of the sub class

  • A typical virtual method lacks the visual presentation, but can be overwritten at any level in the class hierarchy

Would that about sum it up?

There’s a much bigger distinction. Events are implemented, not overridden. With an overridden method, you get just the implementation at the leaf node. Any other implementation of that event in a super is ignored. With events, you get all the code in each level of the class hierarchy being executed.