Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

More specifically, what do you feel Junior, Intermediate, and Senior programmers should know about OO design and programming?

I'm hoping that having some appropriate expectations will help us during the recruiting process.

share|improve this question

closed as primarily opinion-based by Ixrec, durron597, GlenH7, MichaelT, Snowman Jul 4 at 17:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

What sort of programmer? I'd expect the level of expertise to be different between embedded programming and writing desktop apps. –  David Thornley Oct 15 '10 at 15:13
Wouldn't the correct answer depend on the job requirements? If someone was going to work on functional software, would the OO requirements be different from those of a web shop or a video game? –  dash-tom-bang Oct 15 '10 at 16:51

2 Answers 2

If they develop in a OO language, I guess the answer is that they should understand the OO design and programming at 100%

However, if you are hiring a junior, I think you can be more flexible, and judge its ability to learn new concepts rather that its knowledge level at the time of the interview.

share|improve this answer
+1 for "ability to learn new concepts". –  Liggy Oct 15 '10 at 13:35

All levels should :

  1. Know Design Patterns (this is mostly understood to be the compilation by GoF, but also some other such as Dependency Injection, etc).

  2. Understand how to model the interactions thru Use Cases a.k.a. "user stories".

  3. Is careful with inheritance. (EDIT, by request from OP: Basically, inheritance is recommended to be used very carefully as it leads to so-called "white-box reuse" (meaning that implementation details of base class are no longer hidden), which breaks the spirit of OOP. If you really need to reuse a class functionality you can often yield much bettter results by object composition, as it does not change the OOP landscape and leads to a cleaner design. This is summed up by the famous principle : "Favor composition of objects over inheritance". This does not mean however that inheritance should always be avoided, just that other venues should be explored first.)

  4. Programs to interface rather than to class.

  5. Understands UML and is able to describe his design through UML.

  6. Never, ever comes up with the "best possible" design right in the first iteration.

  7. Can identify potential problems with own design = understands contraints under which interfaces and classes are usable.

share|improve this answer
Great points! Can you perhaps elaborate on "Is careful with inheritance"? –  Liggy Oct 15 '10 at 13:37
I've never met a developer who used UML in real world stuff. I'm sure it's great for management, but is it part of understanding object orientation? Not for me. –  glenatron Oct 15 '10 at 13:41
@glenatron - I once worked with a guy who literally said - "I never needed to make any notes". Does that mean his point is valid? I'm sure for him it's valid, but for me - no. –  Jas Oct 15 '10 at 13:45
@Liggy, I've edited my answer to include a bit of explanation for poit 3 (Inheritance). Hope it helps. –  Jas Oct 15 '10 at 13:52
-1 because of #2 and #5. These are good practices but have nothing to do with OOP. UML is a tool often used for capturing OO design, but it is not at all required. –  Matt Olenik Oct 15 '10 at 14:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.