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, no registration required.

As a C++ developer from the 90s during the great OOP wars, I put high value to OOP as a basis for hiring new C# developers into the company.

However, there are plenty of frameworks today like ASP.NET MVC that handles most of the OOP heavy lifting. Programmers without deep knowledge of OOP can just as easily follow the paradigm and still be able to complete their projects. OOP may not be as compelling as it was before for us application developers, especially with a framework like MVC.

I can see a few instance where OOP will be really handy, like for example developing a workflow type of a project. Or those with state-machine requirements. But really, most projects that really come by (at least to us here anyway) are just CRUD functionalities.

Below is my list when hiring. Is it fair to have OOP there as the number one item?

  1. OOP and Design
  2. Server side programming: C#, ASP.NET MVC and EF
  3. Client side programming: JQuery, CSS, HTML, etc.
  4. Database design
share|improve this question

4 Answers 4

up vote 3 down vote accepted

When I was learning MVC in PHP, I often thought that "this OO stuff is just functions wrapped by classes", especially since I was used to a procedural style of coding. But then I got more and more into researching design patterns, proper encapsulation, decoupling and general theory behind OOP.

I can say that understanding the OOP principles in the context of MVC really made a difference in the Model part of the app. While the controllers are still pretty much already laid out and all you need to do is fill the action methods with the proper code, and views are just html with some code here and there, the model is where knowledge of OO principles shows. When you have anything more than a dead simple CRUD app, it involves planning the domain classes. Then you throw in an ORM like EF to take care of persistence, and add some repositories to decouple from the EF implementation. Then you implement a unit-of-work to do persistence for each request. Then you throw in a DI container like Unity, to keep all of this nicely decoupled, mostly to allow for proper testing.

The "application" is in essence the domain model, with the entity classes, services and repositories, and if this part is done right, it almost makes no difference what kind of UI you put on top of it, be it an MVC app which serves pages, or some REST app which will send JSON to a mobile app, or a desktop app. A well designed Model can be reused across different applications.

Also, knowing OO principles will make it easier to understand how the MVC thing works in the first place, and help clear out some of the "magic" that might be happening under the covers, and it will make it easier to switch languages if necessary (and if the other language is also object-oriented).

In conclusion, I'd say yes, OOP and design is essential.

share|improve this answer

I’m also in charge of the technical interview in my company.
It’s hard to tell you what would be my number one item as I like people having a wide technical knowledge.

But, one thing that is sure, even if most of the actual frameworks we’re using tend to abstract the OOP thing, developers should know and understand at least a bit, what they’re using.

From my point of view OOP is still an important part to know and understand.
I’m still astonished by the number of people that cannot explain me the usefulness of an Interface! Or even what’s the difference between an Interface and an Abstract Class!

We’re really into Clean Architecture and we’re fan of the Onion one. How could a developer code the Application Core without knowing at least what an Interface is?

Knowing how to use EF, how to write some MVC or having basic knowledge of JQuery, is within reach for all developers.
Having good knowledge of what OOP is, how useful it is and when is it important to use it, might be the key difference between an average developer and the-one-that-you-really-want-to-hire.

share|improve this answer

I would expect a C# developer to have a good understanding of OOP. However, I get the impression from your list that your developer will be a generalist, and not a C# specialist.

If you choose your developers depending on their OOP knowledge, you might have a very clean controller and model; but they may not be able to write optimized SQL queries when the need arises, and your front-end architecture could end up being a huge mess.

Maybe you could try hiring people with complementary skills.

share|improve this answer

Being that C# is an object oriented language I guess it goes without saying that OOP is on the checklist for a C# developer, however it's amazing to me how many programmers (green or experienced) actually understand and live by the principles of OOP.

If I were you I would probably replace number one with SOLID principles.

share|improve this answer
    
you will be surprise to know that most candidates I interview have never come across SOLID principles in particular and their OOP theory is mostly obscured in general. At first I find this rather discomforting, but you can probably attribute the problem to the fact that most coding frameworks boosts their productivity in such a way that the need to be critical with OOP is not as compelling, thus my question above. –  Ronald Jul 10 '13 at 8:18
    
You'd be surprised to find that many of the experienced developers (and a majority of computer scientists) do consciously discard OOP and decline to take this pathetic model as any reasonable basis for their work. –  SK-logic Jul 10 '13 at 8:25
    
Have you got any articles describing that trend, SK? I find functional programming feels more expressive and concise, but then I was trained in applied maths, not computer science. –  Rob Lyndon Jul 10 '13 at 9:37
    
@RobLyndon, there is a huge number of articles on OOP criticism. But FP is subject to pretty much the same generic criticism - being just one specific model it cannot cover all the possible problem domain semantics, as well as OOP or any other narrow model. The main objection to objects is that this model should not be treated as a sort of "grand unifying theory" of everything, and applied with discretion. –  SK-logic Jul 10 '13 at 10:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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