It's common practice to use classes when needing to hold state.
However, I'm wondering if it's the best approach when you don't need all the baggage OOP comes with like inheritance, etc...<p>Here is an example of how I would go about it without classes :<p>function makePlayer() {<p><pre><code> const data = {
x: 100,
y: 100,
health: 300,
speed: 200
}
const methods = {
setHealth(value){
data.health = value
},
// etc...
}
return {...data, ...methods}</code></pre>
}<p>Do you think this is a good approach? If not, why?<p>EDIT: The question is meant to be general and not specific to a given framework or library. For something like React you use what is given by the library. There isn't much room for choice here.
OOP classes are commonly used because they seem to naturally map to physical objects, especially in games. However they can break down when trying to model the inevitable exceptions to this "natural" mapping or abstract concepts.<p>OOP is based on inheritance, but there is a school of thought that prefers composition over inheritance[1]. Composition is more flexible and usually more CPU cache efficient. Entity component system (ECS) is another way to store game objects based on composition. Instead of grouping properties related to a single object together, the same property from all objects are grouped together (thus it is usually more CPU cache efficient).<p>Someone made the argument the logical conclusion of ECS is a relational database: store and modify your (game) entities using SQL![2]<p>Another paradigm is using immutable state (works with either OOP-like objects or ECS-like entities). CRUD loses data that event-sourced objects can access later. (CRUD cannot remember what items were removed from a shopping cart without extra work; event-sourced objects naturally retain this information.)[3]<p>[1]: <a href="https://youtu.be/hxGOiiR9ZKg" rel="nofollow noreferrer">https://youtu.be/hxGOiiR9ZKg</a><p>[2]: <a href="https://hw.leftium.com/#/item/38545417" rel="nofollow noreferrer">https://hw.leftium.com/#/item/38545417</a><p>[3]: <a href="https://youtu.be/I3uH3iiiDqY" rel="nofollow noreferrer">https://youtu.be/I3uH3iiiDqY</a>
> Do you think this is a good approach? If not, why?<p>There is no real advantage to bundling data and methods together like: `{...data, ...methods}`<p>This just uses extra memory because every player must contain its own duplicate copy of the exact same methods.<p>Instead, methods should be stored outside the player object and require their input `value` to implement an "interface". For example, the input value for the `setHealth()` method must implement the "Health" interface.<p>TypeScript provides syntax for defining interfaces. I think JSDoc provides a way to implement interfaces with annotations. Otherwise, you could just manually enforce the interface as a convention.<p>In fact, JavaScript already allows you to attach methods to objects via Object prototypes. [1]<p>[1]: <a href="https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/Object_prototypes" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Ob...</a>
Take this from someone who has been down this road: you are way over-thinking this.<p>Until you accept this, you will be holding yourself back as a JavaScript developer.<p>If you need objects with encapsulated state and methods, use classes.<p>OOP does not magically introduce baggage or complexity.<p>Your proposed solution is still OOP. Coming up with your own OOP framework <i>will</i> introduce baggage and complexity.<p>Classes are highly optimized in modern JS engines.<p>Classes can be transpiled to performant code for legacy JS engines.<p>There are times when classes are not the right choice, but avoiding classes when they’re the obvious right choice is a clear indicator that a developer is unwilling to actually learn JavaScript.<p>Edit:<p>Your example code also has a bug, where your methods don’t actually mutate the properties of the returned object.<p>Please take the leap and just learn to use JavaScript classes!
For simple state management here is what I do: <a href="https://github.com/prettydiff/wisdom/blob/master/state_management.md">https://github.com/prettydiff/wisdom/blob/master/state_manag...</a><p>Here is an application with an OS-like GUI making use of that concept: <a href="https://github.com/prettydiff/share-file-systems">https://github.com/prettydiff/share-file-systems</a>
The reason some things manage state via classes etc is because it can change.<p>When health changes, maybe you want to change the UI to reflect the new health, without running a "updateHealthUI(data.health)" each time. Maybe speed is also based on health. When a project has enough people and every file is changing every day, sometimes you just want something to observe another state without them understanding the context around it. Most of the inefficiency in a large team is communicating context.<p>Don't use more than what you need. Sometimes you don't need React.
What problem are we trying to solve?<p>When I think of holding in memory state, to me it’s less about class or OOP vs something else and more about race conditions, thread safety, possibly idempotency, and proper abstraction design.<p>Abstraction design meaning, I’m not exposing the keys to the castle or leaking internal details where it might allow another good intentioned programmer to do bad things or introduce some subtle, difficult to reproduce bug.