Question Reasoning on the class call (XAML)

[CoUSCoUS]

Hello !

I'm not used to programming GUIs and I'm looking for the most correct reasoning to develop my little application.

I need to extract data from an HDF5 file and then call a DLL so technically, my application is not complicated but I'm wondering about the following.

Knowing that on my application (XAML), I have two classes, one for the data extraction and another one for the DLL management, what is the best philosophy:
- Put the execution of my functions in the constructor and create an instance of my class each time I need it?
- Create an instance only once and call methods?
- Create an intermediate class that bridges the gap between my GUI and my different classes?
- Merge my two classes?

What do you think ? How do you try to think your application when you start ?

 

[Skydiver]

Is there a real reason why you need full blown class for DLL management? If not, then all you really need is a static class that exposes methods that call the DLL. No need to create an instance of this static class.

For the class that extracts data, does it maintain any kind of state? If not, then like above you can just get by with a static class.

As for merging the two class, take a step back and review the SOLID object-oriented design principles. If you believe that you'll still follow those principles even after merging then go for it. Personally I think that for testing purposes, keeping them separate would be a better idea. Maybe what you are really looking for is a facade or adapter class that makes it easier for your UI to interact with the other two classes.