Design pattern frustrations

Question

Hi,

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

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.

Answer 2

I am sure that you have used some design patterns if you have been programming for 4 years although you may not be aware that you did.

Design pattern will teach you to solve some problem that some one has already gone through and found solution for it. and finally documented it for us.

If you want to learn design patters you can start with "Head First Design Patterns" it is a great book.

Answer 3

Even though you use C#, I'd suggest going through some of the books on patterns. First would be the GoF book - Design Pattens. Then try reading some book on Enterprise Design Patterns. As you read, you'll recognize (or see) the Pattern. This is generally an "Aha" moment.

You'll also recognize the same from your own code. Knowing patterns will help you in good designing. It helps in knowing the patterns as you'll immediately recall the pattern when a problem related to it arises.

The programming principles you specified are good and DO follow them. However they are more at a class level. Moving higher up to the System design, Patterns will be more helpful.

Most importantly - Patterns give you a vocabulary to discuss design ideas with whole team.

Answer 4

I'm not sure what you really need is design patterns. You probably need more general understanding of design. Giving more advice on that will be difficult without more info.

Design patterns (as in GoF style) work best with a particular style of writing code. Imagine your classes not as things, but as people. Imagine that these people then communicate to each other, by something like passing notes, or through inter-department mail or something like that.

In general, the ways in which these people communicate, and the patterns of message flow, are pretty close to the GoF design patterns. The patterns that don't match this are typically 'helpers' that are required to write applications that fit this model.

Answer 5

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 6

Try this book, it is funny and gives you not only how to implement the pattern, also when to do it.

http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124