Procedural Code vs OOP

Pho3nix

The Legend
Joined
Jul 31, 2009
Messages
32,825
Reaction score
3,033
Location
On the toilet
Hi :)

Was having a conversation with my senior regarding the difference between the two and ways forward because I am a fan (sue me) of the former.
I'm not adverse to OOP but find procedural a little easier to implement and easily scalable for my uses so far.
Problem is I am worried (thus the initial topic) that I might be impeding my own marketability and making life harder for myself when I move into another position eventually.

Understand the concepts of OOP so don't think that's the problem but eish :(
Any words of wisdom from the community at whole?
End goal is to become a kick-ass developer and not a "adequate one". Not sure if this is even a valid concern tbh :o.
 
Prepare for a **** storm :P

yeah. no good will come of this thread.

use oop when it makes sense and don't when it doesn't.

...it just happens to make sense most of the time

Your cursing my thread before it has even started. Come on guys this isn't the age old Experience vs Degree argument :p

@Sp4ceman thanks for you input though
 
Horses for courses ... both have their place in different applications. I reckon any developer worth their salt should be able to use either/both depending on the situation.
Same as the age-old argument about which language you should learn.... why should you limit yourself
 
Horses for courses ... both have their place in different applications. I reckon any developer worth their salt should be able to use either/both depending on the situation.
Same as the age-old argument about which language you should learn.... why should you limit yourself

+1
 
Code:
Person person = new Person("Bob");
Dog dog = new Dog();
dog.bark();
dog.attack(person);

using objects procedurally :p
 
OOP can be really useful, but it's got its pitfalls. I generally do use it, but use it sparingly, and only where it really does make sense.

The bad OOP programmer has never seen a line of code that shouldn't be a method or piece of data that shouldn't be wrapped in a class. The bad OOP programmer thinks that everything should be an object, and that as many OOP design patterns as possible should be used in their code.

The good OOP programmer tries to figure out what the objects in the system really are. If the class names have to be suffixed with "Manager" or "Helper" or some such, they probably shouldn't be classes. The good OOP programmer realizes that sometimes a struct is just a struct, and sometimes a procedure is just a procedure.

I have recently worked with two 1M+ line code bases. One had ~50 classes, the other had ~6000. The latter, I couldn't figure out WTF was going on in, since the class model mapped very very closely to a particular mental model, that the architect had - so precise that I couldn't figure out what was going on, since his mental model of how things work differed from mine (and likely anybody else's). The fundamental issue I realized was that, while any good developer can follow the logic flow with in a well written procedural program, if someone starts to create objects and classes that have no "from common understanding" conceptual backing, but are rather just convenient groupings of code and data, things can go south rather quickly.
 
Last edited:
I agree with cguy. Know when to use OOP and when to use procedural code. Precede that with good understanding & concepts will make you into a kick-ass developer.

It comes down to continuous learning and practice.
 
My Opinion: Understand and master OOP if you want a bright future in programming, and as a rule of thumb, use OOP when it does not add unnecessary complexity to your application and don't use it if it does.

You really have to objectively look at what is best for the specific project in front of you, and then decide between the two models which is best without taking into account your personal preference. My experience will show that "personal Preference" itself sometimes adds unnecessary complexity to any project. It is for that reason that leaders must have an objective vision about a project in order for them to lead the team down a path that suits the project.
 
Years and years back when I first learned to really program, on my HP48sx, I was writing a pretty complex procedure that I needed to put a piece of program code onto the stack, change some parameters and then execute the program. The HP just wouldn't let me do that of course and had to change my whole tactic.

Years later I came across OOP, and realized how easily my original program could've been done if the HP's programming language was a bit more powerfull and not so procedural.
 
Once you truly understand oop and the single responsility principle you dont go back to anything else

OOP or die trying...
 
Your cursing my thread before it has even started. Come on guys this isn't the age old Experience vs Degree argument :p
No it's worse, like who has the best kid.

From my experience have OOP on your resume for project managers but use it only in self defense. Basically only use it where it makes sense which will not be often. If you feel like you're forcing it then you are.
 
1wait. just for fun whenever you say yes or no please type the language and what kind of code you most frequently write.

i use oop pretty much everywhere in c# asp.net mvc. i very rarely use static classes and i use dependency injection and tdd.

if you don't write oop what kinds of systems are you writing
 
1wait. just for fun whenever you say yes or no please type the language and what kind of code you most frequently write.

i use oop pretty much everywhere in c# asp.net mvc. i very rarely use static classes and i use dependency injection and tdd.

if you don't write oop what kinds of systems are you writing

this
 
From what I know you can't use OOP in assembler... lol
[)roi(];12753269 said:

Actually, you can do OOP in both of them, they're just not OO languages. If you're counting virtual machines, there's also Jasmin, which is an actual OO assembler.

See also:

Object-Oriented Programming With ANSI-C (book)
and
Object-Oriented Programming in C (Dr. Dobb's article)
and
Object-Oriented Programming in Assembly Language (Dr. Dobb's article)

I've actually worked with variations on both of the above during my career.
 
Top
Sign up to the MyBroadband newsletter
X