What is a proper way to separate data structure logic from its graphical representation?
It's more of a software design question, than strictly programming, so I'll paste UML diagrams instead of code for everyone's convenience.
Language is Java, so variables are implied references.
I'm writing an app, that helps edit a very simple data structure, that looks like this:
On my first trial run I've included all the drawing-related and optimization code into the data structure, that is, every Node knew how to draw itself and kept a reference to one of shared cached bitmaps. UML:
It was easy to add (fetch a corresponding bitmap and you're done) and remove (paint background color over previously mentioned bitmap). Performance-wise it was nice, but code-wise it was messy.
So on the next iteration I decided to split things, but I may have went to far and things got messy yet again:
Here data structure and its logic is completely separated, which is nice. I can easily load it from file or manipulate in some way before it needs to be drawn, but when it comes to drawing things get uncomfortable.
The classic way would be to change data then call invalidate() on drawing wrapper,but that's inefficient for many small changes. So to, say, delete 1 Tile Id have to either have Drawn representation be independent of Data and call deketeTile() for both separately, or funnel all commands to Data through Drawing class. Things get even messier when I try to add different drawing methods via Strategy pattern or somehow else. The horror:
What wis a clean efficient way to organize interactions with Model and View?
oop design-patterns
asked Nov 22 '18 at 12:19
IcedLanceIcedLance
1909
add a comment |
It's more of a software design question, than strictly programming, so I'll paste UML diagrams instead of code for everyone's convenience.
Language is Java, so variables are implied references.
I'm writing an app, that helps edit a very simple data structure, that looks like this:
On my first trial run I've included all the drawing-related and optimization code into the data structure, that is, every Node knew how to draw itself and kept a reference to one of shared cached bitmaps. UML:
It was easy to add (fetch a corresponding bitmap and you're done) and remove (paint background color over previously mentioned bitmap). Performance-wise it was nice, but code-wise it was messy.
So on the next iteration I decided to split things, but I may have went to far and things got messy yet again:
Here data structure and its logic is completely separated, which is nice. I can easily load it from file or manipulate in some way before it needs to be drawn, but when it comes to drawing things get uncomfortable.
The classic way would be to change data then call invalidate() on drawing wrapper,but that's inefficient for many small changes. So to, say, delete 1 Tile Id have to either have Drawn representation be independent of Data and call deketeTile() for both separately, or funnel all commands to Data through Drawing class. Things get even messier when I try to add different drawing methods via Strategy pattern or somehow else. The horror:
What wis a clean efficient way to organize interactions with Model and View?
oop design-patterns
asked Nov 22 '18 at 12:19
IcedLanceIcedLance
1909
What exactly made you feel that the first approach resultant code is messy?
– progmatico
Nov 23 '18 at 22:38
The code that deals with data, that is independent from any frameworks but standard libraries, is mixed with the platform-specific code that serves to visualize the data. The classes end up being pretty long and objects - heavy. I'm pretty sure it violates half if not all of SOLID and also makes unit testing hard as I need to mock platform-specific (android in this case) libraries for them. Also if I treat it as MVC it pretty much unites M and V in same class. Or at least that's what I think.
– IcedLance
Dec 3 '18 at 10:45
add a comment |
It's more of a software design question, than strictly programming, so I'll paste UML diagrams instead of code for everyone's convenience.
Language is Java, so variables are implied references.
I'm writing an app, that helps edit a very simple data structure, that looks like this:
On my first trial run I've included all the drawing-related and optimization code into the data structure, that is, every Node knew how to draw itself and kept a reference to one of shared cached bitmaps. UML:
It was easy to add (fetch a corresponding bitmap and you're done) and remove (paint background color over previously mentioned bitmap). Performance-wise it was nice, but code-wise it was messy.
So on the next iteration I decided to split things, but I may have went to far and things got messy yet again:
Here data structure and its logic is completely separated, which is nice. I can easily load it from file or manipulate in some way before it needs to be drawn, but when it comes to drawing things get uncomfortable.
The classic way would be to change data then call invalidate() on drawing wrapper,but that's inefficient for many small changes. So to, say, delete 1 Tile Id have to either have Drawn representation be independent of Data and call deketeTile() for both separately, or funnel all commands to Data through Drawing class. Things get even messier when I try to add different drawing methods via Strategy pattern or somehow else. The horror:
What wis a clean efficient way to organize interactions with Model and View?
oop design-patterns
asked Nov 22 '18 at 12:19
IcedLanceIcedLance
1909
It's more of a software design question, than strictly programming, so I'll paste UML diagrams instead of code for everyone's convenience.
Language is Java, so variables are implied references.
I'm writing an app, that helps edit a very simple data structure, that looks like this:
On my first trial run I've included all the drawing-related and optimization code into the data structure, that is, every Node knew how to draw itself and kept a reference to one of shared cached bitmaps. UML:
It was easy to add (fetch a corresponding bitmap and you're done) and remove (paint background color over previously mentioned bitmap). Performance-wise it was nice, but code-wise it was messy.
So on the next iteration I decided to split things, but I may have went to far and things got messy yet again:
Here data structure and its logic is completely separated, which is nice. I can easily load it from file or manipulate in some way before it needs to be drawn, but when it comes to drawing things get uncomfortable.
The classic way would be to change data then call invalidate() on drawing wrapper,but that's inefficient for many small changes. So to, say, delete 1 Tile Id have to either have Drawn representation be independent of Data and call deketeTile() for both separately, or funnel all commands to Data through Drawing class. Things get even messier when I try to add different drawing methods via Strategy pattern or somehow else. The horror:
What wis a clean efficient way to organize interactions with Model and View?
oop design-patterns
oop design-patterns
asked Nov 22 '18 at 12:19
IcedLanceIcedLance
1909
asked Nov 22 '18 at 12:19
IcedLanceIcedLance
1909
asked Nov 22 '18 at 12:19
IcedLanceIcedLance
1909
asked Nov 22 '18 at 12:19
IcedLanceIcedLance
1909
asked Nov 22 '18 at 12:19
IcedLanceIcedLance
1909
1909
What exactly made you feel that the first approach resultant code is messy?
– progmatico
Nov 23 '18 at 22:38
The code that deals with data, that is independent from any frameworks but standard libraries, is mixed with the platform-specific code that serves to visualize the data. The classes end up being pretty long and objects - heavy. I'm pretty sure it violates half if not all of SOLID and also makes unit testing hard as I need to mock platform-specific (android in this case) libraries for them. Also if I treat it as MVC it pretty much unites M and V in same class. Or at least that's what I think.
– IcedLance
Dec 3 '18 at 10:45
add a comment |
What exactly made you feel that the first approach resultant code is messy?
– progmatico
Nov 23 '18 at 22:38
The code that deals with data, that is independent from any frameworks but standard libraries, is mixed with the platform-specific code that serves to visualize the data. The classes end up being pretty long and objects - heavy. I'm pretty sure it violates half if not all of SOLID and also makes unit testing hard as I need to mock platform-specific (android in this case) libraries for them. Also if I treat it as MVC it pretty much unites M and V in same class. Or at least that's what I think.
– IcedLance
Dec 3 '18 at 10:45
What exactly made you feel that the first approach resultant code is messy?
– progmatico
Nov 23 '18 at 22:38
What exactly made you feel that the first approach resultant code is messy?
– progmatico
Nov 23 '18 at 22:38
The code that deals with data, that is independent from any frameworks but standard libraries, is mixed with the platform-specific code that serves to visualize the data. The classes end up being pretty long and objects - heavy. I'm pretty sure it violates half if not all of SOLID and also makes unit testing hard as I need to mock platform-specific (android in this case) libraries for them. Also if I treat it as MVC it pretty much unites M and V in same class. Or at least that's what I think.
– IcedLance
Dec 3 '18 at 10:45
The code that deals with data, that is independent from any frameworks but standard libraries, is mixed with the platform-specific code that serves to visualize the data. The classes end up being pretty long and objects - heavy. I'm pretty sure it violates half if not all of SOLID and also makes unit testing hard as I need to mock platform-specific (android in this case) libraries for them. Also if I treat it as MVC it pretty much unites M and V in same class. Or at least that's what I think.
– IcedLance
Dec 3 '18 at 10:45
add a comment |
1 Answer
1
active
oldest
votes
First, definitely decouple the app logic from UI. Make some model for your schematic. That will solve your trouble to unit test the app model, as you already said. Then I would try the Observer pattern. But given that a schematic can have lots and lots of graphical components (your Tiles), I would change the usual setup for notifying every observer when something changes in the model, to notifying only the corresponding GraphicalComponent (Tile), when a Component gets changed in the Model. Your UI asks Model to do things, and gets called back in some parts to update. This will be automatic, no duplicated calls, just the initial observer registry on GraphicalComponent creation.
answered Dec 3 '18 at 22:08
progmaticoprogmatico
1,9991512
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53430883%2fwhat-is-a-proper-way-to-separate-data-structure-logic-from-its-graphical-represe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
First, definitely decouple the app logic from UI. Make some model for your schematic. That will solve your trouble to unit test the app model, as you already said. Then I would try the Observer pattern. But given that a schematic can have lots and lots of graphical components (your Tiles), I would change the usual setup for notifying every observer when something changes in the model, to notifying only the corresponding GraphicalComponent (Tile), when a Component gets changed in the Model. Your UI asks Model to do things, and gets called back in some parts to update. This will be automatic, no duplicated calls, just the initial observer registry on GraphicalComponent creation.
answered Dec 3 '18 at 22:08
progmaticoprogmatico
1,9991512
add a comment |
First, definitely decouple the app logic from UI. Make some model for your schematic. That will solve your trouble to unit test the app model, as you already said. Then I would try the Observer pattern. But given that a schematic can have lots and lots of graphical components (your Tiles), I would change the usual setup for notifying every observer when something changes in the model, to notifying only the corresponding GraphicalComponent (Tile), when a Component gets changed in the Model. Your UI asks Model to do things, and gets called back in some parts to update. This will be automatic, no duplicated calls, just the initial observer registry on GraphicalComponent creation.
answered Dec 3 '18 at 22:08
progmaticoprogmatico
1,9991512
add a comment |
First, definitely decouple the app logic from UI. Make some model for your schematic. That will solve your trouble to unit test the app model, as you already said. Then I would try the Observer pattern. But given that a schematic can have lots and lots of graphical components (your Tiles), I would change the usual setup for notifying every observer when something changes in the model, to notifying only the corresponding GraphicalComponent (Tile), when a Component gets changed in the Model. Your UI asks Model to do things, and gets called back in some parts to update. This will be automatic, no duplicated calls, just the initial observer registry on GraphicalComponent creation.
answered Dec 3 '18 at 22:08
progmaticoprogmatico
1,9991512
First, definitely decouple the app logic from UI. Make some model for your schematic. That will solve your trouble to unit test the app model, as you already said. Then I would try the Observer pattern. But given that a schematic can have lots and lots of graphical components (your Tiles), I would change the usual setup for notifying every observer when something changes in the model, to notifying only the corresponding GraphicalComponent (Tile), when a Component gets changed in the Model. Your UI asks Model to do things, and gets called back in some parts to update. This will be automatic, no duplicated calls, just the initial observer registry on GraphicalComponent creation.
answered Dec 3 '18 at 22:08
progmaticoprogmatico
1,9991512
answered Dec 3 '18 at 22:08
progmaticoprogmatico
1,9991512
answered Dec 3 '18 at 22:08
progmaticoprogmatico
1,9991512
answered Dec 3 '18 at 22:08
progmaticoprogmatico
1,9991512
1,9991512
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53430883%2fwhat-is-a-proper-way-to-separate-data-structure-logic-from-its-graphical-represe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What exactly made you feel that the first approach resultant code is messy?
– progmatico
Nov 23 '18 at 22:38
The code that deals with data, that is independent from any frameworks but standard libraries, is mixed with the platform-specific code that serves to visualize the data. The classes end up being pretty long and objects - heavy. I'm pretty sure it violates half if not all of SOLID and also makes unit testing hard as I need to mock platform-specific (android in this case) libraries for them. Also if I treat it as MVC it pretty much unites M and V in same class. Or at least that's what I think.
– IcedLance
Dec 3 '18 at 10:45