Управление сессиями в проверке согласованности приложений Swing - PullRequest
Новая
       14

Управление сессиями в проверке согласованности приложений Swing

0 голосов
/ 17 ноября 2018

Я использую синглтоноподобный класс для управления сессией и облегчения обращения к классам. У меня есть два класса LockPage и HomePage, которые лениво инициализированы . Мой Синглтоноподобный класс здесь: 

public class Session{
private static LockPage lock;
private static HomePage homePage;

private Session() {

}
public static HomePage getHomePage() {
    if(homePage==null) {
        homePage = new HomePage();
    }
    return homePage;
}

public static LockPage getLockPage() {
    if(lock==null) {
        lock = new LockPage();
    }
    return lock;
}

public static void resetEverything() {
    lock=null;
    homePage = null;
}
}

LockPage сначала создается из main () , а после успешного входа в систему HomePage инициализируется .

В HomePage класс, если пользователь нажимает кнопку выхода из системы, это называется: 

public void logOUt(){
    Session.getHomePage().disposeScreen();
    Session.resetEverything();
    Session.getLockPage();
}

Мне нужно использовать класс HomePage в нескольких других классах, поэтому я подумал, что ссылки могут быть лучше. Пожалуйста, дайте мне знать, если это ХОРОШИЙ ПОДХОД или есть намного лучший способ.

P.S .: Класс Session по сути не является Singleton

1 Ответ

0 голосов
/ 17 ноября 2018

Пожалуйста, дайте мне знать, если это ХОРОШИЙ ПОДХОД

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

На ум приходят сразу два лучших решения ...

  1. Model-View-Controller

Это разделяет слоиВаш код в отдельные функциональные группы.

В контексте вашего вопроса вы бы «поделились» / «выставили» модель для всех «представлений», которые в ней нуждались.Кроме того, определяя базовую модель как interface, вы уменьшаете связность и уменьшаете вероятность того, что представления делают то, что не должны, просто потому, что они могут (и ваш дизайн позволил им).

Внедрение зависимостей

Это причудливый, бесполезный способ сказать "передать вещи" через параметры.

Таким образом, вместо того, чтобы представление, получающее информацию из «централизованного» источника, например, синглтона, или создавая и настраивая свои собственные экземпляры, вы передаете всю необходимую информацию через параметры конструктора или метода.

С DI легче рассуждать о состоянии кода в любой момент времени.Это также упрощает тестирование, поскольку вам не нужно «подготавливать» какое-то глобальное состояние, а вместо этого просто создавать нужные вам объекты (например, макеты) и «вставлять» их в код.

Опять же, именно здесь interface s уменьшит сцепление, сделав API гораздо более гибким и устойчивым к изменениям.

Слово о синглетонах ...

Это областьвокруг которых возникают пламенные войны, и это может быть весьма решающим.

Вам следует взглянуть на Являются ли Singletons Evil? для множества мнений.

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

В качестве "общего" комментария глобальное состояние должно рассматриваться оченьочень осторожно

...