I would like to use a class Cookie in my namespace for convenience, with the same capabilities as System.Web.Cookie, or better be equivalent. I can't derive from System.Web.Cookie because it is noninheritable...
In C, i could simply typedef it to another type, but I don't see any possibility in VB.net other than write a wrapper class that mimics all functions.
Is there another way to "rename" a type in VB.net (Framework 4.0)?
Edit:
I found a solution, to import the class under a different name:
imports Cookie = System.Web.HttpCookie
But I would still be interested in other solutions.
Therefore I didn't add this as answer.
Related
I'm working in Kotlin, and I have a library that I can't modify (without maintaining my own fork of this huge and rapidly changing library).
There's a class in that library I need to instantiate, and it requires an instance of another class that does some stuff for it. I need to change how that second class works, so it feeds different information to the first class. But the second class is not open, and the first class asks for it by its full, non-open type.
How do I force my way into the non-open class and extend it anyway, against the desires of the library authors? Alternately, how do I cheat the type system to pass my own class off as an instance of the class the library is demanding?
Do I need to do some fiddling around at the JAR/build system level to replace the library's class files with my own versions? Can I use reflection to somehow impersonate the non-open class? Is there some other way to do it?
I work with a codebase where there are many classes with thousands of lines of code. I've noticed inconsistencies in style concerning prepending class names when using their methods and I'm trying to figure out the previous developer's reasoning. If we
import GeneralCode
in Class A, is it bad practice to write
GeneralCode.DoSomething()
in Class A since we already imported it (instead of simply using DoSomething())? I would think so, but I suppose it's also nice to know which methods come from which classes at a glance, since Class A imports many classes and uses methods from several of them.
EDIT: This is for VB.NET, not Java (sorry for the wrong tag, rough morning). I am new to VB.NET but GeneralCode and DoSomething() are not declared as static, neither is the import in Class A.
Might be something to do with VB.NET, but DoSomething() can indeed be used with or without prepending GeneralCode.
A method need to be prefixed with
The class name if it's a static method.
The name of the instance when it's not a static method.
Unless you are calling a method from your own class.
Say you want to add a lengthOfFirstLine method to the predefined File class. Is it a better practice to modify the existing class, or make a new class that extends the File class with your new method?
EDIT -- Specifically, the situation is that a class is lacking one method in particular. I don't want to completely change the class, but rather augment it with that method.
It depends if the method is applicable to all elements of the class File. For instance, lengthOfFirstLine doesn't apply to binary files, so probably it doesn't belong in a generic File class, but if your class only represent text files, then it should go there.
For .NET languages, there's also the option of using extension methods. This way you don't have to "dirty up" a class by adding helper/utility methods to it, and no inheritance is required as well - you add functionality to a class by simply adding a using statement to your code.
Agree with Luis and Lester. If you are using .Net the extension methods are the way to go for this sort of functionality. But you should try not add LengthOfFirstLine to a base class if you can open all sorts of files such as binary files. You would sub class it to a FileClass and add the method to that.
Remember that the extension methods in .Net are syntactic sugar anyway. You can simulate it in your own language using Static classes and methods. This is what .Net does under the covers anyway.
For example have a static FileHelpers class and have various static helper methods on it. The first parameter for each of these static methods would be the File class. So you could call this using FileHelpers.GetLengthOfFirstLine(myOpenedFile)
I have a Util module in my VB.NET program that has project-wide methods such as logging and property parsing. The general practice where I work seems to be to call these methods directly without prefixing them with Util. When I was new to VB, it took me a while to figure out where these methods/functions were coming from. As I use my own Util methods now, I can't help thinking that it's a lot clearer and more understandable to add Util. before each method call (you know immediately that it's user-defined but not within the current class, and where to find it), and is hardly even longer. What's the general practice when calling procedures/functions of VB modules? Should we prefix them with the module name or not?
Intellisense (and "Goto Definition") should make it trivial to find where things are located, but I always preface the calls with a better namespace, just for clarity of reading. Then it's clear that it's a custom function, and not something built in or local to the class you're working with.
Maybe there's a subtle difference I'm missing, but I tend to use shared classes instead of modules for any code that's common and self-contained - it just seems easier to keep track of for me, and it would also enforce your rule of prefacing it, since you can't just call it from everywhere without giving a namespace to call it from.
I usually put the complete namespace for a shared function, for readibility.
Call MyNameSpace.Utils.MySharedFunction()
Util is such a generic name.
Example from the .Net framework. You have System.Web.HttpUtility.UrlEncode(...). Usually you refer to this as HttpUtility.UrlEncode since you have an import statement at the top.
The name of the class which has the static utility methods should be readable and explainable. That is good practice. If you have good class names they might just as well reside in a Utils namespace, but the class name should not be Utils.
Put all your logging in a Logger class. All your string handing in a StringUtils class etc. And try to keep the class names as specific as possible, and I'd rather have more classes with fewer functions than the other way around.
I find myself creating a significant number of wrapper classes, purely because I want to mock out the behaviour of
Classes that don't lend themselves well to the RhinoMocks isolation model (for instance like DirectoryInfo or WindowsIdentity)
Native Win API methods (I normally collect all the methods I need into a single class and wrap the native calls as a class method)
I then find myself appending the class that is wrapped with a 'W' (to indicate that it's a wrapper) and so I end up with DirectoryInfoW (as opposed to DirectoryInfoWrapper which seems rather verbose). Similarly, I end up with wrapped native methods called NativeMethods.DuplicateTokenW.
What would be a good rule of thumb to follow when naming wrapper classes?
Naming conventions are whatever works for the team that you're working with. As long as everyone's ok with a particular convention, then it's ok.
I tend to prefer the more verbose version though, i.e. DirectoryInfoWrapper, rather than having a single letter that doesn't explain anything to anyone who's not familiar with the code. But that's just me.
I'll agree with aberrant80 , if everyone agrees with the convention you are using, then it'll work.
I personally prefer using names that are shorter and descriptive to the class's purpose. At least at the interface level. If you're using a mock framework, then IDirectory or IDirectoryInfo would be a decent set of names, while DirectoryInfoW or DirectoryInfoWrapper would be an interface implementer.
A better example might be wrapping an HttpRequest; define an IRequest to state 'this is what is important to my application', then Request, HttpRequestWrapper, Request, etc would be implementers.
So, to summarize, try and use descriptive, non-overly-verbose interface names.
Just as a side note, I found a more aesthetically pleasing (well, to me) way of wrapping native method calls:
public class NativeMethods
{
// made virtual so that it can be mocked - I don't really want
// an interface for this class!
public virtual bool RevertToSelf()
{
return WinApi.RevertToSelf();
}
...
private static class WinApi
{
[DllImport("advapi32.dll")]
public static extern bool RevertToSelf();
...
}
}
i.e. avoid name collision by encapsulating native method calls in a private nested class.
No 'good' solution to the wrapper class naming issue though, I'd probably go with aberrant80's suggestion and explicitly call my wrappers wrappers.
If you are using C++, you can use namespaces and then just re-use the same class name. For example:
namespace WrapperNamespace
{
class MyClass {...};
}
namespace InternalNamespace
{
class MyClass {...};
}