Дизайн для отправки объектов для добавления в соответствующую структуру данных

Question

У меня есть класс с именем DataStructures, где у меня есть набор public static структур данных, которые хранят объекты. Добавление объекта в структуры данных - это сложный процесс, требующий выполнения ряда проверок, процессов, которые необходимо запомнить, и данных, которые необходимо переставить. В другом классе под названием Foo мне нужно добавить объекты в структуры данных. Я думал, что смогу сделать это, создав метод с именем ObjectFeed, который будет принимать объект и метку объекта в качестве параметров. Метка будет указывать метод, к какой из структур данных объект должен быть добавлен. У меня также будет метод с именем addObject, который будет принимать объект для добавления и соответствующую целевую структуру данных в качестве параметров:

Public Class DataStructures
{
    public static List<obj> object1Storage = new List<obj>();
    public static List<obj> object2Storage = new List<obj>();
    ...
}

Public Class Foo
{
    public void ObjectFeed(/* PARAMETERS */)
    {
      //Code that generates an object called inspectionObject
      //inspection object has an associated enum Type
        if(objectType == Type.Type1)
        {
             addObject(inspectionObject, DataStructures.object1Storage);
        }
        if(objectType == Type.Type2)
        {
             addObject(inspectionObject, DataStructures.object2Storage);
        }
        ...
    }

    private void addObject(obj inspectionObject, List<obj> objStorage)
    {
        objStorage.Add(inspectionObject);
        //And a lot more code
    }
}

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

Edit:

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

Answer 1

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

Если это так, я бы заменил каждый список новым типом объекта, который занимается добавлением данных и выполняет соответствующие проверки.

Что-то вроде:

interface IObjectStorage
{
   void Add(object obj);
   void Remove(object obj);
}

Каждый тип хранилища объектов будет происходить из этого и обеспечивать свою собственную логику. Или это может происходить из Collection<T> или чего-то подобного, если семантика коллекции имеет смысл. Поскольку ваш пример прямо сейчас, я не вижу использования для ObjectFeed, он служит средством доступа к причудливым свойствам.

Выбор свойства для доступа через строку звучит для меня странно. Это очень склонно к опечаткам; Я бы предпочел использовать Type -объекты, доступные из любого объекта в C # через конструкцию GetType-method или typeof().

Тем не менее. Вся установка кажется мне немного неправильной, DataStructures и др.

Во-первых, тестирование вашего статического класса будет трудным. Я бы передал эти магазины тем типам, которые в них нуждаются. Заменить их другими вещами также будет сложно, использование интерфейсов по крайней мере не привязывает вас к конкретной реализации, но что, если вы хотите использовать другое место для хранения объектов в другом коде? Ваш статический класс больше не актуален, и вам нужно будет изменить много кода.

Может быть, эти вещи находятся вне вашего контроля, я не знаю, пример кода немного расплывчат в этом смысле.

Answer 2

Откуда берется тип объекта?Передача строкового значения как типа чего-либо очень редко бывает хорошей идеей.Рассмотрим различные варианты:

1. Создайте перечисление для этих значений и используйте его.Вы всегда можете разобрать его из строки или вывести его в строку, если вам нужно.
2. Может быть, имеет смысл иметь несколько конкретных методов: FeedObjectType1 (object obj) и т. Д.?Как часто они будут меняться?

Действительно трудно дать вам определенный ответ, не видя остальную часть кода.

В большинстве случаев предоставление открытых статических списков из вашего класса DataStructuresне хороший дизайн.Для начала я хотел бы рассмотреть вопрос о том, чтобы сделать их приватными и предоставить некоторые методы для доступа к необходимой функциональности.Я бы хотел обернуть списки методом addObject, чтобы вам не приходилось передавать список в качестве аргумента.Но опять же, я не уверен, имеет ли это смысл в вашем случае.

Answer 3

Как указано в других ответах:

1. public static List s - плохая практика
2. Поскольку метод addObject одинаков для всех структур данных,он должен быть реализован как средство доступа к структуре данных.

Для этого я перенес создание экземпляров структур данных в Foo и переместил метод addObject из Foo в новый класс с именем StorageLibrary, который более точно представляетархитектура структуры данных.

private class StorageLibrary 
{
    private List<obj> storedObjects = new List<obj>();
    public void addObject(obj inspectionObject)
    {
        storedObjects.Add(inspectionObject);
        //And a lot more code
    }
}

public class Foo : StorageLibrary
{
    //Declaration of libraries
    public static StorageLibrary storage1 = new StorageLibrary();
    public static StorageLibrary storage2 = new StorageLibrary();
    ...

    private void ObjectFeed(/* PARAMATERS */)
    {
        //generate objects

        if (objectType == Type.Type1)
        {
            storage1.addObject(inspectionObject);
        }
        if (objectType == Type.Type2)
        {
            storage2.addObject(inspectionObject);
        }
        ...
    }
}