Object Orientation is a rather old concept, with its inception dating back to 60's. It gained prominence, however, in 90's. There are many reasons, none so concrete, for its sluggish growth in mainstream software development. Some ascribe it to the high level of abstraction accounted for in the Object Oriented model. Some described it as too restrictive. The former argument was in the light of the fact that Object Orientation models require comprehensive definition of the problem description so that the resulting model is complete in all respect, i.e., resemble a real world problem, per se. The latter argument was offered by the traditional programmers, who were masters at procedural programming. As they were habitual of jumping off hither-thither, in the program and (directly) in the memory both, to improve performance, which is not recommended, if not prohibited, in Object Oriented paradigm (see how a sentence becomes complex just with commas), they found it restrictive. Technically speaking, the only bottleneck for implementing Object Oriented Architecture on contemporary machines was their poor hardware. If we compare with current technology trends, memory sizes then were too small and processors were too slow. As the hardware technology improved, it paved way for Object Oriented Designs of the Software. Interestingly, the concept of Object Orientation is adhered to surprising levels in Hardware technology, since long. The chip designs are modular. Each chip does a specific job, mostly mutually exclusive to any other chip. Newer variants of same chips augment their functionality, in hardware parlance, improving speed and reducing size. A combination of chips gives a specific set of functionality.
History apart, Object Orientation is still not taught in most of the engineering schools and commensurate institutions. Reason is beyond comprehension. My personal experience says, there is no alternative to Object Oriented paradigm. Procedural Programming is good. Great, in fact. It is the threshold. Undoubtedly, it has served the since long, and served well. But then evolution must occur. Procedural Programming is ill suited for software development of complex problem spaces. For example, implementing an enterprise wide software solution, that encompasses entire business of a company. If the company is, say, a manufacture sector giant, its scope of business has virtually no bounds! Not only its sites can be geographically spread but also, dealing in altogether different domains. Geographical diversification causes taxation differences, while different in domain may be understood as manufacturing of different products. A software that collates all possible diversified business domains and scenarios is bound to be complex. Added to it is a requirement of being flexible. Government (or Regulating Agencies) derives incalculable fun in tweaking fiscal and administration policies every now and then. Incorporating them in a live environment is a risky business. It may render a working program error prone. Now, for a company with revenues in billions of dollars, a minor precision error at third place of decimal may translate into a loss of, at least, few million dollars!
In such complex scenarios, Object Orientation Designs kick in. More importantly, it fits in very well. Since same component is reused, a erroneous change in it is, in first place, traceable and second, localised. Well, same can be said for code libraries. But, libraries are for used predominantly sundry and rudimentary functionality. As in, one needs to compute a factor using a complex algorithm, he can put the logic in a library function and call it whenever and wherever needed. Problem solved. For current company. In case of a standard product, used by a host of companies of different verticals it is not so easy. The solution provider needs to keep versions of libraries for different companies, with further versions for a single company satisfying needs of locales and sundry changes.
If we look closely at the fundamental reason behind it, it boils down to a simple fact: Change is eternal. Flexibility is a difficult demand to meet. Although much needed, for in its absence, most of the service sector companies' existence, big and small alike, will be redundant. In Object Orientation parlance, tackling this issue is suddenly much simpler. If a demand is not met by standard product and an enhancement is required, the standard product needs to be augmented, by inheriting all previous logic and adding the missing functionality. Agreed, it sounds similar to procedural programming with additional overheads. But, important fact it, it is much more manageable! As in, Object Orientation, by definition, provides a way to tackle such scenario. Rather than having skewed names for code libraries, one can segregate the special cases under company specific or industry specific names. Frankly speaking, the real issue is not to find a solution for the ever emerging problems. A good programmer strives for challenges. The real issue is to solve it in such a way that it enhances the product, augmenting its value commercially, deepening its penetration in myriad of verticals seamlessly, evolving it into such a product that in future, just a few simple configurations makes the product deployable, in no time which means cost reduction the client company. That's precisely what is in demand: A flexible, reliable, cheap product that can be deployed fast. Object Orientation is the key.
History apart, Object Orientation is still not taught in most of the engineering schools and commensurate institutions. Reason is beyond comprehension. My personal experience says, there is no alternative to Object Oriented paradigm. Procedural Programming is good. Great, in fact. It is the threshold. Undoubtedly, it has served the since long, and served well. But then evolution must occur. Procedural Programming is ill suited for software development of complex problem spaces. For example, implementing an enterprise wide software solution, that encompasses entire business of a company. If the company is, say, a manufacture sector giant, its scope of business has virtually no bounds! Not only its sites can be geographically spread but also, dealing in altogether different domains. Geographical diversification causes taxation differences, while different in domain may be understood as manufacturing of different products. A software that collates all possible diversified business domains and scenarios is bound to be complex. Added to it is a requirement of being flexible. Government (or Regulating Agencies) derives incalculable fun in tweaking fiscal and administration policies every now and then. Incorporating them in a live environment is a risky business. It may render a working program error prone. Now, for a company with revenues in billions of dollars, a minor precision error at third place of decimal may translate into a loss of, at least, few million dollars!
In such complex scenarios, Object Orientation Designs kick in. More importantly, it fits in very well. Since same component is reused, a erroneous change in it is, in first place, traceable and second, localised. Well, same can be said for code libraries. But, libraries are for used predominantly sundry and rudimentary functionality. As in, one needs to compute a factor using a complex algorithm, he can put the logic in a library function and call it whenever and wherever needed. Problem solved. For current company. In case of a standard product, used by a host of companies of different verticals it is not so easy. The solution provider needs to keep versions of libraries for different companies, with further versions for a single company satisfying needs of locales and sundry changes.
If we look closely at the fundamental reason behind it, it boils down to a simple fact: Change is eternal. Flexibility is a difficult demand to meet. Although much needed, for in its absence, most of the service sector companies' existence, big and small alike, will be redundant. In Object Orientation parlance, tackling this issue is suddenly much simpler. If a demand is not met by standard product and an enhancement is required, the standard product needs to be augmented, by inheriting all previous logic and adding the missing functionality. Agreed, it sounds similar to procedural programming with additional overheads. But, important fact it, it is much more manageable! As in, Object Orientation, by definition, provides a way to tackle such scenario. Rather than having skewed names for code libraries, one can segregate the special cases under company specific or industry specific names. Frankly speaking, the real issue is not to find a solution for the ever emerging problems. A good programmer strives for challenges. The real issue is to solve it in such a way that it enhances the product, augmenting its value commercially, deepening its penetration in myriad of verticals seamlessly, evolving it into such a product that in future, just a few simple configurations makes the product deployable, in no time which means cost reduction the client company. That's precisely what is in demand: A flexible, reliable, cheap product that can be deployed fast. Object Orientation is the key.
