Encourage students to learn and use advanced design I mentor an FRC (FIRST Robotics Competition) team, and they program in java.

The team members who work programming the robot are using an extension1 library which they themselves write.

The library that they write doesn't exactly follow good design concepts. for example, instead of having an interface for describing the functionality of a moving subsystem (a robotic forklift, for instance), they have a class that extends a subsystem, and it contains that functionality.

This is one example, and there are quite a few other examples. I say this to explain that they have quite a bit of code already written, and it would be difficult to make it more abstract and write it with a higher level of design.

So my question is how can I approach the subject, and encourage the students to want to learn and use higher levels of abstractions?

By "approach", I mean bring up the matter, without making it sound as though I think they have to do it, or that their code "won't ever be good unless they do it".

The students can learn it (i.e. they are able and capable of learning those concepts). This question isn't about how to teach it, but rather how to encourage the students to want to learn and apply those concepts

A clarification: I am not their teacher, I am a mentor. I do not teach them, but rather I help them learn (it's informal)

Proper design and abstraction makes code, especially libraries, easier to maintain and easier to use, and also prevents some types of bugs and errors.
That is one of the main points of design patterns, as well as a "side-effect" of following SOLID principles.



1Without going into too much details, I'll say that there is a supplied library for programming the robot, and the team is writing an extension of that library.
The most fundamental shift in my programing came from my attitude about details.
When I was young I wanted to pull every detail out of everything I touched, pin in down in front of me in one source file and beat it into submission. I could stand in one place and know everything.
After decades of programming my attitude is: the less I know the better. Dealing with a detail? Feh, I let other things deal with that. I already have plenty of stuff to think about right here thank you. I don't need more clutter.
I have shifted from a procedural mind set to a more abstract one.
That sounds fancy but all it means is that no mater where I am in the code, I want to think about only one problem, in only one way, from only one perspective.  Any detail that distracts from that is getting tucked away somewhere. I work very hard to make it that easy because I'm that lazy.
There are many ways to try to teach this, problems that invite students to drown themselves in details if they aren't careful. But one guiding principle has helped me see when I'm doing it right.  It has many names but the one I'm most fond of is:
Tell. Don't ask.1,2,3,4,5
If I have to ask a question then I have to deal with the answer. Usually that's a detail. The only reason I ask is because I want to do something and I don't have enough information to do it. Why can't I just tell the thing I asked to just do my something? It knows the answer, so it knows what it needs already. I should be able to just tell it &quot;do it now&quot; and it should be able to go do it without making me think about it.
Adopt this attitude and working abstractly becomes very appealing. Without it, abstraction and polymorphism are very annoying because they're getting in the way of you knowing everything. Teach your students to love not knowing.
I don't know. I don't want to know.

How to motivate students to use this?
Don't.
Motivate them to explore it. Which is better is not a settled issue. What you should teach is what problems this style addresses. How to identify situations that create a greater need for it. How to identify situations where it's irrelevant.
I've been studying every programming principle and style I could find for decades now and not one of them is something I would advise someone to adopt without critically analyzing how and whether to apply it in any given situation.
What I do recommend is practicing with them. Until you've used one while solving a real problem all your doing is being a tourist. I've watched people end their career by waving a book around preaching principles without knowing how to solve a problem.
When interviewing prospects I'd rather hear:
&quot;If you follow principle x it may help with this y issue.&quot;
than
&quot;You should always follow principle x. It's good design. Professionals always follow good design.&quot;
Spare me from fanatics that follow rules without thinking.
Encourage them to learn every principle, pattern, and practice they can. Not because they should always use them, but because when they look at code that already uses them they should understand why the code looks the way it does.
The reality is true professionals spend most of their time wading through crap code trying to get what they need out of it while causing the smallest amount of fuss they can.
The really good ones will spot some tiny little improvement they might be able to get away with while they're here. These &quot;boy scouts&quot; leave the code a little better than they found it. Give me those over the crusaders that want a complete rewrite every time they look at a new code base.
Cultivate in them a skeptical &quot;boy scout&quot; attitude. Give them all the tools but teach them to use them sparingly, wisely, and carefully.