Использование модулей в VB.NET считается плохой практикой?

Question

Во время разработки нового приложения мне было интересно, считается ли использование модуля со свойствами плохой практикой.

Пример кода:

Module modSettings

   public property Setting1 as string

   public property DatabaseObject as IDatabaseObject

End Module

Приведенный выше код является лишь примером, подчеркивающим мой вопрос.В прошлом эта структура часто использовалась в VB6.В прошлом я использовал это также в моих проектах .NET.

Но в наши дни с такими модными словами, как «Внедрение зависимостей», «Тестируемость» и «Разделение проблем», вышеуказанная структура пахнет плохо.Я не могу действительно описать почему, но это просто неправильно.Я должен признать, что пока не очень знаком с приведенными выше ключевыми словами.

Поэтому мне интересно, действительно ли приведенный выше код является плохой практикой.Если да, то для чего бы вы использовали Module? 1013 *

Answer 1

Centro правильно, что модуль (или класс NotInheritable с общими элементами) является ближайшим эквивалентом статического класса C # . Технически, в этом нет ничего плохого, так как это всего лишь один из способов создания этого типа в VB. Например, вы не можете сказать Public Shared Class Settings в VB, поскольку вы не можете поместить ключевое слово Shared в класс.

Сам по себе я бы не назвал это плохой практикой, если конкретное обстоятельство требует наличия модуля, но в противном случае модуль (или другие статические эквиваленты классов), вероятно, не является тем выбором дизайна, который вы хотите использовать для слабосвязанного, тестируемого кода. Кроме того, хотя класс NotInheritable с совместно используемыми членами является более наглядным, чем просто использование модуля, существует как минимум одно обстоятельство, когда вместо него следует использовать модуль.

Когда вам нужно будет использовать модули в VB.Net? Если вы хотите воспользоваться преимуществами методов расширения , тогда это ваш единственный вариант , поскольку, как уже упоминалось, вы не можете создать общий (статический) класс в VB.Net, а также не можете использовать расширения в классах NotInheritable. , Вы должны использовать модуль следующим образом:

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

В C # вы не можете использовать модули и должны использовать статические классы следующим образом:

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

Answer 2

Ключевое слово Модуль в VB.NET пришло из VB 6. На самом деле оно скомпилировано как NotInheritable Class со всеми статическими членами, в C # это закрытый класс со статическими элементами.

Я думаю, что это плохая практика, поскольку не совсем ясно, что это на самом деле класс со статическими членами.

Answer 3

Хотя это возможно сделать, я должен признать, что никогда не видел, чтобы это было сделано на практике.На мой взгляд, легче читать в классе, так как это объявление явное, а использование класса позволяет позднее преобразовать его в класс, если возникнет такая необходимость.Поэтому я не могу придумать причину, по которой вы захотите сделать это над классом с общим членом

Answer 4

Нет ничего плохого в свойствах. Фактически, для реализации связывания вам нужны свойства и для реализации интерфейса INotifyPropertyChanged. Я думаю, что я предпочел бы классы, а не модули, но я в основном парень на C #.