Maybe it’s best to use an event template. For example:
public class MeuEvento {
private final String nomeInformado;
public MeuEvento(String nomeInformado) {
this.nomeInformado = nomeInformado;
}
public String getNomeInformado() {
return nomeInformado;
}
}
public class MinhaView {
private final JFrame frame;
private final JTextField nomeInformado;
private final JButton botaoOk;
private final List<Consumer<MeuEvento>> listeners;
// ...
public MinhaView() {
this.frame = new JFrame();
this.txt = new JTextField("Teste");
this.listeners = new ArrayList<>();
this.botaoOk = new JTextButton("Ok");
// blablabla...
this.botaoOk.addActionListener(evt -> {
MeuEvento me = new MeuEvento(txt.getText());
for (Consumer<MeuEvento> e : listeners) {
e.accept(me);
}
});
}
public void addMeuEventoListener(Consumer<MeuEvento> listener) {
listeners.add(listener);
}
public void removeMeuEventoListener(Consumer<MeuEvento> listener) {
listeners.remove(listener);
}
}
public interface MeuModel {
public void nomeInformado(String nome);
// Mais um monte de outros métodos...
}
public class MeuController {
public MeuController(MeuModel model) {
MinhaView v = new MinhaView();
v.addMeuEventoListener(m -> model.nomeInformado(m.getNomeInformado()));
}
}
When using this format the events fired by view are directly referred to the model, being the controller only responsible for translating/adapting them. The events themselves serve to traffic data between the view and the controller (but it could also be directly between the view and the model, with the disadvantage that the model would receive events instead of just responding to normal method calls).
If there are several possible actions that the screen can perform reflecting on different actions in the model (not necessarily related to 1-to-1), there will be an event class for each of them, so each event will carry the data that is convenient/necessary for it.
Swing itself is already an application of mvc, "reinventing the wheel" is totally unnecessary. If there is already the method there, why create another? And screen components do not need all this treatment, since they will only be accessed by the window class itself.
– user28595
@diegofm So man, but I get a little confused by this, because they say that the layer View cannot "know" the layer Model ... I in case I want to get the right text
JTextFieldto compare with the data of an Arraylist Model, how to do this in the window class itself ? '-'– Daniel Santos
This smells like "validation," if it is, that’s what listeners are for. They are like the layer of controllers, in which you validate the components, send data to the database, return status to the screen and etc. I can’t give you an answer because the question is broad and based on opinions;
– user28595
@diegofm So you mean that in a validation that depends on a data generated by a window, the most appropriate way to do this validation would be in the window class itself ? Even if the object that stores your data is on a different layer than View ?
– Daniel Santos
Nothing prevents you from separating listeners into separate classes, I already think that, depending on the type of validation, it is sometimes better to work with states, type, password and login are valid, I send them to the model through some Systener, and the model returns me whether it is valid or not. Well, you can’t go deeper, maybe you edit and give a more plausible example, you can elaborate some answer.
– user28595