(JavaFx) Правильный способ представляет собой статические поля FXML (и почему это плохая идея)

Question

Я хотел бы иметь поле FXML, доступное из всех классов. В идеальном мире, я бы просто сделать это:

public class CanvasController { 

    @FXML 
    private static final AnchorPane canvas; // This is wrong 

    public static AnchorPane getCanvas() { 
     return canvas; 
    } 
} 

Однако, как пояснил this similar question, статические поля являются «ужасная идея».

Я проектирование редактора узла, что-то вроде этого:

Я хочу добавить node, как ребенок этого AnchorPane из любого места в моем проекте.

Я не прав, если вы хотите это сделать? Почему статические поля - плохая идея, и как мне это сделать?

(Аналогичный вопрос рекомендует использовать свойство, но JavaFx не имеет NodeProperty или AnchorPaneProperty).

Answer 1

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

Почему статические поля плохая идея

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

Это происходит в реальной жизни все время.

Так что в теории это должно быть легко. У вас есть FXML, который определяет макет, и контроллер, чем определяет связанную с ним логику. Итак, все, что вам нужно сделать, это иметь обработчик события (например, в меню), который создает новый Stage и Scene, снова загружает FXML и устанавливает корень сцены в корень FXML.

За исключением того, что он не работает. Проблема в том, что вы делаете корневую панель static. Поэтому, когда вы снова загрузили FMXL, он заменил текущее значение canvas новым с недавно загруженного FXML. Если вы сейчас попытаетесь добавить новые элементы в верхний слой , вы не сможете.

Итак, теперь вы должны реорганизовать код, так что canvas является переменной экземпляра. Что еще хуже, вы публично выставили его с помощью метода static getCanvas(), который можно было бы назвать где угодно в вашем приложении. Поэтому вы должны отслеживать все эти призывы. И вы попадаете в 3 часа ночи, пытаясь сгладить всю вашу кодовую базу, чтобы выяснить, что вам нужно изменить.

Проблема (одна проблема) с созданием статических вещей заключается в том, что вы обязуетесь иметь только одну копию этой переменной и, по сути, вы обязуетесь на это на все время (или обязуетесь переписывать большую часть приложения, если вы меняете свой разум). Это решение протекает вверх: только когда у вас есть один холст, у вас может быть только один контроллер, поэтому вы можете иметь только один редактор узлов. Вы по существу не допустили, чтобы код, который вы написали, был повторно использован.

---

Ваше основное предположение здесь неверно. Ключевое слово static действительно не имеет никакого отношения к Доступность: это около scope. Поле static относится к классу: нестатическое поле относится к каждому экземпляру этого класса. Вы сделали доступным поле, указав общедоступный метод getCanvas() и сделав область действия этого метода - доступным классом (сделав класс общедоступным). Если canvas - это переменная экземпляра, вы можете сделать ее доступной, аналогично определяя общедоступный метод getCanvas() и делая область действия этого метода - теперь доступен CanvasControllerэкземпляр. Таким образом, вы загружаете FXML, извлекаете контроллер, вызывая getController() на FXMLLoader и передавая экземпляр контроллера тому, кому нужен доступ к нему. Обратите внимание, что теперь у вас есть контроль над кодом, кто получил ссылку на контроллер, и если вам нужен какой-либо рефакторинг, у вас есть хотя бы путь для поиска, где используется контроллер.

Вы упоминаете «JavaFX не имеет NodeProperty или AnchorPaneProperty:. Он имеет ObjectProperty, так что вы можете использовать ObjectProperty<Node> или ObjectProperty<AnchorPane>, если вы хотите/потребность

---

В целом, однако, Я думаю, что неплохо также выставлять элементы представления (например, ваш canvas) вне контроллера и даже делиться контроллерами с другими частями приложения. Вместо этого вы должны использовать подход типа MVC. Что отсутствует в вашем вопросе это «M»: модель . Таким образом, ваша модель будет использовать объектную модель wit h классы, такие как Image, Scale, Composite и т. д. Классы должны использовать JavaFX properties, чтобы сделать их наблюдаемыми и использовать ObservableList (и аналогичные) для хранения коллекций этих объектов и отношений между ними. Создайте экземпляр одной модели и передайте ее контроллеру. Контроллер может наблюдать данные в модели и обновлять представление, если он изменяется, и обновлять модель в соответствии с пользовательским вводом. Затем передайте экземпляр модели с другими частями приложения, которым необходим доступ к нему. Это упрощает обслуживание: если вы решите, например, canvas должен быть Pane вместо AnchorPane, это изменение теперь ограничивается вашим FXML и контроллером и не просачивается на остальную часть вашего приложения. Пример (намного проще) MVC (действительно больше MVP) в JavaFX находится в this question.