Design pattern frustrations

Question

I am a developer having 4 years of .Net coding experience, And never cared much about design patterns in my carreer. Recently i have been called for an interview with one of the biggies in the IT, have done 5 rounds (problem solving, pair prograaming , logical reasoning, 2 rounds of tech interview) of interview and didnt offer a job.

The feedback i got from them is am not good at design principles though they are satisfied with my technical & logical reasoning skills. This one made me think that knowing design patterns are the only way to solve the problems?

Though i never used much of a design patterns in my coding, i always tried to implelement the basic principles of OOPS

• Open/closed principle (OCP)
• Dependency inversion (DI)
• Interface seggregation
• Liskov substituion principle (LSP)

I could use these principles to design a system thats loosely coupled and open for enhancements and easy to maintain. Eventtually these are the core constructs of all the design patterns.

But my problem is to find a right pattern for the right problem. I know this knowledge will not come by just reading all the books published in design patterns and practises. this knowledge comes with the experience of building different systems.

Is there any use cases available for the pattern-problem matching.. And your suggestion on learning design principles?

Cheers

Answer 1

Though I think it cannot hurt to become more familiar with design patterns, I want to make sure that there's not a conflation of two things in your question. You said that the feedback you got was that your ability to apply design principles was weak, and you concluded from that feedback that you need to study design patterns. But that's different.

A "design pattern" is a recurring pattern that you see across many different domains. For example, in architecture you see the pattern of "interior courtyard" in many different kinds of buildings. In programming you see patterns like "class that can only have a single instance" or "little hunk of code that glues this to that" in many different kinds of programs.

But principles are not patterns. A pattern is a particular recurring sort of design; a principle is an idea that underlies what makes a design good for the users of the artifact being designed.

For example, a design principle of the JScript language is "be forgiving of small errors". If you make a date object for November 31st, it will silently correct that to December 1st instead of giving an error. There's no "small error forgiveness pattern". Making a design error-tolerant is a design principle -- when we have a choice on how to design a particular feature we consider how well it aligns with all the principles -- some of which are contradictory -- and use those to guide the design of the feature.

This is not a design principle of C#; in fact, the opposite is a design principle of C#. Design principles are not good or bad in of themselves; they are guidelines for what makes a design good for its target set of users.

Writing code without understanding patterns means not having the tools in your toolbox that make doing common tasks easier. Writing code without understanding design principles means writing code that is inconsistent, hard to comprehend, and contrary to the needs of its users. Both are important but they are very different.

Answer 2

Design patterns are called patterns because they keep showing up time and time again in many independent programs, not because they're used to put together programs in the same way that squares are stitched together to make a quilt. They can help lead to a solution for a software problem, but they are not a solution in and of themselves.