Timeline for How to organize logic for table-like feature set? Looking for architecture pattern advice
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 30, 2020 at 14:12 | answer | added | Flater | timeline score: 1 | |
| Nov 27, 2020 at 17:28 | history | edited | Pavel Oliferovskiy | CC BY-SA 4.0 | added 125 characters in body |
| Nov 27, 2020 at 16:18 | history | edited | Pavel Oliferovskiy | CC BY-SA 4.0 | added 137 characters in body |
| Nov 27, 2020 at 16:15 | answer | added | TheHowlingHoaschd | timeline score: 1 | |
| Nov 27, 2020 at 12:12 | comment | added | rwong | Are you able to add a diagram that illustrates your current architecture? It's a bit hard to visualize your complexity concerns. | |
| Nov 27, 2020 at 11:38 | comment | added | Pavel Oliferovskiy | yes, but solving it for every feature-battle crossing will require tons of plumbing code. | |
| Nov 27, 2020 at 10:36 | comment | added | rwong | // since in that case some low-level class will have a direct call to high-level helper class // This can be solved using interfaces and reverse-interfaces (interfaces of callbacks), among other mechanisms. See: dependency-inversion principle. | |
| Nov 27, 2020 at 10:19 | comment | added | Pavel Oliferovskiy | // Have you tried to extract some of those logic into utility functions and helper classes // That will not help, since in that case some low-level class will have a direct call to high-level helper class, thus the problem of "one class knows too much" is still there. That is also makes the class unusable in all different projects that can or cannot include some of the features, listed there. | |
| Nov 27, 2020 at 10:14 | history | edited | Pavel Oliferovskiy | CC BY-SA 4.0 | added 120 characters in body |
| Nov 27, 2020 at 10:00 | comment | added | Pavel Oliferovskiy | Thanks, @rwong! I agree with decoupling idea, that's why I'm trying to find the solution here, and the third "table" option is just about that. Text-based script language sounds fun and useful, although not all platforms allow that. IOS for example is rather strict about executing any non-native code, since it opens a possibility to alter application behavior on the fly and externally. So I'm not sure about that. If I get it right, the "Template-method pattern" which you suggested, then it sounds exactly like my second solution. I'll update the text with that qualification, thank you! | |
| Nov 27, 2020 at 9:49 | comment | added | rwong | Command pattern (link: Wikipedia) | |
| Nov 27, 2020 at 9:48 | comment | added | rwong | // one class contains too much different logic // Have you tried to extract some of those logic into utility functions and helper classes, in order to keep the high-level code tidy and easy to read? | |
| Nov 27, 2020 at 9:39 | comment | added | rwong | Template-method pattern (link: Wikipedia) | |
| Nov 27, 2020 at 9:33 | comment | added | rwong | All of your approaches are good ones at different stages of software development (i.e. prototyping). As the complexity of game design (note: game design is not software development) increases, there is an increasing need to decouple the complexity of game design from the complexity of software development. | |
| Nov 27, 2020 at 9:30 | comment | added | rwong | Many large-scale games ended up implementing a scripting system, where the high level design (game design) can be done by editing a text-based script language, without having to rewrite the low-level implementation code. | |
| Nov 27, 2020 at 9:24 | history | edited | Pavel Oliferovskiy | CC BY-SA 4.0 | edited body |
| Oct 30, 2020 at 18:15 | history | edited | Pavel Oliferovskiy | CC BY-SA 4.0 | edited body |
| Oct 30, 2020 at 15:55 | history | edited | Pavel Oliferovskiy | CC BY-SA 4.0 | added 21 characters in body |
| Oct 30, 2020 at 15:50 | review | First posts | |||
| Nov 13, 2020 at 15:52 | |||||
| Oct 30, 2020 at 15:49 | history | asked | Pavel Oliferovskiy | CC BY-SA 4.0 |