Although I think that it cannot hurt to make him more familiar with design patterns, I want to make sure that your question will not combine two things. You said that the feedback you received was that your ability to apply design principles was weak, and you came to the conclusion that you need to study design patterns. But it is different.
A design pattern is a repeating pattern that you see in many different domains. For example, in architecture you see an example of a “courtyard” in many buildings of different types. In programming, you see patterns such as “a class that can only have one instance” or “a small piece of code that glues this with it” in many different programs.
But principles are not models. A pattern is a concrete, repeating view of a design; principle is the idea that underlies what makes a design suitable for users of an artifact created.
For example, the principle of designing the JScript language is to "forgive small mistakes." If you create a date object on November 31, it will silently fix this until December 1 instead of giving an error. There is no "small error forgiveness pattern." Fulfillment of a design error is a design principle - when we have a choice of how to develop a specific function, we will examine how it meets all the principles, some of which are contradictory, and use them to guide the design of the function.
This is not a C # design principle; in fact, the opposite is the C # design principle. Design principles are not good or bad in themselves; they are guidelines for what makes the design suitable for a targeted set of users.
Writing code without understanding the patterns means that there are no tools on the toolbar to facilitate common tasks. Writing code without understanding design principles means writing code that is inconsistent, hard to understand, and contrary to the needs of its users. Both are important, but they are very different.
Eric Lippert
source share