You can emulate properties by means of getter/setter methods:
Function Value() As Integer
Sub Value(Assigns v As Integer)
And if the class already has a property with that name you can use the Implements keyword to bypass the conflict:
Dim Value As Integer ' the class property
Private Function GetValue() As Integer Implements MyInterface.Value
Private Sub SetValue(Assigns v As Integer) Implements MyInterface.Value
Dim foo As MyInterface = New MyClass
foo.Value = 1
That would seem a very bad design. Every time you add an interface to a class you have to remember to add the data stores to the class too - not exactly encapsulation as we know it.
Furthermore the biggest advantage of interfaces and protocols is that they are types in their own right and cut straight across the class hierarchy - putting the data store into the class that implements the interface seems like a weird hybrid that isn’t even necessary if you turn interfaces into proper protocols.
There is a difference between implementing and adding code (essentially overtiding an empty method in the case of interfaces/protocols).
With your way you can forget to do it and end up with a “This item does not exist”. You can even end up with hard to track bugs if you use the interface as a type and with casting refer to a non-existing property (which should result in a crash even though the compiler does not complain)
IF you. were able to add properties as well as method the property would be part of the things you MUST have in order to implement the interface
You literally couldn’t have the property not exist
Same as if now you claim to implement an interface e then delete one of the required methods