Где я должен хранить списки или карты объектов

Question

Где я должен хранить списки или карты объектов

1

В моем проекте у меня есть несколько объектов, таких как макеты, группы, коробки и многие другие. Эти объекты необходимо хранить в списке или карте с помощью методов для их получения, удаления и размещения в коллекции. В настоящее время я использую статические методы и переменные в связанном классе, например, у меня есть:

public class Layout {
    private static Map<String, Layout> layouts = new HashMap<String, Layout>();
    /*
    Other, non-static variables
     */

    public static void addLayout(String name, Layout layout) {
        layouts.put(name, layout);
    }

    public static Layout getLayout(String name) {
        return layouts.get(name);
    }

    public static void removeLayout(String name) {
        layouts.remove(name);
    }

    /*
    Non-static methods for layout
     */
}

Было бы лучше иметь отдельный класс, который содержит коллекцию каждого типа объекта или одного класса для хранения коллекций всех объектов? Если да, какие имена вы бы использовали для этих классов?

user2248702 09 июль 2014, в 06:21

Источник

0

Это действительно невозможно сказать, не зная больше о вашем приложении. Вам нужно узнать больше о ОО дизайн ...
djechlin 09 июль 2014, в 04:13
1

почему вы используете статический?
Scary Wombat 09 июль 2014, в 04:15
0

Определенно это шанс для вас узнать о ОО-дизайне, поиграть с ним и посмотреть, что вы придумали. Вы, вероятно, узнаете что-то хорошее в процессе. Также, если вы LayoutManager класс с такой картой, некоторые имена будут LayoutManager , LayoutConfiguration , LayoutFactory ( en.wikipedia.org/wiki/Factory_method_pattern ). Просто некоторые мысли. Имя должно отражать то, что делает этот класс, учитывая, что я понятия не имею, что такое Layout , тогда трудно сказать.
ug_ 09 июль 2014, в 04:16
0

@ScaryWombat Было бы бессмысленно не использовать static, так как мне нужно иметь возможность получить макет, не имея экземпляра макета.
user2248702 09 июль 2014, в 04:17
0

как насчет заводского класса тогда?
Scary Wombat 09 июль 2014, в 04:20
0

@ScaryWombat На самом деле это не фабрика, это скорее «контейнер» объектов макета.
user2248702 09 июль 2014, в 04:21
0

смотрите комментарии от djechlin и @ug_
Scary Wombat 09 июль 2014, в 04:23
0

Подумайте об этом так, обычно, если вы делаете что-то, используя статические переменные и методы, которые кажутся такими, что они могут или не должны быть статичными, тогда ваш программный дизайн не в хорошей форме. Подумайте о том, чтобы переделать некоторые другие ваши классы, чтобы можно было LayoutManger , LayoutFactory ... ect, когда это необходимо.
ug_ 09 июль 2014, в 05:49

Показать ещё 6 комментариев

Теги:

java

oop

conventions

1 ответ

Ещё вопросы

Это действительно невозможно сказать, не зная больше о вашем приложении. Вам нужно узнать больше о ОО дизайн ...
почему вы используете статический?
Определенно это шанс для вас узнать о ОО-дизайне, поиграть с ним и посмотреть, что вы придумали. Вы, вероятно, узнаете что-то хорошее в процессе. Также, если вы LayoutManager класс с такой картой, некоторые имена будут LayoutManager , LayoutConfiguration , LayoutFactory ( en.wikipedia.org/wiki/Factory_method_pattern ). Просто некоторые мысли. Имя должно отражать то, что делает этот класс, учитывая, что я понятия не имею, что такое Layout , тогда трудно сказать.
@ScaryWombat Было бы бессмысленно не использовать static, так как мне нужно иметь возможность получить макет, не имея экземпляра макета.
как насчет заводского класса тогда?
@ScaryWombat На самом деле это не фабрика, это скорее «контейнер» объектов макета.
смотрите комментарии от djechlin и @ug_
Подумайте об этом так, обычно, если вы делаете что-то, используя статические переменные и методы, которые кажутся такими, что они могут или не должны быть статичными, тогда ваш программный дизайн не в хорошей форме. Подумайте о том, чтобы переделать некоторые другие ваши классы, чтобы можно было LayoutManger , LayoutFactory ... ect, когда это необходимо.

Arne Burmeister · Answer 1 · 2014-07-09T03-54-00.000Z

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

Лучшим подходом может быть создание репозиториев для каждого из классов, таких как LayoutRepository для хранения и извлечения макетов. Лучше всего использовать инъекцию зависимостей, реализуемую контейнером Spring, если ваше приложение становится больше.

Самой простой была бы общая реализация:

public class Repository<E> {

  private final Map<String,E> elements = new HashMap<>();

  public void add(String name, E element) {
    elements.put(name, element);
  }

  public E get(String name) {
    return elements.get(name);
  }

  public void remove(String name) {
    elements.remove(name);
  }
}

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

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

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