To OOP or not to OOP

My original objective was to just check what best ORM solution is currently for Microsoft technolgoies, then find out a good sample and customize it for my purpose. I stumbled upon number of articles. Notable amongst them were: “Object-Relational Mapping is the Vietnam of Computer Science” and “Why Objects Suck”.

These articles, even if old, seemed relevant to me. It took whole lot of time to read them (incluiding referred and linked articles) and understand. Especially the Vietnam analogy article by Ted Neward takes lot of patience to read (but its interesting anyways). 

I thougth its worth writing about my learning after having read so many things.

First of all, object oriented programming is not a magic silver bullet. There is literally a war going on between proponents and opponents of OOP. Summary of opponents’ opinions is:

• OOP makes things complex for simple stuff
• there is insufficient justification to use it on real world problems given the frequent requirement changes (reworks in inheritance etc) and,
• problem of OR mismatch impedance is too difficult to get away with in real world domains  

Of course, proponents have their own views along with favorite languages and tools that solve problems for them. But I felt opponents had stronger and generalized voice.

Secondly, OR mapping is really stupid thing to worry about. It is matter of choice and comfort of programmer. Now, I am really doubtful that people in our team are using either object orientation or OR mapping techniques (be it LINQ or ADO.Net or NHibernate) that extensively. However, as a group lead of programmers working on different applications, I need to make sure that there exists common understanding between the team and code is written is such a way that it can be transferred to other developers easily. Moreover, given the nature of data centric outputs demanded out of applications that we develop, sticking to relational philosophy seems more appropriate.

Finally, to work in OOP fashion or not is most often the matter of technical consensus within team or the authority of architect or tech lead to drive it.

Lastly and frankly speaking its really unjust to decide programmer's (whether fresh or inexperienced) ability based on his knowledge of OOPs concepts and unfortunately I still hear interviewers reject candidates based on this premise.