Results 1 to 17 of 17

Thread: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2002
    Posts
    379

    Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Hope this question is not too off topic.

    Occasionally I look at exe's written in .net using a de-compiler ( fun sport). I use it to look at the code to observe design techniques just so I can learn new things.

    The one thing I have noticed with many of these apps is that the use of interfaces is crazy, almost every class has an interface inherited and I cannot make sense of it.

    Does anyone here understand why this technique is so overused and what benefit it gives? I have read the whole 'class contract' story, but in the real world I just font understand it advantage.

    If there is an advantage to this approach, can this technique be used in vb6 programming, or is this pattern just useful when writing .net apps?

    thanks

  2. #2
    Frenzied Member
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    1,598

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    I use interfaces in VB6 code fairly frequently, I find them useful for implementing "plugin" like behaviour for classes. Interfaces have the added benefit of forcing the implementing class to have all the methods added to the class so I can't accidentally miss something if I were just using public subs/methods without using an interface.

    For example, I have a main DLL that has a bunch of functions that my user application calls by passing an object and parameters. The functions in the main DLL can then do tests for particular interfaces on the passed object, and if present the DLL can then call known methods implemented within that object, e.g. (air code, may have bugs):

    Code:
    Public Sub DeleteSomething(po_Object As Object, ByVal p_DeleteId As Long)
       Dim lo_Logger As ILogger 
       Dim lo_Delete As IDelete
    
       ' Make sure an object was passed and that it supports the IDelete interface
       If po_Object Is Nothing Then Err.Raise vbObjectError, , "Object required."
    
       If Not TypeOf po_Object Is IDelete Then Err.Raise 5, , "IDelete interface must be supported."
    
       Set lo_Delete = po_Object
    
       If TypeOf po_Object Is ILogger Then  ' Optionally log info if passed object supports ILogger interface
          Set lo_Logger = po_Object
          lo_Logger.Log "Attempting to delete ID#" & p_DeleteId
       End If
    
       On Error Goto ErrorHandler
       ' Attempt to delete passed ID by calling IDelete.DeleteSomething 
    
       lo_Delete.DeleteSomething p_DeleteId
    
       On Error Goto 0
    
       If Not lo_Logger Is Nothing Then lo_Logger.Log "Successfully deleted ID# " & p_DeleteId
    
       Exit Sub
    
    ErrorHandler:
       
       ' Log error is passed object supports ILogger Interface
       If Not lo_Logger Is Nothing Then lo_Logger.Log "Error deleting ID #" & p_DeleteId & " " & Err.Number & " " & Err.Description
    
       Err.Raise Err.Number, Err.Source, Err.Description
    End Sub
    The above example shows how you can optionally perform different actions based on whether an interface is available or not, which is another useful feature of interfaces.

  3. #3
    Hyperactive Member
    Join Date
    Mar 2018
    Posts
    405

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    You use interfaces in the real world all the time so it is natural to extend them to programming. Consider something like a CD player or a Cassette player. You press 'play' and the music starts playing. It works the same on all CD players. You know that if you press the triangle button, music is going to start playing. The play symbol is universal. Then software based players come out (iTunes, winamp, wmc, etc) and the "interface" remains the same even though lots of things beneath it have changed. You understand what to do as a programmer: you need to put a triangle button in your program so users know how to start music, you know how your program should respond, your users already know what to do, etc.

  4. #4
    Frenzied Member PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Newport, UK
    Posts
    1,208

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Quote Originally Posted by axisdj View Post
    Hope this question is not too off topic.

    Occasionally I look at exe's written in .net using a de-compiler ( fun sport). I use it to look at the code to observe design techniques just so I can learn new things.

    The one thing I have noticed with many of these apps is that the use of interfaces is crazy, almost every class has an interface inherited and I cannot make sense of it.

    Does anyone here understand why this technique is so overused and what benefit it gives? I have read the whole 'class contract' story, but in the real world I just font understand it advantage.

    If there is an advantage to this approach, can this technique be used in vb6 programming, or is this pattern just useful when writing .net apps?

    thanks
    Interfaces also make TDD and unit testing a lot easier, especially when coupled with good design practices like Dependency Injection and IoC.

  5. #5
    Member Grant Swinger's Avatar
    Join Date
    Jul 2015
    Posts
    59

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps


  6. #6

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2002
    Posts
    379

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Quote Originally Posted by Grant Swinger View Post
    After watching the whole video I do now know why this is so common in c# apps, its becuase the IDE will extract an interface on demand..

    the video still did not show the benefits, but at least I now understand why its overused.

    Most of the time I see huge amount of interfaces are in projects where each interface is used only once and that seems pertty pointless.. but hey the IDE can create your interface automaticcaly so I guess why not, just in case you need it in the future.

    If olaf is around would love to hear his take on this?

  7. #7
    Frenzied Member
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    1,598

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Every public VB6 class in an ActiveX DLL is also an interface that can be implemented. So we have a lot of "interfaces" too, we just don't use them that way very often.

    But there's nothing stopping you from implementing ClassX in ClassY. You could then pass calls on that interface back to an internal instance of ClassX in ClassY, or completely replace the standard behaviour of ClassX in ClassY's implementing methods. But the cool part is that you can still pass an instance of ClassY to any method that is expecting an instance of ClassX to be passed to it.

  8. #8

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2002
    Posts
    379

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Quote Originally Posted by jpbro View Post
    Every public VB6 class in an ActiveX DLL is also an interface that can be implemented. So we have a lot of "interfaces" too, we just don't use them that way very often.

    But there's nothing stopping you from implementing ClassX in ClassY. You could then pass calls on that interface back to an internal instance of ClassX in ClassY, or completely replace the standard behaviour of ClassX in ClassY's implementing methods. But the cool part is that you can still pass an instance of ClassY to any method that is expecting an instance of ClassX to be passed to it.
    I honestly still cannot make sense of it.. to create an interface merely because the IDE can do it and for no other reason is perplexing, I still feel like I am missing something.

    jbpro are you referring to interfaces in vb6? I use them occasionally when needed.

    WP

  9. #9
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,840

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Whether they are over used or not is irrelevant. What's important is if you understand what they are, what they are used for and when you would use them. don't worry about whether the IDE can create them for you or not, jsut worry about the other stuff. If you can wrap your head around that, then you're fine.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  10. #10
    Frenzied Member
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    1,598

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    I'm probably missing something about your question and even about Interfaces in C# as I've only dabbled in that language, so I'm just speaking from VB6-land. Based on your comments re: creating an interface merely because the IDE can do it though, I was just saying that VB6 does something similar for every public class in an ActiveX DLL (this might be a COM thing, not a VB6 specific thing I don't know, but there are others more knowledgeable than me in this area that might chime in).

    So if you have an ActiveX DLL with a class called CMyClass, then you have a class that is instantiable and and interface that is implementable.

    Please excuse me if I've completely misunderstood your question and I'm telling you stuff you already know, but I'll post this anyway just in case it helps you or anyone else stumbling onto this thread. If you do something like:

    Code:
    Private Sub MyTest() 
       Dim lo_MyClass As CMyClass
    
       Set lo_MyClass = New CMyClass
       lo_MyClass.DoSomething
    End Sub
    Then that instantiates the class and calls a method on it (as we all know - not trying to suggest you don't know that, just setting the scene here!).

    Now let's say we have a third-party DLL that has a method that takes a CMyClass object as a parameter. Something like this:

    Code:
    Sub ProcessMyClass(po_MyClass As CMyClass)
    That method will call DoSomething() on the passed CMyClass object, but we want to do something else during the DoSomething call, changing its standard behaviour. Assuming we don't have access to the source code of the CMyClass DLL nor the third-party DLL, the task seems impossible. However, if you implement CMyClass in your own class then you can write your own code to do whatever you like. For example, you could create a new class called CMySuperDuperClass:

    Code:
    Option Explicit
    
    Implements CMyClass
    
    Private Sub CMyClass_DoSomething()
        ' Now we can do anything we like here!
       MsgBox "I'm doing something in CMySuperDuperClass!"
    End Sub
    And then we can pass our CMySuperDuperClass to the third-party DLL as if it were simply a CMyClass:

    Code:
    Private Sub MyTest()
       Dim lo_MySuperDuperClass As New CMySuperDuperClass
       Dim lo_ThirdPartyClass As New ThirdPartyDll.ProcessingClass
    
       lo_ThirdPartyClass.ProcessMyClass lo_MySuperDuperClass
    End Sub
    We've "tricked" the third party class method into taking our CMySuperDuperClass object in place of the CMyClass object that it was expecting, and as such we'll see our MsgBox appear as opposed to the default behaviour of the CMyClass.DoSomething method.

    So the above is a bit of a contrived example, but let me give you a realy world example of how this was useful to me (the solution described below was proposed to me by Olaf Schmidt, so full credit to him).

    On some seemingly random deployments of my software, I had a couple of reports of strange behaviour. A short while after starting my program, a third-party software installation window would appear and attempt to repair itself. The weird thing was that my software had nothing to do with the third-party software (no attempt at integration/automation), and my software didn't register any files or mess with the registry or Windows System folders in any way so I couldn't figure out how I was stepping on this other programs toes. To make matters more difficult, only a small number of users were experiencing the problem even though many users had the third-party software installed as well. By Googling I discovered that other users of the third-party software reported the same error without my software installed, so I figured it had to be a problem with the third-party developers software. The developer wasn't responsive to my queries, and I even tried numerous tests systems with the third-party software installed and my program running, but I could never reproduce the problem.

    Eventually, I put in some line-by-line debugging messages for the start-up process of my software, and eventually traced the problem to a single line of code where I was getting the Content property of a VBRUN.PropertyBag object. Weird, but at least I've found something to work with!

    Problem is I don't have access to the PropertyBag object, and another class I'm calling later is expecting a PropertyBag object to arrive. At this point I think I'm snookered. I reached out to Olaf to see if it was an issue with the RC5 library since I was getting the content and shipping it over the cRpcConnection object. It was not a problem with the RC5 cRpcConnection object, but he came up with an interesting possible solution - implement the PropertyBag in my own class and use a cCollection class to serialize/deserialize the data instead, thus completely skipping all normal PropertyBag object code while maintaining the ability to pass the custom cPropertyBag object to code that expects a regular PropertyBag! Here's the code:

    Code:
    Option Explicit
    
    Implements VBRUN.PropertyBag
    
    Private Col As vbRichClient5.cCollection
    Private B() As Byte
    
    Private Sub Class_Initialize()
       Set Col = new_C.Collection(False)
    End Sub
    
    Private Property Get PropertyBag_Contents() As Variant
       PropertyBag_Contents = Col.Content
    End Property
    
    Private Property Let PropertyBag_Contents(ByVal RHS As Variant)
       B = RHS: Col.Content = B
       
       Erase B
    End Property
    
    Private Function PropertyBag_ReadProperty(ByVal Name As String, Optional ByVal DefaultValue As Variant) As Variant
       If Col.Exists(Name) Then
          VCopy PropertyBag_ReadProperty, Col(Name)
       Else
          VCopy PropertyBag_ReadProperty, DefaultValue
       End If
    End Function
    
    Private Sub PropertyBag_WriteProperty(ByVal Name As String, ByVal Value As Variant, Optional ByVal DefaultValue As Variant)
        Col.Prop(Name) = Value
    End Sub
    
    Private Sub VCopy(L, R)
       If IsObject(R) Then
          Set L = R
       
       Else
          L = R
       End If
    End Sub
    Et voilą! Just like that, the problem was solved. So thanks to the fact that any public class in an ActiveX DLL has an interface that is implementable in any other class, a solution was achievable where it otherwise would not have been.

  11. #11
    Member Grant Swinger's Avatar
    Join Date
    Jul 2015
    Posts
    59

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Here are a couple books I used to recommend to my students when I was teaching Classic VB.

    "Programming Distributed Applications with COM+ and Visual Basic 6.0". Chapter 2 is called "Understanding Interface-Based Programming" and starts with the line "Getting a grasp of interface-based programming is really tough." All my students heartily agreed with that.

    Also grab "COM+ Programming with Visual Basic" which has some chapters on interfaces and is worth reading.

  12. #12
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    35,059

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Quote Originally Posted by axisdj View Post
    I honestly still cannot make sense of it.. to create an interface merely because the IDE can do it and for no other reason is perplexing, I still feel like I am missing something.

    jbpro are you referring to interfaces in vb6? I use them occasionally when needed.

    WP
    Of all the replies that are here, I think you should read and re-read the short reply that PlausiblyDamp gave in #4. I don't love TDD. In fact, I don't particularly like TDD, but it sure gets lots of press. Whether you really get into TDD, or unit testing in general without TDD, interfaces aren't just useful, they can be said to be essential. I only hesitate because it is likely that somebody could figure out how to do effective unit testing without interfaces, it just wouldn't be nearly as easy.

    For example, I have a dll that I wanted to test extensively (not TDD, though). That dll makes use of an object that needs to know about certain other objects, though for the purpose of testing the dll, those objects are irrelevant. Since all the objects implement interfaces, I can make up dummy objects that implement the interfaces but don't do anything (the method bodies are empty, properties return nothing, and so forth). By making dummy objects, the object that the dll requires can be well-formed (since it needs instances of the dummy objects), without requiring the actual objects that the working program would normally supply.

    Another example would be having a class that did X then saved a file. If you want to test doing X, you might not want to actually save anything. If the "save a file" was part of a class with an interface, you could create a dummy class that implemented the interface, but the "save a file" method was empty. That way, the class under test can test X without actually saving a file because it just calls the dummy save method rather than the real one.

    I have mixed feelings about the emphasis people put on things like TDD and unit testing, but interfaces make any and all of that FAR easier. That's most likely why you are seeing interfaces everywhere, and most likely why the IDE creates automatic interfaces. The modern VS IDE has lots of tools focused on unit testing. Interfaces are part of unit testing. Therefore, the modern VS IDE makes interfaces to facilitate unit testing.
    My usual boring signature: Nothing

  13. #13

    Thread Starter
    Hyperactive Member
    Join Date
    Jul 2002
    Posts
    379

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Quote Originally Posted by Shaggy Hiker View Post
    Of all the replies that are here, I think you should read and re-read the short reply that PlausiblyDamp gave in #4. I don't love TDD. In fact, I don't particularly like TDD, but it sure gets lots of press. Whether you really get into TDD, or unit testing in general without TDD, interfaces aren't just useful, they can be said to be essential. I only hesitate because it is likely that somebody could figure out how to do effective unit testing without interfaces, it just wouldn't be nearly as easy.

    For example, I have a dll that I wanted to test extensively (not TDD, though). That dll makes use of an object that needs to know about certain other objects, though for the purpose of testing the dll, those objects are irrelevant. Since all the objects implement interfaces, I can make up dummy objects that implement the interfaces but don't do anything (the method bodies are empty, properties return nothing, and so forth). By making dummy objects, the object that the dll requires can be well-formed (since it needs instances of the dummy objects), without requiring the actual objects that the working program would normally supply.

    Another example would be having a class that did X then saved a file. If you want to test doing X, you might not want to actually save anything. If the "save a file" was part of a class with an interface, you could create a dummy class that implemented the interface, but the "save a file" method was empty. That way, the class under test can test X without actually saving a file because it just calls the dummy save method rather than the real one.

    I have mixed feelings about the emphasis people put on things like TDD and unit testing, but interfaces make any and all of that FAR easier. That's most likely why you are seeing interfaces everywhere, and most likely why the IDE creates automatic interfaces. The modern VS IDE has lots of tools focused on unit testing. Interfaces are part of unit testing. Therefore, the modern VS IDE makes interfaces to facilitate unit testing.
    Thanks, that makes sense to me. I will come out and say that I am the type of programmer that will never do unit testing, a complete waste of time. There are studies that show that the most detrimental bugs are found by users not unit test. I guess unit test will catch the minor stuff.. but it does not work for my creative personality, way to corporate.. https://blog.usejournal.com/lean-tes...k-b6500139a009

    Thanks again Shaggy.

  14. #14
    PowerPoster
    Join Date
    Feb 2006
    Posts
    21,077

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Development "methodologies" have been used to sell books, lectures, and training for decades. I've never seen first hand evidence that there was anything more to them, but they sure do seem to inspire religious fervor in their adherents.

    I suspect there is a hope that a bible can eliminate the need for talent and experience. Just watch out for the reaction when you point out the emperor has no clothes.


    I'm not sure how that has any bearing on interfaces though.
    Last edited by dilettante; Sep 20th, 2019 at 08:26 AM.

  15. #15
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    35,059

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    I totally agree with the last two posts. Unit testing has the passion behind it that OO had in the early 90s. It was THE solution to all our problems. Of course, we eventually learned that it really wasn't. It can be useful, some people will love it more than others (I do love OO in a simple form), and we'll still have plenty of problems.

    I've come around to the realization that for some programs, unit testing, after a fashion, is particularly useful, while for other programs it really isn't. The real value that I'm seeing for me is that, if I have a pretty comprehensive test suite that tests some part of a sufficiently large, multi-part, project, then I can make changes to that piece and run the test suite afterwards. What the test suite can tell me is whether or not the changes I made have broken any of the assumptions I had when I last worked on that part of the project. It can't tell me whether the assumptions were right or wrong, just that my changes violated the assumptions. If the project is large enough, that is benefit enough.
    My usual boring signature: Nothing

  16. #16
    Hyperactive Member
    Join Date
    Mar 2018
    Posts
    405

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Quote Originally Posted by Shaggy Hiker View Post
    What the test suite can tell me is whether or not the changes I made have broken any of the assumptions I had when I last worked on that part of the project.
    Also good for making sure the new guy isn't introducing bugs into systems he isn't aware of

  17. #17
    Frenzied Member PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Newport, UK
    Posts
    1,208

    Re: Design Question? Interface usage in .NET advantages, appy theory in VB6 apps

    Quote Originally Posted by Shaggy Hiker View Post
    I totally agree with the last two posts. Unit testing has the passion behind it that OO had in the early 90s. It was THE solution to all our problems. Of course, we eventually learned that it really wasn't. It can be useful, some people will love it more than others (I do love OO in a simple form), and we'll still have plenty of problems.

    I've come around to the realization that for some programs, unit testing, after a fashion, is particularly useful, while for other programs it really isn't. The real value that I'm seeing for me is that, if I have a pretty comprehensive test suite that tests some part of a sufficiently large, multi-part, project, then I can make changes to that piece and run the test suite afterwards. What the test suite can tell me is whether or not the changes I made have broken any of the assumptions I had when I last worked on that part of the project. It can't tell me whether the assumptions were right or wrong, just that my changes violated the assumptions. If the project is large enough, that is benefit enough.
    Like all things in software development I tend to find a bit of pragmatism goes a long way....

    If I am working in .Net then everything is OO and a lot of the code I tend to write in .Net lends itself to TDD. I can certainly agree with the benefits you mentioned but I also find that thinking of the tests first and working in a TDD fashion helps me to focus on a problem and usually results in cleaner code. Without that focus I can often end up with code that might work but is often a bit of a sprawling mess.

    If I am doing anything in Python or Javascript I rarely need to deal with complex OO and the code I would use these languages for doesn't lend itself to TDD (or even unit testing) so I wouldn't bother.

    To me it is a tool - if using it in a given scenario makes things better then I will use it, if not then I won't

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width