Лучший дизайн для совместного использования экземпляра класса между многими классами

Question

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

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

Answer 1

Я использовал бы инъекцию зависимости, Spring framework. Другой вариант - использовать шаблон Singleton.

Answer 2

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

Просто у всех классов, которые нуждаются в APIUtility, возьмите экземпляр как зависимость в конструкторе.

Таким образом, если вам нужно/хотите, вы можете просто создать экземпляр APIUtility один раз и поделиться им.

FYI, это то, что некоторые люди назвали бы «инъекцией зависимого человека».

Answer 3

Вы можете использовать переменную типа ThreadLocal.

ThreadLocal можно рассматривать как область доступа, как области действия запроса на или сеанса области видимости. Это область потока. Вы можете установить любой объект в ThreadLocal, и этот объект будет глобальным и local к определенной теме, к которой обращается этот объект. Глобальный и местные? Поясню:

• Значения, хранящиеся в ThreadLocal являются глобальной к потоку, а это означает, что они могут быть доступны из любой точки внутри этого потока. Если поток вызывает методы из нескольких классов, то все методы могут видеть переменную ThreadLocal, установленную другими методами (потому что они выполняются в одном потоке). Значение не обязательно должно передаваться явно. Это похоже на то, как вы используете глобальные переменные.
• Значения, хранящиеся в ThreadLocal являются локальными для потока, что означает, что каждый поток будет иметь свою собственную переменную ThreadLocal. Один поток не может получить доступ/изменить переменные другого потока ThreadLocal.

Java Thread Local – How to use and code sample

например,Вы можете иметь что-то вроде этого:

public class APIUtility { 

    private static ThreadLocal<Engine> ENGINE_LOCAL = new ThreadLocal<Engine>(); 

    public static void setEngine(Engine engine) { 
     ENGINE_LOCAL.set(engine); 
    } 

    public static Engine getEngine() { 
     ENGINE_LOCAL.get(); 
    } 

} 

class NameValidator { 

    public void foo() { 
     Object obj = APIUtility.getEngine().getSomething(); 
    } 

} 

Смотрите также:

• Thread-local storage - Wikipedia, the free encyclopedia
• Java Thread Local – How to Use and Code Sample | Javalobby

Answer 4

Вы должны принимать инъекции в зависимость \ рамках МОК, как CDI или весной. Мне лично нравится CDI, но это личный выбор.

С впрыском зависимостей Контейнер управляет ассоциациями между вашими классами. Если вы получаете доступ к классу, в котором есть элементы внутри, которые должны быть введены, компилятор устанавливает их через Constructor-Injection (Constructor) или Setter-Injection (Setter-Method).

Answer 5

Я бы использовал весну с dependency injection и подходящим bean scope.

Answer 6

Это определенно случай для инверсии элемента управления или стратегии.

В целом, хотя я должен был бы сказать, что, может быть, ваши обязанности немного перепутаны. Есть ли причина, по которой он не может быть статическим классом util (который принимает токен в качестве параметра)? Если нет, то вы также можете это сделать, если да, вы, вероятно, должны подумать о более полезном имени для класса.