I have a bunch of different forms that I would like to create a base MustInherit class for. One function I would like them all to contain is a shared function called GetForms(). I know that you can't declare a shared function MustOverride so I did the following in my abstract class:
Public Shared Function GetForms() As List(Of OrderForm)
'to be overridden in child class'
Return Nothing
End Function
And this in my child class:
Public Overloads Shared Function GetForms() As List(Of OrderForm)
'do stuff'
End Function
Will this cause problems down the line, or is this an acceptable workaround? It has a smell to it, but it will enforce that all my forms include a shared GetForms function.
EDIT I realize that if this were possible with interfaces, I would use one, but you can't declare shared functions in interfaces and I would like to make sure that this is a SHARED function.
This has a smell because it creates a false expectation of the behavior of the code.
You mention that your reason for doing this is that 'it will enforce that all my forms include a shared GetForms function'. This is only partly true. Yes, they will all have the GetForms function, but you're not actually forcing the derived classes to implement their own version of it. If you forget to implement the function on one of them, you'll be calling the base version, and you won't get any sort of warning about it from the compiler.
That is the smell: it can't actually enforce the behavior that you want, but it creates an impression, at first glance, that it can. This will lead to headaches 6 months from now when you're adding a new Form type and you've forgotten the convention. You'll get no warning that something's wrong until you start getting bad results during testing.
If you want to enforce behavior, you have to do it using instance members; using MustOverride (abstract) functions or an interface.
You can have static (Shared) methods like that, but you can't enforce the implementation of them.
Each static method is local to it's class, you can't overload it in a child class or make it abstract (MustInherit). You have to use an instance method (non-static) to get the object oriented aspects that you want.
Yes, that does smell!
Looks like you should be using an interface instead.
Here is a vb.net article: http://www.developer.com/lang/other/article.php/939411
Why wouldn't you simply declare it as:
Public MustOverride Function GetForms() As List(Of OrderForm)?
Static methods aren't inherited, so the expectation of overriding is not something we want to encourage. In other words, I think you might be barking up the wrong tree here.
Related
I am having a "weird" situation of my VB.Net modules, as per my understanding, Module in VB.Net means static class so I have implemented a couple of helper modules with couple of functions each, let's have some examples for better explanation (free hand code, may contains syntax problem):
Namespace Helpers
Module HelperA
Public Function FunctionA() As Boolean
Return True
End Function
End Module
End Namespace
Namespace Helpers
Module HelperB
Public Function FunctionB() As Integer
Return 1
End Function
End Module
End Namespace
When I start coding in Visual Studio and type Helpers., both FunctionA() and FunctionB() are show up in the recommended auto-complete dialog which I have not type HelperA or HelperB yet, I have some C#.Net projects with static class and I found such behavior does not apply to C#.Net static class.
It is weird to me and inconvenience since I am now having 50-ish functions under a single namespace, have done some Google but nothing could be find, could anyone suggest a solution (besides change Module to Class) or any keywords to search with?
Any help will be appreciate!
Module doesn't technically mean static class. Static in VB.net (with regard to functions) is Shared, and there is no Shared Class. What I think you want is a sealed/abstract/not-inheritable class with static/shared functions (you'll be able to call the functions without an instance of the parent class, but you'll still have to reference the parent class when calling the function). If that's the case, then do something similar to the following:
Public NotInheritable Class HelperA
Public Shared Function FunctionA() as Boolean
Return True
End Function
End Class
Having said that, the only difference I've found—at least for practical purposes—between a shared function and a module function is that module functions can be called without referencing the module.
I've been using dart for quite a while now. If I want to implement dynamic getters, setters and functions for objects of a class, I can make use of the noSuchMethod-method. But what if I now want to have such a dynamic getter, setter of method on class layer? In Ruby, for example, if one wants to implement a dynamic class method, one would define the method_missing-method on the class object, like for example:
class Test
def self.method_missing
//Do some matching, return result or error
end
end
How would I achieve this in Dart?
I don't think you can do this in Dart without mirrors/reflection.
I also don't think this is very useful.
You can't call a static method on a 'dynamic' type and therefore you can't mock static methods.
If you need this you should just make it a normal method instead of a static one.
You can just override noSuchMethod as noticed here
I've got a class called ArtificialIntelligenceBase from which you can create your own artificial intelligence configuration sending some variables to the constructor or you can make a class that inherits from ArtificialIntelligenceBase and in the constructor of this new class just call the function super() with the parameters of the configurations.
I've also created some examples of artificial intelligences in classes, AIPassive, AIAgressive and AIDefensive. Obviously all of them inherits from ArtificialIntelligenceBase.
The point is that there're only few public functions in the base class. The variables in the base class are read only and the non public functions are protected in case you need to apply some modifications on them when created another pre-defined AI.
You can also create another AI just calling the base class sending some parameters in the constructor like this: new ArtificialIntelligenceBase(param1, param2, param3, param4);
I've tought about make the classes as a singleton because the classes can never change and once setted, their variables never change.
The question is: Is the singleton the best pattern to do this? Because I'm not sure.
PD: You don't need to explain any patter, just mention the name and I'll search for how it works
PPD: I'm developing in AS3. Just in case it helps
Thanks
In general, singletons are evil. I don't see any reason in your case to use a singleton, either. It sounds like you're using your own version of a factory method pattern (using a constructor somehow?) or maybe a prototype (I don't know AS3 one bit), but if you're looking for other patterns a couple of other ones are abstract factory and builder.
You don't need to use the singleton pattern to limit yourself to using only one instance per type of class, though. It doesn't help avoid redundancy.
I have a class called MembershipHelper, which I am using in my ASP.NET project. It looks like this:
Public Class MembershipHelper
Public Shared Function IsMultiStoreUser() As Boolean
return Roles.IsUserInRole(....)
End Function
Public Shared Function IsAdmin() As Boolean
return Roles.IsUserInRole(....)
End Function
Public Shared Function IsReaderOnly() As Boolean
return Roles.IsUserInRole(....)
End Function
End Class
I read somewhere that its not a good idea to have a class with just shared functions - but I don't remember where.
Why is this bad and how can I improve it?
Thank you
From the naming that you used for your functions it seems that all functions describe properties of a user (e.g. whether the user is an admin).
Therefore it would seem more natural** to have these functions replaced by properties of your user object or by having your user implement an IRole interface.
** I'm not saying that your design is good or bad. Depending on the context such a helper class might very well be reasonable.
Shared functions are like static functions, which in turn are like global functions or objects.
What you are essentially doing in your example is adding some redirection and abstraction, which I think is fine for Helper/Extension classes.
In a base class object, I have an overridable subroutine that I would like all derived objects to have the ability to include. However, they don't have to, and if it's not necessary for them to use it, I don't want them to be forced to declare it. To enforce this, I've left the default behavior empty. For example, here's my whole sub:
Protected Overridable Sub MySubroutine(ByVal someObject As Object)
End Sub
Is this bad practice? I don't want to declare it as MustOverride, but I don't want default behavior. Is there a "better" way of doing this, or is this perfectly acceptable? I don't want to be that hack programmer... just trying to learn :)
Yes, this is perfectly acceptable. A MustOverride member can often be too strict of a requirement for an inheriting class so if you want a virtual member without default implementation this is the proper thing to do.
Anyone who is inheriting from this class will appreciate the fact that you have defined a virtual member as a "hook" into your class like this. Also the fact that you have declared this method as Protected is also a good idea as public virtual members can be problematic from a maintenance standpoint.
As a step in your learning process, you should download .Net Reflector (from redgate).
Using it will tell you a lot about how others develop their code, and how Microsoft develops the framework code. You'll learn a lot from it.