I've been reading about access modifiers in VB.Net lately, and there is something that I can't really understand: How do elements in a Class (or Module) inherit the modifiers of their enclosing block?
For example, suppose you have a Friend class Bla in an assembly, with a public method Foo:
Friend Class Bla
Public Sub Foo
(...)
End Class
Does it behave differently than when Foo is set to Friend? If so, which one do you advise?
Friend Class Bla
Friend Sub Foo
(...)
End Class
Thanks!
In my opinion, it doesn't matter whether one specified public or Friend for Foo because the enclosing class is available only in this assembly.
One can choose to restrict the access modifier for a method/property than that of the class. In your example, the method Foo can be private` as well, which means the method won't be available to callers, including other classes in the same assembly.
One can access methods through class/instance. If the class is private, what use is a public method?
EDIT: On a side note, it is possible for you to return an instance of Bla to the caller (which is in other assembly). In that case, the caller should be able to call public method, if Foo is declared public. This is my assumption.
If someone does jump through the reflection hoops required to access Bla, they don't need to do so again to then call Public Sub Foo, but they do for Friend Sub Foo.
Related
I have a class that I would like to extend by defining a new class that contains the first class as a public property, as well as additional added properties. However, the class that I'm extending has multiple derived types, which should be treated the same in the extension class.
Below is an example of what I am trying to do:
Public Class ClassA
End Class
Public Class ClassB
Inherits ClassA
End Class
Public Class ClassC
Inherits ClassA
End Class
Public Class BaseExtended
Public Property Foo As ClassA
Public Property ExtendedMetaData1 As Double
Public Property ExtendedMetaData12 As Integer
End Class
Public Class DerivedExtendedB
Inherits BaseExtended
Public Property Foo As ClassB
End Class
Public Class DerivedExtendedC
Inherits BaseExtended
Public Property Foo As ClassC
End Class
The code that uses an instance of any of the 'extended' classes would then need use that instance appropriately depending on it's type. There would be many cases where the property 'Foo' needs to be accessed and modified outside of the class that it belongs to.
If I were to implement something like what I have shown above, that would require that I first cast it to the required type before accessing or modifying it. Ideally I would like to do that inside the 'DerivedExtended' class; The alternative, I think, would be to duplicate code to cast that property would [hundreds of times] in the client code.
Private Sub ClientUsesObject(bar As BaseExtended)
' Perform a task that is agnostic Foo type
' Would not require that Foo be cast to any specific type
If bar.GetType() Is GetType(DerivedExtendedB) Then
Dim barCast As DerivedExtendedB = DirectCast(bar, DerivedExtendedB)
' Perform task that requires Foo to be of type ClassB
ElseIf bar.GetType() Is GetType(DerivedExtendedC) Then
Dim barCast As DerivedExtendedC = DirectCast(bar, DerivedExtendedC)
' Perform task that requires Foo to be of type ClassC
End If
End Sub
What I'm looking for is advice outlining or describing a design pattern that can handle this situation. I've searched for quite a while, and have not been able to find any examples that solve this problem.
I realize that this may be somewhat of an "XY" problem. I'm working with existing code that simply assumes all instances are of the same derived type (when in fact some instances are of the other derived type). As such, the existing code does not work. To me what I've tried to outline above seems like the most straightforward path, but I'm open to alternative if this is just the wrong approach.
This pattern of type covariance in derived classes is the canonical reason for what is called in C++ the "Curiously Recurring Template Pattern" and has been called in .NET the "Curiously Recurring Generic Pattern." I believe it's also sometimes referred to as "F-Bounded Polymorphism" (not a computer scientist, so I might have the reference wrong).
You can write a base class like this:
Public Class Base(Of TDerived As Base)
Public Overridable Property foo As TDerived
End Class
And then use it like this:
Public Class MyDerived
Inherits Base(Of MyDerived)
End Class
Then, the derived class has a property foo whose type is MyDerived. No casting required by clients.
However, this has some limitations. It works best when you don't need to switch back and forth between derived and base. There is no one Base, so you can't declare instances of it. If you want to be able to declare something as Base, then you end up needing to fall back on a non-generic base class. This will still work well for certain usage patterns where you don't need to convert from base to derived, but otherwise you run right back into the casting problems you are trying to avoid.
Eric Lippert has written a bit about this pattern. He's always interesting to read, so I'd recommend looking up his commentary.
Another alternative to consider, if the generic approach doesn't work for you, is code generation. You can use T4 templates to process a compact description of what your code should be, and generate the code files from them. A long list of casts is less tedious if you only write the machinery to generate it, you don't write them all out explicitly.
Consider the following simple class hierarchy:
A.m
classdef A < handle
methods (Access = protected) %# protected vs. private
function foo(obj)
disp('class A')
end
end
end
B.m
classdef B < A
methods (Access = public)
function foo(obj)
disp('class B')
end
end
end
Class B inherits from class A and is supposed to override the protected foo method as public.
If we try to instantiate the derived class, we get the following error:
>> b=B();
Error using B
Method 'foo' in class 'B' uses different access permissions than its superclass 'A'.
The weird thing is if foo was defined as private method in the superclass A, the code works just fine when we invoke the overridden method:
>> clear classes
>> b=B(); b.foo()
class B
So is this a limitation/bug in MATLAB OOP implementation, or is there a good reason behind this behavior? (Code was tested on R2012b)
As a comparison, in Java the rules state that you cannot reduce visibility of a method in the sub-class, but you can increase it, where:
(weakest) private < package < protected < public (strongest)
This appears to be a limitation of Matlab. I've tried all combinations of attributes. Matlab throws errors whenever the attributes are different, except when the method of A is private, in which case the attributes in B don't matter.
In other words, unless the method in A is private, the attributes of the method in A and B have to be the same. I guess this does make sense to some extent, in that TMW say "If a method is visible to the subclass, attributes have to be the same; if a method is not visible to the subclass, the subclasses can do whatever they like".
Can anyone explain me in VB i need to use Public Shared Sub so it can be accessed from another form.
But what this "Public" and "Shared" means?
Who is public?
With who is shared?
If it is public shared does this means some other software or "some hacker app" can easier have access to this sub and it's values?
In VB.NET, Shared is equivalent to static in C# - meaning the member belongs to the class, not an instance of it. You might think that this member is 'Shared' among all instances, but this is not technically correct, even though VB.NET will resolve a Shared member though an instance invocation.
public class1
public shared something as string
public somethingelse as string
end class
The following code illustrates how VB.Net allows you to access these:
...
class1.something = "something" 'belongs to the class, no instance needed
dim x as new class1() with {.somethingelse = "something else"}
Console.WriteLine(x.somethingelse) 'prints "something else"
Console.Writeline(class1.something) 'prints "something" <- this is the correct way to access it
Console.Writeline(x.something) 'prints "something" but this is not recommended!
...
Public means any linking assembly can see and use this member.
The Public accessor keyword simply means that the method, property, etc. is visible and callable from outside of the DLL or Assembly that defined it.
The Shared keyword means that the method, etc. is not "instanced". That is, it is part of the Class definition only, and not part of the objects that are created ("instanced") from that Class definition. This has two principal effects:
The Shared method can be called at anytime, without actually having an object/instance of that Class. and,
Shared methods cannot access any of the non-Shared parts of the Class definition (unless an object instance is passed to it). They can only directly access the other Shared parts of the Class definition.
I am a C# programmer but I have to work with some VB.Net code and I came across a situation where I have two methods on an interface with the same name but different method parameters. When I attempt to implement this interface in a class, VB.Net requires explicitly declaring "Implements MethodName" after the method signature. Since both method names are identical, this is confusing the compiler. Is there a way to get around this sort of problem? I suspect this must be a common occurrence. Any thoughts?
N.B. This was more a case of the programmer not verifying that the interface in question had not changed from underneath him.
How is this confusing the compiler?
The compiler expects to find an implementation for every method signature, and distinguishes the implementations by their signatures.
If the signatures are identical/undistinguishable (in most cases it means that the arguments are of the same types in the same order) you'll get a design-time error related to the interface, saying that the two methods cannot overload eachother as they have the same signature.
So, in any case, the compiler should not be confused.
Should you need further assistance, please attach a code sample - these things are relatively easy to resolve.
Tip: When writing the implementation, as soon as you write down "implements MyInterface" and hit Enter - Visual Studio will create a "skeleton" code of the implementation, which saves you writing the method signatures and correlating them to the interface.
Example code of having two methods with the same name and everythign working well:
Interface MyInterface
Sub MySub(ByVal arg0 As DateTime)
Sub MySub(ByVal arg0 As ULong)
End Interface
Class MyImplementation
Implements MyInterface
Public Sub MySub(ByVal arg0 As Date) Implements MyInterface.MySub
...
End Sub
Public Sub MySub(ByVal arg0 As ULong) Implements MyInterface.MySub
...
End Sub
End Class
You can make the method private and give it another name.
Like:
Private Sub SaveImpl(ByVal someEntity As IEntity) Implements IRepository.Save
this will look to the outside like: someRepository.Save
This is kind of two questions (one more specific than the other).
If I have a method like this:
Public Function Blah(String Foo)
End Function
Can I qualify Foo against another type (for instance can I require that Foo be a String that also implements IInterface?).
I'm imagining something vaguely similar to this:
Public Function Blah(RandomObject Foo Where RandomObject Is IInterface)
End Function
Additionally, is there any way to qualify the Type parameter?
For instance, can I require that the Type I take as a parameter is of a particular class tree?
Public Function Blah(Type t Where Type Of String)
End Function
I should mention that I am using this in the context of a property of an attribute so the class declaration itself cannot be generic (this is purely focused on qualifying a method parameter rather than typing a class and its methods).
This looks like a case for generics to me. Your method signature would be something like this in VB.NET:
Public Function Blah(Of T As {IImplementedByT})(Foo As T)
This specifies that Foo can be of any type T as long as T implements IImplementedByT. Note that this method can be generic without the containing class needing to be generic. If you want T to be a class derived from RandomClass that also implements this interface, you can specify both constraints:
Public Function Blah(Of T As {RandomClass, IImplementedByT})(Foo As T)
You can do the first for a generic type, but not for a nongeneric type. Basically a variable (including a parameter) can only have one compile-time type, so you can't say "it has to be a Foo and an IBar - you have to pick one or the other. Generics let you say "it has to be some type T where T derives from Foo and implements IBar" though.
Generics is a huge topic - too big to cover in a Stack Overflow answer - but Microsoft has a good introductory article.
As for your second question - no, you can't do that. The Type value will only be known at execution time, so it has to be an execution time check. You can write that check fairly easily though, with Type.IsAssignableFrom.
Not sure what you mean by "Foo be a String that also implements IInterface".
string class is sealed, so you can't inherit from it & hence you cant implement an interface on top of it.
I hope I am on the right page.