Timeline for How to deal with different level of abstractions (blurred line between data and models)
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 20, 2021 at 14:13 | comment | added | Zazaeil | @ibi0tux than you question is quite misleading. You are asking about inheritance and the way compile-time known abstractions are related. I see no connection to dynamic/runtime here. Maybe you could rephrase your question and provide more specific illustrations of your particular problem? | |
| Jan 20, 2021 at 14:10 | comment | added | ibi0tux | yes, but my problem is that thoses facades are in my case supposed to be created at runtime. | |
| Jan 20, 2021 at 14:06 | comment | added | Zazaeil | @ibi0tux > a facade is an object that serves as a front-facing interface masking more complex underlying or structural code. That is exactly what you have described. | |
| Jan 20, 2021 at 14:04 | comment | added | ibi0tux | Sorry, maybe my question wasn't clear. What I meant is that the data end user will manipulate are MyForm instances. The user can create a form model just like MyForm is, but form models will be instanciated to create different forms. Data from those forms will be collected and stored (and this is why defining a data model for each form model is important), etc. The point is there is already a "data model" structure that exist (the classes), why couldn't I use the same mechanism to represent "end-user data models" too ? | |
| Jan 20, 2021 at 13:56 | history | answered | Zazaeil | CC BY-SA 4.0 |