There are likely to be cases where you use the grid without rendering it (e.g. simulating offscreen places) and more importantly different ways to render the same game state from the grid (e.g. realtime main view in third person 3D, realtime minimap from an overhead perspective, exported high quality video).

Even without such slightly advanced usages, defining and respecting a boundary between game data and rendering will produce a simpler and cleaner design.

It depends what you're trying to accomplish. If you're trying to make the next Unreal Engine 5, then stick to the books. If you're trying to make a game, though, do what works and refine it on the next game.

troutsneeze said:

If you're trying to make a game, though, do what works and refine it on the next game.

I'm afraid this sounds like advice to ignore traffic lights because one is in a hurry, but slow down at the next intersection: if a game project is abandoned because it has become too complicated to make progress, the next project might not exist at all.

Afraid I couldn't disagree more, but there's no sense in arguing. I do have over a dozen (probably 2 dozen) published games since the 1990s to back me up.

troutsneeze said:

I do have over a dozen (probably 2 dozen) published games since the 1990s to back me up.

This is the “For Beginners” forum. You know how to “do what works” with small and rare mistakes and you probably don't even see organizing data structures and rendering as a challenge; but someone “having frequent trouble with designing my classes and structuring my code” needs more actionable and specific advice than spending years to reach your level of experience.

Splitting a complex design (here a self-rendering grid) into two simpler and therefore easier designs (here a grid and a renderer) is a safe general principle to follow for a beginner because minimizing difficulty is more important than minimizing effort or code size.

An expert who can predict and avoid mistakes could be confident enough to combine the two systems in order to write less code, but (another useful general principle for beginners) cutting corners is something that should be attempted prudently after you “stick to the books” and succeed.