Use modules in VB.NET, considered bad practice?

Question

During the development of a new application, I was wondering, considering that using a module with properties is considered bad practice.

Code example:

Module modSettings public property Setting1 as string public property DatabaseObject as IDatabaseObject End Module 

The above code is just an example to emphasize my question. Previously, this structure was often used in VB6. I used to use it in my .NET projects too.

But these days, with keywords like Injection Dependency, Testability, and Problem Separation, this structure smells bad. I can’t describe why, but this is simply wrong. I must admit that I am not very familiar with the keywords.

So I'm wondering if the above code really is . If so, what would you use Module for?

Answer 1

Centro is right that the module (or the NotInheritable class with members included) is the closest equivalent to the C # static class . So technically, nothing happens to her, because this is just one way to create this class of VB class. For example, you cannot say Public Shared Class Settings in VB, since you cannot put the Shared keyword in a class.

By itself, I would not call it bad practice if a particular circumstance requires a module, but otherwise the module (or other equivalents of a static class) is probably not the design choice you want for a loosely coupled test code. In addition, while the NotInheritable class with Shared members is more descriptive than just saying the module, there is at least one circumstance in which the module should be used instead.

When will you need to use modules in VB.Net? If you want to use extension methods , then this is your only option , because, as already mentioned, you cannot create a general (static) in VB.Net, you also cannot use extensions for NotInheritable classes. You should use the module as follows:

 Imports System.Runtime.CompilerServices Public Module StringExtensions <Extension()> _ Public Function Remove( _ ByVal input As String, _ ByVal subStrings As String()) As String Return String.Join("", input.Split(subStrings, StringSplitOptions.None)).Trim() End Function End Module 

In C #, you cannot use modules and must use static classes as follows:

 public static class StringExtensions { public string Remove(this string input, string[] subStrings) { return string.Join("", input.Split(subStrings, StringSplitOptions.None)).Trim(); } } 

Answer 2

The key module Module in VB.NET comes from VB 6. In fact, it is compiled as a NotInheritable Class so that all members are static, in C # it is a private class with static members.

I think this is bad practice, since it is not entirely clear that this is actually a class with static members.

Answer 3

There is nothing wrong with properties. In fact, to implement the binding you need the properties and implementation of the INotifyPropertyChanged interface. I think I would prefer classes over modules, but I'm mostly C #.

Answer 4

Although this can be done, I must admit that I have never seen this in practice. In my opinion, this is easier to read in the class, because this declaration is explicit, and using the class allows you to later convert to the class if the need arises. Therefore, I cannot think of any reason why you would like to do this on a class with a common member