Object Oriented Programming was once heralded as the savior of the programming industry. With inheritance, polymorphism and encapsulation OOP was supposed to make complex programming easy. Over a decade later OOP has become just another good idea that fell short of its lofty goals. The blame for this lies more with the people who have attempted to use it rather than the methodology itself.

Outside of a few circles, object oriented programming was never fully understood and much less properly utilized by the mainstream programming crowd. Coming from a mindset of the Functional Programming model, objects merely represented logical structures from which to continue and extend their Functional Programming roots. The failure of the programming community as a whole to completely grasp the OOP methodology is why it continues to suffer low adoption and poor results from its use.

While most programmers parrot the tenets of OOP - Inheritance, Polymorphism, and Encapsulation - they fail to grasp the even more important subtleties required to properly utilize these tools.

Probably the most important subtlety is that a class must be designed to perform precisely one function and nothing more. This means that classes are usually very small with neglegable amounts of code, yet are still meaningful to other classes. A properly designed OOP project will have small bits of code spread across large numbers of classes, each class dealing only with one specific function, such as comparing two digits to determine which is larger.

Where OOP fails is when a project contains one or more classes known as "God Classes". A God Class is a class that contains large and far-reaching knowledge of data and processes that are not directly controlled by that class. Such classes are in direct contrast with OOP principles.

Consider a house to be an OOP project, and the rooms within that house to be classes. Each room serves a specific purpose. You sleep in the bedroom. You do laundy in the laundry room. Hallways connect other rooms and direct traffic between them. There are a limited and strictly defined ways to enter and leave the house - through doorways. You wouldn't consider eating in the bathroom and you wouldn't design a house with only one or two large multi-purpose rooms. You wouldn't try to use windows as proper ways to enter and exit simply because you failed to design for doors. Yet it is this very misguided reasoning that leads to the failure of countless OOP projects.

Another problem that OOP projects succumb to is failure to recognize the boundaries of OOP. Object oriented design was not intended as a solution to every problem. Indeed no methodology can make such a claim. Yet the insistence of some OOP evangelists that it is the methodology for every project is precisely why projects not suited to OOP fail. OOP, like any other methodology, has limitations and the decision on which methodology to use must be made on a project-by-project basis.

Object oriented programming fully lives up to its billing providing the programmer understands when its use is appropriate. The programmer must also understand more than just the main tenets of OOP in order to make it successful. Design patterns, lightweight meaningful classes, and truly encapsulated logic are all key to a successful OOP project.