Back to Basics: Object Oriented Programming for Procedural Developers
Published on August 3rd, 2006 by DannyT. Filed under Best PracticesI have recently had re-emphasised one of my first lessons in learning OOP (Object Orientated Programming). If coming from a procedural background:
“Forget 95% of what you already know”
The majority (if not all) of the developer-geek type people I have met all originally learnt procedural programming. Also the majority, at some point, thought of OOP as “the next step” or an extension of their existing skillset. I am confident that because of this perspective the learning process is shrouded by preconceptions of how things should be and makes for a frustrating and confusing time. Which I would also apportion to the number of people who have attempted and retracted from OOP (myself originally included). Also going from a proficient developer in procedural to newbie can also quickly take its toll on the appeal of OOP.
I have recently been working on an application that was developed in VB.Net but in a procedural style. Whilst this system performs well and is stable, it is a pain in the ass to maintain and extend which are the real benefits of OOP (not so much code re-use as is promoted by many as the main advantage who are perhaps more academically aware than real world experienced). This is what prompted me to write this post for anyone tempted to try learning OOP, leave procedural at the door for now, not that existing knowledge will be redundant but until you get to grips, plead ignorance.
This concept has been suggested by others and more thoroughly investigated, I firmly agree and would enforce that OOP IS NOT Procedural coding, nor an extension of, or a step above.
Markus
October 7th, 2006 at 1:21 pm
Hi,
well I personally really can´t agree to this “forget 95%” advice as well as the author of the second link above (“suggested by others”) who classifies Java simpler compared to C++. I´m not a professor or something alike and the only person I´ve teached OOP at this time was myself.
In my opinion you shouldn´t introduce anymore the term of “procedural programming” because this is for me the real confusion in this area. Confusing because there isn´t always anymore a precise borderline between procedural and object-oriented programming.
Take for example JavaScript. You can write little programs with several functions calling each other without using one self-customized object. With my understanding this is like prodedural programming. But where are all these functions located? In the “main-object” of JavaScript. Mhhh a function contained in an object. Other people and me would call this also a method. Is this OOP? Definitifly not! But should somebody for example coming from JavaScript who wants to learn ActionScript 3, Java or C# forget 95% (most) of the “old language”? I say NO! Not only because in this example there are many paralells in syntax, operators and keywords but also because the way of thinking in “procedural programming” is indeed a small subset of thinking in “object-oriented programming”. For me grouping sub-processes together to a function is similar to encapsulation without the data hiding which is one important feature of OOP. And where is the difference between functions using other functions and composition in OOD?
OOP simply provides much more tools for writing better structured and maintainable code.
Both authors of the links contained in this article shouldn´t tell somebody what they have to forget to learn something new. Their problem lies in how to teach it. Lastly to comment something to point 2 of the author of the third link (“more thoroughly investigated”):
“The danger with hybrid languages is that students with prior programming experience in a procedural language are not encouraged to change their style.”
-> This is a lack of the teacher´s competence not a danger coming from hybrid languages!
“… beginning students often believe their work to be finished as soon as the compiler accepts their program.”
-> That´s why there is a teacher. Nobody goes to a course because of the presence of a compiler.
If I would start a course I would ask which candidate has already used or has tried to use OOP / OOD and not telling them first to forget something they have worked arround.
Another last word: I hate this classification “procedural”. Take again JavaScript and search the web if JavaScript is procedural or not:
- Wikipedia says YES
- ECMAScript Lang Specification doesn´t mention this term once (so NO?)
- JavaKicks.com (http://www.javakicks.com/j2ee/JavaScript_can_function_as_procedural_and_an_object_oriented_language)
“JavaScript can function as procedural and an object oriented language” (YES)
Thats why I neither mind anymore about this “procedural” thing nor would I tell somebody …. you guess it!
Markus
October 7th, 2006 at 1:30 pm
Oh yea, another thing and the way I found your blog: Could you perhaps send me an invitation to wallop.com? This would be great!
Greetings!
Markus
October 8th, 2006 at 12:48 am
Hi Danny,
thank you very much for sending me an invitation
(and so fast).
Greetings
DannyT
October 9th, 2006 at 9:06 am
Hi Markus, thanks for the well thought out comment. I do agree that there is no clear distinction between OOP and procedural programming, as with many languages you may have to rely on a combination of the two as you mentioned.
My point however, was more concerned with the approach taken to an OOP project vs a procedural. My post originated from my experiences with a VB.Net application that had been clearly written by someone with a background in VB6/VBA. This took me back to when I was learning AS2 and .net and how I would continually end up creating objects that were essentially acting as holders for massive long procedural functions.
When I went on one of Aral’s courses, he highlighted to me to ditch my procedural approach and start with a clean plate. Everything started to fall into place then. Of course if I needed to carryout conditional statements, loops and other snippets I could do no problem based on my existing knowledge.
I would say planning and building an OOP application vs procedural is about 95% architecture and design and 5% language specific syntax. That’s very ballpark guesstimates but its the principle I’m referring to.
(No problem re: the wallop invite
)
Markus
October 30th, 2006 at 3:59 pm
Hi Danny,
mainly because of the one or other comment from one of the authors mentioned above.
I totally agree to that. Some weeks later I have to admit that I overreacted a bit
Perhaps I misunderstand them all but I don´t like this “procedural programming 98% bad” standpoint which is definitely not yours
.
Greetings from Germany
Markus