I still remember the days back in the early 90’s when I was learning object PASCAL,there was a debate about whether object oriented programming (OOP) would become the next big thing. And it did. Today,almost all computer languages support OOP,even Perl.
The true concept of OOP, albeit old, is still quite foreign to most of the mainstream programmers. Sure, you might argue that almost every one uses an object oriented language nowadays, but very few uses inheritance for bigger concepts across the system.
Sure you use objects, but in most of the business applications, objects are used the same way as C libraries–you declare the object you want to use, call whatever the method you need and that’s it. Almost all the business applications I’ve seen so far use objects only in the most rudimentary way, and thus are not cruel object oriented design by nature. Object orientation requires deeper understanding of the business and programming, requires significant investment in research. But in reality, most businesses are task driven. Your manager wanted you to get something done, and get it done fast. With the minimal input and time constraint, you would almost always resort to the “traditional way” of programming, creating a program that is defined by its input and output and ignoring its architecture.
It is not necessarily a bad thing given how fast technology changes these days. For most businesses, writing an object oriented system versus a component based system might not differ much. But it is easier and cheaper to hire someone who can understand the component based system and make changes to it than to find a true OOP guru. And for the outside world, as long as the system functions as it should, no one really cares how the system is originally designed.
I see this trend happening in most businesses and the only places where OOP really matters remain in schools, a handful of companies that develop components, and of course, the companies that created the computer languages that you use…
