How to keep Java GUI completely separate from Core

I'm working on the project. I am trying to implement the kernel as an independent jar file that can be run from the command line or even from a Windows service. The kernel will be responsible for tracking multiple files and sending email notifications. The question is, what would be the best idea to keep the GUI completely independent?

A graphical interface is needed after interacting with the kernel

  • send file list
  • receive notifications from the kernel about how many files were processed
  • receive notifications about the status of files, i.e. SEND / Processing / Failed, etc., which will be displayed in the graphical interface
  • receive information if there are incoming messages from the kernel

I had this software developed in Delphi and C. C was used to encode core logic and use Windows messages and callbacks, I registered the Delphi GUI in C dll / service. I am confused how to implement it in java.

  • Observer pattern?
  • Small client / server communication between the kernel and gui?

PS: The reason I'm discussing here is to study and study the best design for such programs when encoded in Java. I do not request Observer Pattern documentation or client server architecture. There may be other possible ways that I don't know about. Therefore, I look forward to any idea, design or frame.

+5
source share
2 answers

Oberserver Pattern is really the right answer for three of your 4 use cases.

, :

public interface Core {

    sendFiles(List<File> files);
    registerProgressListener(ProgressListener listener);            
    registerStatusListener(StatusListener listener);
    registerMessageListener(MessageListener listener);
}

public interface ProgressListener{
    madeProgress(ProgressEvent)
}

ProgressEvent ( ) ,

public class ProgressEvent {
    public final double progress;
    public final String fileName;
    public ... // constructor
}

, , ​​ gui . - . ​​ GUI, , , SwingUtilities.invokeLater invokeAndWait GUI.

+3

, , ?

, ​​ , (java.util.concurrent. *). , , .

, , .

+1

All Articles