jakemry said:
My questions are: Should the visualization code be a part of the grid class?

Usually no, especially if it involves gfx API calls, but you might replece the gfx API later.
But tbh, personally i do add debug visualization and GUI stuff to the class. This often even helps to figure out how the class works and what it's doing. So in some sense such debug code serves as documentation.
I do however make such code optional using preprocessor defines, to remove it from final release builds.

jakemry said:
Should the manipulation of data be a part of the grid class?

Usually yes. That's functionality tightly coupled to the data of the class, basically like those getters and setters we use for abstraction.

jakemry said:
I just don't know when the right time is to separate things or when I am creating too many layers. Are visualization and data unique enough to warrant separating them from the main class?

Usually you want to split a class if it starts to serve multiple purposes instead just one.
Notice visualization is a bad example. Because it should not affect the state of the data, it won't do any harm, and thus there shows no real need to separate it.
But let's say we have some GameObject class, and it has member functions like those:
DetectCollisions(), CalculateForces(), IntegratePhysics(), Animate, Render(), PlaySound().
That's surely too much. We quickly loose track of who might have affected state and when in unexpected ways.
So i would remove all those functions but put them into Physics, Animation, Rendering and Audio systems, which then may all depend on GameObject but the GameObject knows nothing about those systems.

But that's just personal opinion and habits. You can look up ‘SOLID’ for generally accepted guidelines.

In game development, it's beneficial to follow the Single Responsibility Principle (SRP) and separate concerns. Your grid class should primarily handle data and logic related to the grid structure and manipulation. Visualization code, such as rendering cells and edges, is best placed in a separate class, often referred to as a "renderer" or "view" class. This separation helps maintain clean, organized code and makes it easier to modify or extend either the grid or visualization independently in the future. Keep the classes focused on their specific responsibilities to avoid creating unnecessary layers and improve code maintainability.