Die Idee von
@White_Fox mit MVC und
@lam_tr mit den Business Logiks geht in die gleiche Richtung.
Es macht Sinn, eine Applikation in Teile aufzuteilen die möglichst gut voneinander abgekoppelt sind. Bei MVC hat man ein Model, das dann u.a. auch die ganze Business Logik enthält. Das weiss also, was es so an Business Objekten gibt, was für Daten diese beinhalten und was für ein Verhalten. Also eigentlich die ganze Applikation nur eben ohne irgend ein "Frontend".
Dazu dienen dann Controller und View. Das Gute ist dabei: Das Model ist unabhängig von View und Controller und kann auch sehr gut getestet werden.
Und da musst Du dann jetzt schauen, ob und wie Du da die Daten und das Verhalten in Deinem Code entsprechend in genau so ein Model verlagern kannst.
Und das ist vermutlich auch, was
@Trjavnamen etwas meinte. Denn wenn Du so ein Model hast, dann kann die JavaFX Applikation zur Not irgendwie dieses Model ansprechen und da irgendwas machen. Wobei ich da auch meine, dass es sich lohnen kann, da von Anfang an sauber zu arbeiten. Aus meiner Sicht ist das MVVM besser geeignet (mvvmFX Library mal ansehen. Da hast Du auch ganz viel Doku rund um MVVM verlinkt...). Aber das ist alles prinzipiell egal. Etwas mit MVC beschäftigen und dann schauen, welche Teile zum Model gehören und daher irgendwie bleiben können wäre auf jeden Fall ein erster Schritt, der notwendig ist.
Konkret bedeutet das:
- Schauen, was für Daten Du irgendwo halten willst. Die müssen dann in entsprechenden Klassen verbleiben.
- Was für Verhalten hast Du bisher? Also z.B. ein Button wird gedrückt und dann passiert eine Logik. Diese Logik wird im Model verbleiben können (Aber ohne eine Anzeige anzupassen) ... Validierungen kann man ggf. auch erst einmal ins Model packen (in ein ViewModel verlagern geht später mit der IDE ja auch einfach).
So schmeisst Du also alles, was Swing Oberfläche raus. Und je nach Aufbau kann es tatsächlich einfacher sein, einfach bei 0 sauber anzufangen....
