Which is better and why: Procedural vs Object Orientated.

biometrics

Honorary Master
Joined
Aug 7, 2003
Messages
71,858
I'm old school and prefer procedural coding (object based, event driven & procedural). What's the big deal with OOP?
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
6,282
I'm old school and prefer procedural coding (object based, event driven & procedural). What's the big deal with OOP?
What language(s) are you coding in?

This is a pretty big topic, and for completeness you probably also want to ask what's the deal with the other approach: FP (Functional Programming)
 

cguy

Executive Member
Joined
Jan 2, 2013
Messages
8,527
I'm old school and prefer procedural coding (object based, event driven & procedural). What's the big deal with OOP?

The way I see it, OOP provides a convenient way of binding context/state to related functionality. It also, then provides convenient mechanisms to make incremental changes to such bindings, and also to combine, share and reuse code.

That said, I have become very conservative with my use of OOP over time. It makes a lot of sense for containers and APIs (especially callbacks). Also, it usually makes sense for certain high level constructs of your code design. This is about the extent that I use it today. I've seen plenty of code bases that have gone gung-ho on OOP, creating accessors for every attribute/member variable, a new class hierarchy every time a piece of code is shared, bundling every function into some sort of class, making every structure a class, overloading variables in bizarre ways, etc. the net result being that to understand any given 20 lines of code, you have trace through 15 different files to see what is actually being run - assuming you even can know, since you may not even know what subclass is being called from a static analysis of the code.

So, in general, I use it, but I don't ever sacrifice clarity for some misguided notion of "OOP purity". I would much rather work in a large C code base, than a large C++ or Java code base that didn't have a very good architect (both for initial design, and for preventing random people from OOPifying anything that looked OOPifiable ;) ).
 
Last edited:

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
6,282
I agree with cguy overall; IMO the approach to OOP, Procedural and FP need not be so substantially diverse; in fact much of the principles of Procedural coding has been adopted in FP and is gaining ground in OOP circles i.e. the notion of avoiding unnecessary object complexity, and focusing on creating easy to test functions with minimal to no hidden inputs and effects.

Naturally some areas OOP style code is a bit more valuable than others e.g. UI, but that doesn't mean the entire design needs this. Ratios vary, but I generally for apps lean towards a UI OOP veneer (10-20%) and FP Body (80-90%).
 
Top