Procedural v.s Object oriented programming?

[chronozphere]

Hey Everyone, :)

I have taught myself, during previous years, how to write proper Object Oriented code. However, I've noticed that there are still a lot of programmers who prefer the old procedural style. Personally, I can't imagine how to structure my program without using classes/inheritance/visibility and other OOP techniques.
So I was wondering, how do you feel about this? OOP or procedural? Can someone explain to me how to write big programs without creating any classes?

Chronoz

[code_glitch]

Now this is totally honest from me, (i'm not that good a programmer and maybe that's why) but:

a) you can create classes in pascal? I never went past record in datatypes.
b) OOP?? I just use functions and procedures inside units.
c) structure, depends on what I'm doing. But usually, Its simply based on the units I'd made previously.

But as far as I know OOP is better than procedural so why would you want to revert?

cheers,
code_glitch

PS. How do you make a class in pascal??

[chronozphere]

Yes, you can create classes in pascal and use all the features that Object orientation has to offer. (Delphi and free-pascal are both "Object pascal" compilers which support OOP)



But as far as I know OOP is better than procedural so why would you want to revert?


Well, many people say that it's better, but we can put some question marks there. There are still cases where the procedural approach is better than the OOP approach. There is actually no such thing as "better". Most people prefer OOP nowedays. And no, I don't want to revert. I simply would like to know how to use procedural programming for a big project, without getting lost. :)

[Andru]

I like procedural style more than OOP(I use it only with C++ at work), and I can't explain exactly why I like it more... maybe because of love to OpenGL and system programming :)


Can someone explain to me how to write big programs without creating any classes?
Hmm... structures, good architecture and there is no problems with it :)

[Carver413]

OOP has always been my choice but not the whole drag and drop thing. although I use lazarus rarely do I use the Vcl I prefer to start with my own base class and go from there. trying to follow your way back through the many class inheritances is some what of a pain. that and most of whats there is no use to me. The other thing that is important to me is having scripting built into the class which is why I use my own base class. it has scripting built into the base so every class that desends from it will naturally inherit this. whether I need to dump the contents of a single object or an entire tree it is always there and I am in control. with a single import I and pull in a very complex scene without the need to hard code it. each object can literally contain its own language that exists only as long as the object exists. scripts can run locally from within the object or globally from the top of the tree. it would be difficult to pull that off procedurally.

[WILL]

Well if you wanted to take a step back in time and make a non-OOP [Standard] Pascal program, don't declare any classes or lists. Instead use records and arrays alone. This had proved memory intensive for large arrays of records so you could instead allocate a raw chunk, or chunks of memory and then count your data as you go along, this however is instruction intensive, but you have to weigh the benefits of the one to fit the needs of the other. Starting to see one of the reasons why the object oriented approach to allocating 'objects' was something of a breakthrough? ;)

Also instead of having a triggered reoccurring method (a nono in the pre-OOP world) where your application would cycle, you'll have to keep your code executing inside of a single repeating loop. This means of structuring is still useful today, though it will negate the ability to use multi-threading, a now mainstay in most desktop or laptop computing. Probably not something a super-3D engine would want, but for some smaller and more independent scale games, this works just fine too.

OOP is great and it adds all kinds of benefits, --such as more organized code, more optimized memory allocation and multi-threading-- however it is still possible to over-objectify all your project code and add more work to what should be a small or quick and dirty game project. As programmers we're allowed to cheat a little to get the job done, like my old highschool CS teacher used to say "programmers are lazy, so we should always try to do things in a way so that we can be lazy." :) It's a weird way of putting it, but the idea behind it was to code to make your job easier not harder. At least I sure hope that was his message. :P

[farcodev]

I like procedural more than OOP, in FARC in only use OOP for only one system which is used only in the first part of the game and useless after, it's better to free it.
I'll use it also for production caculations threads.
But apart that, it's mainly records/procedures/functions formatted following strict rules.

[code_glitch]

And I still don't know what I code in... Don't really want to know either since half the time it's a mess.

Apart from that, I have written some programs with only procedure, but I would recommend against it for your own moral sanity. In my experience, I would agree with farcodev:

it's mainly records/procedures/function and that would be as far as my vocabulary goes, and seems sufficient.

[Bpascal]

I think i use OOP where it belong, I mean mostly when writing libs for been used for me or others programmers, when i want complicated things be translated to be used in an easier way; and where instancing that piece of code has sense.

I still use plain Procedures & functions with Var parameters and simple Records in my programs when they are just more that enough to implememt somthing;

I have seen people create class just becouse they can, but not becouse it is necesary; i have seen classes which are too short that with one simple records and 2 or 3 simple procedures should have been enough.

the other day i was reading a game programming book for C++ where the autor difined into a class the matrix and vectors maths; so he like to use things like mymathlib.vectoradd(v1,v2); :P

[virtual]

i've seen some big projects using procedural programming like Blender and Quack .. , personally i like procedural in C/C++ ,and OOP in delphi

[WILL]

I sort of do both really. I use the structure of OOP to make all my game objects (player or players, enemies, pick-ups, etc) and the game world (map ro level) into an object. And inside of those I create functions and procedures that do the majority of the manipulation of those objects to control that game mechanics.

Then my main code block is a single loop (no real multi-threading for me like this unfortunately) where I check for what game mode state the game is in and place all my objects' functions in there. I may also have supporting functions which are placed above the main game loop, such as the game reset/initialization block, program startup (init all my SDL, OpenGL, textures, input options, menus, etc...) and clean up after quitting code too.

Unless you are working for a professional development company, there is no set rule that you have to be all OOP or all procedural, it's all up to you and what is availible with the tools you use. As an indie game rpgrammer, it's about doing it the way YOU want.

[User137]

I use OOP mainly. Just something like math unit contains functions and i have no desire to make them classes.. nor should anyone. There are millions of benefits from using classes and i'm pretty sure they're discussed through plenty of times :p

[NecroDOME]

To work OO with procedures, you can make something like List.pas. This has a function CreateList(): Pointer;
From this on you can make functions like
ListAdd(ListPointer: Pionter; item: Pointer);
ListRemove(ListPointer: Pionter; item: Pointer);
List...();

[chronozphere]

i've seen some big projects using procedural programming like Blender and Quack .. , personally i like procedural in C/C++ ,and OOP in delphi

Now that is interesting. Does anyone know any other big opensource projects that are using the procedural paradigm? I would like to browse through the code to see how they solve problems (that are otherwise solved using Inheritance or other OOP techniques).

@NecroDOME: Yes, I know what the idea is. OpenGL uses that kind of routines. I kinda like it, but I also like OOP. :)

[DarkBow]

In my personal projects I tend to use OOP as much as I can, although probably not good enough :P.

On the other hand, In my current work I can not do that (although I try hard) since most of our codebase (1.2 million loc approx) is made in procedural and drag-and-drop-onto-the-form style. :(

[Nitrogen]

Thats quite nasty! I've been getting increasingly more and more OOP orientated with my projects as I go along. My older stuff was a horrible mess of procedures in each unit.

After the last 2 year's experience with actionscript, php and java (in java "everything is a class" is a fundamental rule), I put each class in it's own file and use a pure OOP paradigm for everything.

At my work, all my projects are OOP and even use MVC (model view controller paradigm) on top of the OOP structure...

[Ñuño Martínez]

I didn't read everypost you wrote, but I think there is a "problem" whith the "Object-Oriented Programming" concept.

I mean, Many people think that OOP is a feature of certain programming languages. I don't think so. I think that OOP is a way to face a problem.

Actually it's possible to do OOP in plain C, including encapsulation and inheritance! (And I mean plain C, not C++ nor Objective C). An actual example; there you have the Allegro library (http://alleg.sourceforge.net/), written in C and Assembler but using an "Object" approach to define lots of objects. If you see the description of the BITMAP structure you'll see it has a virtual method table to define functions as drawing primitives, blitting, sprite drawing, etc.

On the other way, use a language that has classes doesn't guarantee that you're using OOP. Actually most Visual Studio, Delphi and Lazarus programmers I meet use objects but they don't use OOP! They just drag'n'drow some components to the form and program responses to some events and... what? Is that OOP? Can't you do it with pure procedural programming?

Just thinking about this.

[chronozphere]

I didn't read everypost you wrote, but I think there is a "problem" whith the "Object-Oriented Programming" concept.


Yes, there are more people who feel the same way. Just google for some OOP v.s procedural articles. You'll find that there are people who see OOP as a non-productive overly complex way of writing software. Those articles made me create this thread. :)

I think it would be interesting If i did a small non-OOP project (something like pacman or so). I'm especially interested in how inheritance is done with procedural programming. You mentioned a virtual method table. I have to look into that. :)

[Nitrogen]

You'll find that there are people who see OOP as a non-productive overly complex way of writing software.

Strange... I see things like MVC has a non-productive, overly complex way of writing software, whereas OOP is just like a fundamental. It's a given. I wonder if I'd feel that way about MVC if I was involved in hectic multi-person projects...

[chronozphere]

OOP is a way to think about software. Some people never got used to OOP (the oldschool coders) and others just love the C-feeling of procedural code. I can understand this, because the C language is very easy to understand, yet powerfull (The same can be said about pascal because you can consider it a superset of C, functionality wise). The problem with OOP is that it restricts your way of thinking about your code. The constructs in OOP are flexible at the beginning, but as a project progresses, you may run into all kinds of problems. For example, if you heavily rely on complex things like polymorphism, generics or operator overloading, it will be very hard to understand what's going on.

About MVC, I think it has some good potential. For example, I'm working on a PHP web project, where I am using an MVC framework (KohanaPHP). I must say that for this kind of application, it works great. :)

[Ñuño Martínez]

I'm especially interested in how inheritance is done with procedural programming.

An example:


TYPE
TClassA = RECORD
PropA: INTEGER;
END;

TClassB = RECORD
Parent: TClassA;
PropB: INTEGER;
END;

Assuming INTEGER as 32 bit, both records have the "same" first 32 bit, so you can do something like this:



VAR
TheObject: TClassB;
OtherInstance: ^TClassA;
BEGIN
OtherInstance := POINTER (@TheObject);
OtherInstance^.PropA := 1;
WriteLn (TheObject.Parent.PropA);
END;

Add procedures and funcitions to the equation and here you have the beggining. :)


(...) For example, if you heavily rely on complex things like polymorphism, generics or operator overloading, it will be very hard to understand what's going on.
That's why I never use generics nor operator overloading. When I programmed C++ I had lots of problems with that. Sepcially with operator overloading, because a lot of times the compiler selected the wrong one doing weird conversions and returning bad data. The worst is that data is "valid" so it's hard to find where the problem is.

BTW, I think most people don't use it correctly. It seems as they're using it because it's cool or because everybody uses it, but I'm not sure if they're really think about if it's really useful or helps to the development.