xsharp.eu

Hi Dick,

Interfaces: ... to get some "contract" about what arguments or return types you methods should have...

That's the important fact. In our main programm we have more than 200 customer specific plugins. In VO have written several base classes (as demonstrated in my refactoring sample). Then in the plugIn dll the class is inherited from the base class. The app doesn't have to know anything about the implemention. It just initializes the class and calls the methods.

This could also be done late bound. BUT what if you need a new parameter. With a strongly typed base class (or interface in X#) the compiler complains about the wrong signature.

I like the concept of interfaces very much. One class can implement mutliple interfaces but can inherit just from one class. In our plugins we often have to create multiple classes that do nearly the same because it can just inherit from one base class. With interfaces we can create one class in the plugin and implement multiple interfaces.

Stefan

Hello Stefan, Wolfgang,

SHirsch wrote:The app doesn't have to know anything about the implementation. It just initializes the class and calls the methods.

But I do want the app to know about the implementation! This may be useful in an environment where many people work on the same program but not for projects done by 1 or 2 programmers, like we mostly do. Maybe I've missed the samples where the use of an interface (Except for multiple inheritance) makes sense but I really checked out quite a few of those examples.

SHirsch wrote:BUT what if you need a new parameter. With a strongly typed base class (or interface in X#) the compiler complains about the wrong signature.

Yes, that's great. That's why we strong type everything, also when looking into old code which is not yet strong typed. I add a parameter, get a few (or many) compiler errors, double click them, which works great in VO, and add the default value for the new parameter to all "error lines". So my method calls are up to date in often not more than a few minutes. Why should I use an interface to hide these changes?

SHirsch wrote: One class can implement multiple interfaces but can inherit just from one class.

Yes, that can indeed be useful, I think that is what Wolfgang also posted.

PS: I will try to understand your DO CASE subclass tomorrow....

Dick

Hi Dick,

I think you missunderstood me. The programmers should know the implementation or should have access to. BUT the app itself does not have to know about the implementation.

A real live conference would be a good place to show you some examples where interfaces are a very good use case. I tried to write it down but it's easier to show and explain in real live and answer questions.

Stefan

Stefan,

I would welcome an interactive event like this. Can we plan something?

Robert

Hi Robert,

what are you exactly thinking of?
I was thinking of a classic face to face conference as it was planned before corona.

Stefan

Stefan,

SHirsch wrote:Hi Robert,
what are you exactly thinking of?
I was thinking of a classic face to face conference as it was planned before corona.

Classic, face to face would be great, but is not possible this year, at least that is what I expect.
Would you be willing to do a (short) online demo of this ?

Robert

Robert,

sure, online demo would be possible.
I can demontrate some interface samples from backend apps in X#.
And one GUI sample and some internal samples in VO that use base classes that will become interfaces after migration.
It's not rocket science. All have been demonstated before by someone else. But maybe some real world samples can explain the usage a bit better.

Stefan

Hello Stefan,

Would be a great idea. Despite the extensive sample I still do not really understand what you achieved with the DO CASE & classes.

For a presentation, I've seen many, last one's live where the DevShare's in the UK, it works best if the speaker builds a sample from scratch and changes strategy to go to the end objective, e.g. if you start with a normal DO CASE and change the code to make it, what you consider, better. That's what you are doing in reality as well. Then you are not trying to comprehend large pieces of code and also you are following the speaker the same way as you program yourself.

A good sample is Chris' previous presentation of how to convert a VO program into X#. Very easy to follow, because you just see 'real time' what you would encounter when you would do it yourself, including the compiler errors and how to solve these one by one (and why a certain method to solve it was chosen).

I hope it works out.

Dick