That’s a list of basic C# concepts. To see a pretty full list of basic concepts check out the scripting tutorials in the learn section.
For advanced techniques you want to be talking about design patterns, procedural generation, reflection, dependency injection and the like.
But reaching for a tool just because it’s advanced is a bad idea. Code should be no more advanced then is needed to do the job. Sometimes an ordinary hammer is more effective then a sonic screwdriver.
While everybody enjoys making sonic screwdrivers, they are rarely something that makes it out the door in a production game. What you want to do is learn how to solve simple problems in the context of Unity engineering, and then build upon those simple concepts to solve more and more complex problems.
What thing you use, sonic screwdriver or a nail file or a large brick is irrelevant. You should concentrate on what you (personally) have to say to the compiler to make it give you the result you want, and to do that you should learn the language you are using (obviously), but also the abstract language used to describe problems that may be solved by software.
But I like your last list item: USE THE DEBUGGER! As I said in another post, the DEBUGGER is the only friend you have when coding, because the COMPILER freakin’ hates you and is going to do everything in its power to thwart your good intentions. But in the end you will conquer it always if you know how to debug effectively.
Ok in Unity I often see people wanting to (this is based of seeing what people post on this forum)
Have an inventory system
Have an ability system
Have dialogues
Have some kind of cutscene scripting
AI
Logic flow (intro - game - game over - intro etc
Have game saves
Have a damage/health system
Have a bullet system
Have an interaction system
Each of these have multiple ways to implement using one or more of the techniques you listed in your first post.
Instead of just researching about those techniques abstractly. I would sit down with a real world problem and then decide how to solve it. The chances are you will probably end up using the OOP design patterns without really realizing you are!
IMO Its easier to grasp design patterns if you have a concrete use for them.
The complete lack of self-awareness of posting this particular and entirely substance-free reply to a six-year-old, substantive thread is kind of incredible.