Summary
Design patterns are good to know, but even more important are design principles. If you don't know why you're using a design pattern, you shouldn't be using it.
Advertisement
In So You Call Yourself a Java Programmer I said how utterly disappointed I was that none of the four candidates I had interviewed knew the four access modifiers in Java. Tomorrow I have another interview scheduled. Most programmers put design patterns on their resume, so I generally ask them what they think about design patterns and give me some examples.
Most are able to give me some examples - singleton, factory, etc. - but ideally I would like them to go beyond citing actual design patterns and actually discuss the rationale behind the patterns. In some ways design patterns mask critical thinking. Software engineers know about them and know how to use them, but a good portion - dare I say the majority - don't understand their evolution. In other words, they can answer, give me some examples of design patterns, but are stumped when asked what are some principles of good object-oriented design.
This is what I'm looking for (courtesy cilu/codeguru.com)
Open Close Principle (OCP)
Liskov Substitution Principle (LSP)
Design by Contract
Dependency Inversion Principle (DIP)
Law of Demeter (LoD)
Interface Segrgation Principle (ISP)
Reuse/Release Equivalency Principle (REP)
The Common Reuse Principle (CRP)
Common Closure Principle (CCP)
Acyclic Dependencies Principles (ADP)
Stable Dependencies Principle (SDP)
Stable Abstractions Principle (SAP)
This is obviously not an exhaustive list and I'm not really looking for the candidate to spout off the names of all these design best practices; just give me in their own words what makes a good design. So it's fine that you don't use the word orthogonal as long as you explain why it's important. As long dependency management is mentioned that's all I need, because that's what it's really all about - managing depedency.
> <p>In <strong><a > href="http://work.tinou.com/blog/2005/09/so_you_call_you.ht > ml">So You Call Yourself a Java Programmer</a></strong> I > said how utterly disappointed I was that none of the four > candidates I had interviewed knew the four access > modifiers in Java. Tomorrow I have another interview > scheduled. Most programmers put <em>design patterns</em> > on their resume, so I generally ask them what they think > about design patterns and give me some examples. </p> > > <p>Most are able to give me some examples - singleton, > factory, etc. - but ideally I would like them to go beyond > citing actual design patterns and actually discuss the > rationale behind the patterns. In some ways design > patterns mask critical thinking. Software engineers know > about them and know how to use them, but a good portion - > dare I say the majority - don't understand their > evolution. In other words, they can answer, <em>give me > some examples of design patterns,</em> but are stumped > when asked <em>what are some principles of good > object-oriented design</em>.</p> > > <p>This is what I'm looking for (courtesy > cilu/codeguru.com)</p> > > <ul><li>Open Close Principle (OCP)</li> > > <li>Liskov Substitution Principle (LSP)</li> > > <li>Design by Contract</li> > > <li>Dependency Inversion Principle (DIP)</li> > > <li>Law of Demeter (LoD)</li> > > <li>Interface Segrgation Principle (ISP)</li> > > <li>Reuse/Release Equivalency Principle (REP)</li> > > <li>The Common Reuse Principle (CRP)</li> > > <li>Common Closure Principle (CCP)</li> > > <li>Acyclic Dependencies Principles (ADP)</li> > > <li>Stable Dependencies Principle (SDP)</li> > > <li>Stable Abstractions Principle (SAP)</li></ul> > > <p>This is obviously not an exhaustive list and I'm not > really looking for the candidate to spout off the names of > all these design best practices; just give me in their own > words what makes a good design. So it's fine that you > don't use the word orthogonal as long as you explain why > it's important. As long dependency management is > mentioned that's all I need, because that's what it's > really all about - managing depedency.</p>
OK - I like your prejudices but my guess is that less than 2% of developers and less than 10% of "architects" will recognize these principles. I sometimes wonder if, after EJBs, the GoF book, despite its brilliance, has been one of the more destructive software contributions. I think that 90% of teh design patterns I see in the field are plain and simple wrong. Singleton is even better - it's a watse of space at least 98% of the time.
I agree Peter's statement "I sometimes wonder if, after EJBs, the GoF book, despite its brilliance, has been one of the more destructive software contributions."
I have long felt that this lust for patterns is unnatural. Patterns will occur in a natural way, you do not have to go looking actively to include patterns in your work.
Unfortunately, knowledge about the implementation of patterns without understaning the problem domain causes more harm than good.
I'm not sure asking someone about abstract principals is a good interview technique. It is so vague and open-ended.
Better to ask for a solution to a specific problem and see if any good principals and/or patterns emerge. Then, if the candidate can't come up with anything, you've learned enough and if the the candidate comes up with something nice, you can explore the process and thinking behind it.
My 2 cents. Design Patterns are like tools in a mechanic's tool box. They should have it but should not use it only because they have it. Design principles are the set of guidelines. Any good design shall not neccesarily satisfy all the design principles but never the less the developer should think through it and use what ever looks suitable.
Nakedly asking about abstract principles only demonstrates that the candidate has read the right books not they he understands them. The first question I ask in an interview is about the candidate's most recent project. If a candidate can explain it to me in plain language and I understand it in a few minutes then they understood what they did.
I then use that project as a jumping-off point to delve deeper into their knowledge. My asking questions like, "how was it designed?", "why was is designed that way?", "what were the alternatives?" and "how would you have done it different?" In fact that last question is one of the most important. A programmer or architect that hasn't learned any lessons from his previous project is not the person you want working for you.
i want some infomation about factory and abstract factory method, i confused it, so that please send information quick as possible, because i give presentation to my friends,
Previous Topic
