Object Oriented Programming not necessarily superior !
In the programming world, OOP is considered the panacea of programming methodolgies ! Well, that is what most people think anyway, but is it ?
I am a 100% procedural style programmer and I don’t feel OOP is really all that more superior than procedural style coding. Now there are a number of viewpoints about why OOP is not any better, but for moment, I will state how I view OOP. I don’t have anything against it, but neither do I feel it is some how inherently superior either. The idea that everything needs to be an object is just plain false. Now there are some cases where the concept of objects may ber very useful, but rather than view it as a core programming style, IMO objects should simply be considered just another data type (albeit with some code attached). Just like you choose different data types for different requirements, objects can simply be just one more tool in your toolbox. I just don’t think OOP should take over a programming language so everything tends to be an object.
OOP requires a lot more planning up front, so in the long run if it is used indescrimently, then you will end up taking a lot longer in writing software and make it more complex. When OOP as a data type actually fits the job, then it may just be worth it.
The idea of things like COM, ActiveX and now OOP originally were thought up to encourage code reusability. Some suggest that OOP produces better software because you can reuse OOP objects. In my own experience though, I have found that rarely can one reuse overly complex blocks of code. The more complex code is, whether as an object or as a procedure, the more likely it is too unique for it to be used over and over again. The simpler a piece of reusable code is, the more likely it can actually be used over and over again.
To illustrate: Imagine you write a routine or an object, which has the sole purpose of drawing a line of text. It may have a few options, such as defining the font to use and the text. Likely such a routine would be used a great deal, so code reusability works well. Now imagine you create a routine or object, which has the sole purpose of drawing a line of text at the perfect center of a circle and only useing a specific style font (always fixed width). Now this may be useful for the current project, but it does not sound like something one may use a lot. Why ? Because it is more specific, tied to a specific project. So the more complex a routine or object becomes, the less likely it will be used over and over again and if one attempts to try to use it in places where it is not well suited, it will be more like a round peg in a square whole.
I believe this may be at the core of one problem with any code reuse, but especially with objects. Objects tend to be much more complex than procedural routines, because you can build complex data types into them and add many layers of code to them (methods). While one may build an object which can be reused, the idea of using that object to build upon to create even larger more complex objects, simply creates all sorts of problems. The idea of inheriting and building upon another object, sounds great in theory, but in reality it could end up making software more complex and slower, because if you build too many times up previous objects, the complex increases greatly.
Procedural style programming tends to encourage building reusable routines which are smaller and more managable. For example, one may have a complex calculation used a lot in a trade and it could be turned into a useful function. It saves a lot of code, because you reuse it over and over again, but it is small and managable and one is less likely to make changes to it which will break other code. Objects tend to be complex, so many changed internally could be common. Procedures and functions tend to be smaller and more task specific, so one rearly needs to change them, unless they are broken somehow, so the code is less likely to cause problems elsewhere in an app.
I strongly feel that code reusability is viatl for faster software development, but that procedural style coding can produce much better and more efficient reusable libraries. Also I tend to build libraries on the fly, rather than over plan them. The reason is that one never knows whether a routine designed to be reused will actually be used that much. Now if I start coding and I see that some code I wrote is being written multiple times, then it becomes obvious that such code should be put into a reusable routine. This decrease the amount of planning that has to go into designing an application, but yet still encourages code reusability. There is no harm in writing code to be used simply once and then to later find, that it would make a good routine. You see, the code has likely already been tested and you know it works and now you know it would be worth the time to convert it into a procedure or function and most of the time it takes little effort to copy a block of code and turn it into a function. If libraries are built this way, then the routines are more likely to be truly valuable. You saw the need to move it to a function in the first place, so it is obvious it can be reused a lot more.
My own GUI engine was built this way. It progressively grew and sections of code which once were embeded in the library, were taken out of a large section of code and converted into a smaller more managable reusable routine.
Now some programmers have some very strong viewpoints about OOP and why it is not as “rock solid” as some would have you believe. Now while I may not agree with every view of these programmers, they do have a number of valid points worth considering. Here are some links to some very interesting articles:
This is my favorite, by Richard Mansfield: http://www.4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf
Some more articles:
http://blog.dmbcllc.com/2008/05/13/object-oriented-programming-has-failed-us/
http://www.bitwisemag.com/copy/bytegeist/bytegeist1.html
http://www.cs.loyola.edu/~binkley/772/articles/oopbad.htm