I cant remember that we had any trouble organizing the data flows. Usually you want to keep your interfaces narrow and the class free of any dependencies. So you use callback functions to connect your UI to the business logic.
Think of a calculation tool with numerous inputs elements. You build a class that creates all or some of your input elements. The class has only three callbacks:
onInput
onUndo
onDismiss
When you use the class, you CAN apply these callbacks, but you don´t need to.
If the user inputs some data, the class collects all the data from the UI. If a callback is installed, it sends a JSON object with all the data. Or, it just sends a message that new data have arrived and lets the external logic grab the data they need directly. But in any case you do not need to know, WHO installed the callback.
So, you can establish direct connections between the business logic and an UI this way, but often you will use some kind of dispatcher to organize the data flow more explicit. So, the dispatcher installs the callback and gets informed, when a user input happend. Now he can decide, how to handle the message.
I know that there are lot´s of applications, where each button has it´s own event function. That brings you this kind of spaghetti data flow we should avoid. But if you start developing your UI based on classes, this is a way to organize the dataflow too.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I cant remember that we had any trouble organizing the data flows. Usually you want to keep your interfaces narrow and the class free of any dependencies. So you use callback functions to connect your UI to the business logic.
Think of a calculation tool with numerous inputs elements. You build a class that creates all or some of your input elements. The class has only three callbacks:
When you use the class, you CAN apply these callbacks, but you don´t need to.
If the user inputs some data, the class collects all the data from the UI. If a callback is installed, it sends a JSON object with all the data. Or, it just sends a message that new data have arrived and lets the external logic grab the data they need directly. But in any case you do not need to know, WHO installed the callback.
So, you can establish direct connections between the business logic and an UI this way, but often you will use some kind of dispatcher to organize the data flow more explicit. So, the dispatcher installs the callback and gets informed, when a user input happend. Now he can decide, how to handle the message.
I know that there are lot´s of applications, where each button has it´s own event function. That brings you this kind of spaghetti data flow we should avoid. But if you start developing your UI based on classes, this is a way to organize the dataflow too.