рефакторинг структуры с внутренними статическими свойствами - PullRequest
Новая
       24

рефакторинг структуры с внутренними статическими свойствами

0 голосов
/ 08 мая 2018

Я сталкиваюсь с довольно большим количеством занятий от бывшего сотрудника. При проверке того, что делает код, я наткнулся на struct со internal static свойствами.

Структура используется довольно часто. У большинства свойств есть только get, но у некоторых есть set и get. Структура длиной около 200 строк с вложенными внутренними структурами.

Я не могу обернуть голову вокруг этой структуры и того, чего человек хотел достичь с ее помощью.

Это не проверено, и нет документации, которая заставляет меня задуматься, почему человек решил внедрить нечто подобное.

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

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

Мои вопросы: Зачем кому-то использовать структуру с открытыми статическими свойствами и как от нее избавиться (может быть, это хорошо известный рефакторинг или что-то в этом роде), поскольку она используется во всем коде (~ 800 ссылок, подсчитанных Visual Studio)

КСТАТИ: он не помещается ни в какое пространство имен 

internal struct ConfigurationPaths
{
    private static string _pathConfig;
    private static string _pathConfigUI;
    private static string _pathConfigUI_Default;
    private static string _pathConfig_DataToView;
    //... removed the following lines due to readability in the question

    internal static string AppPath
    {
        get
        {
            Module[] mod = Assembly.GetExecutingAssembly().GetModules();
            return Path.GetDirectoryName(mod[0].FullyQualifiedName);
        }
    }

    internal static string FilePath
    {
        set { _pathConfig = value; }
        get { return _pathConfig; }
    }

    internal static string UserInterface
    {
        set { _pathConfigUI = value; }
        get { return _pathConfigUI; }
    }

    internal static string UserInterface_Default
    {
        get
        {
            if (_pathConfigUI_Default == null)
            {
                String appPath = AppPath.AppendPathSeperatorIfNeeded();
                _pathConfigUI_Default = String.Format("{0}files{1}config{1}ui{1}default.ux", appPath, Path.DirectorySeparatorChar);

            }
            return _pathConfigUI_Default;
        }
    }

    internal static string UserInterface_GridView
    {
        set { _pathConfig_DataToView = value; }
        get { return _pathConfig_DataToView; }
    }
    //... removed the following lines due to readability in the question
}

Ответы [ 2 ]

0 голосов
/ 08 мая 2018

Статические классы - довольно распространенная ошибка для данных конфигурации, DatabaseAccess и аналогичных случаев.Это так часто, даже сама Microsoft делала это хотя бы раз .

Но, как я уже сказал: это ошибка.Если вам когда-нибудь придется заменить код из-за некоторых изменений в бэкенде - а тем более получить изменяемый бэкэнд - он вернется, чтобы укусить вас.Класс / структура, для которых требуется создание экземпляра, с экземпляром, назначенным для статического поля, является самым близким, который я когда-либо получал.Таким образом, по крайней мере, вы можете изменить экземпляр во время выполнения.

Что касается того, почему он использовал структуру, а не класс: поскольку создание экземпляров не требуется, разница между обоими типами в значительной степени не имеет значения.Возможно, он был программистом на С ++.Для них единственное различие между структурой и классом состоит в том, что метод доступа по умолчанию является открытым или закрытым.

0 голосов
/ 08 мая 2018

Похоже, что намерение было для конфигурации. Если это так, статический класс будет более полезным 

internal static class Configuration { ... }

A struct выполнение этого не дает значения и не является идиоматическим. Что касается того, почему они это сделали ... возможно, просто не самый лучший разработчик. Я бы поместил класс config в корневое пространство имен проекта, хотя они, вероятно, не поместили его в пространство имен, чтобы избежать каких-либо объявлений using по всей базе кода.

Если вас беспокоит глобальный / статический характер, я бы предложил преобразовать все это в свойства экземпляра и передать его вещам, которые в этом нуждаются. Делая это, он становится больше похожим на сервис конфигурации - возможно, полностью удалив сеттеры и усвоив код, который выполнял настройку. Это, конечно, будет больше ОО.

Это также поддается внедрению зависимостей и тестируемости, особенно если вы наложите интерфейс на него.

...