this post was submitted on 12 Jul 2025
14 points (100.0% liked)

Rust

7166 readers
2 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago
MODERATORS
 

An interesting article that lays out a problem and goes through a few different solutions, some of which I haven't thought about much before.

I'm working on a video game in Rust, and I'm running into this kind of modelling problem when it comes to keeping track of the game state. So far I've refactored something that resembles Approach 5 into something that looks more like Approach 3. As I get more confident about the final shape of the data, it (seemingly) becomes a better idea to represent it in a more structured way.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] TehPers@beehaw.org 6 points 1 week ago (1 children)

To me, it seems like this article is overemphasizing code duplication as problematic. If multiple types of searches use some of the same fields, it's okay to just copy them to each search type that uses them. This also allows each search type to be independently updated later on to add additional fields or deprecate existing fields without affecting other search types.

Fields that should always exist together should probably be moved to a struct containing those fields, if there's some concept that encapsulates them. Paging fields, for example, that exist only on two of three variants can just live in their own struct, and those two variants can have fields of that type.

Code duplication is only really problematic when all duplicates need to be updated together every time. That does not seem to be the case here.

seems to me he's trying to be more general than the Search example and considering that another complex project may actually have those problematic cases

i mean, he doesn't even dismiss the patterns with code duplication, just lists it as a drawback, which agrees with his conclusion that there's no one-size-fits-all solution