1

my question is, what is the best way to let a child class communicate with the parent class. For example: I have a main class simply called Main, and another class SomeClass. Now the Main class creates an instance of SomeClass, once the state of the SomeClass-object changes, the Main class should execute different code, depending on what changed. Yeah I know, that already sounds like the Observer design pattern, but how would I implement it with state changes treated differently? I'm currently writing an Android app with a database to make it more specific. In my project I have the main class, a class to connect, read from/write to the database and a GUI container class. (oversimplified, there are a few more) The main class creates an instance of both the GUI and database class. Now if I press a button A, it should write A-data to the database, if I press button B, it should write B-data to the database. As I think that a gui class shouldn't have direct access to the database, I tried other options, than just accessing the database from the gui-class Currently, I defined a placeholder abstract class with only one method, that I am just overwriting with the functionality. So right now I have to create a one-method-class A for the click of button A and a one-method-class B for the click of button B. It doesn't sound like the best way to me, I mean It's working, but I'd like to improve my code, so if you have any idea, please write your solution. :)

Sebastian
  • 153
  • 1
  • 10
  • in my view, it is fine to have one event handler per button. Isn't it? Then it is fine to run code of class that shoud do something. It is fine to me. – StepUp May 25 '22 at 19:48
  • what do you mean by code of class? to access the database class directly from the GUI class? – Sebastian May 25 '22 at 20:33

2 Answers2

1

As a good practice it is better to avoid write code in GUI class. So we can use MVVM pattern here.

Let me show a simple example for your case. This is a ViewModel class. View model does not have reference to view class:

public class YourViewModel 
{
    public void LoadA() 
    { 
        // here you can interact with your database
    }

    public void LoadB()
    { 
        // here you can interact with your database
    }
}

This is your view class. It handles button clicking, user interactions with view and forwards to the view model. It has a reference to view model.

public class YourView
{
    YourViewModel yourViewModel;

    public YourView()
    {
        yourViewModel = new YourViewModel();
    }

    public void ButtonA_Handler() 
    {
        yourViewModel.LoadA();
    }

    public void ButtonB_Handler() 
    {
        yourViewModel.LoadB();
    }
}

If you want to handle many events, then you can try to use this approach How to: Handle Multiple Events Using Event Properties.

StepUp
  • 36,391
  • 15
  • 88
  • 148
  • That sounds like a better way than my current :) to make it clear, ViewModel is a class that only provides the methods that should be called, when buttons are pressed and don't provide changing the GUI elements, is it? – Sebastian May 26 '22 at 07:36
  • @Sebastian yeah, you are right! View model should know nothing about your view. Some view animations, images should be handled only in view class. This is a separation of concern or Single Responsibility Principle of [SOLID](https://stackoverflow.com/questions/13692126/cant-seem-to-understand-solid-principles-and-design-patterns) – StepUp May 26 '22 at 07:47
  • @Sebastian I am glad that it helped to you!:) – StepUp May 26 '22 at 07:58
0

It seems like a good way to approach this would be to use a pattern like that described in this previous Stack Overflow answer.

They provide sample implementations there but to apply to your case, you don't need to give the GUI direct access, you can have a parent class which implements the "listener" functionality, and a child (GUI) class which just calls its parent, with those details abstracted away from the child.

If you feel like you need more details/examples on implementing this pattern see https://refactoring.guru/design-patterns/observer/java/example

Phoenix
  • 952
  • 2
  • 12