I think there are two parts to it. First, you want to push them to get into the habit of solving problems by expressing the question clearly enough that the answer falls naturally from it. That's so fundamental that every aspect of engineering benefits from it, but it's particularly important as a first step in writing code.

The second part is building the intuition for the abstractions themselves. That's tricky as they have to teach themselves. They need to build coherency in their internal mental langauge of abstraction, and the only way to do that is to work directly on real code, and work through the consequences of doing it one way vs. another.

That means you have to let them commit code you don't like. By all means, explain what your concerns are, but then let them see how it evolves and as it becomes more untenable, that's when you go back to rethinking it and trying to state the problem clearly.

Likewise, when they do it well, you can highlight that, especially drawing attention to changes to their code that worked nicely.