71 reputation
5
bio website
location
age
visits member for 1 year, 10 months
seen Jul 14 at 15:19

Feb
27
comment Using the mouse as a multi-tool creates heavy conditional logic for executing commands, how do I change this?
I mean, obviously I won't really get "rid" of the logic. I'm just looking for different solutions to encode it in different ways/places. I've never built anything with a large "command tree" so I'm just kinda putting feelers out there.
Feb
27
comment Using the mouse as a multi-tool creates heavy conditional logic for executing commands, how do I change this?
In a more simple app, where actions are only based on 1 variable, this is definitely the way to go. But I'll end up with (at least) 3 variables (scope, mouse-button, object-state) to determine the click action. Which is leading me more and more to the Factory pattern; one isolated place to create the Commands because their creation logic is complicated.
Feb
27
comment Using the mouse as a multi-tool creates heavy conditional logic for executing commands, how do I change this?
I think an understanding of the Command pattern might help you understand my question better. So would a better example on my part :). Although, I see what you're getting at in a general, a hashmap could only get rid of one layer of conditional logic, there are still a lot of paths to get which Command to execute based on the mouse's target.
Feb
27
comment Using the mouse as a multi-tool creates heavy conditional logic for executing commands, how do I change this?
Yeah, I'm not using a specific framework, and I'm probably a more unusual edge case (interactive music notation on HTML5 Canvas) where most frameworks don't actually give me that useful of a boilerplate. All my views test for click detection, so I know the targets of the specific click at the beginning of the method determineClickCommand(clickedFocus). I figured it would be better to have one isolated place where all Commands are being created based on the mouse's target(s) and their individual states, as opposed to creation being scattered to various views.
Feb
27
comment Using the mouse as a multi-tool creates heavy conditional logic for executing commands, how do I change this?
I'm more concerned with the overall design, so language isn't a big deal. But I'm not exactly sure I understand what you're saying.
Jan
16
comment How to refactor “nested” view classes to avoid deep method calls?
This is what I was looking for. So essentially, I need to decouple the model and view further with a controller (basically implementing a MVC pattern). Do I have this correct?
Jan
16
comment How to refactor “nested” view classes to avoid deep method calls?
@DocBrown Apologies, but I was doing some research in trying to see how I could restructure with more clarity in general. But I think Shivan's answer best answers my question. EDIT: fixed error
Nov
19
comment Music Notation Editor - Refactoring view creation logic elsewhere
@JW01 See my update above for my response. And thanks for the book suggestions! I'll check them out.
Nov
18
comment Music Notation Editor - Refactoring view creation logic elsewhere
@JW01 The thing is I'm not sure how to solve certain notation logic without it. For instance, a note needs to know about all previous notes in a measure as well as the measure's key to determine their accidentals. And yes, I have a "Editor" entity which will contain the entire app. Probably will end up factoring in an "Instance" class so you could swap between multiple scores.
Nov
17
comment Music Notation Editor - Refactoring view creation logic elsewhere
You are right, however, I may want to separate the layers into a public API at some point. So having similar semantics to the traditional model was something I was trying to maintain. Also, for ties I have a Duration class which deals with all duration modification (dots, tuplets, ties, etc)