this post was submitted on 05 Feb 2025
16 points (94.4% liked)

Programming

18101 readers
42 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
16
How do you structure your models save/load code? (lemmy.pe1uca.dev)
submitted 2 days ago by pe1uca@lemmy.pe1uca.dev to c/programming@programming.dev
12 comments fedilink hide all child comments
 

I have in mind two options:

  • Code in the class being saved/loaded. The flows for each entity/model are in the same place, so it's easy to just have one file open to see all the functionalities of that class, but this means having more code in a single file.
  • Code in a dedicated class (like a factory)
    This makes each file smaller, but spreads flows of a single model into different parts of the repo, also because I'm thinking of having a directory /src/models and another like /src/export (or serialize)

What do you guys think?
What's your preferred way to organize the save and load flows?

you are viewing a single comment's thread
view the rest of the comments
[–] packadal@beehaw.org 2 points 2 days ago

You should group your source files by domain, then by feature, e.g. 'src/foo/model' and 'src/foo/exports'.

Is serialization/deserialization the only aim of these structures ? If not, that code should definitely be separated, so as to evolve separately from the structure itself.

If it is the only aim, the code should also be separated, so you can change your serialization type (e.g. from JSON to XML) without impacting the model.

Also you might need another export for compatibility with another software, and you don't want your model file to grow with the 10 formats you support.