Issues understanding the use of Interfaces in your Rubberduck website entry

[OmarZini]

https://rubberduckvba.wordpress.com/2020/02/27/vba-classes-gateway-to-solid/

I'm still trying to get my head around this post and I certainly need some help here. I can't seem to properly understand the use of the Interface. Initially, the goal was not to expose some members of the class due to the fact that it could raise a run-time error, which we want to avoid (compile errors are preferred). When not exposing a procedure member like a function, the best way is to use an Interface. I get that. But two questions arise:

• Why haven't you included the FillData signature in the Interface just as you did with the ChangeLastName Function? One could argue that then the Interface might not be implemented in other classes because they don't need to implement this Function but, wouldn't this comply with the Interface Segregation Principle (i.e. having several interfaces is preferred over having one)?

• Anyways, let's stick to the Factory Design, wasn't the ultimate goal of this post to rely on compile errors? What is the point of having the Factory if it's still using the FillData method. I can see it throwing a run-time error as soon as we pass in wrong data types.

I'm by no means an expert, I'm trying to understand the concepts you are exposing.

Thank you very much for your posts and the RubberDuck project!

[retailcoder]

Follow-up questions (via LinkedIn/InMail):

---

I leave here my answer to Ben's reply to my post in case you could somehow paste it into the comments section:

"Thanks a lot for your time and explanations! It has taken me a couple of hours to understand your explanation, read through the post again and write this answer. I hope it's up to yours!

Let me give you some background and why it's still a bit difficult for me to properly understand some concepts, because I'm afraid I'm still a little (less!) confused. Please, bear with me. [YOU CAN SKIP THE FOLLOWING SECTION AND READ "QUESTIONS"]

I have been using VBA for quite some years and then got attracted by C# and the possibility to create good code. I thought that I could somehow leverage the knowledge of one language and "implement" in another, and all the way around. Half a year ago I discovered that Interfaces could be used in VBA and I thought to myself that this would be even better to reinforce theory and become a better "programmer" (I'm a Mechanical Engineer but I love programming). And then I came across Rubberduck and thought to myself: "you not only can make better applications, but Rubberduck will help you grasp good OOP concepts that you will use in other programming languages!". I think - maybe others won't agree - that the beauty of Rubberduck is not only the high value it brings in when programming in VBA but also the high educational component that brings into the community to broaden their (our) minds in a world that has been taken by storm by coding.

I "understand" concepts like delegates, events, abstract classes and interfaces from C#. I know about inheritance and the cornerstones of OOP, what's more, I "understand" them! The problem is, I understand them individually, not as a whole, i.e. how can I use them at once (if possible) in an application and conforming to SOLID principles (which I'm still trying to understand!). That's why I'm trying to read all your entries and understand them, to improve my VBA applications (very complex, with lots of forms), my VBA skills and C#. All in all, I want to become a better programmer, BUT I'M IN THE FRUSTRATING STAGE WHERE THE BIG PICTURE IS NOT CLICKING :( (I'm not yelling).

QUESTIONS

I think everything makes much more sense now. I must admit that I have been a little bit misled by the "compile-error" thing as if it was the sole purpose alongside encapsulation.

So let me see if I got it correctly, starting from your clarification on figure 4.4. By instantiating the Person class first, we can use FillData as a constructor as we keep the rest of the class members private. Thus, by next using the Interface it is as though we could "hide" what was before exposed by the class (i.e. FillData) and show what had been hidden (like a ON/OFF switch). In short, by not being able to use FillData a second time (thanks to casting Person to IPerson) we achieved the same functionality as that of a Constructor plus having a compile error. The compile error is just when accessing FillData from outside, the potential run-time errors from within FillData code (e.g. passing in wrong data types) will still have to be prevented by using error handling. Am I right?

Then the Factory Design Pattern allows for "hiding" the Person class and avoid the compile error we got when we tried to invoke the constructor a second time (from the constructor).

Could you please confirm this is what you meant through your answer?"